Hallo, ich habe mit Drehimpulsgebern scheinbar noch leichte Verständnisschwierigkeiten. Wenn ich einen Geber 20/20 (20 Impulse/20 Rastungen) habe. In welchem Bereich habe ich dann die 20 Impulse? Sind das dann 20 Impulse pro Rastung? Zuerst dachte ich, dass dann ein Impuls pro Rastung kommt. Aber das ist nicht der Fall. Da kommen massig Impulse. Ich habe den STEC11B13 (http://www.reichelt.de/STEC11B13/3/index.html?&ACTION=3&LA=446&ARTICLE=73916&artnr=STEC11B13&SEARCH=stec11b13#av_tabtech) von Reichelt. Irgendwie spinnt der ganz schön rum, mal 20 Impulse hoch, 5 runter, obwohl ich hoch drehe.
Klaus W. schrieb: > In welchem Bereich habe ich dann die 20 Impulse? Sind das dann > 20 Impulse pro Rastung? Nein, 20 Impulse pro Umdrehung und 20 Rastungen pro Umdrehung, d.h. bei jeder Rastung kommt ein Puls. > Irgendwie spinnt der ganz schön rum, mal 20 Impulse hoch, > 5 runter, obwohl ich hoch drehe. Das wird wohl an deiner Auswertung liegen.
Klaus W. schrieb: > Irgendwie spinnt der ganz schön rum, mal 20 Impulse hoch, > 5 runter, obwohl ich hoch drehe. Die Kontakte des Encoders prellen. Externes entprellen mit 2 RC Gliedern hilft.
Beide Terminals mit 10kOhm/100nF RC-Glied entprellen, dann kommen vernünftige Impulse heraus.
Hi Die Routinen von hier zur Entprellung funktionieren problemlos. Und das auch noch in 20 Jahren. MfG Spess
Welchen µC nutzt Du? Falls Du z.B. einen STM32 benutzt, sind Entprellung und 2-bit-Gray-Code-Encoder bereits als Peripherie enthalten.
:
Bearbeitet durch User
> spess53 schrieb: >> Die Routinen von hier zur Entprellung > > Wozu braucht man die? ;-) :-p Na zur Entprellung natürlich! Es gibt nämlich auch andere µC neben dem STM32. Zum Beispiel die ARV's. Und wenn kein Hardware-Interface im µC vorhanden ist, macht man es eben per Software. Das funktioniert tadellos, wie Spess schon schrieb.
Drehimpulsgeber brauchen keine Entprellung, solange die Abtastzeit per Software schneller ist als die Zeit zwischen 2 Pulsen. Wenn es doch Probleme macht, ist der Auswertealgorithmus falsch.
Heizer schrieb: > Drehimpulsgeber brauchen keine Entprellung … und man wertet die Impulse nicht per interrupt aus, das wurde hier auch noch nicht diskutiert. Wartet doch erstmal ab, ob im µC des TO ein Hardware-Interface ^^ vorhanden ist.
Hi >Welchen µC nutzt Du? >Falls Du z.B. einen STM32 benutzt, sind Entprellung und >2-bit-Gray-Code-Encoder bereits als Peripherie enthalten. Haben ATXMega auch. MfG Spess
Ich verwende einen Atmega8. Entprellung habe ich auch schon probiert. Macht keinen Unterschied. Laut Beschreibung des Algorithmus soll dort eine Entprellung bereits integriert sein. Die Drehimpulsgeber sind als "Problemkinder" bekannt. Mit "normalen" Auswertealgorithmen lassen die sich gar nicht auswerten. Da hatte jemand lange dran rum gebastelt, um das hin zu bekommen. War glaube ich sogar hier im Forum, bin ich mir jetzt aber nicht mehr sicher. Die Auswertung erfolgt per Interrupt. Dürfte sich aber auch nicht anders lösen lassen, da das Hauptprogramm viel macht und vermutlich eh zu langsam wäre. Hier mal der Code des Algorithmus:
1 | Shift Zustandswechsel , Left , 2 |
2 | Zustandswechsel.0 = Encoder_a |
3 | Zustandswechsel.1 = Encoder_b |
4 | Zustandswechsel = Zustandswechsel And &B00001111 ' And 15 benötige nur 4 Bit |
5 | If Zustandswechsel = &B00000100 Then ' = 4 erst muss 01 kommen, dann 00 |
6 | Decr Enc_wert : Encoder_richtung = 0 ' Wert abziehen und Richtung setzen |
7 | If Nichtnull = 1 Then ' wenn 0 nicht erlaubt: |
8 | If Enc_wert = 0 Then Enc_wert = Enc_grenze ' wenn Wert=0 dann auf Grenze setzen |
9 | Else |
10 | If Enc_grenze < Enc_wert Then Enc_wert = Enc_grenze ' rechne: 0-1=255 Überlauf! , dann auf Grenze setzen |
11 | End If ' geht auch mit Word statt Byte |
12 | Else |
13 | If Zustandswechsel = &B00001000 Then ' = 8 erst muss 10 kommen, dann 00 |
14 | Incr Enc_wert : Encoder_richtung = 1 ' Wert erhöhen und Richtung setzen |
15 | If Enc_grenze < Enc_wert Then Enc_wert = Nichtnull ' wenn Grenze überschritten, dann auf 0 oder 1 setzen |
16 | End If |
17 | End If |
18 | If Encoder_richtung = 0 Then |
19 | Drehencoder_wert = Drehencoder_wert - 1 |
20 | Else |
21 | Drehencoder_wert = Drehencoder_wert + 1 |
22 | End If |
Klaus W. schrieb: > Ich verwende einen Atmega8. Entprellung habe ich auch schon > probiert. Was für eine Entprellung? Hardware? Software? > Macht keinen Unterschied. Dann funktioniert die Entprellung nicht. > Laut Beschreibung des Algorithmus soll dort > eine Entprellung bereits integriert sein. > Die Drehimpulsgeber sind als "Problemkinder" bekannt. Das sehen 99% anders. > Mit "normalen" > Auswertealgorithmen lassen die sich gar nicht auswerten. Auch das sehen 99% anders. Sie machen es einfach. > Da hatte jemand > lange dran rum gebastelt, um das hin zu bekommen. Glaube ich auch. Wenn man nur "bastelt" und es nicht richtig macht. > War glaube ich sogar > hier im Forum, bin ich mir jetzt aber nicht mehr sicher. Klar war es schon im Forum. Gefühlte 1000mal. Da bin ich mir sicher. > Die Auswertung > erfolgt per Interrupt. Aha, jetzt kommen wir der Sache schon etwas näher. Auch dieser Punkt wurde schon bis zum Erbrechen diskutiert. > Dürfte sich aber auch nicht anders lösen lassen, > da das Hauptprogramm viel macht und vermutlich eh zu langsam wäre. Das wurde mehrfach widerlegt. Unter anderem von Peter Dannegger. Such mal im Forum, das ist voll davon.
Joe F. schrieb: > Die Kontakte des Encoders prellen. > Externes entprellen mit 2 RC Gliedern hilft. Das ist die lange Schreibweise von "Murks". Klaus W. schrieb: > Da hatte jemand lange dran rum gebastelt, um das hin zu bekommen. > Die Auswertung erfolgt per Interrupt. Dürfte sich aber auch nicht anders > lösen lassen, da das Hauptprogramm viel macht und vermutlich eh zu > langsam wäre. Das ist die noch wesentlich längere Schreibweise von "Murks". > Die Drehimpulsgeber sind als "Problemkinder" bekannt. Mit "normalen" > Auswertealgorithmen lassen die sich gar nicht auswerten. Peter kann das. Ich kann das. Und andere. Man muss "Problemkinder" nur richtig analysieren und anpacken... Einmal in VHDL: http://www.lothar-miller.de/s9y/categories/46-Encoder Und einmal mit "Beschleunigung" in C: http://www.lothar-miller.de/s9y/categories/54-Encoder
Klaus W. schrieb: > Zuerst dachte ich, dass dann ein Impuls pro Rastung kommt. So ist es auch. > Irgendwie spinnt der ganz schön rum, mal 20 Impulse hoch, > 5 runter, obwohl ich hoch drehe. Das liegt sicher nicht am Drehgeber. Wie fragst du ihn denn ab ? So macht man es richtig: http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.29 http://www.mikrocontroller.net/articles/Drehgeber So macht man es falsch: Joe F. schrieb: > Externes entprellen mit 2 RC Gliedern hilft. Hu Z. schrieb: > Beide Terminals mit 10kOhm/100nF RC-Glied entprellen, dann kommen > vernünftige Impulse heraus. Klaus W. schrieb: > Hier mal der Code des Algorithmus: Irgendwie verstehe ich deinen code nicht. Du wertest 2 Übergänge aus, von 01 nach 00 und von 10 nach 00, das war's, dabei gibt es 8 aktive Zustandswechsel, 4 passive und 4 illegale.
Torsten C. schrieb: > … und man wertet die Impulse nicht per interrupt aus, Doch, dafür gibt es je nach Anwendung praktische oder zwingende Gründe ;-)
m.n. schrieb: >> … und man wertet die Impulse nicht per interrupt aus, > Doch, dafür gibt es je nach Anwendung praktische oder zwingende Gründe Leierleierleierleierleierleierleierleierleierleierleierleierleierleierle ierleierleierleierleierleier... Natürlich wertet man einen Drehgeber im Interrupt(*) aus. Aber eben nicht per Interrupt(**). (*) Timerinterrupt (**) Pinchangeinterrupt
Klaus W. schrieb: > Laut Beschreibung des Algorithmus soll dort > eine Entprellung bereits integriert sein. > Die Drehimpulsgeber sind als "Problemkinder" bekannt. > Mit "normalen" Auswertealgorithmen lassen die sich > gar nicht auswerten. Der Algorithmus zur Auswertung von Drehimpulsgebern ist seit Jahrzehnten bekannt und u.a. in den DSE-FAQ beschrieben. Da keine Flanken sondern Pegel ausgewertet werden, braucht man auch keine Entprellung. Es gibt zwar eine einfache Auswertung über Flanken und D-Flipflops, die sich für "Handdreher" eignet, die funktioniert aber nicht immer sicher. Die "Standardauswertung" dagegen ist keinesfalls ein "Problemkind"; sie erfordert aber Grundkenntnisse über die Verwendung von Logikbausteinen, wenn man keine fertigen Unterprogramme verwenden will.
Lothar M. schrieb: > Natürlich wertet man einen Drehgeber im Interrupt(*) aus. Ja gut, nachdem die ISR durch einen PCINT ausgelöst wurde.
m.n. schrieb: > Ja gut, nachdem die ISR durch einen PCINT ausgelöst wurde. Nachdem die ISR durch einen Timer-Interrupt ausgelöst wurde natürlich.
:
Bearbeitet durch User
m.n. schrieb: > Ja gut, nachdem die ISR durch einen PCINT ausgelöst wurde. Wers so machen will, dass das auch in der EMV-verseuchten Umgebung deterministisch läuft, der nimmt den Timerinterrupt und pollt den Encoder...
Klaus W. schrieb: > Irgendwie spinnt der ganz schön rum, mal 20 Impulse hoch, > 5 runter, obwohl ich hoch drehe Kommt mir bekannt vor, so oder so ähnlich verhält es sich eigentlich allen Anwendungen, wo ich bislang damit konfrontiert wurde, vorzugweise aus dem Arduino Umfeld. ?!? schrieb: > Unter anderem von Peter Dannegger. Such > mal im Forum, das ist voll davon. Die Forumssuche ist Murks. Anstatt 100 Worte zu tippen wäre ein aussagekräftiges Stichwort oder auch ein Link hilfreicher. Über den Namen und mehrere Ecken habe ich letzlich einen Thread von P.D. dazu gefunden, aber erst, nachdem ich wusste, wonach ich suchen musste.
Lothar M. schrieb: > Wers so machen will, dass das auch in der EMV-verseuchten Umgebung > deterministisch läuft, der nimmt den Timerinterrupt und pollt den > Encoder... Wer keine anderen Drehgeber als den o.g. kennt, kann das ja so machen. Nur als allgemeine Lösung taugt das nunmal nichts, da hift kein Prollen.
bianchifan schrieb: > Die Forumssuche ist Murks. > Anstatt 100 Worte zu tippen wäre ein aussagekräftiges Stichwort oder > auch ein Link hilfreicher. Stichwort und Link gabs bereits vor über vier Stunden von MaWin. > Über den Namen und mehrere Ecken habe ich letzlich einen Thread von P.D. > dazu gefunden, aber erst, nachdem ich wusste, wonach ich suchen musste. Für Inkrementalgeber? Wie bereits gesagt, eine Entprellung ist unnötig. Leider wird im INet gerade über Inkrementalgeber sehr viel Unsinn verbreitet.
bianchifan schrieb: > Die Forumssuche ist Murks. Genau das musste ich auch schon feststellen. Da habe ich die Beiträge per Google-Suche besser gefunden. > Anstatt 100 Worte zu tippen wäre ein aussagekräftiges Stichwort oder > auch ein Link hilfreicher. > Über den Namen und mehrere Ecken habe ich letzlich einen Thread von P.D. > dazu gefunden, aber erst, nachdem ich wusste, wonach ich suchen musste. Ich sage zu den sinnlosen Antworten hier lieber nix. Hatte gedacht, hier gibts Fachpersonal. Danke an die sinnvollen Antworten, die anderen ignoriere ich. Behandlung per Interrupt-Auslösung wird sogar im Datenblatt von Hopt&Schuler beschrieben, ist also durchaus nicht so abwegig. Ich werde mir jedenfalls andere Drehgeber zulegen, die von Alps sind Murks, wie auch hier auf der Seite zu lesen ist: https://www.mikrocontroller.net/articles/Drehgeber Leider bin ich bei meiner Suche auf noch mehr von den "Schrott-Dingern" gestoßen. Wer die Raste exakt auf eine Flanke legt, hat das System definitiv nicht verstanden.
Klaus W. schrieb: > Wer die Raste exakt auf eine Flanke legt, hat das System > definitiv nicht verstanden. Das Problem lässt sich oft durch Vertauschen der beiden Ausgänge lösen. Grundsätzlich sind Flankenauswertungen bei Inkrementalgebern Pfusch. Das Pfusch manchmal trotzdem jahrelang funktioniert, sieht man tag- täglich in unserer realen Welt... :-)
Harald W. schrieb: > Grundsätzlich sind Flankenauswertungen bei Inkrementalgebern Pfusch. > Das Pfusch manchmal trotzdem jahrelang funktioniert, sieht man tag- > täglich in unserer realen Welt... :-) ...und leider wird dieser Pfusch von vielen Anfängern nachgemacht ("Steht ja im Internet, also muß es richtig sein"), siehe Klaus W. schrieb: > Ich sage zu den sinnlosen Antworten hier lieber nix. Hatte gedacht, hier > gibts Fachpersonal. > > Danke an die sinnvollen Antworten, die anderen ignoriere ich. > Behandlung per Interrupt-Auslösung wird sogar im Datenblatt von > Hopt&Schuler beschrieben, ist also durchaus nicht so abwegig. Was soll man dann noch sagen? Wer sich nichts sagen lassen will, dem kann man eben nicht helfen. Der muß eben mit Pfusch weiterleben, bis er vielleicht mal die Erfahrung macht, daß die anderen aufgrund langer Erfahrungen eventuell doch recht haben könnten.
Klaus W. schrieb: > Ich werde mir jedenfalls andere Drehgeber zulegen, die von Alps sind > Murks, wie auch hier auf der Seite zu lesen ist: > https://www.mikrocontroller.net/articles/Drehgeber Ich denke, für Deine vor noch 24h vorhandene Ahnungslosigkeit, bist Du jetzt ein wenig zu forsch. Weder sind diese Drehgeber einfach nur Murks, noch steht in dem bezeichneten, tendenziösen Artikel die alleinige Wahrheit. Und wenn Du noch mehr 'Schrottdinger' gefunden hast, solltest Du auch mal hinterfragen ob die Elektronik oder der Anwender 'schrottig' ist oder arbeitet. Nimm optische Drehgeber mit - sagen wir mal - 256 Impulsen/Drehung mit prellfreiem Ausgang. Da sollten dann alle Probleme entfallen, außer vielleicht das der Finanzierung. Noch etwas: Hopt&Schuler, muß man die kennen?
Klaus W. schrieb: > die von Alps sind Murks Klar, man kann auch teurere Inkrementaldrehgeber nehmen. Aber statt den Inkrementaldrehgeber kann man auch den µC wechseln. Hardware-Inkremental-Dekoder haben mit Pegelwechseln auf Rastpunkten kein Problem. @spess53 + Thomas W.: Danke für die Ergänzung: Der STM8S103F3P6 z.B. für 24 Cent, der SAM3X8E, der ATXMega usw. haben - wie gesagt - Hardware-Inkremental-Dekoder.
Klaus W. schrieb: > Danke an die sinnvollen Antworten, die anderen ignoriere ich. Ich hoffe, Du kannst die sinnvollen von den nicht sinnvollen Antworten unterscheiden. Die erste, sinnvolle Antwort kam m.E. von Torsten bereits nach einer Stunde.
m.n. schrieb: > Und wenn Du noch mehr 'Schrottdinger' gefunden hast, solltest Du auch > mal hinterfragen ob die Elektronik oder der Anwender 'schrottig' ist > oder arbeitet. Wenn ich nen Drehgeber habe, der Rasten hat und diese exakt auf einer Flanke liegen, ist das nicht im Sinne des Erfinders. Selbst wenn ich das mit Algorithmen raus rechne, ist es unnötiger Rechenaufwand. Dass der Kontakt bei jeder Erschütterung hin und her pendelt ist ja wohl klar. Um genau sowas zu vermeiden, hat er ja gerade eine Raste. Wenn ich das raus rechne, dann reduziere ich automatisch die Auflösung. Schließlich muss ich mir im Algorithmus immer die Frage stellen, ob das denn nun eine gewollte, oder ungewollte Bewegung ist. Der Wechsel erfolgt ja durchaus im erlaubten Rahmen, d.h. der Signalwechsel ist nicht von vornherein als illegal zu erkennen. Dementsprechend muss der Nutzer also den Regler weiter drehen, damit dies auch als Bewegung zweifelsfrei erkannt werden kann. Mit anderen, wo die Raste zwischen Flanken liegt, besteht das Problem erst gar nicht. Und bautechnisch ist das kein Mehraufwand, d.h. solche müssen also nicht mehr kosten. > Noch etwas: Hopt&Schuler, muß man die kennen? Nö, einer von vielen Herstellern. Man muss nicht alle kennen. Aber sehr viele Elektronikversender kennen die, da sie nämlich von denen was verkaufen.
Klaus W. schrieb: > Selbst wenn ich das mit Algorithmen raus rechne, ist es unnötiger > Rechenaufwand. Was willst Du da "rausrechnen? Ich denke, Du solltest Dich doch noch mal mit den Grundlagen von Inkrementalgebern beschäftigen. Übrigens gibt es Firmen, die mit Inkrementalgebern Auflösungen im Nanometerbereich erreichen. Natürlich muss dann auch die mechanische Stabilität stimmen. > Wenn ich das raus rechne, dann reduziere ich automatisch die Auflösung. Stimmt nicht. > Mit anderen, wo die Raste zwischen > Flanken liegt, besteht das Problem erst gar nicht. >> Noch etwas: Hopt&Schuler, muß man die kennen? > Nö, einer von vielen Herstellern. Wie bereits gesagt: Nicht alles was im INet steht, muss auch stimmen.
Klaus W. schrieb: > Wenn ich nen Drehgeber habe, der Rasten hat und diese exakt auf einer > Flanke liegen, ist das nicht im Sinne des Erfinders. Du wirst (hoffentlich) lachen, es gibt auch Drehgeber, bei denen ein Kanal die Impulse erzeugt, die gezählt werden können, und der andere Kanal von einem Schalter kommt, der in der einen Drehrichtung offen, und in der anderen Drehrichtung geschlossen ist. Der gibt nur die Richtung vor, so wie auch der 'flankende Rastpunkt' genutzt werden kann.
m.n. schrieb: > Du wirst (hoffentlich) lachen, es gibt auch Drehgeber, bei denen ein > Kanal die Impulse erzeugt, die gezählt werden können, und der andere > Kanal von einem Schalter kommt, der in der einen Drehrichtung offen, und > in der anderen Drehrichtung geschlossen ist. Der gibt nur die Richtung > vor, so wie auch der 'flankende Rastpunkt' genutzt werden kann. Ein solcher Spezialdrehgeber war in meinem Heizkörperthermostat verbaut und defekt. Leider findet man da praktisch keinen Ersatz. Jetzt muss ich mit einem Doppeltaster einstellen...
Harald W. schrieb: >> Wenn ich das raus rechne, dann reduziere ich automatisch die Auflösung. > Stimmt nicht. Richtig: Stimmt nicht, da es bei Alps zwei Flankenwechsel pro Raste gibt. Man shiftet den Counter um ein Bit nach rechts. So mache ich das seit Jahren und es funktioniert sogar mit 'nem Akkuschrauber-Test. :-p
Klaus W. schrieb: > Behandlung per Interrupt-Auslösung wird sogar im Datenblatt von > Hopt&Schuler beschrieben, ist also durchaus nicht so abwegig. Das Datenblatt hat dann natürlich auch extra RC an den Eingangssignalen: http://www.hopt-schuler.de/de/produkte/schalter/encoder/488
Torsten C. schrieb: > Klar, man kann auch teurere Inkrementaldrehgeber nehmen. Aber statt den > Inkrementaldrehgeber kann man auch den µC wechseln. Oder einen ergänzen: Beitrag "mini Quadraturdekoder + 32 Bit Zähler + TWI, Attiny25"
Clemens L. schrieb: > Das Datenblatt hat dann natürlich auch extra RC an den Eingangssignalen: > http://www.hopt-schuler.de/de/produkte/schalter/encoder/488 "Wenn ein Schalterpin an eine Unterbrechung Input des Mikrocontrollers angeschlossen wird" - naja, ob das die Glaubwürdigkeit des Datenblatts steigert? Allerdings wird die Polling-Variante ja auch explizit beschrieben. Aber warum soll man A und A' b.z.w. B und B' kurzschließen?
:
Bearbeitet durch User
Clemens L. schrieb: > Das Datenblatt hat dann natürlich auch extra RC an den Eingangssignalen: > http://www.hopt-schuler.de/de/produkte/schalter/encoder/488 Und die Interrupt-Variante wird als zweite Möglichkeit gezeigt. Das erste Beispiel behandelt das Polling mit Level- und nicht mit Flankenauswertung.
Torsten C. schrieb: > Klar, man kann auch teurere Inkrementaldrehgeber nehmen. Aber statt den > Inkrementaldrehgeber kann man auch den µC wechseln. Man muss weder noch tun. Die ALPS sind problemlos auswertbar mit den genannten richtigen Algorithmen, und es ist völlig egal, ob die Rastpunkte am Flankenwechsel liegen oder gar keine Rastpunkte da wären, gute Software funktioniert immer. Dein Algorithmus ist einfach falsch gewesen. Auch der Herr, der in https://www.mikrocontroller.net/articles/Drehgeber#Dekoder_f.C3.BCr_Drehgeber_mit_wackeligen_Rastpunkten rumgepfuscht hat, hat einfach ein völlig anderes Problem in den Auswertealgorithmus verlagert: Seine Eingaberoutine kam wohl nicht damit klar, daß sich von Abfrage zu Abfrage der Wert um +/-1 ändert, weil der Drehgeber mechanisch wackelt. Es war aber völlig richtig, daß dabei um +/-1 verändernde Werte geliefert wurden, denn so drehte sich auch der Drehgeber, er wurde völlig korrekt ausgewertet. Das Teilen durch 2 hätte nachher passieren sollen. Clemens L. schrieb: > Klaus W. schrieb: >> Behandlung per Interrupt-Auslösung wird sogar im Datenblatt von >> Hopt&Schuler beschrieben, ist also durchaus nicht so abwegig. > > Das Datenblatt hat dann natürlich auch extra RC an den Eingangssignalen: > http://www.hopt-schuler.de/de/produkte/schalter/encoder/488 Schrott funktioniert natürlich nur manchmal. Schrott muss auch nicht billig sein.
Raste auf Flankenwechsel ist Müll. Mag zwar kompensierbar sein und nicht unbedingt ein Argument einen anderen Encoder zu nehmen, das ändert aber nichts daran, dass das Müll ist. Bei Menuführung mit Drehencoder hab ich dann entweder ein Menu, was nur auf jede zweite Raste reagiert (wirkt seltsam) oder eine Stelle, in der es zappelt. Kann man sicher noch besser kompensieren, aber naja. Nicht optimal
Jan H. schrieb: > Raste auf Flankenwechsel ist Müll. Raste auf Flankenwechsel != Keine Flanke zwischen Rastpunkten
:
Bearbeitet durch User
Walter T. schrieb: > Jan H. schrieb: >> Raste auf Flankenwechsel ist Müll. > > Raste auf Flankenwechsel != Keine Flanke zwischen Rastpunkten Hat auch nie einer behauptet. Es geht einfach nur um die Aussage, dass die Raste exakt auf dem Flankenwechsel einfach Mist ist. Wenn im Ruhezustand ständis die Flanke zappelt, ist das nicht im Sinne des Erfinders eines Dregebers.
Jan H. schrieb:
> Raste auf Flankenwechsel ist Müll.
Der arme TO.
Hier schreiben so viele Leute Müll, wie soll der TO da noch
durchblicken?
Wer selbst (! das soll es auch noch geben!) programmiert und sich
Gedanken macht, für den ist so ein Drehgeber wohl kein Problem. Egal wo
die Rasterung zur Flanke sitzt.
Wer nur Code kopiert, für den ist alles was nicht auf Anhieb
funktioniert schlecht, kaputt, falsch, Mist und Müll.
Schade der TO hätte was lernen können, vor allem von Leuten die
Erfahrung haben.
Klaus W. schrieb: > dass > die Raste exakt auf dem Flankenwechsel einfach Mist ist Eigentlich stört sie nicht - man ignoriert sie einfach. Man muß nur wissen, welche der vier Flanken die "Nutzflanken" und welche die Flanken auf der Rastung sind.
Aber Flankenwechsel an dem Punkt, um den der losgelassene Encoder rum wackelt. Wenn er nach einer Erschütterung auf beiden Zuständen stehen bleiben kann, dann ist das wirklich unpraktisch. Wenn er eins hin und immer auch wieder zurück wackelt ist es eigentlich egal. Welcher der beiden Effekten tritt bei denen eigentlich genau auf. Ich hatte es interpretiert als ersteres.
Klaus W. schrieb: > Hat auch nie einer behauptet. Es geht einfach nur um die Aussage, dass > die Raste exakt auf dem Flankenwechsel einfach Mist ist. Wenn im > Ruhezustand ständis die Flanke zappelt, ist das nicht im Sinne des > Erfinders eines Dregebers. Walter T. schrieb: > Eigentlich stört sie nicht - man ignoriert sie einfach. Man muß nur > wissen, welche der vier Flanken die "Nutzflanken" Jan H. schrieb: > Mag zwar kompensierbar sein Korrektur auf: Ist mit geringem Aufwand kompensierbar. Müll ist ein zu starkes Wort dafür, da muss ich mich wohl entschuldigen. Es ist einfach suboptimal.
Warum ein Hersteller sich wünscht, mit seinen "Micro"-Schalterchen geladene Kondensatoren kurz zu schliesen, braucht man wohl nicht weiter erläutern. Oder doch? Er verkauft dann einfach mehr! (solange die Kunden das mitmachen)
Carl D. schrieb: > Warum ein Hersteller sich wünscht, mit seinen "Micro"-Schalterchen > geladene Kondensatoren kurz zu schliesen, braucht man wohl nicht weiter > erläutern. Oder doch? Er verkauft dann einfach mehr! (solange die Kunden > das mitmachen) oder er verhindert damit eine Oxidation der Kontakte. Der Strom bei 33nF sollte nicht zu einen Lichtbogen führen.
Carl D. schrieb: > Warum ein Hersteller sich wünscht, mit seinen "Micro"-Schalterchen > geladene Kondensatoren kurz zu schliesen, braucht man wohl nicht weiter > erläutern. Oder doch? Es gibt hier eine "Mindeststromfraktion", die Dir das sicher erklären kann. Derzufolge müssen Kontakte immer freigebrannt werden, damit sie nicht verstopfen aber auch noch nicht zusammenschweißen. Da ich persönlich sowieso in die Hölle komme, betreibe ich Kontakte mit Unterstrom u.a. auch im Mikroampere-Bereich. Das ist schwer verboten und dürfte garnicht funktionieren. Böse, böse. Insofern hätte ich mindestens 1 kOhm in Reihe zum Schalter eingezeichnet, was die Schaltung aber unnötig verteuern würde. Hier wird nämlich immer in Millionenstückzahlen kalkuliert und die beste Schaltung benötigt keinerlei Bauteile. Soviel zum Sommerloch-Drehgeber-Fred ;-)
m.n. schrieb: > Ich betreibe Kontakte mit Unterstrom u.a. auch im Mikroampere-Bereich. Aha. Bist Du vielleicht ein Untermensch? SCNR
Harald W. schrieb: > Aha. Bist Du vielleicht ein Untermensch? > SCNR Solange Du auf der anderen Straßenseite stehst und schnell laufen kannst, darfst Du das ruhig fragen ;-)
m.n. schrieb: > Oder einen ergänzen Wo bei ein ATtiny25 zwei bis dreimal so teuer ist, wie ein STM8S103F3P6 und auch keinen eingebauten Hardware-Incremental-Decoder hat. Aber ich weiss: Er ist im DIP und AVR ist sowieso besser. ;-)
Torsten C. schrieb: > m.n. schrieb: >> Oder einen ergänzen > > Wo bei ein ATtiny25 zwei bis dreimal so teuer ist, wie ein STM8S103F3P6 > und auch keinen eingebauten Hardware-Incremental-Decoder hat. > > Aber ich weiss: Er ist im DIP und AVR ist sowieso besser. ;-) ??? Wo kaufst Du Deine Bauteile? Digikey ATtiny25 1,36€ STM8S103F3P6 1,69€ Mouser ATtiny25 1,06€ STM8S103F3P6 1,56€ (Einzelpreise) Ja, ich weiss, dass das bei weitem nicht die günstigsten Bezugsquellen sind, aber ich wollte die Preise jeweils beim gleichen Anbieter vergleichen.
Ich hatte ja oben angedeutet, daß mir diese Millionenstückzahlschnorrer auf den Keks gehen, und prompt meldet sich einer zum Appell. Torsten C. schrieb: > Wo bei ein ATtiny25 zwei bis dreimal so teuer ist, wie ein STM8S103F3P6 Also ich zahle für einen ATtiny25 17 Cent. Was kostet Dein STM8 genau? Das zu dem Thema ;-) Für den ATtiny25 gibt es ein fertiges Programm, was funktioniert. Zum STM8 gibt es nur virtuelles Säbelrasseln.
m.n. schrieb: > Zum STM8 gibt es nur virtuelles Säbelrasseln. Nein, steht oben, da ist nix virtuelles. Das ist ein freundlicher Hinweis. Wie kommst Du auf "Säbelrasseln"? Bernd schrieb: > Wo kaufst Du Deine Bauteile Steht im China-Thread. ATTINY25-20SU: €0,67 / piece incl. Versand. Gehört aber auch in den China-Thread und nicht hierher.
:
Bearbeitet durch User
Walter T. schrieb: > Klaus W. schrieb: >> dass >> die Raste exakt auf dem Flankenwechsel einfach Mist ist > > Eigentlich stört sie nicht - man ignoriert sie einfach. Man muß nur > wissen, welche der vier Flanken die "Nutzflanken" und welche die Flanken > auf der Rastung sind. Dazu kommt noch, daß 20 Impulse pro Umdrehung gleich 40 Pegelwechsel sind (ein Impuls ist immer ein Übergang von L zu H und ein weiterer von H zurück auf L). Da üblicherweise die Impulse pro Phase und Umdrehung angegeben werden, sind es insgesamt 80 Codewechsel je Umdrehung. Oder 4 Codewechsel pro Raststufe. Feiner als eine Raststufe kann man einen rastenden Encoder ohnehin nicht auswerten. Selbst wenn der Rastpunkt genau auf einem Codewechsel liegt - die anderen drei Codewechsel sind stabil. Man findet also mit minimaler Anstrengung eine Auswertung, die stabile Werte liefert.
m.n. schrieb: > Es gibt hier eine "Mindeststromfraktion", die Dir das sicher erklären > kann. Derzufolge müssen Kontakte immer freigebrannt werden, damit sie > nicht verstopfen aber auch noch nicht zusammenschweißen. Aber diese Pauschalisierung ist leider falsch. Es gibt sonne und solche Kontakte. Welche, die mit sehr kleine Ströme gut zurecht kommen, und welche, die damit Probleme haben. Machmal werden diese Eigenschaften beim Kontaktmaterial auch kombiniert: Kontakte für große Ströme, die zusätzlich hauchvergoldet sind. Das Gold verhindert Oxidation und kann daher kleine Ströme schalten. Wird der Kontakt aber mit hohen Strömen belastet, verdampft das Gold und es ist nur noch ein Hochstromkontakt. > Da ich persönlich sowieso in die Hölle komme, betreibe ich Kontakte mit > Unterstrom u.a. auch im Mikroampere-Bereich. Das ist schwer verboten und > dürfte garnicht funktionieren. Böse, böse. Es muss also gar nicht böse sein wenn Du das tust. Aber musst Du auch genau wissen, was Du tust. Leider lässt sich die Welt oft nicht auf ein einfaches "gut" oder "böse" reduzieren ... Gruß Dietrich
Dietrich L. schrieb: > Aber diese Pauschalisierung ist leider falsch. Das wollte ich ja mit meinem 'Zitat' auch zum Ausdruck bringen. Ebenso wie es auch Gründe gibt, Drehgeber unterschiedlich auszuwerten: polling oder als Interruptquelle. Nur die vielen Fliegen kennen immer nur ihren Haufen und bestehen darauf, daß er der einzig wahre sei. Ab und zu muß man dann die Klatsche nehmen, auch wenn das Getöse groß wird ;-) Axel S. schrieb: > Feiner als eine Raststufe kann man einen rastenden Encoder ohnehin nicht > auswerten. Selbst wenn der Rastpunkt genau auf einem Codewechsel liegt - > die anderen drei Codewechsel sind stabil. Man findet also mit minimaler > Anstrengung eine Auswertung, die stabile Werte liefert. So ist es!
m.n. schrieb: > Nur die vielen Fliegen kennen immer nur ihren Haufen und bestehen > darauf, daß er der einzig wahre sei. Genau! Millionen von Fliegen können nicht irren: Scheisse schmeckt köstlich. :-)
m.n. schrieb: > Das wollte ich ja mit meinem 'Zitat' auch zum Ausdruck bringen. Ebenso > wie es auch Gründe gibt, Drehgeber unterschiedlich auszuwerten: polling > oder als Interruptquelle. Wie für m.n. üblich: Unvollständige Beschreibung lässt Interpretation scheunenweit offen. Interrupt kann hier Timerinterrupt oder Flankeninterrupt sein. Timerinterrupt ist kein Problem. Flankeninterrupt ist immer falsch. Damit ist die allgemeine Aussage "interruptquelle" nutzloses Geschwätz. Aber selbst das "Zitat" hilft m.n. nicht; Beitrag "Mindeststrom bei Taster/Schalter für sicheren Betrieb?" Hier kommt der Mindeststrom beim Kontakt her. a) Der Fragende in dem Thread hat wirklich ein Problem mit dem Mindeststrom. b) Die Antwort in dem Thread von m.n. ist nutzlos. Marvin M. bringt das gut rüber: Datum: 17.02.2013 14:20 @m.n. Dein Beitrag strotzt ja vor Wissen. Begründungen? Nur zur Info: Auch Goldkontaktschalter brauchen Mindeststrom, nur Quecksilberbenetzte Kontakte nicht, aber Quecksilber ist in Zeiten von RoHS rar. Man muss also sage. i.A. brauchen Schalter einen Mindeststrom. Sogar dann, wenn keiner im Datenblatt steht.-
MaWin schrieb: > Flankeninterrupt ist immer falsch. > Damit ist die allgemeine Aussage "interruptquelle" nutzloses Geschwätz. Damit der Sommerlochthread nicht stirbt: Ich finde es trotzdem gut! Bin ich doch viel zu faul irgendwas ständig abzufragen, das möglicherweise nie benutzt wird. Der Drehgeber soll mir gefälligst Bescheid sagen, wenn er was will ...
Volker S. schrieb: > Der Drehgeber soll mir gefälligst Bescheid sagen, wenn er was will ... Drehgeber: "Bescheid!"
Volker S. schrieb: > Bin ich doch viel zu faul irgendwas ständig abzufragen, > das möglicherweise nie benutzt wird. Der Drehgeber soll mir > gefälligst Bescheid sagen, wenn er was will ... Geht mir genauso. Auch der Timer soll sich melden, wenn er überläuft. Ihn dauernd sinnlos auf Überlauf abzufagen, ist doch richtig lästig.
m.n. schrieb: > Auch der Timer soll sich melden, http://www.mamiweb.de/nfs/premiummagazin/container/037/37418/schueler-melden-sich-l.jpg
Na, wo es hier gerade so nett zu geht, melde ich mich auch nochmal aus Interesse, selbst wenn ich weder ein Timer noch ein Drehgeber bin: Wo gibt es den ATtiny25 für 17Cent? m.n. schrieb: > Also ich zahle für einen ATtiny25 17 Cent. Was kostet Dein STM8 genau? 24 Cent bei 100 Stück incl. Versand, siehe Beitrag "µC mit 1K SRAM für 24ct"
Lothar M. schrieb: >> Die Kontakte des Encoders prellen. >> Externes entprellen mit 2 RC Gliedern hilft. > Das ist die lange Schreibweise von "Murks". Ach.. mal wieder eines der beliebten Themen, wo sich zwei aus schierem Grundsatz unversöhnlich gegenüberstehende Parteien bekriegen. Also: Drehgeber auf Basis von mechanischen Kontakten prellen immer, das ist Stand der Technik und es ist eben kein Murks. Drehgeber auf Basis von Optik prellen nicht, brauchen dafür aber Schmitt-Trigger-Eingänge wegen der recht "unsteilen" Flanken. Drehgeber auf magnetischer Basis (Austriamicrosystems) prellen überhaupt nicht und brauchen auch keine Schmitt-Trigger. Schick&Teuer Jede Sorte hat ihre Meriten - und die simplen mechanischen haben den geringsten Preis. Dafür prellen sie eben, bäh. Andererseits könnte man das Prellen schlichtweg ignorieren, sofern der durch den Flankenwechsel ausgelöste Interrupt (jaja, Lothar) nur schnell genug ist. Grund: der dahinter stehende Zählvorgang ist ja richtungsabhängig und so kann der "Zählerstand" eben auch für ne kurze Zeit prellen (also quasi +1, -1, +1, -1, +1) und wird sich nach der ganzen Prellerei auf dem neuen Stand befinden. Eben so, als hätte es überhaupt kein Prellen gegeben. Natürlich ist es lästig, wenn man auf jedes VOR und ZURÜCK und wieder VOR eine ganze Latte von µC internen Aktivitäten auslöst. Sinnvoller wäre es, mit jedem Flanken-Interrupt einen Timer zur Verzögerung zu (re)starten und die Weiterverarbeitung erst mit dessen Ablaufen zu starten - also wenn sich die Prellerei gelegt hat. Weitaus einfacher ist es jedoch, tatsächlich zu entprellen und dies in Hardware zu tun. Man braucht dafür aber nur einen Tiefpaß, nämlich den für die Interrupt-Erzeugung. Ach ja: Bei den hier eher wenig besprochenen Kinetis µC von Freescale gibt's die Entprellung in der Port-Logik. Find ich elegant. Hab sowas Ähnliches bislang nur noch bei Nuvoton gefunden. So. Hier mal ein Beispiel, wie das geht: /******* Interrupt vom Drehgeber *************/ __irq void PORTB_IRQHandler (void) { dword L; long i; L = GPIOB_PDIR; // Port lesen i = 1 & ((L>>2) ^ (L>>3)); // Richtung ? if (i) { ++DgPosition; Add_Event(idDrehR); } else { --DgPosition; Add_Event(idDrehL); } } Und noch ein Wort an Lothar, der ja Fan vom Polling ist: Entweder belästigt man den µC mit häufigem Polling oder man kriegt hie und da die Drehereignisse nicht mit - jajaja.. auch hier schlägt das Abtast-Theorem gnadenlos zu. Genau deshalb finde ich Polling grottenschlecht, denn immerhin ist der zeitliche "Dynamik"-Bereich bei Drehgebern wesentlich größer als bei Tasten aller Art. W.S.
W.S. schrieb: > Drehgeber auf Basis von Optik prellen nicht, brauchen dafür aber > Schmitt-Trigger-Eingänge wegen der recht "unsteilen" Flanken. > > Drehgeber auf magnetischer Basis (Austriamicrosystems) prellen überhaupt > nicht und brauchen auch keine Schmitt-Trigger. Schick&Teuer Drehgeber beider Sorten können durch mechanische Vibrationen an der Übergangsstelle deutlich schnellere Flankenwechsel liefern als durch Drehbewegung erklärbar, sich also wie bei prellenden Kontakten verhalten. Auch elektrische Einstreuungen können im Zustandsübergang zu einem hin und her des Signals führen, das sich nicht vom Prellen mechanischer Drehencoder unterscheidet und viel schneller ist als der Strichwechsel. Alle Drehencoder sind also auf der Auswerteseite gleich wie mechanisch prellende zu behandeln. W.S. schrieb: > Andererseits könnte man das Prellen schlichtweg ignorieren, sofern der > durch den Flankenwechsel ausgelöste Interrupt (jaja, Lothar) nur > schnell genug ist. Alle Interrupteingänge haben eine Maximalfrequenz des Signals bzw. minimale notwendig stabile Zeit. Dieses kann durch die oben genannten schnellen Flankenwechsel unterschritten werden (es ist nicht garantierbar, daß nicht). Flankeninterrupts sind also prinzipiell immer ein Risiko, sie können sogar den Prozessor überlasten, beispielsweise wenn die InterruptRoutine 12msec benötigt, und der Drehgeber im Schaltpunkt stehen bleibt wo die 100Hz der gleichgerichteten Netzfrequenz zu Flattereffekten führen: Der Prozessor bleibt immer in der Interrupt-Routine und führt das Hauptprogramm gar nicht mehr aus, ist also quasi abgestürzt. Dein Zusatz "sofern der durch den Flankenwechsel ausgelöste Interrupt (jaja, Lothar) nur schnell genug ist" ist also essentiell. Leider ist die benötigte Minimalzeit (Maximallaufzeit des Interrupts) nicht definierbar. Es reicht NICHT, die maximale Drehgeschwindigkeit des Encoders anzusetzen (siehe oben). W.S. schrieb: > Weitaus einfacher ist es jedoch, tatsächlich zu entprellen und dies in > Hardware zu tun. Man braucht dafür aber nur einen Tiefpaß, nämlich den > für die Interrupt-Erzeugung. Man kann mit Hardware (Tiefpass und Schmitt-Trigger) garantieren, daß Flankenwechsel nicht schneller als x bzw. Signalzeiten immer minimal y usec lang sind. W.S. schrieb: > Entweder belästigt man den µC mit häufigem Polling oder > man kriegt hie und da die Drehereignisse nicht mit - jajaja.. Unsinn. Polling erlaubt es, nur mit der realen Drehgebermaximalstrichgeschwindigkeit abzutasten, nicht den oben angesprochenen Prell- und Flattereffekten. Mit der realen maximalen Drehgeschwindigkeit muss der uC so oder so zurecht kommen, und zwar immer, wenn er es nicht kann, ist das Programm einfach unzureichend. W.S. schrieb: > Genau deshalb finde ich Polling grottenschlecht Genau deshalb ist polling die einzige zuverlässig funktionierende Lösung und Flankeninterrupts sind immer Scheisse. Klar daß die Deppen an all so was nicht denken. Dann gibt es halt Geräte, die manchmal funktionieren und manchmal nicht. So etwas kennen wir ja zur Genüge von kommerziellen Geräten.
MaWin schrieb: > Drehgeber beider Sorten können durch mechanische Vibrationen an der > Übergangsstelle deutlich schnellere Flankenwechsel liefern als durch > Drehbewegung erklärbar, sich also wie bei prellenden Kontakten > verhalten. Ich kann mir das bei den Dingern mit Rasten irgendwie nicht vorstellen. Die Raststellungen sind doch (hoffentlich) versetzt zu den Schaltstellen ...
Volker S. schrieb: > Die Raststellungen sind doch (hoffentlich) versetzt zu den Schaltstellen ... Wieso "hoffentlich"? Glaubst du, dass es irgendwelche Hinterhofklitschen gibt, die so etwas konstruieren? http://industrial.panasonic.com/lecs/www-data/pdf/ATT0000/ATT0000CE11.pdf
Clemens L. schrieb: > Glaubst du, dass es irgendwelche Hinterhofklitschen > gibt, die so etwas konstruieren? Wer weiß. Vielleicht die selben Hinterhofklitschen, welche die "kommerziellen Geräte" konstruiert haben auf die MaWin anspielt ;-)
W.S. schrieb: > Drehgeber auf Basis von Optik prellen nicht, brauchen dafür aber > Schmitt-Trigger-Eingänge wegen der recht "unsteilen" Flanken. Siehe Avago AEDR-8300. Flankensteilheit 100...500ns. Da brauchst keinen Schmitt-Trigger. Volker S. schrieb: > Ich kann mir das bei den Dingern mit Rasten irgendwie nicht vorstellen. > Die Raststellungen sind doch (hoffentlich) versetzt zu den Schaltstellen > ... Gibt es so oder so, speziell der Panasonic (z.B. STEC12) bietet in eienr Serie Beides an. rgds
W.S. schrieb: > Ach ja: Bei den hier eher wenig besprochenen Kinetis µC von Freescale > gibt's die Entprellung in der Port-Logik. Find ich elegant. Hast Du eine Größenordnung für die einstellbaren Zeiten? Auf die Schnelle finde ich das nicht im Datenblatt. Oder sind es die 'glitch filter' zu LPTMR. Bei den STM32 gibt es sehr weit einstellbare Filter an den Capture-Eingängen von ns bis fast in den ms-Bereich. Jetzt muß sich nur noch ein Spritti melden, dem nicht nur die Hände, sondern auch die Impulse zittern. Ich habe oft nachgefragt, aber zeigen konnte man mir diese Signale nie. Es sind offensichtlich Signale, die in Fanta enthalten sind und die die Zitter-Phantasie anregen.
6a66 schrieb: > 6a66 schrieb: >> Panasonic (z.B. STEC12 > Korrektur: ALPC STEC (ob 11, 12 oder andere). > rgds Also ich habe die zufällig beide, den ALPS STEC12 und den PANASONIC EVEQDBRL416B als alternative Bestückungsvariante auf unseren Mikrocontroller Boards für Studenten. Kann bei beiden kein Zittern feststellen. Aus den Abbildungen in den Datenblättern werde ich allerdings nicht ganz schlau. Die Darstellung des Rastpunktes ist irgendwie in keinem gelungen.
:
Bearbeitet durch User
Volker S. schrieb: > Also ich habe die zufällig beide, den ALPS STEC12 Da musst Du dann schauen, welche STEC12. Der D http://www.alps.com/prod/info/E/HTML/Encoder/Incremental/EC12E/EC12D1524403.html hat zum Beispiel andere Detent positions wie der E http://www.alps.com/prod/info/E/HTML/Encoder/Incremental/EC12E/EC12E2430401.html Das "Zittern" (aka Prellen) ist im verlinkten Datenblatt ganz unten angegeben (Sliding noise, chattering) rgds
In der Realität sieht das Signal doch ganz anders aus. Wenn man an so einem Encoder dreht, dann gibt es bei/zwischen jedem Rastpunkt bei den STEC zwei winkelversetzte kurze Impulse. Bei dem erwähnten Panasonic EVEQDBRL416B wechselt der Pegel. Diese Abbildungen mit den 50% sind doch irreführend. Warum wird/werden da nicht einfach ein/zwei Winkel angegeben ?
Volker S. schrieb: > Diese Abbildungen > mit den 50% sind doch irreführend. Das wäre ja noch schöner, wenn man so einfach herauslesen könnte, was man wissen muß. :-( SCNR Paul
Paul B. schrieb: > Das wäre ja noch schöner, wenn man so einfach herauslesen könnte, was > man wissen muß. Das ALLERBESTE ist die Abbildung, wo der Rastpunkt genau auf der Flanke des Signals B steht und darunter steht dann: Detent position canot be specified for B signal
Paul B. schrieb: >> Diese Abbildungen mit den 50% sind doch irreführend. > Das wäre ja noch schöner, wenn man so einfach herauslesen könnte, was > man wissen muß. Genau, schliesslich muss man doch die Laien irgendwie abwehren. Sonst kommen die womöglich noch auf die Idee, eine Steuerung mit Inkrementalgebern bauen zu wollen. :-)
Willkommen zum Drehgeber-Sommer-Theater! (Für alle die, die beim Drehgeber-Frühlings-Theater nicht dabei sein konnten...) 1.) Wer einen Drehgeber zu schnell dreht, der wird mit keiner Entprellung der Welt und keiner Routine einen Drehgeber einwandfrei dekodieren können. 2.) Wenn ein Kontakt eines Drehgeber prellt, fällt er zwischen zwei Zuständen hin und her. Also als wenn man an der Stelle vorwärts und rückwärts dreht. Eine schnelle Auswertung flimmert in dieser Zeit zwischen diesen beiden Zuständen um am Ende aber den richtigen Wert auszugeben. Es schaltet ja nur ein Kontakt. Sollte auch der andere innerhalb dieser Zeit schalten, sieht 1.) 3.) Du musst einfach nur regelmäßig die beiden Bits lesen und zu den beiden zuletzt gelesenen packen. Ich mache dies, indem ich die neuen Bits von unten in das Register mit den alten Bits hinein schiebe. Die oberen 4 Bits in dem Byte schneide ich per verUNDung ab. So habe ich 4 Bits. Oder eine Zahl von 0-15. Diese 16 Kombinationen sind die Aussage über vorwärts, rückwärts oder gar nicht gedreht. 4 der 16 Zahlen sind für vorwärts, und 4 weitere für rückwärts. Du musst also bei der einen Gruppe Deinen Zähler inkrementieren und bei einer Zahl aus der anderen Gruppe dekrementieren. Solltest Du an bestimmten Positionen nicht zählen wollen, so ignorierst Du diese Werte. Du musst dabei allerdings darauf achten, dass beide Werte an dieser Position ignoriert werden. Sonst zählt er bei prellen an dieser Position z.B. rauf, kann aber nicht wieder runter zählen, weil dieser Übergang ignoriert wird. Am einfachsten hat es sich erwiesen, eine Tabelle mit 16 Werten zu machen und den Wert aus dem Schieberegister als Index darauf zu verwenden. Wo aufwärts gezählt werden soll, steht eine 1, wo abwärts gezählt werden soll, steht -1 und an allen anderen Positionen eine 0. Der Wert wird geholt und zu Deinem Zähler hinzuaddiert. Fertig. Das Ganze macht man im Timer IRQ. Sind vielleicht 10 Befehle in Assembler, dann hat man seinen fertigen Wert. Als Lektüre empfehle ich auch diesen Thread: Beitrag "Versetzte Rechtecksignale auswerten, kein drehgeber" (Natürlich geht es um genau das ...) Gruß Jobst
:
Bearbeitet durch User
Klaus W. schrieb: > Ich werde mir jedenfalls andere Drehgeber zulegen, die von Alps sind > Murks, wie auch hier auf der Seite zu lesen ist: > https://www.mikrocontroller.net/articles/Drehgeber Dann verstehe ich nicht, wieso die bei mir astrein laufen. Aber du wirst wohl Recht haben ...
Jobst M. schrieb: > 3.) Du musst einfach nur ... OMG ! Bin ich froh, dass das bei mir immer austeichend gut mit einem simplen flankengetriggerten IR funktioniert, welcher lediglich den Zustand des anderen Signals checken muss ...
Vloki schrieb: > Bin ich froh, dass das bei mir immer austeichend gut mit einem simplen > flankengetriggerten IR funktioniert, welcher lediglich den Zustand des > anderen Signals checken muss ... Warts ab. Auch Drehgeber altern.
Vloki schrieb: > Bin ich froh, dass das bei mir immer austeichend gut mit einem simplen > flankengetriggerten IR funktioniert, welcher lediglich den Zustand des > anderen Signals checken muss ... Ich wette, dass es umständlicher ist! Gruß Jobst
Jobst M. schrieb: > Willkommen zum Drehgeber-Sommer-Theater! > (Für alle die, die beim Drehgeber-Frühlings-Theater nicht dabei sein > konnten...) > > 1.) Wer einen Drehgeber zu schnell dreht, der wird mit keiner > Entprellung der Welt und keiner Routine einen Drehgeber einwandfrei > dekodieren können. > > 2.) Wenn ein Kontakt eines Drehgeber prellt, fällt er zwischen zwei > Zuständen hin und her. Also als wenn man an der Stelle vorwärts und > rückwärts dreht. Eine schnelle Auswertung flimmert in dieser Zeit > zwischen diesen beiden Zuständen um am Ende aber den richtigen Wert > auszugeben. Es schaltet ja nur ein Kontakt. Sollte auch der andere > innerhalb dieser Zeit schalten, sieht 1.) > ... Und das funktioniert auch an einer Motor/Servowelle, wo es gar keine Rastungen gibt, und wo Murphy dafür sorgt, daß der immer an einem Umschaltpunkt zum Stehen kommt. MfG Klaus
Klaus schrieb: > Und das funktioniert auch an einer Motor/Servowelle, wo es gar keine > Rastungen gibt, und wo Murphy dafür sorgt, daß der immer an einem > Umschaltpunkt zum Stehen kommt. Danach ist aber doch gar nicht gefragt.
Jobst M. schrieb: > Willkommen zum Drehgeber-Sommer-Theater! Du bist spät! Hast Du denn schon ein Ticket erworben? Jobst M. schrieb: > 3.) Du musst einfach nur regelmäßig die beiden Bits lesen Aha, ein Poller ;-) Ich habe hier einen Drehgeber, der liefert 100000 Flankenwechsel/s. Den muß ich ja dann 100000*/s abfragen, die Schiebeoperation ausführen und den indizierten Wert aus einer Tabelle lesen - aber auch, wenn sich der Geber garnicht dreht. Na, wer macht denn sowas?
Ohne mich groß einmischen zu wollen;: Und inwieweit ist die ganze Zeit in einer Endlosschleife auf den nächsten Interrupt des Drehgebers zu warten, besser? Um den in irgendeinen Energiesparmodus zu versetzen und durch den Int aufwecken zu lassen, ist die Zeit zwischen 2 Impulsen ja bei der Impulszahl sicher zu kurz.
:
Bearbeitet durch User
Harald W. schrieb: > Warts ab. Auch Drehgeber altern. Ich fürchte so lange wird der gar nicht benutzt werden. Aber in extremen Anwendungsfällen muss man das in Erwägung ziehen. Jobst M. schrieb: > Vloki schrieb: >> Bin ich froh, dass das bei mir immer austeichend gut mit einem simplen >> flankengetriggerten IR funktioniert, welcher lediglich den Zustand des >> anderen Signals checken muss ... > > Ich wette, dass es umständlicher ist!
1 | void interrupt high_isr(void) |
2 | {
|
3 | if (ENC_IR){ |
4 | #ifdef ENCODER_PANASONIC
|
5 | mENC_INT_TOG_EDGE(); |
6 | #endif
|
7 | if(ENC_DIR == ENC_DIR_UP) |
8 | flags.encUp = 1; |
9 | else
|
10 | flags.encDown = 1; |
11 | mENC_IR_CLR(); |
12 | return; |
13 | }
|
14 | ...
|
Martin L. schrieb: > Um den in irgendeinen Energiesparmodus zu versetzen und > durch den Int aufwecken zu lassen, ist die Zeit zwischen 2 Impulsen ja > bei der Impulszahl sicher zu kurz. Also es geht hier doch um ein mechanisches Bedienelement, welches in aller Regel verhältnismäßig vernachlässigbar wenige Aktionen auslöst. Wenn es für das Programm nichts anderes zu tun gäbe, dann schätze ich die Zeit in einem evtl. Energiesparmodus doch best. >99,9%
Guten Morgen, ich habe Peter Danneggers C Programm für die Drehencoder Dekodierung in einer Hochsprache als assembleroptierte Version in eine Bibliothek gepackt. In der worst-case Analyse benötigt die Routine 119 CPU-Takte + 3 CPU-Takte (ISR-Call) - also 123 CPU-Takte. Wird der AVR µC mit z.B. 16MHz betrieben und mit einer Timer-Zyklusfrequenz von 2kHz betrieben, erfolgt ein Aufruf der Timer-ISR alle 16.000kHz /2kHz = 8.000 CPU-Takte. In diesem Timer-Zyklus beträgt dann die 'Auslastung' nur 1,54%. Auf alle 16Mio CPU-Takte bezogen dann auch nur: 2000 *7,69 *10⁻⁶ = 0,0154
:
Bearbeitet durch User
Uwe S. schrieb: > In diesem Timer-Zyklus beträgt dann die 'Auslastung' nur 1,54%. > > Auf alle 16Mio CPU-Takte bezogen dann auch nur: 2000 *7,69 *10⁻⁶ = > 0,0154 Wo ist jetzt genau der Unterschied zwischen 1,54% und 0,0154 ?
Volker S. schrieb: > Martin L. schrieb: >> Um den in irgendeinen Energiesparmodus zu versetzen und >> durch den Int aufwecken zu lassen, ist die Zeit zwischen 2 Impulsen ja >> bei der Impulszahl sicher zu kurz. > > Also es geht hier doch um ein mechanisches Bedienelement, welches in > aller Regel verhältnismäßig vernachlässigbar wenige Aktionen auslöst. Grundsätzlich ja, aber ich bezog mich -hätte wohl zitieren sollen- direkt auf den davor befindlichen Beitrag, in dem eben als Argument gegen Polling die hohe Zahl der Impulse kam. In den Energiesparmodus zu gehen wird ja nun bei der dort angeführten 100Khz Impulsrate auch nicht wirklich klappen, so daß die Abfrage per Interrupt gegenüber Polling da keinen echten Vorteil bringt.
m.n. schrieb: > Ich habe hier einen Drehgeber, [...] den > muß ich ja dann 100000*/s abfragen [...] - aber auch, wenn sich der > Geber garnicht dreht. > > Na, wer macht denn sowas? Für gesparte Takte kriegt man kein Geld zurück. Und für eine Auslastung des µC, die von der Bediengeschwindigkeit des Nutzers abhängt, bekommt man keinerlei Test-Mehraufwand genehmigt.
hi, und das sind grad mal 100kHz, ganz simpel, wenn man nicht alles in der IRQ macht sondern wirklich nur in Register lesen aus LUT lesen und die Position berechnen. Wenn das Signal ordentlich Aufbereitet ist und sauber zum µC kommt kann man auch Flankengesteuert auswerten, aber es gibt dir max beim Stromverbrauch durch Sleep Mode einen Vorteil, der Prozessor muss so oder so genug schnell sein für Drehgeber mit 100kHz Eingang. Mfg ich
Uwe S. schrieb: > Wird der AVR µC mit z.B. 16MHz betrieben und mit einer > Timer-Zyklusfrequenz von 2kHz betrieben, erfolgt ein Aufruf der > Timer-ISR alle 16.000kHz /2kHz = 8.000 CPU-Takte. > > In diesem Timer-Zyklus beträgt dann die 'Auslastung' nur 1,54%. Na gut, und bei 100 kHz Timerfrequenz sind es dann 77 %, wenn mein Taschenrechner mich nicht geprellt hat. Das ist doch ein guter Wert, wenn man den µC beschäftigen will ;-) Martin L. schrieb: > In den Energiesparmodus Wer redet denn von Stromsparen? Habe ich etwas überlesen oder suchst Du nach einem zufälligen Scheinargument? In der Regel soll der µC noch andere Sachen erledigen, als nur sinnlos vor sich hinzuzählen. Wenn man ihn mit Timer-ISRs zukleistert, bleibt da nicht mehr viel übrig. Klaus schrieb: > Und das funktioniert auch an einer Motor/Servowelle, wo es gar keine > Rastungen gibt, und wo Murphy dafür sorgt, daß der immer an einem > Umschaltpunkt zum Stehen kommt. Dazu braucht man Murphy garnicht. Die Erfahrung hat ja jeder einmal gemacht. Eine Motorwelle springt mal eben fünf Schritte vorwärts und dann wieder drei zurück; und das Alles in 10 µs. Das ist dann eine Art Kammerflimmern, was man nur mit Polling auswerten kann. Sommerloch-Theater: Tod einer Motorwelle ;-)
Walter T. schrieb: > Für gesparte Takte kriegt man kein Geld zurück. Und für eine Auslastung > des µC, die von der Bediengeschwindigkeit des Nutzers abhängt, bekommt > man keinerlei Test-Mehraufwand genehmigt. Ach jetzt wird es mir langsam klar, warum viel Code zur Auswertung sich lohnt ;-)
m.n. schrieb: > Martin L. schrieb: >> In den Energiesparmodus > > Wer redet denn von Stromsparen? Habe ich etwas überlesen oder suchst Du > nach einem zufälligen Scheinargument? Keineswegs. Ich habe da nur grade ein kleines Verständnisproblem. > In der Regel soll der µC noch andere Sachen erledigen, als nur sinnlos > vor sich hinzuzählen. Wenn man ihn mit Timer-ISRs zukleistert, bleibt da > nicht mehr viel übrig. Welche Sachen z.B. könntest Du denn den uC zuverlässig und geplant in der Zeit erledigen lassen, wenn jederzeit ein Interrupt auftreten und die 100Khz Auslastung auftreten könnte? Mir fehlt da grade das Vorstellungsvermögen. Die Aufgaben müssten ja also eh in jedem Fall so geschnitten sein, daß sie auch erledigt werden, wenn die maximale Frequenz auftritt. Ob das per Polling geschieht oder per Eingangs-INT ist ja egal. Welche echten Aufgaben, die erledigt werden müssen, kannst Du denn so schneiden, das sie von der größeren Zeit zwischen 2 Interrupts beim eingangsgesteuerten Interrupt profitieren, aber zuverlässig noch mit der geringstmöglichen Zeit zurecht kommen? Das einzige mögliche Plus, was mir also bei der Nutzung eines Eingangs-Interrupts eingefallen ist, war das sich bei längerer Nichtnutzung der uC schlafen legen kann. Aber da hat man dann eben u.U. bei entsprechend geringen Zeiten zwischen 2 Pulsen das Problem, dass die Aufwachzeit zu lang wird.
Martin L. schrieb: > Welche Sachen z.B. könntest Du denn den uC zuverlässig und geplant in > der Zeit erledigen lassen, wenn jederzeit ein Interrupt auftreten und > die 100Khz Auslastung auftreten könnte? Mir fehlt da grade das > Vorstellungsvermögen. Ich stell mir gerade vor wie ein Benutzer an einen 20/20 Drehgeber 5000 U/s macht ;-) Im Ernst, auch wenn das an der eigentlichen Fragestellung ETWAS vorbeigeht. Lieber Interrupts mit 100kHz die auftreten könnten und nur geringen Aufwand zur Abarbeitung benötigen, als Interrupts die mindestens mit 200kHz auftreten müssen und viel Abarbeitungsaufwand benötigen.
Volker S. schrieb: > > Ich stell mir gerade vor wie ein Benutzer an einen 20/20 Drehgeber 5000 > U/s macht ;-) Na, ich hab das nicht aufgebracht...
Hi, dann hast du aber was falsch gemacht. Es wird ja am ANFANG die n_max bestimmt/geschätzt und darauf entwickelst du dein System. Weil was macht dein System, wenn jetzt mit doppelter Drehzahl gefahren wird, Richtig: Auch nichts sinniges. Also bitte immer die Spec betrachten. MfG ich
Volker S. schrieb: > Im Ernst, auch wenn das an der eigentlichen Fragestellung ETWAS > vorbeigeht. Es geht darum, daß eine Flankenauswertung per Interrupt alle Möglichkeiten bietet, ob von Stillstand bis zu hoher Drehzahl: eine Lösung für alle Fälle. Es gibt nicht nur diese billigen, mechanischen Geber, sondern auch die mit höherer Auflösung, die auch bei manueller Bedienung und erst recht bei Positionierungen hohe Frequenzen liefern können. Alles fällt unter den Oberbegriff: Drehgeber. Wer sich nun aus Unkenntnis oder Ignoranz einer Erfassung per Interrupt konsequent verschließt, kommt halt aus seinem Sandkasten nicht heraus. Daher auch dieses Kindergeschreie. Immer wieder gehört und das allerletzte Argument: "das brauche ich nicht." Na denn ...
m.n. schrieb: > Es geht darum, daß eine Flankenauswertung per Interrupt alle > Möglichkeiten bietet, ob von Stillstand bis zu hoher Drehzahl: eine > Lösung für alle Fälle. Leider nein. Beim Polling kann man genau vorherschätzen, bis zu welcher Drehzahl/Taktzahl die Erfassung zuverlässig läuft. Bei größerer Drehzahl werden Takte verschluckt. Das ist ein definiertes Verhalten und beeinflusst i.A. die sonstige Stabilität meines Programms nicht. Noch dazu vereinfacht es die Planung. Ich kann jederzeit genau sagen, wann und wie lange gepollt wird. Es ist ja noch nicht einmal eine Verzweigung in der Polling-Routine. Bei einem Flankeninterrupt kann ich: a) im Allgemeinen nicht vorher sagen, bis zu welcher Drehzahl noch alles gut geht. Vorher müßte ich erst einmal profilen, wieviele Takte meine ISR in allen Fällen benötigt und wieviele Takte meine restlichen Bestandteile (Hauptschleife und andere ISRs) in allen Fällen benötigen. b) beim Überschreiten der zulässigen Drehzahl kann sich mein µC bis zum kompletten Aufhängen nur noch mit dem Drehgeber beschäftigen. Ob und wann Hauptschleife und andere ISRs noch dazwischenkommen kann niemand vorhersagen. Das ist kein definiertes Verhalten bei "Überdrehzahl". c) kommt Prellen hinzu, ist der Punkt der "Überdrehzahl" noch viel schneller erreicht.
Ich befürchte, Ihr redet aneinander vorbei. Ist jemand der Meinung, dass Flankeninterrupt ohne Tiefpass und Schmitt-Trigger auch bei Vibrationen oder ungünstiger elektromagnetischer Einstrahlung sicher funktionieren? Sicherlich nicht. Es gibt also so oder so immer eine Maximaldrehzahl, also sowohl bei Timerinterrupt als auch beim Flankeninterrupt. Diese Maximaldrehzahl ist durch den Tiefpass bzw. durch die Timerinterrupt-Frequenz bestimmt.
:
Bearbeitet durch User
Torsten C. schrieb: > Ich befürchte, Ihr redet aneinander vorbei. Ich denke mal die IR Fraktion akzeptiert durchaus, dass es Anwendungen gibt in denen das nicht die Lösung sein kann. Für die Poller ist einfach alles andere nur Scheiße ;-)
Volker S. schrieb: > Ich denke mal die IR Fraktion akzeptiert durchaus, > dass es Anwendungen gibt in denen das nicht die Lösung sein kann. > Für die Poller ist einfach alles andere nur Scheiße ;-) Du bringst es auf den Punkt!
Volker S. schrieb: > Für die Poller ist einfach alles andere nur Scheiße ;-) Wenn man eine Hardware-Auswertung über eine getaktete Logik auch dem Pollen zurechnet (was es ja ist): Stimmt. Einzige Ausnahme: Aufwachvorgang für ein Gerät im Standby. Und da auch nur für den ersten Takt.
Ich weiss nicht, ob das eine Übertreibung sein sollte, als MaWin schrieb: > Timerinterrupt ist kein Problem. > Flankeninterrupt ist immer falsch. Ich würde nicht sagen "falsch". Aber der Flankeninterrupt bringt kaum Vorteile und kann im worst-case Nachteile bedeuten: Einerseits kann man hoffen, Rechenzeit zu sparen, andererseits kann man sie nicht einplanen, weil man sich nicht darauf verlassen kann. Dabei ist es egal, ob die CPU in der (wenn man Glück hat) gewonnenen Zeit schlafen oder Hintergrund-Tasks abarbeiten soll. In beiden Fällen (Schlafen oder Hintergrund-Task) bleibe ich bei meinem STM8S103F3P6 für 24 Cent, denn der decodiert sowohl bei schlafender als auch bei 100% ausgelasteter CPU. In allen anderen Fällen (weder Schlafen oder Hintergrund-Task) ist es m.E. vollkommen egal, wie man es macht und spart beim Timerinterrupt den Tiefpass und den Schmitt-Trigger. Oder?
m.n. schrieb: > Hast Du eine Größenordnung für die einstellbaren Zeiten? Auf die > Schnelle finde ich das nicht im Datenblatt. Hmm.. ja. Portweise, also mit PORTx... folgende Register: - in PCR Filterbit setzen (1<<4), - DFCR und DFWR zur Aufgabe passend setzen. Es geht bei 1 kHz Filtertakt in Stufen von 1 ms, ich glaub bis 31 oder 63 ms - hab's nicht auswendig gelernt. Bei höherem Filtertakt entsprechend kleinere Zeiten. ------- Torsten C. schrieb: > Ich weiss nicht, ob das eine Übertreibung sein sollte, als > MaWin schrieb: >> Timerinterrupt ist kein Problem. >> Flankeninterrupt ist immer falsch. > > Ich würde nicht sagen "falsch". Ich schon. Ach, MaWin schreibt öfters sowas - und es ist tatsächlich falsch. Und wenn man ihm sagt, daß er falsch liegt, wird er ausfallend. Als anständiger Ingenieur konditioniert man Signale, die einer Konditionierung bedürfen, und führt sie erst dann ihrer Auswertung zu. Bei Pfuschern hingegen ist es völlig üblich, daß sie die korrekte Vorbehandlung ignorieren und das daraus erwachsende Fehlverhalten anschließend korrigieren wollen. W.S.
m.n. schrieb: > Ich habe hier einen Drehgeber, der liefert 100000 Flankenwechsel/s. Den > muß ich ja dann 100000*/s abfragen, die Schiebeoperation ausführen und > den indizierten Wert aus einer Tabelle lesen - aber auch, wenn sich der > Geber garnicht dreht. Da vergleichst du jetzt aber Birnen mit Tomaten. Es ging ursprünglich (und stückzahlenmäßig vorrangig) um diese kleinen Drehencoder im Preisbereich um 2€, die anstatt eines Potis zum Einstellen von Werten verwendet werden. Nicht aber um einen industriellen 4000-Schritt-Inkrementalgeber, der locker mal das 100fache kosten darf. So einen Geber schließt man sinnvollerweise an einen Hardwarezähler an, der komplett ohne jegliche CPU Belastung die Zählung übernimmt. Denn ich kann mir bei Interruptauswertung so eines (in Zahlen 1) Inkrementalgebers mit einem AVR sehr gut vorstellen, dass da einige ihre interruptgesteuerte Software dann so hinbekommen, dass entweder der Geber mit gewünschter Maximalgeschwindigkeit drehen darf oder die Software ihre sonstigen Aufgaben erledigen kann. Aber nicht beides zusammen... Torsten C. schrieb: > Es gibt also so oder so immer eine Maximaldrehzahl, also sowohl bei > Timerinterrupt als auch beim Flankeninterrupt. Und jetzt kommt der Knackpunkt: diese Drehzahl ist beim Timerinterrupt mit einer einfachen "1/" Division ermittelbar. Bei der Interruptauswertung kommt es u.A. drauf an, wieviele andere und höherpriore Interrupts im System und wie oft die aktiv sind. Und wenn das einer nicht weiß und 3 Jahre später noch einen "kleinen" Interrupt dazupackt, der nur 1x pro Sekunde kommt, dann kann es passieren, dass durch diese ganz woanders platzierte Baustelle der Encoder auf einmal seltsame Sprünge macht. Und das nur ab und zu, irgendwie... W.S. schrieb: > Bei Pfuschern hingegen ist es völlig üblich, daß sie die korrekte > Vorbehandlung ignorieren und das daraus erwachsende Fehlverhalten > anschließend korrigieren wollen. Ich verlagere Filterung und Entprellung gerne in die Software, weil die so leicht anpassbar ist. Aber ich halte das nicht für Pfusch, sondern habe die Theorie dahinter kapiert... > Torsten C. schrieb: >> MaWin schrieb: >>> Flankeninterrupt ist immer falsch. >> Ich würde nicht sagen "falsch". > Ich schon. Du sagst also mit Nachdruck, es wäre "immer falsch", einen Flankeninterrupt zu verwenden? Wie jetzt diese radikale Kehrtwende? > Und wenn man ihm sagt, daß er falsch liegt, wird er ausfallend. Ich fände deinen Ton im vorigen Post bestenfalls unter Freunden und nach 5-6 Hefeweizen akteptabel. Denn ich denke, du solltest solche Verallgemeinerungen wie "Pfuscher" nicht allzu unbedarft aussprechen. Wenn ich ein Verfahren als "Pfusch" bezeichne, dann ist es was Anderes, wie wenn ich eine Menschengruppe generell als "Pfuscher" bezeichne. Aber jetzt könnt ihr weitermachen. Es wurde schon alles gesagt. Des Öfteren...
Torsten C. schrieb: > und spart beim Timerinterrupt den Tiefpass und den Schmitt-Trigger. So ist es. Wie geschrieben ist das Problem am Flankeninterrupt die ggf. zu kurze Zeit, und wie von mir geschrieben kann man die mit externem Hardwarezusatzaufwand, aka RC und Schmitt Trigger, definiert verlängern. Bloss: Warum sollte man Hardware hinzufügen, bloss weil man schlechte Software geschrieben hat ? Da schreibt man die Software doch lieber gleich richtig.
Nach der endlosen Diskussion sollte doch der Auftrag erkannt worden sei: Baut ein Arduino Shield, dass Drehgeber auswerten kann und schreibt die Lib dazu!!! Dann könnt ihr das ganze ein halbs Jahr lang für teuer Geld auf ebay verscheuern (bis es dich Cinesen kopiert haben) und die dähmliche Fragerei im Forum nimmt deutlich ab.
Karl schrieb: > Dann könnt ihr das ganze ein halbs Jahr lang für teuer Geld > auf ebay verscheuern (bis es dich Cinesen kopiert haben) und die > dähmliche Fragerei im Forum nimmt deutlich ab. Gar keine dähmliche Idee... ;-) MfG Paul
Volker S. schrieb: > void interrupt high_isr(void) > { > if (ENC_IR){ > #ifdef ENCODER_PANASONIC > mENC_INT_TOG_EDGE(); > #endif > if(ENC_DIR == ENC_DIR_UP) > flags.encUp = 1; > else > flags.encDown = 1; > mENC_IR_CLR(); > return; > } Wo werden die Flags auf eine Variable addiert? Und wo wieder zurück gesetzt? Im von mir angegebenen Link findest Du Code von mir. Uwe S. schrieb: > In der worst-case Analyse benötigt die Routine 119 CPU-Takte + 3 > CPU-Takte (ISR-Call) - also 123 CPU-Takte. Hrcchhhg!? =-O Ich benötige 8 Takte! m.n. schrieb: > Ich habe hier einen Drehgeber, der liefert 100000 Flankenwechsel/s. Den > muß ich ja dann 100000*/s abfragen, die Schiebeoperation ausführen und > den indizierten Wert aus einer Tabelle lesen - aber auch, wenn sich der > Geber garnicht dreht. > > Na, wer macht denn sowas? Ich gehe davon aus, dass es sich dabei nicht um einen Drehgeber wie hier behandelt handelt. Sondern etwas mit richtig Auflösung. Also auch etwas, was ohne eine Rastung arbeitet und daher alle vier Flankenwechsel interessant sind. Man also bei Interuptabfrage auf beide Flankenwechsel an zwei Ports reagieren muss. Alleine das stelle ich mir schon problematisch vor, wenn auf einmal mehrere IRQs deshalb ausgelöst werden. Oder löst weiterhin nur eine Flanke an einem Port den IRQ aus? Du nutzt also nur 1/4 der Auflösung des Gebers und zahlst dafür teuer? Na, wer macht denn sowas? ;-) Gruß Jobst
Volker S. schrieb: > Ich stell mir gerade vor wie ein Benutzer an einen 20/20 Drehgeber 5000 > U/s macht ;-) Mit einer am Drehgeber angeschlossenen Platinenbohrmaschine sicherlich möglich. :-)
Und der Hersteller schreibt: 15.000 Cycles Livetime. Also nach 3 Minuten. Wenn man die auf hoffentlich ein paar Jahre streckt, dann reicht Polling, oder?
Bastler schrieb: > Wenn man die auf hoffentlich ein paar Jahre streckt, dann reicht > Polling, oder? Polling reicht auf einem 16MHz AVR für 920000 Striche/Sekunde, für 2 Drehgeber, also daran liegt es eher nicht.
Jobst M. schrieb: > Alleine das stelle ich mir schon > problematisch vor, wenn auf einmal mehrere IRQs deshalb ausgelöst > werden. Oder löst weiterhin nur eine Flanke an einem Port den IRQ aus? Nicht, um hier weiter zu diskutieren, sondern weil Du fragst: bei einem AVR kann man geschickterweise beide Phasen auf einen Port legen, wobei jede Änderung den PCINT zu dem Port auslöst. Aktuellen Code dazu, der das deutlich macht, finde ich gerade nicht. Im Grunde ist es die gleiche ISR Routine (ähnlich kurz wie von W.S. oben gezeigt), wie sie auch mit einem Timerinterrupt angesprungen wird - aber eben nur bei Bedarf und nicht zyklisch. Von einem ATmega8 kommend, der noch keine PCINTs bot, nehme ich vielfach INT0 und INT1, die auf beide Flanken triggern können und bei einem AVR die höchste Priorität nebst eigenem Vektor haben. Ein Beispiel hatte ich vor einiger Zeit in die Codesammlung gestellt. Beitrag "4-fach Flankenauswertung per Interrupt mit ATmega48/88" Die Flanken werden in Assembler ausgewertet, der reservierte Variablen für die Interrupts bietet: 'qcnt_6sub.s'. Liest man den Text, findet man die Optionen für flankengetriggerte oder auch Timer ISR, wobei erstere etwas schneller ist: 500 kHz zu 400 kHz. Weiter unten sind ergänzende Schaltungen gezeigt, wie man unsaubere mechanische Signale flankengetriggert auswerten kann, selbst wenn sie Spikes im einstelligen µs-Bereich aufweisen. Um linieare Weggeber auszuwerten, verwende ich diese Routinen immer flankengetriggert. Diese liefern teilweise sehr hohe Frequenzen, aber immer nur kurzzeitig. Es geht dabei kein Impuls verloren und dennoch kann der AVR volle Leistung liefern. Noch etwas zu Drehgebern: es gibt ja nicht nur diese billigen mechanischen Teile oder welche mit 4000 Schritten/Umdrehung (wobei die hohe Auflösung insbesondere auch für langsam drehende Achsen sinnvoll ist und nicht zwingend ultraschnell ausgewertet werden muß), sondern auch 'schlichte' optische Geber (Bourns z.B.) mit bis zu 256 Impulsen/U die bis 3000 Upm arbeiten. Rechnet man dazu die max. Impulsfrequenz aus, kommt man auf rund 50 kHz. Nicht konstant aber eben auch möglich und auswertbar! Als Beispiel habe ich eine Routine, die einen Schrittmotor als Drehgeber auswertet, sich aber auch für einen optischen Drehgeber mit höherer Auflösung eignet: Beitrag "Schrittmotor als Drehgeber mit Dynamik, AVR" Auch hier kann man erkennen, daß eine Auswertung per PCINT eine einfache Sache ist und den µC nicht kontinuierlich auslasten muß.
@MaWin: ich wollte nur den Irrsinn aufdecken, der da heißt "und wenn das Ding mit 10000 U/sec rotiert, dann ...". So schnell blättert niemand durch LCD-Menüs. D.h. wir sind auf der selben Seite ;-)
Karl schrieb: > Baut ein Arduino Shield, dass Drehgeber auswerten kann und schreibt die > Lib dazu!!! Paul B. schrieb: > Gar keine dähmliche Idee... Das Breadboard-kompatible PCB (Bild) kostet ca. 77ct bei OSH-Park. Es sind noch zwei Aux-Pins und über 600 Bytes EEPROM frei. Dazu kommen noch: * µC: 24ct * zwei 0805-Kondensatoren * Alps-Dreh-Drückgeber * Pin-Header (8 Pins) Features: ¯¯¯¯¯¯¯¯¯ * Operating voltage: 2.95 to 5.5 V * Die beiden Aux Pins sind für PWM, WS2812, ADU oder DS18B20/DHT22/... (1wire) usw. nutzbar. * Konfigurierbar (z.B. TWI-Adresse, Aux-Pin-Funktion) über USB-VCOM und EEPROM, also ohne flashen. * Ansteuerbar über UART, I²C (TWI) oder SPI (dasy chain als slave), auch der freie EEPROM-Bereich. Harald W. schrieb: > … am Drehgeber angeschlossenen Platinenbohrmaschine … Sollte wohl gehen. Ich nutze nur die µC-internen Pullups. Interesse?
:
Bearbeitet durch User
Bastler schrieb: > Und der Hersteller schreibt: 15.000 Cycles Livetime. > Also nach 3 Minuten. ... 3 Sekunden! m.n. schrieb: > bei einem AVR kann man geschickterweise beide Phasen auf einen Port > legen, wobei jede Änderung den PCINT zu dem Port auslöst. Ach? Da bin ich nun aber neugierig, wie sowas gelöst werden soll ... Was liegt denn an dem Pin an, wenn eine Phase gerade H und die andere L ist? > Aktuellen Code dazu, der das deutlich macht, finde ich gerade nicht. Was mich allerdings wiederum nicht verblüfft. m.n. schrieb: > Liest man den Text, findet man die Optionen für flankengetriggerte oder > auch Timer ISR, wobei erstere etwas schneller ist: 500 kHz zu 400 kHz. Ich kann mit dem AVR per polling Signale bis 2MHz auswerten (gut, dann macht der nicht viel anderes mehr ...). Habe ich allerdings bisher nie benötigt. Was ich allerdings bisher benötigt habe, ist Drehgeber im Multiplex abzufragen. Da fällt Entprellung und damit PCINT raus ... Für mich bedeutet die Abfrage per PCINT mehr Hardware und unberechenbare Programmverarbeitung. Nö, da polle ich lieber. Wer mit IRQ glücklich wird, soll das tun. Für mich ist ein Drehgeber kein Ereignis, worauf immer alles stehen und liegen gelassen wird um darauf zu reagieren. Da gibt es andere Ereignisse. Und wer meint, an einem Steuergerät mit mehr als 100 Drehgebern es mit der Drehzahl übertreiben zu müssen, ja, der wird eben einfach mit den Fehlern leben müssen. > Weiter unten sind ergänzende Schaltungen gezeigt, wie man unsaubere > mechanische Signale flankengetriggert auswerten kann, selbst wenn sie > Spikes im einstelligen µs-Bereich aufweisen. Also Spikes, die sogar länger andauern, als ein Phasenabschnitt!? Großartig ...! Gruß Jobst
Ok, 3Sekunden. Ich hatte U/min gelesen, vielleicht weil nicht neben einer 300.000 U/min Bohrmaschine stehen wollte. Man liest eben, was man lesen will. Der Zahnarzt bekommt so was nur per Luftlager und als Turbine zum Fliegen. Von 5kHz drehenden E-Motor-Ankerteile perforiert zu werden ist ziemlich ungesund.
Jobst M. schrieb: > Wer mit IRQ glücklich wird … Ach ja, danke, vergessen: Einer der beiden Aux-Pins kann natürlich auch als Low-Active IRQ konfiguriert werden, wenn der Drehgeber am Arduino-Shield gedreht oder gedrückt wurde oder wenn anderweitig neue Signale anliegen. Volker S. schrieb: > Danach ist aber doch gar nicht gefragt. Über den Punkt, was gefragt war, sind wir alle doch eh schon weit hinaus! Falls ich die Idee von Karl hier jedoch zu sehr in den Vordergrund stelle, bremst mich bitte aus. m.n. schrieb: > ich zahle für einen ATtiny25 17 Cent wo?
:
Bearbeitet durch User
Jobst M. schrieb: > Volker S. schrieb: >> void interrupt high_isr(void) >> { >> if (ENC_IR){ >> #ifdef ENCODER_PANASONIC >> mENC_INT_TOG_EDGE(); >> #endif >> if(ENC_DIR == ENC_DIR_UP) >> flags.encUp = 1; >> else >> flags.encDown = 1; >> mENC_IR_CLR(); >> return; >> } > > Wo werden die Flags auf eine Variable addiert? Und wo wieder zurück > gesetzt? Ich versteh die Frage nicht ganz. Stell dir einfach vor, das es davon abhängig ist, ob und in welchem Menü sich das Programm gerade befindet. Heller-dunkler, vor-zurück, langsamer-schneller, nächstes-vorheriges Menü ... Ist doch nicht Teil des Problems der Drehgeber-Auswertung.
:
Bearbeitet durch User
Jobst M. schrieb: > m.n. schrieb: >> bei einem AVR kann man geschickterweise beide Phasen auf einen Port >> legen, wobei jede Änderung den PCINT zu dem Port auslöst. > > Ach? Da bin ich nun aber neugierig, wie sowas gelöst werden soll ... > Was liegt denn an dem Pin an, wenn eine Phase gerade H und die andere L > ist? > >> Aktuellen Code dazu, der das deutlich macht, finde ich gerade nicht. > > Was mich allerdings wiederum nicht verblüfft. Und, was soll ich Dir jetzt attestieren? Dummheit, Faulheit, Ignoranz oder etwa schon beginnender MaWinismus? Die Antworten auf Deine Fragen(?) hättest Du im nachfolgenden Text finden können. Ich konnte ja nicht ahnen, daß Du damit überfordert bist. Torsten C. schrieb: > m.n. schrieb: >> ich zahle für einen ATtiny25 17 Cent > > wo? Die Quelle für 1000er Stückzahl ist derzeit versiegt; es war zu Zeiten des Eurohöhenfluges. Derzeit ist Schukat ein sicherer Lieferant zu akzeptablem Preis, den ich mir leisten kann ;-) Auf eine China-Quelle würde ich mich aber nicht einlassen wollen, egal, wie der Preis aussieht. Ein Quadraturdekoder auf dem Chip ist sicherlich eine feine Sache. Beim uralten H8/300H war schon einer vorhanden und beim STM32F4 bietet fast jeder Timer mindestens einen Kanal mit enormer Bandbreite, was einen schon fast überfordern kann: "Ich kann mich garnicht entscheiden, ist Alles so schön bunt hier" ;-)
m.n. schrieb: > "Ich kann mich garnicht entscheiden, ist > Alles so schön bunt hier" ;-) ..würde Nina Hagen sagen. MfG Paul
Lothar M. schrieb: > W.S. schrieb: >> Bei Pfuschern hingegen ist es völlig üblich, daß sie die korrekte >> Vorbehandlung ignorieren und das daraus erwachsende Fehlverhalten >> anschließend korrigieren wollen. > Ich verlagere Filterung und Entprellung gerne in die Software, weil die > so leicht anpassbar ist. Aber ich halte das nicht für Pfusch, sondern > habe die Theorie dahinter kapiert... Ja, eben. Das IST Pfusch. Fehler, die man vorn in der Signalkette gemacht hat, kann man regelmäßig nicht mehr weiter hinten ausbügeln - auch nicht mit beliebig viel Theorie. Man handelt sich dabei nur noch weitere Constraints ein. Wir hatten das hier schon unendlich oft: bei PT100-Schaltungen, bei grandiosen Software-Frequenzzählern und so weiter. Also nochmal: Zuerst die Konditionierung, also Filterung, Entprellung, Schmittriggerung oder weiß der Geier was - und erst dann die Auswertung. Und wenn man denn schon die Signale per Vorbehandlung sauber gemacht hat, dann ist Polling - um das es hier ja ging - herzlich überflüssig. Und mit den Bierchen hast du ja so Recht, manchmal seid ihr alle zusammen nur nach ner dreiviertel Flasche Rotwein auszuhalten. Prost. W.S.
O.T. W.S. schrieb: > Und mit den Bierchen hast du ja so Recht, manchmal seid ihr alle > zusammen nur nach ner dreiviertel Flasche Rotwein auszuhalten. > > Prost. Um 13:19 ?? Kein Bier vor 4. --------------------------------------------------------------------- Gestern komme ich wie jeden Tag aus der Kneipe -da tritt mich doch so ein Rindvieh auf die Pfoten... --------------------------------------------------------------------- Onkel, spendest Du für's Trinkerheim? Ach was! Die sollen zu Hause saufen. ;-) MfG Paul
W.S. schrieb: > Fehler, die man vorn in der Signalkette gemacht hat, kann man regelmäßig > nicht mehr weiter hinten ausbügeln - auch nicht mit beliebig viel > Theorie. Tja, manche lernen's nie. verdumme uns aber nicht den Rest der Bevölkerung.
W.S. schrieb: > Also nochmal: > Zuerst die Konditionierung, also Filterung, Entprellung, > Schmittriggerung oder weiß der Geier was - und erst dann die Auswertung. Welche Teile davon sind Software? ;-)
Hallo, regelmäßig, also gibt es Ausnahmen. Man muss das halt im Einzelfall entscheiden, schon mal gesehen wie ABS funktioniert. Da ist auch nix mehr mit Regelmäßig. MfG ich
Volker S. schrieb: > Ich versteh die Frage nicht ganz. Stell dir einfach vor, das es davon > abhängig ist, ob und in welchem Menü sich das Programm gerade befindet. > Heller-dunkler, vor-zurück, langsamer-schneller, nächstes-vorheriges > Menü ... > Ist doch nicht Teil des Problems der Drehgeber-Auswertung. Hmmm ... finde ich schon ... läuft bei mir auch so. Für einen Drehgeber ein Register. Die komplette Menustruktur sowie deren Aktionen liegen in einer Tabelle / Array. Wechsele ich in ein Untermenu, wird der Inhalt des Registers auf einen Stack geschoben und das Register auf 0 gesetzt. Verlasse ich den Menupunkt, wird der Wert vom Stack wieder ins Register geschrieben. Ganz kleines, kompaktes, schnelles Stück SW. Nur EINE Auswertung. Also wertest Du die Impulse dann ausserhalb des IRQs aus? An zig verschiedenen Stellen? kopfkratz Stelle ich mir ungeheuer wartungsfeindlich vor ... Okay, bei dem Vergleich bin ich dann bei 5 Zeilen Code. Eine Auswertung ist das für mich dann allerdings nicht mehr ... Gruß Jobst
In Jobst M. schrieb: > Eine Answer tung Auswertung ist das für mich dann allerdings nicht mehr ... Mir langt's ( bisher-)
Klaus W. schrieb: > Hallo, > > ich habe mit Drehimpulsgebern scheinbar noch leichte > Verständnisschwierigkeiten. ... und ich auch, vielleicht kann mir mal einer kurz helfen. "Messe" einen kleinen billigen mechanischen Alps gerade mit einem akustischen Durchgangsprüfer durch. So wie ich das verstanden habe sollte an bestimmten Einrastungen konstant Kontakt zwischen Terminal C zu einem oder zu beiden Terminals A/B bestehen. Egal wie weit ich aber drehe, es es kommt niemals dazu. Nur beim Drehen selber piepts- immer. Ob nun C-A oder C-B. Ist der Impulsgeber etwa defekt? Handelt es sich um ein anderes Konstruktionsprinzip? Oder was hab ich übersehen?
Michael schrieb: >an bestimmten Einrastungen konstant Kontakt zwischen Terminal C >zu einem oder zu beiden Terminals A/B bestehen. Es werden ja vier Zustände nacheinander durchlaufen und dann beginnt das Gleiche wieder von vorne. 00 10 11 01 00 10 11 01 Vielleicht hat dein Drehgeber den Rastpunkt genau bei 00.
Michael schrieb: > Ist der Impulsgeber etwa defekt? Wahrscheinlich nicht. Ist auch keine geeignete Testmethode.
Michael schrieb: > Egal wie weit ich aber > drehe, es es kommt niemals dazu. Kommt nicht wozu? Auch "beide aus" ist möglich (blaue Linie). Das liegt an <gelber Kringel>, alles in <rosa Bereich> könnte sein.
Günter Lenz schrieb: > Es werden ja vier Zustände nacheinander durchlaufen ja und deshalb sollte sich doch ein A/B<->C Kontakt bei fixer Stellung doch nach wenigen Versuchen feststellen lassen. Jobst M. schrieb: > Wahrscheinlich nicht. Ist auch keine geeignete Testmethode. Warum sollte sich ein A/B<->C Kontakt bei fixer Stellung nicht via (akustischem) Durchgangsprüfer feststellen lassen? Mehr möchte ich ja im Augenblick noch nicht. Torsten C. schrieb: > Kommt nicht wozu? Zu irgendeinem messbaren Kontakt A/B<->C an einem fixen Rastpunkt. Also auch für A... Das muß doch in irgend einer Stellung mit C verbunden sein? Im angehängten Bild ist der Übeltäter.
Es kann ja sein, daß sich drei Zustände zwischen den Rastpunkten befinden. Auf jeden Fall müssen sich alle vier Zustände nachweisen lassen, ansonsten ist er defekt.
Michael schrieb: > Also auch für A... Das muß doch in irgend einer Stellung mit C verbunden > sein? Ja. Aber B nicht. Vielleicht hast Du A und B vertaucht? Michael schrieb: > Im angehängten Bild ist der Übeltäter. So sieht meiner auch aus, für Drehgeber_Arduino_Shield_Idee.png^^.
:
Bearbeitet durch User
Günter Lenz schrieb: > Es kann ja sein, daß sich drei Zustände zwischen > den Rastpunkten befinden. Auf jeden Fall müssen > sich alle vier Zustände nachweisen lassen, ansonsten > ist er defekt. Also 10 Rastungen hab ich hintereinander geprüft und nie kam (außer während des Drehens) irgendein Kontakt A/B<->C zustande. Torsten C. schrieb: > Ja. Aber B nicht. Vielleicht hast Du A und B vertauscht? Alle Kombinationen sind durchgeprüft. Also ich gehe mal von einem Defekt aus und werde mir weitere Exemplare besorgen. Danke für Eure Hinweise.
Michael schrieb: > Warum sollte sich ein A/B<->C Kontakt bei fixer Stellung nicht via > (akustischem) Durchgangsprüfer feststellen lassen? Ja, geht ja offensichtlich nicht ... trotzdem bin ich mir sicher, dass er in Ordnung ist. Wenn Du etwas anderes damit vor hast, als das, wofür er gedacht ist, ist er dafür vermutlich nicht geeignet. Meine Alps Drehgeber haben auch beide Kontakte offen, wenn eingerastet. Michael schrieb: > Im angehängten Bild ist der Übeltäter. Du hast die Kamera falsch rum gehalten. Der übeltäter ist auf der anderen Seite der Kamera! Im Bild ist nur ein Drehgeber, der für das alles nichts kann und so wie er aussieht noch nicht viel erlebt hat. Gruß Jobst
Michael schrieb: > nie kam … irgendein Kontakt A/B<->C zustande. Was bedeutet Dein Schrägstrich? Falls '/' == '|' ("oder"), dann kann der Geber tatsächlich nicht "enc.png"^^ entsprechen. Entweder hast Du einen anderen Geber oder Dein Geber ist - wie Du sagst - kaputt.
Michael schrieb: > Also ich gehe mal von einem Defekt aus und werde mir weitere Exemplare > besorgen. An Deiner Stelle würde ich so richtig Theater beim Versender machen!
Jobst M. schrieb: > Der übeltäter ist auf der > anderen Seite der Kamera! Wenn Du eine plausible Erklärung liefern kannst bin ich gern der "Übeltäter". Da ich mir unsicher war hab ich hier ja auch angefragt. Torsten C. schrieb: > Was bedeutet Dein Schrägstrich? Ob A oder B- egal... Jobst M. schrieb: > An Deiner Stelle würde ich so richtig Theater beim Versender machen! Bin ich nicht der Typ zu ^^
Jobst M. schrieb: > Meine Alps Drehgeber haben auch beide Kontakte offen, wenn eingerastet. Und wie sieht bei Deinen Drehgebern das Diagramm aus? Oder welchen Typ hast Du? Ich frage, damit der geneigte Leser eine Chance hat, mal ins Datenbalatt zu schauen. @Klaus W.: Wir haben seit dem 13.07.2015 um 16:11 Uhr nichts mehr von Dir gehört. Alles klar?
:
Bearbeitet durch User
Torsten C. schrieb: > Und wie sieht bei Deinen Drehgebern das Diagramm aus? Ja Torsten, berechtigte Frage. Antwort: Unbekannt. Ist ein Teil aus der Bastelkiste und wird von mir erstmalig verwendet. Ein Diagramm für ein solches mechanisches Alps, daß bei jeder Rastung beide Kontakte offen (mit C unverbunden) zeigt hat meine bisherige Suche aber noch nicht zutage gefördert..
Michael schrieb: > Wenn Du eine plausible Erklärung liefern kannst bin ich gern der > "Übeltäter". Da ich mir unsicher war hab ich hier ja auch angefragt. Nein, Du bist auch ohne ERklärung der Übeltäter und Du wirst es vermutlich noch feststellen. Und ich habe Dir gesagt, dass Du dazu nicht die richtige Messmethode hast. Das wolltest Du nicht einsehen. Gut kann man so machen. Bringt Dich nur nicht weiter. Torsten C. schrieb: > Und wie sieht bei Deinen Drehgebern das Diagramm aus? Kann ich Dir nicht sagen, da ich nicht auf die Rastung triggern kann. Sie tun ja auch einfach das, was sie tun sollen. Torsten C. schrieb: > Oder welchen Typ hast Du? Muss ich morgen mal im Lager schauen ... Gruß Jobst
Jobst M. schrieb: > Michael schrieb: >> Wenn Du eine plausible Erklärung liefern kannst … > Nein, Du bist auch ohne ERklärung der Übeltäter … Das werden wir sehen, … Jobst M. schrieb: > Muss ich morgen mal im Lager schauen … und zwar morgen. Ich hole schon mal die Cola und die Chips raus. :-)
:
Bearbeitet durch User
Torsten C. schrieb: > … und zwar morgen. Ich hole schon mal die Cola und die Chips raus. :-) Och, weißt Du, ich muss mich nicht von Dir erpressen lassen, Du wirst es auch ohne mich merken. Ich hatte gerade noch etwas geschaut, aber das behalte ich nun für mich. Bestell neue Teile. Die sind bei Leuten, die offensichtlich keine Ahnung davon haben immer kaputt.
Jobst M. schrieb: > ich muss mich nicht von Dir erpressen lassen Welche Erpressung? Jeder zieht sich den Schuh an, der ihm paßt. :-) Also nur heiße Luft. Auch egal.
:
Bearbeitet durch User
Jobst M. schrieb: > Ich sage doch … Das habe ich gelesen. Aber: Wem sagst Du das? Michael oder mir? Meine Geber funktionieren; die habe ich am 31. Mai 2013 bei maritalogo gekauft: http://www.ebay.de/usr/maritalogo Manchmal frage ich mich, wozu ich mir das hier antue. Aber besser als RTL und VOX ist das allemal. ;-) Michael schrieb: > Ja Torsten, berechtigte Frage. > Antwort: Unbekannt. Ich befürchte, Du hattest Recht. Ich packe die Cola wieder in den Kühlschrank und Chips wieder in den Schrank und gehe ins Bett.
:
Bearbeitet durch User
Michael schrieb: > So wie ich das verstanden habe sollte an bestimmten Einrastungen > konstant Kontakt zwischen Terminal C zu einem oder zu beiden Terminals > A/B bestehen. Das hast du falsch verstanden. > Nur beim Drehen selber piepts- immer. Ob nun C-A oder C-B. Das ist doch gut. Denn der Drehencoder soll ja dazu dienen, das Drehen zu erkennen und auszuwerten. Wo der genau rastet und ob das immer die selbe Stelle ist, das ist piepschnurzegal.
:
Bearbeitet durch Moderator
Michael schrieb: > [...] nie kam (außer > während des Drehens) irgendein Kontakt A/B<->C [...] Warum sollte jeder der vier Zustände in einem Rastpunkt liegen? Wie Du ja selbst (noch nicht) gemerkt hast, kannst Du einige Zustände nur während des Drehens erreichen. Frau Werwolf sagt, das gehört so.
Torsten C. schrieb: > @Klaus W.: Wir haben seit dem 13.07.2015 um 16:11 Uhr nichts mehr von > Dir gehört. Alles klar? Jaja, ich lebe noch. Ich lese und denke mir meinen Teil.
Michael schrieb: > Ist der Impulsgeber etwa defekt? Handelt es sich um ein anderes > Konstruktionsprinzip? Oder was hab ich übersehen? Es gibt mindestens zwei unterschiedliche Konzepte. Das eine, welches zu deiner Abbildung passt, funktioniert ungefähr so wie ein Wechselschalter. Von einem Rastpunkt zum nächsten wechselt der Zustand der Schalter. Es würde also in jeder zweiten Stellung piepen. Hier entsteht sozusagen nur ein halber Puls pro Raste (oder eben zwei Rastpunkte für einen Puls). Das andere ist eher eine Taster Funktion. Während des Drehens wird kurz der "Taster" geschlossen. Hier piept es nur beim Drehen. Das ist wohl so bei dem Teil das du hast. Bei diesen Typen hat man dann einen Puls pro Raststellung. Die Darstellung der Signale A und B auf den Abbildungen darfst du nicht so ernst nehmen. Die sind NICHT 90° versetzt (OK bei genau einer ganz bestimmten Drehfrequenz wird's wohl so sein). Da kann man nur sehen welches Signal früher und welches Signal später kommt. Das Tastverhältnis des Signals ist bei den "Tastern" auch nicht 50% sondern eigentlich immer wesentlich kürzer. In der beigefügten Abbildung sieht man links das Wechsler- und rechts das Taster-Prinzip. Wenn man ein Oszilloskop hat, dann schaut man sich das am besten mal an, dann weiß man hinterher Bescheid ;-) <edit>Da ist es dann natürlich von Vorteil wenn man eine Entprellung mit R/C Glied hat </edit>
:
Bearbeitet durch User
Ok, hier noch ein Bild. Das habe ich selber mal für ein Script gezeichnet, welches ich gerade überarbeite und auch deshalb dieser Diskussion folge ;-) Hier sind die zwei Typen in unterschiedlichen Farben dargestellt. Der Rastpunkt ist nicht eingezeichnet. Die gestrichelte Linie markiert den Flankenwechsel, den man mit der Interrupt Technik auswerten kann. Grün wäre ein Signal eines Drehgebers mit gleich viel Rastpunkten wie Pulsen. (Tasterprinzip) Violett ist dann ein Drehgeber mit halb soviel Pulsen wie Rastpunkten. (Wechsler)
:
Bearbeitet durch User
Volker S. schrieb: > Grün wäre ein Signal eines Drehgebers mit gleich viel Rastpunkten wie > Pulsen. (Tasterprinzip) > > Violett ist dann ein Drehgeber mit halb soviel Pulsen wie Rastpunkten. > (Wechsler) Hast Du konkrete Beispiele für jeweils beide Varianten (Datenblätter)? Bislang ist mir noch kein Drehgeber untergekommen, bei dem nicht zwei halbwegs genau 90° phasenversetzte Rechtecksignale mit 50% Tastverhältnis herauskamen.
:
Bearbeitet durch User
Walter T. schrieb: > Hast Du konkrete Beispiele für jeweils beide Varianten? Volker S. schrieb: > Also ich habe die zufällig beide, den ALPS STEC12 und den PANASONIC > EVEQDBRL416B als alternative Bestückungsvariante auf unseren > Mikrocontroller Boards für Studenten. Walter T. schrieb: > Bislang ist mir noch kein Drehgeber untergekommen, bei dem nicht zwei > halbwegs genau 90° phasenversetzte Rechtecksignale mit 50% > Tastverhältnis herauskamen. Mir geht es genau umgekehrt ;-) Wir reden hier doch immer noch über diese Drehgeber die man mit der Hand dreht um irgendwas einzustellen, oder ? Bei Encodern auf Motorwellen oder ähnlichem sieht das natürlich anders aus. <edit> Hmmm, hast du "Datenblätter" später angefügt, oder habe ich das übersehen ? In den Datenblättern sieht das immer so aus ... </edit>
:
Bearbeitet durch User
Volker S. schrieb: > Wir reden hier doch immer noch über diese Drehgeber die man mit der Hand > dreht um irgendwas einzustellen, oder ? OK, auch die gibt es in unterschiedlichen Qualitäten. Ich nutze gerne die hier: http://www.bourns.com/pdfs/bourns_em14_brochure.pdf und für einfachere Bedieneingaben die billigen EVEP von Panasonic: http://industrial.panasonic.com/lecs/www-data/pdf/ATT0000/ATT0000CE11.pdf Beide sehen von der Charakteristik auf dem Oszilloskop nach 50%/90° aus. Aber gut zu wissen, daß das nicht allgemeingültig ist. Volker S. schrieb: > Hmmm, hast du "Datenblätter" später angefügt, oder habe ich das > übersehen ? Ja.
:
Bearbeitet durch User
Lothar M. schrieb: > Das ist doch gut. Dann ist ja gut... Immerhin, das Teil ist auch nicht allzu alt und unbenutzt. > Wo der genau rastet und ob das > immer die selbe Stelle ist, das ist piepschnurzegal. OK. In den mir bislang ersichtlichen Diagrammen mit eingezeichnetem Rastpunkt gab es dort immer zeitweise Verbindungen mit Masse (C). Überhaupt bin ich erst fälschlicherweise davon ausgegangen, daß mit dem Drehen nur ein fixer Code an den Ausgängen wechselt: Der Blick in einen Code zur Auswertung (derselbe siehe Anhang) von Beitrag "AVR: Dreh-Encoder mit Interrupts" hat mich zur gleichen Schlußfolgerung verleitet, indem dort nämlich vom Encoder ein Startzustand abgefragt wird. Volker S. schrieb: > Das andere ist eher eine Taster Funktion. Während des Drehens wird kurz > der "Taster" geschlossen. Hier piept es nur beim Drehen. Das ist wohl so > bei dem Teil das du hast. Bei diesen Typen hat man dann einen Puls pro > Raststellung. Ja wunderbar. Wenn das so ist bin ich zufrieden. Daß diese mechanischen Drehgeber für die Auswertung eine ziemliche Wissenschaft sind geht mir nun auch langsam auf. Ein Oszilloskop ist dazu auch keine schlechte Idee^^
Walter T. schrieb: > Bislang ist mir noch kein Drehgeber untergekommen, bei dem nicht zwei > halbwegs genau 90° phasenversetzte Rechtecksignale mit 50% > Tastverhältnis herauskamen. Diese billigen mechanischen Eingabeelemente mit Namen "Encoder" (um die es in diesem Thread von Anfang an gehen sollte) sind allesamt asymmetrisch. Nur industrielle Inkrementalgeber haben den schönen Quadraturverlauf aus dem (Lehr)Buch... Michael schrieb: > hat mich zur gleichen Schlußfolgerung verleitet, indem dort nämlich vom > Encoder ein Startzustand abgefragt wird. Nach dem Einschalten steht der Encoder irgendwie. Und das ist der Startzustand. Danach kommt die Impulsfolge, wenn sich der Encoder bewegt... BTW: den angehängten Code habe ich nur kurz überflogen und wegen "viel zu kompliziert und umständlich" nicht näher analysiert. Wenn ich in VHDL (das anerkanntermaßen eine eher geschwätzige Sprache ist) nur eine dreiviertel Bildschirmseite brauche, dann muss alles, was mehr braucht unnötig kompliziert sein... http://www.lothar-miller.de/s9y/categories/46-Encoder
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Nur industrielle Inkrementalgeber haben den schönen > Quadraturverlauf aus dem (Lehr)Buch... Lässt sich eingebaute Decoderhardware z.B. im XMega dann problemlos auch für die "billigen" nutzen?
Walter T. schrieb: > Beide sehen von der Charakteristik auf dem Oszilloskop nach 50%/90° aus. > > Aber gut zu wissen, daß das nicht allgemeingültig ist. Ich denke mal bei den meisten (oder allen ?) optischen wird es 50% 90° sein. Bei den Panasonic muss ich mich jetzt ein bisschen wundern. Ich habe die EVEQ anstatt der EVEP die ja im gleichen Datenblatt sind. 50% ist klar, weil es ja "Wechsler" sind. 90° Phasenverschiebung kann ich aber beim besten Willen nicht sehen. Eine Platine mit einem EVEQ liegt genau vor mir und ich mache am besten mal einen Screenshot. (Und schau noch mal genau im Datenblatt, wo der Unterschied ist)
:
Bearbeitet durch User
Michael schrieb: > Lässt sich eingebaute Decoderhardware z.B. im XMega dann problemlos auch > für die "billigen" nutzen? Normalerweise ja, denn von Hand erreicht man keine 30 Umdrehungen pro Sekunde bei 1000 Impulsen pro Umdrehung...
Michael schrieb: > Lässt sich eingebaute Decoderhardware z.B. im XMega dann problemlos auch > für die "billigen" nutzen? Grundsätzlich spielt es (bei den Eingabeteilen) ja keine Rolle, ob der Signalverlauf wie aus dem Lehrbuch aussieht. Das Tastverhältnis und die Phasenlage sind hier egal. Michael schrieb: > Der Blick in einen > Code zur Auswertung (derselbe siehe Anhang) von > Beitrag "AVR: Dreh-Encoder mit Interrupts" > hat mich zur gleichen Schlußfolgerung verleitet, indem dort nämlich vom > Encoder ein Startzustand abgefragt wird. Der Startzustand wurde möglicherweise abgefragt um nicht die erste Flanke eines "Wechler"-Typs zu verpassen. Wenn man beispielsweise nur auf eine Flanke triggert und das entsprechende Signal am Anfang High-Pegel hat, dann muss die aktive Flanke natürlich auf "fallend" stehen um den nächsten <edit>den allerersten</edit> Wechsel zu erfassen zu können. (Bei jedem IR schaltet man dann die aktive Flanke um)
:
Bearbeitet durch User
Volker S. schrieb: > Das Tastverhältnis und die > Phasenlage sind hier egal. Ich dachte eher an Störungen des Signalverlaufs wie Prellen.
Am Wochenende bin ich wieder zuhause bei meinem Oszi und schaue auch noch mal nach. Volker S. schrieb: > Das Tastverhältnis und die > Phasenlage sind hier egal. So ganz egal ist das ja nicht - immerhin hängt die Wahl des minimalen Poll-Frequenz genau davon ab, daß alle erlaubten Zustände mindestens einmal abgefragt werden. Ist einer der Zustände signifikant kürzer, weil die Phasenlage nicht mehr 90° und/oder der Tastgrad nicht mehr 50% ist, muß die Schätzung der maximalen erlaubten Drehfrequenz/minimal erlaubten Pollfrequenz angepaßt werden - offensichtlich waren da meine Schätzungen immer deutlich weniger konservativ als angenommen.
Walter T. schrieb: > Ist einer der Zustände signifikant kürzer, weil > die Phasenlage nicht mehr 90° und/oder der Tastgrad nicht mehr 50% ist, > muß die Schätzung der maximalen erlaubten Drehfrequenz/minimal erlaubten > Pollfrequenz angepaßt werden Oh, DARAN habe ich gar nicht gedacht ...
Versprochenes Beispiel eines Signalverlaufs Panasonic EVEQ mit 32 Rastpunkten (20 ms/Div)
Volker S. schrieb: > Versprochenes Beispiel eines Signalverlaufs Panasonic EVEQ mit 32 > Rastpunkten (20 ms/Div) Mit Flankenauswertung per Interrupt ist das kein Problem - auch wenn man sehr viel schneller dreht.
Lothar M. schrieb: > Moderate Drehgeschwindigkeit mit ca 1/3 Umdrehung pro Sekunde... 32 Rastpunkte sind bei diesem Typ 32 Wechsel. Sagen wir die Pulse sind so ~50ms lang, dann kommt man auf 1 Umdrehung alle 1500ms also 1,5s. -> 2/3 Umdrehungen pro Sekunde. (immer noch moderat ;-) <edit> die Dinger haben ein recht hohes Rastmoment </edit>
:
Bearbeitet durch User
m.n. schrieb: > Mit Flankenauswertung per Interrupt ist das kein Problem - auch wenn man > sehr viel schneller dreht. Vorausgesetzt, die Interrupt-Routine fragt den anderen Eingang ab, bevor der auch wechselt. Allerdings hat die Interrupt-Flanken-Auswertung einen (weiteren) entscheidenen Nachteil: Dreht man wirklich zu schnell, so daß auch der andere Eingang gewechselt hat, erfasst sie die angebliche Drehbewegung einfach falsch. Das Polling-Prinzip (oder der Timer-Interupt mit Polling) ERKENNT wenigstens, daß sie zu langsam abgefragt hat (weil ein Wechsel 00 nach 11 oder 01 nach 10 stattgefunden hat oder zurück) und kann darauf hinweisen, daß ihr die Impulsabstände zu kurz sind bzw. die Bewegung zu schnell. Nur die Dümmsten verwenden Flankeninterrupts.
Volker S. schrieb: > Sagen wir die Pulse sind so ~50ms lang, Einfach mal von steigender Flanke blau bis steigende Flanke blau gezählt: wenn die Skalierung 20ms/div ist, dann dauert da ein kompletter Zyklus ca. 90-100ms...
Lothar M. schrieb: > Volker S. schrieb: >> Sagen wir die Pulse sind so ~50ms lang, > Einfach mal von steigender Flanke blau bis steigende Flanke blau > gezählt: wenn die Skalierung 20ms/div ist, dann dauert da ein kompletter > Zyklus ca. 90-100ms... Ja, aber ein kompletter Zyklus entspricht ZWEI Rastpunkten. (oder einem negativen und einem positiven Puls)
:
Bearbeitet durch User
MaWin schrieb: > Vorausgesetzt, die Interrupt-Routine fragt den anderen Eingang ab, bevor > der auch wechselt. Jetzt machst du dich aber lächerlich ...
Volker S. schrieb: > Ja, aber ein kompletter Zyklus entspricht ZWEI Rastpunkten. > (oder einem negativen und einem positiven Puls) Das sieht man am Oszi-Bild natürlich sehr, sehr schlecht. Und das Datenblatt sagt dann auch etwas Anderes als die erwähnten 32 Rastungen. Mit den dort aufgeführten 8 Zyklen pro Umdrehung ist die Drehgeschwindigkeit mit gut 1,5 U/s schon recht zackig... ;-) BTW: genau das Ding verwende ich mit Beschleunigung seit ewigen Zeiten. Es macht seine Arbeit recht gut. Ohne Beschleunigung würde man sich bei 16 Schritten pro Umdrehung zu Tode kurbeln... http://www.lothar-miller.de/s9y/categories/54-Encoder
:
Bearbeitet durch Moderator
@Lothar Eigentlich würde ich von Dir als Moderator erwarten, daß Du die Pöbeleien schreiender Kinder einfach löscht.
Lothar M. schrieb: > Das sieht man am Oszi-Bild natürlich sehr, sehr schlecht. Und das > Datenblatt sagt dann auch etwas Anderes als die erwähnten 32 > Rastungen... Einfach mal in die rechte (richtige ;-) Spalte schauen. (links P - rechts Q) Jaaaaa, besser ich hätte nochmals explizit geschrieben: "32 Rastpunkte und 16 Pulse"
:
Bearbeitet durch User
Lothar M. schrieb: > BTW: genau das Ding verwende ich mit Beschleunigung seit ewigen Zeiten. Ich verwende den (EVEQ) einfach nur, weil es den billig bei Pollin gab (75ct) als ich einen günstigen Bausatz für unsere Studierenden zusammenstellen wollte. In diesem Sinne: Lieber Pollin als Polling (ha ha ha wie schlecht ;-)
Volker S. schrieb: > In diesem Sinne: Lieber Pollin als Polling > (ha ha ha wie schlecht ;-) Na, so schlecht nun auch wieder nicht. Ein Kalauer kommt immer gelegen. Ja, manche Drehimpulsgeber reagieren ziemlich impulsiv, genau wie jene, die daran drehen. ;-) MfG Paul
Lothar M. schrieb: > W.S. schrieb: >> Also nochmal: >> Zuerst die Konditionierung, also Filterung, Entprellung, >> Schmittriggerung oder weiß der Geier was - und erst dann die Auswertung. > Welche Teile davon sind Software? ;-) Immer die hinteren. Das kannst du dir merken, denn die reale Welt ist analog, danach kommt die Digitalisierung und dann die digitale Welt inclusive Software. Jegliche Digitalisierung wandelt zeit- und amplitudendiskretes Zeug in zeit- und amplitudendiskrete Signale um - und da schlägt IMMER das Abtasttheorem zu. Also muß man vorher im analogen Bereich so konditionieren, daß man nicht in Alias hineinrennt oder sich den S/N-Abstand kaputtmacht. Jeder halbwegs vernünftige Ingenieur weiß das, bloß MaWin nicht: MaWin schrieb: > Tja, manche lernen's nie. > verdumme uns aber nicht den Rest der Bevölkerung. Warum glauben Leute wie MaWin eigentlich, daß man durch das Klopfen derartiger Sprüche mehr Recht hat als durch sachliche Argumente? Oder gar durch das verstehende Lesen dessen, was andere geschrieben haben? Anstatt ausgerechnet MIR Verdummung vorzuwerfen, sollte er besser mal den Tietze-Schenk lesen, eine alte Ausgabe reicht für MaWin völlig aus. W.S.
Wenn ein Drehgeber das macht, was Volker SchK
in screenshot27.png zeigt, ist das meiner Meinung
nach Herstellerpfusch. Der Hersteller sollte schon
90 grad Versatz anstreben, zu mindest 45 grad.
Rastpunkt auf einer Flanke ist nach meiner Meinung
auch Herstellerpfusch. Am besten man nimmt Drehgeber
die Optisch abgetastet werden, die haben keinen Verschleiß
und prellen nicht.
MaWin schrieb:
>Nur die Dümmsten verwenden Flankeninterrupts.
Das kann man so pauschal nicht sagen.
Es kommt darauf an was man machen will.
Wenn man das drehen einer Motorwelle zählen will,
und das die Hauptaufgabe des Programms ist,
würde ich Polling verwenden, wenn das Programm
zum Beispiel die Frequenz eines Oszillators in
einen Kurzwellenempfänger überwacht,
würde ich Flankeninterrupt verwenden. Da braucht sich
das Programm nicht dauernd mit dem Drehgeber beschäftigen,
nur dann wenn der Benutzer am Knopf dreht.
Michael schrieb: > So wie ich das verstanden habe > sollte an bestimmten Einrastungen konstant Kontakt zwischen Terminal C > zu einem oder zu beiden Terminals A/B bestehen. Egal wie weit ich aber > drehe, es es kommt niemals dazu. Dann ist dir wohl mit der Pinbelegung etwas durcheinander gekommen.
W.S. schrieb: > sachliche Argumente Die sachlichen Argumente wurden alle genannt. Es ist die Borniertheit, der Falschgläubigen, die nicht merken, daß ihre Pseudo-Argumente "da wird der Prozessor nicht so belastet wenn keiner am Knopf dreht" hirnrissig sind. Der wahre Hintergrund lautet wohl: Sie haben noch immer nicht verstanden, WO die Probleme eigentlich herkommen, sie wundern sich nur, daß selbst manche kommerziellen Geräte so merkwürdig auf Drehgeber reagieren.
Wolfgang schrieb: > Dann ist dir wohl mit der Pinbelegung etwas durcheinander gekommen Nein, aber am Verständnis^^
Günter Lenz schrieb: > Wenn ein Drehgeber das macht, was Volker SchK > in screenshot27.png zeigt, ist das meiner Meinung > nach Herstellerpfusch. Der Hersteller sollte schon > 90 grad Versatz anstreben, zu mindest 45 grad. Ich bin fest davon überzeugt, daß das gezeigte Verhalten ein Artefakt der Meßmethode ist. Die 90° Phasenversatz gelten unter der Voraussetzung einer konstanten Winkelgeschwindigkeit. Die ist aber bei einem Drehgeber mit Rastung (gar einer so harten wie der Panasonic hat) und beim Drehen von Hand gerade nicht gegeben. Statt dessen kommt der Drehgeber nur langsam aus der alten Rastposition um dann schnell zur nächsten zu springen. Wenn man die Rastung abschalten oder ausbauen könnte (geht aber nicht, zumindest nicht zerstörungsfrei) dann würde man das normale Verhalten sehen können.
Verzeiht mir wenn ich jetzt mal kräftig in den Fettnapf trete. Vor Jahren adoptierte ich die in C geschriebenen Drehgeber Routinen vom Peter auf allen möglichen uC und haben bei mir ohne Ausnahme mit minimalsten Schwierigkeiten überall einwandfrei funktioniert. Hier die Liste: PIC18F8722, PIC18F4620, PIC30F6014, PIC33Mc510, AVR, 8051, CORTEX M3/4, ZILOG Encore! Außer Hardware notwendigen Anpassungen gab es nichts zu ändern oder daran rütteln. Ich habe sowohl verschiedene mechanische neben einigen optischen Drehgebern getestet. Kontaktprellprobleme gibt es auch bei einer ISR Wiederholungsrate von 1ms nicht. Man kann sogar ohne wesentlichen Zählfehler ziemlich schnell daran drehen. Ich würde also deshalb vorschlagen sein Beispiel zuerst zum Laufen zu kriegen, weil es mit absoluter Sicherheit funktionsfähiger Code ist und die Mühe auf alle Fälle wert ist. Sein Beispiel kann man als De-Fakto Referenzdesign schlechthin ansehen. Ich kann es nur wärmstens empfehlen und ist wirklich kein Jägerlatein;-) Mfg, Gerhard
:
Bearbeitet durch User
Volker S. schrieb: > Versprochenes Beispiel eines Signalverlaufs Panasonic EVEQ mit 32 > Rastpunkten (20 ms/Div) Axel S. schrieb: > Ich bin fest davon überzeugt, daß das gezeigte Verhalten ein Artefakt > der Meßmethode ist. Hallo zusammen, mir hat dieses Signal und die Frage, ob das einfach ein Artefakt ist, keine Ruhe gelassen. Deshalb habe ich mal den billigen Pollin-Drehgeber EVEQDBRL416B in meine Bohrfräsmaschine eingespannt - in diesem Drehzahlbereich ist sie zwar nicht wahnsinnig Drehzahlkonstant, aber für eine Abschätzung sollte es reichen. Da ich keine Screenshots machen kann, hier nur ein einfaches Bildschirmfoto vom Oszilloskop. Der Effekt, daß das Puls-Pausen-Verhältnis nicht ganz 50% ist, kann man erkennen, und der Phasenversatz ist auch nicht exakt bei 90°. Aber so stark, wie bei der Messung von Volker S. ist das auch alles nicht von diesem Idealbild (50%/90°) entfernt. Ich nehme also auch an, daß der Unterschied dort durch den Ruck in den Rastpunkten kommt. Auch meine Q&D-Einspannung ist nicht wahnsinnig steif. Und für einen 75-Cent-Drehgeber sind die Toleranzen sogar ziemlich gut. Für mich bleibt die Erkenntnis: Bei einem Drehgeber, der von Hand betätigt wird, können riesige Sprünge in der Winkelgeschwindigkeit auftreten. Also sollte man bei einer Abschätzung einer sinnvollen Abtastrate mehr auf die mit dem Oszilloskop gemessene minimale Pulsbreite als auf Annahmen, wie schnell ein Mensch drehen kann, verlassen. Viele Grüße W.T.
Gerhard O. schrieb: > Außer Hardware notwendigen Anpassungen gab es nichts zu ändern oder > daran rütteln. Ich möchte das auch unterschreiben - ja, auch ich habe früher mal einen PC- oder ext. Int für den Drehgeber genommen, bin aber durch die Robustheit von PeDas Routinen davon völlig abgekommen. Der Timer fragt bei mir nicht nur den Drehgeber ab, sondern auch alle 10 mal etwaige Taster, so das dieser eine Interrupt für alle Benutzerabfragen sorgt, klein kompakt und schnell. In den meisten Projekten bei mir gibt es sowieso Bedarf für einen Ticker. Mich beeindruckt dabei besonders, das die Routine auch mit den ollsten prellendsten Drehgebern klarkommt, die ich hier habe. Das ich zwischen Drehgeber und MC noch ein paar Bauelemente plaziere, wie R und C, liegt daran, das ich nur ungerne direkt Portleitungen an Benutzerelemente führe.
Walter T. schrieb: > Hallo zusammen, > > mir hat dieses Signal und die Frage, ob das einfach ein Artefakt ist, > keine Ruhe gelassen. Deshalb habe ich mal den billigen Pollin-Drehgeber > EVEQDBRL416B in meine Bohrfräsmaschine eingespannt Also dann zum Drehgeber immer gleich eine Bohrfräsmaschine mitliefern, damit der Benutzer auch "richtig" drehen kann oder was ? Ihr seid mir schon'n paar feine Theoretiker. Bestimmt von der Uni ;-)
vloki schrieb: > Ihr seid mir schon'n paar feine Theoretiker. Bestimmt von der Uni ;-) Äääähhh, bitte nicht zu ernst nehmen. Ich dachte nur gerade an die Uni vs. FH Battles ...
Eventuell ist es beim manuellen Durchblättern eins Menüs ja auch kein Problem, wenn wegen nichtkonstanter Winkelgeschwindigkeit ein Dreh untergeht. Wir reden ja nicht von Absolutwertpositionsmessung im 2..3-stelligen kHz Bereich, sondern von günstigen Eingabe-Bauteilen und wenn man mal schnell 10 Menüpunkte rauf oder runter muß, dann bleibt man im 2-stelligen Herz Bereich. Und das Ganze in einen "Regelkreis" über visuelle (LCD-)Rückmeldung.
vloki schrieb: > bitte nicht zu ernst nehmen Wer 90° bzw. 50% erwartet, muss halt ordentlich Hornhaut auf seinen Fingern haben und kräftig zupacken. Mit zarten Frauenhänden, die den Knopf wie ein rohes Ei anfassen, sieht das Diagramm so aus, wie in screenshot27.png. ;-)
vloki schrieb: > Also dann zum Drehgeber immer gleich eine Bohrfräsmaschine mitliefern, > damit der Benutzer auch "richtig" drehen kann oder was ? Dich interessiert also nicht, welcher Effekt durch den Drehgeber und welcher durch den Nutzer kommt? Mich schon. Aber vielleicht liegt es daran, daß ich tatsächlich von der Uni bin. Viele Grüße W.T. -- Dr. Walter Tarpan Lehrstuhl für Bedienelementesinologie TU Osnabrück
Gerhard O. schrieb: > Vor Jahren adoptierte ich die in C geschriebenen Drehgeber Routinen vom > Peter auf allen möglichen uC und haben bei mir ohne Ausnahme mit > minimalsten Schwierigkeiten überall einwandfrei funktioniert. Hier die > Liste: > > PIC18F8722, PIC18F4620, PIC30F6014, PIC33Mc510, AVR, 8051, CORTEX M3/4, > ZILOG Encore! Dito in PSoC4 (M0). Auch im Multiplexbetrieb (4Drehgeber) no Problem mit Peters Routine. Einzige Änderung: Ich zähle nur die Rasten, statt der Stati, da bleibt der Counterbereich konstant, weil nicht je nach Rastenanzahl dividiert werden muss: Auszug:
1 | if (0 == slast % (1 << encoderMode){ // only the right state 0,1,2->1,2,4 |
2 | counterValue += (s & 2) - 1; |
3 | } |
Mit encoderMode = 4 * pulse / detent Achso, natürlich ohne sonstirgendwelche Entprellung
:
Bearbeitet durch User
Mal zwei Fragen an die Flankeninterrupt-Fraktion: 1) Schaltet Ihr die Flanken-Interrups in der ISR immer zwischen steigend und fallend um? Oder reagiert der Interrupt immer auf beide Flanken und wertet Ihr dann den Pegel in der ISR aus? Volker S. schrieb im Beitrag "Re: Drehimpulsgeber" > Es gibt mindestens zwei unterschiedliche Konzepte. Bezogen auf das rechte Diagramm in 'screenshot25.png', wo das Signal B im Rastpunkt unbestimmt ist: 2) Macht Ihr den Flankeninterrupt nur bei Signal A oder auch bei Signal B?
:
Bearbeitet durch User
Walter T. schrieb: > Dr. Walter Tarpan > Lehrstuhl für Bedienelementesinologie > TU Osnabrück Ohne zu suchen: ist das jetzt real? Das würde immerhin erklären, warum Du Dir (zu Recht) die besseren Bourns leistest ;-) Torsten C. schrieb: > Oder reagiert der Interrupt immer auf beide Flanken > und wertet Ihr dann den Pegel in der ISR aus? So ist es einfacher. Beim AVR können INT0 und INT1 bei jeder Flanke die ISR auslösen; ebenso auch der PCINT. Torsten C. schrieb: > 2) Macht Ihr den Flankeninterrupt nur bei Signal A > oder auch bei Signal B? Nur eine Phase gibt 2-fach, und beiden Phasen ergeben 4-fach Auswertung. Sofern man nicht höchste Auflösung braucht, reicht es, nur eine Phase auszuwerten. probiere doch mal dieses Beispiel: volatile int32_t count; #define PHASE_A 2 // INT0 #define PHASE_B 3 // INT1 löst hier aber keine ISR aus #define MASKE (BIT(PHASE_A)+BIT(PHASE_B)) ISR(INT0_vect) { int8_t temp; temp = PIND; // nur ein einziger Zugriff auf PIND ! if((temp & MASKE) == MASKE || (temp & MASKE) == 0) temp = 1; else temp = -1; count += temp; // verkürzt den Code } Matthias S. schrieb: > ja, auch ich habe früher mal einen > PC- oder ext. Int für den Drehgeber genommen, Bei mir ist es genau anders: vor 30 Jahren habe ich fleißig gepollt, da nichts Anderes möglich war; wenn es schnelle Signale waren, mußte ext. Hardware ergänzt werden. Bei den neueren µCs hat man aber erheblich bessere Leistung (Flankenerkennung + Schnelligkeit), sodaß ein Interrupt deutlich eleganter zu benutzen ist, auch wenn viele aus alten Erfahrungen richtige Angst vor Interrupts haben und sich davon auch nicht befreien wollen/können.
Torsten C. schrieb:
>Mal zwei Fragen an die Flankeninterrupt-Fraktion:
Also meine Überlegungen waren bisher nur Theoretisch.
Ich würde den Interrupt auf alle Flanken, bei beiden
Kontakten reagieren lassen, und dann die Pegel in
der ISR auswerten. Wozu hat der Hersteller die
Flankeninterruptfunktion mit eingebaut, wenn man
sie nicht benutzen darf, nur für die Dümmsten?
Praktisch habe ich es aber noch nicht ausprobiert.
Werde ich aber mal in 4 Wochen, wenn ich mehr Zeit habe
mit einem 80C31 mal machen. Ich werde alle Varianten
die hier Vorgeschlagen wurden auf ein Steckbrett mal
testen und Beobachten was passiert. Ich bin kein
Ingenieur und auch kein Dr. Ich befasse mich mit diesen
Dingen nur Hobbymäßig.
Günter Lenz schrieb: > Ich würde den Interrupt auf alle Flanken, bei beiden > Kontakten reagieren lassen, und dann die Pegel in > der ISR auswerten. Naja, sicher ne gute Programmierübung. (siehe Bild) War (glaube ich) der Alps 12.
m.n. schrieb: > probiere doch mal dieses Beispiel: Probieren ist blöd, nachdenken besser: Nehmen wir mal einen realen prellenden Kontakt http://mezdata.de/isp/080_entprellen-mit-ff/ Mal ein paar angenommene Zeiten: 1us an falsch erkannt 0 5us aus verpasst 10us an +1 10us aus -1 7us an +1 100us aus verpasst 7us an +1 25us aus verpasst 10us an +1 50us aus -1 100us an +1 25us aus -1 1us an falsch erkannt 0 5us aus verpasst 20us an +1 20us aus -1 7us an +1 50us aus verpasst ewig an Summe: +3 Die Interrupt-Routine braucht 9us, nach 2us erfasst sie die Ports während der Interrupt bedient wird, sind andere Interrupts gesperrt. Der eine Kontaktwechsel löst also 13 Interrupts aus, die +3 zählen. Ohne extra Hardware aus RC Glied und Schmitt-Trigger, die die Impulszeit garantiert auf die maximale InterruptDauer ausdehnen, https://www.mikrocontroller.net/articles/Datei:Entprellung_mit_IIR-Filter.gif funktioniert die Erfassung nicht zuverlässig. Und ob und wann ein Taster wie schnell prellt, unterliegt einer Menge Randbedingungen, Staub und Oxid, Vibrationen und Alterung, das einzige, was der Hersteller garantiert, ist, daß z.B. nach 5ms das Prellen bestimmt vorbei ist. Wenn also ein Drehgeber beim Ausprobieren funktioniert, ist das mit dieser falschen Auswertung noch lange keine Garantie dafür, daß er am Freitag immer noch fehlerfrei läuft.
m.n. schrieb: > Das würde immerhin erklären, warum Du Dir (zu Recht) die besseren Bourns > leistest Die optischen Bourns-Drehgeber sind das, was früher 10-Gang-Potis waren: Bedienelemente für eine sehr feinfühlige Bedienung. Gern auch für Drehknöpfe mit größerem Durchmesser. Beispiel: CNC-Handrad, Frequenzwahlknopf an besseren Funkgeräten ... (Und, O.T., aber interessante Parallele: Als Meßaufnehmer z.B. für Plotter waren die 10-Gang-Potis auch recht beliebt.) Eine Menüsteuerung würde ich nur im Notfall damit machen. Die feine Einteilung müßte ich für eine sinnvolle Menü-Bedienbarkeit massiv herunterteilen und die fehlenden Rasten stören da auch. Für Menüs sind die billigen Drehgeber mit 32 Rastungen und eingebautem Taster wunderbar. Vermutlich hat damals auch kaum jemand ein Radio mit 10-Gang-Lautstärkepoti entwickelt ... Deswegen habe ich auch beide Typen in der Bastelkiste und beide werden für ihren Zweck eingesetzt.
:
Bearbeitet durch User
Günter Lenz schrieb: > Werde ich aber mal in 4 Wochen, wenn ich mehr Zeit habe > mit einem 80C31 mal machen. Der 8051 in ursprünglicher Form ist einfach viel zu langsam, um heutigen Anforderungen zu genügen. Seinerzeit hatte ich den 80C552 eingesetzt, der mit seinen CT0I - CT3I - Eingängen erste Ansätze für flankengetriggerte Interrupts bot, allerdings viel zu lahm war. Nimm mindestens einen AVR (ATmega88, wie in meinem Codeschnipsel) und takte ihn mit 20 MHz. Walter T. schrieb: > Eine Menüsteuerung würde ich nur im Notfall damit machen. Die feine > Einteilung müßte ich für eine sinnvolle Menü-Bedienbarkeit massiv > herunterteilen und die fehlenden Rasten stören da auch Sag das nicht! Mit besagtem C552 und HP-Drehgeber (64 Pos./U, glaube ich) hatte ich ein 'Radio' gemacht. Entscheidend dabei ist, eine Drehdynamik einzubauen und nach kurzer Zeit den internen Hilfszähler auf 0 zu setzen, um damit einen virtuellen Rastpunkt zu schaffen. Oben hatte ich einen Link auf einen Drehgeber mit Schrittmotor, wo dies auch implementiert ist. Vieleicht mal lesen ;-)
m.n. schrieb: > Torsten C. schrieb: >> Oder reagiert der Interrupt immer auf beide Flanken >> und wertet Ihr dann den Pegel in der ISR aus? > So ist es einfacher. Einfacher war nicht die Frage, es geht darum, wie man die Erkennung sicher macht. Also: Tiefpass ist klar, steht hier schon mehrfach, damit der Pegel nicht wechselt, bis die ISR durch ist. Ich frage, denn man könnte die Flanken-ISR-Flags des B-Signals ja auch in der A-Signal ISR auswerten und das B-Signal höherfrequent entprellen, falls das noch sicherer gegen Falsche Zählungen ist. m.n. schrieb: > Sofern man nicht höchste Auflösung braucht Quark. Die gesuchte Auflösung ist von Rastpunkt zu Rastpunkt und bezieht sich auf das rechte Diagramm in 'screenshot25.png'^^. Also nur eine ISR für Signal A. OK.
:
Bearbeitet durch User
Torsten C. schrieb: > Einfacher war nicht die Frage, es geht darum, wie man die Erkennung > sicher macht. Also: Tiefpass ist klar, steht hier schon mehrfach, > damit der Pegel nicht wechselt, bis die ISR durch ist. Hast Du mein Beispiel nicht gesehen oder nicht verstanden? Der Zustand wird einmalig zu Beginn der ISR gelesen und kann sich dann ruhig wieder ändern. Du kannst natürlich auch beliebig die Flankenerkennung umschalten und damit jede Menge zusätzlich Interrupts erzeugen, wenn das für Irgendetwas gut sein sollte. Torsten C. schrieb: > Ich frage, denn man könnte die Flanken-ISR-Flags des B-Signals ja auch > in der A-Signal ISR auswerten und das B-Signal höherfrequent entprellen, > falls das noch sicherer gegen Falsche Zählungen ist. Wozu, um es unnötig kompliziert zu machen? Torsten C. schrieb: > Quark. Zwitscher liefert die bessere Perspektive.
Reiner W. schrieb: > Naja, sicher ne gute Programmierübung. (siehe Bild) Das sieht kräftig nach Übersprechen aus. Die Störungen treten gehäuft auf, wenn der andere Kanal schaltet.
Mike schrieb: > Das sieht kräftig nach Übersprechen aus. Die Störungen treten gehäuft > auf, wenn der andere Kanal schaltet. Das ist halt die Realität. Mit Polling hat man dabei keinerlei Probleme und braucht keine Zusatzhardware.
Mike schrieb: > Das sieht kräftig nach Übersprechen aus. Die Störungen treten gehäuft > auf, wenn der andere Kanal schaltet. Die Bilder sind im Rahmen einer größeren Arbeit über die Ankopplung von Drehgebern an PSoC 4 in Hard- und Software entstanden. Das Bild zeigt den interessanten Bereich. Dabei wurde nicht untersucht, welchen Einfluss der Messaubau, Übersprechen oder der verwendete Oszi (Digilent Elektronik Explorer) hatten. Gemessen wurde direkt an den Encoderausgängen bei direkter hochohmiger Belastung durch die Porteingänge. Die PSoC Chips liefern ja interne Quadraturdecoder mit, mit denen sich die Encoder absolut sauber lesen lassen, auch wenn sie wie im Bild prellen (oder aus anderen Gründen Störimpulse aufweisen). Da die Hardwareressourcen der PSoC4 Chips aber recht begrenzt sind, habe ich noch eine reine Softwarelösung nach Peters Vorschlag getestet, die ja mit einem Minimum an Software auskommt. Praktisch konnte ich keinen Qualitätsunterschied feststellen (wohlgemerkt im Anwendungsfall eines Drehgebers zur manuellen Eingabe) Ich habe Alps EC11 und die Pollin-Panasonic Teile verwendet. Vorteil der Softwarelösung ist zudem die Tatsache, dass damit ohne viel Aufwand eine Multiplexbetrieb mehrere Drehgeber realisiert werden konnte. Auch wenn ich in Software nur die Lösung nach PD getestet habe (Timer IR), will ich damit ausdrücklich nicht behaupten oder suggerieren, dass eine Flanken-IR Lösung schlechter wäre, da ich das nicht getestet habe (was sicher nicht uninteressant wäre). Michael B. schrieb: > Mit Polling hat man dabei keinerlei Probleme und braucht keine > Zusatzhardware. Ja, das haben meine eigenen Untersuchungen gezeigt. Aber auch das sagt natürlich nicht, dass das mit Flanken-IR nicht gegangen wäre ;-)
Walter T. schrieb: > vloki schrieb: >> Also dann zum Drehgeber immer gleich eine Bohrfräsmaschine mitliefern, >> damit der Benutzer auch "richtig" drehen kann oder was ? > > Dich interessiert also nicht, welcher Effekt durch den Drehgeber und > welcher durch den Nutzer kommt? Man muss da immer das Gesamtsystem sehen. Wenn kein Nutzer mitspielt, dann brauche ich auch keinen Drehgeber. Aber natürlich, wenn man das Gesamtsystem verbessern wollte, dann muss man natürlich wissen, wer für welchen Effekt verantwortlich ist. Anscheinend funktioniert es so wie es ist ausreichend gut.
Volker S. schrieb: > Anscheinend funktioniert es so wie es ist ausreichend gut. Wie meinst Du das? a) Mit fehlerhaften Zählungen (dann muss ich User halt einen Raster weiter drehen) ausreichend gut? b) Mit Timer- oder Flanken-Interrupt oft genug exakt?
Torsten C. schrieb: > Mal zwei Fragen an die Flankeninterrupt-Fraktion: > > 1) Schaltet Ihr die Flanken-Interrups in der ISR immer zwischen steigend > und fallend um? Oder reagiert der Interrupt immer auf beide Flanken > und wertet Ihr dann den Pegel in der ISR aus? > > Volker S. schrieb im > Beitrag "Re: Drehimpulsgeber" >> Es gibt mindestens zwei unterschiedliche Konzepte. > > Bezogen auf das rechte Diagramm in 'screenshot25.png', wo das Signal B > im Rastpunkt unbestimmt ist: > > 2) Macht Ihr den Flankeninterrupt nur bei Signal A > oder auch bei Signal B? 1. kommt drauf an, ob es ein Drehgeber mit gleich vielen Rastpunkten wie Pulsen ist. Wenn es zu jedem Rastpunkt einen Puls gibt, dann machtdas Umschalten keinen Sinn. Wenn das Signal wechselt, dann wechselt auch die aktive Flanke. In beiden Fällen ist immer nur eine Flanke aktiv. 2. Signal A ist anscheinend immer das halbwegs definierte und wird für den IR genommen, der dann Signal B checkt. (Dass die Flanke von Signal B direkt auf dem Rastpunkt liegt könnte man aus vielen Datenblättern deuten, wenn man den lustigen Satz ignoiert, der meist dabei steht)
:
Bearbeitet durch User
Torsten C. schrieb: > Volker S. schrieb: >> Anscheinend funktioniert es so wie es ist ausreichend gut. > > Wie meinst Du das? > > a) Mit fehlerhaften Zählungen (dann muss ich User halt einen Raster > weiter drehen) ausreichend gut? > > b) Mit Timer- oder Flanken-Interrupt oft genug exakt? c;-)
Volker S. schrieb: > 1. kommt drauf an, ob es ein Drehgeber mit gleich vielen Rastpunkten wie > Pulsen ist. Wenn es zu jedem Rastpunkt einen Puls gibt, dann machtdas > Umschalten keinen Sinn. *Wenn das Signal wechselt,* also bei den Typen mit doppelt so vielen Rastpunkten wie Pulsen ...
Volker S. schrieb: > 1. kommt drauf an, ob es ein Drehgeber mit gleich vielen Rastpunkten wie > Pulsen ist. Es ist ein Drehgeber, wie im rechten Diagramm in 'screenshot25.png', so wie Du es zitiert hast: Signal A ist deterministisch und wechselt zwischen den Rastpunkten, an Signal B kann man die Richtung erkennen und es ist im Rastpunkt nicht definiert. Man darf Signal B nur nicht abfragen, wenn es noch prellt und gerade 'falsch' ist. Ich frage euch nur, ob man vom B-Signal besser die Flanken-Flags oder den Polling-Zustand in der Signal-A-ISR abfragt. @Timer-Fraktion: Nicht meckern! Ich versuche zu verstehen, wie die Flanken-Fraktion denkt. Vielleicht ist ja was dran. Die meisten MCUs haben Schmitt-Trigger-GPIOs und ein Kondensator kommt ja schon durch die Leiterbahnen zustande.
:
Bearbeitet durch User
Torsten C. schrieb: > Es ist ein Drehgeber, wie im rechten Diagramm in 'screenshot25.png', so > wie Du es zitiert hast: Signal A ist deterministisch und wechselt > zwischen den Rastpunkten, an B kann man die Richtung erkennen und es ist > im Rastpunkt nicht definiert. Es ist erstens völlig egal, ob Signal B im Rastpunkt definiert ist, weil es nur bei der Flanke von A definiert sein muss und zweitens glaube ich dass die Position des Rastpunktes in Bezug auf Signal B nicht definiert ist und nicht das Signal B im Rastpunkt. (Die Diagramme oder ich sind einfach blöd) <edit>Ich sehe gerade du hast noch was dazu geschrieben. Ja, der Zustand von B beim FLankeninterrupt von A Nochmal ja, IR Pins haben meist Schmitt Trigger Charakteristik
:
Bearbeitet durch User
Volker S. schrieb: > Es ist erstens völlig egal … und zweitens glaube ich … Sag ich ja, aber aus der Flankenwechsel-Interrupt-Fraktion kommen trotzdem keine Antworten. Und glauben tun wir in der Kirche, der Unterschied läuft auf das selbe hinaus, daher egal.
Torsten C. schrieb: > Sag ich ja, aber aus der Flankenwechsel-Interrupt-Fraktion kommen > trotzdem keine Antworten. Kannst du die Frage nochmal stellen ? Die Typen, die für jeden Rastpunkt einen Puls liefern mag ich sowieso lieber. Die sind im Ruhezustand immer aus und "verschwenden" keinen Strom. Flanken muss man auch nicht wechseln. Fallende Flanke A reicht völlig aus. <edit>btw: weil es mich auch interessiert hat und mein Englisch nicht so gut ist um den Hinweis im Datenblatt zweifelsfrei zu überstetzen, habe ich schon mal versucht zu analysieren wie das mit dem Rastpunkt und dem Zustand von Signal B bei so einem ominösen Teil ist. Da wackelte nichts. Vieleicht kann Walter T. ja noch mal ...
:
Bearbeitet durch User
Volker S. schrieb: > Kannst du die Frage nochmal stellen ? Rechtes Diagramm (EC11E/G/J) in https://www.mikrocontroller.net/attachment/262329/screenshot25.png oder https://www.mikrocontroller.net/attachment/262319/Durchklingeln2.png Signal A ist im Rastpunkt eindeutig, Signal B nicht. Ich hatte zwei Fragen an die Flankeninterrupt-Fraktion, zum besseren Verständnis: 1) Schaltet Ihr die Flanken-Interrups in der ISR immer zwischen steigend und fallend um? Oder reagiert der Interrupt immer auf beide Flanken und wertet Ihr dann den Pegel in der ISR aus? Hintergrund: Falls man den Pegel in der ISR auswertet, könnte er wegen des Prellens ja gerade zufällig 'falsch' sein, und die Pegel-Abfrage dauert zusätzlich Zeit. 2) Macht Ihr den Flankeninterrupt nur bei Signal A oder auch bei Signal B? Inzwischen klar: Nur bei Signal A. Frage: 2a) Wertet Ihr in der Signal-A-Flanken-Interrupt-Routine das Flankenwechsel-Flag von Signal B aus (wenn ja welches: Eins oder beide?), oder nur den Polling-Status? m.n. schrieb: > Hast Du mein Beispiel nicht gesehen …? 100e von Interpretationsmöglichkeiten. Dein Beispiel ist eher was für ein Telefonat als für ein Forum. "ja" oder "nein" wäre als Antwort einfacher, als …
:
Bearbeitet durch User
Torsten C. schrieb: > Dein Beispiel ist eher was für ein Telefonat als für ein Forum. > "ja" oder "nein" wäre als Antwort einfacher, als … Jetzt wird hier seit Tagen darüber diskutiert, wobei sich jeder einfach einmal ein kurzes Programm schreiben könnte, um selber seine Erfahrungen zu machen. Das ist doch Alles supersimpel! Aber nein, es ist ja viel einfacher seine Vorurteile zu pflegen - tagelang und immer wieder, wie bei Fußballvereinen und Fremdenfeindlichkeit. Torsten C. schrieb: > Flankenwechsel-Interrupt-Fraktion Geh mal davon aus, daß diese Fraktion beide Verfahren kennt und beherrscht und in der Lage ist, für den jeweiligen Anwendungsfall das Passende auszusuchen.
Torsten C. schrieb: > Die meisten MCUs haben Schmitt-Trigger-GPIOs > und ein Kondensator kommt ja schon durch die Leiterbahnen zustande. Das nützt nicht viel. Wenn du dir die Oszillogramme von oben nochmal anschaust, siehst du ja, was der Schmitt-Trigger dann sauber in high und low umwandelt, das ist bei einem prellenden Drehgeber immer noch nicht eindeutig. Du musst also auf Plausibilität prüfen. Ich habe das damals so gemacht, das ich etwa 30-mal hintereinander auf gleiche Polarität prüfte - wenn bestanden, dann Auswertung, wenn nicht bestanden, raus. Das klappt schon, aber man verschwendet dann doch so viel Zeit im Flankeninterrupt, das die Timer Routine wieder besser abschneidet. Der Kondensator hat bei einigermassen sauberer Leitungsführung ein paar pF bis ein paar dutzend pF, das reicht nicht. Unabhängig von Timer oder Flanke ist es aber eh empfehlenwert, ein wenig ESD Vorkehrung zu treiben, da es sich ja auch um Dreh-Benutzer mit Wollpullover handeln kann. Also wenn möglich, Drehgebergehäuse erden und RC Glieder in die Leitungen. Ich habe auch öfter mal einen Wegwerf-74HC14 in die Leitungen gesetzt, um den MC zu schützen.
Matthias S. schrieb: > Ich habe das damals > so gemacht, das ich etwa 30-mal hintereinander auf gleiche Polarität > prüfte - wenn bestanden, dann Auswertung, wenn nicht bestanden, raus. Wann, mit welchem Prozessor und wie programmiert? Wiederhole das doch noch einmal mit heutigen µCs und mit Deinen heutigen Erfahrungen. Soweit ich mitbekommen habe, setzt Du ja auch AVRs ein, wofür viele Beispiele (auch für Arduino Uno) vorhanden sind: Beitrag "Drehgeber per Interrupt auswerten, AVR" Wie gesagt, es ist supersimpel! Matthias S. schrieb: > Also wenn möglich, Drehgebergehäuse erden und RC Glieder in die > Leitungen. Wenn Du schon RC empfiehlst, mit 10 kOhm und 100 nF bekommst Du die Signaländerungen so langsam, daß man schon fast mit scharfem Hinsehen auswerten kann. RC ist auch immer wieder interessant. Wenn das Jemand für Drehgeber verwendet, wird wild gechimpft, daß das Alles viel zu aufwendig wäre. Falls hier Jemand nach dem Schutz von ADC-Eingängen fragt, wird man von Vorschlägen fast erschlagen, die eine Menge Rs und Cs und auch noch Schutzdioden vorsehen, obwohl Letztere schon im µC vorhanden sind. Immer so, wie es gerade in den Kram paßt.
m.n. schrieb: > Wann, mit welchem Prozessor und wie programmiert? Das fing etwa 1980 mit 6502 an, über Z80 und MCS51. Bei denen natürlich alles in ASM. Bei den ersten beiden war mangels Hardware ein Timer nicht drin, in den letzten MCS51 Projekten dann aber schon. m.n. schrieb: > Wenn das Jemand für Drehgeber > verwendet, wird wild gechimpft, daß das Alles viel zu aufwendig wäre. Nicht für mich. Leitungen, die direkt vom Benutzer in den MC gehen, sind mir suspekt und ich schütze da gerne ein wenig. Sind aber eher 10k und 470pF - 10nF. m.n. schrieb: > Soweit ich mitbekommen habe, setzt Du ja auch AVRs ein, > wofür viele Beispiele (auch für Arduino Uno) vorhanden sind: > Beitrag "Drehgeber per Interrupt auswerten, AVR" > Wie gesagt, es ist supersimpel! Mittlerweile ist da auch viel STM32 bei. Aber supersimpel finde ich mittlerweile die Timernummer. Wie ich oben schon schrieb, packe ich mittlerweile Buttons und Drehgeber in die gleiche Routine und frühstücke damit das ganze Benutzergedöns in einer Routine ab, die auch noch eine immer vorhersehbare Laufzeit hat.
:
Bearbeitet durch User
Matthias S. schrieb: > Das fing etwa 1980 mit 6502 an, KIM, AIM, ACORN? Oder gar PET oder Apple? Irgendwann gab es ja den 6532 mit RAM und Timer ;-) Matthias S. schrieb: > Leitungen, die direkt vom Benutzer in den MC gehen, sind > mir suspekt und ich schütze da gerne ein wenig. Sind aber eher 10k und > 470pF - 10nF. Full Ack, und sofern schnellere Signale im Spiel sind kommen MC1489 o.ä. dazwischen: Überspannungsschutz, Signalformer und bei Bedarf auch noch mit ESD-Schutz.
Volker S. schrieb: > <edit>btw: weil es mich auch interessiert hat und mein Englisch nicht so > gut ist um den Hinweis im Datenblatt zweifelsfrei zu überstetzen, habe > ich schon mal versucht zu analysieren wie das mit dem Rastpunkt und dem > Zustand von Signal B bei so einem ominösen Teil ist. Da wackelte nichts. > Vieleicht kann Walter T. ja noch mal ... Was ist die Frage? Welcher "Hinweis" im Datenblatt? Beim Panasonic-Encoder ist der Flankenwechsel von B im Verhältnis zu Rastpunkt nicht genau definiert. Was auch irgendwie sinnvoll ist: Wenn man bedenkt, daß das Teil für Automobil-Anwendungen gedacht ist und bei der üblichen Vibration im Fahrzeug auch mal gern um den Rastpunkt schwingen kann, wäre es fatal, wenn sich der Softwareentwickler auf ein irgendwie definiertes Verhalten von B im Rastpunkt verlassen würde.
:
Bearbeitet durch User
m.n. schrieb: > Oder gar PET oder Apple? Bei mir Apple ][. Ich hatte damals ein Projekt, um einen Videoschnittplatz mit der Kiste zu steuern, die aus mehreren Philips Zuspielern mit I²C und einem U-Matic Monster mit Parallelschnittstelle bestand. Der Apple wurde mit der Apple Maus und einem selbstgebauten Pult mit Drehgebern und Digitastern gesteuert. In zwei Slots steckten Karten mit 6522, die eine musste dutzende von Leitungen des U-Matic steuern und die andere machte I²C per Bitbanging. m.n. schrieb: > kommen MC1489 o.ä. > dazwischen Ich nehme die 74HC14, weil ich die säckeweise habe, aber es geht ja so gut wie alles, was einen Eingang und einen Ausgang hat.
Matthias S. schrieb: > Mittlerweile ist da auch viel STM32 bei. Na gut, aber im Grunde mußt Du ja nur die Hardware Deines 3-Phasen Frequenzumrichters nehmen: ein Display ist vorhanden und an INT0 ist ja schon C13 mit 2,2 nF vorhanden. Für die andere Drehgeberphase kannst Du einfach PD1 nehmen ;-)
Ach herrje.. ihr diskutiert ja immer noch! Torsten C. schrieb: > Signal A ist im Rastpunkt eindeutig, Signal B nicht. > Ich hatte zwei Fragen an die Flankeninterrupt-Fraktion, zum besseren > Verständnis: zu 1. (welche Flanken) Die allermeisten DG liefern einfach nur zwei um 90° +/-30° versetzte Signale. Eines von denen ändert sich in der Nähe des Rastpunktes. Das ist das Signal, was nur zur Richtungsermittlung in der ISR abgefragt wird. Nennen wir es hier mal "D": Das andere Signal ändert sich so etwa auf halber Strecke zwischen den Rastpunkten. Das ist das Signal, was die Flankeninterrupts auslöst. Und zwar auf beiden Flanken. Nennen wir es hier mal "I". Ich räume ein, daß es bei älteren µC schwierig war, den betreffenden Pin so einzurichten, daß er bei beiden Flankenwechseln einen Interrupt liefert. Vielleicht kommen daher die Bedenkenträger, die lieber pollen wollen. zu 2. (Auswertung) Beim Interrupt auf Flanke ist ja völlig klar, daß es eine Drehbewegung gegeben hat. Da bleibt in der ISR nur übrig, die Richtung festzustellen. Das macht man durch Abfragen des anderen Signals, was sich ja beim Rastpunkt ändert und demzufolge zum Zeitpunkt des Interrupts stabil ist. Dieses Signal ist ja quasi um (etwa) 90° vor- oder nachlaufend, so daß man die Richtung ganz einfach durch ein XOR beider Signale erhält. Also Richtung = I xor D; Das war's schon. Wie man sieht, braucht die Flankenmethode keinerlei gespeicherte Informationen über einen vorherigen Zustand. Die Pollingmethode hingegen benötigt diese Informationen, da sie ja sonst die Änderung des Zustandes nicht erkennen kann. W.S.
Günter Lenz schrieb: > Wenn ein Drehgeber das macht, was Volker SchK > in screenshot27.png zeigt, ist das meiner Meinung > nach Herstellerpfusch. Der Hersteller sollte schon > 90 grad Versatz anstreben, zu mindest 45 grad. > Rastpunkt auf einer Flanke ist nach meiner Meinung > auch Herstellerpfusch. Am besten man nimmt Drehgeber > die Optisch abgetastet werden, die haben keinen Verschleiß > und prellen nicht. Du vergißt die Handhabung des Ganzen. Also ich erkläre es dir mal im Detail: Einen DG mit Rastung drehen zu wollen bedeutet, daß man zunächst etwas Kraft aufwenden muß, um ihn aus seiner Rastung herauszubekommen. Nun ist der Mensch mit seinen Knochen aber keine Werkzeugmaschine, die man um einen gewünschten Winkel verstellt, sondern der menschliche Bewegungsapparat ist was eher elastisches. Deshalb ändert sich der Winkel des DG zunächst garnicht, bis deine Finger soviel Drehmoment aufgebaut haben, daß dies das Rastmoment übersteigt. Dann entspannt sich das Ganze aber mit nem Ruck, bis man in der nächsten Rastung landet. Deshalb ist die Drehgeschwindigkeit beim händischen Drehen zeitlich höchst unterschiedlich (eben ruckhaft) - was man mit einem Oszi, der mit konstanter Geschwindigkeit aufzeichnet, SO nicht wirklich sehen kann. Das Ganze ist deshalb eben kein Herstellerpfusch. Dieses Bild ist übrigens durchaus erhellend, die Pollingmethode betreffend: Es zeigt uns nämlich, daß bei gewöhnlicher händischer Betätigung der DG die meiste Zeit in der Nähe eines seiner Rastpunkte sich befindet und die Annahme, daß man ja bloß mit dem 4fachen der erwartbaren Rastpunktfrequenz zu pollen braucht, eben falsch ist. Stattdessen muß manmindestens mit der doppelten Frequenz pollen, die dem zeitlichen Versatz der im Bild sichtbaren blauen und gelben Kurve entspricht. Und das ist (geschätzt) weniger als 1/25 der Signalperiode. Wenn die Zahl von 34.1ms als Periodenlänge stimmt, dann müßte man mindestens alle 680µs pollen. W.S.
W.S. schrieb: > Deshalb ist die Drehgeschwindigkeit beim händischen Drehen zeitlich > höchst unterschiedlich (eben ruckhaft) - was man mit einem Oszi, der mit > konstanter Geschwindigkeit aufzeichnet, SO nicht wirklich sehen kann. Die eben nicht konstante Drehgeschwindigkeit ist ja auch nicht interessant, sondern nur das was auch der uC sozusagen "sieht" und das ist nun mal das Signal, wie es am Oszi angezeigt wird. (Was dir und mir vermutlich eh klar ist ;-) Wie man das dann auswertet, über Polling oder IR, kann man immer noch in jedem Einzellfall individuell entscheiden ... (Individualismus ist für die Poller anscheinend ein böööööses Wort;-)
:
Bearbeitet durch User
Volker S. schrieb: > Individualismus ist für die Poller anscheinend ein böööööses Wort;-) Poller stehen oft auch nur sinnlos auf Radwegen herum. ;-) mfG Paul
Am einfachsten wäre es, wenn beide Fraktionen sich aus Diskussionen der jeweils anderen Fraktion raushalten. Aber das wäre dann so, wie wenn man C++ Fragen diskutiert und Moby und c-hater halten sich raus. Also unmöglich!
Walter T. schrieb: > Volker S. schrieb: >> <edit>btw: weil es mich auch interessiert hat und mein Englisch nicht so >> gut ist um den Hinweis im Datenblatt zweifelsfrei zu überstetzen, habe >> ich schon mal versucht zu analysieren wie das mit dem Rastpunkt und dem >> Zustand von Signal B bei so einem ominösen Teil ist. Da wackelte nichts. >> Vieleicht kann Walter T. ja noch mal ... > > Was ist die Frage? Welcher "Hinweis" im Datenblatt? > > Beim Panasonic-Encoder ist der Flankenwechsel von B im Verhältnis zu > Rastpunkt nicht genau definiert. Genau das ist die Frage. Was bedeutet der Hinweis im Datenblatt "The stable detent position cannot be identified in phase B" Ich würde es so auslegen wie du. Torsten C. eher anders: Torsten C. schrieb: > Bezogen auf das rechte Diagramm in 'screenshot25.png', wo das Signal B > im Rastpunkt unbestimmt ist: Man könnte jetzt natürlich wieder sagen, dass das beides auf selbe hinaus laufen könnte ;-)
Bastler schrieb: > Am einfachsten wäre es, wenn beide Fraktionen sich aus Diskussionen der > jeweils anderen Fraktion raushalten. Ja das wäre vermutlich das Beste für diejenigen, die hier fragen, weil sie sich erst mal klar werden müssen, was die Drehgeber überhaupt für Signale liefern und dann irgendwann später entscheiden müssen wie diese Signale im Einzelfall am besten ausgewertet werden ... Bastler schrieb: > Aber das wäre dann so, wie wenn man > C++ Fragen diskutiert und Moby und c-hater halten sich raus. Also > unmöglich! Ja ;-) Bestimmt ist mal das eine von Vorteil, mal das andere und oft genug wahrscheinlich scheiß egal.
:
Bearbeitet durch User
m.n. schrieb: > Na gut, aber im Grunde mußt Du ja nur die Hardware Deines 3-Phasen > Frequenzumrichters nehmen: Der FU benutzt allerdings eine völlige andere Eingabe Strategie. Hier wird nur zyklisch (aus der Hauptschleife) die Eingabetastenroutine aufgerufen und Drehgeber gibts hier gar nicht. Interrupts (gar PCINT oder Ext. Int) sind tabu, weil die Erzeugung der Phasen immer oberste Priorität haben muss und die Priorität der ISR im AVR festgelegt ist. Ein Motor darf ja nicht ruckeln, nur weil mal jemand am Rad dreht :-) Übrigens würde auch in diesem Projekt ein gepollter Drehgeber mit abfallen, wenn man es an die zentrale Timerroutine anhängen würde.
Matthias S. schrieb: > Der FU benutzt allerdings eine völlige andere Eingabe Strategie. Die Du hier völlig ignorieren solltest, genauso wie den Motor und alles Andere auch! Ich meinte lediglich, daß Du ohne große Lötarbeit Dein Stück Hardware nehmen könntest, um die generelle Funktion des gezeigten Programmes (Drehgeber per Interrupt auswerten) zu testen und auf dem LCD anzeigen zu lassen. Danach könntest Du in der Lage sein, Deine alten Vorurteile abzulegen. Egal, was Du machst, ein "ja aber" möchte ich dann nicht mehr hören! Bastler schrieb: > Am einfachsten wäre es, wenn beide Fraktionen sich aus Diskussionen der > jeweils anderen Fraktion raushalten. Im Grunde würde es schon reichen, wenn sich dieser armselige Hassprediger fernhalten würde. Dann könnte man viel sachlicher diskutieren.
m.n. schrieb: > Danach könntest Du in der Lage sein, Deine alten Vorurteile > abzulegen. Brauche ich doch gar nicht. Gerade ich gehöre zur Fraktion derer, die das alles schon hinter sich haben und ihre Vorurteile immer wieder hinterfragt haben. Ich bleibe also von nun an beim timergesteuerten Polling.
Matthias S. schrieb: > Ich bleibe also von nun an beim timergesteuerten > Polling. Immer und in jedem Fall ? Du kennst doch bestimmt noch diese Quartett Kartenspiele ? Du weist schon, die man nie als Quartett spielt, sondern immer irgendwelche Werte vergleicht und wer "besser" ist gewinnt den Stich. Ein Flugzeugträger gewinnt da bestimmt immer gegen "Hüpfen" ;-) Aber ist ein Flugzeugträger in der Realität WIRKLICH so gut geeignet einen 50cm breiten Bach zu überqueren ?
Genau! Und deshalb hüpft man über den kleinen Bach oder polkt den Drehgeber zur Menübedienung. Der Flugzeugträger wäre hier der optische Winkelencoder mit 500kHz.
Matthias S. schrieb: > Gerade ich gehöre zur Fraktion derer, die > das alles schon hinter sich haben Und dann schreibst Du: Matthias S. schrieb: > Ich habe das damals > so gemacht, das ich etwa 30-mal hintereinander auf gleiche Polarität was mir eigentlich sagt, daß Du auf diesem Gebiet unerfahren warst und wohl auch geblieben bist. Auch stolpere ich darüber, daß Du Deine Polling-Routinen nicht selber geschrieben hast, sondern dafür eine ext. Quelle brauchtest. Für mich Alles ein Zeichen, daß Du Dich durchaus nicht zurücklehnen solltest und Deine Rentenpunkte zählen kannst!
Warum sollte man auch alles neu erfinden wollen. Mit der Einstellung sollte man Keim Forum besuchen, denn da geht es um Gedanken-AUSTAUSCH und nicht ums Predigen der einen, heiligen Wahrheit. PS.: Ich habe weder mein BS, noch meinen Browser, noch ... selbst geschrieben, noch fühle ich mich schlecht dabei, Dinge zu benutzen, die Andere erfunden haben.
m.n. schrieb: > Auch stolpere ich darüber, daß Du Deine Polling-Routinen nicht selber > geschrieben hast, sondern dafür eine ext. Quelle brauchtest. Ach - ob du es glaubst oder nicht, ich benutze sogar MC und Prozessoren, die ich von Zulieferern beziehe. Ich lese auch Bücher, die ich nicht selber geschrieben habe und spiele eine Gitarre aus den USA. Das ist doch ein albernes Argument, vermutlich, weil dir die brauchbaren gerade ausgegangen sind. Warum soll ich denn das Rad neu erfinden, wenn ich die Routinen gut verstehe und problemlos auf jeder Plattform benutzen kann?
Womöglich hast du auch die ECC83 im deinem Bass-Verstärker nicht selbst mundgeblasen? Unfaßbar ;-))
Hallo, ich bin wieder da;-) Lese mit Interesse Eure diskussion. Ich möchte mal das Subjekt der Diskussion von einer neuen Seite beleuchten. In vielen uC Anwendungen braucht man zur zeitlichen Ablaufsteuerung des eigentlichen Anwendungsprogramm sowieso oft eine Timer ISR im ms Bereich. Da feststeht, dass Polling durchaus für mechanische DG gut genug funktioniert, macht es also nicht viel aus wenn man die DG Abfrage mit in die schon vorhandene ISR mitintegriert. Die armseligen paar CPU Zyklen dazu macht der uC doch lässig mit und ist bei den vielen MIPS der neuzeitlichen uC doch meist vernachlässigbar. Wenn im Programm allerdings keine langsame Ablaufsteuerung vorhanden ist dann hätte das besprochene DG Interrupt Verfahren durchaus Vorteile, solange durch entsprechende Beschaltung oder algorithmischen Kunstwerk sichergestellt wird dass Kontaktprellungen sich nicht mehr negativ auswirken können. ESD Vorkehrungen und Schutz/Filtern der (ISR) uC Eingänge sind selbstverständlich Stand der Technik im professionellen Bereich und brauchen auch hier auch gar nicht mehr erwähnt zu werden. Wenn man sich gut mit der Materie auskennt kommt man auch auf beiden Wegen zum Ziel. Mfg, Gerhard
m.n. schrieb: > Jetzt wird hier seit Tagen darüber diskutiert, wobei sich jeder einfach > einmal ein kurzes Programm schreiben könnte, um selber seine Erfahrungen > zu machen. Das ist doch Alles supersimpel! Welche Erfahrung soll er machen ? Daß es mit Polling immer geht, wenn man ausreichend schnell abtastet, und mit Flankeninterrupt nur manchmal, so dass es für zuverlässigen Betrieb notwendig wird externe Zusatzhardware zu ergänzen. Blöde Erfahrung, dann doch lieber gleich die richtige Methode nehmen statt ewig an falschem herumzudoktorn wie du.
Nur daß es eben 2 Ziele gibt und zu jedem gibt es einen besten Weg. Nur wenn man die "2" nicht verstanden hat, muß man über den Weg diskutieren.
Bastler schrieb: > Womöglich hast du auch die ECC83 im deinem Bass-Verstärker nicht selbst > mundgeblasen? Unfaßbar ;-)) [OT]Ich habe sie sogar mittlerweile rausgeschmissen und durch einen selektierten FET mit Spannungsfolger ersetzt. Selektiert habe ich aber selber, nur der FET ist von Toshiba :-) [/OT]
[ot] welcher genau? Und wie erträgst du das Wegeschrei der kalten Elektronen?[/ot]
Hab ich das Ironie-Icon vergessen? ;-)) Das war eine Anspielung darauf, daß Matthias früher Verfechter heißer Elektronen in leeren Glaskörpern war. Ich hab schon vor 33 Jahren erlebt, wie die Kinnlade eines Vollröhrenbesitzers runterklappt, wenn er gut gemachtes Silizium hört. Gut es lag auch an meiner Gitarre. War viel billiger als seine, aber hatte Humbucker ohne Deckel. Bis ich allerdings verstanden hatte, warum das so klang, sind noch etliche Jahre vergangen.
Bastler schrieb: > Hab ich das Ironie-Icon vergessen? ;-)) Ich fand das mit den Elektronen nur so komisch von Dir und das kam mir dann in den Sinn. Ich habe das schon so verstanden wie Du gemeint hattest. Also nichts für ungut. mfg, Gerhard P.S. [ot]?
:
Bearbeitet durch User
Bastler schrieb: > Warum sollte man auch alles neu erfinden wollen. Muß man nicht, aber der Bedarf an guten Entprellroutinen bestand schon deutlich früher bevor es dieses Forum gab. Und die Chance, daß Herwig Feichtinger etwas Passendes in der MC schrieb, waren auch nicht so groß ;-) Folglich war man seinerzeit auf eigene Routinen angewiesen, wenn man sich heute als alter Hase sehen möchte.
Gerhard O. schrieb: > Die armseligen paar CPU > Zyklen dazu macht der uC doch lässig mit und ist bei den vielen MIPS der > neuzeitlichen uC doch meist vernachlässigbar. Du setzt stillschweigend ein paar Randbedingungen voraus, die praktisch nicht gegeben sind. Die erste ist, daß der angedachte µC so reichlich Zeit und so wenig zu tun hat, daß man seine Rechenzeit verschwenden kann. Gilt nicht wirklich immer. Die zweite ist, daß ein Uhr-Interrupt eine höhere Priorität haben müßte als andere Interrupts, was regelmäßig NICHT der Fall ist bei allen µC, die als Device am USB hängen oder die irgendwelche I2S-Daten streamen und auch noch verarbeiten müssen (Filtern etc, eben alles was man mit simpler DMA nicht machen kann) Die dritte ist, daß es häufig genug Fälle gibt, wo man Strom sparen will/muß und deshalb im Idle-Fall den Takt herunter dreht oder gar den µC schlafen legt. Dort im 700µs - Takt zu pollen, bloß weil man zu dämlich ist, den einen Schleifkontakt per RC zu entprellen, ist albern und nicht zielführend. W.S.
W.S. schrieb: > Du setzt stillschweigend ein paar Randbedingungen voraus, die praktisch > nicht gegeben sind. Deine Argumente sind 100% stichhaltig und unterstreichen dass jedes Design zugeschnittene Lösungen verlangt. Man darf also nicht alles sozusagen über einen Kamm scheren wie es hier so oft geschieht. Das ist schon klar. Gruss, Gerhard
W.S. schrieb: > Die zweite ist, daß ein Uhr-Interrupt eine höhere Priorität haben müßte > als andere Interrupts, was regelmäßig NICHT der Fall ist bei allen µC Aber ein Pinchange Interrupt hat regelmäßig immer höhere Priorität? Das ist gut, denn dann klappt auch das Abfragen des Pegels problemlos. > Die erste ist, daß der angedachte µC so reichlich Zeit und so wenig zu > tun hat, daß man seine Rechenzeit verschwenden kann. Wenn der uC so knapp auf Kante genäht ist, dass er diese "Reserve" nicht hat, passt (eigentlich) auch kein Interrupt mehr "dazwischen". Nur merkt man das nicht sofort, sondern nur ab&zu bei seltsamem Verhalten.
Die bekannten (AVR) Heizkörperthermostate lösen das Tasten-Problem so: Tief schlafen, erster Tasten-Druck weckt per PinChange, dann Pollen aktivieren (und PinChange aus), wenn lange genug nichts passiert ist, Pollen aus (PinChange wieder ein) und Tiefschlaf. Nur alle Sekunde per async-Timer2 aufwachen um Uhr nachzustellen, jede Minute messen und regeln. Bei Bedarf Ventil bewegen. Manchmal gibt es also nicht nur eine an die Anwendung angepaßte Lösung, sondern zeitabhängig gleich 2. Wenn nur PinChange das beste wäre, dann hätte man die Dinger sicher genau so gebaut.
W.S. schrieb: > Die erste ist, daß der angedachte µC so reichlich Zeit und so wenig zu > tun hat, daß man seine Rechenzeit verschwenden kann. Gilt nicht wirklich > immer. Es kommt letzten Endes wirklich auf die Anwendung an. Wenn man nicht gerade sehr CPU-Zyklen intensive Programme bauen muß (z.B. Soft MP3, Video, WS2811 LED Treiber u.ae.), laufen doch mehr uC Programme wie man denkt praktisch doch eigentlich fast im Leerlauf und warten auf irgendwelche Stimuli von der Hardware oder dem User, externe Kommunikation, usw. und verbrennen CPU Zyklen. Zumindest ist das bei den meisten Projekten von mir bis auf ein paar seltene Ausnahmen der Fall. Da hat man dann schon einen gewissen Spielraum um den "bequemen" Weg zu gehen. Jede Anwendung hat individuelle Gesichtspunkte und man findet ja schnell genug heraus inwieweit man die Möglichkeiten ausschöpfen muß. uC Programme verhalten sich oft wie im wirklichen Leben ähnlich wie gewisse Autofahrer die mit großer Geschwindigkeit bei einer roten Ampel bremsen müssen um dann wenn es wieder grün wird, wie verrückt aufs Gas zu steigen um das Spiel dann bei der nächsten Kreuzung zu wiederholen. Das bringt nicht viel. Viele Programme scheinen artverwandt strukturiert zu sein. Da hat man einen CPU mit vielen MIPS und man steigt regelmäßig auf die Bremse um auf irgend etwas Wichtiges zu warten. mfg, Gerhard
:
Bearbeitet durch User
Bastler schrieb: > Manchmal gibt es also nicht nur eine an die Anwendung angepaßte Lösung, > sondern zeitabhängig gleich 2. Wenn man das so bei einem Drehgeber macht, würde ich nicht zustimmen. Das ist für mich wie ein Auto mit zwei Schlüsseln: einer zum Türöffnen und einer zum Starten. Mein Auto braucht nur einen Schlüssel :-) > Wenn nur PinChange das beste wäre, dann > hätte man die Dinger sicher genau so gebaut. Nur, weil jemand das kommerziell so ausführt, muß es noch lange nicht das gelbe vom Ei sein. Dabei denke ich an den Timer meines Küchenherdes (Bosch); da hat man ja nicht einmal das Pollen auf die Reihe bekommen. Bei wenigen Tasten (4-5), die zudem nicht auf der Platine direkt sitzen, würde ich beim Interrupt bleiben, wobei der µC den Kondensator am Eingang aktiv läd bzw. entläd, um die max. RC-Verzögerungszeit unter allen Umständen sicherzustellen. Ein Beispiel wäre ein "Fahrrad-Computer" mit zwei Tasten und einem Impulsgeber. Gerhard O. schrieb: > Es kommt letzten Endes wirklich auf die Anwendung an. Volle Zustimmung!
Walter T. schrieb: > Dr. Walter Tarpan > Lehrstuhl für Bedienelementesinologie > TU Osnabrück hier der fehlende Bezug ....
Walter T. schrieb: > Ein Witz wird nicht dadurch besser, daß man ihn erklärt. Du könntest aber erklären WO der Witz vorkam. Manch Einer fand ihn auch nach intensiver Suche nicht.
Naja, wer einen Witz nicht wahrnimmt, hat auch nicht das Gefühl, etwas verpaßt zu haben. vloki schrieb: > [...] Ihr seid mir schon'n paar feine Theoretiker. Bestimmt von der Uni ;-) Walter T. schrieb: > [...] Aber vielleicht liegt es > daran, daß ich tatsächlich von der Uni bin. > > Viele Grüße > W.T. > > -- > > Dr. Walter Tarpan > Lehrstuhl für Bedienelementesinologie > TU Osnabrück
Walter T. schrieb: > Naja, wer einen Witz nicht wahrnimmt, hat auch nicht das Gefühl, etwas > verpaßt zu haben. Jetzt habe ich es gefunden: Du bist gar nicht im Personenverzeichnis der Uni Osnabrück enthalten: http://www.uni-osnabrueck.de/universitaet/personensuche.html?id=&command=starting_with&search_key=T Das ist natürlich so wahnsinnig lustig, da werden meine Enkel noch drüber lachen müssen... :-(((
Kai M. schrieb: > Du bist gar nicht im Personenverzeichnis der > Uni Osnabrück enthalten: Das ist ja auch das Personalverzeichnis der Uni Osnabrück, nicht der TU. Kai M. schrieb: > Das ist natürlich so wahnsinnig lustig, da werden meine Enkel noch > drüber lachen müssen... Nicht jeder muß über einen unschuldigen Scherz lachen- aber breittreten ist schröcklich. Vielleicht sollte man den Teil ab hier: Beitrag "Re: Drehimpulsgeber" inklisive dieses Beitrags einfach wieder löschen - er trägt nichts zum Thema Drehgeber bei.
:
Bearbeitet durch User
Walter T. schrieb: > Vielleicht sollte man den Teil ab hier: > > Beitrag "Re: Drehimpulsgeber" > > einfach wieder löschen - er trägt nichts zum Thema Drehgeber bei. Vollkommen einverstanden.
m.n. schrieb: > Wenn man das so bei einem Drehgeber macht, würde ich nicht zustimmen. > Das ist für mich wie ein Auto mit zwei Schlüsseln: einer zum Türöffnen > und einer zum Starten. Mein Auto braucht nur einen Schlüssel :-) Wenn ich ein Wohnmobil hätte, fände ich's schon praktisch, wenn ich meine Kinder den Schlüssel geben könnte um was rauszuholen, ohne Angst haben zu müssen, das sie damit lostuckern. Nur so als Beispiel :)
Lothar M. schrieb: > W.S. schrieb: >> Die zweite ist, daß ein Uhr-Interrupt eine höhere Priorität haben müßte >> als andere Interrupts, was regelmäßig NICHT der Fall ist bei allen µC > Aber ein Pinchange Interrupt hat regelmäßig immer höhere Priorität? Das > ist gut, denn dann klappt auch das Abfragen des Pegels problemlos. Wo lebst du? OK, wir können hier weiter über Drehknopf-Chinakunde schwafeln - was vielleicht vergnüglicher ist, als sich mit uneinsichtigen Pollern abzugeben - aber es lesen eventuell auch unerfahrene Neulinge mit, die hier keinen solchen Mumpitz lesen sollten. In den hier üblichen Szenen ist es so, daß man die Prioritäten so vergibt, daß das System insgesamt richtig läuft. Und da ist der Systemtick so ziemlich das Letzte, was es so an Interrupts gibt. Ein Pinchange-Interrupt hat also nur dann nen Vorrang über den Systemtick, wenn man ihn dafür einrichtet - und jetzt kommt es darauf an, wie unterbrechungsempfindlich andere Interrupts sind. Er kann der Pinchange also durchaus die höchste Priorität (mal abgesehen von NMI, Faults etc.) haben - wenn er nur saukurz ist. Der entscheidende Punkt ist, daß der Pinchange-Interrupt per Hardware genau zum richtigen Zeitpunkt kommt, also das vor- oder nacheilende Richtungssignal noch stabil ist. Du hast es ja weiter oben gelesen, daß genau dieses in der Nähe des Rastpunktes umschaltet und damit aufgrund der ruckartigen Bewegung die meiste Zeit tatsächlich instabil ist. W.S.
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.