mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVR: Rücksprung aus Unterprogramm geht nicht


Autor: Thomas R. (automatenmann)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht 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

Autor: johnny.m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Du den Stack nicht initialisierst, dann kann es nicht
funktionieren. Du musst am Programmanfang den Stack Pointer
initialisieren, und wie das geht steht im Datenblatt des Controllers.

Autor: johnny.m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, und abgesehen davon macht dieses Programm überhaupt keinen Sinn.
Was willst Du damit erreichen? Oder testest Du nur den Simulator?

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das klappt auch mit Stack nicht, da wenn "START" durch ist ein RET
ohne passenden CALL ausgeführt wird.

Autor: johnny.m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist richtig. Es fehlt eine Schleife am Ende.

Autor: Thomas R. (automatenmann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ johnny.m

klar macht das Programm keinen Sinn, da ich zum Testen Programmteile
entfernt habe. Hab ich aber eigentlich geschrieben!

Thomas

Autor: johnny.m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja dann schick doch gleich den kompletten Code! Dann kann man sich
nämlich die ganzen Vermutungen und ne Menge Zeit sparen. Warum denkt da
eigentlich keiner dran?

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: D. W. (dave) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube ja.

Autor: Thomas R. (automatenmann)
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: Qwerty (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: inoffizieller WM-Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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).

Autor: johnny.m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal ein aktuelles Beispiel, wozu eine "Reduktion auf das
Wesentliche" führen kann:

http://www.mikrocontroller.net/forum/read-1-394936.html

Autor: Karl heinz Buchegger (kbucheg)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Qwerty (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Qwerty (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Karl Heinz: Volle Zustimmung (mein Posting bezog sich auf die beiden
davor)!

Autor: Christoph Wagner (christoph)
Datum:

Bewertung
0 lesenswert
nicht 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).

Autor: Christoph Wagner (christoph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holla !!! Um zwei auf Submit geklickt und bis jetz hats gedauert ! Kennt
ihr das auch ? WLAN will nich, obwohl man "verbunden" is. Auf jeden
Fall sollte der Beitrag zwischen denen von 13:58 und 13:59 rein.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mitn 8051 wär das nicht passiert.

Die Intel-Leute hatten nämlich mitgedacht: "Mensch da setzen wir doch
den SP einfach auf ne gültige Adresse nachm Reset".

Aber der AVR wurde ja viel später entwickelt und da wäre es doch total
uncool, alte Erfahrungen zu nutzen.


Peter

Autor: Karl heinz Buchegger (kbucheg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
:-)
Zumal der SP bei 1 Million AVRs wahrscheinlich mindestens
999999 mal gleich initialisiert wird.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.