I have an application running on the ARM host that writes to the PRU shared 
memory. The PRU core then manipulates that data and sends it out the EGPIO 
pins with exact timing.

For this to work, I need to have a steady supply of data bursts available 
to the PRU core - about 32 KiB each burst. This won't fit into the PRU 
shared memory (12 KiB), PRU memory (2x 8 KiB), or even spread out over all 
PRU memory (28 KiB total). So it's not possible to load the data into PRU 
memory and then kick off the PRU core to send it out the pins. There will 
be a necessary transfer of additional data from ARM host to PRU memory 
after the PRU has started sending data out through the EGPIO pins.

I've instrumented the PRU PASM code using the CYCLE register, and see that 
there is variable latency when the PRU is waiting for a memory block to be 
received from the ARM host. This can be upwards of 5 milliSec, which won't 
work for this application. I've tried using ionice to set class to realtime 
and priority to 0, but this had no appreciable effect.

Is there some way to reduce the latency of writing from ARM/Linux to the 
PRU memory? I've heard that some projects use DMA to transfer data from the 
PRU to host (ARM, system) DDR (e.g. BeagleLogic project) but nothing about 
the reverse direction. Does this even make sense? Will the kernel already 
be invoking DMA during a memcpy from user virtual address space to the 
mmap'd physical PRU memory address?

I need to  provide about 32 KiB to the PRU within 5 milliSec, repeating 
every 20 milliSec. This seems like it should be easily accomplished, if a 
USB driver can sustain 480 Mbps data rates. I must be approaching this the 
wrong way. Any suggestions on how this should be architected will be 
greatly appreciated. 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1ecc3b3e-4986-4120-bbbb-0d8d49902510%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to