avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Theodore A. Roth
Subject: Re: [avr-libc-dev] eeprom_rb strangeness??
Date: Fri, 1 Nov 2002 09:53:35 -0800 (PST)

On Fri, 1 Nov 2002, Joerg Wunsch wrote:

:) As Thedore A. Roth wrote:
:)
:) > I would think that this should be:
:) >
:) >   unsigned char eeprom_rb (unsigned char *addr);
:)
:) I'd prefer uint8_t *addr.  Both are the same, but the term "char"
:) mnemonically refers to a character you can display, while "uint8_t"
:) rather means a small integer type.  Also, since C99 now standardizes
:) integer types of certain bit width, we can give a good example for
:) what is preferable over all those home-brewn "u8" etc. data types.
:)
:) Or, just use "void *".  In particular for eeprom_read_block(), this
:) would allow passing the address of a structure without any typecast.
:)
:) Maybe uint8_t * for the single-byte operations, and void * for the
:) block operation(s)?

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);

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);

That should cover all the cases sufficiently, although the eeprom_{rd,wb}
are enough to do anything (albeit not optimally).

If I don't hear anything against these changes, I'll implement them over
the weekend.

Ted Roth





reply via email to

[Prev in Thread] Current Thread [Next in Thread]