Drehencoder auslesen ASM

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.

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

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

1

in r16, pinb ; pb0 und pb1 incrementaleingänge

2

andi r16, 3

3

or r16, old

4

ldi ZL, lo8(table)

5

ldi ZH, hi8(table)

6

add ZL, r16

7

adc ZH, r0          

8

lpm r17, Z ; r17 enthält nun was auf die aktuelle position zu addieren ist

9

lsl r16

10

lsl r16

11

sts old, r16

12

...

13

...

14

.section .progmem.data

15

.type table, @object

16

.size table, 16

17

table:

18

.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

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.

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.

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.