Wieviele Drehencoder kann ein atmega8 auswerten?

Einen ATtiny13 pro Encoder und dann jeweils 20 davon per SPI mit nem 
ATMega8 auslesen.


Peter

@ tombaer (Gast)

>Kann man diese Aufgabe mit EINEM Atmega8-16Mhz lösen oder sollte man
>besser mehrere Atmegas einsetzen (z.B. 32 Encoder pro Atmega,
>Übermittlung der Daten über I2C an einen Zentralatmega, usw.)?

Hmm. Mal rechnen.

Sagen wir mal eine Abtastrate von 200 Hz, mach 5ms pro Abtastperiode. In 
dieser Zeit müssen 200x3 = 600 Bit seriell eingelesen werden. Das dauert 
bei 16 MHz Takt und Hardware SPI ca. 75us, mit Softwareoverhead 
vielleicht 100us. Bleiben für die Auswertung pro Encoder ca. 
4,9ms/200=~25us, was bei 16 MHz Takt 400 Takten entspricht. Puhhh, da 
ist der AVR schon ziemlich ausgelastet, in BASCOM wird das wohl eher 
knapp. C und ASM sollten das schaffen. In BASCOM sollte man pro AVR 
vielleicht nur 50 Encoder auswerten, macht dann 4+1 AVR.

MFG
Falk

@ Peter Dannegger (peda)

>Einen ATtiny13 pro Encoder

Ist das nicht ein wenig Overkill?

Mfg
Falk

@Falk: Diese Drehencoder müssen häufiger ausgelesen werden, das 
Datenblatt garantiert nur eine Phasenverschiebung der beiden Ausgänge 
von 2.5 ms - 500 bis 1000 Hz sind also Pflicht.

Je nach Aufwand der Midi-Übertragung würde ich also zwei bis vier mega8 
vorschlagen.

@  Jan M. (mueschel)

>@Falk: Diese Drehencoder müssen häufiger ausgelesen werden, das
>Datenblatt garantiert nur eine Phasenverschiebung der beiden Ausgänge
>von 2.5 ms - 500 bis 1000 Hz sind also Pflicht.

Naja, kommt immer auf die Drehzahl an. Wie schnell kann man die Dinger 
sinnvoll maximal drehen und wieviele Pulse/Umdrehung geben die aus?

MFG
Falk

@Falk: Die Angabe bezieht sich auf 60 U/min, also eine Umdrehung pro 
Sekunde. Wenn man nur eine Viertel Umdrehung macht (= 4 Schritte = 8 
Zustandsänderungen) und ohne mitzuzählen "einfach mal ein Stück dreht" 
ist man deutlich schneller.

Ich würde als Konzept mehrere Tiny2313 vorschlagen, die jeder 4 oder 5 
Drehencoder abfragen und per "wired OR" UART an einen Mastercontroller 
melden, der sie zyklisch abfragt. So kann man Peters Idee vielleicht 
materialsparender umsetzen. Als Drehencoder würde ich keinesfalls zu den 
Panasonic-Teilen von Pollin raten, sondern eher zu den PEC11 von 
CSD-Electronics. Die haben ein schwächeres Rastmoment und ein besseres 
Feeling, außerdem eine bessere Kontaktqualität. Die Abfrage bei den 
PEC11 sollte in einem Raster von 1ms erfolgen, um auch schnelle 
Bewegungen mitzubekommen.

Warum eigentlich nicht irgendwelche programmierbaren Logic-ICs oder auf 
andere Weise das ganze realisieren?

200 Drehencoder sind schon ne Menge. Allein die Verkabelung bzw. Platine 
wird nen schönes Ding :D

@ Erik D. (Firma privat) (dareal)

>Warum eigentlich nicht irgendwelche programmierbaren Logic-ICs oder auf
>andere Weise das ganze realisieren?

Hmm, gute Idee. Ein kleiner FPGA + Schieberegister zur Porterweiterung 
könnte das spielend schaffen. Und wenn man dort noch nen kleinen uC 
reinsetzt, ist ein ein schönes System on a Chip (SoC).

MfG
Falk

Falk Brunner wrote:

> Naja, kommt immer auf die Drehzahl an. Wie schnell kann man die Dinger
> sinnvoll maximal drehen und wieviele Pulse/Umdrehung geben die aus?

Ich bin mittlerweile auf etwa 5kHz hoch gegangen mit der Abtastrate. 
Dann kann man schon relativ schnell drehen. Man kann aber immer noch 
ohne großen Aufwand so schnell drehen, dass die Software Impulse 
überspringt. Unter 1kHz braucht man bei den Pollin Drehgebern garnicht 
erst anfangen.
Bei größeren Anzahlen würde ich daher auch zu einer Hardwarelösung 
greifen, alleine schon wegen den Pins.

Welcher Synthie soll es denn sein und was willst Du eigentlich senden 
(ein Control Change oder kennt der Synthie auch ein Data 
Increment/Decrement)? Soll die Drehbank ein kleines Display oder 
LED-Kränze besitzten?

Gibt es denn vllt. sogar fertige Auswertungs-ICs für Drehencoder?

Wie funktionieren solche programmierbaren Logiken und wie werden sie 
programmiert?

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

Wenn man den Aufbau modular gestaltet, dann ist die Verkabelung auch mit 
der Mehr-Controller-Variante sehr moderat: 5V, Masse und Daten. Die 
Leitungen treffen sich auf der Hauptplatine, können als Ring- oder 
Stichleitung ausgeführt werden. Zusätzlich zum Abfragen der Drehencoder 
kann der Einzelcontroller dem Anwender noch einige Lichtsignale über 
LEDs darstellen, was der intuitiven Bedienung zuträglich ist. Bei einem 
einzigen Logik-IC mit hunderten von Pins wird die Verkabelung sicher 
noch wuliger (3 Leitungen zu jedem Encoder) und ist eigentlich nur auf 
einer großen Hauptplatine, auf die dann alle Drehencoder aufgelötet 
werden, zu beherrschen. Das hat aber wieder mechanisch gesehen 
Nachteile. Weiterhin arbeiten die meisten CPLDs oder FPGAs mit kleineren 
Betriebsspannugen (3.3 oder 2.5V), so daß man für die Anbindung an den 
Hauptcontroller Pegelwandler benötigt. Modulbauweise hat sich bei 
Audiotechnik bewährt, da man im Fehlerfall sozusagen on-the-fly auf der 
Bühne schnell mal ein paar Module auswechseln kann ;-).