[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-bit eepromaddres

From: Wouter van Gulik
Subject: Re: [avr-libc-dev] Re: [bug #21410] Incorrect use of 16-bit eepromaddresses in devices with 8-Bit address registers
Date: Wed, 24 Oct 2007 21:13:40 +0200
User-agent: Thunderbird (X11/20070824)

Eric Weddington wrote:
-----Original Message-----
From: address@hidden [mailto:address@hidden
org] On Behalf Of Joerg Wunsch
Sent: Wednesday, October 24, 2007 6:28 AM
To: address@hidden
Subject: [avr-libc-dev] Re: [bug #21410] Incorrect use of 16-bit eepromaddresses in devices with 8-Bit address registers

As Wouter van Gulik wrote:

What is the main reason not to build a per-device lib, apart from
the time to do such a thing? I quickly scanned the mailing archives
but I could only find the build time as a reason. Is this still
Basically yes.  With the current number of AVRs we are supporting (and
Eric adding  another dozen or  so right now),  the build time  for the
entire  avr-libc project  could easily  reach something  like  half an
hour, which is way too long.

I think that argument is bogus. It is only the toolchain distro maintainers
and the avr-libc developers that have to eat up that time. I think that is
reasonable considering the value of the feature. Besides, we need to get you
a faster machine, Joerg. ;-)

IMHO, the biggest issue is the amount of developer time needed to make the
change, the resulting testing, and the other reason you mention below:
If we were to change the model to a per-device library one, we'd also
have to think of a good transition scheme, because this library model
scheme is hand-wired into the GCC (compiler driver) code.  So it's not
only we need a new avr-libc but also a new GCC.  One possible option
for that is to start with avr-libc building per-device *and*
per-architecture libraries for quite some time, and only then start
modifying GCC.

And *that* is the biggest reason why it hasn't been done yet. Coordinating
the two projects.
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.

Just my 2 cents.


reply via email to

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