Guten Tag,
Ich habe mir letzte Woche ein paar Rotary Encoder mit eingebaut Taster
gekauft. Und wollte ich sie gerne in mein aktuellen Projekt verwenden.
Da ich dieses aber noch nicht genutzt habe bin ich neu auf diesen
Gebiet.
Im Internet habe ich schnell ein simplen Code gefunden der eine Zahl
inkrementiert oder dekrementiert. Je nachdem in welche Richtung man denn
Encoder dreht. Der Code war Ursprünglich für die Arduino IDE gedacht. Da
ich aber damit nicht arbeite. Habe ich diesen Code umgeschrieben damit
ich ihn nutzten kann.
Der Code an sich funktioniert auch. Wenn ich den Encoder nach Rechtes
drehe, dann wird der Counter + 1 gezählt. Wenn ich nach linkes drehe
dann Counter - 1. Wenn ich aber dann Encoder ganz langsam drehe. Ohne
das er wieder "einrastet" dann macht der Counter komische Sprünge.
Beispiel:
0
1
0
1
Liegt das dann dem langsamen drehen? Wenn man "normal" dreht das selbst
wider einrastet dann funktioniert das zählen problemlos.
Hier mal der Code:
1
if(PIND & (1<<encoder0PinA)) n = 1; else n = 0;
2
3
if((encoder0PinALast == 0) && (n == 1)) {
4
if((PIND & (1<<encoder0PinB)) == 0) {
5
encoder0Pos--;
6
}else{
7
encoder0Pos++;
8
}
9
sprintf(buffer, "%d\r\n", encoder0Pos);
10
sendToSerial(buffer);
11
}
12
encoder0PinALast = n;
n und encoder0PinALast sind als 0 festgelegt.
encoderPinA ist Pin 3 des Port D Registers. Pin B ist Pin 2 des Port D
Registers. Die beiden Pins sind als Input Konfiguriert. Keine Internen
Pullups!
Ein Bild wie der Encoder verkabelt ist, ist angehängt.
Lg Felix.
Felix N. schrieb:> Im Internet habe ich schnell ein simplen Code gefunden
Spitze.
Es gibt immer Lösungen, die einfach erscheinen aber falsch sind.
http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.29
R1, R4, C1, C2 sind bei der richtigen Lösung überflüssig und bremsen
daher auch nicht wie sonst die maximale Rotationsgeschwindigkeit.
Felix N. schrieb:> Ohne> das er wieder "einrastet" dann macht der Counter komische Sprünge.>> Beispiel:> ...> Liegt das dann dem langsamen drehen?
Das liegt da dran, das du auf der "Kante" rumeierst. Falls dich das
stört, könntest du eine Hysterese in der Software einbauen.
huster schrieb:> Hier ist die Antwort auf Deine Frage:> https://www.mikrocontroller.net/articles/DrehgeberDieter F. schrieb:> huster schrieb:>> Hier ist die Antwort auf Deine Frage:>> https://www.mikrocontroller.net/articles/Drehgeber>> Nimm es und versuche das Prinzip zu verstehen.
Ah. Sollte beim nächsten mal wohl doch erst die Suchfunktion nutzten...
Ich habe mir die Seite mal durchgelesen. Und denn Soliden Code von der
Seite zum Testen übernommen. Ich weiß jetzt das ich ein Decoder mit 4
Schritten habe. Das Problem mit den komischen Sprüngen ist nun weg.
Nur ist jetzt meine Verkablung noch richtig? Oder kann/muss da was weg?
Lg Felix.
Felix N. schrieb:> Ich weiß jetzt das ich ein Decoder mit 4 Schritten habe.
Den Decoder kannst du doch programmieren, wie du möchtest.
Die Drehgeber liefern immer das gleiche AB-Signal, unterscheiden sich
aber in der Lage und Dichte der Rasten (so denn vorhanden)
Wolfgang schrieb:> Den Decoder kannst du doch programmieren, wie du möchtest.> Die Drehgeber liefern immer das gleiche AB-Signal, unterscheiden sich> aber in der Lage und Dichte der Rasten (so denn vorhanden)
Okay. Wusste ich nicht.
Ich habe halt gemerkt das wenn ich die Funktionen durchgehe das bei
read1
0
4
kam bei read2
0
2
und bei read4
0
1
Lg Felix.
Felix N. schrieb:> Nur ist jetzt meine Verkablung noch richtig? Oder kann/muss da was weg?
Siehst Du in PeDa's Beispielen irgendwelche Widerstände, Kondensatoren
etc.
Wenn nicht, würde ich diese als "nicht relevant" bezeichnen :-)
Michael B. schrieb:> R1, R4, C1, C2 sind bei der richtigen Lösung überflüssig und bremsen> daher auch nicht wie sonst die maximale Rotationsgeschwindigkeit.
Bei ihm ist Tau=10k Ohm * 10nF = 0,1ms
Er könnte auch 100k Ohm und 10nF als Tiefpass nutzen oder 1MOhm und 1nF
bis 10nF.
Stefan U. schrieb:> Ich denke auch, daß die Zeitkonstante deiner Entprellung VIEL zu> kurz ist. 30-100 mal mehr wäre angemessen. Ich hätte 100nF und 47k Ohm> verwendet.
Man muss übethaupt nicht entprellen, wenn man das richtige Programm
nimmt, aber manche machen es auf biegen und brechen falsch.
Hi
MaWin schrieb:> Man muss übethaupt nicht entprellen, wenn man das richtige Programm> nimmt, aber manche machen es auf biegen und brechen falsch.
Das wir aber nicht zeigen - hahaha - Pech gehabt :)
(oder wie darf ich Deinen Post interpretieren?)
MfG
MaWin schrieb:> Man muss übethaupt nicht entprellen
Das mag sein. Aber ich brauch doch eine minimal Beschaltung um überhaupt
die beiden Flanken zu haben. Also 5V High und 0V GND.
Oder nicht? Also mindestens 1 Widerstand und Kondensator für einen Pin,
oder nicht?
Lg felix
batman schrieb:> Nein, du kannst den Encoder direkt an Eingangsports mit internem Pullup> anschließen. Die Spannungsflanken entstehen durch den Stromfluß im> Pullup.
Also, einfach interne Pullup aktivieren. Was ist denn besser extern oder
intern?
Meine Taster betreibe ich immer mit interne Pullup und denn Taster gegen
GND.
Lg Felix.
Felix N. schrieb:> Meine Taster betreibe ich immer mit interne Pullup und denn Taster gegen> GND.
Dein Drehgeber ist doch für die Eingänge das Gleiche wie 2 Taster.
Felix N. schrieb:> Oder nicht? Also mindestens 1 Widerstand und Kondensator für einen Pin,> oder nicht?
Lass doch mal den Sch..ß-Kondensator weg. Schalte den Pull-Up vom
µC-Eingang an und, falls du nicht kilometerlange Leitungen an dem
Drehgeber hast, ist es damit gut.
MaWin schrieb:> Man muss übethaupt nicht entprellen, wenn man das richtige Programm> nimmt, aber manche machen es auf biegen und brechen falsch.
Das Problem was ich darin sehe ist dass diese Taster ihre
Prelleigenschaftenmit der Zeit verändern und das Programm dann teilweise
nicht mehr so optimal funktioniert.
Eigentlich funktioniert das mit der Software-Entprellung sehr gut, aber
nicht wenn man eine maximale Prellzeit annimmt die "gerade so" ausreicht
wenn der Taster oder Drehgeber noch neu ist.
Weder Soft- noch Hardwareentprellung beim Encoder. Es ist funktional
kein Taster, sondern ein Positionsgeber. D.h. man will nicht die Anzahl
oder Länge von Tastendrücken, sondern die Position.
Michael B. schrieb:> R1, R4, C1, C2 sind bei der richtigen Lösung überflüssig und bremsen> daher auch nicht wie sonst die maximale Rotationsgeschwindigkeit.
Nur so zur Ergänzung, die Beschaltung im ersten Post kommt nicht von
ungefähr:
Wenn man sich das Datenblatt des typischen Alps EC12E ansieht, z.B.
hier:
http://cdn-reichelt.de/documents/datenblatt/F100/402097STEC12E08.PDF
dann sieht man, dass genau diese Verschaltung vorgeschlagen wird:
"At design of the pulse count process, useing the C/R filter circuit as
bellow is recommended" (sic!)
Ob das nun unbedingt notwendig ist oder nicht, ist eine andere Sache,
aber aus der Luft gefallen ist die Beschaltung nun eben nicht...
Mike J. schrieb:> Das Problem was ich darin sehe ist dass diese Taster ihre> Prelleigenschaftenmit der Zeit verändern und das Programm dann teilweise> nicht mehr so optimal funktioniert.
Ich habe PeDas Drehgeber Routine zum Probieren schon mit übelsten
vergammelten Drehgebern aus uralten Autoradios getestet und selbst die
machen null Probleme. Die einzigen, die immer mal wieder Spass machen,
sind die, die genau auf dem Rastpunkt umschalten. Diese muss man dann
als 4er statt als 2er Geber abfragen.
Tobias S. schrieb:> Michael B. schrieb:>> R1, R4, C1, C2 sind bei der richtigen Lösung überflüssig und bremsen>> daher auch nicht wie sonst die maximale Rotationsgeschwindigkeit.>> Nur so zur Ergänzung, die Beschaltung im ersten Post kommt nicht von> ungefähr:> Wenn man sich das Datenblatt des typischen Alps EC12E ansieht, z.B.> hier:> http://cdn-reichelt.de/documents/datenblatt/F100/4...> dann sieht man, dass genau diese Verschaltung vorgeschlagen wird:> "At design of the pulse count process, useing the C/R filter circuit as> bellow is recommended" (sic!)>> Ob das nun unbedingt notwendig ist oder nicht, ist eine andere Sache,> aber aus der Luft gefallen ist die Beschaltung nun eben nicht...
Genau, "At design of the pulse count process,". Zum reinen Pulszählen
wäre das nötig oder/und wenn per IRQ gelesen wird. Hier macht man aber
eine Auswertung als (4-Phasen-)Positionsgeber bzw. Gray-Code und mit
diesem zusätzlichen kleinen Softwareaufwand spart man sich eben den
Hardwareaufwand.
Matthias S. schrieb:> Ich habe PeDas Drehgeber Routine zum Probieren schon mit übelsten> vergammelten Drehgebern aus uralten Autoradios getestet und selbst die> machen null Probleme. Die einzigen, die immer mal wieder Spass machen,> sind die, die genau auf dem Rastpunkt umschalten. Diese muss man dann> als 4er statt als 2er Geber abfragen.
dito, ich hatte mich auch gewundert, aber als 4er läuft er mit PeDas
Sourcen prima!
batman schrieb:> Genau, "At design of the pulse count process,". Zum reinen Pulszählen> wäre das nötig oder/und wenn per IRQ gelesen wird. Hier macht man aber> eine Auswertung als (4-Phasen-)Positionsgeber bzw. Gray-Code und mit> diesem zusätzlichen kleinen Softwareaufwand spart man sich eben den> Hardwareaufwand.
So ist es. Habe auch mal lange geübt und hatte am Schluss dann aber eine
sehr einfache Lösung ganz ohne externe Komponenten und die Firmware
ebenfalls sehr einfach. Es funktionierte dann immer zuverlässig, egal
mit welcher Geschwindigkeit am Drehgeber hantiert wurde.
Aber schlechte Implementationen habe ich leider auch schon zuhauf in
teuren Geräten wie z.B. Signalgeneratoren von Keysight und Oszilloskopen
gesehen.
Matthias S. schrieb:> Die einzigen, die immer mal wieder Spass machen,> sind die, die genau auf dem Rastpunkt umschalten.
Dann hast du die beiden Kontakte vertauscht.
Normal ist bei einfachen DG, daß ein Kontakt direkt im Rastpunkt
umschaltet und der andere genau zwischen den Rastpunkten. Den letzteren
benutzt man zum Erkennen, daß überhaupt eine Drehbewegung stattfand,
also für das Auslösen des Interrupts (bis auf MaWin natürlich). Den
anderen, der im Rastpunkt umschaltet, benutzt man zum Erkennen der
Richtung. Eigentlich ganz einfach. Jaja, es gibt auch DG, wo der
Rastpunkt außerhalb beider Umschaltpunkte liegt.
Und zum Gezänk um die Außenbeschaltung: Die beiden Hochzieher sind
nötig. Basta - und warum? Weil man sie relativ niederohmig machen kann
(2k2 .. 4k7) und weil sie damit die immer zum Verrotten neigenden
Kontakte frei-brutzeln. Wer sich gern Störungen einfangen will, der kann
natürlich auch die chipinternen Pullups benutzen. Geht - aber dauerhaft
nur bei ganz kurzen Leitungen. Die Kondensatoren gegen Masse sollte man
drin haben, 10..22nF sind OK so. Eigentlich braucht man den Kondensator
nur bei einem Kontakt, nämlich bei demjenigen, der den Interrupt (wieder
ohne MaWin) auslöst, also den Drehvorgang anzeigt. Der Kontakt für die
Richtung braucht nicht entprellt zu werden.
Aber R1 und R4 in der obigen Schaltung sollte man rausschmeißen.
Nochwas zum "Software-Entprellen": Manche Chips (z.B. Kinetis) haben ne
Hardware-Entprellung in der Chiplogik. Sowas kann man benutzen, aber
eine reine Software-Entprellung ist albern, denn sie bedeutet nen
unnötig großen Aufwand durch übertrieben hohe Samplingrate für so einen
DG, der mit 1..2 billigen Kondensatoren mindestens genauso gut bedient
ist.
W.S.
Entprellung mit Kondensatoren vereinfach die Software mitunter
erheblich, kostet aber zusätzliche Bauteile.
Anhand der Fragen schätze ich, daß der TO mit Entprellung per Software
vorläufig überfordert ist, daher rate auch ich zu Kondensatoren.
Falls es eine Massenproduktion werden soll, sollte man die zusätzichen
Kosten durch die Bauteile im Auge behalten.
Mike J. schrieb:> Das Problem was ich darin sehe ist dass diese Taster ihre> Prelleigenschaftenmit der Zeit verändern und das Programm dann teilweise> nicht mehr so optimal funktioniert.
Du hast den Gray-Code nicht verstanden. Da der Hamming-Abstand der
Codeworte genau 1 beträgt, entstehen durch ewaiges Prellen keine
Zählfehler.
Matthias S. schrieb:> Ich löse keine Interupts mit Drehgeber aus.
Ich schon. Mindestens dann, wenn ich (bzw. mein Produkt) normalerweise
energiesparend schlafen soll, aber bei Betätigung des Encoders aufwachen
soll.
Aber auch sonst ist das kein Problem, man braucht durch das logische
Schema eines solchen Encoders einfach nur zwei unabhängig voneinander
sperrbare und für beide Flanken sensitive Interrupts für seine beiden
Signale.
PeDa's Lösung ist nicht weniger als die bestmögliche Lösung für einen
Polling-Ansatz, aber eben auch nicht mehr. Es gibt eine vollkommen
gleichwertige Lösung mit Interrupts, die verwendeten Interrupts müssen
halt nur o.g. Bedingungen genügen.
Hat man solche verfügbar, kann man die Vorteile der Interruptlösung
nutzen, als da wären:
1) Kombination mit Aufwach-Funktionalität vollkommen problemlos, da
system-immanent.
2) Null Grundlast bei Nichtbetätigung des Encoders, aber trotzdem recht
hohe maximale Schrittrate (*).
(*) Mit der Polling-Lösung kann man theoretisch höhere Schrittraten
realisieren, das Blöde ist halt nur, dass man dann praktisch nix anderes
mehr tun kann...
W.S. schrieb:> Und zum Gezänk um die Außenbeschaltung: Die beiden Hochzieher sind> nötig. Basta - und warum? Weil man sie relativ niederohmig machen kann> (2k2 .. 4k7) und weil sie damit die immer zum Verrotten neigenden> Kontakte frei-brutzeln.
Wenn man daran glauben kann, daß man mit 1mA da etwas frei-brutzeln kann
oder muß, das mit 0,1mA nicht geht - ja dann muß man die wohl einlöten.
W.S. schrieb:> Normal ist bei einfachen DG, daß ein Kontakt direkt im Rastpunkt> umschaltet und der andere genau zwischen den Rastpunkten.
Man wäre blöd, denn dann müsste man z.B. für 32 Raststellungen 2 Spuren
mit je 32 Wechseln, also 16 Kontaktfeldern und 16 Lücken haben, also 64
Kombinationen pro Umdrehung.
Dabei reichen für 32 auszuwertende Raststellungen 2 Spuren mit je 8
Kontaktfeldern und 8 Lücken, eben 32 Kombinationen wenn man es richtig
macht.
> Den letzteren> benutzt man zum Erkennen, daß überhaupt eine Drehbewegung stattfand,> also für das Auslösen des Interrupts (bis auf MaWin natürlich).
Da bin ich dann wenigstens einer, der es richtig macht...
Es ist hinreichend dargelegt, dass das Auslösen von Interrupts durch
Drehgeber schlicht und einfach die blödeste Idee ist, die man haben
kann.
Entweder der Eingang wird nicht entprellt, dann können so viele
Interrupts so schnell nacheinander kommen, dass die ersten Interrupts
noch nicht abgearbeitet sind wenn der nächste kommt, mit je nach
Implementation entweder Stacküberlauf als Folge oder Fehlzählung,
oder der Eingang wird mit extra Hardwareaufwand per RC Kombination am
Schmitt-Trigger Eingang entprellt und wird wegen der nötigen RC
Zeitkonstante damit so gebremst, dass schon bei 1/10 des sonst möglichen
Tempos die ersten Zählfehler auftreten.
> Den> anderen, der im Rastpunkt umschaltet, benutzt man zum Erkennen der> Richtung. Eigentlich ganz einfach.
Viele einfach klingende Antworten sind halt einfach falsch.
> Aber R1 und R4 in der obigen Schaltung sollte man rausschmeißen.
Bloss weil du ihre Funktion bei der Entprellung durch RC Glied und
Schmitt-Trigger Eingang nicht verstehst, heisst das noch lange nicht,
dass sie überflüssig sind.
Wenn, während der Übergang von geschlossener Kontakt zu offender Kontakt
die Spannung über dem C durch den pull up aufgeladen langsam bis zur
Schmitt-Trigger Schaltschwelle steigt ein Prellen des Kontaktes den C
durch den quasi Kurzschluss wieder schlagartig schnell entlädt, hat man
immer noch ein prellendes Signal.
Gibt es aber R1 bzw. R4 in richtiger Dimensionierung, dann kann die
Spannung, nach Erreichen der Schmitt-Trigger Einschaltschwelle, in der
Zeit des prellenden Kontakts nicht mehr so weit entladen werden, dass
die untere Schaltschwelle erreicht wird, man hat also entprellt.
> eine reine Software-Entprellung ist albern, denn sie bedeutet nen> unnötig großen Aufwand durch übertrieben hohe Samplingrate für so einen DG
Armer W.S., deine Prozessoren nutzen sich ab durch so viele Befehle oder
laufen heiss. Schon blöd, wenn mansolchen Schrott hat.
Ein Prozessor muss IMMER die Rechenleistung übrig haben um Drehgeber
auswerten zu können, denn es könnte ja auch jederzeit am Knopf gedreht
werden. Daher ist es nie ein Problem, in der Hauptschleife oder
zeitgebergesteuert Drehgeber richtig auszuwerten.
Macht aber nicht jeder, manche Leute sind halt ebenso dumm wie du und
machen es wie du falsch. Das sind dann die Drehgeber, die Impulse
verpennen und sich verzählen. Ich wüsste da z.B. einen im Autoradio, der
ständig nervt, die RC nach Datenblatt sind auf der Platine erkennbar.
W.S. schrieb:> OK, dann erweitere ich die Ausnahmeliste auf MaWin und dich.
Du hast fachlich dermassenen nachweislichen Schwachsinn geschrieben,
dass du einfach nur armselig bist in deiner Borniertheit und
Lernresistenz.
W.S. schrieb:> Normal ist bei einfachen DG, daß ein Kontakt direkt im Rastpunkt> umschaltet und der andere genau zwischen den Rastpunkten.
"Genau am" gibt es nicht. Je nach Temperatur, Drehrichtung und
allgemeiner Weltlage wird der Kontakt irgendwo in der Nähe schalten. Das
Signal auf dem einen Kanal ist am Rastpunkt nicht spezifiziert.
MaWin schrieb:> Man wäre blöd, denn dann müsste man z.B. für 32 Raststellungen 2 Spuren> mit je 32 Wechseln, also 16 Kontaktfeldern und 16 Lücken haben, also 64> Kombinationen pro Umdrehung.
Du willst damit nicht sagen, das z.B. Alps zu Blöd ist, Drehencoder zu
bauen, oder?
Guck dir beispielsweise die Signale von den Typen
EC09E/EC11E/EC11J/EC11K oder EC20A an. Die haben den Umschaltpunkt vom
B-Kanal genau auf der Raste. Bei dem Typ EC11B liegt er auf beiden
Kanälen im Bereich des wohl definierten Schaltzustandeses.
Dann gibts noch welche mit 4 Umschaltungen (2 pro Spur) zwischen den
Rasten - und wahrscheinlich auch wieder 4-er mit Raste auf Umschaltung,
damit man eine schöne reichhaltige Auswahl hat und es nicht langweilig
wird. :)
MaWin schrieb:> Ein Prozessor muss IMMER die Rechenleistung übrig haben um Drehgeber> auswerten zu können, denn es könnte ja auch jederzeit am Knopf gedreht> werden. Daher ist es nie ein Problem, in der Hauptschleife oder> zeitgebergesteuert Drehgeber richtig auszuwerten.
Tach, also ich frage Encoder, egal 1/2/3/4, mit einer Assembler-Routine
1000 mal pro Sekunde ab. Das reicht für alle normalen von Menschenhand
brauchbare Schrittänderungen. Und ich glaube, dass zwischen diesen
Abfragen verdammt viel Zeit für alles andere ist. Interrupts sind nicht
die erste Wahl.
Cheffe
Cheffe schrieb:> Tach, also ich frage Encoder, egal 1/2/3/4, mit einer Assembler-Routine> 1000 mal pro Sekunde ab. Das reicht für alle normalen von Menschenhand> brauchbare Schrittänderungen.
Das gleiche geht auch in C. Da die meisten Machwerke von mir sowieso
einen Ticker brauchen, wird die Timer ISR mit 1ms Rate eben nebenbei für
den Drehgeber benutzt, oft sind auch Taster gleich mit dabei (alle 10
Ticks). Das ist dann ein Aufwasch und fertig.
Wenn man Sleep braucht, weckt man einmal in der PinChange ISR.
eben ;) Das mache ich beim ESP32 auch so. Die 1ms Timer ISR erzeugt
nebenbei den Sekunden Takt und ließt alle Button inkl. Encoder ein. Das
macht sie ja sowie so wenn ich das Register auslesen muss habe ich doch
gleich alle Pins in der Hand. Jedenfalls fast <32 ;)
Das Ergebnis schiebe ich in einen Que eine andere Task warte bis es was
zum lesen gibt.
Also selbst mit dem ESP32 geht kein Tick verloren, so lange man keinen
Akkuschrauber einsetzt.
Das Problem war nur heraus zu bekommen wie man die 64bit Timer mit ISR
einsetzt ohne das das Teil irrend wann abschmiert.
Guten Abend,
Ich bins nochmal.
Und hätte da eine Frage. Im Moment ist es ja so das die Abfrage
dauerhaft passiert. Die beiden Eingänge von denn Encoder sind an INT0
und INT1 meines ATMega328P angeschlossen.
Kann ich mit ein Interrupt diesen Prozess auslösen so dass er die
Drehung nur ausgibt wenn auch wirklich gedreht wird?
Nur welchen Flanken Wechsel stelle ich dann ein? Weil der ist ja immer
andere je nachdem in welche Richtung ich drehe. Oder soll ich "Any
logical change on INT1 generates an interrupt request." wählen. Dann
müsste ich aber doch theoretisch nur 1 Interrupt Pin nehmen da sich ja
an beiden Pins eine Flanke ausgelöst wird.
Lg Felix.
Nunja das mit INT0 und INT1 ist nicht schön. Ich habe nicht nachgeschaut
aber beim AVR war es so das diese Unterschiedliche Prioritäten haben.
Benutze wie oben erwähnt einen Timer und lese in dessen ISR die Pins
ein.
Ob sich das Rad bewegt hat kann man anhand der Position Festellen. Die
Funktion für das Auslesen in deiner Applikation setzt die Position
einfach auf 0. Wenn diese ungleich 0 ist hat sich das Rad seit dem
letzten Aufruf bewegt. Das verhinder auch das die Positionsvariable in
der ISR überläuft.
Felix N. schrieb:> Und hätte da eine Frage. Im Moment ist es ja so das die Abfrage> dauerhaft passiert. Die beiden Eingänge von denn Encoder sind an INT0> und INT1 meines ATMega328P angeschlossen.> Kann ich mit ein Interrupt diesen Prozess auslösen so dass er die> Drehung nur ausgibt wenn auch wirklich gedreht wird?> Nur welchen Flanken Wechsel stelle ich dann ein? Weil der ist ja immer> andere je nachdem in welche Richtung ich drehe. Oder soll ich "Any> logical change on INT1 generates an interrupt request." wählen. Dann> müsste ich aber doch theoretisch nur 1 Interrupt Pin nehmen da sich ja> an beiden Pins eine Flanke ausgelöst wird.
Ist der Thread an dir spurlos vorüber gegangen ?
Oder ist heute schon Trolltag ?
Funktionierende Lösungen wurden gleich zu Beginn genannt.
Offensichtlich hat dich das Trollgehabe von W.S. und c-hater erfolgreich
in die Irre geleitet.
Felix N. schrieb:> Kann ich mit ein Interrupt diesen Prozess auslösen so dass er die> Drehung nur ausgibt wenn auch wirklich gedreht wird?>> Nur welchen Flanken Wechsel stelle ich dann ein?
Kannst du schon machen, wenn es glücklich macht ;-)
Natürlich solltest du dann die Spur für den IR nehmen, deren Flanke
definiert zum Rastpunkt liegt (A?) und dein Drehgeber sollte natürlich
auch einen Rastpunkt haben.
Bei der Flanke käme es darauf an, ob es sich um einen Drehgeber handelt,
der A und B zwischen den Rastpunkten kurz nach GND schaltet, oder um
einen, der zwischen den Rastpunkten die Zustände wechselt. (Typ kann ich
auf die Schnelle hier nicht finden)
Im ersten Fall wäre der IR auf der fallenden Flanke sinnvoll, im zweiten
müsste die Flanke umgeschaltet werden.
Sehr sinnvoll wäre auch eine ausgeprägte Schmitt-Trigger Charakteristik
des IR Eingangs...
Falls du das dann (aus welchen Gründen auch immer) machst, sag es keinem
;-)
>>Rotary Encoder macht komische Sprünge beim ganz langsamen drehen.
Zum Abschluß kann ich sagen, daß auch ich beim Polka- oder Walzer-Tanzen
dieses Verhalten aufweise.
MfG Paul
Cheffe schrieb:> Tach, also ich frage Encoder, egal 1/2/3/4, mit einer Assembler-Routine> 1000 mal pro Sekunde ab. Das reicht für alle normalen von Menschenhand> brauchbare Schrittänderungen. Und ich glaube, dass zwischen diesen> Abfragen verdammt viel Zeit für alles andere ist. Interrupts sind nicht> die erste Wahl.
Also ich benutze Interrupts um überhaupt erstmal den Timer zu starten,
sprich dreht man am Encoder löst der erste Flankenwechsel einen
Interrupt aus. In diesem wird der Interrupt ausgeschaltet und ein
entsprechender Timer gestartet (oder ein Flag gesetzt, je nach sonstigen
Aufgaben). Nach 10 ms werte ich dann den Encoder aus und schalte den
Pinchange-Interrupt für den Encoder wieder an. Das ist ebenfalls mehr
als ausreichend für einen von Menschenhand gedrehten Drehgeber und macht
IMO die geringste Prozessorlast. Schritte habe ich dadurch bewusst noch
nie verloren oder zu viel dazu bekommen.
Für Encoder, wo ein Anschluß auf der Rastung wechselt, kann meine
Routine zappeln.
In diesem Fall muß man die beiden Pins vertauschen und einen Pin
invertieren, damit die Zählrichtung gleich bleibt. Vorzugsweise macht
man das in der Definition von PHASE_A, PHASE_B.
Damit legt man die Rastung in den Phasenwechel, wo sich encode_read2
nicht ändert.
Und statt Timerinterupt kann man auch den Pin-Change-Interrupt nehmen
(auf beide Pins).
Peter D. schrieb:> Für Encoder, wo ein Anschluß auf der Rastung wechselt, kann meine> Routine zappeln.
Logo. Das ist klar, wenn man den Gesamtzustand pollt und auf
Ungleichheit testet.
Eben deshalb benutzt man als entscheidendes Kriterium ja auch eben DAS
Signal, was nicht in der Nähe des Rastpunktes umschaltet.
Das andere Signal braucht man nur, um bei erkannter Änderung des ersten
Signals die Richtungsinformation zu liefern.
Aber dieser Thread ist ohnehin versaut. Ich bin grad beim Überlegen, ob
man mal ne Art "MaWin-Fibel" mit seinen besten Poltereien
zusammenstellen sollte.
In der Zwischenzeit erweitere ich die Ausnahmeliste auf MaWin, Matthias
S. und den namenlosen "cheffe".
W.S.
Thread beobachten
Seitenaufteilung abschalten