On 6/23/2016 9:43 AM, Vincent lc wrote: > First thanks for your reply. > > So to answer your question, I try to load a data every 25ns. > > I have few questions regarding your reply : > > * Can I write into the PRU memory form a C program on the ARM side at that > can of speed ? (because for now I have succeeded at least) > o In addition does your solution can load several data at the same time > as > I do with the propriety of the register R30 of the PRU ?
Probably. If your data is Byte sized (pun intended), that's 40 MB/s, or about 10 million 32-bit writes/sec (10 MHz). IIRC, the L4_Fast bus used to communicate with the PRU runs at 100 MHz, so there's lots of head room. > * Also the fact, is I am also reading data at the same time (I didn't tell > you > about it previously in order to be clearer)., so can I do so with the > solution "C program on the ARM side do the writing into the PRU memory > ring-buffer" ? Maybe that it would be more easy with your DDR memory > solution ? You can read and write from the PRU memories at the same time. There is no problem with the ARM writing to the PRU data memory at the same time the PRU is reading it. > * Moreover, I didn't new that the PRU got a Ring buffer, is it link with the > section 4.4.1.2.3.3 28-Bit Shift In of the Technical reference manual, or > is > it something else ? A ring buffer is a software mechanism that allows two asynchronous processes to communicate without having to use locks or semaphores, so it is very fast. There are many ways to construct these depending on exactly what you need to do (how many writers and readers there are), and what sort of atomic transactions are supported by the hardware you're running on. Google "lock free queue" and "lock free ring buffer" for lots of details. I expect you will probably be OK with a degenerate single writer, single reader ring-buffer, but you haven't fully explained what you're doing and you keep adding details, so you'll have to figure that out for yourself. :) > * Also the fact with your solution with the DDR memory is that to load a > data > from there I have also observed some huge delay with the LBBO command. Or > it's just me who have done something wrong ? PRU reads from DDR memory will stall until the data is returned, which is one reason I suggested using the ARM core to write the data into the PRU (the writes will post, so the ARM core can carry on doing other things while the data actually gets written). If you want to read data efficiently from DDR using the PRU, you should use the LBBO command to read as large a block of data as possible. The PRU ties into the same L3F on-chip fabric as the ARM and GPU cores, so there's plenty of bandwidth, you just need to read as much as possible at one time to reduce the read latency effects. -- Charles Steinkuehler [email protected] -- 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/4ed0fb23-efa9-dec8-f075-f830318e5e92%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
