[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[avr-libc-dev] eeprom_write_block inconsistent between WinAVR and Linux
From: |
Dale Whitfield |
Subject: |
[avr-libc-dev] eeprom_write_block inconsistent between WinAVR and Linux |
Date: |
Sun, 13 Jul 2008 11:29:34 +0200 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
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] eeprom_write_block inconsistent between WinAVR and Linux,
Dale Whitfield <=