.hex zu gross, warum?

#675785
Lesenswert?

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.
Gast #676288
Lesenswert?

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.
Gast #676518
Lesenswert?

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
#676536
Lesenswert?

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.
Gast #676561
Lesenswert?

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
int main (void) {
4

5
return 1;
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
Moderator Persönliche Seite #676602
Lesenswert?

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.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren