Codegrösse?

Gast #77192
Lesenswert?

Hallo,
ich bin gerad dabei einen Atmega16 zu programmieren (avr-gcc). Leider
hab ich echte Probleme mit den Dateigrössen. Ich habe zuerst stdio
stdlib und string.h eingebunden. Damit wurde das Programm (.hex) 13500
Byte gross ?!

Der Mega hat nun ja 16 Kb. Da ist nicht mehr so viel Platz, also hab
ich die wichtigsten Funktionen (atoi, strcmp, und sscanf) selber
programmiert und die Header rausgeworfen. Der Code ist immer noch fast
genau so gross!

Kann man da Abhilfe schaffen? Oder hab ich nur einen Denkfehler?

Danke
MfG Torsten
Gast #77193
Lesenswert?

> Ich habe zuerst stdio stdlib und string.h eingebunden. Damit wurde
> das Programm (.hex) 13500 Byte gross ?!

Von den Header-Dateien wird es weder groß noch klein: die enthalten
nur die Deklarationen.  Entscheidend ist, was Du alles linkst.  stdio
ist allerdings schon ein mächtiger Klopper, völlig klar, für einen
ATmega16 kann das je nach Aufgabe aber durchaus benutzbar sein.

> ... also hab ich die wichtigsten Funktionen (atoi, strcmp, und
> sscanf) selber programmiert und die Header rausgeworfen.

Es wäre besser gewesen, stattdessen die Ursache zu analysieren. ;-)

Meine Vermutung ist, daß Du nach wie vor die floating point Variante
von printf() drin hast, aber ohne Deine Linker-Kommandozeile ist das
schwer zu sagen.  Du kannst Dir die Ausgabe-Symboltabelle mal ansehen,
dort siehst Du, welche Funktion auf welche Adresse gelinkt ist.  Mit
Tools wie avr-sizex bekommst Du wohl sogar gesagt, welche Funktion wie
groß ist (disclaimer: habe ich selbst noch nie benutzt).

Im Übrigen bezweifle ich, daß Dein rewrite von strcmp() kleiner
geworden ist als die Bibliotheksfunktion. ;-)  Auch bei scanf() bin
ich dran interessiert zu sehen, ob Du das kleiner bekommen hast als
ich...
Gast #77196
Lesenswert?

Aus der Groesse des *.hex Files kann man nicht direkt auf die
Code-groesse schliessen. Das *.hex Fileformat hat sehr viel Overhead
(Adressen , Zeilenlaengen, Pruefsummen) der nur zur Datenuebetragung
(PC <-> Programmiergerät) benoetigt werden. In den Controller wird nur
die reine Binaerinformation programmiert die wesentlich weniger Platz
beansprucht.
Ich würde einfach mal das File in den Controller programmieren!

Hans
Gast #77197
Lesenswert?

Hui, ich dachte das Hex File enthält die Daten so wie sie in den mC
kommen?! Naja, wieder was gelernt.

@Jörg: Naja, die nachprogrammierten Sachen, sind nur so gemacht das es
funktioniert.
Es ist natürlich so, das der header nur Referenzen bereitstellt. Da war
ich auf dem Holzweg...

Wo könnte man denn (ausser im Programmer) sehen wie gross die
Binärdaten des Programms sind?

Danke

MfG Torsten
Gast #77200
Lesenswert?

Hi

avr.size main.elf

text sollte dann in etwa die benutzte Menge Flash angeben. Allerdings
sind 13k Hex-File immer noch ~4,5k belegtes Flash. Wie Jörg schon
vermutet wirst du irgendwas unnötiges dazulinken. Schieb doch mal deine
Linkerkommandos hier rein.

Matthias
Gast #77204
Lesenswert?

Hallo...
man kann die Codegroesse auch direkt sehen (ausgabe).
Das sieht dan ~ so aus:

Size after:
expose.elf  :
section    size      addr
.text      1002         0
.data        12   8388704
.bss         16   8388716
.noinit       0   8388732
.eeprom       0   8454144
.stab      3636         0
.stabstr   2524         0
Total      7190

Die Section .text ist die Codegroesse.

Alex
Gast #77206
Lesenswert?

Hi

@Jörg

Ich nutze zum Teil das EEPROM um dort irgendwelche Daten oder
Grafiken/Texte) abzulegen (Flash wird knapp). In dem Fall enthält .data
auch diese Daten die aber nicht im Flash landen. Deshalb schrieb ich
oben auch

"text sollte dann in etwa die benutzte Menge Flash angeben"

Wenn man also das EEPROM als Datenspeicher verwendet muß man .data
nicht komplett zu .text dazurechnen.

Matthias

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