Forum: Projekte & Code AVR: Dreh-Encoder mit Interrupts

Hallo Christian,

hast Du auch eine entsprechende Lösung in C?
Das wäre mir sehr hilfreich.

Gruß Winfried

Hi Winfried,

nein leider nicht... alles nur in Assembler bei mir :) ... du solltest 
aber anhand der Kommentare ziemlich schnell C-Code daraus machen 
können... ansonsten als Inline-ASM reinnehmen...

aber was viel schlimmer ist; ich sehe gerade, daß der Code einen Fehler 
hat:

in der siebten Zeile nach "; INT1 (B)" (also Zeile 103)steht "rjmp 
e_int1"... das ist natürlich falsch, weil er sonst immer wieder nach 
oben springt... richtig ist "rjmp e_int11"... sorry dafür, muss beim 
Umbenennen der Sprungmarken passiert sein! anbei noch einmal die 
korrigierte Fassung...

ciao Christian

Ok, ich werde mal versuchen, es zu erklären...

also das ganze basiert wie gesagt auf einem Automaten, den ich anhand 
der Pegel-Wechsel beim Drehen des Encoders entworfen habe. Mein 
ursprünglicher Automat hatte glaube ich 9 Zustände, die ich auf 
lediglich 2 minimieren konnte (fragt bitte nicht, wie der Automat einmal 
aussah! :))... den aktuellen Automaten findet ihr im Anhang... für 
diejenigen unter euch, die mit Automatentheorie nicht so vertraut sind: 
Die Kreise sind die Zustände (mit den entsprechenden Namen drin (hier 
binär)), die Pfeile sind die Übergänge von einem Zustand in den anderen 
und an den Pfeilen stehen die möglichen Eingaben und die entsprechenden 
Ausgaben, die den Automat veranlassen den Zustand zu wechseln (in der 
Form "Eingabe, Ausgabe(n)")...

ich habe die Eingaben in folgender Form geschrieben: A und B stehen für 
die entsprechenden Pins des Encoders von denen High oder Low kommt (bzw 
INT0 und INT1 am controller)... die Zahl in der Klammer gibt an, ob der 
aktuelle Pegel Low (0) oder High (1) ist...

so bedeutet "A fällt (1), Minus" am Pfeil von Zustand0 nach Zustand1 
also, daß der Zustand von 0 nach 1 gewechselt wird, wenn am Pin A des 
Encoders eine fallende Flanke erzeugt wird, der Pegel aber trotzdem High 
ist (wenn z.B. wieder zurückgeprellt wurde o.Ä.) und das als Ausgabe 
dann ein Minus erfolgt (sprich: Encoder wurde nach Links gedreht) 
(soviel zu Peters Hinweis, auf die gewollte Flanke zu testen)... das 
"Steigend" und "Fallend" in der Ausgabe bedeutet, daß ab sofort der 
entsprechende Eingang (INT0 (A) oder INT1 (B) vom controller) auf die 
steigende oder fallende Flanke reagieren soll...

Man sollte zum besseren Verständnis sich das Datenblatt eines Encoders 
(bzw dessen Ausgangssignale) anschauen und dann einfach mal Schritt für 
Schritt durchgehen... Beispiel: nehmen wir an, der Encoder steht 
ursprünglich in einer Rast-Position, in der A = Low (0) sowie B = Low 
(0)... dann wird durch die Initialisierung zunächst einmal der richtige 
Start-Zustand bestimmt (hier Zustand 0) und INT0 und INT1 sollen auf die 
steigende Flanke reagieren (denn wenn beide LOW sind wird ja wohl beim 
nächsten Bewegen des Encoders ne steigende Flanke kommen)... wird der 
Encoder jetzt nach Rechts (im Uhrzeigersinn) gedreht, wird zunächst auf 
INT0 (A) eine steigende Flanke kommen und dann auf INT1 (B)... im 
Automaten sieht das dann so aus: "A steigt (1)" führt von Zustand 0 in 
den Zustand 1 und es wird INT0 ab jetzt auf die fallende Flanke 
reagieren, anschließend wird mit der Eingabe "B steigt (1)" im Zustand 1 
gekreist und dabei B (INT1) auf die fallende Flanke geschaltet und Plus 
"ausgegeben" (bzw gemacht halt)... auch das Prellen des Encoders wird 
mit der Automaten-Logik aufgefangen... einfach mal ausprobieren!

Der Code ist also nix anderes als der AVR-Assembler gerecht gemachte 
Automat...

noch mal zu Peter; die Geschichte, daß man testen sollte ob während des 
Umschaltens eine Flanke auftritt habe ich ehrlich gesagt nicht 
bedacht... ich denke aber mal, daß das so selten auftritt, daß man es 
hier vernachlässigen kann...

