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.