Forum: Mikrocontroller und Digitale Elektronik Effezenter Drehgeber decoder in c

Christian K. schrieb:
> Bekommt man dieses Ergebnis vielleicht auch mit einfachen arithmetischen
> Operationen hin, ohne dies Klotz aus if-eleses?

Ich habe mit ca. sowas gute Erfahrung gemacht, ist auf jeden Fall klarer 
was passiert:

https://github.com/mathertel/RotaryEncoder

(Arduino, aber einfach zu uebersetze)

leo

Christian K. schrieb:
> Jetzt habe ich einmal selber einen Algorithmus geschrieben der perfekt
> funktioniert

Na dann ist ja gut, aber warum das Rad neu erfinden, es gibt schon 
besseren code:

Am einfachsten realisiert man das mit einer state machine als Tabelle. 
In C sieht das so aus.

  int table[4][4]={{0,1,0,0},{-0,0,0,0},{0,0,0,-1},{0,0,0,0}};
  int position=0; // zaehlen wir mal die absolute Position
  volatile int quadrature_input; // bit 0 und bit 1 sind 
Quadratureingaenge
  int new_quadrature_value, last_quadrature_value=quadrature_input;
Folgenden Code ausreichend oft wiederholen (in der Programm Hauptscheife 
oder einer Zeitgeber gesteuerten Interrupt Routine):
  new_quadrature_value=quadrature_input;
  position+=table[last_quadrature_value][new_quadrature_value];
  last_quadrature_value=new_quadrature_value;

angepasst an deine Encoder aus:

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

Christian K. schrieb:
> Bekommt man dieses Ergebnis vielleicht auch mit einfachen arithmetischen
> Operationen hin, ohne dies Klotz aus if-eleses?

Ja - indem du die Hardware deines µC benutzt. Konkret: indem du dir den 
Kontakt deines DG heraussuchst, der am weitesten entfernt von den 
Rastungen seinen Zustand ändert, und den führst du an ein Port-Pin, das 
du so programmieren kannst, daß es auf Zustandswechsel (also sowohl 
H-->L als auch L-->H) einen Interupt auslöst.

Daß du dieses Signal mit einem Kondensator (üblich etwa 22nF) glättest 
und dabei entprellst, sollte klar sein.

Und in der ISR brauchst du dann bloß:

1

bool A, B;  // die Zustände der beiden DG-Signale

2

3

A = Zustand Port-Pin von DG-A

4

B = Zustand Port-Pin von DG-B

5

if (A ^ B) 

6

  AddEvent(idDrehRechts);

7

else

8

  AddEvent(idDrehLinks);

9

// das war's.

W.S.

W.S. schrieb:
> Und in der ISR brauchst du dann bloß:bool A, B;  // die Zustände der
> beiden DG-Signale
>
> A = Zustand Port-Pin von DG-A
> B = Zustand Port-Pin von DG-B
> if (A ^ B)
>   AddEvent(idDrehRechts);
> else
>   AddEvent(idDrehLinks);
> // das war's.

Das funktioniert nur nicht, da egal in welche Richtung ich drehe immer 
auf gleichen Pegel ungleicher Pegel folgt und auf ungleiche Pegel 
gleicher Pegel.

W.S. schrieb:
> nd den führst du an ein Port-Pin, das du so programmieren kannst, daß es
> auf Zustandswechsel (also sowohl H-->L als auch L-->H) einen Interupt
> auslöst.

Man kann quasi drauf warten, in jedem Drehgeber thread kommt so ein 
grober Unsinnn, zumindest EINER hat in seinem Leben bis heute nicht 
begriffen, dass man unentprellte Kontakte niemals auf einen 
Interrupt-Pin gebrn darf.

Und an statt dass dieser Unwissende sein Wissen mal durch Lesen von 
http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.29 oder 
https://www.mikrocontroller.net/articles/Drehgeber ausgebügelt hätte, 
posaunt er es hier in grossen Worten hinaus, damit auch jeder erfährt 
welche groben Fehler er macht.

Martin schrieb:
> Das funktioniert nur nicht, da egal in welche Richtung ich drehe immer
> auf gleichen Pegel ungleicher Pegel folgt und auf ungleiche Pegel
> gleicher Pegel.

Falk B. schrieb:
> W.S. schrieb:
>> Ja - indem du die Hardware deines µC benutzt. Konkret: indem du dir den
>> Kontakt deines DG heraussuchst, der am weitesten entfernt von den
>> Rastungen seinen Zustand ändert, und den führst du an ein Port-Pin, das
>> du so programmieren kannst, daß es auf Zustandswechsel (also sowohl
>> H-->L als auch L-->H) einen Interupt auslöst.
>
> NICHT SCHON WIEDER DIE ALTE LEIER! DAS IST UNSINN!

Unnsinn ? Schon mal ausprobiert?
Das geht schon, vorausgesetzt man nimmt den richtigen ENCODER.
Seht euch mal die Datenblätter von ALPS die EC11 Serie an,
mit ein bisschen Guggi Luggi findet man das raus.

Die Ausage von W.S. stimmt und ist kein Unsinn! geht aber nicht mit 
jeden ENCODER.

Man braucht ja auch keinen Interrupt und keine Entprellung. Man muss nur 
öfters die Zustände abfragen als die maximale Drehgeschwindigkeit.

SaschaFries schrieb:
> Man braucht ja auch keinen Interrupt und keine Entprellung. Man muss nur
> öfters die Zustände abfragen als die maximale Drehgeschwindigkeit.

