IC zum decodieren von Drehencoder

Hallo

Von Agilent gibts Quadrature Decoder/Counter Interface ICs HCTL-2000, 
HCTL-2016, HCTL-2020

Schöne Grüsse
Otmar

Encoder schrieb:
> vor ein paar Monaten hielt ich ein Datenblatt für ein IC zum
> debouncen/decodieren von Drehencodern in den Händen.

Das war wahrscheinlich schon mehrere Jahrzehnte alt.

http://www.lsicsi.com/encoders.htm
http://www.avagotech.com/ Ins Suchfeld HCTL eintippen.

Heute macht das der uC nebenbei

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

MaWin schrieb:
> Heute macht das der uC nebenbei

Im Normalfall hast du schon Recht, aber Falk hatte oben schon darauf 
hingewiesen, daß es auch Sonderfälle gibt.

Beispielsweise du hast einen Incrementalgeber mit 5000 Strichen, und der 
dreht sich mit 10.000rpm, dann hast du 833.000 Flanken pro Sekunde, die 
du auswerten mußt. Kommt vielleicht nicht so oft vor wie ein Drehgeber 
für das Menue eines LCDs, aber es kommt vor.

Mehmet Kendi schrieb:
> IRQ: ja, aber Timer-Interrupt.
> http://www.mikrocontroller.net/articles/Drehgeber

Alles falsch :-) Es geht auch mit IRQ und ganz schnell.
Beitrag "4-fach Flankenauswertung per Interrupt mit ATmega48/88"

Die Frage ob die Drehgeber besser über Interruptfähige Pins oder einen 
Timerinterrupt ausgewertet werden hängt vor allem davon ab, ob die 
Signale Prellen könne. Bei prellenden Signalen geht es einfacher mit dem 
Timer - bei sauberen Signalen geht es besser mit direkten Interrupts.

Für extra ICs zur Auswertung besteht kaum noch Bedarf da es genügend µCs 
mit passendem Hardware-Interface gibt, und meistens auch die 
Softwarelösung geht.

Mit den Kollegen von der HTCL-Fraktion bin ich mal ganz furchtbar aufs 
Maul geplumpst.
Hatte die Hoffnung auf einen, vom µP und seinen Unterbrechungen, 
unabhängigen Positionszähler. Typischer Fall von denkste.
Im Datenblatt hat aber alles prima Funktioniert...

Amateur schrieb:
> Mit den Kollegen von der HTCL-Fraktion bin ich mal ganz furchtbar aufs
> Maul geplumpst.

Erzähl mal mehr, oder kannst Du jetzt nicht mehr sprechen.
Selber hatte ich mit den Teilen keine Probleme.

m.n. schrieb:
> Es geht auch mit IRQ und ganz schnell.

Was natürlich grober Unsinn ist, denn es funktioniert nur mit prell- und 
zitterfreien Drehgebern, und ist durch die blödsinnige Wahl der 
Interrupts nicht "ganz schnell" sondern etwa 4 mal langsamer als mit 
pollender Abfrage.

Aber wer partout die falsche Lösung sucht, wird dort fündig.

MaWin schrieb:
> Was natürlich grober Unsinn ist, denn es funktioniert nur mit prell- und
> zitterfreien Drehgebern,

Ach! Bei kritischen Signalen schaltet man je nach Signalquelle einfach 
ein RC-Glied vor die Eingänge: z. B. 10k und 1nF. Und schon passt es.
Man darf sich eben nur nicht bockig stellen :-)

m.n. schrieb:
> ein RC-Glied vor die Eingänge: z. B. 10k und 1nF.

Und machst dir damit die Flanken zur Sau.
Wenn du mit dem Fahrrad zu schnell fährst, schiebst du auch einen Stock 
in die Speichen, oder?

Das Problem mit dem Prellen kann man Hardwaremäßig abfangen, ist aber 
extra Aufwand. Der Code hat aber noch ein anderes Problem: es wird nur 
jeweils eine Richtung der Flanken ausgewertet, und dabei kann es beim 
Umdrehen zu einem Schrittfehler kommen - wenn der Sensor um die eine 
Flanke Pendelt wird fortlaufend in eine Richtung gezählt.

