.hex zu gross, warum?

[Thomas (Gast)]

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

[Wolfgang Horn (Gast)]

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

[Johannes M. (johnny-m)]

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.

[Rolf Magnus (Gast)]

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.

[Thomas (Gast)]

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

[Karl H. (kbuchegg)]

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.

[Thomas (Gast)]

hmpf
Da haste Recht. Nehme alles zurück.

Also, dann versuch ich's mal so:
Optimizer ist -s

main.c sieht so aus:

#include <avr/io.h>

int main (void) {

return 1;
}

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

[Stefan B. (stefan)]

Die Optimizer-Option ist -Os. Und bei den Delay-Funktionen MUSS der 
Optimizer benutzt werden, weil die sonst nicht arbeiten wie gewünscht.

[Thomas (Gast)]

Danke für den delay-hint!

Ich Trottel hatte die sprintf-option auf "floating". So kann's gehen.

t

[Jörg W. (dl8dtl) (Moderator)]

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:

% avr-size foo.elf
   text    data     bss     dec     hex filename
   4630       0       0    4630    1216 foo.elf

Lass ich diese Bibliothek raus, dann bleibt übrig:

% avr-size foo.elf
   text    data     bss     dec     hex filename
    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.

[Thomas (Gast)]

Wow, Deine Glaskugel ist spitze!

Besten Dank trotzdem!