COM Interface für MIDIbox unter Linux

Deutsch
1

Hallo,

ich würde gern eine kleine MIDIbox bauen, um unter Rosegarden/Linux etwas konfortabler arbeiten zu können. Nutzen will ich dafür meinen Laptop, d.h. ich brauche entweder ein USB MIDI Interface oder ich spreche die MIDIbox direkt per serieller COM Schnittstelle an.

Von der Hardware und mit kleiner Firmwareänderung (steht glaub irgendwo beschrieben) funktioniert das offensichtlich. Aber was für Treiber brauche ich dazu im Linux? Wie sieht es bei dieser Lösung mit den Latenzzeiten aus. Ist das irgendwie langsamer als eine USB-Lösung?

Gibt es vielleicht auch komplettes COM-MIDI Interface (funktionsfähig unter Linux), welches ähnlich gut wie die USB Lösungen läuft?

Grüsse

Stefan

2

Hallo Stefan,

es mag zwar seltsam klingen, doch die serielle Verbindung ueber die COM Schnittstelle funktioniert schneller als die Verbindung ueber MIDI->USB->Laptop, da MIDI mit einer etwas langsameren Baudrate laeuft, und der direkte Weg ueber USB bei den MIDIbox Projekten nicht moeglich ist. to-COM ist auch einfacher zu realisieren, deshalb wuerde ich diese Loesung in Deinem Fall favorisieren.

Der Treiber fuer das COM Interface befindet sich wahrscheinlich bereits auf Deiner Festplatte, er gehoert zu Alsa. Ein HowTo zur Installation gibt es hier: http://alsa.opensrc.org/serial, einziger Unterschied: die Baudrate betraegt 38400

Gruss,

        Thorsten.

3

Hallo Thorsten,

danke für die schnelle Antwort. Von der Baudrate ist es schneller, ok - ich dachte da eher an Buffer bei der seriellen Schnittstelle, die bei den USB Treibern vielleicht nicht vorhanden sind.

Ok, was wäre nun zu tun? Nehme ich nur die MIDIbox, müsste ich im Quelltext oder per Parameter einfach die Baudrate auf 38400 Baud setzen? Die Variante mit dem MIDI-Merger ist - soweit ich verstanden habe - nur für das alte OS notwendig.

Das I2C Prinzip mit den 2x2 MIDI in/out klingt aber auch sehr interessant. Wenn man das mit einem COM Interface und einer MIDIbox vereinen könnte, wäre das ziemlich genial.

Nachtrag: Wer ist dort eigentlich der I2C Master? Ist das schon die MIDIbox?

Grüsse

Stefan

4

danke für die schnelle Antwort. Von der Baudrate ist es schneller, ok - ich dachte da eher an Buffer bei der seriellen Schnittstelle, die bei den USB Treibern vielleicht nicht vorhanden sind.

Sowohl MIDI->USB als auch USB->PC sind gebuffert, zusaetzlich bietet USB auch noch eine Art Handshaking, so dass Daten nur auf der MIDI->USB Strecke verloren gehen koennten.

Das serielle Interface hat einen Hardware Buffer, doch der ist kleiner. Auf Treiberseite wird jedoch ein zweites mal softwaremaessig gebuffert, so dass die Wahrscheinlichkeit fuer einen Datenverlust sehr gering ist (in der Praxis wird das wohl niemals geschehen).

Ok, was wäre nun zu tun? Nehme ich nur die MIDIbox, müsste ich im Quelltext oder per Parameter einfach die Baudrate auf 38400 Baud setzen?

Ja, wie unter http://www.ucapps.de/mios_bootstrap_experts.html beschrieben, muss im ID Feld der Wert “000000000000100” eingetragen werden. Dies geschieht beim Programmieren des Bootloaders, der holt sich dann genauso wie spaeter MIOS die Konfiguration aus diesem Feld.

Die Variante mit dem MIDI-Merger ist - soweit ich verstanden habe - nur für das alte OS notwendig.

was moechtest Du genau mergen?

Das I2C Prinzip mit den 2x2 MIDI in/out klingt aber auch sehr interessant. Wenn man das mit einem COM Interface und einer MIDIbox vereinen könnte, wäre das ziemlich genial.

Theoretisch waere das moeglich, ich habe es jedoch noch nie selbst ausprobiert. Man kann das interne MIDI Interface auf 38400 Baud einstellen, und die MBHP_IIC_MIDI slaves (bis zu vier koennen betrieben werden) mit normaler Baudrate.

Allerdings werden die Datenstroeme nicht von MIOS verwaltet, sondern das muss auf Applikationsseite geschehen. Ein Beispiel befindet sich in der MIDI Router Applikation.

Ein Problem: in dieser Konstellation kann es sehr einfach zu einem Buffer Ueberlauf kommen, da die Daten ueber den internen Port schneller eintreffen, als sie ueber das normale MIDI Interface mit niedrigerer Baudrate uebertragen werden koennen (Flaschenhals Problem) - MIDI bietet kein Handshaking. Grosse Buffer mildern das Problem (bei MIOS: 64 Bytes, bei MBHP_IIC_MIDI: 96 bytes), doch die Gefahr besteht…

Nachtrag: Wer ist dort eigentlich der I2C Master? Ist das schon die MIDIbox?

Ja, ausschliesslich (Multi Master Betrieb wird nicht unterstuetzt)

Gruss,

        Thorsten.

5

was moechtest Du genau mergen?

Nichts. Ich hatte nur verstanden, dass man mit dem alten OS zwischen MIDIbox und PC-Com-Port noch den MIDImerger brauchte, um die Baudrate anzupassen.

Theoretisch waere das moeglich, ich habe es jedoch noch nie selbst ausprobiert. Man kann das interne MIDI Interface auf 38400 Baud einstellen, und die MBHP_IIC_MIDI slaves (bis zu vier koennen betrieben werden) mit normaler Baudrate.

Allerdings werden die Datenstroeme nicht von MIOS verwaltet, sondern das muss auf Applikationsseite geschehen. Ein Beispiel befindet sich in der MIDI Router Applikation.

Ein Problem: in dieser Konstellation kann es sehr einfach zu einem Buffer Ueberlauf kommen, da die Daten ueber den internen Port schneller eintreffen, als sie ueber das normale MIDI Interface mit niedrigerer Baudrate uebertragen werden koennen (Flaschenhals Problem) - MIDI bietet kein Handshaking. Grosse Buffer mildern das Problem (bei MIOS: 64 Bytes, bei MBHP_IIC_MIDI: 96 bytes), doch die Gefahr besteht…

Hm, also das mit den Datenströmen verstehe ich nicht so ganz. Jeder Kanal der nicht auf der MIDIbox selbst liegt, wir einfach weitergeleitet. Oder übersehe ich da etwas?

Mit den Buffern verstehe ich auch nicht ganz. Wo ist dort der Flaschenhals? Angenommen es kommen Daten mit 38400 Baud - dann werden die sich doch vermutlich auf MIDIbox, MIDI OUT1 und MIDI OUT2 verteilen - je nach Routing. Ausnahme ist natürlich der Pakettyp mit beliebig vielen Bytes. Der Flaschenhals sollte ansonsten die Richtung MIDI zur COM sein: Nämlich wenn von allen MIDI IN Ports und der MIDIbox etwas zum PC gesendet wird?

Andersrum könnte man doch auch eine Baudrate von 115200 Baud nehmen und 4 unabhängige MIDI Ports realisieren. Wären ja auch nur 64 mögliche Kanäle.

Grüsse

Stefan

PS: Ich habe (noch) keine praktischen Erfahrungen mit MIDI, also bitte nicht böse sein falls ich Müll erzähle…

6

