Hallo zusammen! Zuerst wollte ich anmerken, dass ich noch keine praktische Erfahrung mit der Programmierung von Mikrokontrollern habe. Literatur, Soft- und Hardware sind aber schon vorhanden ;). Meine Frage ist daher vorerst noch rein theoretischer Natur. Aufgabe: Ich möchte einen Midi-Controller bauen, der einen Musiksynthesizer steuern soll. Es sollen Panasonic-Drehencoder von Pollin verwendet werden, die über serielle Schieberegister 74HC165 abgefragt werden (links, rechts und Taster). Nach Auswertung und Entprellung soll der entsprechende Parameter überprüft, verändert und über Midi an den Synthie gesendet werden. Da der Synthesizer ziemlich komplex ist, wären zur optimalen Bedienung ca. 200 Encoder notwendig. Es soll vorzugsweise mit Bascom gearbeitet werden, C oder ASM ist aber auch kein Hindernis. Frage: 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.)? Ich freue mich auf jede Antwort. Gruß von Thomas
>ca. 200 Encoder
Das ist jetzt ein Scherz??
Schonmal über ein anderes, sinnvolleres Konzept nachgedacht?
zum Beispiel ein Encoder + Display und Menuführung??
> Schonmal über ein anderes, sinnvolleres Konzept nachgedacht? > zum Beispiel ein Encoder + Display und Menuführung?? Im Audio-Bereich sind eigentlich sehr, sehr viele Knöpfe völlig normal. Mischpulte bringen es locker auf einige hundert Knöpfe, auch wenn man problemlos nur die Knöpfe für einen Kanal sowie einen Kanal-Auswahlknopf anbringen könnte. Aber offenbar ist sowas in der Hitze des Gefechts zu unpraktisch.
www.ucapps.de ist dein Freund. Da solltest du vernünftige Lösungen für dein Midi-Problem finden. ■
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.
Hallo! ucapps.de kenne ich schon - die Idee mit den Schieberegistern habe ich von dieser Seite (DIN-Modul). Ich möchte aber mit atmegas arbeiten. Und es sind wirklich um die 200 Encoder erforderlich. Für eine intuitive Bedienung ist das hangeln durch verschachtelte Menues eher hinderlich. Wer schon einmal an einem modularen Synth geschraubt hat, kann das verstehen. Das Schwurbeln an den Drehknöpfen grenzt schon fast an Wolllust ;) So wie es ausschaut, ist wohl eine Arbeitsteilung sinnvoll. Das werde ich dann bei meinen ersten Experimenten erforschen. Auf jeden Fall vielen Dank für alle Antworten! Viele Grüße von Thomas
@ 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?
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 ;-).
@ Erik D. (Firma privat) (dareal) Ja, allerdings keine mechanischen. http://www.austriamicrosystems.com/03products/20_rotary_encoders.htm Die Teile haben eine Art SPI Schnittstelle. Damit sollte man mehrere Problemlos kaskadieren können. Ausserdem liefern die Teile immer einen absoluten Wert.
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.