Hallo,
habe inzwischen eine kleine Testschaltung aufgebaut, in der ich u.a.
einen Drehencoder (STEC12E06 vom großen R) betreibe. Ich habe ihn
"falsch herum" eingebaut, d.h. er hat pulldown-Widerstände bekommen.
Zur Auswertung nehme ich die Graustufenbestimmung von Peter Dannegger
(aus der Codesammlung) in Verbindung mit einem Timer-Interrupt.
Laut Datenblatt sollen die Prellungen unter 3 ms liegen - ich betreibe
also die Tina mit Original 1 MHz intern und den Timer mit Vorteiler 8 =>
alle 2 ms einen Timer Überlauf. Um über die 3 ms Samplezeit zu kommen,
prüfe ich den Drehencoder nur alle paar Überläufe (habe jetzt von 2-8
ausprobiert).
Im Moment sieht es so aus, als ob 4 Pulse pro Rasterung kommen.
Das ziemlich stabil vor und zurück. Ich gebe den Zähler auf einer
Segmentanzeige aus und wenn ich den Encoder ganz langsam von einer Raste
zur nächsten drehe, sehe ich, dass ich kein Problem mit der Anzeige
habe. Es werden alle einzelen Werte angezeigt. In Normaltempo gedreht
tanzt er Diskofox.
Alternativ habe ich auch mal probiert, den Timer mit Vorteiler 64 zu
fahren, dann verliere ich allerdings Takte, d.h. ich muss unkontrolliert
drehen um einen Schritt weiter zu kommen.
Wie kann ich denn hier wieder zu verlässlichen Einzelschritten kommen?
Muss ich dem Encoder noch irgendwelche analogen Bauteile spendieren,
oder habe ich schlicht einen falschen Encoder gekauft?
Santiago wrote:
> Im Moment sieht es so aus, als ob 4 Pulse pro Rasterung kommen.> Das ziemlich stabil vor und zurück.
Dann funktioniert er doch richtig.
Der Code liefert die Differenz zur letzten Lesung.
Um größere Wertebereiche zu erzielen, muß man dieses Delta z.B. zu nem
16Bit Wert signed addieren.
So, nun hast Du die 4-fache Pulszahl, also den 16Bit Wert zur Ausgabe
durch 4 teilen und gut is.
Wenns beim schneller Drehen falsch zählt, dann die Timerinterruptzeit
verringern, 3ms ist schon ziemlich viel.
Das Entprellen macht nicht das Timerintervall, sondern der Algorithmus.
Dazu muß er aber alle 4 Phasen zuverlässig einlesen können.
Peter
Hallo Peter,
danke für Deine Unterstützung.
> So, nun hast Du die 4-fache Pulszahl, also den 16Bit Wert zur Ausgabe> durch 4 teilen und gut is.
Ich habe eine Anwendung, in der ziemlich viele (kleine) Werte geändert
werden sollen, deshalb hatte ich bislang die Zähler in einem Bitfeld
angeordnet.
Manche Werte sind 6bittig, andere nur 1bittig ...
... letztere sind nicht gerade prädestiniert, mittels Encoder
eingestellt zu werden, wenn man dadurch aber alle Taster spart ...
Jetzt alle Zähler um das 4fache erhöhen verbraucht doch ziemlich viel
Speicher (der nichtmal sinnvoll verwendet wird). Das ist schon eher
ärgerlich ;)
Gibt es (empfehlenswerte und erhältliche) Encoder, die nur einen Puls
per Raste erzeugen?
> Wenns beim schneller Drehen falsch zählt, dann die Timerinterruptzeit> verringern, 3ms ist schon ziemlich viel.
OK, danke für die Hausnummer. Ohne Erfahrung ist es nicht leicht, die
richtige Richtung zu finden.
> Das Entprellen macht nicht das Timerintervall, sondern der Algorithmus.> Dazu muß er aber alle 4 Phasen zuverlässig einlesen können.
Das hatte ich schon so verstanden.
Werde trotzdem mal eine schnellere Abtastung ausprobieren.
Santiago wrote:
> Ich habe eine Anwendung, in der ziemlich viele (kleine) Werte geändert> werden sollen, deshalb hatte ich bislang die Zähler in einem Bitfeld> angeordnet.> Manche Werte sind 6bittig, andere nur 1bittig ...> ... letztere sind nicht gerade prädestiniert, mittels Encoder> eingestellt zu werden, wenn man dadurch aber alle Taster spart ...
Dann schau Dir mal das Assemblerlisting an, welche Codemonster Dir
daraus der Compiler basteln muß.
Es ist unsinnig, um ein Bit SRAM zu feilschen und dafür 100 Byte mehr
Code zu haben, die AVRs haben massig SRAM.
Nimm für 1..6 Bit ein Byte, für 7..14 Bit 2 Byte als Zählvariable und
gut is. Dann zur Ausgabe 2*rechts schieben, damit der Wert /4 geteilt
wird.
Peter
Hallo Peter,
> Dann schau Dir mal das Assemblerlisting an, welche Codemonster Dir> daraus der Compiler basteln muß.
Äh - meinst Du jetzt aus den Bitfeldern?
> Es ist unsinnig, um ein Bit SRAM zu feilschen und dafür 100 Byte mehr> Code zu haben, die AVRs haben massig SRAM.
Hm - ich feilsche gerade mit einem tiny2313 herum - so üppig ist das mit
dem Speicher imho nicht. Aber bis ich Assembler nicht nur lesen, sondern
auch schreiben/denken kann, fließt noch viel Wasser den Bach runter.
> Nimm für 1..6 Bit ein Byte, für 7..14 Bit 2 Byte als Zählvariable und> gut is. Dann zur Ausgabe 2*rechts schieben, damit der Wert /4 geteilt> wird.
Ok, werde mir das mit den Bitfeldern mal genauer anschauen.
Das mit dem Schieben hatte ich sowieso schon drin, weil meines Wissens
die Tina sich mit dem Multiplizieren schwer tut.
Bleibt noch die Frage, ob mir nicht jemand einen Encoder empfehlen kann,
der nur einen Puls pro Rasterung liefert?
