Optischen Drehencoder auswerten

[Dieter B. (Gast)]

Hallo,

Ich stehe gerade ein wenig auf dem Schlauch...

Ich benutze einen Mega168 und möchte damit meinen Drehencoder (optisch) 
auswerten.

Es handelt sich um einen MRL20...

Phase_A habe ich an INT0 (PD2) angeschlossen und INT0 auf fallende 
Flanke konfiguriert.

Phase_B hängt an einem PD0...

Ich möchte wenn ich links drehe, dass die LED angeht... drehe ich 
rechts... soll sie aus bleiben...

was mache ich falsch ?

#define PHASE_A PORTD |= (1<<PD2)
#define PHASE_B PORTD |= (1<<PD0)

/* PullUp´s aktivieren */
PORTD |= ((1<<PD0) | (1<<PD2));

/* INT0 konfigurieren (fallende Flanke) */
  EIMSK |= (1<<INT0);
  EICRA |= ((1<<ISC01));

/* Drehencoder auswerten (Phase_A triggert den Interrupt) */
ISR (INT0_vect)
{
  if (!(PHASE_B))
  {
    PORTD |= (1<<PD5);
  }
    else
  {
    PORTD &= ~(1<<PD5);
  }
}

[Mike (Gast)]

Dieter B. schrieb:
> was mache ich falsch ?

Was geht denn nicht?

Dir fehlt mindestens ein Hauptprogramm. Und die ISR nützt dir gar 
nichts, solange du Interrupts nicht freigibst.

[Dieter B. (Gast)]

Mike schrieb:
> Dieter B. schrieb:
>> was mache ich falsch ?
>
> Was geht denn nicht?
>
> Dir fehlt mindestens ein Hauptprogramm. Und die ISR nützt dir gar
> nichts, solange du Interrupts nicht freigibst.

Das Hauptprogramm existiert...
Ich kann mit dem Drehencoder auch die ISR von INT0 aufrufen (sehe ich an 
einer LED)

nur die Richtung kann ich nicht erkennen... Ob ich links oder rechts rum 
drehe...

[m.n. (Gast)]

Dieter B. schrieb:
> Phase_A habe ich an INT0 (PD2) angeschlossen und INT0 auf fallende
> Flanke konfiguriert.

INT0 muß beide Flanken auswerten; mehr habe ich mir nicht angesehen.

[Dieter B. (Gast)]

m.n. schrieb:
> Dieter B. schrieb:
>> Phase_A habe ich an INT0 (PD2) angeschlossen und INT0 auf fallende
>> Flanke konfiguriert.
>
> INT0 muß beide Flanken auswerten; mehr habe ich mir nicht angesehen.

Du meinst in der ISR von INT0 ?

[m.n. (Gast)]

Ich weiß schon garnicht mehr, wo ich was beschrieben habe. Die ersten 
Beispiele laufen mit PCINT, können aber einfach auf INT0 umgestellt 
werden.
Das letzte Beispiel ist auf höchste Geschwindigkeit getrimmt und wertet 
INT0+INT1 aus.

Beitrag "Drehgeber per Interrupt auswerten, AVR"
Beitrag "Schrittmotor als Drehgeber mit Dynamik, AVR"
Beitrag "4-fach Flankenauswertung per Interrupt mit ATmega48/88"

[littleHelper (Gast)]

Hi
das muss ganz oben in den defines nicht PORTD sondern PIND heißen dann 
gehts

auserdem musst du dein programm in eine int main(void){} funktion 
schreiben... nur weils auch so geht heist das noch lang nicht das mans 
darf

der ordnung halber solltest du deine register in einer init funktion 
setzen

und für so einfache sachen noch nicht unbedingt erforderlich aber wenns 
etwas komplexer wird musst du den pin entprellen und solltest du die 
auswertung umfangreicher machen... hierzu benutze bitte die suchfunktion

[MaWin (Gast)]

Dieter B. schrieb:
> Phase_A habe ich an INT0 (PD2) angeschlossen und INT0 auf fallende
> Flanke konfiguriert.
>
> was mache ich falsch ?

Alles.
Wie kommt man auf die hirnrissige Idee, Drehgeber per Flanken auswerten 
zu wollen?

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

Vorhee lohnt auch nicht die Korrektur der vielen Programmfehler.

[m.n. (Gast)]

MaWin schrieb:
> Wie kommt man auf die hirnrissige Idee, Drehgeber per Flanken auswerten
> zu wollen?

