Einen wunderschönen guten Abend, auf geht´s in meinen ersten Post in diesem Forum. Seit dem ich hier in tausenden schon bestehenden Beiträgen Hilfe fand, bin ich hier immer gerne unterwegs, bin heute allerdings an einem Problem/Fragestellung angekommen, bei der ich hier keine Antwort finde. Mein aktuelles Projekt besteht in einem modularen Midi-Controller System, das beliebig erweiterbar ist. Technisch bedeutet das: In den Modulen: Unterschiedliche Sensoren, beispielsweise Encoder, Fader, Buttons etc. ausgestattet mit Motor(für Fader), LEDs oder (Display; werde ich wohl wegen komplexität nicht einbauen). Der ganze Spaß ist, wenn nötig über De/Multiplexer an einem uC (bis jetzt ATTiny44, falls mehr Pins nötig sind, kann ich ohne Probleme umdisponieren) der über ein Bus-Protokoll sämtliche Informationen, über möglichst wenig Leitungen, trotzdessen mit genügend Geschwindigkeit für Midi Anwendungen an mein Hauptmodul versenden und ankommende Daten umsetzten soll. Das Hauptmodul besteht neben eigenen Bedienelemtenten (für z.B Presetwechsel)aus Testzwecken aus einem Teensy 4.1, der alle Daten als Mididevice an den Rechner gibt aber auch Anweisungen aus der GUI empfangen und weiterreichen soll (bsp.: LED Farbe, Bild Display). Meine Frage(n)v1: Welches Protokoll bietet sich für die Komunikation zwischen Hauptmodul(bis jetzt Teensy) und uCs in Modulen(bis jetzt ATTiny44) sowie GUI(Windows Form Applikation auf C++ Basis) und Hauptmodul an? Ich habe an I²C für die "interne" Komunikation gedacht wobei ich mir hier bei der Geschwindigkeit für Midi Anwendung nicht sicher bin und für die Komunikation mit dem Rechner an ein selbstgeschriebenes serielles Protokoll gedacht. Müsste dann ja mittels UART laufen!? Meine Frage(n)v": Sind die o.g. Protokolle überhaupt noch zeitgemäß oder gibt es etwas, dass sich besser eignen würde? Ich hoffe die Angaben reichen euch um mir zu helfen und sind nicht so abstrakt das hier morgen schon hingerichtet bin :P. Da ich etwas in der Größenordung noch nie gemacht habe, kann es sein, dass ich hier einige Dinge nicht so ganz richtig beschrieben habe und freu mich über jede Berichtigung, aber ins kalte Wasser zu springen, war bis jetzt eigentlich immer eine sehr gute Idee Greets Thaddäus
Generelle MIDI fragen kann ich dir Beantworten aber was in Bezug auf Thaddäus V. schrieb: > ATTiny44 & Co ist leider nicht, da wir sie in keinen unseren MIDI Devices einsetzen. I²C bietet sich an, vor allem, wen du die bis 1MHz Version verwendest. Da ist zwar der Bus etwas empfindlicher, aber auch einiges schneller. Wenn der I²C Bus richtig Konfiguriert ist, unterstützt er dann auch "lahme" Bauteile
:
Bearbeitet durch User
Patrick L. schrieb: > I²C bietet sich an, vor allem, wen du die bis 1MHz Version verwendest. > Da ist zwar der Bus etwas empfindlicher, aber auch einiges schneller. > Wenn der I²C Bus richtig Konfiguriert ist, unterstützt er dann auch > "lahme" Bauteile Erstmal besten Dank :D Wie sieht das denn aus mit dem Lizensrecht? Kann ich das Protokoll komerziell ohne Gebühren verwenden? Gibt es Libarys die ich damit verwenden kann, ohne hier Abgaben zu tätigen/ die Libary/den Code ansich anzugeben?
Thaddäus V. schrieb: > Wie sieht das denn aus mit dem Lizensrecht? Kann ich das Protokoll > komerziell ohne Gebühren verwenden? Gibt es Libarys die ich damit > verwenden kann, Ja und Ja. Die Lizenzen sind mittlerweile grössten Teils Ausgelaufen und wenn du Fertige I²C Bauteile verwendest (Dazu zählt auch der im µC implementierte I²C Bus), ist es sowieso kein Problem. Und "Libarys" und App Notes gibt es zu Hauf. Auch hier im Forum.
:
Bearbeitet durch User
Patrick L. schrieb: > Und "Libarys" und App Notes gibt es zu Hauf. Sehr cool das hat Atmel ja so oder so clever gelöst und Ups, da hab ich mich wohl verschrieben... Du schriebst in der ersten Antwort "in unseren Midi Controllern" was verwendet ihr da/ hast du eine Empfehlung für mein Hauptmodul? Seriell und I²C Bus sollten natürlich drin sein, Digital In/Out bräuchte ich so 10-12 in Summe ideal wäre natürlich ein eigebauter UART bzw. USB Bus, den ich direkt für die Kommunikation mit der GUI verwenden kann bzw. für die Mididaten.
Wenn das ein Midi Controller ist, was soll denn da für ein anders Protokoll außer Midi für die Kommunikation Rechnergui-Controller in Frage kommen? Dein Teensys muss doch sowieso als Usb-Midi-Interface arbeiten für die Kommunikation Controller->PC. Da kann doch auch gleichzeitig die Gegenrichtung drüber laufen. Und für deine Kommunikation GUI-Controller kannst du SysEx verwenden, wenn nichts anderes passt. Solltest du MidiIn und MidiOut im Rechner exclusiv für was anderes als deine GUI Verwenden wollen, helfen Midimerger oder Verteiler in Software. Oder lass den Teensys gleich 2xMidiIn und 2xMidiOut bereitstellen, dann kannst du über ein Paar mit deiner Gui kommunizieren und das andere steht dann zur freien Verwendung. Aber als Protokoll würde ich bei Midi bleiben. Und über USB hast du da ja auch keine Geschwindigkeitsprobleme.
Thaddäus V. schrieb: > Welches Protokoll bietet sich für die Komunikation > zwischen Hauptmodul(bis jetzt Teensy) und uCs in Modulen(bis jetzt > ATTiny44) sowie GUI(Windows Form Applikation auf C++ Basis) und > Hauptmodul an? zur Konstruktion von Bedienoberflächen ("Mensch-/Maschine-Schnittstellen") Beitrag "LabVIEW meets µC" vor 3 Jahren hab ich auch nach einem Protokoll von midi aus gesucht: Beitrag "Re: Analogwert im zweierkomplement seriel senden?" Thaddäus V. schrieb: > Sind die o.g. Protokolle überhaupt noch zeitgemäß oder > gibt es etwas, dass sich besser eignen würde? Wenn die Protokolle zu zeitgemäßen Keyboards passen, ja Thaddäus V. schrieb: > Da ich etwas in der Größenordung noch nie gemacht habe, kann es sein, > dass ich hier einige Dinge nicht so ganz richtig beschrieben habe und > freu mich über jede Berichtigung, aber ins kalte Wasser zu springen, war > bis jetzt eigentlich immer eine sehr gute Idee Die Hauptarbeit mit dem zuordnen von Funktionen etc. kommt erst wenn ein Protokoll lauffähig ist .... im Zweifel lässt sich das Protokoll auch noch nach der Hauptarbeit austauschen
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.