Hi,
gibt es eine verlässliche Möglichkeit herauszubekommen wie viel Platz
ein .hex file auf dem Mikrocontroller benötigen wird ohne es via avrdude
hochzuladen?
----
Die Lösung kommt mit der AVR-Suite:
1
# avr-size main.hex
----
Hintergrund der Frage:
Wenn ich ein .hex File über die winavr Suite kompiliere ist das .hex
File auf der Festplatte größer als der Platz der später auf dem AVR
Mikrocontroller benötigt wird. Es scheint ca. 2 Mal so groß zu sein,
aber nicht immer und nicht exakt 2x.
Ich habe jetzt ein Projekt was ich auf den ATMega328p portiere und
bisher ist das .hex File zu groß für den Mikrocontroller, d.h. ich bin
dabei den Code zu optimieren. Dabei ständig ein Upload auf den
Mikrocontroller zu versuchen ist mehr als lästig und kann dem Flash
Speicher nicht wirklich gut tun.
Danke im Voraus!
Dominique S. schrieb:> gibt es eine verlässliche Möglichkeit herauszubekommen wie viel Platz> ein .hex file auf dem Mikrocontroller benötigen wird ohne es via avrdude> hochzuladen?
ja.
Wandle es in ein binary file um. Hex2Bin
Hi Dominique S,
Mit AVR dude kompillierst du nicht!!!!
Das Prog ist nur zum hochladen deines Hex-Files auf die MCU.
http://www.mikrocontroller.net/articles/AVRDUDE
In welcher Umgebung (i.e. AVR Studio, etc) schreibts du deinen Code? Du
solltest mal in die Ausgabe deines Compillers gucken, da steht wieviel
Speicherplatz die hex auf deinem Target benötigt.
Meist sogar in prozent vom ausgewählten Microcontroller-Typ.
MFG
Philipp
Dominique S. schrieb:> Zeigt dir deine Compiler-Ausgabe nicht an wie groß das Programm ist?
nein, weil das auch nicht die Aufgabe von Compiler ist. Eventuell hat
sich jemand die Mühe gemacht es noch im makeprozess mit auszugeben.
@ Dominique S. (mronak)
>gibt es eine verlässliche Möglichkeit herauszubekommen wie viel Platz>ein .hex file auf dem Mikrocontroller benötigen wird ohne es via avrdude>hochzuladen?
Ja. Durch 2,6875 dividieren.
Denn die .ex Dateien sind im Intel-hex format abgespeichert, wobei meist
pro Zeile 16 Byte gespeichert werden. Das Format ist menschenlesbar in
ASCII, d.h. 1 Byte Im Flash wird als 2 ASCII Zeichen kodiert. Dazu kommt
pro Zeile noch eine Prüfsumme (2 zeichen) + 9 Zeichen für die
Kopfinformation pro Zeile. Macht 43/16=2,6875.
>Ich habe jetzt ein Projekt was ich auf den ATMega328p portiere und>bisher ist das .hex File zu groß für den Mikrocontroller, d.h. ich bin>dabei den Code zu optimieren.AVR-Studio zeigt dir nach jedem Compilerlauf die Größe deines
Flashspeichers + EEPROM + RAM EXAKT an!
Phil schrieb:> Hi Dominique S,> Mit AVR dude kompillierst du nicht!!!!
Äh... ja :D. WinAVR... d.h. avr-gcc als compiler, avr-objcopy etc...
Sorry... ich brauch mehr Kaffee.
Ich wusel mal etwas mehr durch's make file und melde mich ggf noch mal.
Danke schon mal an alle.
Ok... das war relativ einfach:
# avr-size main.hex
Übrigens @Falk Brunner: Die Rechnung kann ich nachvollziehen, aber die
Flashgröße ist eine andere, nah dran aber nicht 100%.
:1000000009C016C015C014C013C012C011C010C062
:100010000FC00EC011241FBECFE9CDBF20E0A0E667
:10002000B0E001C01D92A836B207E1F702D06BC064
:10003000E7CF82E087BBC1983AD0C0E08C2F4ED08A
:100040008130B1F4C19A87E99AE30197F1F700C0D2
:100050000000C19887E99AE30197F1F700C000001A
:10006000C19A87E99AE30197F1F700C00000C198AF
:1000700023D080916700813079F4809160008130D5
:1000800059F4CF5FC83009F4C0E0C19A8FE59AEE09
:100090000197F1F700C00000C1989FEB24ED81E0CB
:1000A000915020408040E1F700C00000C7CF87B3E7
:1000B000856087BBC09A0895C298C29AE7E6F0E0CF
:1000C00081E0B49B02C0808301C01082C098C09AB6
:1000D000319790E0EF35F907A1F70895482FC298BE
:1000E000C29A27E030E080E0552747FD509524175D
:1000F000350744F086B382958170C098C09A21502C
:0A0100003109F5CF0895F894FFCF00
:00000001FF
Die ersten zwei Zeichen nach dem Doppelpunkt geben die länge der Zeile
an.
Die beträgt im normalfall 16.
Die nachfolgenden 3 (oder 4?) die Zeilenanzahl.
Daraus ergibt sich aus der vorletzten Zeile:
0A = Dezimal 10 // letzte Zeile
10 = Dezimal 16 // Anzahl volle Zeilen mit 16 multiplizieren da diese
immer 16 lang sind.
10 + (16 * 16) = 266 // Letzte Zeile + alle vorherigen
:LLAAAATTDD...DDCC
LL = Anzahl der Nutzdaten in der Zeile
AAAA = Adresse (im Speicher)
DD = Nutzdaten
TT = Record Type der Zeile (*)
00: Daten
01: EndOfFile
CC = neg. Prüfsumme
* I.d.R. begegnet man nur den Typen 00 und 01, die anderen sind für
Daten >64k etc vorgesehen.
Ralf
Holger L. schrieb:> :1000E000C29A27E030E080E0552747FD509524175D> :1000F000350744F086B382958170C098C09A21502C> :0A0100003109F5CF0895F894FFCF00> :00000001FF>> Die ersten zwei Zeichen nach dem Doppelpunkt geben die länge der Zeile> an.> Die beträgt im normalfall 16.> Die nachfolgenden 3 (oder 4?) die Zeilenanzahl.
4 Zeichen sind es. Und es ist nicht die Zeilenzahl, sondern die Adresse,
wo die Daten hin sollen.
Danach kommt noch ein Byte für den Record-Typ und dann beginnen erst die
Nutz-Daten.
>> Daraus ergibt sich aus der vorletzten Zeile:>> 0A = 10 // letzte Zeile> 10 = 16 // Anzahl volle Zeilen mit 16 multiplizieren da diese immer 16> lang sind.>> 10 + (16 * 16) = 266 // Letzte Zeile + alle vorherigen
Ganz unten den EOF-Record (01) mit der Prüfsumme (FF) hast du noch
vergessen.
Ralf schrieb:> :LLAAAATTDD...DDCC> LL = Anzahl der Nutzdaten in der Zeile> AAAA = Adresse (im Speicher)> DD = Nutzdaten> TT = Record Type der Zeile (*)> 00: Daten> 01: EndOfFile> CC = neg. Prüfsumme
Das ist natürlich erheblich eleganter ausgedrückt.
npn schrieb:> Ganz unten den EOF-Record (01) mit der Prüfsumme (FF) hast du noch> vergessen.
Laut AtmelStudio kommen genau
"Program Memory Usage : 266 bytes 26,0 % Full"
dabei heraus, ist natürlich die Frage ob die Berechnung falsch ist oder
ob die letzte Zeile nicht zählt ?
Holger L. schrieb:> Ralf schrieb:>> :LLAAAATTDD...DDCC>> LL = Anzahl der Nutzdaten in der Zeile>> AAAA = Adresse (im Speicher)>> DD = Nutzdaten>> TT = Record Type der Zeile (*)>> 00: Daten>> 01: EndOfFile>> CC = neg. Prüfsumme>> Das ist natürlich erheblich eleganter ausgedrückt.>> npn schrieb:>> Ganz unten den EOF-Record (01) mit der Prüfsumme (FF) hast du noch>> vergessen.>> Laut AtmelStudio kommen genau> "Program Memory Usage : 266 bytes 26,0 % Full"> dabei heraus, ist natürlich die Frage ob die Berechnung falsch ist oder> ob die letzte Zeile nicht zählt ?
Achso, okay. Mein Fehler. Die Prüfsumme kommt natürlich nicht in den
Controller, wird also nicht mitgezählt.
Aber das obige, der Aufbau der Zeilen, das hattest du falsch
geschrieben. Schau dir mal die Beschreibung von Ralf an und auch meine
und vergleich dann mit deinen Erläuterungen. Da sind paar Fehler drin,
die Ralf und ich richtiggestellt haben (nicht nur "eleganter
ausgedrückt"). :-))
Ja, ist ja richtig.
Aber solange er keinen Bootloader benutzt sind die fortlaufend
nummeriert, und um auf die schnelle die Größe zu ermitteln ist es
eigentlich optimal.
Holger L. schrieb:> Ja, ist ja richtig.> Aber solange er keinen Bootloader benutzt sind die fortlaufend> nummeriert, und um auf die schnelle die Größe zu ermitteln ist es> eigentlich optimal.
Versteh mich bitte nicht falsch. Ich habe ja nicht gesagt, daß deine
Berechnung falsch ist. Nur die Bedeutung einiger Bytes. Okay? :-)
