Forum: Compiler & IDEs [gelöst] Speicherplatz eines .hex Files auf dem Microcontroller


von Dominique S. (mronak)


Lesenswert?

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!

: Bearbeitet durch User
von Peter II (Gast)


Lesenswert?

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

von 1234599 (Gast)


Lesenswert?

Zeigt dir deine Compiler-Ausgabe nicht an wie groß das Programm ist?

von Phil (Gast)


Lesenswert?

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

von Dominique S. (mronak)


Lesenswert?

1234599 schrieb:
> Zeigt dir deine Compiler-Ausgabe nicht an wie groß das Programm ist?

Leider nein, die Ausgabe von make all ist lediglich das hier:
1
avr-gcc -Wall -Os -mmcu=atmega328p -DF_CPU=16000000 -c main.c -o main.o
2
avr-gcc -Wall -Os -mmcu=atmega328p -DF_CPU=16000000 -c uart/uart.c -o uart/uart.o
3
avr-gcc -Wall -Os -mmcu=atmega328p -DF_CPU=16000000 -c display/display.c -o display/display.o
4
avr-gcc -Wall -Os -mmcu=atmega328p -DF_CPU=16000000 -c keys/keys.c -o keys/keys.o
5
avr-gcc -Wall -Os -mmcu=atmega328p -DF_CPU=16000000 -c utilities/utilities.c -o utilities/utilities.o
6
avr-gcc -Wall -Os -mmcu=atmega328p -DF_CPU=16000000 -c kspio/kspio.c -o kspio/kspio.o
7
avr-gcc -Wall -Os -mmcu=atmega328p -DF_CPU=16000000 -c kspio/millis.c -o kspio/millis.o
8
avr-gcc -Wall -Os -mmcu=atmega328p -DF_CPU=16000000 -c dsky/dsky.c -o dsky/dsky.o
9
avr-gcc -Wall -Os -mmcu=atmega328p -DF_CPU=16000000 main.o uart/uart.o display/display.o keys/keys.o utilities/utilities.o kspio/kspio.o kspio/millis.o dsky/dsky.o -o main.elf
10
avr-objcopy -j .text -j .data -O ihex main.elf main.hex

von Peter II (Gast)


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

@ 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!

von Dominique S. (mronak)


Lesenswert?

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.

von Dominique S. (mronak)


Lesenswert?

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

von Holger L. (max5v)


Lesenswert?

: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

: Bearbeitet durch User
von Ralf (Gast)


Lesenswert?

: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

von npn (Gast)


Lesenswert?

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.

von Holger L. (max5v)


Lesenswert?

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 ?

von npn (Gast)


Lesenswert?

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"). :-))

von Holger L. (max5v)


Lesenswert?

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.

von npn (Gast)


Lesenswert?

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? :-)

von Holger L. (max5v)


Lesenswert?

Kein Problem!
Wenn ich Mist schreibe muß es korrigiert werden das ist ja auch gut so.

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.