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

[Shaun Jackman]

Hello Eric,

I agree: correct code first, optimization second. I am not complaining
that eeprom_write_dword is an 80 byte function. I agree that
reading/writing a 32-bit word will take a bunch of code on an AVR. I
am arguing that it is a design flaw that eeprom_write_dword takes 80
bytes *per call*. It may be a documented, reasoned design flaw, but it
is a inarguable design flaw nonetheless.

Cheers,
Shaun

On Thu, Feb 28, 2008 at 6:53 AM, Weddington, Eric
<address@hidden> wrote:
>  Hi Shaun,
>
>  Thanks for your response!
>
>  Your last sentence is really the crux of the matter. If regular
>  functions are provided then we're back to where we started and it
>  doesn't resolve the avr-libc bugs (non-working routines on certain
>  devices). If the functions are provided in the header file, and they are
>  non-inline, then there is a strong potential for duplicate function
>  names at the link stage. Without going to "lib-per-device" design, the
>  only solution available has to be in a header file, whether inline
>  assembly, or inline C functions.
>
>  The AVR is not terribly efficient at moving around 32-bit integers, or
>  greater, so I would expect that a read/write dword would be large to a
>  certain degree.
>
>  Again, it comes down to having correct code first, and then optimized
>  code (for size) later.
>
>  Eric