avr-gcc:Was passiert bei zu vielen Variablen/zu wenig SRAM´?

[vklaffehn]

Hallo!
Mir ist grad was schreckliches passiert :
Ich habe ein Array mit 128 bytes angelegt, und das ganze für meinen ATTiny26 übersetzt, der ja nur 128 bytes SRAM hat, und der compiler hat nichts gemerkt... Da ich noch andere Variablen habe und GCC das SRAM bestimmt auch irgendwie aufteilt (Variablen ab 0x60 aufwärts?), würde das doch bestimmt dazu führen das ich das ganze SRAM mit müll zuschreibe, richtig? Kann der Compiler merken, wenn das SRAM voll ist, oder muß man da selbst drauf achten?
Danke schonmal!!

[uwegw]

Bei aktuellen Versionen wird beim Kompilieren ausgegeben, wie viel Speicher benutzt wird:

AVR Memory Usage:
-----------------
Device: atmega16

Program:    6104 bytes (37.3% Full) //Flash
(.text + .data + .bootloader)

Data:       4833 bytes (472.0% Full) //Sram
(.data + .bss + .noinit)

^^ da hab ich testweise auch mal nen zu großes Array angelegt.
Man muss auch noch beachten, dass vom Stack noch weiterer Speicher benötigt wird.

[SprinterSB]

Kann der Compiler merken, wenn das SRAM voll ist, oder muß man da selbst drauf achten?

Da muss man selbst drauf achten, weil der Compiler nicht die nötigen Informationen dazu hat.

avr-gcc (gcc generell) hat keine Ahnung davon, wie der µC, für den er übersetzt, so ausgestattet ist (RAM, Flash, SFR-Adressen, ...).

Über den Gesamtspeicherverbrauch kann er auch nichts wissen, das könnte bestenfalls der Locator (also avr-ld), der die SRAM-Adressen der Objects festlegt. Aber der meckert auch nicht, auch nicht mit --check-sections

Die Ausgabe von uwegw kommt übrigens von avr-size -C ..., was wohl einige Makefile-Gneratoren automatisch ins Makefile klöppeln.

Eine IRQ, die bei StacK Under- oder Oveflow getriggert wird, felt dem AVR-Core leider. Zur Laufzeit ist es also schwierig, das zu erkennen bzw. sich einen Überblick über den dynamischen RAM-Verbrauch zu machen um planen zu können.

Evtl erreicht man das Meckern des Linkers, indem man im Linker Script File eine Section unmittelbar nach .data (evtl auch .bss oder .noinit) definiert, die sich bei Überschreiten der SRAM-Kapazität dann mit der lezten SRAM-Section überlappen würde.

Aber selbst wenn er meckert, dann er immer noch nicht wissen, was zu Laufzeut auf dem Stack und dem Heap abgeht.

https://www.roboternetz.de/wissen/in...en_mit_avr-gcc

Bild hier