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. ;-) _______________________________________________ AVR-libc-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
