Umm, describe "no longer works correctly". There are two defects that I know of that can cause problems: 1. If a function is called from an ISR, the ISR will not pre-save all of the "call-used" registers before calling the function. This can cause serious and hard-to-track-down problems. The only workaround on this that I know of is to hand-save all call-used registers on entry to the ISR and restore them before exit. WinAVR defect 1956569 A patch has been submitted according to Eric. 2. On 3-byte PC processors (ATmega2560/2561), the EEPROM routines will not work correctly. This is because they were rewritten to use function pointers, and GCC only knows about 2-byte function pointers. A patched eeprom.h file has been submitted. AVR-LibC Bug 22878 These are both changes from WinAVR 20071221 that caused my code to fail. There may be more, but because of problem 1 above, I cannot get my code to run long enough to find anything else. If you can live with 20071221, I would stick with that. From your problem description, I would definitely suspect problem #1 above.
Best regards, Stu Bell DataPlay (DPHI, Inc.) ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Paddock Sent: Monday, May 12, 2008 2:35 PM To: avr-gcc-list@nongnu.org Subject: [avr-gcc-list] What has changed between WinAVR 20070525rc2 andWinAVR 20080430? Can anyone tell me what has changed from: avr-gcc (GCC) 4.1.2 (WinAVR 20070525rc2) to?: avr-gcc (WinAVR 20080430) 4.3.0 I recompiled code for a working product using 4.1.2 with 4.3.0 and it no longer works correctly. Fairly complex product so trying to localize the problem would not be all that much fun, without some insights as to what might be different. The unit has a bit mapped display. With 4.3.0 I have random pixels that I don't have with 4.1.2, which probably indicates that I have something marginal in my display driver timing. When I assert INT0 the unit eventually locks up with 4.3.0, but not with 4.1.2. All rather vague descriptions, I know... RAM and EEPROM usage remained the same, code size grew by 516 bytes going from 4.1.2 to 4.3.0.
_______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
