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

[Weddington, Eric]

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of Dmitry K.
> Sent: Thursday, February 28, 2008 10:23 PM
> To: address@hidden
> Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
> 
> Hi all.
> 
> I like the rewrite. It looks good. My only concern is not
> only code size. There is a second question: this functions
> are not a normal C functions.  That is:
> 
> . No argument type control at compile time. For expamle,
> the expressions like
>     eeprom_write_block ("Apple", s, sizeof("Apple"));
>     eeprom_write_dword (3.14159, 0);
> do not type any warnings.
> 
> . It is impossible to get address of eeprom function
> to inderect call.
> 
> . Avr-gcc can not to optimize the EEPROM reading, like it
> can do this in case of SRAM.
> 
> 
> Summarizes the Eric's "eeprom.h" and all ideas from above
> (Wouter, Shaun, Rick) I have prepare two projects.
> 
> Project 1.
> It is a very simple: use an inderect calls (not indirect
> registers). It is eliminates big space expense and notes
> above: eeprom functions are pure functions. It is needed
> to add only 6 very short functions into Avr-libc. At this
> moment this project is ready for test. I can to commite
> at this week-end.
> 
> Project 2.
> Use a set of high quality asm functions. This is not only
> space effective, also it is fast. Now the set of funtions is
> ready for test. Some efforts are needed to include into
> Avr-libc: I am not happy to do this manualy.
> 
> In attach the "eeprom.h" of project 1.
> 
> Opinions?


- In eeprom.h, I had changed it to "inline static" because I received a
comment from a tester that 4.1.x gave warnings on "static inline". But
"inline static" was ok. So you may want to test your version with
previous versions of GCC (4.1.x) to avoid the same issue.

- We can't have library functions until avr-libc moves to a
library-per-device design. We have to be able to conditionally compile
the code to change it for certain devices.

- The ability to taking the addresses of these functions is not that
critical. How often would this be done in a real AVR application? It's
not likely.

- Yes there is no type checking, but that requires functions, which
requires library-per-device design.

At this point, I do NOT care if the generated code is twice the size as
used to be, as long as the code:
- Works correctly for *all* AVR devices in the toolchain that has EEPROM
(see avr-libc bug #21410), with all locations of EEPROM registers
- Fixes the GCC bug #31644 test case
- Has a means to allow future handling of the new EEPROM design in the
XMEGA devices

It would be nice if we can, in the future, remove all instances of
__EEPROM_REG_LOCATIONS__, as that was a kludge to begin with. This means
that we should only depend on typical register definitions in the IO
header file like EECR, EEDR, EEARL, EEARH, EEAR, etc.

Oh, and can it be done in a week? I need a short-term fix, now. This
discussion has gone on way too long. If you wish to debate the various
merits/demerits of the design, then please provide working examples that
meet the criteria above. I have seen Wouter and Dmitry provide code.
Shaun, you provided the dword routines (even though they've been
modified).

Eric Weddington