www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Hilfe zu Drehencoder-Auswertung nach Wiki


Autor: Wurzel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich versuche den Pollin Drehencoder von ALPS auszuwerten. Ich habe mich 
genau nach dem C-Code im Wiki hier auf der Website gehalten. 
http://www.mikrocontroller.net/articles/Drehgeber

Die Auswertung läuft in folgender Funktion ab:
char decoder_getc(uint8_t x_position, uint8_t y_position, unsigned char min_char, unsigned char max_char)
{
  unsigned char zahl = '0';
  
  while( !(ENCODER_BOTTON_PORT & (1<<ENCODER_BOTTON_PIN)) ); //warten bis Taster losgelassen wird

  while( ENCODER_BOTTON_PORT & (1<<ENCODER_BOTTON_PIN) )
  {
    zahl += encode_read2();
  

    lcd_gotoxy(x_position, y_position);
    lcd_putc(zahl);

  }
  return zahl;
}  


Das Problem ist, dass manchmal Drehungen nicht erkannt werden, oder ich 
erst zig mal drehen muss bis sich was auf dem Display tut. Auch werden 
manchmal Zeichen übersprungen.
:-(

Ich habe die Abtastrate auf 0,5ms verringert und auf 4 bzw. 8ms erhöht. 
Hat irgendwie nichts gebracht. Ich bin jetzt etwas ratlos.

Hat jemand mit dem Pollin ALPS Drehencoder Erfahrungen? Wer kann helfen?
danke.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich habe mich genau nach dem C-Code im Wiki hier auf der Website gehalten.
Gut. Der Code funktioniert super.

> Das Problem ist, dass manchmal Drehungen nicht erkannt werden
Dann zeig mal deinen restlichen Code. Bei dem, was du schon gepostet 
hast, erwarte ich Schlimmes... :-/

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wurzel schrieb:

> Hat jemand mit dem Pollin ALPS Drehencoder Erfahrungen?

Welcher ist es denn genau?
(Hintergrund: Ich habe hier auch Drehgeber, die verhalten sich aber ganz 
anders. Die geben beim Drehen von einer Rastposition zur nächsten nur 
Pulse aus)

Autor: Wurzel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ATmega16 @ 8MHz Quarz

Hier der Code für den Timer0.
#define XTAL    8000000
//Drehencoder Pinbelegung
#define PHASE_B    (PIND & 1<<PD2)
#define PHASE_A    (PIND & 1<<PD7)
 
volatile int8_t enc_delta;      // -128 ... 127
static int8_t last;

void timer0_init(void)
{
  int8_t recent;

  recent = 0;
  if( PHASE_A )
    recent = 3;
  if( PHASE_B )
    recent ^= 1;          // convert gray to binary
  last = recent;            // power on state
  enc_delta = 0;
  TCCR0 |= (1<<WGM01)|(1<<CS01)|(1<<CS00);    // CTC, XTAL / 64
  OCR0 = (uint8_t)(XTAL / 64.0 * 1e-3 - 0.5);  // 1ms
  TIMSK |= 1<<OCIE0;
}

void timer0_comp_irx(unsigned char enable)
{
  if( enable )
    TIMSK |= (1<<OCIE0);
  else
    TIMSK &= ~(1<<OCIE0);
}

ISR( TIMER0_COMP_vect )        
{
  int8_t recent, diff;

  recent = 0;
  if( PHASE_A )
    recent = 3;
  if( PHASE_B )
    recent ^= 1;          // convert gray to binary
  diff = last - recent;        // difference last - new
  if( diff & 1 )            // bit 0 = value (1)
  {        
    last = recent;          // store new as next last
    enc_delta += (diff & 2) - 1;  // bit 1 = direction (+/-)
  }
}

Drehencoder:
#define ENABLE  1
#define DISABLE  0

int8_t encode_read1( void )      // read single step encoders
{
  int8_t val;

  timer0_comp_irx(DISABLE);
  val = enc_delta;
  enc_delta = 0;
  timtimer0_comp_irx(ENABLE);
  return val;          // counts since last call
};
 
 
int8_t encode_read2( void )      // read two step encoders
{
  int8_t val;

  timer0_comp_irx(DISABLE);
  val = enc_delta;
  enc_delta = val & 1;
  timer0_comp_irx(ENABLE);
  return val >> 1;
};
 
 
int8_t encode_read4( void )      // read four step encoders
{
  int8_t val;

  timer0_comp_irxDISABLE);
  val = enc_delta;
  enc_delta = val & 3;
  timer0_comp_irxENABLE);
  return val >> 2;
};

Folgendes muss ich noch sagen:
Die Funktion decoder_getc(..) sieht etwas chaotisch aus, weil die 
Auswertung nicht über den Timerinterrupt geschehen ist. Die zwei 
fehlenden Parameter min_char und max_char wurden zu testzwecken 
entfernt.
Außerdem Timer0 Overflow Interrupt läuft noch ein Interrupt vom Timer0 
ca. alle 4ms.
In der main wird nach Initalisierung (Ports, Timer) die Funktion 
decoder_getc() aufgerufen und das ASCII Zeichen auf dem Display 
ausgegeben. Es handelt sich bei der Funktion nur um eine Testroutine.

@Karl heinz
ALPS 11mm Size Metal Shaft Encoder EC11 Series
Model No. EC11E15244B2

Autor: Wurzel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier das Datenblatt zu den Encodern von ALPS
http://www.alps.com/products/WebObjects/catalog.wo...