Nichts. Ich hatte nur verstanden, dass man mit dem alten OS zwischen MIDIbox und PC-Com-Port noch den MIDImerger brauchte, um die Baudrate anzupassen.

nein, schon die PIC16F basierenden MIDIboxen konnten mit der COM Baudrate senden, der Merger war nur dann notwendig, wenn man an den MIDI In auch ein normales MIDI Keyboard anschliessen wollte, bei dem sich die Baudrate i.d.R nicht aendern laesst.

Hm, also das mit den Datenströmen verstehe ich nicht so ganz. Jeder Kanal der nicht auf der MIDIbox selbst liegt, wir einfach weitergeleitet. Oder übersehe ich da etwas?

wenn der interne MIDI Merger aktiv ist, werden eingehenden und intern generierte Daten weitergeleitet. Ausnahme sind getunnelte Events, doch das ist ein anderes Thema (“MIDIbox Link”)

Mit den Buffern verstehe ich auch nicht ganz. Wo ist dort der Flaschenhals? Angenommen es kommen Daten mit 38400 Baud - dann werden die sich doch vermutlich auf MIDIbox, MIDI OUT1 und MIDI OUT2 verteilen - je nach Routing.

Das Routing, das Du selber programmieren muesstest… wenn MIDI Out1 saemtliche eingehenden Daten, und zusaetzlich vielleicht auch die internen Daten weiterleiten soll, dann entsteht hier ein Flaschenhals.

Ausnahme ist natürlich der Pakettyp mit beliebig vielen Bytes. Der Flaschenhals sollte ansonsten die Richtung MIDI zur COM sein: Nämlich wenn von allen MIDI IN Ports und der MIDIbox etwas zum PC gesendet wird?

Das Problem besteht in beiden Richtungen, ist aber sehr stark fallabhaengig. Wenn die MIDI Applikation (in Deinem Fall: Sequenzer) nicht kontinuierlich MIDI Events sendet, dann koennen sie rechtzeitig weitergeleitet werden, bevor sich etwas staut.

Andersrum könnte man doch auch eine Baudrate von 115200 Baud nehmen und 4 unabhängige MIDI Ports realisieren. Wären ja auch nur 64 mögliche Kanäle.

Eine hoehere Baudrate wuerde das Problem noch verschaerfen…

Wie soll Dein Setup konkret aussehen? Ich habe das Gefuehl, dass wir einander vorbeireden. Evtl. ist USB in Deinem Fall doch die bessere Loesung.

Gruss,

        Thorsten.

7

Eine hoehere Baudrate wuerde das Problem noch verschaerfen…

Wieso?

4 x 31250 = 125000 Baud

Würde also in Rückrichtung sogar zu wenig sein.. wobei das dann eh nur theoretisch wäre - da müssten ja alle Ports unter Volllast laufen.

Die Richtung andersrum müsste man halt durch einen geschickten Treiber abfangen werden - der eben virtuell 4 Schnittstellen je 31250 Baud zur Verfügung stellt.

Wie soll Dein Setup konkret aussehen? Ich habe das Gefuehl, dass wir einander vorbeireden. Evtl. ist USB in Deinem Fall doch die bessere Loesung.

Naja, für den ersten Schritt möchte ich nur ein Gerät mit ein paar wenigen Fadern/Potis, Tastern und LEDs.. also sowas wie die MIDIbox64 - nur eben deutlich kleiner. Das ganze per serieller Schnittstelle. Und wenn ich schon so ein Kasten baue, dann muss der wenigstens gleich auch MIDI IN und MIDI OUT haben..

Stefan

8

Wieso?

4 x 31250 = 125000 Baud

Würde also in Rückrichtung sogar zu wenig sein.. wobei das dann eh nur theoretisch wäre - da müssten ja alle Ports unter Volllast laufen.

Die Richtung andersrum müsste man halt durch einen geschickten Treiber abfangen werden - der eben virtuell 4 Schnittstellen je 31250 Baud zur Verfügung stellt.

