> > *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).* >
I've never done this personally, But wouldn't it be faster to write from the ARM core directly into the 12k PRU shared memory ? Or is that what you're proposing ? On Thu, Jun 23, 2016 at 12:02 PM, Charles Steinkuehler < [email protected]> wrote: > 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. > -- 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/CALHSORpdXSv3mW3NYNicrBRCUuwWpDgnm37RK6WtfjtCbVyoQg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