Autor: Rene K. (draconix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich muß sagen, ich habe hier drei verschiedene, ausgebaute, 
Drehimpulsgeber liegen... alle haben eine andere Art der Ansteuerung.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kann jetzt aus dem Kopf nicht sagen, welchen ALPS Typ ich genau 
habe. Aber wenn ich abends nach Hause komme, werd ich das mal eruieren 
und meine Codebasis rausgeben.

Autor: Wurzel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Karl heinz

Das wäre sehr freundlich von dir, danke!

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm.
Der letzte Encoder, den ich noch nicht verbaut hatte, versteckt sich 
hartnäckig.
Jetzt kann ich nicht sagen, was das genau für ein Typ ist. Aber ich weiß 
noch, wie ich ihn das erste mal ausprobiert hatte: Ich hab einen Kanal 
(A) an den Durchgangspiepser gehängt und war erstaunt, dass derbeim 
Drehen von einer Rastposition in die nächste nur ganz kurz gepiepst hat. 
Erwartet hatte ich eigentlich, dass sich mit dem Drehen von einer 
Rastposition in die nächste ein Piepsen/nicht_piepsen ergibt.

Wie auch immer.
Ich habe die Auswertung in die Tastenentprellroutine vom PeDa 
eingebunden.
D.h. Timer-Overflow der alle paar Millisekunden ausgelöst wird.
#define ENCODER_DDR     DDRA
#define ENCODER_PORT    PORTA
#define ENCODER_PIN     PINA
#define ENCODER_A       (1<<PA5)
#define ENCODER_B       (1<<PA4)
 

uint8_t prevEncoderA = ENCODER_A;
uint8_t prevEncoderB = ENCODER_B;
uint8_t encoderA = ENCODER_A;
uint8_t encoderB = ENCODER_B;

ISR( TIMER0_OVF_vect )                            // every 10ms
{
  ...

  // Drehendcoder
  prevEncoderA = encoderA;
  encoderA = ENCODER_PIN & ENCODER_A;
  encoderB = ENCODER_PIN & ENCODER_B;

  if( encoderA != prevEncoderA ) {      // Pegelwechsel A
    if( !encoderA )               // 1 -> 0  Startflanke
      prevEncoderB = encoderB;
    else {                        // 0 -> 1  Endflanke
      if( prevEncoderB != encoderB ) {  // gilt nur, wenn es an B ebenfalls einen Pegelwechsel gab
                                        // da die Wechsel phasenverschoben sind
                                        // ist das gleichzeitig eine Entprellung

        if( encoderB )
          key_press |= KEY_NEXT;
        else
          key_press |= KEY_PREV;

      }
    }
  }
}

Das Ergebnis wird in key_press abgeliefert und wird mit den normalen 
Entprellroutinen für die Tasten mit abgefragt.
///////////////////////////////////////////////////////////////////
//
// check if a key has been pressed. Each pressed key is reported
// only once
//
uint8_t get_key_press( uint8_t key_mask )
{
  cli();                                          // read and clear atomic !
  key_mask &= key_press;                          // read key(s)
  key_press ^= key_mask;                          // clear key(s)
  sei();
  return key_mask;
}

und natürlich die Intialisierung
int main( void )
{
  KEY_DDR  &= ~ALL_KEYS;                // konfigure key port for input
  KEY_PORT |=  ALL_KEYS;                // and turn on pull up resistors

  ENCODER_DDR &= ~( ENCODER_A | ENCODER_B );
  ENCODER_PORT |= ENCODER_A | ENCODER_B;
 
  ...

  TCCR0 = (1<<CS01)|(1<<CS00);      // divide by 1024
  TIMSK |= 1<<TOIE0;        // enable timer interrupt

  ...

  sei();

  while ....


Ich hätte eigentlich gerne ein komplettes Beispiel zusammengestellt, 
aber das Teil ist hartnäckig weg :-)

Autor: alpshasser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alle Alps Drehencoder sind anders.
Auch die mit derselben Partnummer.
Insbesondere die Phase B kann bei der Rastung stabil 1 oder 0 sein oder 
- meistens- undefiniert irgendwas sein.
Auch kann es 2 oder 1 Impuls zwischen Rastungen geben. Eine allgemein 
definierte Aussage zu diesem Murks ist nicht möglich.

Autor: Wurzel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe leider kein Oszi und kann daher nur den Zustand in den 
Rasterstellungen erfassen. Beide "Phasen" wechseln zwischen 11 und 00.

Ich probiere mal meinen Code an deine Vorlage anzupassen.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wurzel schrieb:
> Ich habe leider kein Oszi und kann daher nur den Zustand in den
> Rasterstellungen erfassen.

Wenn Du langsam genug drehst, dann siehst Du auch an LEDs, wie die 
beiden Phasen schalten.

> Beide "Phasen" wechseln zwischen 11 und 00.

So ist es bei meinem Alps von Pollin (Bestellnummer 240399, vor einigen 
Jahren gekauft) auch, ist eine Ausführung mit kurzer geriffelter 1/4 
Zoll-Welle, 30 Rastungen pro Umdrehung (15 mal 00 und 15 mal 11) und 
sehr sauberen Rastpunkten ohne Wackler an einer der beiden Phasen (im 
Gegensatz zum Panasonic-Drehgeber Bestellnummer 240313, dessen Phase B 
genau im Rastpunkt umschaltet).

>
> Ich probiere mal meinen Code an deine Vorlage anzupassen.

Ich frage die Dinger im Timer-synchronisierten Job im Abstand von 1 ms 
ab, wobei ich aus (um 2 Bit geshiftetem) Alt-Wert und Neuwert einen 
Index bilde, über den ich den Increment-Wert (-1, 0, +1) aus einem 
Flash-Array hole (LUT). Bei Drehgebern mit anderen Eigenschaften wird 
einfach nur die LUT angepasst.

Mit C-Code kann ich nicht dienen, ich werkele in ASM.

...

Autor: Rene K. (draconix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wurzel schrieb:
> Ich habe leider kein Oszi und kann daher nur den Zustand in den
> Rasterstellungen erfassen. Beide "Phasen" wechseln zwischen 11 und 00.
>
> Ich probiere mal meinen Code an deine Vorlage anzupassen.

Jep ist richtig so, er schaltet nicht direkt 11 und 00 sondern schaltet

in die eine Richtung

P1: 0-1-1   /  1-0-0
P2: 0-0-1   /  1-1-0

in die andere Richtung

P1: 0-0-1  /  1-1-0
P2: 0-1-1  /  1-0-0

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  alpshasser (Gast)

>Alle Alps Drehencoder sind anders.

Oh wie schön.

>Insbesondere die Phase B kann bei der Rastung stabil 1 oder 0 sein oder
>- meistens- undefiniert irgendwas sein.

Es ist ja auch selten dämlich, die Rastpunkte genau auf den 
Flankenwechsel eines Kanals zu legen.

MfG
Falk

Autor: Wurzel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Falk brunner

ALPS hat es wohl geschafft den Rastpunkt einer Phase auf die Flanke zu 
legen (siehe Datenblatt). ;-)

Autor: Hannes Lux (hannes)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
> @  alpshasser (Gast)
>
>>Alle Alps Drehencoder sind anders.
>
> Oh wie schön.
>
>>Insbesondere die Phase B kann bei der Rastung stabil 1 oder 0 sein oder
>>- meistens- undefiniert irgendwas sein.
>
> Es ist ja auch selten dämlich, die Rastpunkte genau auf den
> Flankenwechsel eines Kanals zu legen.

Das weißt Du und das weiß ich, aber Panasonic weiß das nicht...
http://www.pollin.de/shop/downloads/D240313D.PDF
Schau Dir das Impulsdiagramm an, Spur B hat die Flanke (den 
Pegelwechsel) genau auf dem Rastpunkt.

@Wurzel:
Beim Alps ist das nicht der Fall, siehe Datenblatt im Anhang.

>
> MfG
> Falk

...

Autor: Wurzel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Lux

Doch! Zumindest bei den Typen EC09E/EC11E/EC11J/EC11K. Schau mal auf 
Seite 9 des Datenblatts. ;-)
http://www.alps.com/products/WebObjects/catalog.wo...

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wurzel schrieb:
> @Lux
>
> Doch!

Der Alps-Drehencoder, den Pollin unter Bestellnummer 240339 verkauft 
hat, hat seine 30 Rastungen allesamt im stabilen Bereich beider Spuren. 
Und dies nicht nur laut Datenblatt, sondern auch real. Um dies zu 
überprüfen, habe ich gestern Abend extra mein Steckbrett hervorgeholt 
und das dort verbaute Exemplar (unten ganz rechts) mit LEDs 
durchgespielt.
http://www.hanneslux.de/avr/tipps/brett/index.html

> Zumindest bei den Typen EC09E/EC11E/EC11J/EC11K. Schau mal auf
> Seite 9 des Datenblatts. ;-)
> 
http://www.alps.com/products/WebObjects/catalog.wo...

Ja, das ist wie bei dem Panasonic-Drehgeber (Bestellnummer 240313), den 
Pollin derzeit noch vertreibt und dessen Datenblatt ich oben verlinkt 
habe.

Wenn schon (mindestens) zwei Hersteller solche Drehgeber anbieten, dann 
muss es doch auch Kunden geben, die so "selten dämlich" (TM Falk) sind, 
solche Konstrukte in Auftrag zu geben.

Diese "selten dämliche" Konstruktion ist zwar nicht gerade vorteilhaft, 
lässt sich aber auch zuverlässig und sauber auswerten, ich habe in 
verschiedenen Basteleien die Panasonic-Drehgeber (Pollin 240313) im 
Einsatz.

Bei Drehgebern, die ihre Rastung auf 00 und 11 haben, gibt es pro 
Rastung auf jeder Spur eine Flanke. Um diese Drehgeber auszuwerten, 
prüft man ja eine Spur auf Flanke und die andere Spur auf Zustand. Bei 
symmetrischen Drehgebern ist es egal, welche Spur man auf Flanke prüft. 
Bei diesen "selten dämlichen" Drehgebern prüft man Spur A (also die 
Spur, die im eingerasteten Zustand stabilen Pegel liefert) auf Flanke 
und Spur B auf Zustand. Da der Zustand nur relevant ist, wenn eine 
Flanke erkannt wurde, spielt der (eingerastet) undefinierte Zustand der 
Spur B keine Rolle.

Zum Abtasten des Drehgebers wird das Bitmuster (der Zustand der beiden 
Spuren) eingelesen und auf die beteiligten Bits maskiert. Dies wird dann 
zu dem "gemerkten" und um 2 Bits verschobenen Bitmuster der letzten 
Abtastung geORT. Es entsteht eine 4-Bit-Zahl, die als Index auf die LUT 
genutzt wird. Von diesen 16 möglichen Zuständen sind bei diesen 
Drehgebern aber nur 4 Zustände relevant.

