[Top][All Lists]

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

Re: [avr-libc-dev] Re: [bug #21410] Incorrect use of 16-biteepromaddress

From: Wouter van Gulik
Subject: Re: [avr-libc-dev] Re: [bug #21410] Incorrect use of 16-biteepromaddresses in devices with 8-Bit address registers
Date: Thu, 25 Oct 2007 09:00:53 +0200
User-agent: Thunderbird (Windows/20070728)

Eric Weddington schreef:
-----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 just thought maybe going halfway is easy, apparently not.

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

No problem for me.


reply via email to

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