Alternative Speicheraufteilung bei µC

[Rick (rick)]

Hallo Forum!

Die klassische RAM-Speicheraufteilung (mit C auf dem Mikrocontroller) 
ist ja .data, .bss, Heap und Stack (Bild links).

Das Ganze hat den Nachteil, das der Stack in den Heap oder gar bis in 
die Daten reinlaufen kann. Das passiert auf kleineren Architekturen 
(AVR8) schnell, falls man denkt, man legt mal eben im Unterprogramm ein 
größeres Array an und benutzt dieses. Die Folge sind korrumpierte Daten 
und/oder unerklärliches Programmverhalten bzw. Abstürze.

Nun bin ich (mal wieder) aktuell beim STM32 und bin letztens über eine 
andere Anordnung gestolpert: Stack, .data, .bss und Heap (Bild rechts). 
Nun können der Heap und der Stack zumindest nicht mehr die Daten 
zerstören. Außerdem gibt es i.d.R. einen Hardfault, wenn man versucht 
auf Speicher zuzugreifen, den es nicht gibt. Beim AVR hilft das 
wahrscheinlich nicht so viel, da man auf den niedrigen Adressen in den 
IO-Bereich reinläuft.

Einen (wirklich kleinen) Nachteil sehe ich: Man muß vorher schon wissen, 
wieviel Platz man dem Stack einräumen möchte.

Nun meine Frage: Hat das schon mal jemand längerfristig ausprobiert und 
kann über seine Erfahrungen berichten?
Oder gibt es (echte) Nachteile auf dem ersten Blick, die ich übersehen 
habe?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Rick schrieb:
> Einen (wirklich kleinen) Nachteil sehe ich: Man muß vorher schon wissen,
> wieviel Platz man dem Stack einräumen möchte.
Genau das ist aber bei Architekturen, wo der Speicherplatz knapp ist, 
der eigentliche Knackpunkt. Und ausserdem kann natürlich auch bei deiner 
Speicherkonfiguration der Heap einfach in den Stack (oder vice versa) 
reinlaufen, denn beim Überlauf von xff...ff geht es mit 0 weiter und 
beim Unterlauf von 0 geht es nach xff...ff. Du kannst also mental 
einfach das "obere Ende2 des Speicherbereichs an das "untere Ende" 
anfügen.

Und dann siehst du: beide Speicheranordnungen im Bild sind bis aufs 
i-Tüpfelchen gleich. Lediglich die Startadressen sind anders.

[Rick (rick)]

Lothar M. schrieb:
> Und ausserdem kann natürlich auch bei deiner
> Speicherkonfiguration der Heap einfach in den Stack (oder vice versa)
> reinlaufen,
Für einen AVR o.ä. simmt das, zumindest wenn der Speicher den Adressraum 
2^n komplett füllt. Ich habe aktuell einen STM32 vor mir, der hat noch 
Lücken in der Speicheraufteilung...

[Bauform B. (bauformb)]

Ich lege den Stack schon immer auf die niedrigste Adresse, quasi 
instinktiv. Es scheint zu funktionieren ;)

Allerdings kann man mit der MPU auch die klassische Anordnung sicherer 
machen: .data, .bss, Heap, NICHTS, Stack. Man muss ein wenig RAM für 
eine verbotene Zone zwischen Heap und Stack opfern, je nach RAM-Größe 
zwischen 64 Byte und wenigen kByte.

Damit könnte man sogar auf einen Überlauf reagieren, die Grenze zur 
Laufzeit verschieben und das Programm weiter laufen lassen.

Mit der MPU kann man auf die gleiche Art auch einen zweiten Stack 
anlegen, wir haben ja 2 Stackpointer. Und man kann ein XN Bit setzen 
(aka NX, Execute Never).

[Andreas M. (amesser)]

Rick schrieb:
> Einen (wirklich kleinen) Nachteil sehe ich: Man muß vorher schon wissen,
> wieviel Platz man dem Stack einräumen möchte.

Musst Du doch eh wenn Du nicht nach Prinzip Hoffnung verfahren willst. 
Sobald du mit einem RTOS arbeitest geht es gar nicht anders, der 
verlangt beim starten der Task nach einer Angabe für die Stack-Größe 
msit sogar direkt nach Vor-Allokation des Stacks.

Rick schrieb:
> Nun meine Frage: Hat das schon mal jemand längerfristig ausprobiert und
> kann über seine Erfahrungen berichten?