In die LUT werden also nur dort Incremente eingetragen, wo Spur A den 
Pegel wechselt (also eine Flanke hat).

Eine Drehrichtung:
Rastung alt neu
        A B A B
        -------
 -->    0 0 0 1   1
 |  >   0 1 1 1   7  Flanke an A
 |      1 1 1 0  14
 |  >   1 0 0 0   8  Flanke an A
 |      0 0 0 1   1
 |  >   0 1 1 1   7  Flanke an A
 |      1 1 1 0  14
 |  >   1 0 0 0   8  Flanke an A
 --<    0 0 0 1   1

Andere Drehrichtung:
Rastung alt neu
        A B A B
        -------
 -->    0 1 0 0   4
 |  >   0 0 1 0   2  Flanke an A
 |      1 0 1 1  11
 |  >   1 1 0 1  13  Flanke an A
 |      0 1 0 0   4
 |  >   0 0 1 0   2  Flanke an A
 |      1 0 1 1  11
 |  >   1 1 0 1  13  Flanke an A
 --<    0 1 0 0   4

Die eine Drehrichtung ergibt also bei Flanken an Spur A die Zahlenwerte 
(als Index auf die LUT) 7 und 8, die andere Drehrichtung 2 und 13. 
Daraus ergibt sich, dass bei Index 7 und 8 der Wert +1 (als Increment) 
in die LUT eingetragen wird und bei Index 2 und 13 der Increment-Wert 
-1. Alle anderen Elemente des Arrays (der LUT) werden mit dem Wert 0 
aufgefüllt.

Wird Spur A und B vertauscht, so ergeben sich andere Index-Werte. Bei 
symmetrischen Drehgebern ist das egal, die "selten dämlichen" spinnen 
dann aber.

Somit wird der Zählerstand nur verändert, wenn eine Flanke an Spur A 
erkannt wurde. Der Zustand von B ist in diesem Zeitpunkt ja stabil.

Dies alles läuft im Timer-Int oder einem per Timer synchronisierten Job 
ab. Die Aufruf-Frequenz ist ein Kompromiss zwischen CPU-Last und maximal 
möglicher Drehgeschwindigkeit. Bei Verwendung des Drehgebers als 
manuelles Eingabegerät hat sich bei mir eine Abtastfrequenz von 1 kHz 
bewährt.

Die Mainloop (bzw. ein Job davon) addiert nun diesen Zählerstand auf den 
zur Bearbeitung anstehenden Wert und löscht ihn danach. Somit gehen 
keine Drehbewegungen verloren, wenn es in Main mal länger dauert.

C-Code kann ich Dir nicht geben, ich mach' sowas in ASM.

...

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Hannes Lux (hannes)

>Wenn schon (mindestens) zwei Hersteller solche Drehgeber anbieten, dann
>muss es doch auch Kunden geben, die so "selten dämlich" (TM Falk) sind,
>solche Konstrukte in Auftrag zu geben.

Sicher, was aber nicht automatisch bedeutet, dass das sonderlich klug 
ist. Wie es scheint, ist der Drehgeber auch heutzutage noch sehr mit 
mystischen Vorstellungen behaftet.

>Diese "selten dämliche" Konstruktion ist zwar nicht gerade vorteilhaft,
>lässt sich aber auch zuverlässig und sauber auswerten,

Nöö, das ist mehr oder minder Glückssache, jenachdem wie "klapprig" der 
individuelle Drehgeber ist. Warum das so ist, steht im Artikel 
Drehgeber.

>Rastung auf jeder Spur eine Flanke. Um diese Drehgeber auszuwerten,
>prüft man ja eine Spur auf Flanke und die andere Spur auf Zustand.

Genau DAS ist Billigmurks, der aber leider selbst bei Markenherstellern 
zu finden ist. Kann jeder leicht prüfen. Einfach einen Drehknopf fest 
anfassten und immer auf einem Rastpunkt leicht hin- und herdrehen. 
Mechanisch dreht man immer vor und zurück, ein Menu darf dabei nicht 
kontinuierlich weiterblättern bzw. wenn es eine Zahleneinstellung ist, 
muss sie vor und zurück springen. Tut sie das nciht, ist die Auswertung 
Schrott.

MfG
Falk

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
> @  Hannes Lux (hannes)
>
>>Wenn schon (mindestens) zwei Hersteller solche Drehgeber anbieten, dann
>>muss es doch auch Kunden geben, die so "selten dämlich" (TM Falk) sind,
>>solche Konstrukte in Auftrag zu geben.
>
> Sicher, was aber nicht automatisch bedeutet, dass das sonderlich klug
> ist.

Da gebe ich Dir schon mal unbestritten recht. Aber...
Nicht alles, was ich nicht (auf Anhieb) verstehe, ist von vornherein 
Schrott.

> Wie es scheint, ist der Drehgeber auch heutzutage noch sehr mit
> mystischen Vorstellungen behaftet.

Bei mir nicht.

>
>>Diese "selten dämliche" Konstruktion ist zwar nicht gerade vorteilhaft,
>>lässt sich aber auch zuverlässig und sauber auswerten,
>
> Nöö, das ist mehr oder minder Glückssache,

Nöö, ist es nicht. Es sei denn, Du meinst mit Glücksache das Vertauschen 
der Spuren, dann hättest Du natürlich recht. Aber dann ist auch der 
(richtig gepolte) Anschluss der Versorgungsspannung Glücksache... ;-)

> jenachdem wie "klapprig" der
> individuelle Drehgeber ist.

Wenn er wirklich "klapperig" (auf beiden Spuren) ist, dann gehört er in 
den Schrott.

> Warum das so ist, steht im Artikel
> Drehgeber.

In diesem Artikel steht eine Menge theoretisches Blabla, aber nichts 
Konkretes praktisch Verwertbares (zumindest vor einiger Zeit, aktuell 
nachgesehen habe ich nicht).

>
>>Rastung auf jeder Spur eine Flanke. Um diese Drehgeber auszuwerten,
>>prüft man ja eine Spur auf Flanke und die andere Spur auf Zustand.
>
> Genau DAS ist Billigmurks,

Du musst es ja wissen...

> der aber leider selbst bei Markenherstellern
> zu finden ist. Kann jeder leicht prüfen. Einfach einen Drehknopf fest
> anfassten und immer auf einem Rastpunkt leicht hin- und herdrehen.
> Mechanisch dreht man immer vor und zurück, ein Menu darf dabei nicht
> kontinuierlich weiterblättern bzw. wenn es eine Zahleneinstellung ist,
> muss sie vor und zurück springen. Tut sie das nciht, ist die Auswertung
> Schrott.

Diesem Test hält meine Auswertung locker stand.

Anscheinend hast Du meinen Text nicht richtig gelesen und bist auf 
"Flanke" angesprungen. Mit "Auswertung der Flanke" meinte ich natürlich 
keinen externen Interrupt, sondern einen Vergleich zwischen Neuwert und 
Altwert bei zyklischer Abfrage (per Timer-Interrupt).

>
> MfG
> Falk

...

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:

> anfassten und immer auf einem Rastpunkt leicht hin- und herdrehen.
> Mechanisch dreht man immer vor und zurück, ein Menu darf dabei nicht
> kontinuierlich weiterblättern bzw. wenn es eine Zahleneinstellung ist,
> muss sie vor und zurück springen.

Noch nicht mal das.
Eine saubere Auswertung erkennt, dass nicht beide Flanken in einer 
korrekten Reihenfolge gekommen sind und tut nichts.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Falk Brunner schrieb:
>
>> anfassten und immer auf einem Rastpunkt leicht hin- und herdrehen.
>> Mechanisch dreht man immer vor und zurück, ein Menu darf dabei nicht
>> kontinuierlich weiterblättern bzw. wenn es eine Zahleneinstellung ist,
>> muss sie vor und zurück springen.
>
> Noch nicht mal das.
> Eine saubere Auswertung erkennt, dass nicht beide Flanken in einer
> korrekten Reihenfolge gekommen sind und tut nichts.


