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

[Hakan Ardo]

Hi,
the latest debian release of gcc and binutils are based on the
WinAVR-20080610 winavr patches. But the latest avr-libc release is
1.6.2 at:

  http://download.savannah.gnu.org/releases/avr-libc/

but winavr seems to be based on 1.6.3, and the only one patch for it,
30-avr-libc-1.6.3-dwarf2.patch, which does not fix this problem.

On Sun, Jul 13, 2008 at 1:39 PM, Preston Wilson <address@hidden> wrote:
> 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
>
>
>



-- 
Håkan Ardö