> > *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. * >
And this is what could happen if one PRU is reading while another is writing. As far as blocking / non blocking. I honestly do not know. But is my instinct that if it is not explicitly mentioned as being a blocking call - It will be non blocking. On Sat, Aug 1, 2015 at 1:40 PM, Carlos Novaes <[email protected]> wrote: > 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]> 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. > -- 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.
