Re: [avr-libc-dev] eeprom_rb strangeness??

[Joerg Wunsch]

As Theodore A. Roth wrote:

> Ok, here's the new prototypes I propose then:
> 
> 
>   #include <inttypes.h>
> 
>   uint8_t eeprom_rb (uint8_t *addr);
>   void eeprom_wb (uint8_t *addr, uint8_t val);
> 
>   uint16_t eeprom_rw (uint16_t *addr);
> 
>   void eeprom_read_block (void *to_buf, void *from_addr, size_t n);

Makes sense.

> And for completeness, I propose adding these:
> 
>   void eeprom_ww (uint16_t *addr, uint16_t val);
>   void eeprom_write_block (void *to_addr, void *from_buf, size_t n);

I guess the reason why they are not implemented is that it can
cost you a lot of time you end up in waiting for the EEPROM cell
to become ready.  I agree that they should be implemented anyway,
but the documentation should stress that issue a bit so people
aren't caught in surprise when they discover that writing a block
might take several milliseconds (which is close to an infinite
wait given the good processing speed of the AVR ;-).

Anyone who wants to have it better needs to implement an
interrupt-driven API, but that's beyond what avr-libc can do for
them.

Eric wrote:

> For readability it would be nice to have
> 
> eeprom_read_byte
> eeprom_write_byte
> eeprom_read_word
> eeprom_write_word
> eeprom_read_block
> eeprom_write_block

I have to agree.
-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/