Hey Carlos, So, let me say up front that I have zero hands on with the PRUs. But have experienced something similar recently with Linux shared memory using mmap. Which *may* not be as fast as the PRU's but was fast enough to produce output fast enough to "flood" out / crash firefox within seconds.
*Will PRU0 or PRU1 stall and wait for the other to complete the access?* > * Will PRU0 read the previous data?* > * Will PRU1 read corrupted data?* I would think that neither of these cases would be desirable. But in the case of the second and third question, both could be possible - e.g. undefined behavior. In the first question I'm not sure what you mean exactly, but I did again experience something similar with POSIX shared memory. To explain further. Two processes, one reading, one writing. The process doing the writing has more to do and hence is not as fast as the reading process. In this case, the reader literally locked out the writer, since it was able to access the file so fast. The end result was that the writer process was able to write to this memory once, after which is was completely locked out but the reader process. *PRU0 will send a interrupt to PRU1 every time it read the scratchpad. Also > I can let PRU1 interrupt PRU0 to signal that the new data are ready, but > doing so will waste at least two or three cycles. * Is ~ 15ns that important ? versus not knowing what may happen? Anyway, there are a few people here that know the PRUs very well. Perhaps if they answer your question it may render what I say here moot. But if you really need deterministic operation. "Waste" the 3 cycles per loop iteration. It will probably make your life much easier, and your data much more reliable :) On Sat, Aug 1, 2015 at 9:49 AM, Carlos Novaes <[email protected]> wrote: > Hello again, > > My application uses the two PRUs: > PRU0 will control four PWM and some digital outputs and has some tight > time constraints. In short, the less assembly instructions it runs on the > normal execution path, the better. > PRU1 on the other hand, will read some inputs and do the interface with > PRU0 and ARM. It implements a sort of ring buffer with the ARM side and > transfer new data to PRU0 via scratchpad. Aside from the number of tasks, > there a plenty of time to waste here. > PRU0 will send a interrupt to PRU1 every time it read the scratchpad. Also > I can let PRU1 interrupt PRU0 to signal that the new data are ready, but > doing so will waste at least two or three cycles. > > What I would like to know is, if there are a conflict on the scratchpad > communication. lets say PRU1 is writing some registers to the scratchpad > bank0 while, at the same time, PRU0 is loading the same registers from the > same scratchpad bank. > Does anyone know what happens in this case? > Will PRU0 or PRU1 stall and wait for the other to complete the access? > Will PRU0 read the previous data? > Will PRU1 read corrupted data? > > > > PS: Section 5.2.4.2 of the am335xPruReferenceGuide.pdf > <http://mythopoeic.org/BBB-PRU/am335xPruReferenceGuide.pdf> explains what > happens if the two prus are trying to write at the same time. This is not > my case as PRU0 will never write anything on the scratchpad. > > > -- > 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]. > 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]. For more options, visit https://groups.google.com/d/optout.
