On 9/8/2016 12:41 PM, William Hermans wrote: > > > On Thu, Sep 8, 2016 at 6:36 AM, Charles Steinkuehler > <char...@steinkuehler.net > <mailto:char...@steinkuehler.net>> wrote: > > On 9/7/2016 7:50 PM, William Hermans wrote: > > > > SETDATAOUT -> |= BITx > > CLEARDATAOUT -> &=(~BITx) > > > > I gues I'll have to reread the TRM again. > > The set/clear registers only affect the bits that are written with a > '1' value, all other bits remain unchanged, while writing directly to > the DATAOUT register affects the value of all 32 bits in the GPIO > bank. Using the set/clear registers allows a single atomic write > operation to affect the specific bit(s) you want to change without > having to perform a non-atomic read-modify-write cycle. > > Since the write to the set or clear register is atomic, if both the > ARM and the PRU both use this method, no locks or other hand-shaking > is required to prevent corruption. > > -- > Charles Steinkuehler > char...@steinkuehler.net <mailto:char...@steinkuehler.net> > > > It has long been programing technique to use DATAOUT |= BITx to set a > register > bit DATAOUT &= (~BITx) to clear a register bit, or something like if(DATAOUT > & > BITx){} or if((DATAOUT &BITx) == 0 or 1) to read a bit from a register.
Yes, it has. But those short-hand snippits of C code are hiding an implicit read-modify-write cycle: DATAOUT |= BITx ...turns into: Read : <temp> = DATAOUT Modify: <temp> = <temp> | BITx Write : DATAOUT = <temp> ...where <temp> is probably a CPU register (unless your C compiler is _really_ bad!). But if you use the set/clear registers it's just: Write : SETDATAOUT = BITx If you have multi-threaded code (or interrupts or the PRU) that can modify GPIO output states, you have to protect the read-modify-write cycle with some sort of lock. With the set/clear registers, no lock is necessary for reliable operation. > So I'm having a very hard time taking what you're saying without a grain of > salt. Especially after having read that section of the TRM in detail, and not > getting what you got from it. But I do feel that if you read a gpio register > bit > first, before writing to it there should be no contention as to what the > register should be. In a multi-threaded system, the time between the read and the write in the read-modify-write cycle is when corruption can happen. If another process writes to the GPIO after the read, but before the write, that update can get lost (this was covered in a previous email with specific examples). Take with as much salt as required for it to make sense, but controlling access to shared resources (like a GPIO bank, or a shared variable) is a very basic part of multi-threaded programming...but it's still _really_ easy to get wrong! -- 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/8e97f79a-7c13-9c0b-b5e4-5e0bf26c0799%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
