> > *However this "overhead" is somewhat mitigated by the fact that it is only > on the PRU that is waiting for access. Write should only be one cycle, a > compare, I'm less sure about.*
I was not very clear here. This kind of implementation should be somewhat mitigated because half the process is done on each PRU. So if a write is 1 cycle and a compare is 1 cycle. You're reducing the delay to 1 cycle per core. Instead of 3 cycles per core. On Sat, Aug 1, 2015 at 5:10 PM, William Hermans <[email protected]> wrote: > *However well (or not) it is handled in hardware, the problem is well* >> * known in operating systems, which have two (or more) effective* >> * simultaneous processes going on at the same time. Synchronization* >> * between processes becomes critical under certain circumstances. You* >> * may have that kind of problem.* >> >> * Consider what happens when you write a string of bytes/words rather* >> * than a single one. What happens if that's interrupted halfway* >> * through? In an operating system, it can happen.* >> >> * Harvey* >> > > > Yes, so for example it is possible to get half a good integer, and half a > corrupt integer. However that should not be a problem in bare metal as is / > may be the case of the PRU's. Since they operate completely independent of > the A8's OS. > > So Carlos, one option you may be able to use. Boolean "tag". First byte in > memory starts off with either a 0, or 1. This value then instruct the PRU's > which one has access "rights" to the shared memory. Then once the PRU that > has access right to the memory is done with it's operation. It writes the > value the other PRU is allowed to access. > > However, this introduces a compare, and an additional byte write. Which > may use up more than or at least as much overhead which you're trying to > avoid. However this "overhead" is somewhat mitigated by the fact that it is > only on the PRU that is waiting for access. Write should only be one cycle, > a compare, I'm less sure about. > > On Sat, Aug 1, 2015 at 3:48 PM, Harvey White <[email protected]> > wrote: > >> On Sat, 1 Aug 2015 14:17:45 -0700 (PDT), you wrote: >> >> >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? >> >> However well (or not) it is handled in hardware, the problem is well >> known in operating systems, which have two (or more) effective >> simultaneous processes going on at the same time. Synchronization >> between processes becomes critical under certain circumstances. You >> may have that kind of problem. >> >> Consider what happens when you write a string of bytes/words rather >> than a single one. What happens if that's interrupted halfway >> through? In an operating system, it can happen. >> >> Harvey >> >> >> > >> >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. >> > > -- 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.
