Linux/AM3358: PRU RPMsg example on Linux side

Thank you, Nick.

That's what I was looking for.

Is sysfs write/read the best/only way for passing messages back and forth, or is there a more 'direct' way to communicate between the ARM and PRU cores? I haven't checked it yet, but my initial concern would be performance/latency when messaging through the file system... (Analog to the GPIO sysfs set/clear vs. direct mmap() access performance comparison).

Setting/clearing bits back and forth would be probably sufficient in terms of 'messaging' for my application.

Extra question (unrelated): Is there a PRU example that shows how to transfer larger amounts of data (data stream acquired through the PRU interface) directly to RAM (and then being read/processed by the ARM)?

Thanks again,
Dusty.

Hey there Dusty,

Yes, RPMsg is a bit slower since you need to copy the message several times as it goes through the kernel. If you do not need the message portion, you should be able to go faster using just interrupts.

Answers to the rest of your questions are affected by whether you are trying to communicate with the PRU from the kernel or from userspace.

For communicating from the kernel: I do not have a TI example for you where the kernel sets the PRU INTC bits directly, but some other customers have implemented something along the lines of what you seem to be looking for. Check out these posts: customer #1 seems to use DMA and directly sets the INTC bits in posts 1 and 2. Customer #2 looks like they use a mix of RPMsg and directly setting INTC bits in post 3.

NOTE: I am not sure if customer #2 is operating in the kernel or userspace. If they are in userspace, that changes my understanding of userspace limitations. It looks like those customers implemented it slightly differently, so I would appreciate hearing how you choose to do it.

For communicating with userspace: TI has not currently implemented a way to expose a block of PRU memory to userspace through RPMsg - that is a benefit that UIO offers over RemoteProc (TI hasn't supported UIO for several years). If your end application has elevated permissions, you could use /dev/mem to expose the PRU memory (including INTC registers). If not, you could create a kernel driver that exposes the PRU memory, and then your userspace code could interact with the driver. Also see NOTE above.

TI does not have an "official" way to move large amounts of data between the PRU and the ARM, so we do not have any examples directly showing data transfer. The PRU can access the entire memory space once you clear the the STANDBY_INIT bit of the SYSCFG register, so as long as your application can access that region of DDR you should be set. There is a certain amount of delay between the PRU and DDR, so some customers prefer to have ARM read data directly from the PRU's local RAM rather than DDR. If using userspace in this context, see "For communicating with userspace" above.

Regards, 

Nick

Great, thank you. I will work through all the resources and let you know what we end up with.