Aha,  haste dein erste Arduino-Programmle ans laufen gebracht?
Genau so kommt das rüber :-(

Falk B. schrieb:
> Nicht nur das. Auch das DIREKTE anschließen von einem Kondensator, egal
> ob 1 oder 22nF an die Encoderausgänge ist ein Fehler! Denn dabei
> schließt der Schalter im Encoder periodisch einen geladenen Kondensator
> ohne Strombegrenzung kurz! Das erzeugt ordentlich Kontaktverschleiß!
> Wenn schon, dann ein gescheiter RC-Tiefpaß mit dem Pull-Up an der
> richtigen Stelle.

Jetzt ziehst du aber die Dinge an den Haaren herbei :-(
Das ist eigentlich selbsredend das man den Eingängen ein 'RC-Tiefpass' 
verpasst.
Das traue ich sogar dem W.S. zu (der denkt halt schneller als er 
schreibt)

Falk B. schrieb:
> Aber auch damit ist die Flankenauswertung per Interrupt NICHT solide!
> Aber das haben wir schon mehrfach bis zum Erbrechen diskutiert. Klar,
> einige WOLLEN es nicht verstehen, das Dogma läßt grüßen!

Dann erklär mir warum  unsere verbauten ENCODER genau mit dieser Methode 
bei unseren Kunden problemlos funktionieren?
Ich hab das mal kurz überschlagen: Es kommen da ungefähr 15000000 (15 
Millionen) Inkremente pro Jahr zusammen.
Man muss sich das mal vor Augen führen und das mit dieser 
unzuverlässigen, unsolieden Flankenauswertung  :-)
Ich gebe zu, man muss halt mit Verstand an die Sache rangehen und sich 
damit auseinander setzen.

Falk B. schrieb:
> Yalu X. schrieb:
>
>> W.S. schreibt zwar etwas von einem 22nF-Kondensator zur Entprellung, was
>> aber je nach Pull-Up-Widerstand und Hysteresespannung der µC-Eingänge um
>> eine bis zwei Größenordnungen zu wenig ist.
>
> Nicht nur das. Auch das DIREKTE anschließen von einem Kondensator, egal
> ob 1 oder 22nF an die Encoderausgänge ist ein Fehler! Denn dabei
> schließt der Schalter im Encoder periodisch einen geladenen Kondensator
> ohne Strombegrenzung kurz! Das erzeugt ordentlich Kontaktverschleiß!
> Wenn schon, dann ein gescheiter RC-Tiefpaß mit dem Pull-Up an der
> richtigen Stelle.

Oder man macht genau das mit Absicht um die Kontakte vor Oxidation zu 
schützen. (Stichwort "Frittspannung" / engl. "wetting current"). Angaben 
im Datenblatt des Herstellers sollte man natürlich beachten.

il Conte schrieb:
> Dann erklär mir warum  unsere verbauten ENCODER genau mit dieser Methode
> bei unseren Kunden problemlos funktionieren?

Glauben die Hersteller und die Kunden ärgern sih.

Ich habe auch ein Autoradio das im Inrementalencoder sichtbar falsch 
zählt, einen Funktionsgenerator dessen Incremental-Auswertung offenbar 
euer Qualitätskriterium erfüllt und zickt, und höre von vielen Leuten 
sie sich wundern, warum sie den Knopf schneller drehen können als die 
angeblich so schnelle Elektronik ihm folgen kann.

Schrott ab Werk, von Entwicklern wie dir, die nicht mal die Grundlagen 
beherrschen.

Yalu X. schrieb:
> Es ist jedenfalls nicht damit getan, den
> Encoder ein paar mal ein paar Rasten erst nach rechts und dann wieder
> nach links zu drehen und nachzuschauen, ob der Zähler dann wieder auf 0
> steht.

Wer redet vom Zähler ?
Im übrigen sollte das deine SW wissen wenn der Zähler wieder auf Null 
steht.
Durch links und rechts drehen ?  Auf so ne Idee muss man erst mal kommen 
:-O

MaWin schrieb:
> Schrott ab Werk, von Entwicklern wie dir, die nicht mal die Grundlagen
> beherrschen.

Gegenfrage: Was beherschten du ? Bashing ?

>Das ist eigentlich selbsredend das man den Eingängen ein 'RC-Tiefpass'
>verpasst.

Wer einen uC für sich arbeiten läßt und die Kontakte versucht mechanisch 
zu entprellen, nur weil er der Interrupt-Flanken-Glaubensgemeinschaft 
anhängt, der macht doch was grundlegend falsch.

>> Man braucht ja auch keinen Interrupt und keine Entprellung. Man muss nur
>> öfters die Zustände abfragen als die maximale Drehgeschwindigkeit.

>Aha,  haste dein erste Arduino-Programmle ans laufen gebracht?
>Genau so kommt das rüber :-(

Wenn man die Auswertung über Zustände macht, so wie es auch im 
Mikrocontroller-Artikel beschrieben ist, dann gibt es nur dann 
Zählfehler, wenn man zwischen 2 Auswertungen ZWEI Schritte weiterzählt. 
Das passiert aber bei Jittern an einer Flanke nicht.

Bei einer Abfrage in einer 1ms Task kannst Du also am Drehgebener mit 
1000 Zustandsänderungen pro Sekunde arbeiten, also 250Hz wenn Du nur 
einen Kanal A oder B betrachtets.

Ich habe bereits um 2005 ein Messgerät entwickelt, das einen Drehgeber 
mit 900/3600 Pulse pro Umdrehung auswertet. Ca 4 Umdrehungen pro 
Sekunde. Schneller Richtungswechsel. Es verzählt sich nie. PIC18 mit 
5MHz Systemtakt.

> Dann erzähl doch mal, wie ihr die Encoderauswertung auf Zuverlässigkeit
> prüft.
Geht ganz einfach: Es gibt 4 Zustände:
- nix
- hoch
- runter
- Fehler.

Fehler darf nie passieren. Den Fehler auszuwerten geht ganz einfach, 
indem man in die Tabelle noch nen weiteren Wert einfügt, den man dann 
auswerten kann.

Yalu X. schrieb:
> Was spricht also dagegen, ohne zusätzlichen Aufwand
> dafür zu sorgen, dass auch dieses letzte Promille an verschluckten
> Inkrementen der Vergangenheit angehört?

Die natürliche Renitenz der Leute, einzusehen daß die falsch liegen.

Yalu X. schrieb:
> Werden bei euch die Impulse etwa nicht gezählt?

Nein - wir tun die nur begutachten:-)

Das zählen der Impulse in der SW ist komplett zweitrangig !

Es geht hier nur darum die Impulse die der Drehgebr liefert in den 
allerwertesten uC zu bekommen und um nichts mehr.

Yalu X. schrieb:
> Dann erzähl doch mal, wie ihr die Encoderauswertung auf Zuverlässigkeit
> prüft. Deine bisherigen Informationen vermitteln eher den Eindruck, dass
> ihr sie ungetestet an den Kunden ausliefert und auf Reklamationen
> wartet. Bleiben diese (aus welchen Gründen auch immer) aus, wird die
> Auswertung als perfekt angesehen. Ich hoffe natürlich für dich und deine
> Kunden, dass dieser Eindruck falsch ist.

Es ist eigentlich noch viel schlimmer:
Ich hab mich seiner Zeit vor jeder Auslieferung so richtig in die Hosen 
gemacht :-))
Mann o Mann!

Falk B. schrieb:
> Ich kann auch ohne
> Helm Motorrad fahren und keinerlei Unfall erleiden. Kann sein, muss
> nicht.

Oder andersrum:
Ich kann auch mit aufgesetztem Helm zu Fuß durchs Dorf laufen,
Es könnte ja sein dass jemand sich aus dem Fenster lehnt und den 
Nachttopf ausleert :-)

