Keil Stack-Heap Größe STM32Fxxx

hallo, der Heap hat nix mit Keil oder stm32 zu tun sondern mit dem 
verwendeten OS oder der Implementierung. Der Stack steht im cmsis 
startup.c und ist dort als unsigned long pulStack[size] definiert. Wenn 
du Multithreading verwendest hast du dann zusätzlich für jeden Thread 
einen eigenen Stack.

ok, habe deinen text nicht gut gelesen, also um festzustellen wieviel 
Stack benutzt wurde musst du deinen Stack mit einem Pattern zB. 
0xA5A5A5A5 füllen und das im startup.s im Reset Handler bevor du in die 
erste c Funktion aufrufst und zur Laufzeit überprüfen wieweit dein Stack 
überschrieben oder noch frei ist.
diese Überprüfung solltest nach einer möglichst goßen Codeabdeckung 
machen also die ganze Funktionalitäten ausprobiert worden sind.

KeilBenutzer schrieb:
> Das hilft mir aber nicht weiter, da ich immer noch nicht weiß, ab wann
> ich einen Stackoverflow erleide.

Für den Stack guckst Du in den static call graph, den der Keil als 
HTML-Datei ausgibt, und guckst Dir den Stackbedarf Deiner entry-Funktion 
an (mitsamt Tochterfunktionen). Im Falle von bare metal (also ohne OS) 
ist das main(). Dazu addierst Du noch den Stackbedarf der 
Interruptfunktionen, die ebenfalls in der HTML-Datei stehen.

Obendrein kannst Du damit auch rauskriegen, was den meisten Bedarf 
verursacht. Manchmal kann man eine Funktion mit hohem Stackbedarf auch 
splitten aus zwei Funktionen, die nacheinander aufgerufen werden und für 
sich weniger Stack brauchen. Dann sollte man die aber mit 
Compilerattributen versehen, daß sie nicht inlined werden dürfen.


murx schrieb:
> diese Überprüfung solltest nach einer möglichst goßen Codeabdeckung
> machen also die ganze Funktionalitäten ausprobiert worden sind.

Davon halte ich als alleinige Hauptlösung nichts, weil das nicht 
garantiert, daß der worstcase passiert, nämlich alle Interrupts 
verkettet genau an der Stelle, wo die Anwendung auch schon maximalen 
Stack benutzt.

Zum Überprüfen, ob man in der Analyse (s.o.) was vergessen hat, ist das 
aber nützlich, denn das Ausprobieren darf keine höheren Werte als die 
Analyse geben.

Hallo,

danke für die Antworten!

Methode 1: definiertes beschreiben des RAMs hatte ich mir auch schon 
überlegt. Aber ich wollte mir die Mühe ersparen mich im Debug-Memory 
Fenster tot zu suchen :-) Aber nichts für ungut, scheint wohl die 
einzige Möglichkeit zu sein den Heap rauszufinden.

Methode 2: Danke für den Tipp, ich benutze kein RTOS...

Meine HTM-Datei spuckt mir folgendes aus:

1

<H3>Maximum Stack Usage =       4656 bytes + Unknown(Functions without stacksize, Cycles, Untraceable Function Pointers)</H3><H3>

Erst mal sehr schön, leider habe ich eine Menge Interrupt-Funktionen...

Gibts eine ähnliche Möglichkeit auch für den Heap?

Gruß

KeilBenutzer schrieb:

> Erst mal sehr schön, leider habe ich eine Menge Interrupt-Funktionen...

Kein Problem, die einzelnen Funktionen sind ja auch gelistet. Also 
addiert man deren Stackbedarf zum Stackbedarf von main() dazu.

Der Keil-Compiler ist leider ein bißchen blöd, weil er z.B. die 
Software-Floatingpoint-Routinen stackmäßig nicht berechnen kann, obwohl 
das seine eigenen Libraries sind.

> Gibts eine ähnliche Möglichkeit auch für den Heap?

Nein, denn dynamische Allozierung und statische Analyse geht nicht so 
gut zusammen. Bzw. nur dann, wenn man zur Compilezeit schon weiß, 
wieviel man allozieren muß und das nicht erst zur Laufzeit abhängig von 
den Umständen ermittelt wird - dann würde man den Speicher ja gleich 
statisch allozieren.

Das ist einer von mehreren Gründen, wieso die eine Hälfte der Leute hier 
embedded malloc überhaupt nicht verwendet - und auch die andere tut das 
nur unter größtem Bedauern nach Abwägung aller Alternativen und unter 
Berücksichtigung der Fallstricke.