Auch das funktioniert ohne Probleme, solange man den Drehgeber nicht zu 
schnell dreht, was bei Benutzung als manuelles Eingabegerät aber egal 
ist.

Von den 16 möglichen Kombinationen aus Alt und Neu werden ja 12 
ignoriert (0 in der LUT) und nur 4 genutzt (2 ma sorum und 2 mal rosum 
(TM Paul)).

...

Autor: Wurzel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hannes Lux

Es funktioniert!
Ich habe den Code von Karl Heinz Buchegger probiert, aber auch kein 
brauchbares Ergebnis erhalten. Ich weiss nicht wieso.
Dann habe ich die Funktion mit Hilfe der LUT getestet und damit 
funktioniert es jetzt schon viel besser. :-)
Nur ganz selten wenn ich den Knopf ganz langsam zwischen zwei 
Rastpunkten drehe zählt er manchmal eine Stellung falsch (+1 oder -1). 
Aber kein Vergleich zu meinen vorherigen Versuchen, da ging ja nichts 
zuverlässig. Das Problem was ich noch habe ist, dass Phase A und Phase B 
vertauscht sind. D.h. Phase A am Pin des Encoders ist Phase B im 
Programm. Also müsste die LUT noch angepasst werden.

Hier der Code in C, Verbesserungsvorschläge nehme ich gerne entgegen.
ATmega16 @ 8Mhz

Initialisierung Timer0
#define XTAL    8000000
//Drehencoder Pinbelegung
#define PHASE_B    ((PIND & 1<<PD2)>>PD2)
#define PHASE_A    ((PIND & 1<<PD7)>>PD7)

void timer0_init(void)
{
  recentA = PHASE_A;
  recentB = PHASE_B;
  enc_delta = 0;
  TCCR0 |= (1<<WGM01)|(1<<CS01)|(1<<CS00);    // CTC, XTAL / 64
  OCR0 = (uint8_t)(XTAL / 64.0 * 1e-3 - 0.5);  // 1ms
  TIMSK |= 1<<OCIE0;
}

Timer Compare ISR
volatile int8_t enc_delta;      // -128 ... 127
static int8_t lastA, lastB, recentA, recentB;
const int8_t decoder_lut[]={  0,
                -1, //2
                0,
                0,
                0,
                0,
                1, //7
                1, //8
                0,
                0,
                0,
                0,
                -1, //13
                0,
                0,
                0 
              };
                

ISR( TIMER0_COMP_vect )        
{
  uint8_t index;
  
  lastA = recentA;
  lastB = recentB;

  recentA = PHASE_A;
  recentB = PHASE_B;

  index = ((lastA<<3)|(lastB<<2)|(recentA<<1)|(recentB)) & 0b00001111; //Zustände zu 4Bit zusammenfassen und maskieren
  enc_delta += decoder_lut[index-1]; //Wert aus der LUT entnehmen

}

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die LUTs für die beiden möglichen Polungen sehen in ASM so aus:
/*
dgtab:      ;Tabelle mit Drehgeber-Werten (alt-alt-neu-neu als Index)
                    ;aa nn,     aa nn
.db     0, 1        ;00 00,     00 01
.db     0, 0        ;00 10,     00 11
.db    -1, 0        ;01 00,     01 01
.db     0, 0        ;01 10,     01 11
.db     0, 0        ;10 00,     10 01
.db     0,-1        ;10 10,     10 11
.db     0, 0        ;11 00,     11 01
.db     1, 0        ;11 10,     11 11
*/

dgtab:      ;Tabelle mit Drehgeber-Werten (alt-alt-neu-neu als Index)
                    ;aa nn,     aa nn
.db     0, 0        ;00 00,     00 01
.db     1, 0        ;00 10,     00 11
.db     0, 0        ;01 00,     01 01
.db     0,-1        ;01 10,     01 11
.db    -1, 0        ;10 00,     10 01
.db     0, 0        ;10 10,     10 11
.db     0, 1        ;11 00,     11 01
.db     0, 0        ;11 10,     11 11

Eine ist auskommentiert. Es stehen immer 2 Bytes in einer Zeile, weil 
die ASM-Direktive ".db" das bei Flash-Daten (die ja wordadressiert sind) 
so verlangt (geradzahlig).

...

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hannes Lux (hannes)

>Wenn er wirklich "klapperig" (auf beiden Spuren) ist, dann gehört er in
>den Schrott.

Nöö, auch wenn er keinen Wackelkontakt hat, ist das Ding nicht 
wasserdicht. Und nur weil das Ding bei dir in Einzelstückzahlen auf dem 
Steckbrett läuft, heisst das nicht automatisch, dass die Lösung 
wasserdicht ist.

>> Warum das so ist, steht im Artikel
>> Drehgeber.

>In diesem Artikel steht eine Menge theoretisches Blabla, aber nichts
>Konkretes praktisch Verwertbares (zumindest vor einiger Zeit, aktuell
>nachgesehen habe ich nicht).

Klasse, so kann man sich natürlich auch rausreden. Und nur weil du was 
nicht (auf Anhieb) verstehst, ist es noch lange kein theoretisches 
BlaBla . . . ;-)

>Anscheinend hast Du meinen Text nicht richtig gelesen und bist auf
>"Flanke" angesprungen. Mit "Auswertung der Flanke" meinte ich natürlich
>keinen externen Interrupt, sondern einen Vergleich zwischen Neuwert und
>Altwert bei zyklischer Abfrage (per Timer-Interrupt).

Ok, hab deinen Post nochmal genau gelesen.
Hast Recht ;-)
Das passt in dem Fall. Vielleicht sollte man das in den Artikel 
Drehgeber aufnehmen. Denn die ALPS & Co "Murksdrehgeber" sind ja nun mal 
recht verbreitet. Und der Verlust/Halbierung der Auflösung ist in diesem 
Fall sogar positiv, denn man erhält nur einen Puls pro Rastung, was im 
allgemeinen erwünscht ist.

MfG
Falk

Autor: Wurzel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So ich habe die LUT und die ISR noch etwas angepasst. Aber manchmal 
"springt" der Encoder vor und zurück wenn man in eine Richtung bewegt. 
Also macht er quasi 1,-1 vielleicht auch 1,0,-1 beim drehen in ein und 
die selbe Richtung.

Wo ist hier noch der Fehler? **ratlos**

#define PHASE_A    ((PIND & 1<<PD2)>>PD2)
#define PHASE_B    ((PIND & 1<<PD7)>>PD7)
#define KEY      ((PIND & 1<<PD6)>>PD6)
#define BOUNCE    20 //BOUNCE*Abtastrate der ISR=Prellzeit

volatile int8_t enc_delta;
volatile uint8_t key_pressed, key_state;
static int8_t lastA, lastB, recentA, recentB;
const int8_t decoder_lut[]={  0,
                -1,
                0,
                0,
                1,
                0,
                0,
                0,
                0,
                0,
                0,
                1,
                0,
                0,
                -1,
                0 
              };
                

ISR( TIMER0_COMP_vect )        
{
  uint8_t index;
  static uint8_t count;
  
  lastA = recentA;
  lastB = recentB;

  key_state = KEY;
  if(!key_state )
  {
    count++;
    if( count >= BOUNCE )
      key_pressed = 1;
  }  
  else
  {
    count = 0;
    key_pressed = 0;
  }

  

  recentA = PHASE_A;
  recentB = PHASE_B;

  index = ((lastA<<3)|(lastB<<2)|(recentA<<1)|(recentB)) & 0b00001111;
  enc_delta += decoder_lut[index];
}

P.S. in der ISR ist noch eine Entprellung des Encoder-Tasters eingefügt 
worden.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nimm mal als LUT:
0, 0, 1, 0, 0, 0, 0,-1,-1, 0, 0, 0, 0, 1, 0, 0
bzw. das Gegenstück:
0, 0,-1, 0, 0, 0, 0, 1, 1, 0, 0, 0, 0,-1, 0, 0

