-----Original Message-----
From: Wouter van Gulik [mailto:address@hidden
Sent: Wednesday, October 24, 2007 1:14 PM
To: Eric Weddington
Cc: 'Joerg Wunsch'; address@hidden
Subject: Re: [avr-libc-dev] Re: [bug #21410] Incorrect use of
16-biteepromaddresses in devices with 8-Bit address registers
Maybe we must make a separation between peripheral drivers and the
library functions.
There are basically two area's why per device is desirable: different
instruction set's (movw&mul)
And different peripherals requiring different approaches. (I regard
eeprom as a peripheral here)
The trouble off the different instruction sets is tackled by the
architectures.
However trying to bundle the peripherals is now breaking avr-libc. At
the moment I can only see eeprom as a supported peripheral over all
devices. Maybe fuse read support would be peripheral support.
I am not
pleading to implement all peripherals, just a valid reason not to
implement a true per device lib. But merely a
per-device-lib-for-the-peripherals.
Since the peripheral differ most it seems legal to split it this way.
Hi Wouter,
All the talk is a bit academic. Unless someone is willing to come forward
and reorganize avr-libc, add in the changes necessary per device, get it
working with a version of GCC, get it all committed and come up with a
migration plan for the distribution owners, then it's not going to get done.
Any change in avr-libc to compile something per-device, that is not a part
of the startup code, is going to be a significant change. That's one reason
why none of the avr-libc developers have done it yet. We've been talking
about compiling per-device since at least 2004. None of us has the time or
energy to go through with it.