Great! Thanks for the explanation.
As you might imagine, the pru is incrementing at a very well controlled frequency. The host program on the other hand I have very little control of timing (hence the need for the pru!) So from the host side, I'm just zeroing the memory address inside a "while" loop that runs a bunch of other stuff as well (mainly fprintfs and printfs.) Since I have no control of how long these operations take, I just figure that they happen when they happen, and I figure that it is really unlikely that I will see 2 zero writes from the host get clobbered in a row. At the moment I have my watch dog time set to 25, so I think this wont be a problem. BUT... you say that the read-modfiy-write sequence will not be atomic? This is the part of the setup that is run by the PRU. If this is not atomic, am I correct in understanding that my PRU program loop will no longer run on a predictable frequency? I suppose I can tolerate timing chaos of 20-30ns, but not much more than that... and I would prefer to have my PRU loop running very regularly! Have I understood you correctly? Thank you, Bill On Sun, Jan 18, 2015 at 7:04 AM, <[email protected]> wrote: > > > On Friday, January 16, 2015 at 1:58:33 PM UTC-5, Bill Gray wrote: > >> >> The idea is that the host program is constantly setting an address in >> shared memory to 0 in a loop. The PRU is also constantly incrementing that >> same address. If the host loop stops, the value at the address climbs >> above a maximum and the PRU knows that the host program has gone away. >> >> As I think this scheme through, I realize that there is a large >> likelihood that the host program and the PRU will try to operate on this >> shared memory address at the same time! >> >> So far my program has not appeared to suffer any ill effects, but I guess >> I'm just interested in how this is handled by the am335x and if I ought to >> aware of possible gotchas! >> >> The memory writes should be atomic but the read modify write will not be. > This will cause you to loose some sets to zero when the PRU reads the > memory location, ARM sets it to zero then the PRU writes back the > incremented value. It would be good to have the increment rate and clear > rate such that if they conflict once that they won't both happen at the > same time at the next set to zero. > > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to a topic in the > Google Groups "BeagleBoard" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/beagleboard/zEyRq27D9to/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Bill Gray Velkess 415 407 7356 -- 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.
