First thanks to all of you for your reply. I'm also sorry for my delay. I didn't speak about the reading part early because for me it's seem to be working, So to summarize my code is only doing two things : 1) send different sequences of value on several channels of the PRU and all of them need to be sent at the same time 2) When a data have been send, I read data (from register r31) and store them into the memory (into "/sys/class/uio/uio0/maps/map1/addr") -> And I do this loop until I have send all the data.
@Charles So it's true if L4_Fast bus used to communicate with the PRU runs at 100 MHz I will be really interested in it. If I have well understand it, that's mean that I have to load the data into this location PRU_ICSS 0x4A30_0000 0x4A37_FFFF 512KB PRU-ICSSInstruction/Data/ControlSpace (extract from page 184 of the TRM : Table 2-4. L4 Fast Peripheral Memory Map (continued) ) Previously, I was using this instruction to load my data into the PRU RAM prussdrv_pru_write_memory(PRUSS0_PRU0_DATARAM, 0, sequenceData, NUMBER_DATA ); So now I have to replace it with prussdrv_map_extmem(sequenceData); Is its write ? (sequence Data is my array of data store define as is : unsigned int sequenceData[NUMBER_DATA]; An other question is, in assembly, am I also supposed to load it from 0x4A30_0000 address or there is a padding that I need to had because of the PRU mapping ? When you are saying : > 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. > you mean use LBBO (LBBO REG1, Rn2, OP(255), IM(124)) with IM=124 write ? Before I start to do so, have you got an idea of the "read latency effects" that I have to expect in this specific case? @ TFJ So with the message for charles you should see my method to load the data into the DRam. I measure the time between the moment that I start loading the value into the DRam and the end of my program and I subtract the time that sequence need (by observing it at the oscilloscope). I know that it's not really accurate measurement but I was already to munch from what I was expected. Thanks by advance Regards Vincent " Enjoy life no matter what ! " On Thursday, 23 June 2016 21:02:34 UTC+2, Charles Steinkuehler 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] <javascript:> > -- 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/10faaa5b-19b3-448c-8725-d93f37da1df9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
