Hallo, ich erhalte verschiedene Größenangaben, je nach Methode wie ich zähle: avr-size main.elf text data bss dec hex filename 6786 126 196 7108 1bc4 main.elf avr-size main.hex text data bss dec hex filename 0 6870 0 6870 1ad6 main.hex egal wie ich bei ersterem text, data und bss zusammenaddiere oder abziehe, komme ich nicht auf die 6870 Bytes bei der zweiten Methode. Ich war bisher immer von text + (bss -data) ausgegangen, aber das passt doch nicht ganz. mit avr-size *.o erhalte ich: text data bss dec hex filename 384 0 0 384 180 ad_converter.o 84 42 0 126 7e calibration_config.o 386 0 0 386 182 clock.o 3269 55 13 3337 d09 control.o 210 0 0 210 d2 da_output.o 458 0 6 464 1d0 lcd.o 186 0 0 186 ba main.o 388 0 20 408 198 rs232_io.o 289 0 1 290 122 scheduler.o 160 0 0 160 a0 tools.o 352 20 0 372 174 user_in.o 126 8 0 134 86 validator.o Addiere ich hier alle Werte für text, so ist die Summe (6292) kleiner als der Wert text bei avr-size main.elf. Und zuguter letzt direkt ins .hex file geschaut, finde ich 429 Zeilen mit je 16 bytes, eine Zeile mit zwei Bytes (warum auch immer) und als vorletzte Zeile eine mit vier Bytes, die letze besitzt nur die Checksumme. Macht zusammen immerhin die oben genannten 6870 bytes. Wie passen nun die drei Werte zusammen? Übrigens sind die Werte bei avr-size *.o für den gcc 4.1.0 abhängig von der Optimierung, wobei manche Dateien bei -O1, manche bei -O2 und manche bei -Os die kleinsten Werte haben. Ich hätte gererell bei -Os die kleinsten Größen erwartet.
hallo, nur kurz zu deiner zusammenrechnung der .o -files. da fehlen dir einfach die instruktionen aus der gcrt aus der avrlibc. und dann nicht zu vergessen die instruktionen aus der libgcc.S, die vom gcc bereitgestellt und auch in finalen .elf gelinkt wird. bye kosmo
Malte __ wrote: > ich erhalte verschiedene Größenangaben, je nach Methode wie ich zähle: > avr-size main.elf > text data bss dec hex filename > 6786 126 196 7108 1bc4 main.elf Der ROM-Verbrauch ist text + data (letzteres, weil ja die initializer der initialisierten Daten auch im ROM hinterlegt werden müssen). Der statische RAM-Verbrauch ist data + bss. Da kommt noch der dynamische Verbrauch für den Stack hinzu. > avr-size main.hex > text data bss dec hex filename > 0 6870 0 6870 1ad6 main.hex Da ein Hex-File selbst keine section-Information hat, schlagen es die binutils erstmal pauschal auf "data" zu. In Wirklichkeit enthält das Hex-File natürlich das ROM-Abbild. Warum das hier weniger als text + data aus deinem ELF-File sind, erschließt sich mir allerdings nicht. > mit avr-size *.o ... bekommst du insbesondere keine exakte Angabe über den bss-Verbrauch, da dieser in den verschieblichen Objekten noch in Form sogenannter common blocks definiert wird, die erst vom Linker überlagert werden. Damit kennt erst der Linker deren tatsächlichen Speicherverbrauch. Das Ganze stammt aus FORTRAN-Zeiten und wurde in die Unix-C-Compiler übernommen, weil man damit so schön schlampig einfach "int foo;" in eine Header-Datei schreiben kann, und die im Prinzip daraus resultierenden Definitionen der Variablen foo in jedem Objektmodul dann vom Linker doch noch in nur ein einziges foo verwandelt werden. (Ich vermute mal, dass das "Ur-C" einfach noch gar kein "extern"-Schlüsselwort besass.) Im GCC kannst du das mit -fno-common übrigens verhindern. Außerdem fehlt dir bei deinen .o-Dateien natürlich alles aus der Bibliothek, vom startup-Code angefangen.
> Wie passen nun die drei Werte zusammen?
LOL ja das ist wirklich komplett seltsam gelöst, typisch open source und
von Linux kommend.
FLASH=xxxxx als Beispiel wäre ja auch zu einfach gewesen.
hackklotz wrote: > LOL ja das ist wirklich komplett seltsam gelöst, typisch open source und > von Linux kommend. [ ] Du hast Ahnung. [ ] Du hast je mit etwas anderem als Windows und Linux zu tun gehabt.
Hab's gerade mal an ein paar Beispielen ausprobiert: In allen Fällen ist text+data im ELF-File gleich data im Hex-File, so wie man das erwarten würde. Ich benutze binutils 2.17. Bist du sicher, dass dass das Hex- und das ELF-File wirklich zueinander gehören? Möglicherweise hast du das Programm geändert, kompiliert und gelinkt, aber das Hex-File noch nicht aktualisiert. Bei meinem Makefile bspw. wird das Hex-File erst beim Flashen des Controllers generiert, nicht schon beim Kompilieren. Es ist damit die meiste Zeit nicht aktuell.
Danke, für die Erklärung. Mein Makefile erzeugt jedoch nach dem compilieren stets die .hex Datei. Ich denk, ich weiß jetzt aber wo die Differenz herkommt: avr-size main.elf text data bss dec hex filename 6882 126 200 7208 1c28 main.elf avr-size main.hex text data bss dec hex filename 0 6966 0 6966 1b36 main.hex avr-size main.eep text data bss dec hex filename 0 42 0 42 2a main.eep Demnach enthält die main.elf auch noch die EEprom Daten, die .hex logischwerweise jedoch nicht.
Ja, das ist wahr, die section .eeprom wird in der Standardausgabe mit zu "data" gerechnet. Wenn du avr-size -A benutzt, bekommst du die Informationen detaillierter.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.