Jim Brain wrote: > > Which is why there is the <util/atomic.h> macros. Check out: > > > > ATOMIC_BLOCK( ATOMIC_RESTORESTATE ) > > Can someone clarify why these macros are preferred over doing > cli()/sei()/SREG=sreg in code? I'm not trying to troll, but > wonder if there is something I am missing.
Jim: I'm cc'ing this response to the list. If you have the question, perhaps someone else does, too. I'm sure someone else will be far better at answering this, but I'll take a stab. The quick answer to your questions is, "not much." From a functional point of view I think that the educated programmer can avoid (and *has* avoided!) the use of the ATOMIC_BLOCK. The key phrase in that previous sentence is "educated programmer". ATOMIC_BLOCK allows you to explicity declare a section of code as "atomic" rather than hinting at it by the use of the "cli(); ... sei();" sequence. More important, in my mind, is that the macros are written in such a way that the enclosed code is guaranteed not to be optimized out of the block. Finally, the simple "cli(); ... sei();" that newbies were using would enable interrupts even if they were not enabled on entering the sequence. With the ATOMIC_BLOCK( ATOMIC_RESTORESTATE ) call you're explicitly telling everyone that you want the state restored to whatever it was when you entered the block. I use it mostly for readability and documentation purposes. It nice to think that some other poor slob maintaining my code will be notified of the importance of the atomicity of the section I mark. Plus, with the separate commands it's easy to accidently remove one of the key statements without any whining from the compiler. ATOMIC_BLOCK prevents that kind of fumble-fingered mistake for which I am so famous. ;-) Hope this helps! Best regards, Stu Bell DataPlay (DPHI, Inc.) _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list