Auf der Suche nach einer Lösung einen Drehgeber in asm auszuwerten, stieß ich auf diesen Code der genau meinen Vorstellungen entsprach. Beitrag "Drehencoder auslesen ASM" Als Grundauswertung ist das Programm fast so geblieben nur das man jetzt die Auswertung in einer ISR, für Timer oder Interrupt gesteuert, lösen kann. Zusatz ist die Auswertung des Drucktasters, die bei einigen Ausführungen vorhanden ist. Aber das war das deutlich geringere Problem... Zeilen mit * gehören zur TIMER-Auswertung Zeilen mit ** gehören zum Interrupt Timer 0 CTCMODE OC0A auf unter 10ms einstellen, PinToggle deaktiviert Pins entsprechend beschalten oder INT0/1 jeden Flankewechsel(_- / -_) aktivieren PCI aktivieren (jeder Flankenwechsel wird beachtet, nicht einstellbar) ISR für Timer und INT0/1 PCI Ablauf wie folgt INT0/1 Drehencoder, PCI: Taster: 1. Altwert laden 2. Neuwert einlesen 3. UND Maskierung Neuwert (abhängig an welchen Pins) 4. Neuwert in Altwert speichern 5. Vergleich alt neu ? wenn alt = neu 9. Ende 6. Altwert swapen 7. Neu Altwert odern (so steht der Zustand vorher nacher in einem Register) 8. Vergleich und dann jeweils die Sprungbedingung links/rechts 9. Ende Links/Rechts UP Richtung als veränderbare Zahl oder nur als Bitstetzung zur weiteren Auswertung Der Interrupt zeigt nur an DAS eine Auswertung zu tätigen ist!!
:
Bearbeitet durch User
Chris S. schrieb: > oder Wieso oder ? Du hast genau den richtigen Code gefunden der zuverlässig (wenn es Lichtschranken sind, keine kratzenden Schleifer bei denen Kontaktausfälle durch Kondensatoren ausgeglichen werden müssen) Incrementaldrehgeber auswertet. Was soll jetzt der Schwachsinn das zwanghaft auf die nachweislich nicht funktionierende Flankeninterrupts umzustellen, Interrupts die beim Prellen der Kontakte bzw. vibrieren der Lichtschranken den Prozessor überrennen ? Wird die Menschheit wirklich immer dümmer und du rennst vorweg ? https://dse-faq.elektronik-kompendium.de/dse-faq.htm#F.29
Zwanghaft schon mal gar nicht da die Auswertung nur dann erfolgt wenn Flanken erfasst werden.... Beweise es das es nicht bei Lichtschranken, die stark vibrieren, funktionieren soll!! Wer behauptet muss abliefern. Ich habe auch nicht geschrieben das es für Lichtschranken geeignet sei. ;) Und ja die Menschheit muss in deinen Augen immer dümmer werden, mein Gott wo wärst du ohne Fehler unserer Vorfahren?
Chris S. schrieb: > Beweise es das es nicht bei Lichtschranken, die stark vibrieren, > funktionieren soll!! Wer behauptet muss abliefern. Damit wurden ganze Bücher gefüllt! Lies sie selber oder glaube Jenen, die das taten!
Tipp: Sowas nicht mit einem fabrikneuen Encoder entwickeln, sondern mit einem maximal ausgeleiherten, kurz vor Lebensdauer-Ende. Z.B. den mal in die Bohrmaschine einspannen und ein paar Runden drehen lassen. Nichts ist ärgerlicher als diese "geplante Obsoleszenz"-Geräte, wo nach einem Jahr der Drehgeber nur noch in eine Richtung will, wild durch die Gegend springt, bei jeder Rastung einen Schritt vor und drei zurück macht usw.
Prinzipiell scheint die gezeigte Auswertung mit externen Interrupts zu funktionieren. Insbesondere dieses wird IMHO nicht passieren: Εrnst B. schrieb: > Nichts ist ärgerlicher als diese "geplante Obsoleszenz"-Geräte, wo nach > einem Jahr der Drehgeber nur noch in eine Richtung will, wild durch die > Gegend springt, bei jeder Rastung einen Schritt vor und drei zurück > macht usw. Allerdings hat das Verfahren gegenüber der Timer-Variante nicht nur Vorteile. Vorteile: - Solange der Drehgeber stillsteht, wird keine CPU-Zeit gebraucht. - Das Verfahren kommt auch mit höheren Signalfrequenzen zurecht, für die bei der Timer-Variante die Interruptfrequenz des Timers erhöht werden muss, was dann aber zu einer dauerhaft höheren CPU-Auslastung führt. Bei der Interrupt-Variante steigt die CPU-Auslastung zwar ebenfalls mit der Signalfrequenz, geht aber auch wieder zurück, sobald die Signalfrequenz sinkt. Nachteile: - Der Erfolg des Verfahrens hängt von der Art und Weise ab, wie der µC Flanken detektiert und darauf basierend Interrupts auslöst. Für die AVRs scheint das in Ordnung zu sein, wenngleich die Datenblätter diesbezüglich etwas lückenhaft sind. Für die meisten anderen µC-Typen wird es vermutlich ebenso funktionieren, aber garantiert werden kann das nicht. - Die mittlere CPU-Auslastung ist zwar tendenziell niedriger als bei der Timer-Variante, kann aber für die Dauer des Kontaktprellens auf 100% ansteigen, da bei höherer Prellfrequenz der Interrupthandler lückenlos mehrfach hintereinander aufgerufen wird. Dies hat zur Folge, dass andere Interruptquellen nur stark verzögert bedient werden können, so dass bspw. beim UART-Empfang evtl. Daten verloren gehen. Bei der Timer-Variante sind sowohl die prozentuale CPU-Auslastung als auch die Zeitdauer, während der andere Interrupts blockiert werden, unabhängig von der Prelldauer und der Signalfrequenz, was zu deutlich weniger Überraschungseffekten führt. Aus den genannten Gründen ist die Timer-Variante in den meisten Fällen die für den Programmierer stressfreiere. Wenn wirklich die CPU-Auslastung minimiert werden muss und/oder hochauflösende Drehgeber mit hohen Drehzahlen (hohe Signalfrequenzen) ausgewertet werden sollen, würde ich die Auswertung nicht in Software machen, sondern einen µC nehmen, der bereits entsprechend ausgestattete Timer/Counter mitbringt. Mittlerweile ist das kein allzu exotisches Feature mehr. Einige ATxmega, die meisten (oder alle?) STM32 und sogar der chinesische Billigheimer CH32V003 für unter 30 Cent können das und stoßen damit selbst bei Encodern mit 10.000 Strichen und 10.000 U/min (das sind über 6 Mio Zustandsübergänge pro Sekunde) noch lange nicht an ihre Grenzen.
Es gibt als 3. Weg noch die Kombination beider Verfahren, indem die Flanken per ISR verarbeitet werden, die zuvor durch DFFs mit einem Takt (50 - 100 kHz) synchronisiert wurden. Dadurch wird die Interruptrate nach oben begrenzt und die Prozessorbelastung gesenkt, wenn die Siganle unverändert bleiben. Zur Synchronisierung könnte man auch einen 8-pol. µC verwenden, der langsam getaktet zwei Eingänge einliest und an zwei Ausgänge weiterleitet. Anstatt andere µCs zu nehmen, bietet gerade der ATmega328 (o.ä.) eine elegante Möglichkeit, nicht nur die digitalen Signale zu zählen, sondern bei anliegenden phasenverschobenen Sinussignalen eine Interpolation vorzunehmen. Was ich bei den einfachen, schnellen Dekodervorschlägen immer vermisse, ist die Möglichkeit, einen Indeximpuls auszuwerten. Meines Erachtens ist es praxisfern, dies wegzulassen. Baut man diese Möglickeit bei 'normalen' Dekodern dazu, sinkt dadurch die maximale Zählrate. Zu schnell, mit Index und günstig (RP2040) gibt es an anderer Stelle einen Beitrag: Beitrag "schneller Quadratur-Dekoder A/B+Index mit RP2040, Arduino" Wenn der TO aber per ISR auswerten möchte, soll er es meinetwegen ruhig machen. Zur Begrenzung der max. Eingangsfrequenz reichen im einfachsten Fall RC-Glieder an den Eingängen. Die internen Schmitttrigger bereiten die Signale wieder passend auf.
Mi N. schrieb: > Es gibt als 3. Weg Klar, es gibt Umwege und Sackgassen. Mi N. schrieb: > Wenn der TO aber per ISR auswerten möchte, soll er es meinetwegen ruhig > machen Vorausgesetzt, du musst später das Gerät nicht bedienen. Es gibt keinen sinnvollen Grund, es NICHT so zu machen wie es simpel perfekt funktioniert, per Timer, bloss weil man noch nicht ahnt, wann die Problemen der anderen Methoden auftreten (ein kleiner Hinweis könnte sein, dass Timerinterrupts auch die Info liefern, wann zu schnell gedreht wurde, der übliche Flankencode aber nicht). Wenn der Prozessor nicht die Rechenzeit fur Timerinterrupt übrig hat, hat er auch nicht die Rechenzeit Flankeninterupts zu bearbeiten, und wenn er die Flankeninterrupts bearbeiten könnte, kann er auch den einfacheren und schnelleren code des Timers bearbeiten. Aber Mino hat sich schon seit ewiger Zeit als 100% lernresistent gezeigt. Ja, Prozessoren ohne Timer, oder im sleep, brauchen ggf. anderen code, z.B. aufwachen per Flanke, aber zählen bitte per polling und state machine.
Michael B. schrieb: > Es gibt keinen sinnvollen Grund, es NICHT so zu machen wie es simpel > perfekt funktioniert, per Timer Es gibt nur wenige Gründe, aber es gibt sie (s. mein obiger Beitrag). Es gibt auch nur wenige Gründe, die Encoderauswertung noch in Software zu machen, trotzdem kleben viele an diesem Vorgehen fest. > ein kleiner Hinweis könnte sein, dass sich die Technik seit dem 8048 stark weiterentwickelt hat (s. ebenfalls mein obiger Beitrag). > dass Timerinterrupts auch die Info liefern, wann zu schnell gedreht > wurde, der übliche Flankencode aber nicht Der Code des TE tut das in gleicher Weise, aber vermutlich entspricht er nicht dem, was du als "üblich" ansiehst. Wenn du "üblich" mit "fehlerbehaftet" gleichsetzt, hast du natürlich recht. Unter dieser Prämisse funktioniert aber auch der "übliche" Timer-Code nicht.
Yalu X. schrieb: >> dass Timerinterrupts auch die Info liefern, wann zu schnell gedreht >> wurde, der übliche Flankencode aber nicht > > Der Code des TE tut das in gleicher Weise Mit üblich meine ich dass üblicherweise Flankeninterruptcode keine Info über zu schnelles drehen liefert, üblich heisst nicht immer sondern oft, überwiegend häufig. Bezieht sich also nicht auf 1 Stichprobe.
Michael B. schrieb: > keine Info > über zu schnelles drehen liefert Wayne... Ne im ernst wen, es soll ja solche und solche geben!
Michael B. schrieb: > Mit üblich meine ich dass üblicherweise Flankeninterruptcode keine Info > über zu schnelles drehen liefert Neben dieser unsinnigen 'Anforderung' können flankengetriggerte Dekoder ja auch Signale mit viel höherer Geschwindigkeit erfassen. Da verzählt sich eben nichts. Ein Atmega schafft 100 kHz. Verglichen mit einem 100 Hz Timerinterrupt ist das Faktor 1000.
Mi N. schrieb: > Michael B. schrieb: >> Mit üblich meine ich dass üblicherweise Flankeninterruptcode keine Info >> über zu schnelles drehen liefert > > Neben dieser unsinnigen 'Anforderung' können flankengetriggerte Dekoder > ja auch Signale mit viel höherer Geschwindigkeit erfassen. Da verzählt > sich eben nichts. > Ein Atmega schafft 100 kHz. Verglichen mit einem 100 Hz Timerinterrupt > ist das Faktor 1000. Was schreibst du für einen Schwachsinn. Und das obwohl du schon an früheren Diskussionen um Drehgeberauswertung teilgenommen hast. Ein Atmega, um bei deiner Prozessorwahl zu bleiben ohne Hardwardecoder, schafft 4 Drehgeber mit 1 Mio Strichen pro Sekunde, oder 1 mit 2 Mio, per Abtastung wie bereits in diesem thread verlinkt, das ist schlicht und einfach per Flankeninterrupt nicht mal ansatzweise schaffbar. Also bitte verunstalte das Forum nicht mit deinem an den Haaren herbeigezogenen Unfug.
Michael B. schrieb: > Ein Atmega, um bei deiner Prozessorwahl zu bleiben ohne Hardwardecoder, > schafft 4 Drehgeber mit 1 Mio Strichen pro Sekunde, oder 1 mit 2 Mio, > per Abtastung wie bereits in diesem thread verlinkt, Und dabei wird dann noch erkannt, ob zu schnell gedreht wurde? Du redest Dich mal wieder um Kopf und Kragen. Eine Schaltung mit unverdrahteten Eingängen könnte noch schnellere Signale 'verarbeiten' und ist genauso praxisfern ;-)
Mi N. schrieb: > Und dabei wird dann noch erkannt, ob zu schnell gedreht wurde? Guck doch einfach rein in den Code und palaver nicht wie die Jungfrau vom Kinde.
Michael B. schrieb: > Mi N. schrieb: >> Und dabei wird dann noch erkannt, ob zu schnell gedreht wurde? > > Guck doch einfach rein in den Code und palaver nicht wie die Jungfrau > vom Kinde. Er hält das halt für Humbug, er müsse ja nen Akkuschrauber anflanschen... :´DDD
Michael B. schrieb: > Ein Atmega, um bei deiner Prozessorwahl zu bleiben ohne Hardwardecoder, > schafft 4 Drehgeber mit 1 Mio Strichen pro Sekunde, oder 1 mit 2 Mio, > per Abtastung wie bereits in diesem thread verlinkt, Die dort implementierte Auswertung gefällt mir sehr gut, Daumen hoch! Die "knapp 1 Msps" erinnert mich aber etwas an Marketinggeschwätz. Natürlich kann dieser Wert erreicht werden, dann tut der Controller aber nichts anderes mehr. Man kann allenfalls davor sitzen und sich in Gedanken vor Augen führen, wie in seinem Inneren gerade die Inkremente in den vier Registern rasend schnell hochgezählt werden ;-) Michael B. schrieb: > Mi N. schrieb: >> Und dabei wird dann noch erkannt, ob zu schnell gedreht wurde? > > Guck doch einfach rein in den Code und palaver nicht wie die Jungfrau > vom Kinde. Ein einfaches "Nein" hätte dich nur 4 statt 80 Tastenanschläge gekostet.
Yalu X. schrieb: > Die "knapp 1 Msps" erinnert mich aber etwas an Marketinggeschwätz. > Natürlich kann dieser Wert erreicht werden, dann tut der Controller aber > nichts anderes mehr. Man kann allenfalls davor sitzen und sich in > Gedanken vor Augen führen, wie in seinem Inneren gerade die Inkremente > in den vier Registern rasend schnell hochgezählt werden ;-) Genau das ist der Punkt! Hier habe ich einen Lineargeber (Glas) mit 600 mm Länge und 1 µm Auflösung. Der Referenzindex wird etwa in der Mitte ausgegeben und die max. Verfahrgeschwindigkeit liegt bei <= 1 m/s, was einem minimalen Flankenabstand von 1 µs entspricht. Um beim Einrichten die absolute Position zu erhalten, muß eine Fahrt über den Ref.-Index ausgeführt werden. Wo ist nun die Schaltung, das Programm mit einem ATmega, an dessen Eingängen PH-A, PH-B und REF angeschlossen werden und auf einer LC-Anzeige die aktuelle Position angezeigt wird?
Mi N. schrieb: > Genau das ist der Punkt! > Hier habe ich Der Punkt ist: du hast nicht, sondern dir gerade etwas zusammenkonstruiert. Etwas, das dein Flankeninterrupt NIEMALS schaffen kann (du selbst traust ihm nur 0.1Msps zu), beim polling hingegen liegt es im Bereich des Möglichen (2Msps bei nur 1 ausgewerteten Encoder, da wäre 50% Zeit für Auswertung, das sollte zu schaffen sein).
von Yalu X.(yalu) (Moderator) 30.12.2024 00:33 Danke, das ist Kritik die A. sinnvoll B. nachhaltig C. auf einem entsprechenden Niveau ist und dadurch annhembar. Mir ist durchaus bewusst das ein Prellen bei dieser Methode sich nicht ganz wegdiskutieren lässt. Für meine Anwendung aber aussreichend. Soll einfach ein simple Menüsteuerung werden die ich mal 2005 mit Tastern umgesetzt hatte... Michael B. schrieb: > Guck doch einfach rein in den Code und palaver nicht wie die Jungfrau > vom Kinde. Also keine HIGH Noblêêê Deluxe MultiProof Raketenwisschaftsanwendung und trotzdem ist der Marsrover abgestürzt... Und die sind nur an der Umrechnung vom imperialen zum metrischen System gescheitert. Somit Platz 1 der Erfahrung... Yalu X. schrieb: > Es gibt auch nur wenige Gründe, die Encoderauswertung noch in Software zu > machen, trotzdem kleben viele an diesem Vorgehen fest. Die Frage nach dem Stand der Technik kam beim durchlesen verschiedener Encoderbeiträge nebulös daher. Michael B. schrieb: > Mit üblich meine ich dass üblicherweise Flankeninterruptcode keine Info > über zu schnelles drehen liefert, üblich heisst nicht immer sondern oft, > überwiegend häufig. Ahja und mit der Flanke nen Timer starten geht bei mir also nicht ? Weil ? War auch nicht im privaten Pflichtenheft festgeschrieben das er das können soll... Michael B. schrieb: > Ein Atmega, um bei deiner Prozessorwahl zu bleiben ohne Hardwardecoder, > schafft 4 Drehgeber mit 1 Mio Strichen pro Sekunde, oder 1 mit 2 Mio, > per Abtastung wie bereits in diesem thread verlinkt, > > das ist schlicht und einfach per Flankeninterrupt nicht mal ansatzweise > schaffbar. Frage wo nimmst du diese nibolösen Pflichtenhefte immer her ? Würde ich zb 4 Drehgeber auf eine Port geben könnte man mit den PCInterrupt die selbe Routine anspringen, bei pos/neg Flanke anspringen und auswerten. Aber jetzt kommts, das will ich gar nicht!! Es wird keine V13 mit 16 Leitwerken die du immer entwickeln willst. Zusätzlich müsste man für so ein Vorhaben, komplett anders vorgehen! Da reicht alleine der Prozessor in keinster Weise... WO sind eigentlich deine Quelltexte in diesen Forum ? Oder noch besser warum ergänzt du den Artikel Drehencoder nicht einfach mit deinem massiven Wissen welche HW heute Up to Date sind? Mit ausführlicher Erklärung Pros und Cons ? Das einzige was ein Mensch mit ins Grab nimmt, sind weder materialle oder monetöre Dinge, sondern Wissen welches angehäuft wurde aber nie das Tageslicht gesehen hat... Also lass uns doch auf einem vernünftigen Niveau Wissensaustausch betreiben. So kann und will dich keiner ernst nehmen. Du kannst und weißt auch nicht alles und auch nur durch lesen von Erfahrungen Anderer, heißt es nicht das du es verstanden hast und auch wenn du es verstanden hättest, ist das Verstehen ebend nur ein Trostppreis!! So mit bleibt nur pure Erfahrung als Platz 1 übrig...
:
Bearbeitet durch User
Chris S. schrieb: > Ahja und mit der Flanke nen Timer starten geht bei mir also nicht Welchen Krieg führst du hier ? Du hast anständigen Code mit Timerinterruptauswertung. Kurz, übersichtlich, funktionierend, halt nicht selbst geschrieben sondern gefunden. Dann kommst du, machst ihn länger, unelegant, unübersichtlicher, langsamer, und ahnst noch nicht mal wann er nicht funktionieren wird bzw. welche Probleme die Integration in ein Gesamtprogramm liefern wird wegen Pinbelegung und Ressourcen. Jeder normale Mensch stampft den Müll dann wieder ein, aber nicht du: es wird jetzt mit Krallen aus Teufel komm raus verteidigt. Weil dazu jegliche Argumente fehlen kommen abstruseste Behauptungen. Wozu ? Drehencoderauswertung ist gelöst, es gibt dazu eine best practice, eleganten kurzen Code.
Michael B. schrieb: > Welchen Krieg führst du hier ? Gar kein wer aber jedes mal abgeht wie ne Tüte Mücken, muss sich selbst nicht wundern das der Hall aus dem Wald sich als MItkopplung widerspiegeln kann. ;) > Du hast anständigen Code mit Timerinterruptauswertung. Kurz, > übersichtlich, funktionierend, halt nicht selbst geschrieben sondern > gefunden. Wie bitte ? Das man einen Ansatz brauchte weil die eigenen Versuche zwar in die richtige Richtung gingen aber ebend unvollständig waren, siehe Torwart und glitschiger Ball, sowas kennt jeder. Daher ist kopieren, verstehen und dann umsetzen auf andere Pins ganz legitim. Lesen/Schreiben und Rechnen hast du uch nur als Kopie gelernt und war nicht dein geistiger Ergus, sondern der anderer... Also einfach mal runter kommen, geh mal spazieren oder ordentlich sporten dann passt das auch... Michael B. schrieb: > bzw. welche Probleme die Integration in ein Gesamtprogramm liefern wird > wegen Pinbelegung und Ressourcen. NÖ, der wird auch auf allen Pins laufen bitte Quellcode & PLatzhalter nachvollziehen ... Michael B. schrieb: > Drehencoderauswertung ist gelöst, es gibt dazu eine best practice, > eleganten kurzen Code. Na dein Code ist so kurz das man den gar nicht sieht, weder in Artikeln um Wissen zu vermitteln oder gar mal sinnvolle Beispiele...
Chris S. schrieb: > ist so kurz das man den gar nicht sieht, Dazu muss man beide Augen aber fest zudrücken. Na ja, nicht jeder startet ins neue Jahr mit offenen Augen, man einer ist zu faul, Links zu folgen.
Moin, lass Dich nicht ärgern. Dein Projekt finde ich sehr interessant. Mein Schrittmotor-Projekt möchte ich mit einen günstigen Drehgeber erweitern, um Werte einzustellen. Die beiden Ausgänge vom Drehgeber würde ich auf jeweils einen Pin von Port B und C legen. Mit den unterschiedlichen PCI- Adressen lässt sich feststellen, welcher Pin sich geändert hat und mit den Pegeln die Drehrichtung. In der ISR sperre ich den aktuelle Interrupt und aktiviere den jeweils anderen, weil die nächste gültige Änderung nur vom jeweils anderen Pin kommen kann. Dadurch brauche ich keine weitere Entprellung. Die Speicherung des alten Zustandes ist auch nicht notwendig. Zur Zeit bin ich in Urlaub und kann nichts ausprobieren. Gruß Carsten
Carsten-Peter C. schrieb: > Moin, > lass Dich nicht ärgern. Dein Projekt finde ich sehr interessant. Mein > Schrittmotor-Projekt möchte ich mit einen günstigen Drehgeber erweitern, > um Werte einzustellen. Die beiden Ausgänge vom Drehgeber würde ich auf > jeweils einen Pin von Port B und C legen. Mit den unterschiedlichen PCI- > Adressen lässt sich feststellen, welcher Pin sich geändert hat und mit > den Pegeln die Drehrichtung. In der ISR sperre ich den aktuelle > Interrupt und aktiviere den jeweils anderen, weil die nächste gültige > Änderung nur vom jeweils anderen Pin kommen kann. Dadurch brauche ich > keine weitere Entprellung. Die Speicherung des alten Zustandes ist auch > nicht notwendig. Zur Zeit bin ich in Urlaub und kann nichts > ausprobieren. > Gruß > Carsten Naja es ist eher eine Vorarbeit als das eigentliche Projekt. Bin gerade am erstellen der Platinen. Beachte das die PCIs innerhalb ihrer PCI-Gruppe den selben Interrupt nutzen. Umschalten brauchste eigentlich da PCIs auf beiden Flanken reagieren zb PhA mit positiver Flanke kam kann nur PhA mit negativer oder PhB mit postiver Flanke kommen. Die Speicherung des alten Zustandes dient der Drehrichtungserkennung. Probiers einfach aus.
Carsten-Peter C. schrieb: > In der ISR sperre ich den aktuelle > Interrupt und aktiviere den jeweils anderen, weil die nächste gültige > Änderung nur vom jeweils anderen Pin kommen kann. Dadurch brauche ich > keine weitere Entprellung. Das wir lustig... Nimm aber bitte nen "Eingefahrenen" Geber! Die kratzen so schon. :)
Carsten-Peter C. schrieb: > In der ISR sperre ich den aktuelle Interrupt und aktiviere den jeweils > anderen, weil die nächste gültige Änderung nur vom jeweils anderen Pin > kommen kann. Das funktioniert nicht, nicht einmal mit einem prellfreien Encoder. Wenn nämlich die Drehrichtung geändert wird, entsteht zweimal direkt hintereinander ein Pegelwechsel auf demselben Pin. Der zweite Wechsel – und damit ein Zählschritt – würde mit deinem Verfahren verloren gehen.
Es wurde schon alles gesagt. Nur noch nicht von jedem. ;-)
Yalu X. schrieb: > Das funktioniert nicht, nicht einmal mit einem prellfreien Encoder. Moin, ich habe noch einen alten Drehgeber von ALPS gefunden und an meine Schrittmotorsteuerung angeschlossen. Im Anhang ist der Ablauf kurz beschrieben, falls es jemanden interessiert. Der Nachteil: Es werden 2 PCIE Adressen gebraucht. Da ich keine freien Timer hatte und keine zyklischen Unterbrechungen wollte, kam diese Entprellung nicht in Frage. Ein Pollen ging wegen der sehr unterschiedlichen Laufzeiten der Hauptschleife auch nicht. Die Entprellung erinnert mich an die mit einem RS-FF. Das Programm funktioniert auch beim Richtungswechsel bei mir gut. Es ist klein und schnell und braucht nur eine Speicherstelle im SRAM. Sicher findet man auch eine Version mit nur einem PCIE. Wurde ja schon 1000 mal diskutiert. Gruß Carsten
Carsten-Peter C. schrieb: > Das Programm funktioniert auch beim Richtungswechsel bei mir gut. So
1 | Drehrichtungsänderung |
2 | : |
3 | A ____-_-----------_-_______----:---__ |
4 | : |
5 | B __________-_---------_-_______:_____ |
6 | |
7 | x +1 +1 +1 +1 +1 -1 |
Ich sehe dein -1 nicht.
:
Bearbeitet durch User
ich verstehe die Titelfrage nicht mal! ASM ist unnötig und im Timerinterrupt kann man mehr als Drehencoder auswerten, einfach Flags setzen und wenn Zeit ist langsamere Routinen bearbeiten, es ist ja nie nötig all Routinen in µs abzuarbeiten, manche Dinge haben viele ms Zeit z.B. Display aktualisieren (mehr als 5 kann keiner ablesen, 10x allenfalls das eine Uhranzeige flüssiger läuft) ADC das Rauschen einfangen ist auch nicht sinnvoll, also Mittelwert bilden.
Michael B. schrieb: > Ich sehe dein -1 nicht. Mit der Flanke von A wird der Pegel von B in Speicherstelle MBinB geschrieben. Der ist jeweils unterschiedlich und gibt die Richtung vor. Er wird nur ausgewertet, wenn A =0 ist. Probier es einfach aus. In DrehB1: kannst Du festlegen, was passieren soll. Gruß Carsten
Carsten-Peter C. schrieb: > Probier es einfach aus. Dito Haste nen alten "eingeradelten" ALPS? So richtig "lustig" wird's erst, wenn alle Kontakte, zu kratzen beginnen!
Teo D. schrieb: > So richtig "lustig" wird's erst, wenn alle Kontakte, zu kratzen > beginnen! Moin, Du sprichst die Grenzen der Auswertung an. Wenn ein Kontakt noch flattert und der jeweils andere schon schaltet, wird es schwierig. Es ist dabei egal, ob sehr langsam oder sehr schnell gedreht wird. Wenn ein Drehgeber irgendwann so schlecht ist, kann man ja auch 5€ für einen Neuen ausgeben. Gruß Carsten
Carsten-Peter C. schrieb: > Drehgeber irgendwann so schlecht ist, kann man ja auch 5€ für einen > Neuen ausgeben. Warum neu, richtig ausgewertet ist das kein Problem! Billig ALPS, müsste man(n) dann ja schon nach ca. 0,5-2 Stunden Kurbeln, erneuern... Carsten-Peter C. schrieb: > Wenn ein Kontakt noch > flattert und der jeweils andere schon schaltet, wird es schwierig. Du hast da drei Kontakte und alle schleifen, kratzen und prellen. Es gibt auch bessere, die sicher auch länger halten und faule Programmierer eher tolerieren. Carsten-Peter C. schrieb: > Du sprichst die Grenzen der Auswertung an. Nicht "meiner". Bei mir funktioniert das problemlos... :) Funst wie hier schon angesprochen, wie bei Tastern auch. Kein Hexenwerk!
Wenn beide Kanäle des Encoders gleichzeitig prellen oder kratzen, ist eine zuverlässige Auswertung unmöglich, egal mit welchem Verfahren. Es gibt dann einfach kein Kriterium, um gewollte Zustandswechsel von ungewollten zu unterscheiden.
Yalu X. schrieb: > Wenn beide Kanäle des Encoders gleichzeitig prellen oder kratzen, ist > eine zuverlässige Auswertung unmöglich, egal mit welchem Verfahren. Es > gibt dann einfach kein Kriterium, um gewollte Zustandswechsel von > ungewollten zu unterscheiden. Es ist davon auszugehen, das es mehr "stabile" Zustände gibt als das es kratzt!? Ich entpelle das wie Taster (oh wunder), angepasste kürzere Timings... Und was soll ich schreiben, es tut mehr als zufriedenstellend und das bei diesen Grotten schlechten Teile, die ich mir da andrehen hab lassen. Mit simpler "Entprellung", ohne einen stabilen Zustand zu detektieren, sind das nur noch Zufallsgeneratoren. Irgendwann is da natürlich auch Schluss. Nur tun die halt nun grob gelogen schon das 50-100 fache an gekurble.
Yalu X. schrieb: > Wenn beide Kanäle des Encoders gleichzeitig prellen oder kratzen, > ist > eine zuverlässige Auswertung unmöglich, egal mit welchem Verfahren. Es > gibt dann einfach kein Kriterium, um gewollte Zustandswechsel von > ungewollten zu unterscheiden. Da die billigen Encoder Schleifkontakte haben, und die in den Lücken nicht schleifen sondern nur auf den Kontaktstreifen, die Aussetzer dort aber prozentual viel weniger ausmachen als die Zeit die der Schleifer Kontakt gibt, kann man das Problem mit einer RC Entprellung vor dem Schmitt-Trigger Eingang lösen. Der niederohmige Kontakt des Schleifers entlädt schnell, der pull up lädt langsam auf, und im Endeffekt bleibt die Spannung immer unter der Schmitt-Trigger-Schelle.
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.