Wir arbeiten hier ausschließlich so. Man kann so auch die Performance 
optimieren indem man z.B. den Stack auf einen Adressbereich legt auf den 
die ARM parallel zum "normalen" Hauptspeicher zugreifen kann. Z.b. ins 
DTCM. Manchmal ist ein und derselbe physikalischen Speicher auch über 
unterschiedliche Busports via unterschiedlichen logischen Adressen 
erreichbar. Das bietet ebenfalls Optimierungspotential.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Rick schrieb:
> einen STM32 vor mir, der hat noch Lücken in der Speicheraufteilung...
Hilft dann auch nur, wenn diese Lücken im Adressraum tatsächlich auch 
mit pyhsikalischem Speicher gefüllt sind.

[Rainer W. (rawi)]

Rick schrieb:
> Speicheraufteilung.pdf

Warum diese Transportverpackung?

"Zeichnungen und Screenshots im PNG- oder GIF-Format hochladen"

[Niklas G. (erlkoenig)]

Rainer W. schrieb:
> Warum diese Transportverpackung?

Warum machst du aus der immer perfekt scharfen Vektorgrafik im PDF eine 
verpixelte und größere (!) PNG-Datei?

[Johann L. (gjlayde)]

Rick schrieb:
> Beim AVR hilft das wahrscheinlich nicht so viel,

Neu AVRs (AVR-Sx, AVR-Lx) haben rudimentären hardwarebasierten 
Stackschutz. Siehe CPU_SPLIM.

[Mi N. (msx)]

Rick schrieb:
> Heap und Stack (Bild links).
>
> Das Ganze hat den Nachteil, das der Stack in den Heap oder gar bis in
> die Daten reinlaufen kann.

Ich finde diese Aufteilung genau richtig, da der Speicher für Stack und 
Heap verwendet werden kann. Wenn sich beide Bereiche in die Quere 
kommen, dann ist der Speicher eben zu klein.
Im Prinzip ist es auch egal, ob ich temporären Speicher im Heap 
reserviere und wieder freigebe oder lokale Arrays im Stack landen. Stack 
ist wohl einfacher, sodaß (hier) viele Kollegen mit dem Heap sowieso 
nichts anfangen können.

[Rolf (rolf22)]

Mi N. schrieb:
> Im Prinzip ist es auch egal, ob ich temporären Speicher im Heap
> reserviere und wieder freigebe oder lokale Arrays im Stack landen.

Nicht ganz egal. Im Heap führt es u. U. zu Fragmentierung, im Stack 
nicht. Ist der Heap fragmentiert, dann kann man u. U. nicht mehr allen 
vorhandenen Speicher nutzen.

> Stack ist wohl einfacher, sodaß (hier) viele Kollegen mit dem Heap sowieso
> nichts anfangen können.

Ja, Stack ist viel einfacher, aber beschränkt auf lokale Variablen.

Viele schreiben im C-Stil und nutzen/kennen die C++-Möglichkeiten nicht. 
Und in C ist die Heap-Speicherverwaltung bekanntlich problematisch 
(Buffer overflow, dangling pointer, fehlendes Destruct() nach Exceptions 
und anderes), sodass mancher vorsichtshalber die Finger davon lässt.
In C++ ist das alles einfacher.

[Rainer W. (rawi)]

Niklas G. schrieb:
> Warum machst du aus der immer perfekt scharfen Vektorgrafik im PDF eine
> verpixelte und größere (!) PNG-Datei?

Geht es dir um den Inhalt oder um die Eleganz und Universalität der 
Graphik?
Gegen die perfekte Vektorgraphik an sich spricht nicht, ist hier aber 
eher ein akademischer Vorteil.
Dank der Verpackung funktioniert die Voransicht im Forum nicht, weil die 
Software das anscheinend nicht unterstützt, und macht den Beitrag 
unnötig schwer lesbar.

Bei der von mir gewählten Größe der Graphik ist von "verpixelt" nichts 
zu sehen, solange man nicht auf eine akademische, völlig praxisfremde 
Vergrößerung reinzoom. Da die Information, die die Graphik bietet, 
genauso gut in 10 Textzeilen passt, ist ein weitere Reinzoomen 
überflüssig.

An den zusätzlichen 27 kByte wird das Forum nicht ersticken, da gibt es 
ganz andere, inhaltslosere Anhänge, für die man hunderte von diesen 
hochladen könnte. Die zehn Textzeilen wären vom Speicherbedarf deutlich 
sparsamer als die Vektorgraphik ;-)