Gibt es schon Aussagen/Erfahrungen betzüglich der (entstehende)Codegröße (sonst bleib ich lieber bei der 2007er Version)? Viele Grüße, egberto
Gast
#1194633
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.
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!
Gast
#1195484
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.
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
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
Trotzdem sollte man prinzipiell nicht auf ältere Versionen zurückgreifen, sondern versuchen die Bugs in den neuen Versionen zu reparieren.
Hab eben mal mein aktuelles Projekt mit verschiedenen Versionen von avr-gcc übersetzt und die Codegröße anzeigen lassen
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
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
Atmega324P WinAVR-20081205: 10108 bytes WinAVR-20090313: 10110 bytes Benutze beim Zugriff auf das interne Eeprom meine eigenen Lese- und Schreib-Funktionen.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.