Du moechtest also vom Linux Treiber aus “Load Sharing” betreiben? Das wuerde theoretisch funktionieren, erfordert jedoch Kenntnisse in der Treiberprogrammierung.

Die maximale RS232 Baudrate ist 115200 Baud, der Mikrocontroller sollte sich in diesem Fall nur noch um das Routen kuemmern, da die Bytes alle 80 uS eintreffen. Zusaetzlich koenntest Du auch ein Handshaking ueber die RTS/CTS Leitungen realisieren, um einen potentiellen Datenverlust von vorneherein zu vermeiden. MIOS ist hierfuer nicht geeignet, es wuerde auf eine eigene Firmware und einen zusaetzlichen Mikrocontroller herauslaufen.

Naja, für den ersten Schritt möchte ich nur ein Gerät mit ein paar wenigen Fadern/Potis, Tastern und LEDs.. also sowas wie die MIDIbox64 - nur eben deutlich kleiner. Das ganze per serieller Schnittstelle. Und wenn ich schon so ein Kasten baue, dann muss der wenigstens gleich auch MIDI IN und MIDI OUT haben..

Solange Du die MIDIbox als Controller betreibst, wird es mit der to-COM Schnittstelle keine Probleme geben.

Ein vollwertiger MIDI In/Out erfordert wesentlich mehr Entwicklungsaufwand auf uC und Linux Seite - viel Spass :wink:

Eine bereits laufende Loesung waere die Verwendung des MBHP_USB, oder MBHP_USB_PIC Interface (MBHP_USB_PIC ist nicht offiziell released, und auch nicht dokumentiert, laeuft aber - auch unter Linux - mit bis zu 5 MIDI In und Outs)

Gruss,

        Thorsten.

9

Du moechtest also vom Linux Treiber aus “Load Sharing” betreiben? Das wuerde theoretisch funktionieren, erfordert jedoch Kenntnisse in der Treiberprogrammierung.

Die maximale RS232 Baudrate ist 115200 Baud, der Mikrocontroller sollte sich in diesem Fall nur noch um das Routen kuemmern, da die Bytes alle 80 uS eintreffen. Zusaetzlich koenntest Du auch ein Handshaking ueber die RTS/CTS Leitungen realisieren, um einen potentiellen Datenverlust von vorneherein zu vermeiden. MIOS ist hierfuer nicht geeignet, es wuerde auf eine eigene Firmware und einen zusaetzlichen Mikrocontroller herauslaufen.

Die Frage ist, ob man die Last wirklich per Treiber verteilen muss. Die MIDI Events kommen eh nur in der programmierten Häufigkeit. D.h. wenn man seine Geräte sinnvoll verteilt, sollte es eigentlich zu keinen Problemen kommen. Ausnahme bleiben lange Frames. Die Frage ist nur, in wie weit diese nicht auch bei “normalem” MIDI Probleme machen.

Solange Du die MIDIbox als Controller betreibst, wird es mit der to-COM Schnittstelle keine Probleme geben.

Ein vollwertiger MIDI In/Out erfordert wesentlich mehr Entwicklungsaufwand auf uC und Linux Seite - viel Spass :wink:

Eine bereits laufende Loesung waere die Verwendung des MBHP_USB, oder MBHP_USB_PIC Interface (MBHP_USB_PIC ist nicht offiziell released, und auch nicht dokumentiert, laeuft aber - auch unter Linux - mit bis zu 5 MIDI In und Outs)

MBHP_USB_PIC !? Was ist aus dem USART Bug geworden?

Auf die Cypress Variante würde ich lieber verzichten - Fotoplatten gelingen mir nicht so gut…

Stefan

Nachtrag: Wieso funktionieren bei der USB Variante 5 MIDI in/out und bei einer COM Schnittstelle nicht? 12 MBaud zu 31250 Baud ist doch noch kritischer als 115200 zu 31250… :slight_smile: Müsste also “nur” der USB MIDI Treiber auf eine COM umgeschrieben werden, oder?

