Dieses Unterprogramm gibt mir Rätsel auf. Es läuft genau 6x ohne
Probleme durch und ab dem 7. Mal spinnt es. Und zwar wird ab dem 7. Mal
die for-Schleife nur 2x ausgeführt. Warum auch immer.
Hat irgendwer schon ähnliches erlebt? Was kann da sein?
Danke, Andy
Bedeutet "dein" soviel wie "da ein"?
Kann es sein, daß "rfdata" per Call-by-Reference aufgerufen wird und so
gegebenenfalls den übergebenen Parameter (hier "m") ändern kann?
Ja, "dein" sollte "da ein" heißen gg
Nein, rfdata() wird byval aufgerufen. Was ich jetzt aber herausgefunden
haben: Wenn ich anstatt "Print" "Print m" schreibe funktionierts
einwandfrei! Auch nach dem 7. Mal. Natürlich könnte ich jetzt sagen:
Problem gelöst, aber ich würde gern wissen, warum das so ist?
Kann es sein, dass Bascom hier pfuscht??
THX Andy
locale datenstellen werden auf den stapelspeicher abgelegt wenn du den
zu klein eingestellt hast kommen manchmal solche effekte zustande.
$hwstack = 32 ' default
use 32 for the hardware stack
$swstack = 10 ' default
use 10 for the SW stack
$framesize = 40 ' default
use 40 for the frame space
@MR
Vielen Dank für deinen Hinweis. Ich habe diese Werte nun mal geändert
und es scheint wirklich daran zu liegen. Aber es funktioniert noch nicht
100%ig.
Wie weiß ich, welche Werte dort hingehören??
Danke,
Andy
$hwstack = 64 ' default
use 32 for the hardware stack
$swstack = 64 ' default
use 10 for the SW stack
$framesize = 40 ' default
use 40 for the frame space
Rahul Der trollige wrote:
> Irgendwie stelle ich gerade gewisse Ähnlichkeiten zwischen Bascom und> ASM: Man muß sich um den Stack kümmern.
Nö, muß man bei ASM und auch beim AVR-GCC überhaupt nicht.
Der Stack liegt oben, die globalen Daten legt man unten ab.
Und schon isses total wurscht, wie groß der eine oder andere Bereich
ist.
Sie müssen nur zusammen in den SRAM passen.
In Bascom ist die Lage aber bedeutend kritischer, da ja mindestens 4
verschiedene Bereiche angelegt werden.
Es wird also sehr oft passieren, daß in einem Bereich noch massig Luft
ist und dafür ein anderer überläuft.
Man kriegt also Probleme, weit bevor der SRAM voll ist.
Warum man daher so einen Unsinn macht, kann ich nicht nachvollziehen.
Peter
Danke einmal für eure Antworten.
Und was kann ich nun dagegen machen, dass manche Bereiche nicht
überlaufen? Kann man diese irgendwie in gewissen Zeitabständen manuell
leeren??
mfg
Andy
>Nö, muß man bei ASM und auch beim AVR-GCC überhaupt nicht.>Der Stack liegt oben, die globalen Daten legt man unten ab.>Und schon isses total wurscht, wie groß der eine oder andere Bereich>ist.>Sie müssen nur zusammen in den SRAM passen.
Das ist bei Bascom nicht anders, die Daten liegen unten und der Stack
oben. Es gibt bei Bascom nur mehrere Stacks und die kann man in der
Simulation prüfen lassen, ob da irgendeiner überläuft.
@Andreas
Der Stack muß nur groß genug gewählt werden, dann läuft da nichts über.
Lies mal in der Hilfe über den Stack, da steht alles drin.
Gruß
Klaus
Klaus wrote:
> Das ist bei Bascom nicht anders, die Daten liegen unten und der Stack> oben. Es gibt bei Bascom nur mehrere Stacks und die kann man in der> Simulation prüfen lassen, ob da irgendeiner überläuft.
Genau das ist ja der entscheidende Unterschied, Bascom hat 3 Stacks,
Assembler oder AVR-GCC aber nur einen.
Wie man das durch Simulation lösen soll, erklär mir mal.
Wie soll man denn Reaktionen von externen Schaltungen simulieren ?
Auch kannst Du nicht alle möglichen Ablaufvarianten testen (wann schlägt
welcher Interrupt zu).
Peter
Hallo Peter,
da hast du ja Recht. Bei deinem Stack ist es aber nicht anders, wenn der
zu klein gewählt ist, du kannst ja auch nicht alle Ablaufvarianten
testen. Externe Schaltungen und Interrupts kann man schon bis zu einem
gewissen Grad simululieren. Wenn die Software sich ungewöhnlich verhält,
dann werden die Stacks eben etwas erhöht. Ok, ich verlier ein paar Bytes
gegenüber Assembler oder C, aber so dramatisch ist das wohl nicht,
zumindestens nicht im Hobbybereich.
Gruß
Klaus
Hallo,
Irgendwie war das mit dem Stack doch nicht der Fehler! Das Programm
stürzt bei mir in regelmäßigen Abständen ab - bleibt einfach hängen!
Wo könnte da noch eine Fehlerquelle sein??
Danke, Andy
>Nö, muß man bei ASM und auch beim AVR-GCC überhaupt nicht.
Ich meinte damit nur, dass man bei ASM (zumindest bei den
AVR-Assembler-Programmen, die ich bis jetzt gesehen habe), den
Stackpointer "manuell" ans RAM-Ende legen muß - zu Beginn des Programms.
Den Stack zu überwachen ist eigentlich nichts kompliziertes.
1) Einfach bei der µC Initialisierung den RAM mit einem Füllmuster
beschreiben.
zb (0xCAFE)
2) zur Laufzeit immer wieder überprüfen ob die letzten Stackbytes noch
mit dem Füllmuster gefüllt sind. ==> zb Pin XY = Low bei Stack ok; High
bei Stack voll
3) sind auch die letzten Bytes des zugeteilten Stacks überschrieben dann
muss der Stack vergrößert werden.
@Ralph
Danke für die Info. Aber wie macht man das in Bascom?? Hab da keine
Erfahrungen damit!
Kannst du mir da vielleicht ein bisschen helfen??
Danke,
Andy