Man kann es auch richtig machen mit Interrupt, aber das geht anders - 
eigentlich genau so wie die Routine im Timer Interrupt, nur das halt 
nicht zu festen Zeiten ausgewertet wird sondern wenn was passier. Da 
geht dann auch mit z.B. einem Pin-Change Interrupt der beide Eingänge 
zusammen auswertet.

ich schrieb:
> Und machst dir damit die Flanken zur Sau.

Der von mir benutzte AVR (andere µCs sind dabei nicht ausgeschlossen) 
hat einen eingebauten 'Eber' bzw. Schmitt-Trigger-Eingang.
Wie gesagt, alles kein Problem, wenn man nicht bockig ist.

Ulrich schrieb:
> Der Code hat aber noch ein anderes Problem: es wird nur
> jeweils eine Richtung der Flanken ausgewertet,

Das darf man nicht machen. Es müssen immer beide Flanken beachtet 
werden.

m.n. schrieb:
> Das darf man nicht machen. Es müssen immer beide Flanken beachtet
> werden.

Siehst du, und mit Polling wertet man vier Flanken aus (beide Kanäle).
Kannst du natürlich mit Pinchange auch machen, dann brauchst du aber 
zwei Interrupts. Und das wäre ja dann der Gipfel an Blödsinn...

m.n. schrieb:
> Und schon passt es.

Nur wenn die Eingänge Schmitt-Trigger haben.

> Man darf sich eben nur nicht bockig stellen :-)

Der einzige, der bockig ist "ich will aber Interrupts auch wenn alle 
sagen daß das blöd ist", bist du.

Ach Kinners. Ich weiß ja, dass viele Fliegen auf einem Haufen sitzen und 
sich richtig wohlfühlen.

Mein Link von oben zeigt ein Stückchen Programm, mit dem man Flanken im 
2µs Abstand per Interrupt oder im 2,5µs Abstand mit polling auswerten 
kann.
Kann sich doch jeder frei entscheiden, wie er es gerne hätte.

ich schrieb:
> Siehst du, und mit Polling wertet man vier Flanken aus (beide Kanäle).
> Kannst du natürlich mit Pinchange auch machen, dann brauchst du aber
> zwei Interrupts. Und das wäre ja dann der Gipfel an Blödsinn...

Du hast Dir also meinen Code garnicht angesehen oder nicht verstanden: 
ist mir egal, such Dir was aus.

MaWin schrieb:
> Nur wenn die Eingänge Schmitt-Trigger haben.

Welcher Prozessorhersteller kann sich heute denn noch erlauben, digitale 
Eingänge ohne Schmitt-Trigger vorzusehen. Bei der heutigen 
Stromspartechnik ginge das gleich voll daneben.

Yalu X. schrieb:
> Ursprünglich hießen diese Encoder-ICs 74LS2000. Die bereits
> genannten
> HCTL2xxx sind die CMOS-Varianten bzw. Erweiterungen davon.
>
> Zum Thema Interrupts oder Sampling: Schon in grauer Vorzeit, als die
> o.g. ICs noch hipp waren, hatte man schon erkannt, dass eine
> zuverlässige Decodierung der Drehgeber bis in hohe Frequenzbereiche mit
> klar definierter oberer Grenzfrequenz nur per Sampling möglich ist.
> Deswegen haben alle diese ICs einen CLK-Eingang, über den der
> Sample-Takt bereitgestellt wird.

Auch dieses Argument wird bei ihm leider wirkungslos verhallen. Er will 
nun mal seine Interrupts und läßt sich nicht davon abbringen.

Jedem Tierchen sein Pläsierchen :-)

m.n. schrieb:
> Das darf man nicht machen. Es müssen immer beide Flanken beachtet
> werden.

Genau das ist das Problem mit dem Code. Immerhin hat der den Fehler 
selber erkannt. Es könnte ja ggf. noch funktionieren, denn man die 
beiden Interrupts parallel belegt und einen Pin dazu - das gibt dann 
wenigstens keine Zählfehler, braucht aber 3 Pins und gibt nur die halbe 
Auflösung.

Gerade der Pinchange Interrupt bietet die Möglichkeit das ganze mit nur 
einer ISR zu machen. Das einzige was die Hardware in Sachen Entprellen 
machen muss ist eine zu hohe Interruptrate zu verhindern.

