ASM UART Interrupt Problem

Hallo,
ich bin zur Zeit dabei einen ATMega328P in Assembler zu programmieren, der anschließend in der Lage sein soll WS2811 Pixel anzusteuern. Die Daten soll er später von Glediator bekommen.

Die eigentliche Datenausgabe an die Pixel funktioniert auch soweit korrekt. Probleme bereitet mir nun der Datenempfang.

Zu Testzwecken habe ich jetzt ein neuen Codeblock geschrieben, welcher einfach eine LED beim Empfangen eines bestimmten Zeichens (hier "d") einschaltet. Wird irgendein anderes Zeichen gesendet so soll die LED wieder ausgehen.

Packe ich das ganze in die Main-Loop passiert folgendes:
Der µC reagiert, so wie ich das sehe immer auf das vorletzte Zeichen was gesendet wurde, also sende ich per Terminalprog z.B. ein "s" & "d" so passiert erstmal nichts. Erst wenn ich ein weiteres Zeichen sende geht die LED an, abhängig davon, ob dieses Zeichen ein "d" war, bleibt die LED bei einem weiteren Zeichen an oder geht aus.

Aber eigentlich soll der Datenempfang bzw deren Verarbeitung per Interrupt ablaufen. Wenn ich nun die Routine aus der Main- Loop lösche und nur bei einem Rx- Complete-Interupt anspringe, ist es so, dass die LED quasi die ganze Zeit aus ist. Erst wenn ich eine Taste gedrückt halte, also Daten ununterbrochen gesendet werden, so flackert die LED. Dabei scheint es auch nicht zu interessieren, ob ich "d" oder eine andere Taste gedrückt halte.
Daraus schließe ich schonmal, dass die ISR immerhin angespringen wird bzw der Interrupt auslöst

Hier erstmal mein Code um das ganze etwas zu veranschaulichen:
Die Block sieht folgendermaßen aus:

Main:
cpi temp0,100			;ist temp0="d"?
brne ledaus				;nein,also springen
sbi LED_Port,Test_Pin	;led an
rjmp Main
ledaus:
cbi LED_Port,Test_Pin	;led aus


rjmp Main

Die ISR sieht dan folgendermaßen aus:

SUB_Byte_received:


		push	temp0						; Register sichern
		in		temp0, SREG
		push	temp0


lds temp0,UDR0	;hole Daten


cpi temp0,100			;ist temp0="d"?
brne ledaus				;nein,also springen
sbi LED_Port,Test_Pin	;led an
rjmp weiter
ledaus:
cbi LED_Port,Test_Pin	;led aus


weiter:


		pop		temp0    	;Register wiederherstellen
		out		SREG, temp0
		pop		temp0


		reti

Es wäre nett wenn mich jemand aufklären könnte was ich falsch mache. Denn wenn selbst sowas simples nicht funktioniert, brauche ich mir über komplexere Sachen gar keine Gedanken machen. Falls noch weitere Dinge zur Aufklärung benötigt werden liefer ich die gerne nach.

Ach so zu sagen wäre noch, dass der µC mit 16MHz läuft und UART für den Moment auf 9600 Baud, 8Bit, 1 Stoppbit, No Parity eingestellt ist.

Vielen lieben Dnak schonmal

Moin erstmal,

Zitat

also wie jetzt, wenn ich das richtig sehe, wertest Du das empfangene Byte 2x aus...

Nein, das mache ich nicht. Der Einfachheit halber habe ich es erstmal ohne Interrupt versucht. Also besteht mein Programm im Prinzip nur aus meinem ersten eingefügten Codeblock (+ Register- Def. usw). Dies führt, wie erklärt zur verzögerten Ausgabe der empfangenen Daten.

Anschließend habe ich den Teil aus der Main-Loop ausgeschnitten und in eine Sub gepackt, die von der ISR angesprungen wird.

Zitat

darf ich aufgrund des Schriftsatzes richtig vermuten, dass der Teil aus irgendner SW von mir kopiert ist...?

Ja und nein. Ich muss dazu sagen, dass das mein erstes richtiges Projekt in Assembler ist. (Hatte aber letztes Semester ein Labor an der Uni in welchem die Grundlagen gelehrt, gelernt und angewendet wurden) Daher habe mich erstmal umgeschaut und bin dann ,wie du ja schon richtig vermutet hast, auf deine SW gestoßen. Daraus habe ich aber nichts sinnlos kopiert, sondern nur den "Stil" übernommen, da ich ihn für sehr übersichtlich und nachvollziehbar halte (was bei Assembler meiner Meinung nach recht schwierig ist).

Zitat

Frage: ist das nur kopiert, oder weißt Du, was das macht....?

Siehe oben und ich denke zumindest, dass ich weiß, was ich da tue
Wobei ich glaube, dass ich in diesem einfachen Fall auch darauf verzichten könnte die Register zu sichern, da das Programm im Moment nur aus einer leeren Main-Loop und dem Rx- Complete- Interrupt (aka SUB_Byte_received) besteht, also die Register woanders gar nicht verwendet werden.

Zitat

... nur, dann passiert folgendes: Du hast Dein empfangenes Byte in temp0,
anschließend holst Du per pop wieder vom Stack den Wert, der *vorher* in
temp0 war, überschreibst also Dein empfangenes Byte!

Grundsätzlich richtig ABER bevor ich temp0 wieder vom Stack hole, werte ich es ja in der ISR direkt aus, von daher sehe ich da eigentlich kein Problem.

Und die von dir verlinkte SW kenne ich schon (mit DMX-, wie auch tmp2- Empfang)- wie gesagt sind die Teil meines Wissensfundaments, auf das ich versuche aufzubauen. Sofern ich das bestehende Problem gelöst bekomme, sieht mein nächster Schritt erstmal so aus, dass ich versuchen werde das "Glediator-Protokoll" zu implementieren. Das ist dann doch einfacher als tmp2 (wenn auch Fehleranfälliger, denke ich). Mir geht es halt nicht primär um das Endergebnis, sondern darum was zu lernen/ Gelerntes anzuwenden.

btw der Vorschlag mit den "2- Klassen- Registern" ist sehr gut, den werde ich sicherlich, wenn es etwas komplexer wird, beherzigen.

Schönen Sonntag noch
drs

Ok, dann nochmal alles auf Anfang:

Also ersteinmal Variante A mit UART- Abfrage in der Main-Loop. Diese Variante entspricht der angehängten Datei mit der Ausnahme, das die "SUB_Byte_received" leer ist. Brenne ich dieses Programm nun auf den Chip passiert das oben schon beschriebene:

Zitat

Der µC reagiert, so wie ich das sehe immer auf das vorletzte Zeichen was
gesendet wurde, also sende ich per Terminalprog z.B. ein "s" & "d"
so passiert erstmal nichts. Erst wenn ich ein weiteres Zeichen sende
geht die LED an, abhängig davon, ob dieses Zeichen ein "d" war, bleibt
die LED bei einem weiteren Zeichen an oder geht aus.

So und weiter mit Variante B. Hier habe ich folgende Veränderungen vorgenommen:
- in der "Interrupt.inc" das zu Rx-Complete gehörende "reti" durch "rjmp SUB_Byte_received" ersetzt
- der Inhalt der Main- Loop besteht nur noch aus einem nop- Befehl
- "SUB_Byte_received" sieht nun so aus, wie in der .txt

Bei dieser Variante tut sich nun gar nichts mehr... Die LED bleibt dauerhaft aus.