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
cha...@steinkuehler.net