The way you put it made complete sense. Probably I will do it with some interruption handling, better safe than sorry. But being a hardware guy, this raises a philosophical question: Why handle the case when two simultaneous writes are performed and don't even care in this other case? Maybe because there are interruptions to handle this? Well, then why not just use this same interrupts to also block the simultaneous writes?
Le samedi 1 août 2015 17:59:16 UTC-3, William Hermans a écrit : > > *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] > <javascript:>> 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] <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.
