[gelöst] Speicherplatz eines .hex Files auf dem Microcontroller

Dominique S. OP #3834429
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!
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Phil Gast #3834458
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Dominique S. OP #3834477
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Falk B. #3834485
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!
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Holger L. #3834531
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Ralf Gast #3834543
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
npn Gast #3834545
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Holger L. #3834554
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 ?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
npn Gast #3834556
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"). :-))
Antwort Zitieren Bearbeiten Löschen Beitrag melden
npn Gast #3834574
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? :-)
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren