[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[avr-libc-dev] RFD: more avr-libc API changes
From: |
Joerg Wunsch |
Subject: |
[avr-libc-dev] RFD: more avr-libc API changes |
Date: |
Wed, 7 Sep 2005 22:04:44 +0200 |
User-agent: |
Mutt/1.4.2.1i |
As the impending switch to avr-libc 1.4 allows us to make API changes,
I'd like to get people's opinions on the following:
. 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...
. Are there any users around who really make use of timer_enable_int()
and enable_external_int() (mind the inconsitent naming)? These are
simple assignments to the respective interrupt mask registers, and
there's no way to query the current settings, or just set or clear a
single bit in these masks. The only point for enable_external_int()
is that it provides some basic abstraction about the register name
where external interrupts are being maintained in. However, I
rather think that kind of abstraction would belong into a
long-threatened ``least common denominator'' IO resource header
file, say <compat/io.h>. There are further candidates like UART
register naming and such to go there. As nobody will ever be able
to craft that single, complete, universal, and great file, I'd take
this as an occasion and just start the file by moving
#if defined(EIMSK)
# define __EICR EIMSK
#elif defined(GIMSK)
# define __EICR GIMSK
#elif defined(GICR)
# define __EICR GICR
#endif
out there (probably replace __EICR by something better).
If so, what to do with timer_enable_int() and enable_external_int(),
should I start a <compat/deprecated.h> for these?
--
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] RFD: more avr-libc API changes,
Joerg Wunsch <=
- Re: [avr-libc-dev] RFD: more avr-libc API changes, E. Weddington, 2005/09/08
- Re: [avr-libc-dev] RFD: more avr-libc API changes, Wojtek Kaniewski, 2005/09/08
- Re: [avr-libc-dev] RFD: more avr-libc API changes, E. Weddington, 2005/09/08
- Re: [avr-libc-dev] RFD: more avr-libc API changes, Joerg Wunsch, 2005/09/08
- Re: [avr-libc-dev] RFD: more avr-libc API changes, Wojtek Kaniewski, 2005/09/08
- Re: [avr-libc-dev] RFD: more avr-libc API changes, Joerg Wunsch, 2005/09/08
- 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