Hallo! Kurz vorweg, bin Noob, habe mir gerade einen Arduino Mega gekauft, und plane, damit einen MIDI-Controller für Erwachsene zu bauen, er soll unter anderem 128 Drehregler bekommen. Dafür brauche ich 8 Stück 4067 16-Kanal-Multiplexer. Nun könnte ich die 4 Digitaleingänge pro Multiplexer direkt an die Digitalausgänge des Arduino hängen, dadurch würde ich aber 32 Ausgänge verbraten - also dachte ich, es muß doch möglich sein, die Multiplexer so zu verschalten, daß ich stattdessen nur 7 Ausgänge brauche. Ich dachte an so etwas: Die 4 Eingänge jedes 4067 auf die ersten 4 Ausgänge des Arduino. Die nächsten 3 Ausgänge auf die 3 Eingänge eines 4051 8-Kanal-Multiplexers. An dessen Common-In 5V. Dessen Ausgänge jeweils über ein 7404 NOT-Gate an die Inhibit-Eingänge der 4067er. Fragen: 1.) Kann das so funktionieren? 2.) Wenn nein, warum nicht? 3.) Geht's einfacher? Nehme begeistert jeglichen Tip, Rat oder Schelte entgegen. Danke im Voraus!
Ich würde eher einen 74138 zur Generierung der 8 enable Signale für die Multiplexer benutzen. Das erfordert 3 Portbits vom Arduino.
Alle A,B,C,D der 4067 parallel schalten und den entspr. 4067 per Inhibit auswählen = 12 Leitungen
Heiko K. schrieb: > Kurz vorweg, bin Noob, habe mir gerade einen Arduino Mega gekauft, und > plane, damit einen MIDI-Controller für Erwachsene zu bauen, er soll > unter anderem 128 Drehregler bekommen. Hast du dir schon gedanken gemacht, wie die Daten der 128 Controllern in das MIDI Protokoll passen sollen? EDIT: NPRN bietet sich an, erfordert aber mindestens 3 MIDI Nachrichten pro Wertänderung pro Drehregler...
:
Bearbeitet durch User
Eric B. schrieb: > Heiko K. schrieb: >> Kurz vorweg, bin Noob, habe mir gerade einen Arduino Mega gekauft, und >> plane, damit einen MIDI-Controller für Erwachsene zu bauen, er soll >> unter anderem 128 Drehregler bekommen. > > Hast du dir schon gedanken gemacht, wie die Daten der 128 Controllern in > das MIDI Protokoll passen sollen? > > EDIT: NPRN bietet sich an, erfordert aber mindestens 3 MIDI Nachrichten > pro Wertänderung pro Drehregler... Wenn man auf die reservierten controller Nummern 120 - 127 keine Rücksicht nehmen muss würden die 128 controller doch alle in die control change message Bx passen.
Wenn die Haptik nicht nervig werden soll, muss der Controller die Kanäle ganz schön flott abarbeiten. Angenommen jeder Eingang soll 50 Mal pro Sekunde gelesen werden: 1s/(50*128) = 1s/6400 = 156µS pro Wandlung. Wenn du 8 auf einmal einliest werden daraus 156µS*8 = 1,25mS. Sample Frequenz 156µS: 1/0.000156 = 6410Hz Sample Frequenz 1,25mS: 1/0.00125 = 800Hz. Ich glaube nicht, dass der ADC alle 8 aufeinmal samplen kann, also sind wir bei 6,41kHz. Da ist noch keine Mittelwertbildung drin, die Werte werden so ganz schön wackeln. Entweder macht der Controller das dauerthaft nebenher oder man nimmt explizit X Wandlungen dafür. Dadurch würde sich die Sample Frequenz mit X multiplizieren. Zwischen den Kanal-Wechseln muss auch jedes mal das Analog-Switch-Konstrukt bedient werden, was auch Zeit braucht. Alles in allem eine ganz schöne Aufgabe, die du lösen willst...
Eric B. schrieb: > Hast du dir schon gedanken gemacht, wie die Daten der 128 Controllern in > das MIDI Protokoll passen sollen? Das tun sie, es gibt 128 Control Change Messages. Wenn ich nur die unregistrierten nehme (das sind so um die 30 glaube ich) gibt es immer noch 16 Kanäle. Also noch viel Luft nach oben. Gedanken mache ich mir eher darum, ob bei der vielen Multiplexerei noch genügend Zeit für die einzelne AD-Wandlung bleibt...wenn ich mal 2 Knöpfe gleichzeitig drehe, ob dann im PC noch eine sanfter An-/Abstieg oder eine Treppe ankommt...
Zu langsam :-) ...ja, genau. leeer schrieb: > Entweder macht der Controller das dauerthaft nebenher oder man nimmt > explizit X Wandlungen dafür. Dadurch würde sich die Sample Frequenz mit > X multiplizieren. Kannst du das etwas näher erläutern, den Punkt hab ich nicht verstanden.
Warum denn immer dieser "ein uC" Ansatz? Nimm doch mehrere (z.B. 328) und lass sie über I2C oder SPI mit einem Master quatschen!? Der fragt reihum ab ob sich was geändert hat und schickt das dann raus.
Entweder du machst direkt drei (oder mehr) Wandlungen nacheinander, verrechnest diese und schreibst das Ergebnis irgendwohin: Ergebnis = (Wandlung1 + Wandlung2 + Wandlung3) / 3 Oder aber du bildest nach jeder Wandlung den neuen Mittelwert: Ergebnis = (Ergebnis + Wandlung) / 2
Heiko K. schrieb: > ob dann im PC noch eine sanfter An-/Abstieg oder eine Treppe ankommt... Analog-Freaks würden sagen mit MIDI 7-Bit Controller Events kommt da immer eine Treppe an... ;-) Es kommt ja drauf an, was Du steuern möchtest. Ein Vorteil der NPRNs ist ja auch die höhere Auflösung.
Jörg schrieb: > Warum denn immer dieser "ein uC" Ansatz? Nimm doch mehrere (z.B. 328) > und lass sie über I2C oder SPI mit einem Master quatschen!? Der fragt > reihum ab ob sich was geändert hat und schickt das dann raus. Der 328 hat aber nur in TQFP 8 ADC Kanäle, damit man einfach rechnen kann, sollte man schon 8 haben. 6 ist das suboptimal und 4 verlangsamt alles nur unnötig. Ein einzelner mega8 sollte damit nicht überfordert sein. Der Hardwareaufwand kommt doch aufs selbe raus. X Controller oder X Analog-Switches. Der Preis wird allerdings steigen, wenn man nicht nur einen nackten Controller ohne Cs und Quarz einbauen will. ISP Stecker, Quarz, Reset-Taster, evtl. Diagnose-LEDs, ..., ...
Kannst ja trotztdem einen 4067 dazu packen. Bei 128 Knöppen macht das den Kohl nun nicht soo fett und die Dinger haben genug Zeit zum Rechnen...
Man könnte ja auch Drehencoder statt Potis nehmen und sich den ganzen lahmen ADC Kram sparen. Natürlich muss da entprellt werden, aber ich denke, insgesamt wäre das schneller abzufrühstücken.
straf mich lügen, aber Drehencoder kann man nicht multiplexen? Hab da wenig Erfahrung, aber ich brauche doch die capture compares der Timereingänge um die decoder zu berechnen, und da hat kein uC 128 Stück sondern eher so Größenordnung 10-20. Insgesamt schönes Projekt, aber sobald es um Timing und Zeitgenau Dinge geht, muss man selber ran, und weg vom arduino, würd ich jetzt denken, aber als Start klappt der sicher gut.
Encoder kann man auch pollen. Das geht schätze ich ca. 10x schneller als die ADC-Kanäle lesen. Hier im Wiki gibt es guten Stoff zum Thema Drehencoder.
Deswegen ja mehrere uCs... Ich würd' erstmal 16 Potis über einen 4067 an den Mega hängen und gucken was passiert und wie es sich anfühlt. Dann kann man immer noch weitersehen in welche Richtung sich das Konzept entwickelt...
leeer schrieb: > Ergebnis = (Wandlung1 + Wandlung2 + Wandlung3) / 3 > Ergebnis = (Ergebnis + Wandlung) / 2 Danke. Ich hab mich schon gefragt, ob es bei der AD-Wandlung von Spannung aus billigen Potis nicht zum Zittern der Werte kommt, und was man dagegen tun könnte...
Hallo,
>>Ergebnis = (Wandlung1 + Wandlung2 + Wandlung3) / 3
Du willst NICHT durch 3 teilen auf einem atmega...
Wenn daraus ein Shift werden soll nehm ein Vielfaches von zwei...
GRUSS J
:
Bearbeitet durch User
The D. schrieb: > Man könnte ja auch Drehencoder statt Potis nehmen Könnte man. Hab ich auch schon überlegt. Vorteil: Schneller und genauer, und man kann in der DAW den Wert nach oben und unten verändern, ohne komplett woanders hin zu springen und den Originalwert zu verlieren. Nachteil: Kein fühl- und sichtbarer Anschlag, kein optisches Feedback, und Drehencoder sehen auf den ersten Blick komplizierter zu bauen und programmieren aus...
Heiko K. schrieb: > Danke. Ich hab mich schon gefragt, ob es bei der AD-Wandlung von > Spannung aus billigen Potis nicht zum Zittern der Werte kommt, und was > man dagegen tun könnte... Bei sauberem Aufbau zittert da garnichts - ratiometrische Messung vorausgesetzt! Heiko K. schrieb: > Nachteil: Kein fühl- und sichtbarer Anschlag, kein optisches Feedback, > und Drehencoder sehen auf den ersten Blick komplizierter zu bauen und > programmieren aus... ... keine absolute Position, schlechte Auflösung bei Billigversionen und auf keinem Fall mit nur einem µC zu erfassen.
>Nachteil: Kein fühl- und sichtbarer Anschlag, kein optisches Feedback, >und Drehencoder sehen auf den ersten Blick komplizierter zu bauen und >programmieren aus... Gibt welche mi Raster. Code gibts von Peter, Strippen brauchst du 2 pro Encoder. GRuß J
m.n. schrieb: > Bei sauberem Aufbau zittert da garnichts - ratiometrische Messung > vorausgesetzt! Das ist auch meine Erfahrung. Nur selbst die besten Potis/Fader geben irgendwann den Geist auf. Aber das ist mit Encodern nicht besser. Potis kann man zur Not auch fast immer zerlegen und reinigen. Bei Encodern wird's da schwieriger. Heiko K. schrieb: > Kein fühl- und sichtbarer Anschlag, kein optisches Feedback, > und Drehencoder sehen auf den ersten Blick komplizierter zu bauen und > programmieren aus... Der Sichtbare Anschlag lässt sich mit LEDs realisieren: http://physicalcomputing.at/WebRoot/Store2/Shops/f46ab952-295a-4f65-8ffa-38a4b8eec267/5412/B5FB/0AD0/8BDA/9E0A/0A48/3508/21F0/Bildschirmfoto_2014-09-19_um_15.26.09.png Encoder sind nicht aufwendiger Aufzubauen und zu Erfassen als Potis. Ein Controller kann auch 128 Encoder (semi-)gleichzeitig erfassen. Das sind 256 Leitungen, die man z.B. über Shift-Register einlesen kann. Bei 16MHz AVR gehen 8MHz SPI. Mit jedem Clock wird ein Bit übernommen: 1s/8MHz = 125nS pro Bit. 125nS * 128 = 16µS um alle Encoder einmal abzufragen. Ergibt 62,5kHz maximale Samplerate für alle Encoder. Das ist deutlich schneller als es sein muss. Daraus folgere ich: Mehrere Controller steigern den Aufwand nur unnötig. Haben die Encoder noch Buttons dauert es halt nochmal um 1/3 länger => immernoch schnell genug. m.n. schrieb: > und > auf keinem Fall mit nur einem µC zu erfassen. Lüge?
leeer schrieb: > Der Sichtbare Anschlag lässt sich mit LEDs realisieren: Wow sehen die stylisch aus, das würde mir gefallen...sprengt nur leider das Budget :-) Hm. Vielleicht ein Ring für alle Encoder. Oder ne LCD-Anzeige...
leeer schrieb: > Lüge? Nein. > Bei 16MHz AVR gehen 8MHz SPI. Mit jedem Clock wird ein Bit übernommen: > 1s/8MHz = 125nS pro Bit. > 125nS * 128 = 16µS um alle Encoder einmal abzufragen. Ergibt 62,5kHz > maximale Samplerate für alle Encoder. > Das ist deutlich schneller als es sein muss. Milchmädchenrechnung.
m.n. schrieb: > leeer schrieb: >> Lüge? > > Nein. > >> Bei 16MHz AVR gehen 8MHz SPI. Mit jedem Clock wird ein Bit übernommen: >> 1s/8MHz = 125nS pro Bit. >> 125nS * 128 = 16µS um alle Encoder einmal abzufragen. Ergibt 62,5kHz >> maximale Samplerate für alle Encoder. >> Das ist deutlich schneller als es sein muss. > > Milchmädchenrechnung. Pro Encoder 2 Bit, also kann man 4 Encoder pro read operation in einem Takt samplen. Insgesamt sind also 32 reads nötig, macht 32 Takte nur um die Rohdaten zu lesen. Dazu kommt das Umschalten der Multiplexer, macht zusätzlich 32 write Operationen. Wir sind dann bei 64 Takten pro Durchgang wenn ich mich nicht irre. Jetzt müssen die Rohdaten natürlich noch durch eine Entprellung und anschließend dekodiert werden. Für die Entprellung nehme ich einfach mal 100 msec an, das heißt, 10 mal pro Sekunde gibts von allen Encodern neue Werte die jetzt nur noch dekodiert werden müssen. Das alles belastet den Prozessor lächerlich wenig (im Promille Bereich) und kann im Hintergrund von einer Timer-Routine erledigt werden. Man möge mich berichtigen, falls ich hier einem Denkfehler unterliege.
The D. schrieb: > Man möge mich berichtigen, falls ich hier einem Denkfehler unterliege. Gerne. Mit 10 Abtastungen/s bekommst Du die Drehung der Drehgeber schon garnicht mehr mit. Zudem sollten die Drehgeber eine Auflösung von >= 64 haben, um an die Auflösung der Potis heranzukommen. Solche Drehgeber würde ich nicht unter 5 kHz abtasten. Und großer Schreck, wenn die dann noch alle Zittern. Viel Spaß beim Bitschuppsen ;-)
m.n. schrieb: > The D. schrieb: >> Man möge mich berichtigen, falls ich hier einem Denkfehler unterliege. > > Gerne. > Mit 10 Abtastungen/s bekommst Du die Drehung der Drehgeber schon > garnicht mehr mit. Zudem sollten die Drehgeber eine Auflösung von >= 64 > haben, um an die Auflösung der Potis heranzukommen. Solche Drehgeber > würde ich nicht unter 5 kHz abtasten. > Und großer Schreck, wenn die dann noch alle Zittern. > > Viel Spaß beim Bitschuppsen ;-) Sorry, aber das hat ja niemand behauptet. Natürlich muss viel öfter gesampelt werden. Das ist bei 64 usec Dauer für das Samplen auch problemlos möglich. Ich habe lediglich gesagt, daß MIT ENTPRELLEN letztlich alle 100msec ein neuer Satz Werte verfügbar ist. Und damit ist die gefühlte Reaktionszeit akzeptabel.
Encoder sind ja für viele Anwendungen schön, aber sie behalten ihre Stellung nach dem Ausschalten nicht. Man muss also entweder die Stellungen in ein EEPROM oder SRAM speichern oder man hat nach dem Einschalten nicht den letzten Zustand wieder. Die Kosten für den LED Kranz sind auch nicht zu unterschätzen. Da sind Potis doch einfacher zu handhaben. Mit einer nicht so komplizierten ISR für den AD Wandler sollte es auch möglich sein, die 128 Kanäle im Hintergrund in ein Array zu speichern. Die ISR könnte auch auf Gleichheit mit dem vorherigen Wert vergleichen und Flags setzen, damit die Hauptschleife den Controllerwert senden kann.
:
Bearbeitet durch User
Hm, warum gleich die volle Ladung? Beginne doch einfach erst einmal mit 8 Potis und bringe die ganze Sache zum laufen. Wenn das zufriedenstellend läuft, fange an das Projekt zu erweitern... Hier kannst du ja auch schon erste Versuche mit der Erweiterung machen, z.b. die 8 Potis dann über einen Mulitplexer einlesen, oder einen zweiten Arduino über eine der seriellen Schnittstellen mit dem Master zu verbinden. mfg Gast
Thread beobachten
Seitenaufteilung abschalten
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.