RE: [avr-libc-dev] Re: [bug #21410] Incorrect use of 16-biteepromaddresses in devices with 8-Bit address registers

[Eric Weddington]

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

I would much rather have the pain of slightly increased code size and inline
eeprom routines to be able to properly support all devices, then doing
nothing and letting bit-rot set in. Any objections that would veto such a
move?

Eric Weddington