WinAVR 20090313 Released

[Mehmet K. (mkmk)]

http://sourceforge.net/projects/winavr/

[egberto (Gast)]

Gibt es schon Aussagen/Erfahrungen betzüglich der (entstehende)Codegröße 
(sonst bleib ich lieber bei der 2007er Version)?

Viele Grüße,

egberto

[Andreas K. (andie)]

Ich habe ein kleines Projekt auf einem ATtiny13A mit folgenden 
Codegrößen:

WinAVR-20071221:  974 bytes  (95,1%)
WinAVR-20081205: 1508 bytes (147,3%)
WinAVR-20090313: 1508 bytes (147,3%)

Ich bleibe bei der 2007er Version ;-)

Gruß andie.

[Simon K. (simon)]

Andreas Kasper wrote:
> Ich habe ein kleines Projekt auf einem ATtiny13A mit folgenden
> Codegrößen:
Repräsentativ.

> Ich bleibe bei der 2007er Version ;-)
Mach das.

Zurück in die Steinzeit!

[mkmk (Gast)]

Wenn Du die EEprom Funktionen benutzest, so werden die Programme seit 
den 2 letzten 2 Releases massiv aufgeblaeht. Wenn Du sie dann durch 
eigene ersetzest, schrumpft die Grösse auf das Normalmass zurück.

[Johann L. (gjlayde)]

Ja. Früher war alles besser ;-)

Das Problem scheint nur bei den Block-Funktionen für den EEPROM aus der 
avr-libc zu bestehen, also für eeprom_read_block und eeprom_write_block.

Die eeprom_read_block ruft im Endeffekt indirekt die __eerd_block auf, 
deren Implementierung ganz unschuldig aussieht:
   http://cvs.savannah.gnu.org/viewvc/avr-libc/libc/misc/eerd_block.c?revision=1.2&root=avr-libc&view=markup

Wenn man allerdings nen Dump macht und sieht, was da alles hinzugelinkt 
wird, dann sieht es nicht mehr ganz so prickelnd aus (siehe Anhang).

Und das kostet nicht nur mächtig Flash, sondern knabbert auch merklich 
am  RAM! Es werden sehr viele Register gesichert.

Das Problem sollte sich auf avr-libc-Ebene beheben lassen, indem das 
Makefile für die genannten Funktionen -mcall-prologues vermeidet.

Aus Applikationsebene sollte man die Funktionen vermeiden, wenn man sich 
nicht ohnehin über andere avr-libc Funktionen die 
Prolog/Epilog-Funktionen zieht. In dem Falls könnte man selbst ne 
Schleife um die read/write Byte Funktionen bauen, und muss bei dem 
EEPROM-Zeug zumindest nicht bei Null anfangen...

Johann

[Peter D. (peda)]

Die AVR-GCC 4.3.x erzeugen bei mir alle den selben Code. An der 
Optimierung wurde also nichts geändert.

Wenn Du AVRs benutzt, die der AVR-GCC 4.2.x schon kennt, solltest Du ihn 
ruhig weiter verwenden. Insbesondere, wenns eng im Flash wird.

Der AVR-GCC 4.3.x erzeugt oftmals doch recht seltsamen Code.


Peter

[Simon K. (simon)]

Trotzdem sollte man prinzipiell nicht auf ältere Versionen 
zurückgreifen, sondern versuchen die Bugs in den neuen Versionen zu 
reparieren.

[Johann L. (gjlayde)]

Hab eben mal mein aktuelles Projekt mit verschiedenen Versionen von 
avr-gcc übersetzt und die Codegröße anzeigen lassen

avr-gcc  |  WinAVR  | Code
---------+----------+------
 3.4.6   | 20060421 | 11656
 4.2.2   | 20071221 | 12244
 4.3.0   | 20080610 | 12068
 4.3.2   | 20081205 | 12152
 4.3.2   | 20090309 | 12122

Sei der Dezember-Release gab es also eine minimale Verbesserung, und in 
der 4-er Linie lässt sich eine Tendenz zu kleinerem Code hin erkennen.

Der 4-er Compiler schliesst weiter zur letzten 3-er Release auf und 
liegt nur noch 4% hinter ihr.

Simon K. wrote:
> Trotzdem sollte man prinzipiell nicht auf ältere Versionen
> zurückgreifen, sondern versuchen die Bugs in den neuen Versionen zu
> reparieren.

Klaro, aber bis dahin wird noch ein Weilchen vergehen. Ich seh das nicht 
so dogmatisch, daß man prinzipiell immer das Allerneueste haben bzw. 
einsetzen muss.

Johann

[Mehmet K. (mkmk)]

Atmega324P

WinAVR-20081205: 10108 bytes
WinAVR-20090313: 10110 bytes

Benutze beim Zugriff auf das interne Eeprom meine eigenen Lese- und 
Schreib-Funktionen.