Codegrösse?

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

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?

Kurze Antwort: RTFM.

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

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

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

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

-> Avr-gcc rulez :-)

MfG Torsten

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

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

Hi

RTFM. Das steht in der AVRLibc-Doku.

Matthias

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

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

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

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

[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