> > *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?*
Again, I do not know the hardware that well. I have a pretty good rough idea of what the PRUs are capable of. From a high level. That's about it. It is completely possible that each core can block the other while accessing this shared memory. I do not know one way or another. All I am saying, is that from a software perspective, plus what little I do know about hardware of this type - this make no sense. As operations of this sort could introduce added complexity, and operational overhead. However, one thing to keep in mind. Simultaneous writes, are guaranteed corruption, especially if somehow another processor we reading between the two writes. Simultaneous read / write will not necessarily introduce corruption in data. For this, a couple things to keep in mind. If writes, and reads take the same amount of time. Reads are nearly guaranteed to be"safe" - Although perhaps redundant. It is also as I mention above fairly "trivial" to implement a read/write mechanism. Or give each PRU exclusive "rights" to the shared memory at any given point in time. On Sat, Aug 1, 2015 at 5:19 PM, William Hermans <[email protected]> wrote: > *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.