oder bei anderer Polung:
0, 1, 0, 0,-1, 0, 0, 0, 0, 0, 0,-1, 0, 0, 1, 0
bzw. das Gegenstück:
0,-1, 0, 0, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0,-1, 0

In Deinem oberen Beispiel hast Du Dich vermutlich beim Index verhaspelt, 
Du musst von 0 bis 15 zählen, Deinen Kommentaren nach hast Du von 1 bis 
16 gezählt... ;-)
Beitrag "Re: Hilfe zu Drehencoder-Auswertung nach Wiki"

Dein unteres Beispiel entspricht ja meinem unteren Vorschlag.
Beitrag "Re: Hilfe zu Drehencoder-Auswertung nach Wiki"
Wenn der Murks ist, dann müsstest Du mal meinen oberen Vorschlag 
umsetzen.

...

Autor: Rambo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ähm oben, unten... ich bin jetzt etwas durcheinander.

Ja ich habe den Code und die LUT geändert.

 enc_delta += decoder_lut[index*+1*];

Die Erhöhung des Index um 1 war ja falsch, weil ich ja dadurch nie das 
Element 0 aus der LUT erhalten kann (und 16te Element existiert ja nicht 
wie du schon erwähnt hast).

Also ich gehe jetzt mal davon aus, dass ich die vier LUTs in der letzten 
Codevariante ausprobieren soll. 
Beitrag "Re: Hilfe zu Drehencoder-Auswertung nach Wiki"

Autor: Rambo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich habe jetzt alle LUTs getestet, keine Besserung. :-(

P.S. ich meine natürlich das Element mit dem Index 16
>(und 16te Element existiert ja nicht wie du schon erwähnt hast)

Autor: Wurzel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe auch mit der Abtastzeit gespielt, hat aber auch nichts 
gebracht.(Name stimmt jetzt wieder ;-))

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Deinen C-Code kann (und will) ich nicht nachvollziehen. Meine Routine 
sieht so aus (Auszug, kein vollständiges Programm) und funktioniert:
;Drehgeber-Routine in AVR-Assembler für Panasonic-Drehgeber von Pollin.

;vereinbarte Konstanten:
.equ dgpin=pina             ;Drehgeberport-Eingänge
.equ dgneumsk=3             ;untere 2 Bits
.equ dgaltmsk=15            ;untere 4 Bits

;genutzte Register (Auszug):
.def null=r2                ;immer Null
.def dgz=r4                 ;Drehgeber-Zähler 
.def dgalt=r21              ;Drehgeber-Bitmuster alt + neu
.def wl=r24                 ;Working L
.def wh=r25                 ;Working H


drehgeber:          ;wertet Drehgeberbewegungen aus, Aufruf mit 1 kHz
 in wl,dgpin                ;Drehgeber-Port einlesen
 andi wl,dgneumsk           ;nur die benutzten 2 Bits werten
 lsl dgalt                  ;altes Drehgeber-Bitmuster
 lsl dgalt                  ;nach oben schieben
 or dgalt,wl                ;neue Drehgeberbits einblenden
 andi dgalt,dgaltmsk        ;Index auf 4 Bit begrenzen (uralt löschen) 
 ldi zl,low(dgtab*2)        ;Tabelle mit
 ldi zh,high(dgtab*2)       ;Dregheber-Increment-Werten
 add zl,dgalt               ;Index aufaddieren
 adc zh,null                ;Übertrag auch
 lpm wl,z                   ;Inkrement-Wert holen (0, +1 oder -1)
 add dgz,wl                 ;Drehgeber-Increment aufaddieren
 ret                        ;fertig, zurück...


/* ;Diese Polung ist deaktiviert...
dgtab:      ;Tabelle mit Drehgeber-Werten (alt-alt-neu-neu als Index)
                    ;aa nn,     aa nn
.db     0, 1        ;00 00,     00 01
.db     0, 0        ;00 10,     00 11
.db    -1, 0        ;01 00,     01 01
.db     0, 0        ;01 10,     01 11
.db     0, 0        ;10 00,     10 01
.db     0,-1        ;10 10,     10 11
.db     0, 0        ;11 00,     11 01
.db     1, 0        ;11 10,     11 11
*/

;Diese Polung ist aktiv:
dgtab:      ;Tabelle mit Drehgeber-Werten (alt-alt-neu-neu als Index)
                    ;aa nn,     aa nn
.db     0, 0        ;00 00,     00 01
.db     1, 0        ;00 10,     00 11
.db     0, 0        ;01 00,     01 01
.db     0,-1        ;01 10,     01 11
.db    -1, 0        ;10 00,     10 01
.db     0, 0        ;10 10,     10 11
.db     0, 1        ;11 00,     11 01
.db     0, 0        ;11 10,     11 11

...

Autor: Wurzel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also wenn ich mir den Assembler-Code ansehe, entspricht dies genau 
meiner Vorgehensweise im C-Code. :-/

Vielleicht liegt's doch am Drehencoder selbst. ???

Autor: screwdriver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hannes,