wenn noch Fragen sind, dann los...

ciao Christian

Ist schon eine Menge Kode nur fuers Ablesen eines Encoders.

Ich habe meine Kode leider nicht so schnell dabei, aber habe andere 
Loesung gewaehlt.

Nennen wir die Encoder Signale Xa und Xb

Xa wird auf Int0 UND Int1 angeboten. Int0 wird zur Erkennung aufgehenden 
Flanken konfiguriert. Int1 wird fuer abgehende Flanken verwendet.

Xb wird angeboten ueber ums eben welche andere IO pin.

Nun teste ich bei Interrupthaendler Int0 und Int1 der Wert von Xb.

Int1: Xb == 1 ? -> Positive Drehung sonst Negative Drehung

Int0: Xb == 0 ? -> Positive Drehung sonst Negative Drehung

Kann man in etwa 10 ASM commands ausschreiben.

Nachteil ist das ich nicht die ganze Resolution vom Encoder verwende.

Das ganze in C findest du im Code für den h-mpeg mp3player...
http://www.h-mpeg.de und dann auf Downloads.

Hallo,

wenn man die Layouts und die Schaltpläne, die auf der Seite
http://www.h-mpeg.de öffnen mit einer korrekt lizensierten Eagle-Version 
öffnen will, dann gibt es den berühmten
Load-Error, der auf die Erstellung dieser Dateien mit einer Raubkopie 
hinweisen!!!

Werner

Hallo, bin grad auf diesen Code gestoßen.
Hätte da mal eine Frage dazu:

Der Automat ist im Zustand 0 und es kommt eine steigende Flanke an A.
Dann wechselt der Automat in den Zustand 1, aber woher weis der Automat 
welche Aktion er bei steigender Flanke ausführen muss?
Es gibt zwei :
1. im Pfeil von 0 nach 1
2. im Pfeil von 0 nach 0

oder muss er beide abarbeiten?

Das gleiche Problem ist wenn der Automat jetzt mit steigender Flanke in 
Zustand 1 wechselt und der Kontakt prellt(also eine negative Flanke 
erzeugt)
Wechselt der Automat dan wieder in Zustand 0, da es ja am Pfeil von 1 
nach 0 eine Anweisung gibt, das bei fallender Flanke wieder nach 0 
gewechselt werden soll?

Wäre schön wenn mir das jemande erklären könnte, da ich mit dieser 
Darstellung noch keine Erfahrung gemacht habe während meiner 2jährigen 
Lehrzeit.

mfg Benedikt

Hallo,

kann mir den keiner meine Fragen beantworten?

mfg Benedikt

hammer_c wrote:
> Ok, ich werde mal versuchen, es zu erklären...

Mal ne ganz andere Frage: mit was ist denn dieser hübsche Automat 
gezeichnet? Ist das Visio?
Danke, Grüße, holli

Wie oft denn noch?! Encoder an zwei Interruptleitungen ist 
SCHWACHSINN. Und dieses 
"Wenn-Leitung-A-sich-ändert-dann-werte-Leitung-B-aus" ist noch größerer 
Schwachsinn. Wenn man doch sowieso schon nen Timer laufen hat, dürfte es 
doch möglich sein, da noch ne schnucklige kleine Entprellroutine 
mitlaufen zu lassen...

... habe das mit den beiden Interrupts und der Auswertung der Drehgeber 
mit c getestet (imagecraft ICC) und es klappt wirklich wunderbar:

##############################################################
##############################################################
##############################################################

// PHASEA u -B sind die beiden Encoder Eingänge
#define PHASEA (PIND & 1<<PIND1)  // PIND.1 ist
#define PHASEB (PIND & 1<<PIND2)  // PIND.2 ist

// phasen-check: bestimmung ob interrupt mit fallender oder steigend. 
//flanke. Hier verwende ich interrupt1 auch alf fallende Flanke für den 
//Taster
void check_phase(void)
{
switch (PHASEA+PHASEB)
     {
     case 0: EICRA  = 0x3E; break; //Int0:Fall/Int1:Rise/Int2:Rise/
     case 2: EICRA  = 0x3A; break; //Int0:Fall/Int1:Fall/Int2:Rise/
     case 4: EICRA  = 0x2E; break; //Int0:Fall/Int1:Rise/Int2:Fall/
     case 6: EICRA  = 0x2A; break; //Int0:Fall/Int1:Fall/Int2:Fall/
     }
}

// Interrupt-Routine 1
#pragma interrupt_handler int1_isr:iv_INT1
void int1_isr(void)
{
 //external interupt on INT1
switch (PHASEA+PHASEB)
  {
  case 0: if (EICRA==0x3E | EICRA==0x3A) count++; else count--; break;
  case 6: if (EICRA==0x3E | EICRA==0x3A) count--; else count++; break;
  }
check_phase();
}

