How to Use the PRU to Control a Peripheral: PRU_ADC_onChip on Sitara 335x using Beaglebone Black

[@PeterSosinski]

thanks.... Nick....

[@davidthacher1397]

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?

[@TheNefastor]

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 ?

[@davidthacher1397]

@@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.

[@davidthacher1397]

@@TheNefastor Again I would look into the mailboxes. If you want to write your own, that is probably the proper way to do it.