eeprom_write_block inconsistent between WinAVR and Linux

[Dale Whitfield]

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
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[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
> AVR-libc-dev@...
> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[Hakan Ardo-2]

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 <pwilson@...> 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
>> AVR-libc-dev@...
>> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
>
>
>

--
Håkan Ardö


_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[Weddington, Eric-2]

 

> -----Original Message-----
> From:
> avr-libc-dev-bounces+eweddington=cso.atmel.com@...
> [mailto:avr-libc-dev-bounces+eweddington=cso.atmel.com@nongnu.
> org] On Behalf Of Hakan Ardo
> Sent: Monday, July 14, 2008 2:50 AM
> To: Preston Wilson
> Cc: avr-libc-dev@...
> Subject: Re: [avr-libc-dev] eeprom_write_block inconsistent
> between WinAVR andLinux
>
> 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.
>

And technically, there is no 1.6.3 release of avr-libc. I just pulled a
CVS snapshot of avr-libc. The avr-libc patch is very minor anyway.


_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[Hakan Ardo-2]

OK, is there a tag or a date/time of this snapshot so I can pull the
same one for debian?

On Mon, Jul 14, 2008 at 4:37 PM, Weddington, Eric
<eweddington@...> wrote:
>
> And technically, there is no 1.6.3 release of avr-libc. I just pulled a
> CVS snapshot of avr-libc. The avr-libc patch is very minor anyway.
>



--
Håkan Ardö


_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[Weddington, Eric-2]

 

> -----Original Message-----
> From: Hakan Ardo [mailto:hakan.ardo@...]
> Sent: Monday, July 14, 2008 12:24 PM
> To: Weddington, Eric
> Cc: Preston Wilson; avr-libc-dev@...
> Subject: Re: [avr-libc-dev] eeprom_write_block inconsistent
> between WinAVR andLinux
>
> OK, is there a tag or a date/time of this snapshot so I can pull the
> same one for debian?
>

Use the "WinAVR-20080610" tag of avr-libc. This is for the 1.6 branch.


_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev