Hallo, vor ein paar Monaten hielt ich ein Datenblatt für ein IC zum debouncen/decodieren von Drehencodern in den Händen. Ich find das ums verrecken nicht mehr. Kann mir jemand einen Tipp geben? Danke
nö, sorry. Einige µCs haben einen Quadratur.Decoder incl. Entprellung eingebaut, da habe ich die Links gelöscht.
Hallo Von Agilent gibts Quadrature Decoder/Counter Interface ICs HCTL-2000, HCTL-2016, HCTL-2020 Schöne Grüsse Otmar
öhm warum einen eigenen Chip für eine Basicfunktion das geht in SW und belegt nur 2 IO-Pins, vorzugsweise IRQ. Wenn es eine HW Lösung sein muss tun es ein paar Gatter? Brauchst du nur die Richtung oder auch die Ticks und wie willst du das weiter verarbeiten?
@ Winfried J. (Firma: Nisch-Aufzüge) (winne) > warum einen eigenen Chip für eine Basicfunktion das geht in SW und Manchmal braucht man aber etwas anderes, z.B. wenn es Drehgeber mit hoher Auflösung und Drehzahl sind.
Könnte man auch in einem kleinen CPLD/FPGA umsetzen, wenn man es extern braucht: https://www.mikrocontroller.net/articles/Drehgeber#Beispielcode_in_VHDL
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.
Falk Brunner schrieb: > Manchmal braucht man aber etwas anderes Wie immer in diesem Forum: Alle zanken sich und der "Autor: Encoder (Gast)" hat noch gar nicht gesagt, um wieviele Flanken pro Sekunde es sich bei ihm handelt. Beim STM32F4 z.B. muss ich mich gar nicht zwischen Interrupt oder Polling entscheiden; der entprellt und zählt direkt den Timer-Counter hoch und runter. Die CPU kann dabei schlafen.
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.
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.