Hi Willian, Thank you for your insights. I am thinking how to write a test code to determine exactly what happens, but it is not as trivial to me.
The point with POSIX shared memory is, on my understanding, valid until some extent. It takes one cycle for the PRU to read from or write to the scratch pad register. That is just one cycle to back up the entire (or partial) contents of the registers and another cycle to get them back (on the same or on the other PRU). To clarify, my first guess is that PRU0 wil be blocked until PRU1 complete the writing, so it wil read in two cycles. The effect on the pwm outputs will be a 5ns jitter. The 15ns are important as long as my third guess is proved to be impossible. This conflict is unlikely to happen and so I can live with either a 5ns jitter or a repeated sample. But I can not allow for a corrupted reading that may even interpret a signal to shutdown my pwm module. Well, I am just trying to push the PRU to its limits and got four pwm (10 bits) and three output pins driven at 19531 samples per second with no software induced jitter (every execution path takes exactly the same time, so any jitter is hardware related). By including the interrupt control the sample rate will drop to 15024 samples per second or a little less. Of course this is all in vain if I cannot get the ARM running at 1GHz to process the inputs and generate a control action at this rate even with a high priority task. Le samedi 1 août 2015 15:35:24 UTC-3, William Hermans a écrit : > > 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] > <javascript:>> 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] <javascript:>. >> 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.
