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
Hi ggf hilft das
1 | L L Rast punkt |
2 | L H |
3 | H H Rast punkt |
4 | H L |
5 | 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.
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
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
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
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:
1 | return val; |
2 | return val >> 1; |
3 | return val >> 2; |
niemals das gleiche rauskommen kann. Peter
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
Peter Dannegger wrote: > Du kannst auch gerne andere C-Programmierer fragen, sie werden Dir > bestätigen, daß bei: >
1 | >
|
2 | > return val; |
3 | > return val >> 1; |
4 | > return val >> 2; |
5 | >
|
6 | >
|
> 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.
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.