Yalu X. schrieb:
> Ursprünglich hießen diese Encoder-ICs 74LS2000. Die bereits genannten
> HCTL2xxx sind die CMOS-Varianten bzw. Erweiterungen davon.

SN74LS2000 habe ich noch einen hier, die wärmen immer gut; vom THCT2000 
noch zwei ebenso wie vom CF32006FN (drei Kanäle). Oder falls jemand den 
CF32007NT braucht, verschenke ich auch gerne eine Stange. Soviel dazu.

Und da ich absolut beschränkt agiere, nehme ich jetzt pro Kanal einen 
ATmega48, der mir Dreh- und Inkrementalgeber bis 100kHz auswertet. Das 
ist zumeist auch oberhalb der Grenzfrequenz der Geber.
Neuerdings werde ich den ATtiny441 verwenden - noch kleiner und 
ebenfalls mit 100-fach Auswertung für sin/cos-Signale. Kosten Pro Kanal 
< 1€ avec plaisir.

m.n. schrieb:
> Und da ich absolut beschränkt agiere, nehme ich jetzt pro Kanal einen
> ATmega48,

Und was hat das jetzt mit dem Thema Polling oder Interrupt zu tun?

Ulrich schrieb:
> Gerade der Pinchange Interrupt bietet die Möglichkeit das ganze mit nur
> einer ISR zu machen.

Ursprünglich hatte ich den INT0-Eingang eines AVRs favorisiert, da 
dieser die höchste INT-Priorität nach /Reset besitzt. Auch reicht es für 
die Auswertung von mechanischen Drehgebern nur einen Interrupt-Eingang 
zu verwenden, um pro Rastpunkt genau einen Zählschritt zu erreichen.

In einem zweiten Schritt habe ich dann einen PCINTx-Eingang probiert, 
wobei ebenfalls nur eine Phase die ISR auslöst, zusätzlich aber noch die 
Option bietet, eine 4-fach Auswertung durchzuführen. Damit kann man auch 
kleinere AVRs verwenden, bei denen nur irgendein PCINTx zur Verfügung 
steht. Mit einem 8-pol. Tiny könnte man sich das "Dekoder-IC" selbst 
erstellen.

Da ich ein bißchen Zeit hatte, dies auch umzusetzen und zu testen, habe 
ich die Ergebnisse in die Codesammlung gestellt: 
Beitrag "Drehgeber per Interrupt auswerten, AVR"

Hallo Zusammen,

wenn ihr einen schönen Baustein zum verarbeiten von Encoder wollt.

LS7366R

Dieser arbeitet zu hunderten bei uns ein relevanten Baugruppen ohne 
Probleme.

Und alles was langsamer läuft geht direkt im AVR.

PS: Alle alle die einen Encoder entprellen wollen.
    Wenn ein Encoder prellt, dann ist er eh für nichts zu gebrauchen.
    Lieber einen Euro mehr aus geben und was verlässliches haben.

Gruß Thomas

Thomas schrieb:
> Alle alle die einen Encoder entprellen wollen.
>     Wenn ein Encoder prellt, dann ist er eh für nichts zu gebrauchen.

Es gibt keinen Encoder der nicht prellt.

Mechanisch per Kontakt oder Reed-Kontakt abgetastete prellen sowieso,
und photoelektrisch oder so abgetastete haben den prelltypisch 
wiederholten Flankenwechsel nur eines Kanals durch Vibrationen bei 
langsamerem Drehtempo in einer Frequenz, die nicht von der Drehzahl 
sondern nur von der Vibrationsfrequenz abhängt.

Decoder müssen also so oder so mit Prelleffekten klarkommen, deren 
Frequenz nicht mal vorherzusehen ist.

Aber das ist ja kein Problem, wenn man nicht so blöd ist und meint, 
unbedingt die Flanken auswerten zu müssen.

Thomas schrieb:
> wenn ihr einen schönen Baustein zum verarbeiten von Encoder wollt.
>
> LS7366R
>
> Dieser arbeitet zu hunderten bei uns ein relevanten Baugruppen ohne
> Probleme.

Das ist sicherlich eine Lösung für alle Fälle. Auch, wenn man nur 
mechanische Geber anschließen möchte: 2 x pullup-Widerstand und beide 
Phasen direkt an die Eingänge. Pro Raststellung erhält man zwei 
Schritte, die man durch Division verringern kann: meinetwegen per 
Schiebeoperation oder auch in float :-)