ich habe deinen Assemblercode nach Bascom portiert. Das Ergebnis 
arbeitet sehr sauber. Nur mit viel Mühe geht da mal eine Rastung 
verloren. Das hat mir so gut gefallen, das ich den Bascom-Quelltext dann 
hier (http://rn-wissen.de/index.php/Drehencoder) veröffentlicht habe.

Danke.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier der neue Abschnitt im Artikel Drehgeber

http://www.mikrocontroller.net/articles/Drehgeber#...

MFG
Falk

Autor: screwdriver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch der C-Code von Peter Dannegger hat mit diesen hier per Datenblatt 
vorgestellten "wackligen" Drehgebern, die in der Raststellung 
Signalwechsel haben, keine Probleme. Diese "Wackler" aber auch das 
sogenannte Pendeln wird durch die zyklich aufzurufende Anpassungsroutine
int8_t encode_read2( void )
herausgerechnet.

mfg
screwdriver

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  screwdriver (Gast)

>Signalwechsel haben, keine Probleme. Diese "Wackler" aber auch das
>sogenannte Pendeln wird durch die zyklich aufzurufende Anpassungsroutine

Nöö, das ist in deinem Fall Zufall. Denn die Umschaltung zwischen zwei 
Zuständen kann nämlich auch genau auf der Flanke liegen, auch bei read2 
oder read4.

MfG
Falk

Autor: screwdriver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
> Denn die Umschaltung zwischen zweiZuständen kann nämlich auch genau auf
> der Flanke liegen, auch bei read2 oder read4.

Das spielt keine Rolle.

Durch einen Pegelwechsel eines Encoder-Signals wechselt in PeDas 
Timer-ISR wohlwahr die Variable enc_delta zwischen +1 und -1. Und eine 
Auswertung des Encoders mit der Routine encode_read1 im Hauptprogramm 
würde dann auch dieses Pendelverhalten in der Variable val zeigen.
Die o.a. Encoder sind jedoch mit der Routine encode_read2 auszuwerten. 
Hier muß die Variable enc_delta jedoch größer 1 oder kleiner -1 sein, 
damit sich die Variable val im Hauptprogramm ändert.

Autor: Wurzel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:

Ich habe dem ALPS Encoder unrecht getan, er funktioniert jetzt sehr 
zuverlässig! Ursache war ein defekter Pin am ATmega16.

Autor: Wurzel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich bin's nochmal. Mit einer neuen Problemstellung:

Ich verwende den integrierten Taster des Drehencoders. Das Entprellen 
wie in meinem obigen funktioniert auch. Aber ich möchte jetzt 
unterscheiden zwischen kurz und lang gedrückt. Leider komme ich da nicht 
weiter. Den Code von PeDa 
http://www.mikrocontroller.net/articles/Entprellun... 
kapiere ich irgendwie wie nicht und ich bräuchte den ja auch nur für 
einen Taster und nicht einen ganzen port. :-(

Kann mir jemand helfen wie ich vorgehen sollte. Es muss kein fertiger 
Code sein, ich möchte ja auch noch was lernen. Danke euch im Vorraus.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wurzel schrieb:
> Hi,
>
> ich bin's nochmal. Mit einer neuen Problemstellung:
>
> Ich verwende den integrierten Taster des Drehencoders. Das Entprellen
> wie in meinem obigen funktioniert auch. Aber ich möchte jetzt
> unterscheiden zwischen kurz und lang gedrückt. Leider komme ich da nicht
> weiter.

So, Unterschied kurz/lang. Den erfährt man also erst beim Loslassen, 
denn aus kurz könnte ja noch lang werden... ;-)

Man erhöht also bei gedrückter einen Zähler, sorgt dafür, dass er nicht 
überläuft und wertet ihn beim Loslassen aus. Nach der Auswertung wird er 
natürlich wieder auf 0 gesetzt.

Betrachtet man jetzt die Zeiten und Wertebereiche so stellt man 
Folgendes fest:

Der Drehgeber wird im Zeitabstand von 1 ms abgefragt. Fragt man im 
selben Raster auch den Taster ab, so kann man mit einem Byte als Zähler 
maximal 255 ms als Tastendruckzeit darstellen. Das ist zuwenig. Man 
könnte nun 16-bittig zählen, dann müsste man aber auch 16-bittig 
auswerten. Das ist zwar kein Akt, aber nicht nötig. Denn man kann auch 
einen Vorteiler laufen lassen, der z.B. nur jede 16. Runde zuschlägt. 
Dann reicht das Byte des Zeitzählers bis zu 4 Sekunden.
Also etwa:
 inc vorteiler
 andi vorteiler,15
 brne weg_hier

 ;Tastenabfrage...
weg_hier:

Damit wird die Tastenabfrage dann nur noch alle 16 ms aufgerufen.

Beim Abfragen des Tasters gibt es zwei Zustände, Taster betätigt (L) und 
Taster unbetätigt (H). Die Tastenabfrage läuft ja auch im Interrupt. Um 
dem Hauptprogramm einen erfolgreichen Tastendruck mitzuteilen, werden 
noch zwei Bit als Merker gebraucht, das eine signalisiert den langen 
Tastendruck, das andere den kurzen. Gelöscht werden die Bits dann von 
der Mainloop, wenn zu zu dem Programmteil verzweigt, der den Tastendruck 
(den zugehörigen Job) abarbeitet.
 ;Tastenabfrage        ;Teil der Timer-ISR, Aufruf alle 16 ms
 inc tastenzeit            ;erstmal auf Verdacht erhöhen
 cpi tastenzeit,255        ;Endwert erreicht?
 brne tastenabfrage1       ;nöö, weiter...
 dec tastenzeit            ;ja, letzten Schritt zurücknehmen
                           ;der Zähler Tastenzeit kann somit nicht
                           ;überlaufen...
Tastenabfrage1:
 sbis tastenpin,tastenbit  ;ist Taste betätigt? - nein, auswerten...
 rjmp Tastenabfrage_end    ;ja, weg hier, denn Zählen u. Begrenzen ist
                           ;ja fertig...
 cpi tastenzeit,taste_lang ;Zeit für lang überschritten?
 brlo Tastenabfrage2       ;nein, weiter...
 sbr merker,1<<t_lang      ;ja, Merker für langen Tastendruck setzen
 rjmp Tastenabfrage3       ;und weiter...
Tastenabfrage2:
 cpi tastenzeit,taste_kurz ;Zeit für kurz (Entprellzeit) überschritten?
 brlo Tastenabfrage2       ;nein, weiter...
 sbr merker,1<<t_kurz      ;ja, Merker für kurzen Tastendruck setzen
Tastenabfrage3:
 clr tastenzeit            ;Tastenzeit löschen
Tastenabfrage_end:

Der Zähler "tastenzeit" wird also bei gedrückter Taste erhöht, wobei ein 
Überlauf verhindert wird. Bei ungedrückter Taste wird er zwar auch 
erhöht, fällt aber durch die Lang- und Entprell-Prüfung und wird wieder 
gelöscht. War zuvor die Taste lang genug gedrückt, so wird vor dem 
Löschen noch der zugehörige Merker aktiviert. Dieser wird vom 
Hauptprogramm geprüft und gelöscht.

> Den Code von PeDa
> 
http://www.mikrocontroller.net/articles/Entprellun...
> kapiere ich irgendwie wie nicht und ich bräuchte den ja auch nur für
> einen Taster und nicht einen ganzen port. :-(

Da der in C ist, ... ;-)

>
> Kann mir jemand helfen wie ich vorgehen sollte.

Ich hoffe, es ist verständlich genug erklärt.

> Es muss kein fertiger
> Code sein,

Naja, ist einfach so drauflos geschrieben, ist also nicht geprüft, es 
können durchaus Tippfehler drin sein.

> ich möchte ja auch noch was lernen. Danke euch im Vorraus.

...

Autor: Wurzel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich denke so wie du beschrieben hast, bin ich vorgegangen.
#define BOUNCE 20
#define LONG   100
#define KEY    ((PIND & 1<<PD6)>>PD6)

volatile uint8_t key_pressed, key_pressed_long;

//alle 1ms Interrupt
ISR( TIMER0_COMP_vect )        
{
  uint8_t index;
  static uint8_t count, count2;
  
  lastA = recentA;
  lastB = recentB;


  if(!KEY )
  {
    count++;
    if( count >= BOUNCE ) //20ms
    {
      key_pressed = 1;
      count = 0;
      count2++;
    }
    if( count2 >= LONG ) //20ms*100=2s
    {
      key_pressed_long = 1;
      count2 = 0;
    }
  }  
  else
  {
    count = 0;
    count2 = 0;
  }


  recentA = PHASE_A;
  recentB = PHASE_B;

  index = ((lastA<<3)|(lastB<<2)|(recentA<<1)|(recentB)) & 0b00001111;
  enc_delta += decoder_lut[index];
}

//Funktionen zum abfragen der Merker

uint8_t encoder_keypressed( void )
{
  uint8_t temp = key_pressed;
  key_pressed = 0;
  return temp;
}

uint8_t encoder_keypressedlong( void )
{
  
  uint8_t temp = key_pressed_long;
  key_pressed_long = 0;
  return temp;
}

Ich weiss ja das wir nicht die selbe Sprache sprechen, daher umschreibe 
ich die Tastenabfrage. ;-)

Die ISR wird alle 1ms aufgerufen. Wenn Taster gedrückt (L) dann wird 
count um 1 erhöht. Wenn count den Wert zum Entprellen erreicht hat, wird 
der Merker für kurze Tastenbetätigung gesetzt, count wieder null, und 
gleichzeitig der zweite Zähler count2 um 1 erhöht. Erreicht count2 den 
Wert für langes Drücken, wird auch hier der Merker gesetzt und count 
zurückgesetzt. Falls zwischendurch der Taster losgelassen wird, werden 
beide Zähler auf null gesetzt, d.h. um sicher zu gehen, dass die Zeiten 
eingehalten werden.
Die Abfrage der Merker erfolgt in der main() über die zwei Funktionen 
encoder_keypressed() und encoder_keypressedlong(). innerhalb dieser 
Funktionen werden die Merker wieder zurück gesetzt.

Soweit mein Code, aber irgendwie funktioniert dieser noch nicht richtig. 
:-/

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wurzel schrieb:
> Also ich denke so wie du beschrieben hast, bin ich vorgegangen.

Den C-Text kommentiere ich nicht...

> Ich weiss ja das wir nicht die selbe Sprache sprechen,

Naja, ich spreche die Sprache, die der AVR auch spricht (ASM ist eine 1 
zu 1 Umsetzung in Maschinencode) und die der Architektur des AVRs 
entspricht.

> daher umschreibe
> ich die Tastenabfrage. ;-)

Das ist gut...

>
> Die ISR wird alle 1ms aufgerufen. Wenn Taster gedrückt (L) dann wird
> count um 1 erhöht.

Gut.

> Wenn count den Wert zum Entprellen erreicht hat, wird
> der Merker für kurze Tastenbetätigung gesetzt, count wieder null, und
> gleichzeitig der zweite Zähler count2 um 1 erhöht.