Hi

>Es könnte ja sein dass jemand sich aus dem Fenster lehnt und den
>Nachttopf ausleert :-)

Ist das bei euch noch üblich?

MfG Spess

spess53 schrieb:
> Ist das bei euch noch üblich?

Ja durchaus - z.B. wenn ein Jungmann die für ihn Auserwählte verschmät 
hat.
Man muss wissen bei uns hier gibt es noch Hochzeitlader und man wird 
verheiratet. Der Hochzeitslader ist so ne Art 'Anbantel Manager', wenn 
der nichts taugt dann kann es eben  zu solchen Vorfällen kommen ;-)

Übrigens gab es sowas in Schottland wirklich (Die Zeit vor dem 
Spülklosett)
Da ging keiner ohne Regenschirm umher, die besseren Leute hatten sogar 
einen 'Vorausgeher' der die Entsorger zur Zurückhaltung ermahnt hat.
Kein Scherz - das gab es wirklich!

S. R. schrieb:
> Besser: Du nimmst einen Timer, der alle paar Millisekunden einen
> Interrupt auslöst. In dessen ISR liest du dann die Pins ein und wenn
> sich deren Zustand ändert, reagierst du darauf.

Überhaupt nicht besser, sondern schlechter. Man verplempert alle paar 
Mikrosekunden Rechenzeit und ignoriert die ohnehin in der Peripherie 
vorhandene Funktionalität. Die wird dann per Software ersetzt.


> Noch besser: Du nimmst die Quadraturdecoder-Hardware deines
> Mikrocontrollers, sofern vorhanden. Dann bist du sämtliche Probleme los.

Das ist allerdings die beste Lösung - so man sie im Chip vorhanden hat 
und sofern man nicht zu arrogant oder dämlich ist, die Drehgebersignale 
rein analog zu entprellen.

W.S.

Martin schrieb:
> Das funktioniert nur nicht, da egal in welche Richtung ich drehe immer
> auf gleichen Pegel ungleicher Pegel folgt und auf ungleiche Pegel
> gleicher Pegel.

Da die Signale regelmäßig um etwa 90 Grad versetzt sind, passiert genau 
DAS nicht und alles funktioniert wie gewünscht. Kannste glauben, ich 
weiß das mit 100% Gewissheit.

Mal dir einfach mal zwei um 90° versetzte Signale auf und mach dir klar, 
wie das funktioniert.

W.S.

Schade, dass es soweit kommen mußte.

Hardware und Design von Software werden unerbitterlich im Glaubenskrieg 
verteidigt. Agumente kommen zu kurz, oder werden als Blödsinn abgetan, 
ohne widerlegt zu werden. Politik, Soziale Medien und nun auch 
Elektrotechnik.
Dachte immer, grad hier wäre Physik und Mathematik massgebend. Aber 
nein, der Glaube an selbstgeschaffene "Fakten" (die nicht mal belegt 
werden) dominiert.

Willkommen alle in der neuen lernresistenten, bornierten Welt, der 
lauten Argumente und des fehlenden Sachverstands.

Ich bedaure nur alle, die was lernen wollen und denen es dadurch schwer 
gemacht wird. Grad die Unerfahrenen wissen bald nicht mehr wem sie 
glauben sollen.

Vielleicht doch den Trumps dieser Welt? Auch wenn sie hier anders 
heißen.

Martin schrieb:
> Das funktioniert nur nicht, da egal in welche Richtung ich drehe immer
> auf gleichen Pegel ungleicher Pegel folgt und auf ungleiche Pegel
> gleicher Pegel.

Klar: Nach Regen folgt Sonnenschein, darauf wieder Regen und dann wieder 
Sonnenschein.

Du vergisst halt völlig, dass es zwei Signale sind. Da ist ein Bezug 
zwischen den Signalen vorhanden, der dient zum Erkennen der Drehrichtung 
und zur Vierfachauswertung.

schade schrieb:
> Schade, dass es soweit kommen mußte.


Das kommt doch hier immer so. Deshalb kann man sich nur noch jeden Tag 
von Neuem darüber be-ömmeln und seine eigenen Routinen verwenden. Dann 
ist man niemandem Dank schuldig und muß sich nicht mit grossfressigen 
Rechthabern auseinandersetzen.

Jahrelange Erfahrung mit diesem Forum lehrt das.

