[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] RFC: deprecate INTERRUPT, and replace it by something

From: Joerg Wunsch
Subject: Re: [avr-libc-dev] RFC: deprecate INTERRUPT, and replace it by something less ambiguous
Date: Thu, 10 Feb 2005 14:45:09 +0100
User-agent: Mutt/

As E. Weddington wrote:

> Part of the issue, is that these names are derived from the GCC 
> *attributes* for these functions.

> void signame (void) __attribute__ ((signal));        \
> void signame (void) __attribute__ ((interrupt));    \

> So, should this be changed in GCC too?

I don't think too many users actually look at this, so I'd personally
not touch it.  If we touch that, we need to make sure for which GCC
version we are compiling (autofoo dependencies).

> I would also ask, is it worth it to rename it? Why not do away with 
> __attribute__((interrupt)) all together?

I could think if rare situations where you really might want to
re-enable interrupts as early as possible (in order to not defer other
interrupts while your current interrupt is unimportant regarding its
latency).  E.g. if you've got a timer overflow or compare interrupt
that triggers only once per second, but have also some important data
acquisition interrupt that needs to be handled immediately, you can be
sure that you won't cause a stack overflow.  It's probably rare but if
you need it, it can be really handy.

I hesitate to rename SIGNAL into INTERRUPT quickly again though, in
order to at least ensure for a while that any old program that used
INTERRUPT on purpose will fail to compile.

> With this RFC, I would like to also propose combining <avr/signal.h>
> and <avr/interrupt.h>. Everything to do with interrupts, declaring
> them, turning them on or off, under one header, with it being
> perhaps <avr/interrupt.h>.

I agree.

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]