Wenn man sich dabei bewusst ist, dass dies im Interrupt passiert, also 
(zeitlich) zwischendurch immer das Hauptprogramm läuft, dann erkennt 
man, dass das so nix wird. Denn das Hauptprogramm fragt ja die Merker ab 
und erkennt den Merker für kurzen Tastendruck, bevor die Taste wieder 
losgelassen wird. Der Merker für den kurzen Tastendruck darf also erst 
gesetzt werden, nachdem der Taster losgelassen wurde (also nachdem 
sicher ist, dass es kein langer Tastendruck mehr werden kann).

> Erreicht count2 den
> Wert für langes Drücken, wird auch hier der Merker gesetzt und count
> zurückgesetzt.

Der Count-Merker wurde indessen von Main erkannt, abgearbeitet und 
zurückgesetzt.

> Falls zwischendurch der Taster losgelassen wird, werden
> beide Zähler auf null gesetzt, d.h. um sicher zu gehen, dass die Zeiten
> eingehalten werden.

Zu umständlich, bei strikter Trennung in Vorteiler und Tastenzeit wird 
alles viel einfacher und als angenehmen Nebeneffekt funktioniert es 
sogar.

> Die Abfrage der Merker erfolgt in der main() über die zwei Funktionen

Ob man das in Funktionen auslagern muss, weiß ich nicht, darüber möchte 
ich auch nicht diskutieren. In ASM würde ich die Merker in der Mainloop 
abfragen
 sbrc merker,t_lang        ;trat ein langer Tastendruck auf? - nein...
 rcall langer_tastendruck  ;ja, abarbeiten...
 sbrc merker,t_kurz        ;trat ein kurzer Tastendruck auf? - nein...
 rcall kurzer_tastendruck  ;ja, abarbeiten...
(Je nach Struktur des Programms verzweige ich auch mal über "rjmp" und 
springe statt mit "ret" mit "rjmp mainloop" zurück. Aber das ist eine 
andere Baustelle und muss den C-Programmiierer nicht interessieren.)

... und im Unterprogramm zurücksetzen
 cbr merker,t_lang         ;Jobauftrag löschen, ist ja in Arbeit
und
 cbr merker,t_kurz         ;Jobauftrag löschen, ist ja in Arbeit

> encoder_keypressed() und encoder_keypressedlong(). innerhalb dieser
> Funktionen werden die Merker wieder zurück gesetzt.

Nur doof, dass der kurze Tastendruck bereits voreilig abgearbeitet 
wurde, ehe der lange Tastendruck überhaupt erkannt werden konnte.

>
> Soweit mein Code, aber irgendwie funktioniert dieser noch nicht richtig.
> :-/

Das ist auch kein Wunder, Dein Algorithmus entspricht ja nicht dem 
meinen und ist irgendwie auch nicht zu Ende gedacht. Sieh es aber bitte 
nicht als persönliche Beleidigung, nur irgendwie muss ich es ja (etwas 
direkt) formulieren, damit es verständlich wird.

Wenn mit Interrupts gearbeitet wird, sollte man Programme aus einer 
anderen Sicht betrachten. Die Tasten/Drehgeberabfrage erfolgt ja nicht 
in einer Schleife, in der verweilt wird, bis das Ergebnis vorliegt, 
sondern wird durch zyklusches "Vorbeischauen" und Erledigen nur eines 
Schrittes (entsprechend eines Schleifendurchlaufes) abgearbeitet. 
Zwischendurch ist immer wieder die Mainloop aktiv, bzw. einer ihrer 
Jobs. Gut, es wäre vermessen, dies bereits als "Multitasking" zu 
bezeichnen, aber es ist schon ein kleiner Schritt in diese Richtung...

...

Autor: Wurzel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hannes,

ich nehme deine Antwort nicht als beleidigend auf. ;-) Ich bin mir ja im 
klaren, dass mein Code fehlerhaft und wahrscheinlich Murks ist.

Ich möchte daher nochmal von vorne beginnen und meine Erkenntnisse aus 
deinen Beiträgen in einen Pseudocode zusammen fassen.
vorteiler = 8Bit
tastzeit = 8Bit

ISR alle 1ms:
{
vorteiler um eins erhöhen;
  wenn vorteiler gleich 16:
     dann tastenzeit um eins erhöhen
      und danach prüfen ob tastzeit = 255:
        falls ja: von tastzeit eins abziehen;

...
}
Bis hier hin bin ich noch gekommen, aber danach blicke ich bei deinem 
Assemblercode nicht mehr ganz durch. Wo kommt jetzt der Zustand 
(gedrückt/nicht gedrückt) des Tasters ins Spiel?
Sorry aber ich muss mir das Stück für Stück herleiten.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wurzel schrieb:
> Hallo Hannes,
>
> ich nehme deine Antwort nicht als beleidigend auf. ;-) Ich bin mir ja im
> klaren, dass mein Code fehlerhaft und wahrscheinlich Murks ist.
>
> Ich möchte daher nochmal von vorne beginnen und meine Erkenntnisse aus
> deinen Beiträgen in einen Pseudocode zusammen fassen.
>
> vorteiler = 8Bit
> tastzeit = 8Bit
> 
> ISR alle 1ms:
> {
> vorteiler um eins erhöhen;
>   wenn vorteiler gleich 16:
>      dann tastenzeit um eins erhöhen
>       und danach prüfen ob tastzeit = 255:
>         falls ja: von tastzeit eins abziehen;
> 
> ...
> }
> 
> Bis hier hin bin ich noch gekommen, aber danach blicke ich bei deinem
> Assemblercode nicht mehr ganz durch.

Du hast recht, da ist auch noch (mindestens) ein logischer Fehler drin. 
Ich hätte nur dann hochzählen dürfen, wenn der Taster betätigt ist. Das 
passiert nunmal, wenn man mal schnell etwas Code aus dem Hut schreibt 
und nicht vorher testet. - Sorry...

> Wo kommt jetzt der Zustand
> (gedrückt/nicht gedrückt) des Tasters ins Spiel?

Durch die Abfrage des Tastenpins:
 sbis tastenpin,tastenbit  ;ist Taste betätigt? - nein, auswerten...
 rjmp Tastenabfrage_end    ;ja, weg hier, denn Zählen u. Begrenzen ist
                           ;ja fertig...

SBIS überspringt den RJMP dann, wenn der Tastenpin H-Pegel hat, also der 
Taster nicht betätigt ist. Ist er betätigt, wirkt der Sprung (RJMP) zum 
Ende der Routine.

> Sorry aber ich muss mir das Stück für Stück herleiten.

In BASIC würde es in etwa so aussehen:
vorteiler = vorteiler + 1
if vorteiler >= 16 then             'nur jedes 16. mal
 vorteiler = 0
 if taste = 0 then                  'ist Taste betätigt?
  tastenzeit = tastenzeit + 1       'ja, hochzählen und
  if tastenzeit = 255 then tastenzeit = 254  'begrenzen
 else                               'Taste ist unbetätigt
  if tastenzeit > lang then         'war Taste lange betätigt?
   merker = set merker_lang         'ja, Merker "lang" setzen
  elseif tastenzeit > kurz then     'nein, nicht lang, war dann kurz?
   merker = set merker_kurz         'ja, Merker "kurz" setzen
  endif
  tastenzeit = 0                    'nach Auswertung immer löschen
 endif
endif

Ich hoffe, das ist verständlicher...

...

Autor: Rainier (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe den Code umgeschrieben nach C.
Allerdings klappt's noch nicht. Nutzt du nur einen merker dem du 
unterschiedliche werte (kurz und lang) zuweist?

Der merker wird ja bei der Abfrage vom Hauptprogramm wieder gelöscht, 
oder?

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rainier schrieb:

Wer nun? Rainer, Rambo oder Wurzel?

> Ich habe den Code umgeschrieben nach C.
> Allerdings klappt's noch nicht.

Dann hast Du etwas verändert. Ich vermute, Du hast das ELSEIF falsch 
interpretiert und setzt bei langem Tastendruck beide Merker...

> Nutzt du nur einen merker dem du
> unterschiedliche werte (kurz und lang) zuweist?

Ich nutze derzeit keinen Merker, da ich die Kurz/Lang-Unterscheidung 
bisher noch nicht brauchte. ;-)