Nachteil bei allen zuvor genannten Dekoder-ICs ist die langfristige 
Beschaffbarkeit. Seinerzeit war es immer eine Rennerei, die Teile 
aufzutreiben, oder das Layout an die neueren Ausführungen anzupassen.
Mit aus diesem Grunde habe ich mir vor 20 Jahren den H8/3003 angelacht, 
der schon einen Hardware-Dekoder auf dem Chip hatte und Signale mit weit 
über 1MHz verarbeiten konnte. Danach kam dann der H8S/.... mit zwei 
Quadraturdekodereingängen, und dann die H8SX mit insgesamt vier davon.
Heute liegen die STM32F407 mit insgesamt sechs Kanälen ganz vorne. Zu 
Kosten von <5€ (im LQFP100-Gehäuse) erhält man eine langfristig 
verfügbare µC-Lösung.

Ein kleiner Nachteil der neueren µCs ist die Versorgungsspannung von 
3,3V, wobei die Inkrementalgeber weiterhin mit 5V arbeiten. 
Pegelkonverter sind folglich Pflicht; sofern man sin/cos-Signale 
auswerten möchte, ist bei der zumeist gebotenen Mehrfachauswertung noch 
eine Synchronisierung der Phasenlage erforderlich. Für den festen Einbau 
ist das kein Problem; bei nach dem Einschalten zusteckbaren Gebern kann 
die Zuordnung nicht 100% sichergestellt sein.
Das sind aber Feinheiten, die für Freunde des billigen Einkaufens nie zu 
Tage treten werden.

Wenn man dann die ganzen Erfahrungen zusammenfaßt, lande ich, wie 
geschrieben, bei einem AVR! Hinreichend schnelle Zählfrequenz im 
100kHz-Bereich, optionale sin/cos-Interpolation direkt mit 5V Signalen 
und über IIC-Bus für viele Kanäle zu geringen Kosten ausbaubar. Der 
synchrone IIC-Bus benötigt keine konstante CPU-Taktfrequenz, weshalb 
auch der int. Oszillator, auf max. Frequenz eingestellt, völlig 
ausreichend ist.

m.n. schrieb:
> ist bei der zumeist gebotenen Mehrfachauswertung noch
> eine Synchronisierung der Phasenlage erforderlich.

Du meinst wahrscheinlich ein Abgleich auf gleiche Amplitude.

Gruss Georg

Nein, die Amplituden sind nicht das Problem.

Nimmt man den µC-internen Quadraturdekoder mit 4-fach Auswertung, dann 
ist die Auswertelogik beim Einschalten zurückgesetzt und man kann sich 
an Hand der beiden Phasensignale errechnen, in welchem Quadranten der 
Geber steht und wie die analoge Interpolation stattfinden muß. Das geht 
gut.

Steckt man hingegen den Geber in ein eingeschaltetes Gerät ein, kann man 
nicht 100% sicher sein, dass die zuvor genannte Zuordnung eindeutig 
hergestellt ist. In der Regel funktioniert es, muß es aber nicht.

Ich habe hier sin/cos-Geber, die mit 0,1µm Auflösung arbeiten; die 
Genauigkeit liegt bei 0,2µm (lt. Meßprotokoll des Herstellers).
Sofern die Auswertung passend ist, werden die 0,1µm-Schritte mit hoher 
Wiederholgenauigkeit geliefert. Ist die Auswertung jedoch aus dem Tritt, 
gibt es ebenfalls eine Änderung um 0,1µm und alle 25 Schritte einen 
Sprung um 2,5µm. Sofern der Anwender eine Prüfung auf 
Wiederholgenauigkeit macht und dieses 'Verhalten' bemerkt, gibt es 
richtig Haue ;-)

Um wieder auf den AVR zu kommen: da kann man durch passende 
Programmierung diese Problematik umgehen. Hinzu kommt noch, die 
Gebersignale trotz schwankender Amplituden, Nulllinien und Hysteresen 
richtig auszuwerten; aber es geht!
Weiter möchte ich es nicht ausführen; bei dem vielen Geschrei im 
Hintergrund gehen die Feinheiten sowieso unter.