[Top][All Lists]

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

Re: [avr-gcc-list] Re: [avr-libc-dev] RFD: more avr-libc API changes

From: Szikra István
Subject: Re: [avr-gcc-list] Re: [avr-libc-dev] RFD: more avr-libc API changes
Date: Fri, 9 Sep 2005 04:38:31 -0500
User-agent: Internet Messaging Program (IMP) 3.2.2

For the whole SIGNAL vs INTERRUPT flame:
I'm with 'deprecate booth', cause of ambiguous (and maybe a bit
stupid) naming.

SIGNAL is a normal interrupt, (I'd like INT for it, but integer is
already int, so) i really like the ISR name idea.
since INTERRUPT is an eXtended interrupt (with a sei) it could be
either IRSX or ISRIE (Interrupt Service Routine with Interrupts
Enabled) (SIGNAL could be also ISRID)

by the way i suggest to do something (maybe merging) interrupt.h and
signal.h (to isr.h or interrupt.h)
(what's the point writing isrs if you don't enable interrupts, and
backwards? for the first you include signal.h, for the second you
include interrupt.h, they go hand-in-hand)

> - Wojtek Kaniewski wrote:
> What about the SIG_ prefix? If we'll move to something else than 
> SIGNAL(), I think that it should be dropped or somehow hidden from
> users.

the SIG_* defines could be changed to ISR_*

Istvan Szikra


> - Joerg Wunsch wrote:
>> How about changing the name to "ISR," which would do the same
>> as the existing "SIGNAL"?
>> Then, SIGNAL and INTERRUPT can both be deprecated (avoiding future
>> confusion).
> It has been suggested before, but so far, nobody else seemed to
> care about that suggestion.
> I'm open for it.  I'd probably rather deprecate SIGNAL with a much
> lower priority than INTERRUPT, as there's no strong need to force
> change upon virtually every AVR-GCC program around, but I don't
> such a change.

> - Joerg Wunsch wrote:
> As Wojtek Kaniewski wrote:
>>How about...
>>   #define VECTOR(signame) \
>>   void SIG_ ## signame (void) __attribute__ ((interrupt)); \
>>   void SIG_ ## signame (void)
> I don't know.  I'm more inclined to use ISR(), but I'd rather like
> see other people's opinions on this.
> Obtw., of course, it's __attribute__((signal)). :-)

reply via email to

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