[Top][All Lists]

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

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

From: E. Weddington
Subject: Re: [avr-libc-dev] RFD: more avr-libc API changes
Date: Wed, 07 Sep 2005 23:27:21 -0600
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

Joerg Wunsch wrote:

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...

I don't have a good answer either. :-/

. 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

 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?

- We should define the <compat/*> include directory as for "compatability" includes only. I would take this as meaning "compatability with other compilers" (i.e. IAR, etc.), and "backwards compatability" (i.e. deprecated items that are semi-removed). - We should define the <avr/*> include directory as for includes that are specific to the AVR hardware. For example <avr/boot.h> and <avr/sleep.h> - As a consequence, a "universal UART" header would go into the <avr/*> tree because it is still specific to the AVR hardware. IMHO, it would be <avr/uart.h> (or perhaps <avr/usart.h>). If one sees how <avr/sleep.h> has become a "universal SLEEP" header, then you can see how the "universal UART" header fits in here. - I think it would be best to go ahead and deprecate timer_enable_int() and enable_external_int(). I agree that the naming wasn't very well thought out, perhaps. - I have a possible replacement for the "external interrupt" header. This would provide macros to handle enabling/disabling interrupts, changing the interrupt triggers, etc. It does provide a bit of a HAL for that subsystem. Currently it's geared towards a mega128, so it would need some work to make it applicable across all micros. Again, this is specific to the AVR hardware, and I would suggest naming the header <avr/extint.h>. - Going along with the theme, it would be good to eventually have an <avr/timer.h> header that deals with timers. Again, I have some possible candidates as a starting point. - I think your idea of <avr/deprecated.h> is a great idea! We could put all of those outdated macros in it: sbi(), cbi(), outp(), inp(), etc. ad naseum. :-) - Our previous offline discussion of having a <util/*> tree would be good for "utility headers", i.e. headers that are nice, but not necessary, and that is not related to the AVR hardware. The first entry in this would be <util/bit.h> for bit manipulation macros that we have discussed.

So, can we agree on a policy?


reply via email to

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