Weil man alle Änderungen mitbekommen möchte.
Dazu ein ganz einfache Rechnung: der Drehgeber liefert 50kHz Signale und 
die 'vielbeschworene' Auswertung tastet mit 10kHz die Eingänge ab. Damit 
gehen 4 von 5 Impulsen verloren. Das ist eine ganz schlechte Lösung.

Per Interrupt bekommt man jeden Impuls erfaßt!

P.S.: Dein Link auf Deinen Beitrag ist ja schon 13 Jahre alt. Höchste 
Zeit, ihn mal zu überarbeiten :-)

[Thorsten O. (Firma: mechapro GmbH) (ostermann)]

Wenn man unterabtastet darf man sich nicht wundern wenn das Ergbenis 
nichts taugt. Wenn die ISR zu lange dauert, wirst du die 50KHz auch 
nicht erfassen können.

Mit freundlichen Grüßen
Thorsten Ostermann

[Falk B. (falk)]

@ m.n. (Gast)

>> Wie kommt man auf die hirnrissige Idee, Drehgeber per Flanken auswerten
>> zu wollen?

>Weil man alle Änderungen mitbekommen möchte.

Kannst du mal endlich aufhören, den Rest der Welt mit deinen fixen Ideen 
zu missionieren? Danke.

[m.n. (Gast)]

Thorsten Ostermann schrieb:
> Wenn man unterabtastet darf man sich nicht wundern wenn das Ergbenis
> nichts taugt. Wenn die ISR zu lange dauert, wirst du die 50KHz auch
> nicht erfassen können.

Na ja, wenn man hinreichend schnell abtastet (zum Beispiel mit 100kHz) 
ist der Prozessor schon deutlich belastet, da er alle 10µs die ISR 
ausführen muß. Dies auch, wenn der Drehgeber garnicht bewegt wird.
Geschickter ist es daher, nur bei Bewegung des Gebers die Auswertung per 
Interrupt zu erledigen.
Hinreichend schnell muß die ISR immer sein!

Der letzte von mir oben aufgeführte Link zeigt ein Programm, das per 
Interrupt 500kHz Auswertungen schafft und auch auf Polling umgeschaltet 
werden kann. Die Grenzfrequenz sinkt dann auf 400kHz, wobei eine 
deutliche Grundbelastung des µC vorhanden ist.
Da kann sich Jeder selber aussuchen, wie er es machen möchte.

[spontan (Gast)]

>Na ja, wenn man hinreichend schnell abtastet (zum Beispiel mit 100kHz) ist >der 
Prozessor schon deutlich belastet, da er alle 10µs die ISR ausführen
> muß. Dies auch, wenn der Drehgeber garnicht bewegt wird. Geschickter ist
> es daher, nur bei Bewegung des Gebers die Auswertung per Interrupt zu
> erledigen.

Solch ein Bockmist ist immer wieder nett.

Systeme müssen immer für den Worst Case ausgelegt werden. Deine ISR 
genauso wie eine Abtastung mit Timer-Interrupt.

Du bekommst vom Hersteller kein Geld zurück, wenn der Prozessor in einer 
Warteschleife arbeitet. Da kann er auch ein vernünftiges Programm 
abarbeitn.

Für schnelle Signale nimmt man eh einen Hardwarezähler, ja den gibt es 
auch für 2-Phasensignale, und ja den gibt es auch im Prozessor 
integriert. Z.B. hat sogar der kleine PIC18F2431 solch einen Zähler auf 
dem Chip.

Da werden Interrupts für 50 kHz-Signale sowas von lächerlich.

[m.n. (Gast)]

spontan schrieb:
> Z.B. hat sogar der kleine PIC18F2431 solch einen Zähler auf
> dem Chip.

Ein netter Tipp, nur leider nutzlos.
Der der TO hat einen ATmega168 vor sich zu liegen und 'Wurst Käse' ist 
wohl auch nicht sein Problem.

[Horst H. (horst_h44)]

Die AB-Signale sind kodiert, sodass vier Flanken ausgewertet werden 
können. Das Bild 2 hier: http://ichaus.biz/wp2_encoderanschluss zeigt 
den Ablauf für Vor-/Rückwärts. Wenn mit der positiven A-Flanke nur 
vorwärts gezählt werden soll, dann brauchst Du nur im Programm zu prüfen 
ob B=HIGH ist. Wenn nicht ist es rückwärts und Du kannst den Interrupt 
ignorieren. In Hardware kannst Du aber auch A und B mit einen UND-Gatter 
verknüpfen und auf den Interrupt-Eingang geben(A+B=LOW --> HIGH). 
Umgekehrt gilt das Gleiche.

