Re: [avr-libc-dev] New eeprom library. Comments please

[Björn Haase]

Nigel Winterbottom wrote on Donnerstag, 21. Juli 2005 17:41 :
> Hello All,
>
> I am aware of 3 problems with the eeprom support in avr-libc.
>
> 1. The SFR addresses are wrong for mega48, mega169, mega329 and the like.
> 2. eeprom_write_block takes a very long time even for small blocks.
> (56-Bytes takes approx 0.5s) 3. A topic on AvrFreaks
> http://www.avrfreaks.com/index.php?name=PNphpBB2&file=viewtopic&t=21371
> discussed the fact that the eeprom_read functions are not atomic. I.e. An
> interrupt could potentially mess up EEARL & EEARH.
>
>
> I have taken the avr-libc source "eeprom.S" and heavily modified it to
> create "eeprom1.S" and I've made 2 libraries as follows:
>
> 1. libee1C.a for EECR at 0x1C (for Mega128 etc)
> 2. libee1F.a for EECR at 0x1F (for Mega169, Mega48 etc)
Have a look a the patch I have posted on this list a couple of days ago. My 
patch consist of two parts. The one that deals with the different locations 
of the EEPROM registers does a very similar thing that your patch is doing. 
The difference however is, IIUC that I have changed the build system 
(Makefile and stuff) so that it takes the one single assembler file and 
generates several object files from the original sources. The different 
object files differ by their name, the name of the function entry point 
lables and the register locations: E.g. I have appended a string _1F2021 to 
the label names (e.g. _eeprom_write_byte_1F2021) if the eeprom registers are 
located at 0x1f, 0x20 and 0x21. With my patch it's in the makefile.am (IIRC) 
where one could specify for which set of register locations one desires 
object files to be generated. So it is very easy to include a new set of 
locations in case that the EEPROM registers reside on other addresses for a 
new device. Also there is no need for specific compile switches and with the 
approach I have suggested it is not necessary to build additional seperate 
libraries or to use device-specific compile switches in order to get EEPROM 
support functional.

> No 2 is improved by first reading the eeprom location and skipping the
> write if not necessary. Generaly when writing a block of data, usually
> contained in a structure, only a few bytes have been changed. This mod made
> a huge difference to my application
It would possibly be a good idea to supply a different set of functions: One 
set optimized for speed and one set optimized for size. E.g. in my 
applications the key issue generally is code size and not speed. So it might 
be useful to provide a possibility for the user to choose between the 
different options. Your approach seems to be complementary to the approach I 
have suggested. One could consider to merge them.

> A zip file (libee.zip) is attached which contains the source, libraries and
> the Makefile used to build the libraries.

(Remark: A diff -u would be helpful as well.)

Yours,

Björn