Re: [avr-libc-dev] New device support: AT90CAN128

[Joerg Wunsch]

As Colin O'Flynn wrote:

> Was there a problem with the Mega169 EEPROM using the eeprom.h
> functions? For some reason I thought there was at one point - as I
> think if the Mega169 EEPROM doesn't work than this guys might not
> also.

The problem is not so much avr/eeprom.h itself but the precompiled
binary libraries that implements part of the EEPROM access library.

Right now, we build four different binary versions of each library,
one for each of the AVR ``archs'' supported (avr2 through avr5).
(The only object file that is built per MCU is the gcrt1.o file.)

Since in order to build the libraries, some of the IO register values
are required to know independent of the actual CPU (<avr/io.h>
normally only works if -mmcu= has been provided on the command-line),
and these values have been moved out of the individual processor's
io.h file into a common header file.  The stack pointer registers come
to mind (they are needed inside malloc() in order to protect against
stack-heap collisions), and the EEPROM registers are required for the
EEPROM library.

Thus, any MCU that has the EEPROM registers in a different place
cannot be handled. :-(

This needs to be mentioned in the documentation at least.

I wonder whether the current way of building per `architecture' is
still that optimal, or whether we should start a finer-grained build
scenario (which unfortunately would require changes to the linker).

Btw., since I recently committed the fix for bug #8119 to <avr/wdt.h>
(which affects the ATmega169, for similar reasons to those with the
EEPROM handling), please do verify whether you need to extend that to
the CAN128 as well.
-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/