AVR: Rücksprung aus Unterprogramm geht nicht

OP #360328
Lesenswert?
• ▲
▼
Hallo,
hab hier wohl einen Anfängerfehler:

Nachdem ein für den ATMega8 geschriebenes Assembler-Programm nicht so
funktionierte wie es sollte, habe ich Teile entfernt und simuliert. Was
vom Programm übrig ist findet Ihr im Anhang.

Das Problem:
Nach Aufruf des Unterprogramms INIT, welches nur aus dem
Rücksprungbefehl RET besteht, erwarte ich eigentlich, dass das Programm
mit dem zweiten Befehl im Label START fortgeführt wird. Tatsächlich
springt es aber zum ersten Befehl im Label RESET!!!!

Ich versteh nicht warum, wer kann helfen?

Thomas
Angehängte Dateien:
Gast #360335
Lesenswert?
• ▲
▼
> klar macht das Programm keinen Sinn, da ich zum Testen
> Programmteile entfernt habe. Hab ich aber eigentlich geschrieben!

Mit anderen Worten: Du postest Code, der so gar nicht funktionieren
kann und von dem du weißt, daß er Blödsinn ist, und wir sollen jetzt
auf dieser Basis versuchen, zu raten, warum der Code, den du nicht
gepostet hast, nicht funktioniert.
OP #360337
Lesenswert?
• ▲
▼
@ jonny.m
Danke, das mit der Initialisierung des Stackpointer wer die Lösung


@ Rolf Magnus
@ David W.
Der Code macht zwar keinen Sinn, trotzdem muss das Programm durchlaufen
werden! Wegen der fehlenden Stackpointer-Initialisierung tat es das aber
nicht! Wozu soll ich 100 Zeilen posten, wenn 10 Zeilen reichen?
Gast #360338
Lesenswert?
• ▲
▼
Genau! Ich verstehe auch die Aufregung nicht. Üblicherweise wird in
Foren immer "Reduktion auf das Wesentliche" verlangt, und das hast du
getan, indem du den kleinstmöglichen Code-Schnipsel gepostet hast, der
noch laufen sollte, aber den gesuchten Fehler zeigt. Dass der Code dann
u.U. keinen Sinn mehr macht (im Sinne von "nicht mehr die Funktion
erfüllt", nicht im Sinne von "nicht läuft") ist erstmal zweitrangig.
Gast #360339
Lesenswert?
• ▲
▼
>"Reduktion auf das Wesentliche"
Dabei kann es aber auch gut passieren, dass der Fehler mit reduziert
(oder auch eleminiert) wird, oder ganz andere zutage treten.
Wenn der Code sooo geheim ist, dann sollte man nicht hier nach Hilfe
fragen (müssen).
#360341
Lesenswert?
• ▲
▼
Bitte mässigt euch.
Der OP hat ganz klar in seiner Einleitung geschrieben, dass
er den Code abgespeckt hat, und das der abgespeckte Code
immer noch sein Problem zeigt. Er hat auch ganz klar
dazu geschrieben was nicht funktioniert, wie das Ergebnis
seiner Meinung nach aussehen muesste und was statt dessen
passiert.

Ehrlich gesagt: Derartig präzise formulierte Anfragen würde
ich mir öfter wünschen.
Gast #360342
Lesenswert?
• ▲
▼
Falsch verstanden, meine Aussage war: Solange das reduzierte Programm
noch prinzipiell läuft und den Fehler zeigt, ist eine Reduktion
durchaus sinnvoll. Im verlinkten Thread sehe ich kein lauffähiges
Programm mehr, sondern nur einen Codeschnipsel. Es ist unbestritten,
dass dies für eine Fehlersuche oft zu wenig ist.
#360344
Lesenswert?
• ▲
▼
Zum Verständnis : CALL verhält sich wie JMP, speichert jedoch bevor es
springt die Aktuelle Addresse in einen Stapelspeicher, den Stack.
Dieser ist ein einfaches LIFO (Last-In-First-Out) und wächst nach
unten. Das heiß man initialisiert den Stack-Pointer auf das RAM-Ende,
da ein Call die Addresse dort hinschreibt und den Pointer verkleinert,
sodass der nächste Wert DAVOR geschrieben wird.
RET verhält sich auch wie ein Sprung, nur dass er als Ziel den Wert aus
dem Stack zieht. Dabei wird der Stackpointer erhöht und wenn du keinen
Fehler machst läuft alles einwandfrei. Hast du aber solche umherirrende
"CALL" oder "RET" Befehle, können die den Stack soweit
durcheinanderbringen, dass dein Programm irreläuft und anfängt
irgendwohinzuspringen. Dassselbe übrigens auch, wenn der Stackponter
aus dem RAM läuft.
Auch musst du mit PUSH-POP aufpassen. Diese beiden Befehle
Schreiben/Holen) jeweils den obersten Wert im Stack. Äußerst nützlich,
aber auch gefährlich - denn hier passieren die meisten Fehler, die den
Stack zerstören. (nicht bachtete Schleifen, etc.)
SOmit kannst du auch theoretisch unbegrenzt viele Subprogramme
verschachteln - praktisch ist der RAM deine Grenze (Stackgröße).

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren