RE: [avr-gcc-list] interrupts

[Larry Barello]

Interrupts on the AVR are simple.  When an "event" occurs, and a "mask" is
enabled, a "flag" is set.  If the global interrupt enable (I bit in SREG) is
set, then the processor will vector to the appropriate routine for the
"flag".

For the most part, the "flag" is reset upon taking the vector.  So the
"flag" is reset upon entry into your routine.  You can re-enable global
interrupts and continue processing that vector safely (assuming you have
enough cycles, etc).

With USART it is a little different since the "flag" indicates presence of
data or some condition that the programmer has to do something about to
clear.  I.e. read the buffer, write the buffer, etc.  {That is why you
cannot use INTERRUPT with USART since the interrupt source is constantly
re-interrupting as soon as you take the vector and before you get a chance
to read the byte: you blow the stack and the CPU resets.}

If two or more of the same "event" occur prior to taking the vector, then,
of course, information is lost.  Similar to the USART case: if too many
bytes are received before clearing the "event" you lose data.  The most
common case is a timer tick being lost because the tick handler takes too
long.  If you are clever you can re-enable interrupts and "re-enter" the
timer, but this has to be done in a way that eventually unwinds or again you
blow the stack and reset.

If the "mask" is not set, then the "event" will not set the "flag" and even
if you re-enable the mask, there will be no interrupt.  Some "events" are
level sensitive: INTx and the aforementioned USART case come to mind.  NB
INTx interrupts can also be edge sensitive.  I think the ICP and ACI can
also be level or edge sensitive.

Priority of interrupts (i.e. which one is serviced if two or more are
pending) is based upon the vector table.  Low vectors have higher priority.

In general, if a "flag" is set, but you don't want to take the vector, you
write a 1 to the flag to clear it.  I have never used this except to make
sure the flag was reset before enabling a driver - and that was only because
I was struggling to figure out some other problem.

Cheers!

-----Original Message-----
From: Oliver Kasten

here is my two pennies worth. (i'm pretty pretty sure the following is
right, but wouldn't mind if someone could confirm or disprove.)

...