Re: [avr-libc-dev] Is eeprom_write_byte supporting the new bitwise eeprom write feature of new devices?

[Björn Haase]

Selbst wrote on Mittwoch, 12. April 2006 23:43 :
> Hi,
>
> i just read about the more or less new feature of the newer avr devices
> that allows more efficient eeprom write operations. Basically it allows to
> save some erase cycles if bits only need to be set but none erased:
> http://www.atmel.com/dyn/resources/prod_documents/doc2578.pdf
>
> Are the current avr-libc functions using this eeprom write scheme if
> available?
To my best knowledge there is no such implementation so far.
IMO, there will always be a trade-off. The present library code is optimized 
for *size*: When I re-wrote the EEPROM functions that what I had in mind 
first of all was the code efficiency. I.e. I made quite some efforts to limit 
code size by being as register efficient as possible and as code efficient as 
possible. Speed was not a focus at all. It was frequently stated opinion IIRC 
that EEPROM functions that are trying to be as fast as possible should be 
rather left to the user: It's probably likely that one needs knowledge on 
some of the system's properties to be *really* fast, e.g. by IRQs.

What I'd like to suggest you to do in order to implement your whishes quite 
easily is:

1.) Add an own assembly file to your avr project that is supposed to hold your 
own "fast" eeprom write byte function.

2.) Re-Define the eeprom write byte function. No change elsewhere will be 
necessary. The function entry label should read "__eeprom_write_byte_1C1D1E" 
or "__eeprom_write_byte_1F2021" depending on the place where your device has 
it's eeprom registers. The linker then will use your definitions of the 
function instead of the library's own one. You will only have to implement 
the write byte functions: The write block function and the write word 
function themself make use of the write byte function and would benefit of 
your speed-up.

You should keep care to make the linker place the function in the .text.eeprom 
section just like the present library function.

Note that for the eeprom functions the usual calling convention for functions 
does not apply! You will have to preserve all of the registers. We are not 
using the standard calling convention in order to be as code efficient as 
possible.

... hope that helps, 

Bjoern.

BTW.: 
Here is the present implementation. Note that your function also will be 
required to implement the auto-increment feature for r26:r27. EEprom write 
block and eeprom write byte rely on this. The _EELABEL makro adds the suffix 
(e.g. 1C1D1E) that I mentioned above.

/* write a byte to EEPROM
   Address in r26:r27, value in __tmp_reg__
   Post increment r26:r27.  */

        .section .text.eeprom, "ax", @progbits
        .global _EELABEL(eeprom_write_byte)

_EELABEL(eeprom_write_byte):
        sbic    _SFR_IO_ADDR(EECR), EEWE
        rjmp    _EELABEL(eeprom_write_byte)     /* make sure EEPROM is ready 
*/
#ifdef EEARH
        out     _SFR_IO_ADDR(EEARH), r27
#endif
        out     _SFR_IO_ADDR(EEARL), r26
        out     _SFR_IO_ADDR(EEDR),__tmp_reg__
        adiw    r26,1 /* Increment x register */
        in      __tmp_reg__, _SFR_IO_ADDR(SREG)
        cli                     ; /* no ints between setting EEMWE and EEWE */
        sbi     _SFR_IO_ADDR(EECR), EEMWE
        sbi     _SFR_IO_ADDR(EECR), EEWE
        out     _SFR_IO_ADDR(SREG), __tmp_reg__
        ret