[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
- Re: [avr-libc-dev] RFD: more avr-libc API changes, (continued)
- Re: [avr-libc-dev] RFD: more avr-libc API changes, Wojtek Kaniewski, 2005/09/08
- Re: [avr-gcc-list] Re: [avr-libc-dev] RFD: more avr-libc API changes, Szikra Istvan, 2005/09/09
- Re: [avr-gcc-list] Re: [avr-libc-dev] RFD: more avr-libc API changes, Branislav Katreniak, 2005/09/09
- Re: [avr-gcc-list] Re: [avr-libc-dev] RFD: more avr-libc API changes, Joerg Wunsch, 2005/09/09
- Re: [avr-gcc-list] Re: [avr-libc-dev] RFD: more avr-libc API changes, E. Weddington, 2005/09/09
- Re: [avr-libc-dev] RFD: more avr-libc API changes, Rolf Ebert, 2005/09/10
- RE: [avr-libc-dev] RFD: more avr-libc API changes, Darcy Watkins, 2005/09/12
- RE: [avr-libc-dev] RFD: more avr-libc API changes, Darcy Watkins, 2005/09/09
- Re: [avr-libc-dev] RFD: more avr-libc API changes, Wojtek Kaniewski, 2005/09/08
Re: [avr-gcc-list] Re: [avr-libc-dev] RFD: more avr-libc API changes, Matthew MacClary, 2005/09/08
- Re: [avr-gcc-list] Re: [avr-libc-dev] RFD: more avr-libc API changes,
Björn Haase <=
- Re: [avr-gcc-list] Re: [avr-libc-dev] RFD: more avr-libc API changes, Joerg Wunsch, 2005/09/08
- Re: [avr-gcc-list] Re: [avr-libc-dev] RFD: more avr-libc API changes, Zane D. Purvis, 2005/09/08
- Re: [avr-gcc-list] Re: [avr-libc-dev] RFD: more avr-libc API changes, Joerg Wunsch, 2005/09/08
- Re: [avr-gcc-list] Re: [avr-libc-dev] RFD: more avr-libc API changes, Wojtek Kaniewski, 2005/09/08
- Re: [avr-gcc-list] Re: [avr-libc-dev] RFD: more avr-libc API changes, Joerg Wunsch, 2005/09/08
- Re: [avr-gcc-list] Re: [avr-libc-dev] RFD: more avr-libc API changes, Wojtek Kaniewski, 2005/09/08
- Re: [avr-gcc-list] Re: [avr-libc-dev] RFD: more avr-libc API changes, Joerg Wunsch, 2005/09/09
- Re: [avr-gcc-list] Re: [avr-libc-dev] RFD: more avr-libc API changes, Dave Hansen, 2005/09/09
- Re: [avr-gcc-list] Re: [avr-libc-dev] RFD: more avr-libc API changes, Dmitry K., 2005/09/10
Re: [avr-gcc-list] Re: [avr-libc-dev] RFD: more avr-libc API changes, E. Weddington, 2005/09/09