Speicherplatzbelegung in einem Atmega32

[robocat]

Hallo liebe Bastler,
mir ist irgendwie nicht ganz klar, wieviel Flash- und SRAM-Speicher mein Programm belegt. Ich programmiere mit PN2, kompiliere mit WinAVR und schreibe die HEX Datei mit PonyProg (kein Bootloader).
Beispiel:
Die HEX Datei ist 16.275 Bytes gross (rechtsklick Eigenschaften in Windows). Beim kompilieren schreibt mir WinAVR:

Size after:
bla.elf :
section size addr
.text 5668 0
.data 110 8388704
.bss 145 8388814
.debug_aranges 128 0
.debug_pubnames 596 0
.debug_info 4467 0
.debug_abbrev 1434 0
.debug_line 2802 0
.debug_frame 352 0
.debug_str 1174 0
.debug_loc 1065 0
Total 17941

Nun bin ich zum einen erstaunt, denn das Programm ist noch gar nicht so riesengross; Wenn PonyProg schreibt, scheint es auch nur 15-20% des Gesamtspeichers zu belegen.

Zum anderen ist vor Allem die SRAM Belegung interessant, denn es wird eine Art Datenlogger, und je mehr Daten ich loggen kann, desto schön. Das Problem ist, weder PonyProg noch WinAVR scheint mir mitzuteilen, wenn ich zuviel FLASH oder SRAM belege. Mir ist es schon passiert, dass ich mit "zuviel" einen Atmega unbrauchbar gemacht habe, zumindest schien das so zu sein. Auch hatte ich schon merkwürdiges Programmverhalten, wenn zuviel FLASH belegt war. Pony meldet zwar "Write sucessful" aber das Programm funktioniert nicht mehr richtig; wenn man dann ein paar Bytes kürzer codet, geht es wieder problemlos.

Lange Story kurzer Sinn:
Könnte mir jemand der da durchsteigt mal erklären, wie ich die Speicherbelegung bzw freies FLASH- und SRAM irgendwie ermitteln kann, idealerweise aufs Byte genau, und ohne alle meine Variablen in Handarbeit zusammenzurechnen?

Herzlichen Dank schon im vorraus,
Eure Katze

[dremler]

Hm ich vermute, deine große Hexdatei besteht zu einem großen Teil aus FF, das wird aber als "freier" Speicher gerechnet. Für den AVR ist FF natürlich freier Speicher*vermute ich*

[PicNick]

@Katzerl: Das HEX Format ist der Code in HEX-ASCII mit allem möglichen Zeugs dazu. (Mach mal mit Notepad auf). Das zählt nicht.
Ich glaub, die BIN file zeigt was realistisches.

[robocat]

Danke für eure Antworten. Also das HEX-File selbst gibt schon mal wenig Auskunft, das sehe ich nun ein.
Wenn ich 20 Byte mehr reserviere, vergrössert sich der Wert in der Zeile

.bss 145 8388814

ebenfalls um 20 Byte. Das scheint also was mit der SRAM Belegung zu tun zu haben.

Die Zeile

.data 110 8388704

da weiss ich nicht so recht, was das ist.

Und ".text" - ist das bytegenau die Größe meiner FLASH Belegung?

Sorry wenn ich mich dumm anstelle, aber ich möchte das endlich mal wissen.

[PicNick]

DIe Sache ist so (soweit ich weiss):

Size after:
bla.elf :
section size addr
.text 5668 0 -------------------------- Flash (programm) 5668 Bytes
.data 110 8388704-------------------- SRAM Variable 110 Bytes von dir irgendwo definiert
.bss 145 8388814--------------------- SRAM Variable 145 Bytes , die vom compiler initialisiert werden

Also 255 Bytes SRAM, 5668 Bytes FLASH

[sternst]

DIe Sache ist so (soweit ich weiss):

Fast.

Flash = .text + .data
SRAM = .data + .bss + in der Auflistung nicht angezeigten dynamischen Verbrauch

[robocat]

Vielen Dank, das hilft mir schon um einiges weiter
Mit dynamischem Verbrauch ist Speicher gemeint, den ich mit alloc oder ähnlichem dynamisch reserviere und freigebe?

[PicNick]

Jupp, aber auch der Stack knabbert am SRAM