Re: [avr-libc-dev] eeprom_write_block inconsistent between WinAVR and Linux

[Preston Wilson]

The order of the arguments were accidentally reversed in the first rev of
the eeprom routines that were inline.  Demitry Xmelkov fixed the problem
quickly when the problem was pointed out.  The doc and the WinAVR version
are correct.  Around that same time there were a couple of bugs introduced
into the compiler that did cause wrong code generation, so even if you fix
or work around the eeprom_write_block argument order issue, you might be
dealing with other nasty issues.

One answer is to build a current Linux tool chain based on the WinAVR
patches.

Here is the bug and commit logs for the eeprom_write_block issue:

bug #22828: eeprom_write_block(): incompatibility in args order
http://savannah.nongnu.org/bugs/?22828

The CVS commit logs
http://lists.nongnu.org/archive/html/avr-libc-commit/2008-04/msg00007.html
http://lists.nongnu.org/archive/html/avr-libc-commit/2008-04/msg00006.html

-Preston


"Dale Whitfield" wrote:

> Hi,
> 
> I've just been bitten by a nasty...
> 
> eeprom_write_block is defined differently in WinAVR and avr-libc, as
> distributed under Linux.
> 
> Linux has:
> 
> static __inline__ void
> eeprom_write_block (void *__dst, const void *__src, size_t __n)
> {
>     __eewr_block (__dst, __src, __n, eeprom_write_byte);
> }
> 
> WinAVR has:
> static inline void __attribute__ ((always_inline))
> eeprom_write_block (const void *pointer_ram,
>                     void *pointer_eeprom,
>                     size_t size);
> 
> Its obvious now, after days of debugging, that source and destination
> are reversed. Thus making code developed on one incompatible with the
> other. Its not so obvious when code suddenly misbehaves and is erratic
> when compiled under Linux when it worked under WinAVR. I was looking for
> compiler issues, mistakenly.
> 
> Curiously, 
> 
> http://www.nongnu.org/avr-libc/user-manual/group__avr__eeprom.html
> 
> defines eeprom_write_block as per WinAVR above.
> 
> This isn't really a question of right or wrong, since the Linux version
> follows the usual memcpy/strcpy/etc. It does make me wonder why things
> diverged at some point since copyrights, etc in the two files are
> similar.
> 
> Consistency between the two is important, I feel, but changing one or
> the other is hugely fraught with compatibility issues.
> 
> Now that we have a usable compiler for Linux (Debian in my case), for
> atmega256x, are there any other pitfalls anyone knows about?
> 
> Dale.
> 
> 
> _______________________________________________
> AVR-libc-dev mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev