Erkennen der Drehrichtung eines Drehgebers (Inkrementalwertgeber) mit ATtiny13

[Schmidtbot]

Hallo,
ich brauche Hilfe. Ich baue ein Sportboot(4x1m). Das Ruder wird über einen Schrittmotor(SM) betätigt. Dies Funktioniert auch schon. Jetzt kommt aber mein Problem. Am Lenkrad des Bootes befindet sich eine Drehgeber. Dieser Drehgeber soll den SM Steuern. Dafür habe ich mit einen Attiny13 und einen NE555 für die Trimmung ein Board erstellt. Dieses funktioniert auch. Nur der µC nicht.
Ich gebe auf den µC am PB.3 und am PB.4 die beiden Signale des Gebers. Der µC soll dann am PortB.2 den Takt des Gebers Ausgeben wenn ich das Lenkrad nach rechts drehen. Wenn ich das Lenkrad nach links drehe soll er den Takt am PB.1 ausgeben. Dafür hab ich diesen Code erstelle. Leider Funktioniert dieser nicht. Am Anfang soll er beim Starten die beiden Ausgänge auf High setzen nach dieser Pause soll er das Arbeiten Anfangen.

Besten Danke für euere Hilfe!
Gruß
Rolf

 begin:
    rjmp    main                        ; RESET External Reset, Power-on Reset and Watchdog Reset
reti; INT0 External Interrupt 0
reti; PCINT0 External Interrupt Request 0
reti; TIM0_OVF Timer/Counter0 Overflow
reti; EE_RDY EEPROM Ready
reti; ANA_COMP Analog Comparator
reti; TIM0_COMPA Timer/Counter Compare Match A
reti; TIM0_COMPB Timer/Counter Compare Match B
reti; WDT Watchdog Time-out
reti; ADC ADC Conversion Complete
;------------------------------------------------------------------------------
main:
    ldir16,    lo8(RAMEND)         ; Main program start
outSPL,    r16; Set Stack Pointer to top of RAM
cbiDDRB,   3                   ; PORTB.3 als Eingang gesetzt 
cbiDDRB,   4                   ; PORTB.4 als Eingang gesetzt
sbiDDRB,   1                   ; PortB.1 als Ausgang gesetzt
sbiDDRB,   2                   ; PortB.2 Als Ausgang gesetzt
;...                                ; Hier Init-Code eintragen.
;------------------------------------------------------------------------------
mainloop:
    ldir18,    0b00000000
    ldir17,    0b00000000
    ldir16,    0b00000001
    ldir19,    0b00000110
    outPORTB,  r19
incr17
brne    mainloop    
    incr18
brne    mainloop
    rolr16
sbrsr16,    7                   
    rjmp    mainloop
    ldir19,    0b00000000
    outPORTB,  r19    
Start:   
    inr16,    PINB; alle Eingänge in R16 einlessen
sbrcr16,    3
    sbrR21,    0b00000001          ; setze BIT 0 in R19 auf high
cbrr21,    0b00000001
    sbrcr16,    4
    sbrR22,    0b00000001          ; setze BIT 0 in R19 auf high
cbrr22,    0b00000001      
Flanke:   
    comr17; alle Werte im Register 17 negieren
movr18,    r16; kopiere das Register 16 in das Register 17
andr18,    r17; Und verknüfen der beiden Register- Ergebniss der UND-Verknüpfung in r18
movr17,    r16; kopieren den Inhalte des R16 in R17
sbrcr18,    3                   ; überprüfe die Und-Verknüpfung des ersten Port, true = nicht fals = springe
sbrR19,    0b00000001          ; setze BIT 2 in R19 auf high
cbrr19,    0b00000001
    sbrcr18,    4                   ; überprüfe die Und-Verknüpfung des ersten Port, true = nicht fals = springe
sbrR20,    0b00000001          ; setze BIT 2 in R19 auf high
cbrr20,    0b00000001
Und1:
    andR22,    R19
movr23,    R22
Und2:
    andR21,    R20
movr24,    R21
negieren:
    movr25,    r23
movr26,    r24
incr25     
    incr26
und3:
    andr23,    r26
sbrcr23,    0       
    sbiPORTB,  2
    cbiPORTB,  2
und4:
    andr24,    r25
sbrcr24,    0
    sbiPORTB,  1
    cbiPORTB,  1    
    rjmp    Start                       ; Springe zum Mainloop Punkt

[PicNick]

Wenn man nur die steigenden (oder fallenden) Flanken berücksichtigt, wird man bei jeder Dreh-Richtungsänderung immer einen Schritt verlieren.
Weiss nicht, wie heikel das in deinem Fall ist.
1) wenn nicht, reicht ein D-Flip-Flop, Channel A als "Clock", Channel B als "Data". Das ergibt mit 0/1 die Richtung, und clock ist auch der Takt für den SM

2) vollständige decodierung:
Da Du offenbar gevifter Assembler-Fuzzy bist, hilft Dir vielleicht das Assembler-Listing von dem, was zB Bascom für drehgeber assembliert
http://www.rn-wissen.de/index.php/Ba...ur-.29_ENCODER

theoretisches:

http://www.rn-wissen.de/index.php/Be...anke_ermitteln

[Ostermann]

Ohne mir jetzt deinen Code im Detail angesehen zu haben: Der Encoder kennt nur 4 Zustände. Die kann man einfach in einer Tabelle ablegen und dann jeweils den alten mit dem aktuellem Zustand vergleichen. Über die Tabelle "sieht" man dann, ob es vorwärts oder rückwärts geht. Ein Sprung über 2 oder mehr Tabelleneinträge stellt einen Fehler da. Die Eingänge müssen also schnell genug abgetastet werden.

Pos. Signale
0 00
1 01
2 11
3 10
4=0 00
usw.

Mit freundlichen Grüßen
Thorsten Ostermann

[PICture]

Hallo!

Hoffentlich hilft dir die Beschreibung und Programablaufdiagramm (PAD): http://www.rn-wissen.de/index.php/PI...w._Drehencoder .

[PicNick]

@ostermann, mit verlaub, ich muss dich korrigieren: wenn du nicht beide Flanken auswertest, ist bei einer drehrichtungsumkehr die sache nicht präzise. Und dadurch hast du 8 zustände.
Bin sicher, ich muss bei dir nicht klitzeklein aufzeichnen, wo das problem liegt

[Ostermann]

Hallo Robert!

Man wertet nach meiner Methode überhaupt keine Flanken aus, sondern Zustände und Zustandsübergänge. Von einem Zustand zum nächsten gibt es immer genau zwei erlaubte Übergänge, nämlich linksrum oder rechtsrum. Ich sehe nicht, so du da 8 Zustände herholen willst...

Mit freundlichen Grüßen
Thorsten Ostermann