How to Use the PRU to Control a Peripheral: PRU_ADC_onChip on Sitara 335x using Beaglebone Black
ฝัง
- เผยแพร่เมื่อ 20 ธ.ค. 2018
- Sitara AM3358 Processor
www.ti.com/product/am3358
Sometimes, it makes more sense to control a peripheral with a deterministic,
dedicated processor rather than a general purpose ARM core in a TI processor.
Applications range from a dedicated monitoring system to a real-time
environment where stimulus requires a response from the processor in a known
amount of time. This video shows an example of how to use the Programmable
Real-time Unit (PRU) core to control a peripheral on any TI processor with a
PRU-ICSS or PRU-ICSSG.
Download the AM335x Processor SDK
www.ti.com/tool/PROCESSOR-SDK...
Download the PRU Software Support Package
git.ti.com/cgit/pru-software-...
Order the BeagleBone Black
beagleboard.org/black - วิทยาศาสตร์และเทคโนโลยี
thanks.... Nick....
Stop using shared memory. I do not understand why this is so fricking hard. Use a hardware FIFO between non-real time application processor and real time controller. This avoid contention issues against single interface. If you want to do software FIFO, Queue, etc. make it dual port. Its not hard to make a small SRAM do this. It would allow deterministic IO access and prevent stalls.
Granted you would make up for this with IO buses like SPI which use DMA or FIFO. Technically then you are keeping them completely isolated. Which prevents one from snooping the others IO space.
Technically shouldn't this be using the mailboxes not the RPMsg, which is backed by kfifo?
Very new to Sitara, but shouldn't it be very easy to program your own FIFO on the PRU side ? The mechanism described here appears to be very Linux-friendly, which is probably the point. I don't see any issue with coding my own FIFO's. Is there ?
@@TheNefastor In all fairness this comes from a very hard deadline version of real time. More than likely the PRUs are meant to be state machine automation. There are limits to how hard the deadlines can be. The issue with software FIFOs is that they have state machine values which are hard to properly lock without creating a timing conflict. Granted the PRU's processor design is likely only so strong, so this may be somewhat pointless.
You would want the memory to be on the SRAM side. Without an interrupt, if it exits, there will need to be a polling logic. However multi-direction FIFO on single memory will create access issues. Bus arbitration can solve this some, possibly.
The fact that this standard Linux is a good thing. My issue is also not with the PRU modules. However, the PRUs are not very capable at doing certain things. Even the STM32MP1 suffers from this even though it has more capabilities in state machine automation. PRUs poll DMA to add chip selects to SPI. Cortex-M4F can do more complex things with its own dedicated bus to peripherals and SRAM. Sometimes you just want a few PRUs while other times you want one or more Cortex-M4F.
Writing logic on the PRU or Cortex-M4F can be crippled by the IPC means. It can change the software structure and define what is possible. The issue with most shared memory is the DRAM latency and bus arbitration. Most systems cannot use dual port anymore without creating a serious headache. Multiple individual SRAMs creates headaches and adds area to the chip. However, the programmer does have more freedom here, however I do not know if Linux will use it. RP2040 uses stripped SRAM which may simplify this.
That would allow the shared memory model to likely continue to work without significant issues on arbitration. This would likely be enough for the PRUs intended applications. These pitfalls are not well documented. Most controllers are just state machines, so just adding reconfigurable state machines is likely very powerful. RP2040 provides a lot of different kinds. The PRU is basically one of them. I would not recommend viewing it as a full controller. It can be, however.
@@TheNefastor Again I would look into the mailboxes. If you want to write your own, that is probably the proper way to do it.