[Ässämbla (Gast)]

>http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.29
bin noch am Grübeln was schlimmer ist:
- Auswertung Encoderflanken durch Interrupt, oder
- FAQ / Wiki das voll mit Assemblerbeispielen ist.

[c-hater (Gast)]

MaWin schrieb:

> Wie kommt man auf die hirnrissige Idee, Drehgeber per Flanken auswerten
> zu wollen?

Wenn man z.B. einerseits hochauflösende Geber mit voller Genauigkeit 
auswerten will, auch wenn sie mit hoher Geschwindigkeit bewegt werden, 
wenn sie bewegt werden, aber andererseits nicht ständig 10 mA oder so 
aus einer Knopfzelle zutscheln will...

Naja, schon klar, du bist diesbezüglich völlig merkbefreit, jegliche 
Diskussion ist eigentlich sinnlos.

[c-hater (Gast)]

Thorsten Ostermann schrieb:

> Wenn man unterabtastet darf man sich nicht wundern wenn das Ergbenis
> nichts taugt.

Richtig.

> Wenn die ISR zu lange dauert, wirst du die 50KHz auch
> nicht erfassen können.

Richtig. Nur dauert sie halt nicht so lange, sondern z.B. in meiner 
Implementierung nur genau 16 Takte. Kann also auf einem 16MHz-Atmel 
notfalls mit 1MHz IRQ-Frequenz klarkommen. Das ist mal eben so das 
20fache.

Und wenn keiner am Rad dreht, dann schluckt meine Implementierung exakt 
NULL Takte. Und ja, auch der Prellschrott billiger Geber in 
Rastpositionen läßt sie völlig kalt. Der Preis dafür ist eine 
(nichtakkumulierende) Umkehrhysterese von einem Geber-Schritt und 
leichte Beschränkungen bei der Pin-Wahl, mehr nicht.

Und natürlich ist das Konstrukt dafür geeignet, jederzeit in den 
tiefsten Schlafmodus abzutauchen, wenn niemand am Rad dreht, ganz im 
Gegensatz zu jeder dümmlichen Polling-Lösung. Und natürlich auch 
dafür, aus diesem Tiefschlaf auch wieder aufzuwachen, wenn wieder jemand 
am Rad dreht. Auch wieder: ganz im Gegensatz zu einer dümmlichen 
Polling-Lösung, denn spätestens dafür müssen dann selbst die völlig 
merkbefreiten Hardcore-Poller doch die Interrupts bemühen, die sie 
fürchten wie Dracula den Knoblauch. Blutleere C-Vampire, auch mal ein 
schickes Gleichnis...

[Falk B. (falk)]

@ c-hater (Gast)

>Und natürlich ist das Konstrukt dafür geeignet, jederzeit in den
>tiefsten Schlafmodus abzutauchen, wenn niemand am Rad dreht,

Der Einzige der am Rad dreht bist du. ;-)

[m.n. (Gast)]

c-hater schrieb:
> Richtig. Nur dauert sie halt nicht so lange, sondern z.B. in meiner
> Implementierung nur genau 16 Takte.

Hast Du ein Beispiel dafür?
Meine Routine dauert länger. Zum einen, weil ich 32-Bit Zähler verwende 
und zum anderen vielleicht noch optimieren kann.

c-hater schrieb:
> Und natürlich ist das Konstrukt dafür geeignet, jederzeit in den
> tiefsten Schlafmodus abzutauchen, wenn niemand am Rad dreht, ganz im
> Gegensatz zu jeder dümmlichen Polling-Lösung. Und natürlich auch
> dafür, aus diesem Tiefschlaf auch wieder aufzuwachen, wenn wieder jemand
> am Rad dreht. Auch wieder: ganz im Gegensatz zu einer dümmlichen
> Polling-Lösung, denn spätestens dafür müssen dann selbst die völlig
> merkbefreiten Hardcore-Poller doch die Interrupts bemühen, die sie
> fürchten wie Dracula den Knoblauch.

