Drehencoder auslesen ASM

[Jürgen W. (juergen_w)]

Das ASM-Programm im Anhang liest einen Drehencoder im Timerinterrupt 
aus.
Habe das Programm mal hochgeladen, da ich als ich hier suchte, nur 
Lösungen in C fand.

Viel Spass damit, Jürgen

[Simon K. (simon)]

Immerhin nicht wieder der typische Quatsch mit Auswertung im externen 
Interrupt, sondern per Polling.

Aber sicher, dass es hier noch nichts in Asm gibt? Aber wenns geht ist 
ja gut.

[Schnelldreher (Gast)]

Funktioniert prima und ist sogar verständlich.

Danke

[Chris S. (Firma: hier&da) (keiningenieur)]

Hallo, etwas lange her aber der Quellcode ist genau das, so wie ich es 
mir vorgstellt habe. Saubere Arbeit!

Es ist ein einfaches den Code nur zu übernehmen ohne die Funktion zu 
verstehen. Aber genau das würde ich gerne.
In meinen Quellcode habe ich zwischen Zeile 28 und 29 noch 2x LSR 
eingefügt, damit man andere Pins ebenso nutzen kann, funktioniert.

Vom Prinzip:
0. Timer CTC ca. 1ms OCA0A_INT aktivieren
1. AltZustand laden
2. Neuzustand lesen
3. verUNDen mit 3 um Altwert zu erhalten und sichern
4. Vergleich NEU/ALT auf Gleichheit wenn ja Abbruch sonst weiter
5. SWAPPEN und ODERN um beides zusammenzufassen
6. Auswertung

Das was mir aber Kopf zerbrechen bereitet ist SWAP Befehl und die 
jeweiligen Ergebnisse, sprich wie kommt man auf die Vergleichswerte in 
Zeile 38/40/42/44? Also das die aus dem SWAP/ODER kommen ist 
nachvollziehbar aber wie passt das zur vorherigen Überlegung die man ja 
erstmal anstellte ?

Nachtrag: 19:38
cpi      temp0,$23     ;von 10(2) nach 11(3)
cpi     temp0,$31        ;von 11(3) nach 01(1)
cpi      temp0,$10        ;von 01(1) nach 00(0)
cpi      temp0,$02        ;von 00(0) nach 10(2)

habs erkannt wie Jürgen sich das gedacht hat. Kann nur sagen Top Sache

[Michael B. (laberkopp)]

Chris S. schrieb:
> Das was mir aber Kopf zerbrechen bereitet ist SWAP Befehl

Der ist ja auch etwas ungünstig, das Ergebnis nutzt bit 0 und bit 1 und 
bit 4 und bit 5.

Einfacher wäre 2 x shift left, dann nutzt man bit 0, bit 1, bit 2 und 
bit 3 und kann den ganzen Vergleichskram durch einen Tabellenzugriff 
ersetzen

in r16, pinb ; pb0 und pb1 incrementaleingänge
andi r16, 3
or r16, old
ldi ZL, lo8(table)
ldi ZH, hi8(table)
add ZL, r16
adc ZH, r0          
lpm r17, Z ; r17 enthält nun was auf die aktuelle position zu addieren ist
lsl r16
lsl r16
sts old, r16
...
...
.section .progmem.data
.type table, @object
.size table, 16
table:
.byte 0,1,-1,0,-1,0,0,1,1,0,0,-1,0,-1,1,0

https://dse-faq.elektronik-kompendium.de/dse-faq.htm#F.29

[Yalu X. (yalu) (Moderator)]

Die beiden Encodersignale durchlaufen bei einer Linksdrehung
nacheinander die Zustände 10→11→01→00→10→… In Hexadezimalschreibweise
lauten diese Bitkombinationen 2→3→1→0→2→….

Eine Linksdrehung um 1 Schritt bewirkt somit einen der Zustandsübergänge
2→3, 3→1, 1→0 oder 0→2. Nach dem SWAP und OR in den Zeilen 33 und 34
steht der alte Zustand im höherwertigen und der neue im niederwertigen
Nibble. Da in Hexadezimalschreibweise jedes Nibble einer Hexziffer
entspricht, kann der Zustandsübergang A→N als hexadezimal AN (also bspw.
2→3 als 23) geschrieben werden. Genau das wird in den Zeilen 38, 40, 42
und 44 gemacht. Darin entsprechen die Konstanten $23, $31, $10 und $02
somit den vier für eine Linksdrehung möglichen Zustandsübergängen.

[Chris S. (Firma: hier&da) (keiningenieur)]

Michael B. schrieb:

Alles gut, hatte im alten Post ne knappe Stunde einen Nachtrag dazu 
geschrieben. Konnte mit dem SWAP/OR Befehl es so erweitern das man 
darüber auch den Drucktaster abfragen.

Mit einer Tabelle wollte ich es erst umsetzen wenn ich die richtige 
Software für eine Menüsteuerung schreibe indirekte Unterprgramme, dazu 
musste ich aber erst den Drehencoder auswerten können.

Wie gesagt genauso wie Jürgen es umgesetzt hat, wollte ich das erstmal 
haben.

[Chris S. (Firma: hier&da) (keiningenieur)]

Yalu X. schrieb:
> Die beiden Encodersignale durchlaufen bei einer Linksdrehung
> nacheinander die Zustände 10→11→01→00→10→… In Hexadezimalschreibweise
> lauten diese Bitkombinationen 2→3→1→0→2→….
>
> Eine Linksdrehung um 1 Schritt bewirkt somit einen der Zustandsübergänge
> 2→3, 3→1, 1→0 oder 0→2. Nach dem SWAP und OR in den Zeilen 33 und 34
> steht der alte Zustand im höherwertigen und der neue im niederwertigen
> Nibble. Da in Hexadezimalschreibweise jedes Nibble einer Hexziffer
> entspricht, kann der Zustandsübergang A→N als hexadezimal AN (also bspw.
> 2→3 als 23) geschrieben werden. Genau das wird in den Zeilen 38, 40, 42
> und 44 gemacht. Darin entsprechen die Konstanten $23, $31, $10 und $02
> somit den vier für eine Linksdrehung möglichen Zustandsübergängen.

Jep ich hab das aber nicht gleich erkannt. Siehe Nachtrag
Auf dem Datenblatt von Alps habe ich mir auch die Zustände 
aufgeschrieben zum Diagramm. Nur bei der Umsetzung wusste ich in der Art 
der Auswertung nicht so richtig weiter....
Dann im Netz auf externe Interrupts(Int0/Int1) und Timer gestoßen.

Mit ersteren konnte ich dem Netz entnehmen das dies das Wheiwasser sei. 
Hatte das Programm soweit, das zumindest die Zustände auf LEDs zwar 
angezeigt wurden aber nicht immer korrekt. Meine Vermutung der Fehler 
liegt bei mir im WIE es ausgewertet wird, da ich nur eben die 8 Zustände 
erfassen wollte. Bei einigen Beiträgen fings dann gleich mit Pointer und 
Tabelle an... Das erscheint mit im Moment etwas oversized wobei die 
Absicht mir klar ist.

Das Problem war ebend WIE ich an die Aufgabe herangehen sollt qausi wie 
ein geölter Fussball den man als Torwart halten solle.
Im Moment läuft es mit Timer und Jürgen seinem Quellcode sogar sehr gut.

Ich will das auch noch mal mit den Interrupts probieren da ich den Weg 
jetzt etwas besser kenne.