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?
Thread beobachten
Seitenaufteilung abschaltenBitte 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.