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

[Anton Erasmus]

On 15 Jan 2008 at 20:05, Weddington, Eric wrote:

> Hi All,
> 
> Because of an avr-libc bug (#21410), a GCC bug (#31644), and IIRC, the
> fact that the EEPROM API does not work on at least 2 AVR devices, I have
> taken a stab at rewriting the EEPROM API. The interface has been kept
> the same, but instead of library functions, it has been rewritten as
> macros generating inlined assembly.
> 
> Yes, there is the potential that the macro version could take up more
> code space with more calls to the macro. However, it is imperative that
> this API work on *all* AVRs (that have EEPROM) and to have it work on
> future AVR devices as well. I would rather have it work correctly first,
> optimize later. Since we do not have a true multi-lib environment (per
> device), implementing it as macros is the only way we have right now to
> handle differences with multiple devices.
> 
> I have done compile tests, however, I have not tried this out on actual
> hardware yet. I thought I would get this out to everyone a bit early for
> feedback. Over the next day or two, I will be testing this on some real
> hardware (probably an ATmega128).
> 

I have not seen the eeprom.h file, so my comments might be totally inapropriate.
Wouldn't it be better to use static inline functions in stead of macros ? One 
gets
the same advantages of macros, but without many of the dangers of macros.

i.e. In stead of having a macro

#define foo(x)  /* Code here */

have an inline static function in the header file:

static inline void foo(int x)
{
  /* Code here */
}

Because the function is static, no code is generated if it is not used. 

Regards
  Anton Erasmus

-- 
A J Erasmus