Re: [avr-libc-dev] Change EEPROM SFR definition.

[Joerg Wunsch]

As Anatoly Sokolov wrote:

> In new ATMega devices EEPROM support registers are located to other
> addresses than in AT90S/old ATMega/ ATTiny, it does illogical and
> error prone the generalized definition of these registers in IO.h.

These registers have once already been defined in each individual
io*.h file.  The only idea behind centralizing the EE* registers was
that you don't need a -mmcu option to compile them as long as
__COMPILING_AVR_LIBC__ is also set (from the command-line).

> I suggest to change the order of definition EEPROM registers as
> follows:

> 1.To define EEPROM SFR and corresponding bits in device ioXXXXX.h files.

> 2. In io.h for support EEPROM library define EEPROM SFR only if any
> of __ AVR_device __ is not defined and defined __ COMPILING_AVR_LIBC
> __.

I don't see much point in changing it right now.  It's quite clear
that we need per-MCU-type libraries in order to provide useful EEPROM
libraries.  While it would be relatively easy to change the model from
per-`architecture' (avr2...avr5) to per-device right now, it will cost
a lot of compilation time, with 99 % of the resulting binaries having
identical code anyway.  So past discussions yielded that a different
scheme appears to be ideal where all the device-independent parts are
compiled the way they are now (into one libc.a per architecture), and
the device-dependent files (like the EEPROM library) go into a
separate lib${mcutype}.a file.

While doing that, the separation of libm.a should be dropped as well,
as it serves no useful purpose, and the current libm.a also has stuff
that doesn't even belong there as it is required for general
floating-point math.  We could still ship an empty libm.a for
compatibility for a while, so the people's habit to always use -lm
would not cause an error.

The only drawback of that scheme is:

. the build system will become more complicated

. GCC itself needs to be touched; we somehow need an option that makes
  the transition failsafe so people using a new avr-libc with an old
  compiler would not run into trouble

#1 above is relatively easy, and ``only'' needs to be implemented.

#2 is more complicated.  We could perhaps ignore the issue completely,
and just tell anyone they have to manually add a -l${mcutype} option
to their linker command line when they want the EEPROM routines.  I
don't particularly like that, but it's an option.

We could try to stuff one `generic' set of EEPROM functions into
libc.a so a backwards-compatible library will result out of it, and
only users of the newer compiler (that automatically adds -l${mcutype}
before -lc) will get the new behaviour.  It will cause more build
system complications, but I like that somewhat better than the
previous option.

Any other ideas?


My proposal: once we settled for a per-device build system, we
completely drop the current centralized EE* registers from avr/io.h,
and decentralize them back into each individual device's avr/io*.h
file.  (IIRC, __COMPILING_AVR_LIBC__ is still needed as the malloc
routines want to have the stack pointer definitions so they need to
#include <avr/io.h> without getting a complaint.)

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)