Programm hängt, evtl stack Overflow

[Christoph (Gast)]

Hallo,
ich arbeite mit Bascom und habe gerade ein Problem.
Mein Programm hängt sich nach ca. 3-10 Sekunden auf.
Es sind SEHR viele Variablen und Gosubs.

Wenn die Hauptschleife durchläuft (nach ca. 4 Durchläufen) macht der µC 
Nichts mehr.

Wie kann ich einen Stack Overflow erkennen?

Wenn ich Framesize erhöhe, läuft das Programm etwas länger, ohne sich 
auf zu hängen.

Benutzt wird ein mega32.

Habe ich das überhaupt richtig verstanden?:

SRAM = 1kbyte
jetzt kann ich das auf
$swstack, $hwstack und §framesize
verteilen.

Kann ich das so aufteilen, dass der SRAM dann Nichts mehr Frei hat?
Etwas so: swstack = 500, hwstack = 300, framesize = 200. Rest ist dann 
ja quasi = 0.
Kann man das so machen, oder wird der SRAM noch für irgendetwas 
gebraucht?

lg Chr.

[Christoph (Gast)]

Frage 2.
Habe schon etwas gegoogelt, aber nicht das Passende gufunden.
Was ist/ Wie funktioniert die "real Harware Simulation" in Bascom?

Wenn man ein recht komplexes Programm hat, wo viele Unterprogramme sind, 
Interrupts kommen, Variablen gesetzt/gelöscht werden, kann sich schnell 
ein Fehler einschleichen.
Diesen findet man nicht so schnell, bzw. gar nicht. (je nach dem wie gut 
man den Code kennt usw.)
Wie sucht man am Besten nach solchen Fehlern?
Am besten wäre ja so eine Umgebung, wo du sehen kannst, wo dein Programm 
sich gerade befindet, und was dort passiert. Und zwar in "Echtzeit" auf 
dem µC.

Gruss Chr.

[Udo S. (urschmitt)]

Christoph schrieb:
> Diesen findet man nicht so schnell, bzw. gar nicht. (je nach dem wie gut
> man den Code kennt usw.)
Ist doch dein Code oder?

Christoph schrieb:
> Wie sucht man am Besten nach solchen Fehlern?
Wenn man keinen Debugger hat dann Programm stückweise abstrippen bis der 
Fehler nicht mehr auftaucht. So eingrenzen welches Teilmodul 
verantwortlich ist und das mit einem Minimalprogramm testen.

Christoph schrieb:
> Am besten wäre ja so eine Umgebung, wo du sehen kannst, wo dein Programm
> sich gerade befindet, und was dort passiert.
Nennt sich Debugger / Simulator

Christoph schrieb:
> Und zwar in "Echtzeit" auf dem µC.
Nennt sich Emulator, wirst du nicht bezahlen wollen.

[Peter D. (peda)]

Christoph schrieb:
> Es sind SEHR viele Variablen und Gosubs.

Gosubs (Funktionen) sind gut, deuten auf modulare Programierung hin. Der 
Stackverbrauch ist vernachlässigbar.

Wenn viele Variablen, sollte man überlegen, ob diese nur lokal in einer 
Funktion benötigt werden. Lokale Variablen sind gut (vorausgesetzt, 
Bascom unterstütz sie).
Viele globale Variablen sind böse und machen das Programm 
unübersichtlich.


Christoph schrieb:
> Wie kann ich einen Stack Overflow erkennen?

Keine Ahnung, wie das in Bascom geht. Sagt das Manual nichts dazu?


Christoph schrieb:
> SRAM = 1kbyte
> jetzt kann ich das auf
> $swstack, $hwstack und §framesize
> verteilen.

Sollte auch im Manual stehen, wie das geht.


Peter

[mue-c (Gast)]

Peter Dannegger schrieb:
> Der Stackverbrauch ist vernachlässigbar.

Das gilt natürlich nur so lange, wie die Subs sich nicht gegenseitig 
immer wieder aufrufen. Dann liegen die Rücksprungadressen alle im 
HWStack und der kann dann überlaufen.

> Lokale Variablen sind gut (vorausgesetzt, Bascom unterstütz sie).

Da sie von Bascom im Frame gelagert werden, kann es sein, dass hier ein 
erhöhter Bedarf besteht. Speziell, wenn dies mit den sich gegenseitig 
aufrufenden Subs zusammenkommt.

In Bascom gibt es verschiedene Funktionen, die die Überprüfung auf 
Überlauf unterstützen. Schau dir mal STCheck, $dbg usw. an.

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

Christoph schrieb:
> Mein Programm hängt sich nach ca. 3-10 Sekunden auf.
> :
> Wenn die Hauptschleife durchläuft (nach ca. 4 Durchläufen) macht der µC
> Nichts mehr
Was ist das für eine Monster-Hauptschleife, die pro Sekunde gerade 1 mal 
durchlaufen wird?  :-o

[Udo S. (urschmitt)]

Lothar Miller schrieb:
> Was ist das für eine Monster-Hauptschleife, die pro Sekunde gerade 1 mal
> durchlaufen wird?  :-o
Warum, der eine oder andere Sleep; Kennt man doch :-))

@TO:
Mach dir mal eine Tabelle welche Funktion welche aufruft und prüfe mal 
ob es da Zyklen gibt (a ruft b auf, b ruft c auf und c ruft wieder a 
auf)
Dann kennst du dein Problem.