Drehgeberauswertung nach Peter Dannegger

[Ralf (Gast)]

Hallo,

eine Frage zu Peter Danneggers Drehgeberauswertung von hier:

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

Mein Geber hat hat 30 Raststellen. Eigentlich verhält er sich exakt wie 
im Diagramm des Artikels angegeben.

Unabhängig davon welche der drei Funktionen ich Aufrufe mein Ergebnis 
ist nach einer Umdrehung IMMER 60!?

Ich hätte erwartet, wenn ich encode_read2( void ) aufrufe bekomme ich 
als Ergebnis 1 Schritt pro Rastpunkt! Das wären dann 30 Schritte pro 
Umdrehung...genau soviele wie Rastpunkte.

Wo ist denn mein Denkfehler?

Danke und Gruß


Ralf

[Michael G. (graf)]

Hi

ggf hilft das

L L Rast punkt
L H
H H Rast punkt
H L 
L L Rast Punkt

man erkennen und zählt jeden übergang. Da der Dregeber nur an 2 der 4 
punkte rastet, erkennst du doppelt so viele übergänge als rastpunkte.

[Ralf (Gast)]

Hi,

ja das ist klar. Ich dachte nur genau um das auszugleichen wäre die 
Funktion encode_read2( void ) da. Bzw. auch die encode_read4( void ) 
falls er nur alle 4 Takte Rastet. Das wäre dann alle LL Zustände.



Gruß Michael

[Peter D. (peda)]

Ralf wrote:
> Unabhängig davon welche der drei Funktionen ich Aufrufe mein Ergebnis
> ist nach einer Umdrehung IMMER 60!?

Warscheinlich hast Du nen Fehler eingebaut und es wurde kein neues Hex 
erzeugt, d.h. Du hast 3-mal das gleiche Hex geflasht.


Peter

[Ralf (Gast)]

Hallo Peter,

ich danke Dir für Deine konstrukitve Unterstützung. Wahrscheinlich 
überprüfst Du Deinen Quellcode auch noch einmal gründlich ;-)

Wie auch immer ich schau es mir noch einmal in Ruhe an...oder machs 
besser gleich selber :-))

Gruß Ralf

[Peter D. (peda)]

Ralf wrote:
> ich danke Dir für Deine konstrukitve Unterstützung. Wahrscheinlich
> überprüfst Du Deinen Quellcode auch noch einmal gründlich ;-)

Ja, das tue ich bei den Codebeispielen.
Und es muß mindestens noch einer geprüft haben, das "Solide Lösung" habe 
nämlich nicht ich geschrieben.

Du kannst auch gerne andere C-Programmierer fragen, sie werden Dir 
bestätigen, daß bei:

return val;
return val >> 1;
return val >> 2;

niemals das gleiche rauskommen kann.


Peter

[Ralf (Gast)]

Hey Peter,

daran zweifel ich auch sicher nicht.
Dann würde ich schon eher daran zweifeln, dass mit

enc_delta = 0;
enc_delta = val & 1;
enc_delta = val & 3;

die gleiche Eingangsbedingung für die Timerfunktion gilt.

Allerdings schreibst Du irgendwo, dass Du die beiden unteren Bits 
bewusst maniplierst. Also wird es daran auch nicht liegen.


Gruss Michael

[Benedikt K. (benedikt)]

Peter Dannegger wrote:

> Du kannst auch gerne andere C-Programmierer fragen, sie werden Dir
> bestätigen, daß bei:
>

> 
> return val;
> return val >> 1;
> return val >> 2;
> 
>

> niemals das gleiche rauskommen kann.

Kann es sein, dass das trotzdem falsch (bzw. nicht ganz richtig) ist?
Vermutlich willst du die Werte durch 2 und durch 4 teilen, aber das 
macht >> 1 und >> 2 nicht richtig bei negativen Werten.
Ob der kleine Unterschied zum mathematisch korrekten Ergebnis allerdings 
in dieser Anwendung eine Auswirkung auf hat, habe ich mir nicht genauer 
angeschaut. Ist mir nur gerade aufgefallen, auf sowas fällt man ja 
schnell mal rein.

[Peter D. (peda)]

Es ist mir auch schonmal passiert, daß ich ein falsches Hex geflasht 
habe.

Lösche es nach dem Flashen und mache vor dem nächsten Flashen ein 
Verify, dann weißt Du, daß Du auch wirklich ein neues Hex flashst.


Peter