Na das liest sich ja richtig gut. Warum wurden wir uns noch nicht 
vorgestellt?
Nur eine kleine Korrektur am Rande:
"denn spätestens dafür müssen dann selbst die völlig
 merkbefreiten Hardcore-Proller doch die Interrupts bemühen"

[MaWin (Gast)]

m.n. schrieb:
> Weil man alle Änderungen mitbekommen möchte.

Dann darf man niemals Flanken auswerten, schliesslich kommen bei 
Prellen, mechanischen Vibrationen oder elektrischen Einsteuungen an der 
Umschaltkante viel zu viele in zu kurzen Abständen.
Aber m.n. hat trotz dutzenden von threads zu Drehgeberauswertung noch 
immer seinen Betonkopf nicht renoviert.
Der link wie man es richtig auswertet wurde genannt.

[Thomas Z. (tezet)]

MaWin schrieb:
> Dann darf man niemals Flanken auswerten, schliesslich kommen bei
> Prellen, mechanischen Vibrationen oder elektrischen Einsteuungen an der ...

Hier geht es doch nicht um mechanische Drehgeber, die prellen können. 
Wenn intruptgesteuerte Auswertung so verteufelt wird, weil 
fehleranfällig, dann wundere ich mich, warum beispielsweise SPI 
eingesetzt wird. Da müsste ja "ständig" Kauderwelsch rauskommen.

[m.n. (Gast)]

MaWin schrieb:
> Dann darf man niemals Flanken auswerten, schliesslich kommen bei
> Prellen, mechanischen Vibrationen oder elektrischen Einsteuungen an der
> Umschaltkante viel zu viele in zu kurzen Abständen

Das sind Alles bekannte Vorurteile, von Leuten die weder lesen und 
keinesfalls begreifen wollen.
Obwohl es heute Volksverdummung auf fast allen Kanälen gibt, bin ich 
nicht bereit, dies unwidersprochen stehen zu lassen.

Hier ein paar Erläuterungen:
Beitrag "Re: 4-fach Flankenauswertung per Interrupt mit ATmega48/88"

[Falk B. (falk)]

Mein Gott. Ein normaler Quadraturencoder, wie er im Artikel 
Drehgeber dargestellt ist, besteht aus VIER FlipFlops und DREI EXOR 
Gattern. Selbst wenn man den mit 1 MHz Takten würde, wäre die 
Stromaufnahme exobitant gering und immer nur so hoch, wie es die 
Frequenz der Eingangssignale bestimmt, denn CMOS braucht nur beim 
Pegelwechsel Strom. Alsob braucht es KEINERLEI Stunts mit 
flankensensitiven Interrupts (die ausserdem noch mehr Silizium brauchen 
würden), um dem ultimativen, stromsparenden Quadraturencoder zu bauen. 
Man baut den sinnvolerweise in Hardware, die CPU schuat nur gelegentlich 
vorbei und liest den Zähler aus. Das ist immer noch stromsparender UND 
solider als alle Flankenintterrupttricks dieser Welt. Ende der 
Geschichte.

[MaWin (Gast)]

Thomas Z. schrieb:
> Hier geht es doch nicht um mechanische Drehgeber, die prellen können.

Auch optische Encoder haben solche Effekte, darum habe ich den Satz 
extra fortgeführt mit "mechanischen Vibrationen oder elektrischen 
Einsteuungen", es würde also helfen, wenn du lesen könntest.

m.n. schrieb:
> Das sind Alles bekannte Vorurteile

Erfahrungen, und dein wiederholtes  Getrolle hier, entgegen ALLEN 
Erfahrungen untaugliche Methoden zu propagieren, ist dumm und nervt.
G

[m.n. (Gast)]

Falk Brunner schrieb:
> besteht aus VIER FlipFlops und DREI EXOR
> Gattern.

Soviel?
Und da werde ich angepflaumt, sobald ich nur einen Widerstand und einen 
Kondensator verbaue. Prompt wird mir dann vorgerechnet, welch immenser 
volkswirtschaftlicher Schaden bei Millionenstückzahl dadurch entsteht.
Ihr dreht Euch Eure Argumente immer so, wie es gerade paßt.


Dieter B. schrieb:
> Ich benutze einen Mega168 und möchte damit meinen Drehencoder (optisch)
> auswerten.

Das ist die Ausgangsfrage. Und der ATmega168 hat keinen Quadraturdekoder 
auf dem Chip.

@ Dieter B.
Bist Du schlauer geworden und hast Du Dein Problem inzwischen gelöst?