Hallo! Mache jetzt schon drei Tage an einem erst einmal sehr leicht aussehenden Problem. Hab diesen Drehencoder von Pollin http://www.pollin.de/shop/downloads/D240313D.PDF Wenn ich mir jetzt das Datenblatt ansehe dann "sitzt" der erste Rastpunkt genau auf der B-Flanke. Wenn ich jetzt am Decoder drehe dann bekomme ich alle möglichen Zustände. Was ich damit sagen will ist das der Rastpunkt alle "Werte" bekommen kann. AB 0,0 0,1 1,0 und 1,1. Ist das so gewollt oder verstehe ich da irgendwas falsch? Ich hätte gedacht das jeder Rastpunkt auf einem festen wert steht?!
:
Bearbeitet durch User
https://de.wikipedia.org/wiki/Inkrementalgeber#Signalauswertung oder auch http://www.mikrocontroller.net/articles/Drehgeber
:
Bearbeitet durch User
Jonas K. schrieb: > https://de.wikipedia.org/wiki/Inkrementalgeber#Signalauswertung > http://www.mikrocontroller.net/articles/Drehgeber Oder auch dse faq. Wichtig ist, das man die Zustände, und nicht die Flanken detektiert. Gruss Harald
Hallo Manuel, ja das ist so gewollt. Sonst könntest du ja keine Richtung erkennen. Die Dinger heißen auch oft Drehimpulsgeber oder Rotary Switch. Eine suche hier im Forum ergab sogar etwas fertiges in der Codesammelung: Beitrag "Drehimpulsgeber mit Rasterstellung bei 00/11 auswerten" Gruß deathfun
Hi, schau Dir mal den Kode hier an Beitrag "Pollin Panasonic Encoder für Interrupt Fans" Die Theorie dazu. Vom Drehgeber A bzw. B wird mit einem Interrupteingang verbunden. Ich geh davon aus Pin A. B wird mit einem normalen Eingang verbunden. Der Interrupt erfolgt Flankengesteuert. In der Interrupt Routine wird der Eingang für PIN B abgefragt. Je nach Niveu von B wird links oder Rechts rum gedreht. Anschliessend wird die Erwartung für den nächsten Interrupt von fallend auf steigend beziehungsweise anderherum gesetzt.
Klausb schrieb: > Hi, > > schau Dir mal den Kode hier an Lieber nicht! > Beitrag "Pollin Panasonic Encoder für Interrupt Fans" > > Die Theorie dazu. > > Vom Drehgeber A bzw. B wird mit einem Interrupteingang verbunden. Ich > geh davon aus Pin A. > B wird mit einem normalen Eingang verbunden. > > Der Interrupt erfolgt Flankengesteuert. > In der Interrupt Routine wird der Eingang für PIN B abgefragt. Je nach > Niveu von B wird links oder Rechts rum gedreht. > Anschliessend wird die Erwartung für den nächsten Interrupt von fallend > auf steigend beziehungsweise anderherum gesetzt. Funktioniert leider so wie der ganze Kot aussieht: Wie hingeschissen. Drehenkoder fragt man nicht mit Interrupts ab. Oder glaubst du, die ganzen Leute, die das hier ständig predigen, sind alles Idioten und du hast das Ei des Columbus entdeckt? mfg.
Thomas schrieb: >Lieber nicht! Was soll das? Zitat aus dem o.g. Thread: >Bisher keine Probleme wegen "Prellens" festgestellt. Der Code ist dort 65 mal heruntergeladen worden und es gab keinen Kommentar, daß er nicht funktionieren würde. >Drehenkoder fragt man nicht mit Interrupts ab. Das bestimmst Du nicht. >Oder glaubst du, die ganzen Leute, die das hier ständig predigen, sind >alles Idioten und du hast das Ei des Columbus entdeckt? Glaubst Du, anderen Leuten verbieten zu können, selbst etwas auszuprobieren? gez. Zittermann
Hi >Der Code ist dort 65 mal heruntergeladen worden und es gab keinen >Kommentar, daß er nicht funktionieren würde. Der Zähler erhöht sich schon, wenn man sich den Code ansieht. Also kein Indiz, das den jemand ausprobiert hat. Vernünftigen Code findet man hier: http://www.mikrocontroller.net/articles/Drehgeber MfG Spess
Jeder kann die Fehler machen, die er möchte. Auch Du und alle anderen. Das Problem ist aber ein anderes: Du empfiehlst einen Code, hast aber anscheinend von der Problematik der Drehgeber keine Anhnung. Allein durch logisches Nachdenken ist erkennbar, was für ein Bockmist die Interrupt-Erkennung von diesen Drehgebern darstellt. Wenn das Nachdenken nicht reicht, dann lies die erwähnten Artikel oder Applikationen dazu.
Thomas Eckmann schrieb: > Oder glaubst du, die > ganzen Leute, die das hier ständig predigen, sind alles Idioten und du > hast das Ei des Columbus entdeckt? Darf man denn auch mit 'ja' antworten? Im obigen Datenblatt sind Tiefpassfilter 10k/10nF in Reihe zum µC-Eingang eingezeichnet. In Verbindung mit der Eingangshysteres des AVR (?) ist dies schon eine hinreichende Entprellung. Zittermann schrieb: > Der Code ist dort 65 mal heruntergeladen worden und es gab keinen > Kommentar, daß er nicht funktionieren würde. Es hat aber auch keiner gechrieben, dass es funktioniert. Vielleicht hängt das auch von der Einstellung von und zu delay() ab :-)
>Im obigen Datenblatt sind Tiefpassfilter 10k/10nF in Reihe zum >µC-Eingang eingezeichnet. In Verbindung mit der Eingangshysteres des AVR >(?) ist dies schon eine hinreichende Entprellung. Das ist keine Entprellung. Das ist Bastelkram.
Zittermann schrieb: >>Drehenkoder fragt man nicht mit Interrupts ab. > Das bestimmst Du nicht. >>Oder glaubst du, die ganzen Leute, die das hier ständig predigen, sind >alles > Idioten und du hast das Ei des Columbus entdeckt? > > Glaubst Du, anderen Leuten verbieten zu können, selbst etwas > auszuprobieren? Es geht hier nicht um "bestimmen" oder "verbieten". Es geht darum, daß es schon genügend Erfahrung mit dem Dekodieren von Drehgebern gibt. Und wenn es jemanden gibt, der auf dem Holzweg ist, dann sollte derjenige dann auch den Rat von den erfahreneren Leuten annehmen. "Das macht man nicht" ist kein Verbot, sondern ein Tipp, daß es falsch ist, das so zu machen. Und auch hier im Forum gab es schon genügend Beiträge zu genau dem Thema. Jedesmal wird gezeigt, wie man es mit wenig Aufwand und ganz ohne Interrupts richtig macht. Und immer wieder gibt es Leute, die das nicht glauben und in der Verwendung von Interrupts die eierlegende Wollmilchsau sehen. Eine Suche im Forum würde viel Zeit ersparen und auch so manchen Frust...
Zittermann schrieb: >>Drehenkoder fragt man nicht mit Interrupts ab. > Das bestimmst Du nicht. Es war noch nie besonders schwierig, anstatt einer guten, bekannten Lösung für ein Problem, eine deulich schlechtere, unzuverlässigere Lösung zu erfinden. Sinn macht diese "Interruptlösung" höchstens, wenn man einen Encoder ohne µC nur mit D-Flipflops bauen will und man das Ergebnis sieht und nachkorrigieren kann. Gruss Harald
Spontan unterstellte: >Du empfiehlst einen Code, hast aber anscheinend von der Problematik der >Drehgeber keine Anhnung. Ich empfehle gar nichts, habe nicht einmal den Code ausprobiert. Wogegen ich mich wende, ist die Einstellung: "Ich bestimme, was und wie andere Leute zu programmieren haben!" Jeder kann und darf seine Ideen auf dem Controller testen -er merkt schon, wenn es nicht funktioniert. gez. Zittermann
Zittermann schrieb: > Thomas schrieb: >>Lieber nicht! > > Was soll das? Das ist ein gut gemeinter Rat. > Zitat aus dem o.g. Thread: >>Bisher keine Probleme wegen "Prellens" festgestellt. Ein Zeichen dafür, daß ihr die Technik des Enkoder-Einlesens nicht verstanden habt. Ein Enkoder braucht mit einer vernünftigen Abfrage überhaubt keine Entprellung. > Der Code ist dort 65 mal heruntergeladen worden und es gab keinen > Kommentar, daß er nicht funktionieren würde. Dann gibt es den Kommentar jetzt: Der Code funktioniert nicht! >>Drehenkoder fragt man nicht mit Interrupts ab. > Das bestimmst Du nicht. >>Oder glaubst du, die ganzen Leute, die das hier ständig predigen, sind >alles > Idioten und du hast das Ei des Columbus entdeckt? > > Glaubst Du, anderen Leuten verbieten zu können, selbst etwas > auszuprobieren? Mach doch, was du willst. Aber wenn einer fragt, wie man es machen soll und jemand ihm totalen Schrott anbietet, sage ich ihm, daß er die Finger davon lassen soll. Oder willst du mir das verbieten? Der Link, unter dem steht, wie man es richtig macht, wurde mittlerweile von Spess gepostet. mfg.
Zittermann schrieb: > Jeder kann und darf seine Ideen auf dem Controller testen -er merkt > schon, wenn es nicht funktioniert. Klar darf jeder seine eigenen Erfahrungen machen. Aber es ist nicht die feine Art, wenn man jemanden, der die Sackgassen kennt und einen davor bewahren will, auf die Finger zu hauen "ich kann programmieren, wie ich will". Man kann nicht jedes Problem von Anfang an kennen, aber man kann Irrwege vermeiden, wenn man auf Leute hört, die wissen, wie man es macht und vor allem, wie man es nicht macht.
Hab mir hier schon einiges zu Drehencodern durchgelesen und hab mich für die Variante 1ms Interrupt entschieden. Initialisert wird mit dem Einschaltzustand des Encoders. Dann 5x rechts +5 links und Breakpoint bei test_cnt>20. Das Array im Debugger ausgeben. Leider ist das Ergebnis nicht wie erwartet eine Änderung der Bitfolge von z.B. 00 01 00 01 00 01 zu 11 10 11 10 11 10 beim ändern der Drehrichtung. Vielmehr wird immer mit 00 01 angezeigt. Es scheint kein Richtungswechsel passiert zu sein. Manchmal ändert sich auch die Bitfolge. Wenn ich zuerst nach rechts drehe dann kommt die 11 10 11 10. Auch hier ist die Änderung der Drehrichtung nicht zu sehen (immer noch 11 10 11 10) ? Langsam drehen - schnell drehen - kein Unterschied.
1 | char initialized = 0; |
2 | void Timer1Int(void); |
3 | |
4 | UINT8 code_old = 0; |
5 | INT8 code_delta = 0; |
6 | |
7 | void InitRotaryEnc(void){ |
8 | UINT8 code_new = 0; |
9 | |
10 | mInitRotaryEnc(); //input |
11 | |
12 | RegisterInt(TMR1_INT, &Timer1Int); |
13 | mEnableInterrupts(); |
14 | |
15 | CCPR1 = 0; //Timer data register zero (word) |
16 | ADCON1 |= 0xF; //all pins to digital |
17 | IPR1bits.CCP1IP = 1; //Timer 1 as source |
18 | RCONbits.IPEN = 1; //Interrupt priority |
19 | |
20 | // Configure Timer1
|
21 | OpenTimer1(T1_SOURCE_INT & |
22 | T1_8BIT_RW & |
23 | TIMER_INT_ON & |
24 | // T1_SOURCE_CCP &
|
25 | T1_PS_1_1); |
26 | |
27 | //get current detent steady point
|
28 | |
29 | code_new |= PORTAbits.RA0; |
30 | code_new<<=1; |
31 | code_new |= PORTAbits.RA1; |
32 | code_old = code_new; |
33 | |
34 | initialized = 1; |
35 | |
36 | }
|
37 | |
38 | |
39 | |
40 | |
41 | void Timer1Int(void) { |
42 | UINT8 code_new = 0, code_diff = 0; |
43 | |
44 | static UINT8 tst_cnt = 0; |
45 | static UINT8 tst_arr[100]= {0}; |
46 | |
47 | code_new |= PORTAbits.RA0; |
48 | code_new <<= 1; |
49 | code_new |= PORTAbits.RA1; |
50 | |
51 | if (code_new != code_old) { |
52 | code_old = code_new; |
53 | if (tst_cnt < 20) { |
54 | tst_arr[tst_cnt] = code_old; |
55 | tst_cnt++; |
56 | } else { |
57 | tst_cnt = 0; |
58 | }
|
59 | }
|
:
Bearbeitet durch User
Manuel Kampert schrieb: > Hab mir hier schon einiges zu Drehencodern durchgelesen Im Artikel Drehgeber gibt's einen Abschnitt "Dekoder für Drehgeber mit wackeligen Rastpunkten" der Exakt für Manuel Kampert schrieb: > Hab diesen Drehencoder von Pollin optimiert wurde. Probier den mal.
Manuel Kampert schrieb: > Leider ist das Ergebnis nicht wie erwartet eine Änderung der Bitfolge > von z.B. 00 01 00 01 00 01 zu 11 10 11 10 11 10 beim ändern der > Drehrichtung. Vielmehr wird immer mit 00 01 angezeigt. Dann hat es geprellt. Bei einem prellfreien Drehgeber und hinreichend schneller Abtastung kommen immer alle 4 Zustände vor: 00 01 11 10 00 ... bzw. für die Gegenrichtung: 00 10 11 01 00 ... Rastpunkte bedeuten nicht daß Zwischenzustände ausgelassen werden. Prellen bewirkt, daß das Encodersignal mehrfach zwischen immer den gleichen zwei Zuständen hin- und herspringt. Also bei Beachtung obiger Reihenfolge immer einen (Viertel-)Schritt vorwärts und einen rückwärts. Eine vernünftige Software (im Gegensatz zur der Frickelei mit Interrupts von oben) schaut auf die Zustände und zählt nur dann, wenn die Zustände in der korrekten Reihenfolge durchlaufen werden. Wenn man allerdings die volle Auflösung will (Viertelschritte) dann bekommt man mit prellenden Encodern zwangsläufig häufige Wechsel +1/-1. Besser verwendet man Halbschritte, in einem kompletten Zyklus aus 4 Zuständen zählt man also nur zweimal weiter. Das ist dann auch garantiert prellfrei. Ganz ohne Gefrickel mit RC-Gliedern. Insbesondere kann man bei Encodern mit wackeligen Rastpunkten die beiden Schaltpunkte zwischen die Rastpunkte legen. XL
Erstmal vielen Dank für die ganzen hilfreichen Artikel. Eine letzte Frage: if (PORTAbits.RA0 == 0 && PORTAbits.RA1 == 0) { int i=0; i++; } if (PORTAbits.RA0 == 0 && PORTAbits.RA1 == 1) { int i=0; i++; } if (PORTAbits.RA0 == 1 && PORTAbits.RA1 == 0) { int i=0; i++; } if (PORTAbits.RA0 == 1 && PORTAbits.RA1 == 1) { int i=0; i++; } sollte doch spätestens bei der achten Rasterung bei 00 und 11 angekommen sein - selbst bei wackeligem Rastpunkt und starkem prellen?
Thomas Eckmann schrieb: > Drehenkoder fragt man nicht mit Interrupts ab. Das bestimmst du? > Oder glaubst du, die > ganzen Leute, die das hier ständig predigen, sind alles Idioten Alle nicht, aber einige von ihnen sind es bestimmt. Viele andere sind zumindest lernfähig. In einem Punkt muß ich dir allerdings Recht geben. Der in Beitrag "Pollin Panasonic Encoder für Interrupt Fans" zitierte Code ist wirklich ziemlich Sch***. Er enthält gleich zwei wesentliche Schwächen. Das bedeutet aber keinesfalls, daß es nicht möglich wäre, Drehencoder allein mit Interrupts sinnvoll und extrem rechenzeitsparend abzufragen. Man muß halt nur programmieren können, mehr ist dazu wirklich nicht nötig... Und ja, ich muß zugeben, das geht sogar in C! Jedenfalls wenn man über die in etwa verdoppelte allgemeine Interruptlatenz mal gnädig hinwegsieht, die in den meisten Anwendungen wohl keine so wichtige Rolle spielt. Jedenfalls nicht in denen, die sowieso rein in C geschrieben sind...
c-hater schrieb: > Thomas Eckmann schrieb: > >> Drehenkoder fragt man nicht mit Interrupts ab. > > Das bestimmst du? Warum fragen eigentlich ständig irgendwelche Hampel, ob ich das bestimme? Das ist einfach so. Also freu dich, Hatie. Du hast was dazu gelernt. mfg.
Thomas Eckmann schrieb: > c-hater schrieb: >> Thomas Eckmann schrieb: >> >>> Drehenkoder fragt man nicht mit Interrupts ab. >> >> Das bestimmst du? > > Warum fragen eigentlich ständig irgendwelche Hampel, ob ich das > bestimme? Du hättest es einfach anders formulieren müssen. Beispiel: "Nur blutige Anfänger oder lernbehinderte Deppen fragen Drehenkoder mit Interrupts ab." Da niemand freiwillig zugeben wird, in eine der genannten Kategorien zu fallen, wird der Widerspruch entsprechend geringer ausfallen. XL
Manuel Kampert schrieb: > Erstmal vielen Dank für die ganzen hilfreichen Artikel. Eine letzte > Frage: > > if (PORTAbits.RA0 == 0 && PORTAbits.RA1 == 0) { > int i=0; > i++; […] Du setzt in jedem der if-Blöcke eine lokale Variable auf 0, um sie dann um eins hochzuzählen. Sobald du aus den {} draußen bist, ist dein i aus dem Scope und damit "vergessen."
Manuel Kampert schrieb: > sollte doch spätestens bei der achten Rasterung bei 00 und 11 > angekommen sein - selbst bei wackeligem Rastpunkt und starkem prellen? Der sollte schon beim 3. Rastpunkt jeden Zustand durch haben. btw: Was soll denn der Code den sie da gepostet haben Ihrer Meinung nach machen?
:
Bearbeitet durch User
Thomas Eckmann schrieb: > Drehenkoder fragt man nicht mit Interrupts ab. .. > Das ist einfach so. Also freu dich, Hatie. Du hast was dazu gelernt. Du hast heute deinen arroganten Tag, ja? Händisch bediente Drehencoder haben so seltene Ereignisse, daß man sie getrost per Interrupt abfragen kann - und sollte. Sowas zu pollen ist einfach nur Zeitverschwendung. Schließlich kann der daraus entstehende Zählwert ja nur um exakt 1 hin und her wandern, wenn der Encoder prellen sollte. Das ist OK so, schließlich landet der Wert ja doch auf dem gewünschten Stand, sobald man über den Umschaltpunkt hinweg ist und in die Nähe der Rastung kommt. Also, das "Das ist einfach so" kannst du getrost für dich behalten, es ist Mumpitz. Und zum TO: Manuel Kampert schrieb: > AB 0,0 0,1 1,0 und 1,1. Vielleicht ist dir aufgefallen, daß man das ganze reduzieren sollte. Signal A für den Interrupt und Signal B für die Richtung. Wenn also A sich ändert (beide Flanken beachten!), dann ersieht man aus (B xor A) die Richtung. Drehrichtung = A xor B; oder als ISR: __isr void DrehMich (void) { if (a^b) ++MyCounter; else --MyCounter; ClearMyInterrupt(); } Haben wir's jetzt? (Leute, stellt euch nicht so ******* an!) W.S.
W.S. schrieb: > Händisch bediente Drehencoder haben so seltene Ereignisse, daß man sie > getrost per Interrupt abfragen kann - und sollte. S Man ist blöd, wenn man das glaubt, prellen ist immer gleich schnell. http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.29
W.S. schrieb: > Du hast heute deinen arroganten Tag, ja? > Also, das "Das ist einfach so" kannst du getrost für dich behalten, es > ist Mumpitz. Mit welcher Arroganz kommst du denn daher? Erstens wirst du mir kaum erzählen, was ich für mich zu behalten habe und zweitens ist es kein Mumpitz. Axel Schwenke schrieb: > Du hättest es einfach anders formulieren müssen. Beispiel: > "Nur blutige Anfänger oder lernbehinderte Deppen fragen Drehenkoder > mit Interrupts ab." Dem ist nichts hinzuzufügen. mfg.
Das schöne bei gepollten Drehgebern ist, das man ihre 'Prellstärke' über das Zeitintervall in weiten Grenzen abfangen kann. Bei richtig ollen Drehgebern (z.B. aus alten Autoradios) ist die Prellerei so stark, das man am besten nur alle 5-10ms nachfragt. Wer das in einem flankengetriggerten Interrupt macht, muss da richtig Zeit für aufwenden. Da die Timer ISR vorhersehbare Verarbeitungszeit besitzt und nebenbei z.B. auch noch Taster abfragen kann, halte ich das für keinen grossen Preis für eine zuverlässige Encoderabfrage. Und ja, ich habe die Dinger früher auch immer per Flanken-Interrupt abgefragt. Das geht bei neuen Drehgebern auch sehr fein (vor allem, wenn sie nicht auf der Flanke rasten), baut allerdings mit zunehmendem Alter des Gebers ab.
Manuel Kampert schrieb: > int i=0; > i++; Hab ich weiter oben gefunden, nuicht nur einmal, sondern 4x. Was willst Du damit erreichen?
Matthias Sch. schrieb: > Wer das in einem flankengetriggerten Interrupt macht, muss da richtig > Zeit für aufwenden. Nein; siehe Code von W.S. weiter oben. Mit einem RC-Glied am hysterisierten Eingang wird sichergestellt, dass der nächste Flankenwechsel erst kommen kann, wenn der vorherige verarbeitet wurde. Rechenzeit wird nur proportional zur Frequenz verbraucht, egal, ob 10Hz oder 20kHz. In Ruhestellung wird garkeine Zeit benötigt. In einem Jahr kann man somit 3h19m04,6472s an Rechenzeit sparen!
m.n. schrieb: > Mit einem RC-Glied am hysterisierten Eingang wird sichergestellt, dass > der nächste Flankenwechsel erst kommen kann, wenn der vorherige > verarbeitet wurde. Rechenzeit wird nur proportional zur Frequenz > verbraucht, egal, ob 10Hz oder 20kHz. In Ruhestellung wird garkeine Zeit > benötigt. Wenn mein 4 Jahre alter Golf mal das Zeitliche gesegnet hat, werde ich nachschauen, ob die auch so eine Sch... verbaut haben. Jedenfalls macht der Drehgeber für die Innenraumtemperatur seit ein paar Wochen alles Mögliche, wenn ich daran drehe - egal welche Richtung.
m.n. schrieb: > Mit einem RC-Glied am hysterisierten Eingang wird sichergestellt, dass > der nächste Flankenwechsel erst kommen kann, wenn der vorherige > verarbeitet wurde. Genau das isses doch. Ein prellender Drehgeber erzeugt eben nicht nur eine Nutzflanke, sondern auch noch einen Haufen unnützer Flanken. Wer bestimmt denn, wann die Flanke verarbeitungsfähig ist? Ich habe schon sehr viel mit Drehgebern aller Coleur gemacht, und es gibt solche, die mit Flanken-ISR gut funktionieren, es gibt aber auch solche, wo du entweder riesige RC Glieder einfügen müsstest, oder viele ms in der ISR vertrödelst. Klar, wenn man nur einen (guten) Drehgeber hat und auch immer dieser verwendet wird, kannst du das anpassen, mir ist es aber lieber, wenn ich per #define die 'Qualität' des Drehgebers so anpassen kann, das es mit allen geht, die mir unterkommen. Das reicht dann von schrottigen alten Autoradios bis zu industriellen Qualitätsgebern der 300 Euro Klasse. Frank M. schrieb: > Jedenfalls macht > der Drehgeber für die Innenraumtemperatur seit ein paar Wochen alles > Mögliche, wenn ich daran drehe - egal welche Richtung Nach 4 Jahren finde ich das unmöglich, vor allem in so einem teuren Auto...
:
Bearbeitet durch User
Laß mich raten: den hast Du Dir gekauft, nachdem Du einen ADAC-Test gelesen hast. Weiterhin ist dort wohl noch ein AVR verbaut; mit einem STM32 gäbe es keine Fehlfunktion :-) Es gibt viele Möglichkeiten, Fehler zu machen. Auswertungen per Interrupt zu erledigen, gehört nicht zwingend dazu.
das mit dem # int i; i++ hab ich nur gemacht das ich hier einen Breakpoint setzen kann :-) Gibt's da ne andere Möglichkeit? breakpoint; oder sowas?
Matthias Sch. schrieb: > Genau das isses doch. Ein prellender Drehgeber erzeugt eben nicht nur > eine Nutzflanke, sondern auch noch einen Haufen unnützer Flanken. Wer > bestimmt denn, wann die Flanke verarbeitungsfähig ist? Jede Flanke muß verarbeitet werden! Das RC-Glied muß nur soweit verzögern, bis der vorherige Interrupt abgearbeitet ist. Wenn es dann 5ms lang Prellen sollte, wird eben ein paar mal +1 und -1 ausgewertet. Mich stören bei diesem Thema immer die Schreihälse, die ohne jemals differenziert nachgedacht zu haben lospoltern: "Das darf man nicht!"
m.n. schrieb: > Mich stören bei diesem Thema immer die Schreihälse, die ohne jemals > differenziert nachgedacht zu haben lospoltern: "Das darf man nicht!" Jo, die stören auch mich. Wie oben erwähnt, habe ich eben alles mögliche ausprobiert, ohne Vorurteile und auf einigen verschiedenen Platformen. (AVR, Freescale, STM32, MCS51 usw.) m.n. schrieb: > Das RC-Glied muß nur soweit > verzögern, bis der vorherige Interrupt abgearbeitet ist. Wenn es dann > 5ms lang Prellen sollte, wird eben ein paar mal +1 und -1 ausgewertet. Aber damit ziehst du dir wieder die Unwägbarkeiten der verschiedenen Geber ein und musst das RC Glied entsprechend sorgfältig dimensionieren. Ich stimme dem aber zu, das externe Bedienelemente, die direkt auf Portpins eines MC gehen, ESD Problematik besitzen und man deswegen sowieso etwas Hardware einsetzen muss, um Transienten usw. vom MC fernzuhalten. Aber während die Timer ISR vorhersehbar immer die gleiche Zeit in regelmässigen Intervallen zubringt, ist eine ISR, die auf jede Flanke eines prellenden Drehgebers reagiert, evtl. ein Grund für Seiteneffekte im Programm, auf die ich gerne verzichte, vor allem, wenn nebenbei noch irgendwelche zeitkritischen Routinen arbeiten. Meine Timer ISR fragt Drehgeber und Taster ab, erledigt die Echtzeituhr und ist ansonsten unauffällig. Wenn dann noch die elegante 'Taster lang' und 'Taster kurz' Routine mit Repeat Funktion dazukommt, ist die gesamte Benutzereingabe in der einen Routine abgefrühstückt.
Matthias Sch. schrieb: > Aber damit ziehst du dir wieder die Unwägbarkeiten der verschiedenen > Geber ein und musst das RC Glied entsprechend sorgfältig dimensionieren. Anders herum, die Zeitkonstante muß zum µC passen. Wenn dieser in der Lage ist, z.B. alle 50µs eine neue Flanke zu verarbeiten, reicht eine entsprechend kurze Zeitkonstante aus. Aber ansonsten stimme ich Dir zu, so wie Du es machst. Bei manueller Betätigung von Drehgebern mit niedriger Auflösung kann man gemächlich pollen. Anders sieht es aus, wenn nichtrastende optische Drehgeber verwendet werden, die keine stabile Flanke im Ruhezustand ausgeben. Da wird man sich schwer überlegen, ob man per Interrupt auswertet oder im kHz-Bereich pollt. Optische Drehgeber bieten sich z.B. an, um die Drehung dynamisch auszuwerten: Frequenzabstimmung an einem Funktionsgenerator oder hoch aufgelöster, horizontaler Kurvenverschiebung bei einem Megabyte Oszi, was die Hersteller aus Billigheim noch nicht begriffen haben. Das nervt mich mehr, als die Temperatureinstellung im Auto.
Gestern müssen die Irrenhäuser zum Ausgangstag aufgerufen haben, so viele Noobs wie hier das eigentlich geklärte Thema Inkrementalödecoderabfrage mit ihrem himmelschreienden Unwissen über die Probleme der flankengesteuerten Abfrage verseuchen.
Leider habe ich keine Ahnung warum hier jetzt so viele gerade diese Thema benutzen um sich hier so anzugreifen... Ich denke es führen viele Wege nach Rom. Ich habe meinen Fehler auf jeden fall - auch mit eurer Hilfe - gefunden. Ursache war das schöne bunte lange Flachbandkabel. Auf 5cm gekürzt läuft alles so wie ich mir das gedacht habe :-) Vielen Dank! Manuel
>Ich habe meinen Fehler auf jeden fall - auch mit eurer Hilfe - gefunden. >Ursache war das schöne bunte lange Flachbandkabel. Auf 5cm gekürzt läuft >alles so wie ich mir das gedacht habe :-) Stell doch mal ein Foto Deines Aufbaus rein. Obige Aussage glaub ich einfach nicht. Nicht bei Signalen unter 50 MHz.
Manuel Kampert schrieb: > Leider habe ich keine Ahnung warum hier jetzt so viele gerade diese > Thema benutzen um sich hier so anzugreifen... > > Ich denke es führen viele Wege nach Rom. > > Ich habe meinen Fehler auf jeden fall - auch mit eurer Hilfe - gefunden. > Ursache war das schöne bunte lange Flachbandkabel. Auf 5cm gekürzt läuft > alles so wie ich mir das gedacht habe :-) Wie lang war das denn vorher? Ich glaube, du hast eher die Symptome kuriert. mfg.
@ spontan (Gast) >>Ich habe meinen Fehler auf jeden fall - auch mit eurer Hilfe - gefunden. >>Ursache war das schöne bunte lange Flachbandkabel. Auf 5cm gekürzt läuft >>alles so wie ich mir das gedacht habe :-) >Stell doch mal ein Foto Deines Aufbaus rein. Obige Aussage glaub ich >einfach nicht. Nicht bei Signalen unter 50 MHz. Das hat mit 50 MHz direkt nicht zu tin, wohl aber was mit Anstiegszeiten. Siehe Wellenwiderstand. Wobei hier eher kein Laufzeiteffekt ne Rolle spielt sondern eher ein kapazitives Übersprechen. Allerdings kann ich mir bei einem DREHGEBER das nicht so recht vorstellen, es sei denn, auf der Nachbarader läuft ein aktives Signal.
Falk Brunner schrieb: > Übersprechen. Allerdings kann ich mir bei einem DREHGEBER das nicht so > recht vorstellen, Zumindest nicht, wenn man eine vernünftige Schaltung ohne Interrupt verwendet. :-) Gerade Drehgeber werden ja oft über lange Kabel angeschlossen. Gruss Harald
Harald Wilhelms schrieb: > Zumindest nicht, wenn man eine vernünftige Schaltung ohne > Interrupt verwendet. :-) Aaargh, nicht schon wieder :-P Lange Leitungen zu Tastern und so sind aber schon empfindlich, wenn man sich nur auf die eingebauten Pullups z.B. der AVR verlässt. Die sind mit ihren 30k-80k doch schon recht hochohmig und machen die Zuleitungen unnötig empfindlich. Kräftigere externe Pullups mit 1k-5k6 sollten das Problem dann beheben.
Da muß mit der Auswertung grundsätzlich etwas nicht in Ordnung sein. Selbst die schwachen Pullup-Widerstände könnten nur für gelegentliche Störungen verantwortlich sein, aber nicht bei einigen Zentimetern Leitungslänge. spontan schrieb: > Stell doch mal ein Foto Deines Aufbaus rein. Dem stimme ich spontan zu!
Auch wenns warscheinlich schon wieder zum alten Eisen gehört, ich habe mir gerade so eine Encoderauswertung mit Parsic entwickelt. Das Ding funktioniert tadellos und kommt ohne Interrupt aus. Da Parsic ASM Code für PIC's schreibt und das wohl weniger interessiert könnte aber das Prinzip von Interesse sein. Das Konzept verbraucht "für sich" etwas über 1ms und wenn der PIC dadurch unnötig langsam wird, sollte der Code mit Bedacht in den Gesamtablauf eingebaut werden. Die Monoflop MF2 ist nur zum Test drin, da eine LED mit 1 Shot nicht reagieren würde. RS1 liefert je nach Drehrichtung H oder L. Bei mir bedient diese Schaltung einen Aufwärts- Abwärtszähler den ich zur Steuerung einer China DDS mit AD9850 benötige.
Gerd H. schrieb: > Das Ding funktioniert tadellos Nein, natürlich nicht, nur das siehst du in deinem Simulator mit idealen Eingangssignalen nicht. Warum muss man es mit aller Gewalt prinzipiell falsch machen und sich dann schönreden ? Die einfachere korrekte Schaltung ist nicht patentiert, die darf man benutzen. +---+ A -----|D Q|---+ +-|T | +-(---------- Clock | +---+ | | +---+ +-------+ +---| | | +---+ | |XOR|-- Forward Direction B ---(-|D Q|-+ | +-| | +-|T | | | | +---+ | +---+ | | | +---(-------+ | | +---+ | +-(-------(-+-(-| | | | | +---+ | | |XOR|-+ +---+ | +-(-|D Q|-(---(-| | +-| | | +-|T | | | +---+ |XOR|-- Clock Enable | | +---+ | | +---+ +-| | | | +---(-| | | +---+ | | +---+ | |XOR|-+ +---(-|D Q|-----+-| | +---+-|T | +---+ | +---+ +---+ |555| +---+
@MaWin Aus voller Überzeugung .... nein, das Ding kann nicht funktionieren. Denkst du, ich glaube rein weg einem Simmulator? Wenn ich einen kleinen Beitrag veröffentliche, habe ich das vorher auch praktisch ausprobiert und auf Herz und Nieren getestet. Es führen viele Wege nach Rom und so falsch kann sie nicht sein, da ich 1. ne vollkommen logische Begründung für die Funktion habe und 2. das Ding auch praktisch funktioniert, mit zugegeben auch "schlechten" Exemplaren von P. Ich habe von den Dingern noch nen Sack voll und deren Eigenarten genau untersucht. gelle Nachtrag: Die LED auf dem Bild leuchten natürlich nicht, is ja kein Strom drann, auch wenns so aussieht
:
Bearbeitet durch User
Gerd H. schrieb: > Denkst du Ja, ich denke. Du spielst hier denjenigen, der mit dem Perpetuum Mobile zum Patentamt will, und sich wundert, warum er ausgelacht wird.
kopschüttel, was soll das ...... Solche Anmache und Überheblichkeit ist mir in noch keinem Board untergekommen. Kein Mensch hat etwas von Patent geschrieben. Ich dachte hier geht es um Elektronik, aber das Zwischenmenschlische scheint viiiiiel wichtiger. Jetzt habe ich die anderen Beiträge von MaWin gelesen, könnte glatt der "golden nugget" aus dem Progforum sein,;-)
:
Bearbeitet durch User
Die Panasonic Drehgeber sind recht gut und prellen von vorneherein recht wenig, vor allem wenn sie neu sind. Mit zunehmender Lebensdauer allerdings bildet sich (vermutlich Silber-)Oxid auf den Kontakten und dann prellts ein wenig mehr, so das du evtl. die Zeitkonstante des (1ms) MMV anpassen müsstest.
Hallo Matthias, Du hast Recht, die Dinger sind sind gut. Einziges Manko, wenn das Fett im Inneren "ranzig" wird, wird der Verstellvorgang links / rechts träge. Die 1 ms muss man bei Parsic nicht so dogmatisch sehen. Steht zwar am Modul, ist aber auch vom kompletten Programmdurchlauf abhängig. Man könnte zwar den tatsächlichen Wert errechnen, aber dann auch pratisch testen ist besser. In den Hilfen von Parsic steht die Formel, wie sich der Wert zusammensetzt. Die Wenigsten hier im Board werden das Prog noch benutzen und so gehe ich da nicht weiter drauf ein. Lassen wir die 1ms stehen oder entsprechend deiner Anmerkung eine längere Verzögerung.
Bitte 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.