habe nun das erste mal mit Drehencodern zu tun, da ich eine eine Menüsteuerung machen möchte. So wie ich das sehe muss ich nur feststellen auf welchem Kanal die erste Flanke auftritt und schon habe ich Richtung ich führe dann einen Schritt in diese Richtung aus. Um dann ein evtl. Prellen aus dem Weg zu gehen würde ich einfach die Interrupts für eine gewisse Entprellzeit (bis zur 2ten roten Linie) sperren. So sollte ich ein sehr schnelles reagieren erreichen ohne zusätzlichen Abtastvorgänge. Die Entprellzeit könnte man auch noch nach der Zeitdifferenz der beiden Flanken nachjustieren. Was haltet ihr von dieser Lösung?
Angehängte Dateien:
-
Signal_Drehencoder.png
991 Bytes
:
Thomas O. schrieb: > Was haltet ihr von dieser Lösung? Typisch der erste Versuch der dann ewig Probleme nach sich zieht. Mach's gleich richtig: http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.29
1000mal hier besprochen - keine Flankentriggerung bei mech. Encodern, sondern Abtastung in festen Intervallen. Immer wieder kommen Neuerfinder, die das so oder ähnlich versuchen wollen. Funktioniert sogar meist anfangs, wird aber im Lauf der Zeit immer schlechter bis absolut unbrauchbar.
Dieser Standardfrage ist hier sogar ein Artikel gewidmet: https://www.mikrocontroller.net/articles/Drehgeber
Moin, naja selber machen hat ja noch niemanden geschadet. Wenn man optische oder magnetische Geber hat, dann hat man wenigstens nicht die mechanischen Probleme. Bei den rein mechanischen Billiggebern merkt man am Rastpunkt ob die Auswertung etwas taugt. Verschleiß und eventuell zunehmendes Prellen kann eine jetzt funktionierende Routine später nicht mehr richtig funktionieren lassen. Ich habe eine AVR-ASM-Routine, die für 2,3,4 Impulse pro Rastschritt funktioniert. Da kann ich so schnell mit der Hand nicht drehen. Selbst ein Akkuschrauber bringt die Routine nicht aus der Fassung. Ich frage zwei Drehgeber inklusive Taster 1000x pro Sekunde ab. Man findet natürlich genügend Bullet-Proof-Beispiele hier. Peter Dannegger hat ja einiges veröffentlicht. Holger
Holger D. schrieb: > Moin, naja selber machen hat ja noch niemanden geschadet. Wenn man > optische oder magnetische Geber hat, dann hat man wenigstens nicht die > mechanischen Probleme. Aber die gleichen mit anderer Ursache. Du hast den Artikel nicht gelesen.
> Aber die gleichen mit anderer Ursache. Du hast den Artikel nicht > gelesen. Ich denke ja manchmal das Problem ist fuer viele Menschen schon zu Abstract oder da schimmert deutlich durch das denen die Grundladen der Etechnik fehlen. :) Olaf
Holger D. schrieb: > Ich habe eine AVR-ASM-Routine, die für 2,3,4 Impulse pro Rastschritt > funktioniert. 3 Impulse pro Rastschritt hört sich - vorsichtig formuliert - "kunstvoll" an. Das geht IMHO nur mit einer 4-Impulsauswertung, die bei der Ausgabe eine Zustand unterschlägt. Sonst funktioniert 2-Bit Gray-Code nicht.
Olaf schrieb: > Ich denke ja manchmal das Problem ist fuer viele Menschen schon zu > Abstract oder da schimmert deutlich durch das denen die Grundladen der > Etechnik fehlen. :) Das ist ja nicht verwerflich. Aber warum nehmen die dann nicht erprobte SW von Leuten, die das Problem verstanden haben?
Olaf schrieb: > Ich denke ja manchmal das Problem ist fuer viele Menschen schon zu > Abstract oder da schimmert deutlich durch das denen die Grundladen der > Etechnik fehlen. :) Anderen fehlen dafür die Grundlagen der Rechtschreibung und trotzdem kommen alle irgendwie durchs Leben ;-)
Lasst doch die Leute mal in Ruhe knobeln und tüfteln, statt immer gleich von oben herab auf die vorgekauten "Bullet-Proofs" zu verweisen, die nicht selten auch softwaremässiger Overkill sind... Durch try and error lernt man mehr als durch copy and paste... Nicht zuletzt geht es beim µC-Hobby auch um Knobelei und Rätsel-Lösen mit Nutzen dahinter... Würdet ihr ihnen sachliche Gründe liefern, warum ihr Lösungsansatz suboptimal ist, könnte das dieses Lernerlebnis deutlich verstärken...es wäre kollegialer und deutlich empathischer, als stets sofort inhaltlos die persönlich abwertende Arroganzkeule des Überfliegers zu schwingen und sich an jedem fragenden Neuling-Opfer abzureagieren...
Simpel schrieb: > Durch try and error lernt man Nein, wie man an hunderten kommerzieller Geräte sieht, deren Drehencoder hakelt. Simpel schrieb: > Würdet ihr ihnen sachliche Gründe liefern, warum ihr Lösungsansatz > suboptimal ist Wird in den verlinkten Artikeln für die du zu faul warst ihnen zu folgen getan.
Man muss selbst experimentieren und man muss sich das Gemessene auf Millimeterpapier vergegnwärtigen. Dann kommt man darauf, wie es "in Natura" funktioniert und wie man das auswerten kann. Eventuell kommt man dabei zu einer Routine, die von den gezeigten abweicht und trotzdem funktioniert. Der größte Fehler wäre dann, sie heir zu veröffentlichen und sich dadurch in endlose, völlig fruchtlose Streitereien zu verwickeln.
EncoderDreher schrieb: > Man muss selbst experimentieren und man muss sich das Gemessene auf > Millimeterpapier vergegnwärtigen. Ist fraglich, wie man Dinge wie Kontaktprellen auf Millimeterpapier simuliert, ohne dass man sie vorher bspw. am Oszi oder LA gemessen hat. Wenn man sie aber dort gemessen hat, braucht man auch das Millimeterpapier nicht mehr. Denn darum geht es in all diesen Routinen vorrangig: einen schönen sauberen Gray-Code kann man einfach und auf verschiedene Weise decodieren. Sowas geben aber bestenfalls die teuren optischen Geber von sich. Einen "real verwackelten" dagegen zu decodieren, ist die eigentliche Kunst und der Punkt, wo die schönen einfachen Lösungen schnell an ihre Grenzen kommen. Da stellt das Heizungsventil dann beim Rechtsdrehen des Stellrads nur noch mit Glück die Temperatur nach oben …
Andreas B. schrieb: > Aber die gleichen mit anderer Ursache. Du hast den Artikel nicht > gelesen. Muss ich auch nicht, da meine Routine perfekt ist! Es mag andere Lösungen geben. Holger
:
Bearbeitet durch User
Holger D. schrieb: > Muss ich auch nicht, da meine Routine perfekt ist! Es geht doch nichts über ein gesundes Selbstbewußtsein. ;-) Das würde ich Dir glauben, wenn Du den Artikel komplett gelesen, verstanden und dann immer noch zu diesem Schluss kommen würdest. Und das hier: Holger D. schrieb: > Ich habe eine AVR-ASM-Routine, die für 2,3,4 Impulse pro Rastschritt > funktioniert. läßt mich doch sehr daran zweifeln.
:
Bearbeitet durch User
Jörg W. schrieb: > EncoderDreher schrieb: >> Man muss selbst experimentieren und man muss sich das Gemessene auf >> Millimeterpapier vergegnwärtigen. > > Ist fraglich, wie man Dinge wie Kontaktprellen auf Millimeterpapier > simuliert, ohne dass man sie vorher bspw. am Oszi oder LA gemessen hat. Was soll das? Es steht doch da: Das Gemessene Nicht jeder besitzt einen Speicheroszi oder auch einen Mehrkanaler, um sich beide "Spuren" simultan anzusehen. > Wenn man sie aber dort gemessen hat, braucht man auch das > Millimeterpapier nicht mehr. Jeder hat eine andere Herangehensweise, um Vorgänge in ihre zeitlichen Abläufe zu zerlegen.
EncoderDreher schrieb: > Jeder hat eine andere Herangehensweise, um Vorgänge in ihre zeitlichen > Abläufe zu zerlegen. Und wie machst Du das mit den Kontaktprellen auf Millimeterpapier? Oder das Schwingen einer Welle und das dadurch resultierende Signal? Das denkst Du Dir dann aus und malst dann schöne Kurven oder wie darf man sich das dann vorstellen?
Andreas B. schrieb: > EncoderDreher schrieb: >> Jeder hat eine andere Herangehensweise, um Vorgänge in ihre zeitlichen >> Abläufe zu zerlegen. > > Und wie machst Du das mit den Kontaktprellen auf Millimeterpapier? Oder > das Schwingen einer Welle und das dadurch resultierende Signal? Das > denkst Du Dir dann aus und malst dann schöne Kurven oder wie darf man > sich das dann vorstellen? Richtig, genau so mache ich das... Ich denke nicht, daß es Sinn hat, das hier weiter zu erörtern, wenn es an Vorstellungsvermögen so sehr mangelt.
EncoderDreher schrieb: > Man muss selbst experimentieren und man muss sich das Gemessene auf > Millimeterpapier vergegnwärtigen. Dann kommt man darauf, wie es "in > Natura" funktioniert und wie man das auswerten kann. Es ist weit bekannt und dokumentiert, wie ein Drehgeber funktioniert. Dazu braucht man nicht zu experimentieren, sondern muß nur die vorhandene Dokumentation mal lesen. > Eventuell kommt man dabei zu einer Routine, die von den gezeigten > abweicht und trotzdem funktioniert. Das ist unwahrscheinlich. Alle "Abkürzungen", die ich bisher gesehen habe, hatten das Problem, daß sie nur unter Randbedingungen funktionieren, die in der Praxis dann aber nicht gegeben sind. Die kanonische Implementierung als endlicher Automat, bei dem nur die zyklischen Zustandsübergänge erlaubt sind, ist im Gegenteil beweisbar robust gegen jede Art von Prellen, Flattern, Jitter usw. Außerdem ist sie auch noch unkomplizierter und resourcenschonender als die meisten Alternativen. Die Hürde, etwas besseres zu entwickeln, liegt ausgesprochen hoch. Die Wahrscheinlichkeit, daß das jemand schafft, der noch nicht mal die genannte kanonische Auswertung kennt ist praktisch gleich Null.
Andreas B. schrieb: > läßt mich doch sehr daran zweifeln. Dann tue es. Die Realität sieht anders aus. Aber wahrscheinlich kannst Du nur Cut & Paste und nachplämpern.
Axel S. schrieb: > Die Wahrscheinlichkeit, daß das jemand schafft, der noch nicht mal die > genannte kanonische Auswertung kennt ist praktisch gleich Null. Volle Zustimmung. Holger D. schrieb: > Aber wahrscheinlich kannst > Du nur Cut & Paste und nachplämpern. Ich habe den Artikel gelesen und, im Gegensatz zu Dir, das Problem auch verstanden. Und ja, wenn ich das brauche, kopiere ich das mit nur leichten Änderungen, die aber den Kern der Funktion nicht ändern. Wenn das bei Dir aktuell funktioniert: Schön für Dich. Ich gehe auch oft bei rot über die Ampel. Nie was passiert.
Andreas B. schrieb: > Ich habe den Artikel gelesen und, im Gegensatz zu Dir, das Problem auch > verstanden. Schön, dass Du Probleme verstehst. Ich habe kein Problem, sondern für mich eine Aufgabenstellung zufriedenstellend gelöst. Du kannst das gerne bezweifeln. Es ist mir vollkommen egal!
Angehängte Dateien:
-
DS1Z_QuickPrint1.png
33 KB -
DS1Z_QuickPrint2.png
32 KB -
DS1Z_QuickPrint3.png
32 KB
eure Meinung scheint ja gefestigt zu sein, schade das es kein richtiges Argument gibt wieso es nicht gehen sollte, wenn man seine Software im Griff hat. So stelle ich mir den Ablauf vor 1. der µC erkennt einen Flankenwechsel am Kanal A (Rechtsdreh) springt 2. in die IR-Routine 3. sperrt weitere IRs und ändert z.B. ein Byte von 127 auf 255 (für eine Rechtsbewegung) 4. springt wieder raus 5. weiter im Programmablauf mit Abfrage ob ein Rechtsdreh (255) oder eine Linksdreh (0) gespeichert ist 6. Ausführung der Links/Rechts Aktion 7. Zurückstezten des Bytes auf 127 8. IR Aufruf nach Sperrzeitablauf 9. Prüft ob beide Kanäle den gleichen Pegel (Ruhezustand haben, sonst könnte es noch prellen falls man die Sperrzeit sehr kurz wählt) und gibt dann die Flankentriggerung wieder frei, springt raus 10. weiter im Programm Prellen kommt bei der Low High Flanke bei sehr schnellem Drehen vor, allerdings ist dies nach 200µSek abgeklungen. Wobei mein Messaufbau den Worstcase darstellt erst vom Dekoder 20 cm zu einem Steckboard, eine 1 Meter Zuleitung einer Wandwarze und dann noch die Tastköpfe ohne Federklammer gemeinsam über einen weiteren Draht auf die Masse. Ich hänge mal alle 3 Dateien an, die letzte mit der High Low Flanke hat es anscheinend zerschossen. (Oder kennt jemand einen WEG den USB-Stick am Rigol DS1054Z sauber abzumelden?)
Mach es doch einfach wie du willst. Und irgendwann später machst du es dann auch richtig, nennt sich Lernen.
Moin Thomas, probiere es aus. Du wirst hier keine Antworten bis auf die beiden links bekommen. Schau Dir die Artikel an. Du bekommst Lösungen serviert. Ich persönlich würde die Problemlösung selber entwickeln. Holger
Thomas O. schrieb: > eure Meinung scheint ja gefestigt zu sein, Das nennt man Erfahrung. > schade das es kein richtiges Argument gibt wieso es nicht gehen sollte, > wenn man seine Software im Griff hat. Merkwürdig, welche Selbstüberheblichkeit die Lernresistenten so an den Tag legen. Du kannst prinzipielle Probleme nicht mit Programmiererhanselkram in den Griff bekommen. Ich dachte mir schon, daß du schon so viele Jahre hier im Forum bist, daß du schon gehört haben müsstest, wie man Drehgeber korrekt auswertet. Insofern konnte dein Thread nur ein Trollposting sein. Deine Lernresistenz zeigt den Troll deutlich. Die Auswertung mit dem genannten Verfahren ist - einfach (d.h. wesentlich kürzer in Befehlsanzahl und Laufzeit programmierbar als deine Flankenauswertung) - zuverlässig (sie basiert nicht auf der Hoffnung, daß der uC, wenn man dreht, noch genug Rechenleitung übrig hat um die Flankenwechsel zu verarbeiten) - robust (gegen Prellen und ähnliche Effekte) - erkennt wenn sie überfahren wird, also nicht mehr korrekt arbeitet - schnell (mit der Methode kann man deutlich schnelleren Drehgeberbewegungen folgen als mit der unsäglichen Flankenwechselinterruptmethode) Es gibt NULL Grund, es anders zu machen, ausser Borniertheit. "der uC hat nichts zu tun wenn der Drehgeber nicht bewegt wird" ist kein Grund, denn es gibt kein Geld zurück für nicht genutzte Befehle. Aber manche Leute erfinden auch Sortieralgorithmen schlechter neu.
Thomas O. schrieb: > Prellen kommt bei der Low High Flanke bei sehr schnellem Drehen vor, > allerdings ist dies nach 200µSek abgeklungen Na bitte, da haben wir den Fe ler ja schon. Es mag gut sein, daß dieses Exemplar deines Drehgebers im jetzigen Zustand und so wie du dran drehst, höchstens 200µs lang prellt. Aber Drehgeber altern. Keine zwei Exemplare sind gleich. Und es macht einen riesigen Unterschied, wie man dran dreht. Eine Festlegung auf eine bestimmte Prellzeit wird früher oder später zu einer stotternden Auswertung führen. Die Auswertung per Zustandsautomat hingegen braucht gar keine Annahme über die Prellzeit zu machen. Prellen führt dazu, daß sich der Wert um ±1 ändert. Aber Fehler summieren sich nicht auf. Und wenn man die untersten 1-2 Bits sowieso nicht braucht, weil man Halbschritt- oder gar Vollschrittbetrieb fährt (Drehgeber mit Rastung) dann merkt davon gleich gar nichts.
MaWin schrieb: >.... > "der uC hat nichts zu tun wenn der Drehgeber nicht bewegt wird" ist kein > Grund, denn es gibt kein Geld zurück für nicht genutzte Befehle. Zudem läuft praktisch immer ein 1..10ms Timer, um die zeitlichen Abläufe der Anwendung zu steuern. Falls jetzt jemand mit "deep sleep" kommt, ja dabei darf(/meist muß) man den Timer abschalten und das ist dann der Fall, wo der Drehgeber per PinChange-Int überwacht wird. Aber nur bis der erste Dreh die µC aufweckt. Dann schaltet man PinChange wieder ab und sampled wieder via Timer. Zumindest maschen das die bekannten ATmega169 Heizungsthermostaten, die so Monate mit einem Batteriesatz laufen.
ja ich bin schon etwas länger im Forum unterwegs und kenne noch die Zeiten, wo einem Nein eine Begründung folgte. Nur weil es alle so machen, ist für mich kein Grund. Ich werde mich mal die nächsten Tage an den Code machen und berichten ob und wie es läuft, aber aufgrund der Messergebnisse sehe ich hier keine großen Probleme da das Prellen absolut reproduzierbar ist und nicht aus dem nichts auftaucht, sondern direkt nach dem Flankenwechsel und dann auch sehr schnell wieder weg ist. Mein aktuelles Projekt hat nicht so die Anforderung an den µC da dreht dieser eh meist Däumchen und wartet auf den ADC und so ne IR-Routine in .asm ist in 10-15 Takte wieder erledigt, braucht also weder viel Code noch viel Zeit. Da kann ich also etwas Zeit investieren.
Axel S. schrieb: > Die kanonische Implementierung als endlicher Automat, bei dem nur die > zyklischen Zustandsübergänge erlaubt sind, ist im Gegenteil *beweisbar* > robust gegen jede Art von Prellen, Flattern, Jitter usw. Ganz genau. Allerdings kann man genau diesen Automaten auch bauen, wenn man nur Flanken auswertet. Einzige Voraussetzung: man hat die Möglichkeit, "unerwünschte" Flanken zu unterdrücken. Natürlich nicht durch irgendwelches Timing-Entprell-Gelalle, sondern durch simple Stillegung des entsprechenden Flankensensors, nachdem der eine Flanke gesehen hat. Was mich am meisten bei dieser immer wiederkehrenden Diskussion verwundert: auch die Leute, die nach meiner Einschätzung durchaus verstanden haben, dass das (unter den gegebenen Einschränkungen) auch flankenbasiert funktioniert, scheinen immer wieder bei Neuaufflammen der Diskussion ihre früheren Erkenntnisse immer wieder vollkommen vergessen zu haben scheinen... Was soll das? Ich verstehe den Sinn dahinter einfach nicht. Reines Trollgehabe kann man wohl ausschließen. Aber was sonst steckt dahinter?
c-hater schrieb: > auch flankenbasiert funktioniert, scheinen immer wieder bei > Neuaufflammen der Diskussion ihre früheren Erkenntnisse immer wieder > vollkommen vergessen zu haben scheinen... Wahrscheinlich, weil sie mit so einem angeblich doch irgendwie vielleicht im Labor mal funktionierenden Drehgeber dann doch im echten Leben in Berührung kamen. Ob bei Vissmann Heizungen, im Range Rover Radio , im dBx driverack, it sucks. There aint no reason for such a bullshit.
Es gibt meist mehrere Wege die zum Ziel führen. Wenn es aber einen erprobten Weg ohne erkennbare und verbesserungswürdige Nachteile bei gleichzeitig 100%iger Funktionalität gibt würde ich sagen: Optimum/Maximum erreicht, da gibts eben links und rechts nichts mehr, gar nichts.
Thomas O. schrieb: > Prellen kommt bei der Low High Flanke bei sehr schnellem Drehen vor, > allerdings ist dies nach 200µSek abgeklungen. Ich erlaube mir hier jetzt mal die Unterstellung, dass du gar nicht weißt, was Prellen ist oder zumindest eine irrige Vorstellung mit dir herumträgst! Jeder (mechanische) Schalter prellt bei Betätigung. Und ja, es gibt (am Anfang vielleicht) Schalter mit moderatem Prellen, andere prellen sofort wie der Teufel :-) Das hat wenig bis gar nichts damit zu tun, wie schnell du jetzt drückst oder drehst!!! Es wird sogar so sein, dass du bei 100 Betätigungen inerhalb von 200µs gar kein Prellen mehr hast...so kanns gehen... Gruß Rainer
Wie funktioniert diese mehrfach zitierte "kanonische Auswertung" ? Bitte um eine kurze Beschreibung des Prinzips ? Polling, nehme ich an, und dann ? Gruß Jan
Jan B. schrieb: > Wie funktioniert diese mehrfach zitierte "kanonische Auswertung" ? > Bitte um eine kurze Beschreibung des Prinzips ? Das steht im Artikel Drehgeber Einen extra Artikel gibt es genau deswegen, weil das eine FAQ ist. Nur lesen mußt du ihn dann doch noch selber. Thomas O. schrieb: > ja ich bin schon etwas länger im Forum unterwegs und kenne noch die > Zeiten, wo einem Nein eine Begründung folgte. Nur weil es alle so > machen, ist für mich kein Grund. Das ist auch nicht der Grund. Es haben sich eine Menge Leute Gedanken über das Thema gemacht. Und das Ergebnis dieser Gedanken ist die Auswertemethode mit einem Automaten. Beschrieben im Artikel Drehgeber R! T! F! M! > Ich werde mich mal die nächsten Tage an den Code machen und berichten ob > und wie es läuft, aber aufgrund der Messergebnisse sehe ich hier keine > großen Probleme da das Prellen absolut reproduzierbar ist Das ist Bullshit. Prellen ist niemals reproduzierbar. Deswegen nennt man es ja Prellen. > nicht aus dem nichts auftaucht, sondern direkt nach dem Flankenwechsel > und dann auch sehr schnell wieder weg ist. Ja selbstverständlich prellt ein Kontakt unmittelbar nach der Betätigung. Und nur für eine endliche Zeit. Der Mechanismus ist durchaus verstanden (elastischer Stoß, Physik Oberstufe). Nur sind die Randbedingungen halt nicht gut genug bekannt, um eine sinnvolle Prellzeit vorzugeben. Und es gibt auch einen Zielkonflikt. Machst du die Totzeit zu kurz, springt der Wert. Machst du sie zu lang, reagiert der Geber zu träge und kommt beim schnellen Drehen nicht mehr mit. Und nun stell dir vor, es gibt eine Auswertemethode, die diesen Zielkonflikt komplett vermeidet. Die nur eine einzige Grenzbedingung hat: daß das Abfrageintervall kurz genug sein muß, um jeden Zustand aus dem 4er Zyklus wenigstens einmal zu sehen. Das soll dich keineswegs davon abhalten, deinen eigenen Code zu schreiben. Aber wenn du ihn zeigst und argumentieren willst, warum er besser ist, dann brauchst du ein paar verdammt gute Argumente. Wir warten gern. Aber bitte nimm es uns nicht übel, wenn wir die Luft beim Warten nicht anhalten ...
Wenn man nicht mittlerweile genau wüßte, dass diese immer wiederkehrenden Anwandlungen, jetzt unbedingt eine ganz neue Lösung für so eine uralte triviale Routinegeschichte zusammenschustern zu müssen, nicht etwa durch besondere Kreativität sondern fehlendes Verständnis der optimalen Standardlösung motiviert sind.
Mein Prof. sagte in solchen Fällen immer: wer das nicht glauben will (ok, ging nicht um Drehgeber) solle Bombenentschärfer werden, da ist Raum für eigene Experimente statt auf Erfahrung und Wissen zu setzen.... Und auch der unvergleichliche Holger D. labert nur statt was zu funktionierendes zu zeigen.
H.Joachim S. schrieb: > Und auch der unvergleichliche Holger D. labert nur statt was zu > funktionierendes zu zeigen. Und der unvergleichliche H.Joachim S. reiht sich in die Riege der Laberheinis ein. Man man man. Warum lasst Ihr nicht den Thomas O. machen.
Holger D. schrieb: > Warum lasst Ihr nicht den Thomas O. machen. Kann er ja tun. Er lernt dabei hoffentlich mehr als Du. Und wenn er dabei auch noch den mehrmals zitierten Artikel liest und ihn auch versteht, ist die Wahrscheinlichkeit dazu gar nicht mal so gering.
Andreas B. schrieb: >>Er lernt dabei hoffentlich mehr als Du. Sage mir bitte nur eines: Warum unterstellst Du mir nichts gelernt zu haben? Du kennst mich nicht, ich kenne Dich nicht und trotzdem bildest Du Dir so eine unerhörte Meinung.
Holger D. schrieb: > Du kennst mich nicht, ich kenne Dich nicht und trotzdem bildest > Du Dir so eine unerhörte Meinung. Ich habe Deine Beiträge hier gelesen. Wenn Du auch nur im geringsten auf den Artikel eingegangen wärst und begründet hättest warum Du einen besseren Code gefunden hättest, wäre das anders. Du kannst ja mal Deinen genialen Code mal hier rein stellen. Dann ändere ich vielleicht meine Meinung.
Andreas B. schrieb: begründet hättest warum Du einen > besseren Code gefunden hättest, wäre das anders. Sage mir bitte, wo ich geschrieben habe, dass ich einen besseren Code gefunden habe? Gefunden habe ich sowieso nichts, sondern selber geschrieben. Der Code mag für andere programmiertechnisch nicht perfekt sein, funktioniert aber für mich perfekt und zwar mit allen bisher von mir eingestezten Drehgebern. Und den Artikel habe ich halt vorher nicht gelesen. > Du kannst ja mal Deinen genialen Code mal hier rein stellen. Bin arbeiten. Vielleicht heute Abend. Und warum behauptest Du, dass der Code genial wäre. Das habe ich niemals gesagt. Siehe oben. Was ist mir Dir los?
Holger D. schrieb: > Muss ich auch nicht, da meine Routine perfekt ist! Es mag andere > Lösungen geben. Du hörst Dich heute schon wesentlich anderes an als gestern.
:
Bearbeitet durch User
Es ist doch jedesmal das gleiche, wenn es um Drehgeber geht. Eine endlose Diskussion und zum Schluss macht der TE dann doch, was er will. Ein einziger Hinweis auf den o.a. Artikel sollte reichen und die, die nicht lesen wollen oder können, sollen doch so programmieren, wie sie möchten. Ich habe früher auch mal flankengesteuert ausgewertet, extra Routine fürs Entprellen des Drückerchens am Drehgeber geschrieben usw. aber so richtig war das nur für einen einziges Modell von Encoder und wenn er neu war. Heute benutze ich die Timermethode gleichzeitig für Encoder und Buttons in einem Schwups und benutze das als Library in jedem Encoder Projekt. Das einzige, was dann noch wichtig ist, ist die Auswahl von 1, 2 oder 4 Step Abfrage. Einer der Vorteile ist m.E. die konstante Laufzeit der Routinen bei der Timermethode, egal ob gedreht oder gedrückt wird. Und man hat einen Ticker, den man meist sowieso braucht.
Vielen Dank an Matthias S. Seine Aussagen treffen 100% ins Schwarze. Unbelehrbare sind unbelehrbar. Ein Timer ist bei fast allen Anwendungen unverzichtbar, also kann man ihn sehr gut verwenden zur Abfrage von Tastaturen, Encodern und natürlich auch zu Ausgaben auf Displays oder LEDs. Wer anders programmieren will, der kann es gerne tun. Nehmt die Ideologie aus der und aus anderen Diskussionen.
Beitrag #6211612 wurde von einem Moderator gelöscht.
Matthias S. schrieb: > Ich habe früher auch mal flankengesteuert ausgewertet, extra Routine > fürs Entprellen des Drückerchens am Drehgeber geschrieben usw. Ich gebe zu, ich auch. Nachdem das zwar anfangs mal funktionierte, ich dann einige Problem damit hatte, habe ich mich halt mal in das Thema reingelesen. Dann halt auf o.g. Routine gestoßen, benutzt und zukünftig vergessen. Es gibt viele andere Dinge zu erforschen, da braucht es nicht das Rad zu sein. Nur bin ich damals halt nicht auf die Idee gekommen, daß ich alles besser könnte als der Rest der Welt.
Andreas B. schrieb: > Ich gebe zu, ich auch. Hat wohl fast jeder so versucht. Sieht ja auch so verlockend aus auf den schematisierten Zeichnungen.
Beitrag #6211678 wurde von einem Moderator gelöscht.
Beitrag #6211689 wurde von einem Moderator gelöscht.
Beitrag #6211756 wurde von einem Moderator gelöscht.
Thomas O. schrieb: > So wie ich das sehe muss ich nur feststellen auf welchem Kanal die erste > Flanke auftritt und schon habe ich Richtung ich führe dann einen Schritt > in diese Richtung aus. Das siehst du aber ein bissel blauäugig. Also: Der Knackpunkt des "allgemeinen Drehgebers" ist, daß es 2 Signale gibt, die phasenversetzt sind. Deshalb kann man aus deren Änderungen nicht nur die Tatsache des Drehens, sondern auch der Richtung erkennen. Schön, toll. Und nun? In der Praxis geht es zumeist um handbetätgte Dinger, die einen Rastpunkt haben. Der kann mit dem Umschalten eines der 2 Kontakte zusammenfallen oder auch nicht. Hab beides schon gehabt, aber die Variante, wo Rastpunkt und Umschaltpunkt zusammenfallen, ist viel häufiger. Ist wahrscheinlich auch ne Frage des billigstmöglichen Fertigens. Da man bei solchen Drehgebern ohnehin nur von Rastpunkt zu Rastpunkt drehen kann (und nicht zu Zwischenständen), ist es sinnlos, irgendwelche Zwischenstände überhaupt ermitteln zu wollen. Also steht die Aufgabe, eines der beiden Signale als Quasi-Takt und das andere als Quasi-Richtung auszuwählen und zumindest den "Takt" sauber zu entprellen. Natürlich nimmt man als Takt dasjenige Signal, was am weitesten vom Rastpunkt aus gesehen umschaltet - eben um das Entprellen möglichst gut zu erleichtern. Und hier setzen die fanatischen Streitereien ein: Es gibt ne Fraktion, die lauthals "POLLING" schreit und jeden Andersdenkenden verteufelt - und es gibt deren exaktes Gegenteil in der Interupt-Fraktion. Fakt ist: zum exakten Funktionieren gehört ein ebenso exaktes Entprellen - egal wie man das anstellt. Die Polling-Fraktion setzt auf digitales Entprellen durch Überabtastung usw. - und die Interrupt-Fraktion setzt auf analoges Entprellen per RC-Schaltung. Das eine erfordert Rechenzeit und das andere ein paar passive BE. Nun kannst du dir selber aussuchen, zu welcher Frakton du dich gesellen willst. Ich gehöre zur Interrupt-Fraktion und z.B. MaWin zu den Pollern. Ach ja: sobald man die zuverlässig entprellten Zustände vorliegen hat, ergibt sich die Richtung aus dem Zustand des Signals, was im Rastpunkt sich ändert - und zwar zu dem Zeitpunkt, wo das andere Signal (der "Takt") sich gerade geändert hat. Ein XOR beider Signale direkt nach dem Umschalten des "Taktes" liefert die Richtungsangabe. So, der Rest des Threads gehört den Streitsüchtigen W.S.
W.S. schrieb: > Das eine erfordert Rechenzeit > und das andere ein paar passive BE. Das war die Steilvorlage: Erstens verbraucht die Polling Methode nicht mehr Rechenzeit. Nicht zuletzt, weil man i.A. sowieso irgendeinen Timer laufen läßt. Jedenfalls dann, wenn man Statemaschinen laufen läßt. Über die Programmierung mit den unsäglichen Waits der Arduinofraktion lasse ich mich jetzt mal nicht aus. Selbst wenn man im Durchschnitt mehr Rechenzeit bräuchte, spielt das keine Rolle, weil nicht die Durchschnittsrechenzeit entscheidend ist, sondern der worst case. Und nun: Feuer frei. ;-)
Beitrag #6212103 wurde von einem Moderator gelöscht.
W.S. schrieb: > Also steht die Aufgabe, eines der beiden Signale als Quasi-Takt und das > andere als Quasi-Richtung auszuwählen und zumindest den "Takt" sauber zu > entprellen. Nein. Man muss gar nicht entprellen. Du hast also was Grundsätzliches grundsätzlich nicht verstanden. Wer nicht entprellen muss, muss sich auch keine Gedanken über die mögliche Prellzeit machen, in der seine Routine 'blind' für weitere Impulse wäre, was die maximal erfassbare Geschwindigkeit unnötig begrenzt.
Beitrag #6212122 wurde von einem Moderator gelöscht.
Michael B. schrieb: > Man muss gar nicht entprellen. > Du hast also was Grundsätzliches grundsätzlich nicht verstanden. Und wenn ein Kontakt, nicht nur beim Umschalten prellt, sondern beim Schleifen kratzt... Während der Andere Prellt?
W.S. schrieb: > analoges Entprellen per RC-Schaltung Wer als Entwickler in einer digitalen Schaltung RC-Glieder zum Timing einsetzt, bittet darum, in die Konzern-Logistik versetzt zu werden. Er hat damit gezeigt, daß er für moderne Lösungen wie FPGAs nicht qualifiziert ist. MfG Klaus
Beitrag #6212205 wurde von einem Moderator gelöscht.
W.S. schrieb:
>Ich gehöre zur Interrupt-Fraktion
Es gibt ja mehrere Interrupt-Varianten.
Low-Pegel am INT-Pin löst Interrupt aus
Jeder logische Wechsel am INT1-Pin löst Interrupt aus
Eine fallende Flanke am INT-Pin löst Interrupt aus
Eine steigende Flanke am INT-Pin löst Interrupt aus
Welche Variante benutzt du dafür?
Jaja, da kommt W.S. und schüttet wieder Benzin ins Feuer und prompt geht es weiter... Hier wird keiner den anderen bekehren können - jeder Missionierungsversuch ist vergeblich. Also lasst doch jedem die Facon, nach der er seelig wird.
Matthias S. schrieb: > Also lasst doch jedem die Facon, > nach der er seelig wird. Aber der TO soll doch glücklich werden! Das ist mehr als "lasst doch jedem" :-) Gruß Rainer
Ein aufschluss- und lehrreicher Auswuchs zum Thema Decoder-Algo, war damals dieser zum "Wer hat den schnellsten..?" mutierte Assembler-Thread... Beitrag "Re: Versetzte Rechtecksignale auswerten, kein drehgeber"
W.S. schrieb: > Die Polling-Fraktion setzt auf digitales > Entprellen durch Überabtastung usw. Tatsächlich gehörst du zu der "ich habs nicht verstanden"-Fraktion, welche typischerweise auf diesem Irrweg landet. W.S. schrieb: > Ich gehöre zur Interrupt-Fraktion
Wenn man meint der größte Stuss wurde schon geschrieben und dann kommt W.S.! Interruptgedöhns und HW enprellung funktioniert spätestens dann nicht wenn man eine Matrix aus Drehgebern braucht. Denn dann brauchts eh polling und durchschalten der Spalten. Eine Tastenmatrix lässt sich dann auch gleich im selben Abwasch abhandeln. So geschenen bei einem RGB Mischpult Projekt mit 8 Drehgebern. Da es noch nicht genannt wurde: Diverse µCs (wie zB viele STM32) haben direkt Hardware eingebaut um Drehencoder einzulesen ohne großes hickhack. Bei den STM32 haben das einige der Timer mit 2+ Capture Eingängen.
Mw E. schrieb: > Diverse µCs (wie zB viele STM32) haben direkt Hardware eingebaut um > Drehencoder einzulesen ohne großes hickhack. Ergänzend: der STM8S003 kann das auch. ( ein Timer mit entsprechenden Eingängen). Klappt wunderbar ohne jede CPU-Last, mal abgesehen vom Auslesen des Timerregisters.
Beitrag #6212394 wurde von einem Moderator gelöscht.
Beitrag #6212740 wurde von einem Moderator gelöscht.
VorzeichenLoser schrieb im Beitrag #6212740: > Bitte: Wer o.g. Text verstanden hat, der möge ihn mit seinen Worten > erneut hier posten. Du stehst auf der Leitung: Das (nicht ausreichend) und vieles mehr steht im mehrfach o.a. Artikel. Aber hier scheinen ja 50% zu faul zum lesen zu sein.... Niemand hat Lust das hier zu wiederholen.
Günter Lenz schrieb: > Welche Variante benutzt du dafür? Hoffentlich die des Timer-Interrupts. VorzeichenLoser schrieb im Beitrag #6212740: > Telegrammstil wegen Zensur Ich habe den Eindruck, daß hier nicht wegen off-topic und Beleidigung, sondern weil ein- und Derselbe unter mehreren Namen sich und seine Idee hochjubeln will, gelöscht wird. Denn so viele Doofe wie hier auf ein Mal auftraten kann es gar nicht geben.
MaWin schrieb: > sondern weil ein- und Derselbe unter mehreren Namen sich und seine Idee > hochjubeln will Insbesondere hat er Hausverbot.
Beitrag #6212941 wurde von einem Moderator gelöscht.
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.