|
Anzeige
|
Unerklärliches Phänomen mit Sub-RoutineHallo an Alle, Ich hab dein Unterprogramm:
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 Sonst keiner eine Idee?
Gast
#572404
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
Gast
#573069
$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 Irgendwie stelle ich gerade gewisse Ähnlichkeiten zwischen Bascom und ASM: Man muß sich um den Stack kümmern. 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
Gast
#574598
>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 Wenn immer nur ein Interupt aktiv ist geht das schon in bestimmten Grenzen zu simulieren...
Gast
#574633
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.
Gast
#575007
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 Antwort schreiben |
Anzeige
|
