[avr-libc-dev] Avr-libc functions accessing EEPROM buggy on some controllers ?.

[Björn Haase]

   Hy,

   Today I h= ave tried in vain to use the library functions of avr-libc
   for reading = and writing the EEPROM of a atmega169 device.

   I think, I have found = the origin of the bug and I expect it to
   show up also for a number of o= ther controllers:

   The EEPROM register (e.g. the EEPROM control regis= ter "EECR")
   location within
   io memory space varies between the differen= t family members. This
   means, that
   the address of the registers that sh= ould be used by the library
   functions is
   known at link time only.
   <= P>Within the source code of the library (./libc/misc/eeprom.S") the
   regist= ers,
   however,  are accessed by the adress that is obtained by macr= o
   expansions of the type
   _SFR_IO_ADDR (EECR). I.e. the address of the r= egister is hard
   coded at compile time!

   The result is that my library= function tried to access the EECR at
   address 0x1C (0x3C)
   while it is i= n fact located at 0x1F (0x3F).

   I now have the following question= s:

   1.)
   Should my observation really be considered as a bug or di= d I simply
   do a configuration
   mistake. I don't in fact know whether av= r-libc is supposed to be
   recompiled by the
   user and needs to be given t= he target system. (This might explain
   why the
   crt-files for the atmega = series are not generated automatically by
   the avr-libc-1.0.2
   makefiles= . The AVR_CRT_MEGA variable is empty and, e.g. does not
   include the crt fi= le
   crtm169.o)

   2.)
   In case that it is really a bug, I would b= e grateful for an advice:
   Before starting
   coding I would appreciate the= opinion of the library gurus on which
   method corresponds
   best to the a= vr-libc philosophy.

   I think, the most clear solution of the problem = would be to
   generally
   access IO address space within the library routin= e only by symbols
   that are
   explicitly defined in the crt object file fo= r the respective target.
   I.e., define a ".set" symbol within "gcrt1.S"= for each register.

   Generally speaking, including <avr/io.h> s= hould be considered to be
   potentially harmful
   for all library functions= except the crt sources. I have observed,
   that
   seemingly a lot of libra= ry functions need knowledge of the IO memory
   space
   (e.g. : setjmp.o, s= trcat_P.o, strlen_P.o, strncat_P.o,
   memccpy.o, memchr.o,
   memmove.o, st= rcat.o, strchr.o, strlen.o, strlenwr.o, strlwr.o,
   strncat.o, strnlen.o)

   I suggest therefore to remove the line "#include <avr/io.h>" com   pletely 
from the
   /common/macros.inc file and patch the other sources s= uch that they
   compile also
   without <io.h>.

   I am willin= g to start implementing the bug fix right now. I however
   think it is more = useful
   to wait for a "go" signal from the library gurus.

   Yours,

    Björn
   _______________________   5F______________________=5
   F_______________________
   ____= ____
   Nachrichten, Musik und Spiele schnell und einfach per Quickstart i= m
   WEB.DE Screensaver - Gratis downloaden:
   [1]http://screensaver.web.de/?mc=021110

References

   1. 3D"http://screensaver.=/