schade schrieb:
> Grad die Unerfahrenen wissen bald nicht mehr wem sie
> glauben sollen.

Du hast es richtig erfasst: Genau deshalb gibt es diese unerbitterlichen 
Glaubneskriege.
Was ich so im Geschichtsunterricht mitbekommen habe, ist das hier nicht
der erste Glaubenskrieg.
Stehst du schon im Arbeitsleben ? Da wird so einer wie du als Mobbing 
Opfer auserkohren. Mach die lieber über sowas Gedanken als hier die 
Forumswelt zu beglücken :-(

Dummschwätzer reden und labern ohne Hintergrund und si versuchen nur zu 
provozieren.

Ich hab 30 Jahre lang Hard- und Software entworfen, Geräte gebaut und 
erfolgreich verkauft. Alles im Bereich Fernseh-, Filmstudios und ÜWagen.
Da kamen genug Drehgeber und Tasten vor. Entprellung nur über Software, 
alles andere kostet Geld, ist anfällig bei wechselnden Parametern und 
somit schlechter.

Du kannst glauben was Du willst. Erfahrung ist unbezahlbar.

schade schrieb:
> Ich hab 30 Jahre lang Hard- und Software entworfen, Geräte gebaut und
> erfolgreich verkauft.

Junge red doch gleich vernünftig!
Was treibt dich dann dazu solche 'GutMensch-Gedanken' an den Mann zu 
bringen :-(

Frank M. schrieb:
> Das Problem ist aber, dass W.S. seine Aussage als allgemeingültig
> hinstellt. Und das ist falsch. Korrekterweise hätte er den konkreten Typ
> des Drehgebers angeben müssen, wo es funktioniert. Aber solche
> Spezialfälle helfen im allgemeinen dem TO nicht weiter.

Das ist beileibe kein Problem, da so etwa 99.9% aller Drehgeber mit zwei 
um etwa 90° versetzten Signalen arbeiten. Manche verringern den 
Winkelabstand etwas, so daß die Rastungen so zwischen den Signalwechseln 
liegen, daß beide Kontakte offen sind. Das ist zwecks Stromersparnis, 
ändert aber am Schaltverhalten und an der prinzipiellen Auswertung gar 
nichts.

Und wer jetzt auf den verbleibenden 0.1% exotischen Drehgebern 
herumreitet, der mag dafür meinetwegen nen separaten Thread aufmachen.


Falk B. schrieb:
> Nicht nur das. Auch das DIREKTE anschließen von einem Kondensator, egal
> ob 1 oder 22nF an die Encoderausgänge ist ein Fehler! Denn dabei
> schließt der Schalter im Encoder periodisch einen geladenen Kondensator
> ohne Strombegrenzung kurz! Das erzeugt ordentlich Kontaktverschleiß!
> Wenn schon, dann ein gescheiter RC-Tiefpaß mit dem Pull-Up an der
> richtigen Stelle.

Und das ist tatsächlich der 22 nF Kondensator direkt am DG. Der 
Kontaktverschleiß, über den du hier theoretisierst, ist bei dieser 
Anwendung praktisch nicht vorhanden, denn er ist deutlich geringer als 
das Oxidieren der Kontaktstücke, die in den gewöhnlichen 99% aller 
Drehgeber verwendet werden.

Bei fast allen Relais wird ein Mindest-Kontaktstrom vorgeschrieben, um 
eine sichere Kontaktgabe zu erreichen - bloß du meinst, all so etwas 
nicht zur Kenntnis nehmen zu müssen. Hast du eigentlich JEMALS das 
durchgerechnet, was du hier postest? Ich bezweifle das.



il Conte schrieb:
> Das ist eigentlich selbsredend das man den Eingängen ein 'RC-Tiefpass'
> verpasst.
> Das traue ich sogar dem W.S. zu (der denkt halt schneller als er
> schreibt)

Nein, in exakt DIESEM Falle nicht.

Um nicht sinnlos Strom zu verbraten, wählt man oftmals den Hochzieher zu 
22k bis 47k und der Kontaktstrom, der bei 3.3V damit erzeugt wird, ist 
zu klein, um die mit den Jahren gammliger werdenden Kontakte so eines 
handbetätigten DG wieder freizubrennen. Genau dafür dient nebenher der 
Kondensator direkt am Kontakt.

Und die Entprell-Wirkung ist ebenfalls genau daran gebunden, denn wenn 
man ein RC-Glied vom Kontakt zum Portpin einfügt, dann wird der 
Spannungsanstieg am C verlangsamt und der mittlere Pegel angehoben. Das 
ist schlecht, denn dann ist die Spannung am Pin länger im Bereich des 
Umschaltpunktes (wenn der µC keine Hysterese an den Pins hat). Stell dir 
mal einen Kontakt vor, der 10 Sekunden lang mit genau 50% Duty prellt. 
Dann stellt sich am Pin exakt 1.65V konstant ein. Das ist ne 
Übertreibung zwecks Illustration, zeigt aber das Problem: Alles, was zum 
Glätten führt, ist schlecht. Gut ist hier etwas, das möglichst einseitig 
wirkt: also 100 milliOhm für den Kontakt und 22k für den Hochzieher.

Zur Erklärung:
Bei direktem C am Kontakt ist die Spannung am Pin nach Erstkontakt etwa 
null, um dann mit R*C anzusteigen, wenn der Kontakt prellt. Das Prellen 
ist aber nicht so, daß der Kontakt erstmal für 2 ms abhebt um danach den 
endgültigen Kontakt zu geben - sondern es ist so, daß es innerhalb der 
nächsten 2 ms immer mal wieder kurze Unterbrechungen und kurze 
Kontaktgaben gibt - und die werden mit einer Kombi aus 22nF*22K 
zuverlässig unterdrückt, das heißt, daß der in den Unterbrechungen 
ansteigende Pegel nicht einmal ansatzweise in die Nähe des 
Pin-Umschaltpunktes kommt.

Kurzum, diese Schaltung ist nicht nur sehr einfach und sehr billig zu 
realisieren, sie ist auch in ihren diversen subtilen Nebeneffekten genau 
auskalkuliert und tatsächlich das Beste, was man bei mechanischen DG 
machen kann.

Aber damit haben die hier laut werdenden Disputenten ganz offensichtlich 
noch viel zu wenig zu tun gehabt.

W.S.

Yalu X. schrieb:
> Werden bei euch die Impulse etwa nicht gezählt? Was macht ihr denn dann
> mit den Encodersignalen?

Wir reden hier nicht von Encodern, wie sie z.B. an der Hauptachse der 
Drehbank dran sind, sondern von Drehgebern für einsfuffzig, die am Radio 
zum laut oder leise stellen dran sind.

Und bei mir werden deren Signale dazu benutzt, Botschaften ins 
Event-system der Firmware zu senden. So zum Beispiel "lauter" oder 
"leiser". Und die Auswertung erfolgt dann in einem anderen Teil der 
Firmware, die gelegentlich sich sagt 'lauter als jetzt gibts nicht, ich 
begrenze den Zähler für die Lautstärke auf 99, basta'.

W.S.

W.S. schrieb:
> Zur Erklärung:
> Bei direktem C am Kontakt ist die Spannung am Pin nach Erstkontakt etwa
> null, um dann mit R*C anzusteigen, wenn der Kontakt prellt. Das Prellen
> ist aber nicht so, daß der Kontakt erstmal für 2 ms abhebt um danach den
> endgültigen Kontakt zu geben - sondern es ist so, daß es innerhalb der
> nächsten 2 ms immer mal wieder kurze Unterbrechungen und kurze
> Kontaktgaben gibt - und die werden mit einer Kombi aus 22nF*22K
> zuverlässig unterdrückt, das heißt, daß der in den Unterbrechungen
> ansteigende Pegel nicht einmal ansatzweise in die Nähe des
> Pin-Umschaltpunktes kommt.


Ich staune immer wieder auf neue, dass du Dinge vortägst die richtig 
Hand und Fuss haben. (das würde ich mir auch so bei KiCad wünschen ;-)

Bei uns waren das mal  22nF * 15K.

W.S. schrieb:
> Kurzum, diese Schaltung ist nicht nur sehr einfach und sehr billig zu
> realisieren, sie ist auch in ihren diversen subtilen Nebeneffekten genau
> auskalkuliert und tatsächlich das Beste, was man bei mechanischen DG
> machen kann.

Sagte ich doch oben, 15 Millionen Inkremente/Jahr ohne  irgend welche 
Klagen.

W.S. schrieb:
> Wir reden hier nicht von Encodern, wie sie z.B. an der Hauptachse der
> Drehbank dran sind, sondern von Drehgebern für einsfuffzig, die am Radio
> zum laut oder leise stellen dran sind.

Zur Richtigstellung:
Mit Encoder werden im amerikanischen Sprachgebrauch auch die Drehgeber 
(siehe Bild im Eingangsposting) so bezeichnet.

W.S. schrieb:

> Überhaupt nicht besser, sondern schlechter.

Das kommt ganz klar auf die Randbedingungen an.

Wenn ich z.B. acht Encoder auslesen möchte, diese "handbetätigt" sind 
und mein µC nicht auf Batterie läuft, dann würde ich ganz eindeutig die 
Polling-Variante wählen (natürlich in einer Timer-ISR). Also das 
Dannegger-Konzept (wenn auch natürlich in meiner eigenen, C-freien 
Variante).

Warum? Ganz einfach, weil dieses Konzept in dieser Anwendung vollkommen 
zweifelsfrei all seine Vorteile voll ausspielen kann, die Nachteile aber 
wenig bis garnicht in's Gewicht fallen.

Will ich hingegen einen einzelnen Encoder auslesen, dieser ggf. sogar 
"maschinengetrieben" ist und/oder Batteriebetrieb der MCU nötig ist, 
dann würde ich natürlich meine Edge-Interrupt basierte Lösung verwenden.

Warum? Weil die eben hier all ihre Vorteile voll ausspielen kann, 
während die Nachteile wenig bis garnicht in's Gewicht fallen.

Für alle Anwendungen, die zwischen diesen beiden grob umrissenen 
Extremen liegen, muss man halt abwägen, welches Konzept jeweils besser 
geeignet ist.

------------------------------------------------------------------------

Witzig und für dich wahrscheinlich besonders interessant: eine 
Hardware-Entprellung benötigt de facto keins der beiden Konzepte, im 
besten Fall ist sie vollkommen nutzlos, ggf. (bei falscher 
Dimensionierung) stört sie sogar.

Rotary encoder sind eben keine Taster! Selbst dann nicht, wenn die 
einfachen Vertreter ihrer Art nur aus zwei mechanischen Kontakten 
bestehen. Die Logik ihres Aufbaus erspart eine Entprellung, wie sie bei 
einfachen Tastern nötig ist.

Das ist, was du nie wirklich begriffen hast. Deswegen können die 
unbelehrbaren Polling-Fetischisten (von denen allerdings viele das 
ebenfalls nicht begriffen haben, nämlich insbesondere die lautesten 
Schreihälse!) dich auch immer wieder auslachen. Weil deine 
Edge-Interruptlösung diese innere Lögik der Encoder eben nicht 
berücksichtigt und nutzbar macht.

Ich verrate dir noch den Kern des Tricks: man braucht zwei UNABHÄNGIG 
sperrbare Edge-Interrupts pro Encoder. Dann geht das. Zuverlässig und 
ohne jede Hardware-Entprellung. Und zwar selbst bei den Scheiß-Encodern, 
die in Rastlage noch auf einem Kanal zappeln.

Meine Fresse, jetzt beklatschen sich 2 ewig Lernresistente, il Conte & 
W. S. für ihre Lernresistenz.

Was beide offenbar auch nicht wissen: ja, es gibt einen Mindeststrom und 
einen Maximalstrom pro Kontakt damit der seine Datenblatt Lebensdauer 
auch erreicht, auch bei einem Drehencoder, und ein Kondensator parallel 
zum Kontakt als angebliche RC Entprellung die auf die Art natürlich 
keine ist reisst natürlich beide Grenzwerte.

Selbst richtig gebaute RC Glieder.

1

 +5V

2

  |

3

 4k7 (bei 1 mA Mindeststrom)

4

  |

5

  +--47k--+--|Schmitt-Trigger Eingang

6

  |       |

7

Kontakt 100nF (bei 5ms Prellzeit)

8

  |       |

9

 GND     GND

haben Nachteile, sie begrenzen nämlich die maxinale erkennbare 
Drehgeschwindigjeit auf Werte weit unter der der richtigen 
Softwareauswertung.

MaWin schrieb:
> Selbst richtig gebaute RC Glieder. +5V
>   |
>  4k7 (bei 1 mA Mindeststrom)
>   |
>   +--47k--+--|Schmitt-Trigger Eingang
>   |       |
> Kontakt 100nF (bei 5ms Prellzeit)
>   |       |
>  GND     GND
> haben Nachteile, sie begrenzen nämlich die maxinale erkennbare
> Drehgeschwindigjeit auf Werte weit unter der der richtigen
> Softwareauswertung.

Meine Fresse, soviel Unverstand  - hast du das Ganze schon mal 
auprobiert ?
Hier grosse Reden schwingen und dazu kleine Notdurft :-( klein scheissen 
darf man ja nicht schreiben)

Yalu X. schrieb:
> Genau diese analoge Entprellung ist auch bei den Hardwaredekodern nicht
> erforderlich. Warum wohl?

Beitrag "Re: Effezenter Drehgeber decoder in c"

Wenn du da den 2. Absatz liest wird der Kondensator AUCH wegen der 
Kontakte eingesetzt. Das kann man nicht von der Hand weisen. Wir haben 
unsere Encoder genau so beschaltet und es gab absolut keinen Ärger.
Wir haben zwar nie mettalurgische Untersuchungen durchgeführt, aber das 
schreibe ich diesen 22nF zu! Der Pullup lag bei 15K.

So gesehen ist eine analoge Endprellung notwendig wird aber 
zweckentfremdet.

il Conte schrieb:
> MaWin schrieb:
>> Schrott ab Werk, von Entwicklern wie dir, die nicht mal die Grundlagen
>> beherrschen.
>
> Gegenfrage: Was beherschten du ? Bashing ?

Heult der Typ, der paar Beiträge darüber völlig unreflektiert einen 
anderen Benutzer als Arduino-User bloßstellen wollte...

LOL

il Conte schrieb:
> Meine Fresse, soviel Unverstand  - hast du das Ganze schon mal
> auprobiert ?
> Hier grosse Reden schwingen und dazu kleine Notdurft :-( klein scheissen
> darf man ja nicht schreiben

Autsch, nun warst du im Eifer deones Gefechtes zu blöd, jetzt weiss 
Jeder, dass du nicht den Hauch einer Ahnung hast sondern hier nur 
rumtrollst um des Unfriedens Willen.

Verpiss dich.

Hi

>Heult der Typ, der paar Beiträge darüber völlig unreflektiert einen
>anderen Benutzer als Arduino-User bloßstellen wollte...

Zu recht. Weil das Plagiat ein Arschloch mit Null Ahnung ist.

MfG Spess

Hi

Ach il Conte ist auch noch Gesundheitsberater. Du solltest bei dem Jop 
bleiben.

MfG Spess

Frank M. schrieb:
> Wie schon öfter geschrieben: Wir Moderatoren können das eindeutig
> erkennen.

Eindeutig?
Also wenn jemand auf Arbeit (auch an wechselnden Einsatzorten)  hier 
postet
und dann zu Hause (ein un der gleiche Mann) dann könnt ihr sowas 
feststellen?? das muss mir einer erklären.

Mit den Infos die auf euerer Datenschutzerkärung ersichtlich ist , ist 
das nicht zu machen zumal ihr anscheinend Google Analitics verwendet. 
Softlastige Vereine wie Ihr nemen doch heutzutage Matomo.

spess53 schrieb:
> Ach il Conte ist auch noch Gesundheitsberater. Du solltest bei dem Jop
> bleiben.

Das wäre mir 10x zu langweilig ;-)

Yalu X. schrieb:
> Normalerweise werden die Kontakte durch das Gegeneinanderreiben der
> Kontaktflächen gereinigt (ähnlich wie bei selbstreinigenden Schaltern
> und Tastern).

Nö.

Hast du jemals einen billigen DG von innen gsehen? Wohl nicht. Da ist 
ein Plastik-Spritzguß-Zackenrad drin, was auf zwei Blechzungen drückt, 
die ihrerseits auf einen darunter liegenden Kontakt drücken - oder eben 
nicht.

Da gibt es keinerlei Reibung - außer der zwischen der Blechzunge und dem 
Plastikrad.

Du solltest ohne tatsächliche Kenntnisse der Dinge nicht so theoretisch 
aus deiner Vorstellung über eine mögliche Realisierungsvariante des 
Ganzen heraus argumentieren. Sowas trifft nur manchmal zu und kann in 
den übrigen Fällen nur ebenso Unbedarften imponieren.

Und nochwas zum Entprellen: in einigen µC von Kinetis ist in dem 
Pin-Anschluß bereits eine programmierbare Hardware-Entprellung 
eingebaut. Ja, sowas gibt's - wenn man sich den Chip passend zur Aufgabe 
aussucht und nicht immerzu nur auf einer speziellen Marke herumreitet 
und die Aufgabe an den Chip anpassen will.

W.S.