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

[Wouter van Gulik]

Weddington, Eric schreef:
>>
> 
> Bah! Trying again.
> 
> Thanks for everyone's patience.
> 
> Eric Weddington
> 

So I got the header and my first consideration in is the copyright... 
All previous contributers are now gone? I hope this is WorkInProgress.

Second why all these hideous define with there nasty \ ?

For eeprom read an inline function I came up with this (for E2ND> 0xFF)

//static inline uint8_t __eeprom_read_byte_address_word(uint8_t*) 
__attribute__((always_inline));
static inline uint8_t __eeprom_read_byte_address_word(uint8_t* eeptr)
{
     uint16_t __address_word = (uint16_t)(eeptr);
     uint8_t __result;
     do{}while(!eeprom_is_ready());
     EEARL = __address_word & 0xFF;
     EEARH = __address_word >> 8;
     EECR |= 1<<EERE;
     __result = EEDR;
     return __result;
}

This is plain C, but it's forced to be in this specific order, since all 
(!) access is to volatile memory. There is no timing constraint on 
instruction sequence so there is no problem.

For -O0 it generates large but valid code.
For -O[123] it gives all the same small code
For -Os it might give a function call, so I added the always_inline 
constraint. Then it gives the same results, however it's arguable to leave
the inlining to gcc, since it might be smaller (in case of several calls) 

My C function gives much, much smaller code. GCC gets its hands tide up
because of the assembler, it forgets it can recycle registers etc...

So I would recommend this C function approach for all read routines.
Of course read word could be made more sophisticated using gcc ability to
check on constants (__builtin_constant_p), so you could then check for page
crossing and write the high address only once.

The write sequence is best to be in asm since it needs a special timing and
interrupt clearing.
 
One last thing, why is there a loop before every function? In the old code
there is no loop (although the documentation state there is!?!).

And the old code is not disabling interrupts during eeprom write... which is
no good! Maybe this was the problem of the report for the tiny13?

HTH

Wouter