avr-libc-dev
[Top][All Lists]
Advanced

[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: Björn Haase
Subject: Re: [avr-gcc-list] Re: [avr-libc-dev] RFD: more avr-libc API changes
Date: Thu, 8 Sep 2005 20:07:37 +0200
User-agent: KMail/1.7.1

Matthew MacClary wrote on Donnerstag, 8. September 2005 18:26 :
> On Wed, Sep 07, 2005 at 11:27:21PM -0600, E. Weddington wrote:
> > Joerg Wunsch wrote:
> > >. I'd like to get <avr/signal.h> and <avr/interrupt.h> to eventually
> > > be merged.  As a next step, we could deprecate one of those, and
> > > issue a #warning if it gets included.  But which of the names to
> > > retain?  I tend to keep <avr/interrupt.h> as this sounds more
> > > logical, but then, interrupt handlers are usually introduced with
> > > SIGNAL() for us...
> >
> > I don't have a good answer either. :-/
>
>     My suggestion would be to change INTERRUPT to be the same as
> SIGNAL, and then deprecate SIGNAL. After this the <avr/interrupt.h>
> file could be used and all naming would be completely obvious.
I understand correctly that this one SIGNAL/INTERRUPT macro would leave the 
interrupts disabled.? In this case the user could add the "sei" instruction 
himself by a function call to a "enable_intterrupts ()" function provided by 
avr-libc, if he wants it.

IMO, this would be a clean and transparent solution. And it would avoid the 
most common mistake that shows up when using SIGNAL / INTERRUPT: The user 
then explicitly nows that interrupts are re-enabled. 
The only problem in comparison of the present state with the approach 
suggested above is, IMO, that the time period for which the IRQs are disabled 
gets longer: Irqs get switched on again only after the prologue sequence.

However, IMO, this is not a really serious objection. In case that one really 
needs extremely fast response times when using more than one IRQ handler, he 
could not possibly avoid to write the IRQ service routines himself in asm 
anyway.

Yours,

Bjoern
 




reply via email to

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