RE: [avr-libc-dev] [RFC] New eeprom.h

[Weddington, Eric]

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of Joerg Wunsch
> Sent: Tuesday, January 29, 2008 2:17 PM
> To: address@hidden
> Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
> 
> As Weddington, Eric wrote:
> 
> > > And the old code is not disabling interrupts during eeprom
> > > write... which is no good! Maybe this was the problem of the
> > > report for the tiny13?
> 
> > No, the old code is disabling the interrupts for the write
> > routines. You have to look in the libc/misc/eeprom.S file in the
> > avr-libc source.
> 
> Sure, I'm now almost convinced that we have to move to a per-device
> library model some day.  This will really become a major step though
> (affecting the entire toolchain, binutils, compiler, and library), but
> will resolve many of these things:
> 
<snip> 

> I don't see much point in picking only one of these, and trying to
> craft a reimplementation for it (just because it /could/ be resolved
> by entirely reimplementing it within a header file) when all these
> things eventually have to be resolved anyway.

Joerg, we've gone over this before.

- Yes, we need to move per-device libs *someday*.
- This requires a lot of time and work.
- I need to fix a GCC bug, support *all* AVR device variants with the
EEPROM API, *and support future AVR devices that will be coming out
within a month*.
- No one has yet to volunteer to change all of avr-libc to per-device
libs
- You are working on avr-libc on a volunteer basis; I doubt you have the
time to work on per-device libs and get them working within 2 weeks.
- Therefore, I've chosen the path of least resistance and I'm modifying
<avr/eeprom.h>
- We have precedence in having inline macros that are tailored per
device: pgmspace.h, sleep.h, wdt.h. This just adds another one.

I know that the changes causes the code size to increase. The code *has
to work correctly* before there can be any focus on optimization. At
this point, the EEPROM API implementation causes a GCC bug (internal
compiler error) and IIRC doesn't even work for 2 AVR devices. This is
bad. To add to this, I need the EEPROM API to work for these future
devices that are coming out in a month. You have the datasheets to these
devices, which includes how the EEPROM operates in those devices.

This is the whole reasoning for this change. Since I don't expect anyone
else to volunteer to help, I took it upon myself to make the necessary
changes. Those changes have some problems. I submitted those changes for
feedback from the list.

Eric Weddington