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

[Shaun Jackman]

Hi all,

I like the rewrite. It looks good. My only concern is possibly code
size. I haven't tested it, but it looks as though
__eeprom_write_byte_address_word should generate about 10
instructions, which means __eeprom_write_dword_address_word will
generate 40 instructions, or 80 bytes. It seems to me that an 80 byte
function should not be inlined. I have been following the history of
this issue, and I know the reason these functions are inlined.
However, I'm not sure that the end result, namely an 80 byte inline
function, is valid.

It is possible for the application to provide it's own not inlined copy:
void eeprom_write_dword_not_inlined(uint16_t addr, uint32_t value)
{
        eeprom_write_dword(addr, value);
}
which is a reasonably straight forward workaround. It just seems a bit
clunky. Since I don't have any solutions or suggestions, I'm
definitely not objecting to the rewrite being checked in. The rewrite
fixes otherwise unresolvable issues.

Cheers,
Shaun

On Wed, Feb 27, 2008 at 5:54 PM, Weddington, Eric
<address@hidden> wrote:
> Hi Wouter and All,
>
>  I took your rewrite and had to fix a few things. I also added new 32-bit
>  integer read/write routines per Shaun's feature request (tracker on
>  avr-libc). Everything finally tested correctly.
>
>  I can finally say this now: Besides all of the other reasons I mentioned
>  for changing the EEPROM routines, one of the other reasons to change
>  these routines is becase of the new XMEGA chips that have been
>  announced. Because avr-libc does not yet have a design of library per
>  architecture, changing the EEPROM API implementation to be restricted to
>  just a header file (no compiled code in a library) allows us to modify
>  the implementation per device. This is necessary to fix the
>  implementation for a couple of other AVR devices (where they are
>  currently broken) and also to implement some of the new ways to access
>  the EEPROM in the ATxmega128A1 and ATxmega64A1.
>
>  The attached eeprom.h file is the first step in this.
>
>  Joerg, what is your opinion about adding this to the 1.6 branch? Or
>  would you rather it be restricted to HEAD? If it is restricted to HEAD,
>  then I lean towards cutting a 1.8.0 release sooner rather than later.
>
>  Any other thoughts? I would like to get this committed sometime soon.
>
>  Eric Weddington