[avr-libc-dev] Bug in EEPROM handling routines of avr-libc .?

[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.

   Within the source code of the library (./libc/misc/eeprom.S") the
   registe= rs,
   however,  are accessed by the adress that is obtained by macro   expansions 
of the type
   _SFR_IO_ADDR (EECR). I.e. the address of the re= gister is hard
   coded at compile time!

   I now have the following q= uestions:

   1.)
   Should my observation really be considered as a bu= g or did I simply
   do a configuration
   mistake. I don't in fact know whe= ther avr-libc is supposed to be
   recompiled by the
   user and needs to be = given the target system. (This might explain
   why the
   crt-files for the = atmega series are not generated automatically by
   the avr-libc-1.0.2
   ma= kefiles. The AVR_CRT_MEGA variable is empty and, e.g. does not
   include the= crt file
   crtm169.o)

   2.)
   In case that it is really a bug, I = would be grateful for an advice:
   Before starting
   coding I would appreci= ate the opinion of the library gurus on which
   method corresponds
   best t= o the avr-libc philosophy.

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

   Generally speaking, including <avr/io.= h> should be considered to be
   potentially harmful
   for all library fu= nctions except the crt sources. I have observed,
   that
   seemingly a lot o= f library functions need knowledge of the IO memory
   space
   (e.g. : setj= mp.o, strcat_P.o, strlen_P.o, strncat_P.o,
   memccpy.o, memchr.o,
   memmov= e.o, strcat.o, strchr.o, strlen.o, strlenwr.o, strlwr.o,
   strncat.o, strnle= n.o)

   I suggest therefore to remove the line "#include <avr/io.h&g= t;"
   completely from the
   /common/macros.inc file and patch the other so= urces such that they
   compile also
   without <io.h>.

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

   Y= ours,

    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.=/