I guess I just tend to think, and do things a bit differently than some, or maybe even most.
1) If I could avoid having writes happen on both sides I would. Normally this isn't an issue, but if it is, see 2. 2) If writes *had* to happen on both sides. I would implement a locking mechanism. A single bit somewhere in the PRU's shared memory. I did this with an application I wrote that read data out of the CANBUS, and had to write the parsed data to a shared memory file. Where locking semaphores were far too slow. As I was writing around 1400 data parameters out over a websocket a second. Where the second half of the app( separate process ) had to be on the ball, and send that data out in real-time as it was available . . . Anyway, first half of the application would only write if this bit were set to 0 while the second half would only read while bit was set to 1. So in effect, a blocking write, then read, but it turned out to be very fast. Anyway, I think this is similar how I would approach what's being discussed here. On Thu, Sep 8, 2016 at 1:38 PM, Charles Steinkuehler < char...@steinkuehler.net> wrote: > On 9/8/2016 1:40 PM, William Hermans wrote: > > So here is my contention, but note that I'm emailing you directly. > Because it is > > not my intention necessarily to argue with you, and feel good or > righteous > > about. Especially since I have nearly no hands on with the PRU's or how > they > > behave in relation to usrspace, or even kernelspace Linux. > > > > 25.4.1.18 GPIO_DATAOUT Register (offset = 13Ch) [reset = 0h] > > Yes, the TRM correctly describes the behavior of the DATAOUT, > SETDATAOUT, and CLEARDATAOUT registers, but I don't think you > understand the potential contention issues in a multi-threaded system > which is what makes the set/clear registers very helpful. Believe me, > they wouldn't be in the hardware if they didn't have a very useful > purpose! :) > > I replied with more details to your post on the list. > > -- > Charles Steinkuehler > char...@steinkuehler.net > > -- 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORr2yE4C7yZ5kJO6ZQcPwHkZPMFZNSjq%3D6wt5pbgjgzxig%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
