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

[E. Weddington]

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
> #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?
>
>
>  
- 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?

Eric