10

Die Frage ist, ob man die Last wirklich per Treiber verteilen muss. Die MIDI Events kommen eh nur in der programmierten Häufigkeit. D.h. wenn man seine Geräte sinnvoll verteilt, sollte es eigentlich zu keinen Problemen kommen.

Bastelloesung…

MBHP_USB_PIC !? Was ist aus dem USART Bug geworden?

Siehe http://www.ucapps.de/mbhp_iic_midi.html

Nachtrag: Wieso funktionieren bei der USB Variante 5 MIDI in/out und bei einer COM Schnittstelle nicht? 12 MBaud zu 31250 Baud ist doch noch kritischer als 115200 zu 31250…

USB bietet fuer jeden MIDI Port eine eigene Pipe, ausserdem gibt es eine Art Handshaking, so dass Daten nicht verloren gehen koennen.

Müsste also “nur” der USB MIDI Treiber auf eine COM umgeschrieben werden, oder?

Ich bezweifle, dass sich der Aufwand lohnt. Zumal der COM Port sowieso ausstirbt

Gruss,

        Thorsten.

11

Ok, also wenn das mit dem PIC + USB funktioniert, dann würde ich eindeutig dieser Lösung den Vorzug geben.

Allerdings hast Du ja die Firmware (noch?) nicht veröffentlicht. Arbeitest Du dort noch an Anpassungen für die I2C Module, oder muss ich dort meine (sehr) alten PIC Kenntnisse wieder rauskramen?

Grüsse

Stefan

12

Allerdings hast Du ja die Firmware (noch?) nicht veröffentlicht. Arbeitest Du dort noch an Anpassungen für die I2C Module, oder muss ich dort meine (sehr) alten PIC Kenntnisse wieder rauskramen?

Die Firmware ist fertig, ich finde aber keine Zeit, das ganze Geraffel zu dokumentieren.

Der letzte Snapshot von Maerz liegt unter http://www.ucapps.de/tmp/mbhp_usb_pic_snapshot.zip

Gruss,

        Thorsten.

13

Vielen Dank,

da werd ich wohl mal Schaltkreise bestellen..

Bei Microchip gibts übrigens ein errata-sheet mit Version Mai diesen Jahres in dem der EUSART Bug mit einem Workaround beschrieben ist. Hast Du Dir das schonmal angesehen?

Grüsse

Stefan

14

Nein, weil ich weiss, dass er in meinem Fall nicht weiterhilft - der PIC ist ja nicht ausschlieslich mit dem Datentransfer beschaeftigt, sondern soll auch noch andere Dinge tun. Ich habe diesen Workaround mit dem Microchip Support ausdiskutiert, nachdem ich den Bug reported hatte - in meinem Fall hilft er nicht weiter. Es hat viel Ueberzeugungskraft gekostet (drei Reports verteilt ueber mehrere Monate mit Beispielprogrammen und Oszi-Snapshots), bis der Silicon Bug als solcher akzeptiert wurde. Und scheinbar wurde er ja nun zumindest fuer den PIC18F4620 und aehnlichen Derivaten gefixed, beim PIC18F4550 kann es also nicht mehr lange dauern…

Gruss,

        Thorsten.

15

Ja, habe auch gerade Deinen anderen Beitrag im Forum gesehen.. das lässt ja hoffen.

Hast Du die Quelltexte zur MIDIbox plus 8 auch freigegeben? Finde nur das HEX File. Ich hab in meiner Bastelkiste noch einen 16F877 gefunden, allerdings nur ein 16MHz Quarz. Würde das ganze gern mal schnell auf nen Steckbrett probieren wollen.

Stefan

16

Und wie ist das weiter gegehen mit Rosegarden? Hat es funktioniert?

Ich glaube is muss mir jetzt französisch lernen, dort gibst mehr info über Rosegarden und Midibox.