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.
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.
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.
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
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.
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
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.
