Hey, Leute!
Kann mir jemand sagen, wie's kommt, dass ein winavr-projekt für einen
ATMega16 mir ein .hex-file erzeugt, das mehrere 1000 Byte gross ist?
Ausser header-includes und einer leeren main passiert dort nichts...
Thomas
Sicher Thomas,
16 kByte Flash ergeben 2x16 kByte an Zeichen im Wertebereich
{0,1,..,A,...F}
plus den Overhead für Adressen, Längen und Quersumme.
Ciao
Wolfgang Horn
Die Frage kommt hier fast jede Woche: Die Größe des Hex-Files hat nichts
mit der Größe des Programmcodes zu tun. Ein Hex-File ist eine
ASCII-Datei, die neben dem Code noch Adressinformationen usw. enthält.
Allein die Darstellung im ASCII-Format bläht den eigentlichen Code um
einen Faktor 2 auf.
Dazu kommt noch eine ganz andere Geschichte, nämlich, daß in C
Startup-Code mit gelinkt wird, der immer benötigt wird, auch bei einem
leeren Programm. Bei dem macht der prozentual natürlich sehr viel aus,
fällt aber bei echten Programmen meist kaum ins Gewicht.
Was ich meinte, war auch nicht die Dateigrösse der .hex-Datei, sondern
die tats. Codegröße, die WinAVR mir nach dem compilieren im
Output-Fenster mitteilt. Hab ich mich wohl undeutlich ausgedrückt,
sorry. Ich meine also die Codemenge.
>Sicher Thomas,>16 kByte Flash ergeben 2x16 kByte an Zeichen im Wertebereich>{0,1,..,A,...F}>plus den Overhead für Adressen, Längen und Quersumme.
Ja, und 2 mal 3 macht vier widewidewit...
Thomas
Thomas wrote:
> Was ich meinte, war auch nicht die Dateigrösse der .hex-Datei, sondern> die tats. Codegröße, die WinAVR mir nach dem compilieren im> Output-Fenster mitteilt. Hab ich mich wohl undeutlich ausgedrückt,> sorry. Ich meine also die Codemenge.
Und.
Was erwartest du jetzt von uns.
Dass wir, hellseherisch veranlagt wie wir nun mal sind, durch
Gedankenlesen rausfinden, wodurch dein Programm Speicher
verbraucht?
Dann mache ich mal den ersten Rateversuch:
Du hast den Optimizer nicht eingeschaltet.
>>16 kByte Flash ergeben 2x16 kByte an Zeichen im Wertebereich>>{0,1,..,A,...F}>>plus den Overhead für Adressen, Längen und Quersumme.>> Ja, und 2 mal 3 macht vier widewidewit...
Bei einer völlig korrekten Antwort, solltest du dich mit
deinem Sarkasmus etwas zurückhalten. Immerhin warst du es,
der noch nicht mal seine Frage richtig formulieren konnte.
hmpf
Da haste Recht. Nehme alles zurück.
Also, dann versuch ich's mal so:
Optimizer ist -s
main.c sieht so aus:
1
#include<avr/io.h>
2
3
intmain(void){
4
5
return1;
6
}
und WinAVR sagt nach dem Compilieren:
____________________________________
Size after:
AVR Memory Usage
----------------
Device: atmega16
Program: 4612 bytes (28.1% Full)
(.text + .data + .bootloader)
Data: 0 bytes (0.0% Full)
(.data + .bss + .noinit)
____________________________________
Das bedeutet doch, dass ich mit diesem "Programm" 28,1% von meinen 16K
(eben jene 4612 bt) belegt habe. Und dies kommt mir halt doch viel vor.
Und... Ich habe mal gelesen, man sollte den optimizer nicht nutzen, wenn
man die delay.h-funktionen nutzt...
Und nix für ungut nochmal, bin halt n Hitzkopp.
Thomas
Meine Kristallkugel (zum Glück gerade aus der Reparatur zurück)
sagt, dass du die floatingpoint-Version der printf-Routinen samt
der notwendigen Gleitkomma-Mathe-Routinen zwanghaft mit linkst,
obwohl du sie ja gar nicht benutzt. Wenn ich das ebenfalls mache,
dann komme ich auf:
1
% avr-size foo.elf
2
text data bss dec hex filename
3
4630 0 0 4630 1216 foo.elf
Lass ich diese Bibliothek raus, dann bleibt übrig:
1
% avr-size foo.elf
2
text data bss dec hex filename
3
154 0 0 154 9a foo.elf
Von diesen 154 Bytes entfallen 84 Bytes auf die
Interruptvektortabelle, 58 Bytes auf den Startupcode (der hier zwar
größtenteils nicht nötig wäre, aber trotzdem immer gelinkt wird),
4 Bytes auf die Default-ISR, 6 Bytes auf die Funktion main() und
2 Bytes auf die Funktion exit() (eine Endlosschleife :).
Edit: OK, haben sich unsere Postings überkreuzt, hast es ja selbst
schon gemerkt.