Bitmuster erkennen und vergleichen

Miramare schrieb:
> Schiebe die 2 Bits einfach nacheinander in ein 8-Bit Register und
> vergleiche dann den Wert als Unsigned Int.
>
> 1: 11 10 01 11 = 0xE7 = 231
> 2: 11 01 10 11 = 0xDB = 219

damit weiss er vllt 30% dessen was er wissen muss solltest ihm vllt noch 
den Rest offenbaren

Jasper schrieb:
> soll sie nach vier Zustandsänderungen
> auf zwei Möglichkeiten überprüfen:

Das bis 4 Zählen hat schwerwiegende Nachteile. Der Drehgeber darf nicht 
prellen und der Benutzer muß immer schön brav von Rastpunkt zu Rastpunkt 
drehen.
Übliche Drehgeberroutinen werten daher nicht die Anzahl der Änderungen, 
sondern die Zustände selber aus. Ein Prellen wird damit sofort wieder 
abgezogen bzw. ein Richtungswechsel ist an beliebigen Positionen 
erlaubt.

Jasper schrieb:
> Ich stehe gerade auf dem Schlauch und bitte um einen Vorschlag.
> Vermutlich ist es trivial.
>
> Ein AVR wertet zwei Pins aus und soll sie nach vier Zustandsänderungen
> auf zwei Möglichkeiten überprüfen:
>
> Möglichkeit 1:
> PIN 1  PIN 2
>
> 1      1
> 1      0
> 0      1
> 1      1
>
> Möglichkeit 1:
> PIN 1  PIN 2
>
> 1      1
> 0      1
> 1      0
> 1      1
>
> Wie kann ich das prüfen?

Nimm 2 Positionsvariablen die bei 0 starten
wenn die aktuelle Kombination mit der für die beiden Möglichkeiten 
übereinstimmt dann inkrementiere die Positionsvariable
hat sie den Wert 4 erreicht dann hast du einen Treffer gefunden
wenn die aktuelle Kombination nicht übereinstimmt dann setze die 
Positionsvariable zurück auf 0.

Peter D. schrieb:
> Das bis 4 Zählen hat schwerwiegende Nachteile. Der Drehgeber darf nicht
> prellen und der Benutzer muß immer schön brav von Rastpunkt zu Rastpunkt
> drehen.
> Übliche Drehgeberroutinen werten daher nicht die Anzahl der Änderungen,
> sondern die Zustände selber aus. Ein Prellen wird damit sofort wieder
> abgezogen bzw. ein Richtungswechsel ist an beliebigen Positionen
> erlaubt.

Prellen musst du natürlich vorher schon entsprechend vermeiden!

Jasper schrieb:
> Ein AVR wertet zwei Pins aus und soll sie nach vier Zustandsänderungen
> auf zwei Möglichkeiten überprüfen
Warum musst du da auf 4 Zustandsänderungen warten (wobei sowieso nur 3 
Änderungen zwischen diesen 4 Zuständen sind...)

Jasper schrieb:
> Wie kann ich das prüfen?
Was soll passieren, wenn ein anderes Bitmuster hereinkommt? Oder wenn 
der Wechsel von 01 oder 10 über 00 bzw 11 geht (das tut er für ein paar 
ns sicher, denn diese beiden Signale kommen garantiert nicht 
gleichzeitig an den AVR-Pins an).

Also müssen dei Eingangssignale erst mal konditioniert (aka entprellt) 
werden. Danach kommt die Erkennung, ob sich was geändert hat, dann kommt 
die FSM, die abhängig von der Änderung weiterschaltet.

BTW: musst du da unbedingt alle 3 Zustandswechsel abwarten? Wenn nicht, 
dann wäre das Programm recht einfach. Kommend von 11 müsstest du nur 
jeweils abfragen, ob eines der beiden Bits auf 0 geht, und dann wieder 
warten, bis beide (entprellten) Eingänge 11 sind.

Wie schnell wechseln da eigentlich die Zustände?

Ich hatte da was von Entprellen geschrieben. Das war ernst gemeint. Denn 
wenn die Eingänge nicht absolut zeitgleich wechseln (und das tun sie 
nicht!), dann geht das simple direkte Abfragen früher oder später 
schief. Nach Murphy wird das Problem laufend auftreten...

Und nochmal schrieb im Beitrag #5908221:
> Wo war von einem Drehgeber die Rede?
Keine Ahnung. Ich habe nichts derartiges ins Gespräch gebracht.

> Wo war von Prellen die Rede?
Es ist die Rede von asynchronen Eingängen eines uC , die gemeinsam 
abgefragt werden sollen, als ob sie gleichzeitig den Pegel zum jeweils 
anderen Potential wechseln würden. Das tun sie nicht. Ein Übergang von 
01 nach 10 geht zwangsläufig für ein paar ns über 00 oder 11. Immer. Und 
wenn gerade dann die Eingänge eingelesen werden, dann... ja, was dann?

