[avr-libc-dev] Re: The eeprom handling routines for the mega48

[Björn Haase]

Am Dienstag, 25. Januar 2005 23:41 schrieben Sie:
> Bjoern,  we are using the mega48 and found the problem with the libc.a
> being precompiled causes the library functions in eeprom.S to not function.
>
> I upgraded to the avr-libc-1.20 version which looked to me like they
> thought they fixed that problem, but the same problem still exists or I am
> doing something wrong.   We can use the jtagice-mk2 to step though and we
> see that the compiled libc.a code is still using the 0x1f address for EEARH
> instead of the 0x21 or whatever it is supposed to be.
>
> Has this issue been fixed in anyway yet, or do we just have to use our own
> access functions to the eeprom when using the mega48 (and presumably the
> mega88 and mega1680???
>
> Thanks in advance,
>    Brynn
>
> Brynn Rogers        address@hidden
>    http://www.visi.com/~brynn  to see my triplets!
The problem with the libc build machine presently is, that there is *one* 
library for all of the different avr target families (avr3,4,5). If the 
location of EEARH or any other register varies within one famly, the code is 
bound to fail on some of the targets. For the atmega169 this is a known bug 
that is documented. Maybe this is also the case for other controllers.
My personal recommendation for this issue is:
Do not use the library functions for the eeprom as long as the library build 
machine has been changed to the one device - one libc.a principle. 

I do not know, frankly speaking, whether this is already implemented in 
avr-libc 1.2.0 . ( I myself am still working with 1.0.2 .)

I'd like to suggest you to transfer the source files for eeprom access to your 
project and make shure that they are compiled with the appropriate -mmcu 
compile switch.

Yours,

Björn

P.S.: Please send questions to the mailing lists. Sending mails not via the 
list will make them end them end up in my spam filter waste box.