// Interrupt-Routine 1
#pragma interrupt_handler int2_isr:iv_INT2
void int2_isr(void)
{
 //external interupt on INT2
switch (PHASEA+PHASEB)
   {
   case 0: if (EICRA==0x3E | EICRA==0x2E) count--; else count++; break;
   case 6: if (EICRA==0x3E | EICRA==0x2E) count++; else count--; break;
   }
check_phase();
}


//main
void main(void)
{

init_devices();
check_phase();

while (1)
    {
    printf(count);
    }
}


##############################################################
##############################################################
##############################################################

PS: Wenn einer eine bessere Lösung mit einem Interrupt hat bitte!

In Bascom ist das mit ein paar Zeilen zu machen.....

erst mal brauchst Du mindestens einen Interrupt
mir reicht einer, Du kannst natürlich auch zwei nehmen,
wenn die auflösung feiner sein soll, aber je nach Chip
kann man ja die Änderung auswerten und nicht nur up oder down
in diesem Fall ein Atmega48:


config Pind2 = Input
config Pind3 = Input


Config Int0 = Change
Enable interrupts
Enable Int0
On Int0 Updn

Updn:
If Pind2 = Pind.3 then incr X
If Pind2 <> Pind.3 then decr X
return

.......wobei mit X die zu ändernde Variable
gemeint ist. Die Werte müssen natürlich noch begrenzt werden,
aber das bleibt jedem selber überlassen......
Wichtig ist das Prinzip, die Flanke des einen Kanals auszuwerten
und dann zu schauen ob der andere Kanal gleich oder anders ist.

If Pind2 = Pind.3 then incr X else decr X müsste auch gehen


man kann statt mit Interrupts notfalls auch mit Debounce arbeiten,
aber da sollte die Laufzeit des Hauptprogramms sehr kurz sein,
oder man hüpft alle paar Zeilen ins Unterprogramm mit der Auswertung
sonst hakt das fürchterlich.Nur in Notfällen sinnvoll!

mfG
Franz

> In Bascom ist das mit ein paar Zeilen zu machen.....

Wie schrieb schon Sven P. 2008 :

"Wie oft denn noch?! Encoder an zwei Interruptleitungen ist
SCHWACHSINN. Und dieses 
"Wenn-Leitung-A-sich-ändert-dann-werte-Leitung-B-aus" ist noch größerer 
Schwachsinn. "

Blöd wenn man den Thread nicht bis zu
http://www.mikrocontroller.net/articles/Drehgeber#Solide_L.C3.B6sung:_Beispielcode_in_C
gelesen hat.

Ich habe nicht behauptet, dass das die beste und einzige Möglichkeit
ist einen Drehgeber auszuwerten, aber das ist in Bascom eine sehr 
interessante Variante und wenn der Encoder ein bisschen entprellt ist,
(10k Pull-Up und 100nF nach Gnd) dann reicht das allemal um
mit einem kleinen Drehencoder mit Taster ein Menue zu steuern
 rauf, runter, weiter.....

Es gibt Fälle, da hat man Timer frei, aber keine Interrupts
ich hatte aber das Problem, keine Timer sondern die Interrupts
frei gehabt zu haben, und da hat sich das angeboten.

....mir ist auch der "ENCODER"-Befehl in Bascom bekannt,
aber der ist auch nicht immer die erste Wahl, wenn der
Geber ständig abgefragt werden soll, unabhängig davon,was
das Programm gerade macht.

und auch wenn es um Höchstgeschwindigkeit geht, dann ist die
Interrupt-Variante die schnellste, weil da die Abtastung immer
absoluten Vorrang hat.

Versuche mal den Wert eines hochauflösenden Inkrementalgebers
mit einem Atmega und Bascom auf ein Display zu schreiben....
Wenn man das Signal nicht vorher per Hardware in Takt und Richtung
aufbereitet was man ja in solch einem Fall meist vermeiden möchte,
dann ist die Interruptmethode die einzig brauchbare, weil sich sogar
das Schreiben ins Display dem Interrupt unterordnet.
Das funktioniert bis zu einigen Kilohertz.Der einzige echte
Nachteil der Interrupt-Methode ist das Zappeln, das auftreten kann,
wenn der Kanal des Gebers der den Interrupt auslöst zappelt,
aber das ist dann kein Fehler der Auswertemethode sondern eine
Fehlfunktion des Gebers.

Also lieber MaWin,
hier hat jemand,danach gefragt, ob nicht irgendwer dieses Verfahren
in Bascom hätte.... Und weil ich genau dieses zufällig sowieso
irgendwo in einigen meiner Programme genau so drin habe, und es ganz
hervorragend funktioniert (und ich auch schon andere getestet habe)
habe ich es hier in diesem kürzlich wieder ausgegrabenen Thread
gepostet.

