Forum: Compiler & IDEs Codegrösse?


von Torsten (Gast)


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

von Jörg Wunsch (Gast)


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...

von Martin Jansen (Gast)


Lesenswert?

sorry, passt net so ganz zu dem problem:

ich habe nur mal so ne frage, was bewirkt printf() beim avr??
schickt der dann den string übers uart oder wie?

von Jörg Wunsch (Gast)


Lesenswert?

Kurze Antwort: RTFM.

Lange Antwort: Du kannst das völlig frei festlegen, wohin das geht.

von Hans Hildenbrand (Gast)


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

von Torsten (Gast)


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

von Peter D. (peda)


Lesenswert?

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


Faustregel: hex / 2,8

D.h. in den M16 passen etwa 44kB Hex rein.


Peter

von Torsten (Gast)


Lesenswert?

Kleiner Nachtrag: Wenn ich die hex Datei mit PonyProg öffne, ist die
letzte Adresse irgendwo bei 4000 Bytes !

-> Avr-gcc rulez :-)

MfG Torsten

von Matthias (Gast)


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

von Martin Jansen (Gast)


Lesenswert?

@ jörg:
wie lege ich denn fest, wohin die daten gehen?

von Matthias (Gast)


Lesenswert?

Hi

RTFM. Das steht in der AVRLibc-Doku.

Matthias

von Jörg Wunsch (Gast)


Lesenswert?

Naja, 4,5 KB Flash sind für eine Applikation, die scanf() benutzt,
nicht zu schlimm.

von Alex1 (Gast)


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

von Jörg Wunsch (Gast)


Lesenswert?

> Die Section .text ist die Codegroesse.

Im Prinzip ja, allerdings mußt Du .data noch mit addieren, da ja die
Initialisierungswerte für den RAM auch erstmal durch den ROM müssen.

von Matthias (Gast)


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

von Torsten (Gast)


Lesenswert?

[NEWBIE MODE]
Hmm, das ist eine gute Idee mit dem EEPROM, aber wie bekomme ich die
Daten aus dem Programm in den EEPROM?
[/NEWBIE]

MfG Torsten

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
Noch kein Account? Hier anmelden.