On Jun 11, 2012, at 4:18 AM, Isaac Marino Bavaresco wrote:

> Exactly, *atomic* operations don't need to be protected. Unfortunately,
> most operations are not atomic, even on single bits or bytes.

The operation doesn't need to be any more atomic than the high-level functi=
on(s) being performed.   In this case, the main loop code continually reads=
 (only) the variable set in the ISR, so the worst that would happen is that=
 IF the code is interrupted at a particularly bad place (ie when the "int" =
is half-read), and IF the ISR changes the variable in a way that will resul=
t in an incorrect final value after the other half is read, then there will=
 be ONE occurrence of an incorrect off time.

This is probably inconsequential.  The code doesn't need to be a critical s=
ection not because it's properly atomic, but because IT ISN'T CRITICAL (in =
the high-level meaning of the word.)

YMMV, and it's something to be aware of, but=85
(note that "delay(0)" is sometimes equivalent to "delay(65536)", so acciden=
tally reading 0 due to atomicity issues might in fact be VERY noticeable.)

BillW


--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.