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 <[EMAIL PROTECTED]> 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 >> [email protected] >> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev > > > -- Håkan Ardö _______________________________________________ AVR-libc-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
