[avr-libc-dev] compatibility headers

[Joerg Wunsch]

As E. Weddington wrote:

> Also concerning compatibility: what about things in avrlibc that are 
> in strictly for "compability with other compilers" (mostly IAR). 
> Right now its spread out in pgmspace.h, eeprom.h, ina90.h. Keep them 
> there or some other system to help people migrate?

Hmm, i don't know enough about those compilers.  Shipping them in a
separate header file (<avr/compat-iar.h> ?) has the advantage that
it's clear which of the interfaces is the one we'd recommend to our
users.

> Well it brings up the question, does avrlibc want to get into 
> providing APIs for AVR hardware subsystems (such as UARTs, timers, 
> etc.)? Not that I'm necessarily advocating it. But if not, it seems 
> odd to provide /include/avr/timer.h, ./twi.h, even for that matter 
> ./eeprom.h as somebody could roll their own. parity.h seems more like 
> a candidate for /libc/misc as its own assembler file than as a macro.

eeprom.h looks OK to me since it contains functions for something
basically everybody needs, for a subsystem that's present in every
AVR device.  The implementation is reasonably complete to be useful,
the only missing pieces are block write operations (but that could
be added).  Sure, if someone's really in the need for an interrupt-
controlled EEPROM subsystem, he's got to roll his own anyway.

timer.h looks fairly pointless to me.  It's more something that
should be shipped under `examples'.  It contains stuff for only one
timer channel, and it's fairly incomplete given the variety of things
you can do with the timer channels.

twi.h contains just byte definitions for some registers, basically
things extracted from the device's datasheet.  Thus it's more in the
same boat as the <avr/ioXXX.h> files than providing a subsystem for
I²C users.

I've got a one-shot timer implementation available that i could
contribute which would perhaps be a more appropriate candidate for
<avr/timer.h>. ;-)  Of course, it can be argued that one-shot
timers are rather a matter of the operating system, OTOH i think
they are frequently enough needed even in cases when there's no
operating system at all.  (That's been the reason why i wrote it.)
They are rather hardware-independent in that this library relies on
being called regularly by a hardware timer ISR.  It ``only'' does
the low-level work of maintaining a chain of timer requests, walking
that chain at interrupt time, and calling the registered callback
functions once a timer expires.  The chains are all maintained in
dynamic memory, so no hard limits apply.

If someone's interested to review this, i can publish the source.

-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/