[avr-libc-dev] Re: Interrupt and signal on UART

[Joerg Wunsch]

As gianni rossi wrote:

> I found a problem when I tried to handle INTERRUPT 
> on UART:
> If "SIGNAL" is used to define the handler function
> it works, is I use "INTERRUPT" the function halts.

Sure.  It will recurse to dead if you re-enable interrupts before
you've read/written UDC, and thus cleared the pending interrupt.

> I think I need "INTERRUPT" because in real application
> multiple events can happen at the same time.

No.  First rule of thumb, if you're not sure what you need, you need
SIGNAL().  Second, if you think you need INTERRUPT(), think again.
Finally, only if you are *absolutely certain* you understood all of
its implications, you might use INTERRUPT().

As has already been discussed here, the INTERRUPT macro will
eventually be dropped in a future release, as it has proven to be too
confusing and (see your case) even dangerous to the innocent
developer.  (Note that the functionality of INTERRUPT will not be
removed, but you've got to use an explicit __attribute__((interrupt))
declaration then.)

Strip your ISR down to what is absolutely necessary to be done at
interrupt-time.  That way, interrupt concurrency won't become a
problem.  If you really need to re-enable interrupts within your ISR,
you need to make *pretty* sure you've cleared the pending interrupt
you're currently working on before.  Depending of the kind of
interrupt you're handling, there are many different ways to do that
(and sometimes, as for level-triggered external interrupts, it cannot
be done at all).  Refer to the datasheet for details.

Btw., that question would have been more appropriate for the
avr-gcc-list.  If you're a beginner with AVR-GCC, it's recommendable
you subscribe there:

http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)