Wenn Du also dieses oder andere Programme oder Verfahren aus
irgend einem Grund der ja durchaus berechtigt sein kann,
nicht gut findest, dann antworte bitte sachlich und korrekt
oder machs halt einfach besser......
Aber hier von Schwachsinn oder noch größerem Schwachsinn zu
reden oder zu zitieren und von blöd zu reden schiesst doch
ein bisschen übers Ziel hinaus!

Es kommt immer auf den jeweiligen Fall an, wie die optimale
Lösung aussieht.

mfG
Franz

Richard S. schrieb:
> und erstmal die hier
> veröffentlichte Software getestet ... kein Erfolg

Vielleicht hättest du vorher lesen sollen, wie man es richtig macht, was 
auch der hammer_c nicht beachtet hat:

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

Richard S. schrieb:
> Für die Entprellung der beiden Drehgeberanschlüsse habe ich 100 nF Kerko
> und 4.7 k Pull-up verwendet.

Da du NATÜRLICH keinen Schaltplan angegeben hast, kann man nur vermuten, 
dass 4k7 als pull up und 100nF über den Encoderkontalten sitzen: das 
entladen der 100nF schadet den Encoderkontakten, die Funken rauen die 
Kontakte auf, das prellen nimmt zu, bis es die Encoderauswertung stört.

Da du Interrupts auf Flankenwechsel nutzt, dann aber den aktuellen 
Encoderzustand vom Port einliest (der schon wieder anders sein kann als 
der zum Flankenwechsel führte), stört Prellen deine Software sehr stark.

MaWin schrieb:
> das
> entladen der 100nF schadet den Encoderkontakten, die Funken rauen die
> Kontakte auf, das prellen nimmt zu, bis es die Encoderauswertung stört.

Frage dazu: oxidieren die Kontakte nicht ohne Strom? Z.B. bei 
Relaiskontakten ist ein Minimum an Strom wünschenswert für die 
Selbstreinigung.

Ozvald K. schrieb:
> oxidieren die Kontakte nicht ohne Strom

Ja, Taster brauchen einen Mindeststrom, der wäre bei 4k7 um 1mA, sollte 
reichen.
Die meisten Encoder werden aber keine Zaster sondern schleifende 
Kontakte haben, die reinigen  sich selbst (und nutzen sich dabei ab, 
halt billig).

Eine RC Kombination nach dem Kontakt ist trotzdem nützlich da eben jene 
schleifenden Kontakte während der Bewegung ständig kurze Unterbrechungen 
haben (nicht nur Prellen an den Übergängen, sondern die ganze 
Kontaktfläche lang) die die Auswertung stören und durch eine RC Kombi 
unterdrückt werden. Aber die sollte halt nicht die Kontakte durch zu 
hohen Kondensatorentladestrom schädigen.

Yalu X. schrieb:
> Die Wahrscheinlichkeit,
> dass während der Bewegung beide Kontaktzungen gleichzeitig springen, ist
> sehr gering.

Sie steigt mit dem Alter, also letztlich eine Frage wann die Obsoleszenz 
eintreten soll.

Yalu X. schrieb:
> Ein Glitch in einem der beiden Encoder-Signale, der
> mit einem Abtastzeitpunkt zusammenfällt, führt auch bei ihm zu einer
> temporären Änderung des Zählerstands um ±1. Das wird aber gemeinhin in
> Kauf genommen, da dieser Fehler

Woher weißt du, dass das ein Fehler ist. Vielleicht steht der Encoder 
wirklich genau auf der Grenze, so dass eine 50%-Wahrscheinlichkeit für 
jeden der beiden Zustände die Position sauber beschreibt. Die Schwankung 
um ±1 (eigentlich ±1/2?) fällt dann unter Quantisierungsrauschen. 
Einziges Mittel dagegen ist eine Hysterese, gesteuert durch die 
Auswertung der Richtungsumkehr.

Wolfgang schrieb:
> Einziges Mittel dagegen ist eine Hysterese

Nope.

Einziges Mittel dagegen ist Intelligenz, um die Auswertung richtig zu 
machen, und nicht auf Flankenwechseln die Interrupts erzeugen 
aufzusetzen.

Der TO hat es inzwischen gelernt....

Werner Schwarz schrieb:
> Hallo,
> wenn man die Layouts und die Schaltpläne, die auf der Seite
> http://www.h-mpeg.de öffnen mit einer korrekt lizensierten Eagle-Version
> öffnen will, dann gibt es den berühmten
> Load-Error, der auf die Erstellung dieser Dateien mit einer Raubkopie
> hinweisen!!!
> Werner

Wahnsinn !!!! Das gehört gemeldet!