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
> 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
"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
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
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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.