Hallo
ich suche einen USB Port, den ich an einen AVR Controller anschließen kann. Es gibt zwar AVRs mit USB, jedoch nur in Grobmotoriker-unfreundlichen SMD-Gehäusen. Auch gibt es PICs mit USB. Ich brauche aber nur den USB Port.
Die USB ICs, welche ich bisher ausfindig machen konnte gab´s leider auch nicht als DIP. Weiß hier vielleicht jemand von den uC-Experten Abhilfe?
Dank & Gruß
Basti
Weiß echt keiner was? ??? :-\ :
Hallo Basti,
ich wuerde einen der neuen PIC18Fxx5x nehmen, den USB Bootloader draufbrennen (lassen), und dann das USB Framework von Microchip so modifizieren, dass die USB datenstreams bspw. ueber die I2C oder SPI Schnittstelle zum AVT weitergeleitet werden.
Das ganze erfordert zwar etwas Einarbeitung, kostet jedoch weniger Aufwand, als einen eigenen USB Stack fuer den AVR zu programmieren. Microchip bietet saemtliche Sourcen umsonst an, ausserdem kann man den C18 Compiler fuer 60 Tage testen - das sollte ausreichen, um die “USB-Bridge” auf die Beine zu bringen. Kostenpunkt: ca. 10 EUR (den PIC18F4550 gibt es bspw. bei voti.nl)
Literaturempfehlung: http://www.microchip.com, nach “PICDEM USB User Guide” suchen
Gruss,
Thorsten.
Danke für die Infos.
Ich hätt auch noch ne andere Frage: Was hälst du davon die Baudrate zu erhöhen um den MIDI-Datendurchsatz zu steigern? Wenn ordentlich Daten übertragen werden ist das doch sicher sinnvoll, oder? Durch Zusammenlegen mehrer MIDI-Controller kann bei NI Reaktor eine höhere Auflösung erreicht werden. Könnte man MIDI durch einen “high baudrate mode”, welcher zusätzlich über mehr Controller-Nummern (oberhalb der bereits bekannten MIDI-Befehle) verfügt, zukunftsfähig(er) machen?
Als generelle Loesung halte ich das nicht fuer sinnvoll, da von der Baudrate noch viele andere Dinge abhaengen, die Du vielleicht auf Anhieb nicht siehst.
Zwei Punkte: je hoeher die Baudrate, desto groesser sollte der MIDI Buffer sein. In MIOS ist der Eingangsbuffer bspw. 64 Bytes gross, damit lassen sich bei normaler Baudrate 20 ms ueberbruecken, in denen die Daten nicht abgearbeitet werden. RAM ist sehr wertvoll (zumindest bei PICs) - in anderen Worten: je groesser der Eingangsbuffer, desto weniger bleibt fuer die eigentliche Anwendung uebrig, desto weniger Features kann man implementieren.
Naechster Punkt: Receiver Buffer Overruns - falls der USART keinen internen FIFO bietet, muss eine ISR das eingehende Datum sehr schnell in den Eingangsbuffer bringen, ansonsten kommt es zu einem Ueberlauf. Bei MIDI Baudrate und doppelgebuffertem USART innerhalb von < 640 uS - diese Zeit ist bei einem simplen MIDI Controller sehr einfach einzuhalten, bei einem Synthesizer (ich spreche hier bspw. von der MIDIbox SID und FM), bei dem eine Menge Echtzeit-Berechnungen anfallen, die nicht blockiert werden duerfen, wuerde eine hoehere Baudrate sehr weh tun.
Deshalb macht ein normales MIDI Interface fuer hoehere Transfergeschwindigkeiten nur wenig Sinn - doch es gibt auch alternative Interfaces, und dies waere bspw. USB.
Im Gegensatz zu MIDI bietet USB ein Handshaking - der USB Host wartet auf den Slave, wenn dieser die Daten gerade nicht entgegennehmen kann. Somit ist die Gefahr fuer Buffer-Ueberlaeufe gebannt.
Da das USB-MIDI Protokoll standardisiert ist, waere es eigentlich erste Wahl fuer zukuenftige MIDI Interfaces, wenn da nicht die Macken im Windows Driver waeren, sowie die generellen Probleme mit USB (Latenz, Jitter)… nunja…
Noch einen Hinweis: zur Datenuebertragung zwischen PIC und AVR wuerde ich I2C empfehlen, da auch hier so eine Art Handshaking stattfindet (Clock Stretching). Alternativ koenntest Du Dir auch ein parallel-Interface programmieren - uebertragungsraten > 1MByte/s sollten damit kein Problem sein
Gruss,
Thorsten.
Also MIDI über USB find ich zu indirekt. (Du hast ja schon Nachteile genannt - ne Massenmarkt-Schnittstelle für Drucker und Speichersticks ist halt nicht gerade dafür geeignet)
Ich dachte schon darüber nach, wenigstens für meine eigenen Geräte ne eigene Schnittstelle zu nehmen. Dann könnte ich wenigstens hardware handshake etc. umsetzen.
Nun kam allerdings eine Antwort von Dave Smith, dem ich das U(S)ART-Ding ebenfalls gefragt habe. Im Gegensatz zu dir ist er der Meinung, dass es ziemlich einfach wäre, eine schnellere Version zu entwickeln.
Ich habe nicht behauptet, dass es schwierig waere, eine schnellere Version zu entwickeln. Ich habe nur versucht, Dir zu verdeutlichen, warum es zu schwierigkeiten fuehrt, wenn man einfach nur die Baudrate erhoeht, und weiter keinen Aufwand treibt.
Ok, beschraenke dich auf primitive Applikationen, oder nimm einen schnelleren Mikrocontroller mit viel RAM, und es ist wirklich kein Problem - vielleicht war Deine Frage an the Godfather of MIDI etwas zu undifferenziert 
Gruss,
Thorsten.
Hm, undifferenziert?
Also wenn ich dich richtig verstanden habe, dann war dein Haupt-Gegenargument, dass die PICs mit Echtzeitberechnungen in deinen Synths soweit ausgelastet sind, dass dort eine Erhöhung der Baudrate mit den damit verbundenen Hardware-Mehrbelastungen nicht mehr auf den verwendeten PICs laufen würde.
Was mich etwas irritiert hat: Du empfielst (wenn auch mit ein paar Bedenken) mehr oder weniger das MIDI-USB-Ding. Doch ich kann nicht erkennen, dass die USB-Einbindung weniger aufwändig, geschweige denn besser wär. Es wurde halt schon definiert. Aber da es noch nicht wirklich verbreitet ist, erkenne ich nichtmal darin einen Vorteil.
Also irgendwie scheint es ja aus deiner Sicht abwegiger zu sein, einen eigenen Controller pro “MIDI+”-Schnittstelle zu nehmen als einen extra Controller für USB. Doch ich versteh echt nicht warum?!? :-\ ???
Frieden!
Ich versuche Dir nur zu helfen, und dabei ein bisschen aus meiner Erfahrung zu vermitteln. Wenn Dir meine Antworten arrogant erscheinen, dann bitte ich dies zu entschuldigen - es faellt mir nicht einfach, zu erraten, was Dich wirklich interessiert, worauf Du hinaus willst, welcher Input Dir hilfreich ist. Unter diesen Bedingungen ist es nicht einfach, ein gemeinsame Gespraechsbasis zu finden.
Um den Gespraechsverlauf zu skizzieren: Du hast urspruenglich nach einem USB Chip gesucht, der einfach zu verloeten ist. Niemand hat geantwortet, Du fragst erneut, und ich denke mir, dass ich vielleicht zumindest erwaehnen koennte, dass die PIC18Fxx5x Derivate gar nicht so schwer zu programmieren sind, und dass man sie aehnlich wie einen Standalone USB Chip betreiben kann — mit einem schnellen Interface nach draussen, an das Du dann den AVR haengen kannst.
Danach wechselst Du das Thema (oder verstehe ich das falsch?) - Du fragst nach der Moeglichkeit, die Baudrate (der UART basierenden MIDI Schnittstelle?) zu erhoehen, um den Durchsatz zu erhoehen.
Mein Beitrag dazu: ich halte es (fuer die UART basierte MIDI Schnittstelle) aus den erwaehnten Gruenden nicht fuer sinnvoll, vor allem eben wegen des fehlenden Handshakings. Differenzierter betrachtet kann man natuerlich sagen, dass es in vielen Faellen doch geht, und dass man fuer hoch ausgelastete Prozessoren eine andere Loesung findet muss, doch soweit wuerde ich gar nicht erst gehen - vor allem nicht in der Situation, in der ich nicht weiss, welche Anwendungen Du eigentlich realisieren moechtest (um es mal aggressiv zu formulieren: Du koenntest solche Details ruhig erwaehnen, bevor Du jemanden oeffentlich an die Wand stellst!)
Erst nach diesem Posting erwaehnst Du, dass Du eigentlich gar nicht mit USB arbeiten moechtest. Nun moechtest Du fuer Deine eigenen Geraete eine eigene Schnittstelle nehmen, mit der auch Handshaking moeglich ist - haettest Du das gleich erwaehnt, waere ich vielleicht darauf naeher eingegangen - ich kenne Deinen Vorlieben nicht!
(Mein Tip: I2C, sehr einfach aufzusetzen, und im Gegensatz zu MIDI UART keine Point-to-Point Verbindungen - somit koennen die Geraete direkt untereinander kommunizieren. Auch sind mit einem synchronen Interface hoehere Datenraten als mit einem UART drin - Stichwort Stoersicherheit).
Ok - dies nur, um das Kommunikations-Dilemma aufzuklaeren
Nun die Antworten zu den oberen Fragen:
Also wenn ich dich richtig verstanden habe, dann war dein Haupt-Gegenargument, dass die PICs mit Echtzeitberechnungen in deinen Synths soweit ausgelastet sind, dass dort eine Erhöhung der Baudrate mit den damit verbundenen Hardware-Mehrbelastungen nicht mehr auf den verwendeten PICs laufen würde.
ja, ich muesste entweder Features streichen, oder einen zweiten Baustein fuer die Kommunikation hernehmen.
Wie sieht das bei Deinen Anwendungen aus? Sind die stark ausgelastet, oder ist da noch eine Menge Luft?
Oder planst Du sowieso eine Multichip-Loesung?
Was mich etwas irritiert hat: Du empfielst (wenn auch mit ein paar Bedenken) mehr oder weniger das MIDI-USB-Ding. Doch ich kann nicht erkennen, dass die USB-Einbindung weniger aufwändig, geschweige denn besser wär.
Basierend auf Deinem oberen Posting bin ich davon ausgegangen, dass Du ein Fan von USB bist, und Dich auf diesem Gebiet auch schon auskennst (falls nicht: ich kann Dir eine fertige Firmware ueber den Zaun werfen, in die Du nur noch die Kommunikationsroutinen zu Deinen AVRs einbauen musst).
Es wurde halt schon definiert. Aber da es noch nicht wirklich verbreitet ist, erkenne ich nichtmal darin einen Vorteil.
USB-MIDI hat immerhin den Vorteil, dass es von allen gaengigen Betriebssystemen unterstuetzt wird - und zwar Plug&Play maessig. Unter Windows koennte der Driver zwar besser sein (er ist bspw. nicht Multiclient-faehig). Die Performance ist verglichen mit dem Programmieraufwand akzeptabel.
Alternative zu USB: http://www.mlancentral.com/ - leider kein offener Standard
Dann lieber Ethernet? MIDI-over-Ethernet wurde ja bereits IEEE standardisiert, Treiber sind frei erhaeltlich, ein RTL8019AS laesst sich einfach an einen AVR anschliessen
Doch lassen wir das Thema.
Also irgendwie scheint es ja aus deiner Sicht abwegiger zu sein, einen eigenen Controller pro “MIDI+”-Schnittstelle zu nehmen als einen extra Controller für USB. Doch ich versteh echt nicht warum?!?
Verstehst Du unter “MIDI+” einen UART mit erhoehter Baudrate? Dann liegen die Gruende auf der Hand: Du kannst Dich nicht an einen fertigen Treiber auf PC Seite dranhaengen - hast Du Erfahrung in PC Treiberprogrammierung (falls ja: dann koenntest Du mir bei einem Programmierproblem weiterhelfen
Mit bis zu 115200 Baud koenntest Du die “MIDI+” Geraete bspw. an einen normalen COM Port anschliessen - doch der ist leider ein Auslaufmodell, also nicht zukunftssicher. Auch einen fertigen Treiber haettest Du damit nicht zur Hand. Die CBX/“to-Host” Treiber von Yamaha/Roland/Kawai unterstuetzen nur 38400 Baud, und waere kein wirklicher Fortschritt.
Ein weiteres Problem: was, wenn mehrere Geraete vom PC aus sternfoermig betrieben werden sollen (z.B fuer mehrere gleichzeitig laufende bidirektionale Verbindungen?). Wieviele COM Ports bietet Dein Motherboard, wieviele Interruptleitungen sind frei fuer weitere Ports? Waerst Du mit 115200 Baud bereits zufrieden?
Gruss,
Thorsten.
Frieden!
Ich versuche Dir nur zu helfen, und dabei ein bisschen aus meiner Erfahrung zu vermitteln. Wenn Dir meine Antworten arrogant erscheinen, dann bitte ich dies zu entschuldigen - es faellt mir nicht einfach, zu erraten, was Dich wirklich interessiert, worauf Du hinaus willst, welcher Input Dir hilfreich ist. Unter diesen Bedingungen ist es nicht einfach, ein gemeinsame Gespraechsbasis zu finden.
Ja, du hast völlig recht. Entschuldigung… Von aussen gesehen habe ich “Gedankensprünge” - mit der Kommunikation hab ich es echt nicht so drauf
Um den Gespraechsverlauf zu skizzieren: Du hast urspruenglich nach einem USB Chip gesucht, der einfach zu verloeten ist. Niemand hat geantwortet, Du fragst erneut, und ich denke mir, dass ich vielleicht zumindest erwaehnen koennte, dass die PIC18Fxx5x Derivate gar nicht so schwer zu programmieren sind, und dass man sie aehnlich wie einen Standalone USB Chip betreiben kann — mit einem schnellen Interface nach draussen, an das Du dann den AVR haengen kannst.
Richtig. An dem USB Interface war ich zunächst doppelt interessiert: Zur MIDI-Ãœbertragung und zur Computer-Verbindung. Doch nach näheren Infos fand ich das USB-MIDI nicht mehr so toll. Also suche ich nach anderen Möglichkeiten…
Danach wechselst Du das Thema (oder verstehe ich das falsch?) - Du fragst nach der Moeglichkeit, die Baudrate (der UART basierenden MIDI Schnittstelle?) zu erhoehen, um den Durchsatz zu erhoehen.
Mein Beitrag dazu: ich halte es (fuer die UART basierte MIDI Schnittstelle) aus den erwaehnten Gruenden nicht fuer sinnvoll, vor allem eben wegen des fehlenden Handshakings. Differenzierter betrachtet kann man natuerlich sagen, dass es in vielen Faellen doch geht, und dass man fuer hoch ausgelastete Prozessoren eine andere Loesung findet muss, doch soweit wuerde ich gar nicht erst gehen - vor allem nicht in der Situation, in der ich nicht weiss, welche Anwendungen Du eigentlich realisieren moechtest (um es mal aggressiv zu formulieren: Du koenntest solche Details ruhig erwaehnen, bevor Du jemanden oeffentlich an die Wand stellst!)
Tut mir leid : :-\
Erst nach diesem Posting erwaehnst Du, dass Du eigentlich gar nicht mit USB arbeiten moechtest. Nun moechtest Du fuer Deine eigenen Geraete eine eigene Schnittstelle nehmen, mit der auch Handshaking moeglich ist - haettest Du das gleich erwaehnt, waere ich vielleicht darauf naeher eingegangen - ich kenne Deinen Vorlieben nicht!
(Mein Tip: I2C, sehr einfach aufzusetzen, und im Gegensatz zu MIDI UART keine Point-to-Point Verbindungen - somit koennen die Geraete direkt untereinander kommunizieren. Auch sind mit einem synchronen Interface hoehere Datenraten als mit einem UART drin - Stichwort Stoersicherheit).
Also ist die angeblich “relativ langsame” Geschwindigkeit des I²C-Bus immer noch locker schnell genug für die Anwendung? Ne synchrone Ãœbertragung wär mir definitiv am liebsten…
Wie sieht das bei Deinen Anwendungen aus? Sind die stark ausgelastet, oder ist da noch eine Menge Luft?
Oder planst Du sowieso eine Multichip-Loesung?
Ich plane eine Multichip-Lösung. An einem Chip hängt die ganze Steuerung und alle asynchronen Funktionen etc.
Zum auslesen (abspielen) sollen eigene Chips zum Einsatz kommen, die dann halt jeweils so viele Spuren schaffen wie die Performance es zulässt.
Basierend auf Deinem oberen Posting bin ich davon ausgegangen, dass Du ein Fan von USB bist, und Dich auf diesem Gebiet auch schon auskennst (falls nicht: ich kann Dir eine fertige Firmware ueber den Zaun werfen, in die Du nur noch die Kommunikationsroutinen zu Deinen AVRs einbauen musst).
Ich bin weder Fan, noch kenne ich mich aus. Danke für das Angebot…
USB-MIDI hat immerhin den Vorteil, dass es von allen gaengigen Betriebssystemen unterstuetzt wird - und zwar Plug&Play maessig. Unter Windows koennte der Driver zwar besser sein (er ist bspw. nicht Multiclient-faehig). Die Performance ist verglichen mit dem Programmieraufwand akzeptabel.
Alternative zu USB: http://www.mlancentral.com/ - leider kein offener Standard
Dann lieber Ethernet? MIDI-over-Ethernet wurde ja bereits IEEE standardisiert, Treiber sind frei erhaeltlich, ein RTL8019AS laesst sich einfach an einen AVR anschliessen
Ethernet dachte ich auch schon. Doch das einzige mit MIDI-Ethernet ausgestattete Gerät, welches mir bekannt ist, wurde nochmal ohne Ethernet auf den Markt gebracht - weil nicht nur das Ethernet nicht ging, sondern auch andere Funktionen dadurch gestört wurden. Und es handelte sich um eine große Firma. Naja es dürfte wohl eher daran gelegen haben, dass aus Kostengründen alles auf einem Controller laufen muss…
Jedenfalls interessant, dass sich Ethernet einfach an nen AVR anschließen lässt.
Verstehst Du unter “MIDI+” einen UART mit erhoehter Baudrate? Dann liegen die Gruende auf der Hand: Du kannst Dich nicht an einen fertigen Treiber auf PC Seite dranhaengen - hast Du Erfahrung in PC Treiberprogrammierung (falls ja: dann koenntest Du mir bei einem Programmierproblem weiterhelfen
Mit bis zu 115200 Baud koenntest Du die “MIDI+” Geraete bspw. an einen normalen COM Port anschliessen - doch der ist leider ein Auslaufmodell, also nicht zukunftssicher. Auch einen fertigen Treiber haettest Du damit nicht zur Hand. Die CBX/“to-Host” Treiber von Yamaha/Roland/Kawai unterstuetzen nur 38400 Baud, und waere kein wirklicher Fortschritt.
Ein weiteres Problem: was, wenn mehrere Geraete vom PC aus sternfoermig betrieben werden sollen (z.B fuer mehrere gleichzeitig laufende bidirektionale Verbindungen?). Wieviele COM Ports bietet Dein Motherboard, wieviele Interruptleitungen sind frei fuer weitere Ports? Waerst Du mit 115200 Baud bereits zufrieden?
Nee mit Treiberproggen kenn ich mich nicht aus… Das hier wird mein erstes Projekt, bei dem ich direkt an der Hardware programmiere (dafür ist es recht gewagt, ich weiß).
Die weiteren (zum Teil über mehrere Worte verteilte) MIDI-Controllernummern müssten eh vom Soft-Sequenzer unterstütz werden, damit so ein Treiber Sinn macht.
Also 115200 wär schonmal ne Verbesserung aber noch zu kompromißbehaftet. Das I²C-Ding gefällt mir eindeutig am besten. MIDI und CV brauch ich ja sowieso für die alten Kisten. Doch wenn ich z.B. einen polyphonen Sampleplayer (für Drums) baue, dann muss das halt nicht unbedingt an MIDI hängen
Wenn die “Abspiel-MCUs” auch noch Samples auslesen könnten, das wär schon nicht schlecht
Ach und ich sehe grad, der Receptor kann MIDI & Audio übers Ethernet
hast Du Erfahrung in PC Treiberprogrammierung (falls ja: dann koenntest Du mir bei einem Programmierproblem weiterhelfen
Da könnte ich Dir eventuell helfen…
Hallo,
Basti: kannst Du mal eine Auflistung machen, welche Geraete Du genau zusammenschliessen moechtest (bspw.: Controller, Sequencer, Sampler, …), wie stark die Chips so in etwa ausgelastet werden (hierzu reichen ein paar Eckwerte, wie bspw. die Anzahl der Bedienelemente, die Anzahl der gleichzeitig abgespielten Tracks, die Samplerate…), ob und wie sie untereinander kommunizieren sollen, welche Art von Daten ueber die Schnittstelle uebertragen werden sollen, und alles, was dazu hilfreich sein koennte, die Auslastung des gesamten Systems abzuschaetzen. Dann kann ich Dir sagen, ob I2C ausreichend ist, ob andere (oder mehrere verschiedene) - einfach zu realisierende - Schnittstellen besser geeignet sind, usw.
Ein Hinweis am Rande: neben Pitch Bender (leider nur 16 Kanaele) ist es via NRPN ja bereits moeglich, 14-bittige Werte nach MIDI Standard. zu uebertragen. Mit NRPN sind es bis zu 16*65536 Adressen - wenn man sich auf 16 * 256 moegliche Adressen beschraenkt, sind fuer einen NRPN Stream nur 7 Bytes notwendig. Angenommen, man betreibt eine serielle Schnittstelle mit 1 Mbit/s, dann waere dieser Stream in — sagen wir mal — 100 uS uebertragen. Hier habe ich bereits einen pessimistischen 25%igen Protokolloverhead eingerechnet (alternativ ginge auch ein propritaerer SysEx String mit 5..6 Bytes, doch solche Streams werden von den meisten MIDI Programmen nicht unterstuetzt)
Reaktor (ich beziehe mich auf ein voriges Posting von Dir) erlaubt bei Steuerdaten eine Updatefrequenz von maximal ca. 3kHz (den genauen Wert weiss ich gerade nicht, ich weiss nur, dass komplexere Synths damit auf meinem 2.8 GHz PC nicht mehr laufen - das kommen noch andere Probleme auf Dich zu) — Werteaenderungen werden also ca. 300 uS verarbeitet.
Somit kannst Du (schaetzungsweise, ich habe es noch nie ausprobiert) 3 High-Resolution Werte gleichzeitig zu Reaktor senden, ohne dass die Information bis zum naechsten Updatecycles verloren geht. Ich habe nur zwei Haende…
Ok, das ist uebertrieben, sobald ein Sequencer oder bspw. ein AD-gewandelter externer Oszillator die Werte schickt, wird es schwierig. Hier sollte man wohl doch lieber von MIDI absehen und direkt eine Soundkarte zur Erfassung der Werte verwenden.
Was ich jetzt schon sehe, ist das Problem des Interfacings an den PC. I2C laesst sich jedenfalls nicht direkt betreiben. Was bleibt ist USB oder der Parallelport.
Und so komme ich zu Deinem Angebot, Thomas:
Ich suche jemanden, der Interesse daran hat, einen alternativen MIDI-USB Treiber zu programmieren, welcher Multiclient faehig ist. Das MIDI-USB Protokoll ist eigentlich ziemlich einfach, es arbeitet mit 32bit Worten, die lediglich fuer das MIDI API aufbereitet werden muessen. Sowohl Cypress, als auch Microchip bieten ein Driver Framework fuer Borland C - man muss es eigentlich nur noch richtig konfigurieren, und dann sollte die Kommunikation schon klappen.
Das Problem: das MIDI API muss noch bedient werden, es muessen “MIDI Ports” bereitgestellt werden — mangels Dokumentation weiss ich nicht, wie das zu realisieren ist, doch die Sourcen zu Hubis Loopback Device koennten vielleicht weiterhelfen (die sind allerdings nur in Pascal verfuegbar)
Alternativ zu USB wuerde es mich auch interessieren, ob ein aehnlicher MIDI Treiber fuer den Parallelport moeglich ist, und welche Performance hiermit zu erreichen ist.
Hintergrund: sollte ich irgendwann einmal die Zeit dazu finden (und meine laufenden Projekte abgeschlossen haben… ;-)) werde ich mich an das geplante FPGA basierte 2x16 MIDI Interface setzen. Doch ohne Multiclient Treiber wuerde es mich waerend des Debuggens von MIDI-Appliklation eher behindern, als nuetzen :-/
Gruss,
Thorsten.
Hallo,
Basti: kannst Du mal eine Auflistung machen, welche Geraete Du genau zusammenschliessen moechtest (bspw.: Controller, Sequencer, Sampler, …), wie stark die Chips so in etwa ausgelastet werden (hierzu reichen ein paar Eckwerte, wie bspw. die Anzahl der Bedienelemente, die Anzahl der gleichzeitig abgespielten Tracks, die Samplerate…), ob und wie sie untereinander kommunizieren sollen, welche Art von Daten ueber die Schnittstelle uebertragen werden sollen, und alles, was dazu hilfreich sein koennte, die Auslastung des gesamten Systems abzuschaetzen. Dann kann ich Dir sagen, ob I2C ausreichend ist, ob andere (oder mehrere verschiedene) - einfach zu realisierende - Schnittstellen besser geeignet sind, usw.
Zunächst gibt´s ja nur CV- und MIDI-Eingänge an den Synths & Samplern, die an den Sequenzer angeschlossen werden könnten. Also brauch ich etwa 4-8 MIDI Outs und 1-2 MIDI-In(s). Zunächst könnt ich mit dem ucApps MIDI-CV-Converter analoge Spannungen erzeugen, jedoch wär später eine direkte CV-Ausgabe sehr wünschenswert, zumal ja auch eine höhere Auflösung ganz angenehm wäre
Naja und diverse Analog-Drums (da gibt´s gute Inspirationen bei synthesizerforum.de) sollen noch getriggert werden können aber die Trigger-Informationen bestehen ja nur aus NoteOn & Velocity…
Umgekehrt sollten auch Drumpad-Signale verarbeitet werden können, damit Drumspuren auch direkt eingespielbar sind.
Die Option, interne Drumsamples zu triggern, wäre ab 48 kHz und 24 Bit besonders interessant.
Die Tracks sollen von einem erweiterbaren Multiprozessor-System bereitgestellt werden. Dadurch ist die Spurenanzahl nicht insgesamt durch die MCU beschränkt. Dabei wird eine eigene MCU für die Bedienungs-Funktionen benötigt (sowie eine weitere, um den Speicher zu verwalten - da mehrere Speichermodule verwendbar sein sollen wär hier wohl ne eigene MCU von Vorteil)
Die “schnellsten Noten” sollen 384tel sein - jeder Takt enthält also 384 Schritte. Es wäre wünschenswert, diese Schritte noch verzögern zu können (quasi in Richtung des folgenden Schrittes schieben) - dabei wär die Auflösung davon abhängig, was noch sinnvoll verarbeitet werden kann (ich dachte an etwa 4-8 Bit)
Was ich jetzt schon sehe, ist das Problem des Interfacings an den PC. I2C laesst sich jedenfalls nicht direkt betreiben. Was bleibt ist USB oder der Parallelport.
Klar, dafür benötige ich ne Standart-Schnittstelle. Allerdings möchte ich mit Compact-Flash-Medien arbeiten (Datentausch ist also auch anders möglich) - wichtig wäre also zunächst einmal ein PC-Synchronisations-Port…
Gruß von Basti
Zunächst gibt´s ja nur CV- und MIDI-Eingänge an den Synths & Samplern, die an den Sequenzer angeschlossen werden könnten. Also brauch ich etwa 4-8 MIDI Outs und 1-2 MIDI-In(s).
Hierfuer eignet sich IIC ganz gut - ich nehme mal an, dass Du nicht mit FPGAs arbeiten moechtest, so nimm einfach ein paar (guenstigere) Atmel Chips mit 2 USARTs fuer jeweils 2 MIDI IOs. Gib jedem Atmel eine eigene IIC Slave Adresse, so dass ein IIC Master die MIDI-Daten ueber den Bus verteilen kann. Selbst wenn der IIC Bus mit einem relaxten Timing von 400 kbit getaktet wird (1 MBit sollte auf Boardlevel ebenfalls moeglich sein), koenntest Du damit locker 10..12 MIDI Ports mit voller MIDI-Bandbreite versorgen. Und das ist der Worst-Case - solange nur Steuerdaten (also keine laengeren SysEx Dumps) an alle MIDI Ports gleichzeitig verteilt werden, haut das hin.
Zunächst könnt ich mit dem ucApps MIDI-CV-Converter analoge Spannungen erzeugen, jedoch wär später eine direkte CV-Ausgabe sehr wünschenswert, zumal ja auch eine höhere Auflösung ganz angenehm wäre
Dir ist bewusst, was Du da angehen moechtest?
Das AOUT Modul arbeitet mit 12bit, ein LSB macht also 1/4096 * u_max aus, das sind bei 10V Maximalspannung ca. 2.4 mV — ich moechte mal einen analogen Synthesizer sehen, dessen Grundrauschen (an den Steuerleitungen) kleiner als 5 mV ist
Naja und diverse Analog-Drums (da gibt´s gute Inspirationen bei synthesizerforum.de) sollen noch getriggert werden können aber die Trigger-Informationen bestehen ja nur aus NoteOn & Velocity…
jep, auch ein analoges Drum Modul waere nichts anderes als ein weiterer IIC Slave
(Allgemeiner Tip zum Thema Drum Module: du kennst Hallucinogen’s Seite? http://xlargex.xl.funpic.de/)
Umgekehrt sollten auch Drumpad-Signale verarbeitet werden können, damit Drumspuren auch direkt eingespielbar sind.
Die Option, interne Drumsamples zu triggern, wäre ab 48 kHz und 24 Bit besonders interessant.
Theoretisch mit einem Atmel machbar, wird aber ziemlich tricky bei dieser Bitrate (ein einzelner 8bit uC wird da schon ziemlich ausgelastet sein, 32bit waere besser geeignet)
Die Tracks sollen von einem erweiterbaren Multiprozessor-System bereitgestellt werden. Dadurch ist die Spurenanzahl nicht insgesamt durch die MCU beschränkt. Dabei wird eine eigene MCU für die Bedienungs-Funktionen benötigt (sowie eine weitere, um den Speicher zu verwalten - da mehrere Speichermodule verwendbar sein sollen wär hier wohl ne eigene MCU von Vorteil)
Somit wird die Anzahl der Tracks durch die Performance der “Master MCU” und des Bussystems beschraenkt - bin mir nicht sicher, ob es nicht einfacher waere, alles von einem AT Mega zu verwaltet, der Programmieraufwand ist geringer, und mit entsprechend grossen Memory sollten 128…256 Tracks machbar sein.
Die “schnellsten Noten” sollen 384tel sein - jeder Takt enthält also 384 Schritte.
Das klingt machbar, die MBSEQ arbeitet bspw, mit der gleichen Aufloesung (96 ppqn = 384 clocks pro Takt) und kann 48 (Drum) Tracks ohne Timingschwierigkeiten verwalten. Hier ist das Nadeloehr in der Tat die langsame MIDI Schnittstelle, doch zwei MBSEQ lassen sich schliesslich auch parallel betreiben Doch MBSEQ arbeitet auch nur mit 7bit Events, mit einer hoeheren Aufloesung wuerde es nicht mehr so glatt laufen.
Es wäre wünschenswert, diese Schritte noch verzögern zu können (quasi in Richtung des folgenden Schrittes schieben) - dabei wär die Auflösung davon abhängig, was noch sinnvoll verarbeitet werden kann (ich dachte an etwa 4-8 Bit)
Eine Verzoegerung laesst sich am einfachsten erreichen, indem man die Events entsprechend dem internen Taktraster verzoegert (also: “ticks” abzaehlen und dann das Event abfeuern).
Klar, dafür benötige ich ne Standart-Schnittstelle. Allerdings möchte ich mit Compact-Flash-Medien arbeiten (Datentausch ist also auch anders möglich) - wichtig wäre also zunächst einmal ein PC-Synchronisations-Port…
Hierfuer ist ein normaler MIDI Port ausreichend — bei der Synchronisation kommt es vor allem auf Timingstabilitaet an, also einen geringen Jitter. Wenn Du ganz penipel vorgehen moechtest (denn auch der IIC koennte mal unguenstig blockiert sein), wuerde ich empfehlen, aus den MIDI Clock Events, die an einem der MIDI Ins eintreffen, direkt ein Clock Signal zu erzeugen, und dieses an einen Interrupt Eingang des “Master Controllers” (oder den Sequenzern) anzuschliessen, so dass die Latenz zwischen MIDI In und Sequencer im Worst Case < 10 uS betraegt.
Auf diese Weise waere Deine Hardware auch kompatibel zu analogen Sequenzern
Gruss,
Thorsten.
Danke für die Tipps…
Ich hätte da noch ne Frage zum 74HC165:
Die serielle Leitung (Verbindung QH auf SER des nächsten ICs) ist beim MBHP_DINX4_V2 über 10k mit 5V verbunden. :o Weshalb? Um Spannungsabfall bei längeren Kaskaden zu vermeiden? Oder hab ich da im Datenblatt was übersehen? ???
Dank & Gruß
Basti
Hallo,
eigentlich ist es nur beim letzten Chip notwendig, den “SER” Eingang auf einen definierten Level zu klemmen, um einen erhoehten Stromverbrauch (jeder Eingang der “wackelt”, verbrauch Strom) oder gar einen Latch-Up Effekt zu verhindern. Doch dazu wuerde auch eine Verbindung nach 5V oder 0V ausreichen.
Mit den Pull-Ups erreicht man so etwas wie Plug & Play. Man kann also ein DINX4 Modul betreiben, ohne es voll zu bestuecken, oder etwas an der Software aendern zu muessen (MIOS scannt in der Regel 128 Register), egal wieviele 74HC165 nun wirklich angeschlossen sind.
Gruss,
Thorsten.