Natürlich sollen für lang und kurz unterschiedliche Merker 
(Bitvariablen) genutzt werden, ansonsten könnte man sie ja nicht 
unterscheiden. In ASM nutze ich dazu ein Register, deren 8 Bits 
unterschiedliche Funktion haben. Jeder dieser Bits bekommt einen eigenen 
Namen und wird separat gesetzt und gelöscht. In C wird das nicht viel 
anders sein. Natürlich muss man sie so deklarieren, dass sowohl 
Hauptprogramm als auch ISR darauf zugreifen können.

>
> Der merker wird ja bei der Abfrage vom Hauptprogramm wieder gelöscht,
> oder?

Ja sicher doch. Die ISR setzt bei "Auftreten des Ereignisses" den zum 
Ereignis gehörenden Merker, das Hauptprogramm prüft und löscht dann die 
Merker bei der Ausführung des zugehörigen Jobs. Man kann die Merker in 
diesem Falle auch als "Jobflag" sehen, also ein Flag (Semaphore, Merker, 
Bitvariable, Schalter, RS-Flipflop), das anzeigt, das ein bestimmter Job 
zu erledigen ist (das Gegenstück dazu sind Merker, die einen Status 
anzeigen, der darüber entscheidet, wie ein Job erledigt werden soll).

...

Autor: Wurzel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sry, ich wurschtel hier an mehreren Rechnern rum. -> Wurzel

>Dann hast Du etwas verändert. Ich vermute, Du hast das ELSEIF falsch
>interpretiert und setzt bei langem Tastendruck beide Merker...

Nein, mache ich nicht:
  prescaler++;
  if( prescaler >= 16 )
  {
    prescaler = 0;
    if( !KEY )
    {
      button_down++;
      if( button_down == 255 )
        button_down = 254;
    }
    else
    {
      if( button_down >= LONG )
        key_pressed_long = 1;
      else if( button_down >= SHORT )
        key_pressed = 1;

      button_down = 0;
    }
  }

Ich verwende natürlich auch zwei Merker: key_pressed_long, key_pressed.
zurückgesetzt werden sie nachdem sie abgefragt wurden.

Hm, irgendwas ist noch fehlerhaft.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Hm, irgendwas ist noch fehlerhaft.

Gültigkeitsbereich der Variablen?

...

Autor: Wurzel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
prescaler und button_down sind static variablen in der ISR deklariert.
Die Marker key_pressed_long und key_pressed sind global definiert.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wurzel schrieb:
> prescaler und button_down sind static variablen in der ISR deklariert.
> Die Marker key_pressed_long und key_pressed sind global definiert.

Volatile?

Achnee, ich nehm's zurück, ich habe ja keine Ahnung von C...

...

Autor: Wurzel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, die Globalen sind volatile.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Wurzel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter

>Den Code von PeDa
>http://www.mikrocontroller.net/articles/Entprellun...
>kapiere ich irgendwie wie nicht und ich bräuchte den ja auch nur für
>einen Taster und nicht einen ganzen port. :-(

Autor: screwdriver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@hannes

Dein Code arbeitet wirklich gut. Er hat aber bekanntermaßen den 
Nachteil, das die Signalzuordnung nicht beliebig ist.

Wie wärs denn, wenn du nicht nur zwei Signalzustände auswertest, sondern 
drei. Bei drei Zuständen muß ja mindestens einmal der stabile 
dabeigewesen sein. Somit wäre deine Sprungtabelle um 2bit länger, also 
4mal so lang, aber was solls, die Abarbeitungszeit bleibt ja gleich. Das 
Wackeln und Zappeln hätte dann auch bei falscher Signalzuordnung ein 
Ende! Dann sollte doch die Auswertung unabhängig von der Signalzuordnung 
sein, oder?

mfg
screwdriver

Autor: Rudi D. (rulixa)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hannes Lux schrieb:
> lsl dgalt                  ;altes Drehgeber-Bitmuster
> lsl dgalt                  ;nach oben schieben

Ich habe mit sehr gutem Erfolg deine Routine verwendet.
Ich verwende jedoch 2x lsr, da dann "urold" von selbst im Nirvana 
verschwindet. Die 2. Tabelle habe ich noch selbst abgeleitet.
Sie verwendet ja Übergänge zwischen den Rastpunkten und funktioniert 
deshalb so perfekt.

Siehe attachments

LG Rudi

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rudi D. schrieb:
> Ich verwende jedoch 2x lsr, da dann "urold" von selbst im Nirvana
> verschwindet.

Da bei mir der Drehgeber an den Bits 0 und 1 liegt, wäre Rechtsschieben 
recht sinnfrei. Bei Dir liegt der Drehgeber an Bit 2 und 3, da ist 
Rechtsschieben natürlich besser.

> Die 2. Tabelle habe ich noch selbst abgeleitet.
> Sie verwendet ja Übergänge zwischen den Rastpunkten und funktioniert
> deshalb so perfekt.

Es gibt viele Varianten, wie man die Drehgeberbits anordnen kann. Jede 
Variante erfordert natürlich eine eigene Tabelle. Für 
Copy&Paste-Programmierer ist das natürlich nix, aber wenn man die 
Funktion verstanden hat, dann ist das ja kein Problem. Anschlussbelegung 
und Tabelle ist für mich kein Dogma, ich habe da auch verschiedene 
Varianten im Einsatz. Auch Varianten, die mit nur einem Shift auskommen 
(Bit 0 und 2 oder 1 und 3).

Es gibt da auch eine Variante, bei der zwei Drehgeber angeschlossen sind 
(Bit 0 und 1, sowie 4 und 5). Jedes Nibble enthält die Bits "seines" 
Drehgebers. Die Überträge beim Schieben werden vor dem ORen der neuen 
Bits ausgeANDet.

>
> Siehe attachments
>
> LG Rudi

Noch 'n Tipp: Wenn Du gute preiswerte Alps-Drehgeber suchst, dann schau 
mal hier vorbei:
http://stores.ebay.de/Logo-s-Elektronik-Kiste_Enco...

Dagegen ist der Pollin-Drehgeber Wucher... ;-)

...

Autor: Rudi D. (rulixa)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hannes Lux schrieb:
> Auch Varianten, die mit nur einem Shift auskommen
> (Bit 0 und 2 oder 1 und 3).

Verstehe ich in der Eile nicht.
Danke für die Alps Quelle.
Da ist die Anwendung mit 2x t2313.

LG Rudi

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rudi D. schrieb:

> Verstehe ich in der Eile nicht.

Anschluss von Spur A an Bit 0 und Spur B an Bit 2:

Bit 0: Spur A neu
Bit 1: Spur A alt
Bit 2: Spur B neu
Bit 3: Spur B alt

...

Autor: Rudi D. (rulixa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hannes Lux schrieb:
> Rudi D. schrieb:
>
>> Verstehe ich in der Eile nicht.
>
> Anschluss von Spur A an Bit 0 und Spur B an Bit 2:
>
> Bit 0: Spur A neu
> Bit 1: Spur A alt
> Bit 2: Spur B neu
> Bit 3: Spur B alt
>
> ...

Danke, bis zum nächsten mal
LD Rudi

Autor: rudi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
was stimmt an der routine nicht?

void CheckEncoder(void)
{
  stateA = ENCODER_A;
  stateB = ENCODER_B;

  if ((stateA_old == 0) && (stateB_old == 1) && (stateA == 1) && (stateB 
== 1)//CW
    ||(stateA_old == 1) && (stateB_old == 0) && (stateA == 0) && (stateB 
== 0))
  {
    counter++;
  }
  if ((stateA_old == 0) && (stateB_old == 0) && (stateA == 1) && (stateB 
== 0)//CCW
    ||(stateA_old == 1) && (stateB_old == 1) && (stateA == 0) && (stateB 
== 1))
  {
    counter--;
  }

  ENC_change=1;
  upd_lcd =1;

  stateA_old = stateA;
  stateB_old = stateB;
}


verwende den panasonic encoder und habe schon timer und 
irq_on_pin_change versucht. beides liefert unbrauchbare ergebnisse.

gruß rudi

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.