Und mit "Entprellen" ist hier gemeint, dass mindestens 2 Abfragen 
hintereinander an beiden Pins zusammen das selbe Bitmuster anliegen 
muss. Damit wird das oben beschriebene Problem behoben.

Den Rest des Posts lasse ich besser mal unkommentiert...

Lothar M. schrieb:
> Ein Übergang von
> 01 nach 10 geht zwangsläufig für ein paar ns über 00 oder 11. Immer.

Nicht wenn ich (oder besser, Jasper, der TO ;-)) die beide Pins nur jede 
10ms pollt. Aber auch dann kann es natürlich passieren, dass der Weg 
von 01 zu 10 nicht über Los geht.

Eric B. schrieb:
> Nicht wenn ich (oder besser, Jasper, der TO ;-)) die beide Pins nur jede
> 10ms pollt
Wahrscheinlich... ?
Wenn alle 10ms gepollt wird und die undefinierte Transision 10ns dauert, 
dann geht rechnerisch 1 von 1 Million Abfragen schief. Wenn Murphy 
mitmacht, dann passiert das immer Donnerstags nach der Frühstückspause. 
Aber garantiert nicht dann, wenn man gerade den Fehler sucht.

Deshalb verhindert man so einen Fehler einfach, indem man die 
Wahrscheinlichkeit aus dem Spiel nimmt.

Ich würde es folgendermaßen machen:

Falls ich irgendwas periodisch abfragen wollen würde, stünde in der 
init:

1

#define MUSTER_A 0b11100111

2

#define MUSTER_B 0b11011011

3

...

4

unsigned char input_folge = 0, matched_muster = 0;

5

unsigned char *input_pointer = &input_folge;

In der loop:

1

if (timer_10ms_flag)

2

    matched_muster = ExamineInputs(input_pointer);

und die Funktion ExamineInputs sähe so aus:

1

unsigned char ExamineInputs (unsigned char *input_pointer) {

2

    *input_pointer = ((PORTB&(1<<PB3))&(*input_pointer)>>1);

3

    *input_pointer = ((PORTB&(1<<PB7))&(*input_pointer)>>1);

4

    if (((*input_pointer) == MUSTER_A)||((*input_pointer) == MUSTER_B))

5

        return 1;

6

    else

7

        return 0;

wobei hier exemplarisch PORTB und Pins PB3 und PB7 gewählt wurden. Es 
lässt sich beliebig verkomplizieren oder auch etwas leichter machen, 
wenn man die Variable input_folge als global deklariert - dann müsste 
man nicht mit Pointern rumwerfen und das Programm wäre noch 
übersichtlicher.

Viktor B. schrieb:
> Ich würde es folgendermaßen machen
Das funktioniert aber bestenfalls mur genau dann, wenn die Eingänge den 
Pegel immer zuverlässig mitten in dem 10ms Raster wechseln.
Mal angenommen, der zeitliche Abstand zwischen 2 Zustandsänderungen 
schwankt beliebig zwischen 5 und 50ms. Oder zwischen 2 und 200ms. Oder 
zwischen 9 und 11ms. Was dann?
Oder schlimmer noch: die Eingänge ändern sich mit exakt 10,1ms Abstand. 
Dann geht es 100 mal gut, aber dann rasselt es...

Fazit: der Automat, der hier benötigt wird, hat prinzipiell keine 
zeitliche Abhängigkeit, sondern seine Reaktion hängt nur von Änderungen 
seiner Eingänge ab.

Lothar M. schrieb:
> seine Reaktion hängt nur von Änderungen
> seiner Eingänge ab.

Dann würde man das mit Pin change Interrupts machen und hätte das 
Problem, dass die Pins zwichen dem Zustand 1,0 und 0,1 kurz durch 1,1 
oder 0,0 gehen.

Vielleicht würde es besser gehen, wenn man jede 1 ms sampelt und dann 
unterscheidet, ob sich die Eingänge geändert haben oder nicht. Ist aber 
ziemlich viel Overhead.

Upd.: Wie ich sehe, hat der TO schon ein funktionierendes Programm. Dann 
lohnt es sich ja nicht wirklich, mein Beispiel zu aktualisieren

Jasper schrieb:
> Von daher dachte ich
Ich würde das mit.einem Oszilloskop messen. Soooo arg teuer sind die 
Dinger gar nicht... ?
Denn eigentlich kannst du nur etwas  das du kennst, wirklich 
zuverlässig auswerten.

Jasper schrieb:
> Das funktioniet bisher ohne Probleme.
Ist ja auch kein Wunder. Das ist ja ganz im Gegensatz zu der "war nur 
exemplarisch gemeint"en Frage aus dem Eröffnungspost ein Gray-Code, bei 
dem "aus Gründe" eben niemals 2 Bits gleichzeitig wechseln. Und 
deshalb die ganzen Probleme mit dem Übergang von 01 nach 10 (oder 10 
nach 01) niemals auftreten können.