MIDI an UART 0 - ttyAMA0

Ich hoffe, jemand hier im Forum beschäftigt sich

Zwecks Musikmachereien auch mit dem RasPi.

Ich habe mir mit einem 6N137 Optokoppler einen MIDI Eingang

an den UART-RX Pin (Steckerleiste: Pin#10) eines Raspi 3 gebaut.

Die Ausgangsseite des 6N137 wird mit der 5V Boardspannung des Raspi betrieben.

Da es sich beim Ausgang dieses Optokopplers, wie bei den anderen typischen MIDI Kandidaten,

um einen offenen Kollektor Ausgang handelt

und die Eingänge des Raspi nicht 5V tollerant sein sollen,

habe ich den mit einem Pullup von 4K7 auf die nominellen 3,3V

(Pin#2 der Steckerleiste) hochgezogen

In der /boot/config.txt habe ich dazu folgende Einträge,

nach Vorlage: https://zuzebox.wordpress.com/tag/midi/ gemacht,

um die Baudrate anzupassen:

# Enables the UART. It isn’t strictly necessary
# when combined with pi3-miniuart-bt:
enable_uart=1
# Reassigns the weaker UART (ttyS0) for
# Bluetooth and frees ttyAMA0 for our MIDI interface:
dtoverlay=pi3-miniuart-bt
# Using an DT overlay to achieve the same
# UART clock settings as our init_uart_clock etc. trick:
dtoverlay=midi-uart0

Soweit, so mittelprächtig, die Midibyte müßten demnach also

bei oder in ttyAMA0 landen.

Damit habe ich zwar noch weder ein /dev/midi, noch irgendwas,

das sich unter Alsa als MIDI device ansprechen läßt,

aber da wenigstens die Baudrate nun stimmen soll,

könnte ich MIDI Eingaben von meinem MIDI Keyboard mit

cat /dev/ttyAMA0 abhorchen.

In der Tat kommt da auch was.

Leider ist das aber nur Bitsalat, was die Schnittstelle da kommen sieht,

zudem verschluckt sie immer wieder etliche Byte.

Ich habe dann mit meinem Oskar die Signalspannungen

an RX gemessen:

Low liegt bei 0,25V und High liegt bei 3V an RX,

das sollten eigentlich Werte sein, bei denen die UART eindeutige

Highs und Lows erkennen müßte und der Wert für den

externen Pullupwiderstand von 4K7 wäre O.K..

Mir scheint es eher, daß das mit der Baudrate immer noch nicht hinhaut,

oder dem Raspi das MIDI-Datenformat 8n1 nicht genehm ist.

Bin zwischenzeitlich über ein Kommando gestolpert, das die Geschwindigkeit

der UART anzeigen soll, Ausgabe ist folgende:

pi@ratherfast:~ $ vcgencmd measure_clock uart
frequency(22)=47999000

Das sieht jedenfalls noch astronomisch aus für MIDI und nicht so,

als hätte dieses Overlay "midi-uart0" irgendwas ausgerichtet.

Kommentiere ich das Overlay aus und starte den Raspi neu,

zeigt mir dieses Kommando: frequency(22)=48000000,

also ganze 1000 mehr

Ich bin jedenfalls im Augenblick etwas ratlos

und würde mich freuen, wenn da wer Abhilfe weiß.

Habt Dank für die Antworten.

Quote from Tell

Na ja, ein Midi-Stream ist doch binaer, soviel ich weiss. Binaere Daten waeren also erst mal normal.

So steht's wohl seit 1983 geschrieben und was anderes kommt naturgemäß aus dem Optokoppler 6N137 nicht raus,

da der intern vor dem Ausgang einen Schmittrigger nachgeschaltet hat.

Schnell genug für die 31250 Baud sollte er jedenfalls sein.

Die Frage wäre nur, ob ich mit den beschriebenen 0,25V für eine eindeutige "0" noch in der Spezifikation bin.

Quote

Vor einem cat von der Schnittstelle sollte sie erst mal konfiguriert werden.

Linux hat sehr eigene Ansichten was ein Terminaldriver machen sollte...

Genau diese Konfiguration sollte ja das Overlay "midi-uart0" machen: 8n1,31250Baud,

mehr liefert das gewöhnliche /dev/midi oder /dev/snd/midiC0Dschießmichtot auch nicht,

bzw. wird das so auch vom Keyboard geliefert. Im Prinzip gehts nicht simpler,

nur steht da Linux und die Mehrfachfunktionalitäten der i/o Pins vor.

Wenn das jedenfalls mit "cat" funktioniert, kann ich mir einfach unter /dev einen Link namens "midi"

auf das ttyAMA0 anlegen.

Es scheint jedenfalls noch einige Hürden zu geben:

Ich habe jetzt noch die Kernelparameter "console=serial0,115200 console=tty1" aus der /boot/cmdline.txt entfernt,

das scheint auchnoch dazwischenzufunken.

Der Raspi soll ja zwei UARTS haben.

Ich habe hier:

https://www.raspberrypi.org/do…ion/configuration/uart.md

noch sehr hilfreiche Informationen dazu gefunden.

Z.B.über das Overlay "pi3-disable-bt":

"pi3-disable-bt disables the Bluetooth device and restores

UART0/ttyAMA0 to GPIOs 14 and 15.

It is also necessary to disable the system service

that initialises the modem so it doesn't use the UART:

sudo systemctl disable hciuart."

Das soll die "echte" UART, die eingebaute "Prime Cell UART PL011" wieder

über die i/o Pins zugänglich machen. Bluetooth wäre dann aber abgehängt,

was mich nicht stört.

Die 2. UART, die sog. "mini uart" kann man für MIDI getrost vergessen:

"The baud rate of the mini UART is linked to the core frequency of the VPU on the VC4 GPU.

This means that as the VPU frequency governor varies the core frequency,

the baud rate of the UART also changes."

Wofür die überhaupt gut sein soll, wenn sie nichtmal eine eigene Clock besitzt, ist

eine gute Frage.

In der Beschreibung des Overlays "midi-uart0" steht dann noch Folgendes:

Name:   midi-uart0


Info:   Configures UART0 (ttyAMA0) so that a requested 38.4kbaud actually gets
31.25kbaud, the frequency required for MIDI


Usage:  dtoverlay=midi-uart0


Params: <None>

Wie cladish auch schreibt:

Das Overlay verbiegt also nur die Clock so,

daß danach der Teiler der PL011 für eine ganzzahlige Teilung auf

reale 31250 Baud eingestellt werden kann.

Für eine Terminalausgabe muß dann also die "falsche" Baudrate

von 38400 angegeben werden.

Ehrlich gesagt, halte ich das für ein fürchterliches Durcheinander

und ein Hack scheints obendrein, da der Takt der UART dann nichtmehr dem

Nominellen entspricht.

Aber man sieht, ich komme der Sache wohl schon näher.

Danke nochmal, von dem Linuxkrempel weiß ich eigentlich nicht viel,

das Schönste wäre, wenn ich mit dem gcc und ner vernünftigen Dokumentation

der UART direkt in den Registern dieses "PL011" stochern könnte,

wie man es auch bei den Atmels tut.

Habe heute nicht mehr viel Zeit, das alles auszuprobieren,

aber wenn es dann endlich pfundst, werde ich es nochmal zusammenfassen.

Mojn!

Quote from TE

Was sagt stty -D /dev/ttyAMA0 -all ?

Es sagt wörtlich:

"stty: Wenn ein Ausgabestil angegeben ist, kann kein Modus gesetzt werden."

ich habe ein kleines C-Progrämmchen als MIDI Monitor geschrieben.

Das sollte ja auch mit dem ttyAMA0 laufen, da da auch nichts anderes aufläuft

als beim USB-MIDI Kabel im /dev/snd/midiC1D0.

Immerhin hat das Progrämmchen mittlerweile nun schon etwa 10 Byte nach Programmstart richtig erkannt.

Dahinter wird es dann wieder wüst.

Die Masterclock des PL011 scheint nicht zu wissen, nach welchem Takt sie laufen soll.

Mal sagt "vcgencmd measure_clock uart" das:

frequency(22)=47999000

dann wieder das:

frequency(22)=48000000

Ich weiß nicht, wie ernst man den Output von vcgencmd nehmen kann,

aber 48MHz lassen sich auf 31,25KBaud glatt durch 1536 Teilen,

47,999MHz durch den Teiler 1536 sind dagegen etwa 31249,349 Baud

Die Differenz sind zwar nur 0,651 Baud, aber müßte ein Byte da nicht

schon nach 2 Sek. um mehr als ein Bit nachgehen?

Andererseits "rastet" das Folgebyte durch das Stoppbit ja auch wieder auf

Byteanfang ein.

Oh, das sieht abenteuerlich aus :

Quote

root@ratherfast:/home/pi# stty -F /dev/ttyAMA0 --all

speed 9600 baud; rows 24; columns 80; line = 0;

intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;

lnext = ^V; discard = ^O; min = 1; time = 0;

-parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts

-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel iutf8

opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0

-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke -flusho -extproc

Display More

9600 Baud sind jedenfalls völlig abwegig, immerhin erkennt mein Monitor schon nach Start die ersten paar Byte.

Nochn' Nachtrag,

mein Programm zeigt auch nur was an, wenn ich in der /boot/cmdline.txt den Kernelparameter

"console=serial0, 38400"

eintrage.

War sone Idee von mir. /dev/@serial0 ist ein Link auf /dev/ttyAMA0.

Das ist das Progrämmchen "*mcat":

#include <stdio.h>
#define uint8_t unsigned char
#define _MIDIin "/dev/ttyAMA0"
//#define _MIDIin "/dev/snd/midiC1D0"
//#define _MIDIin "/dev/midi1"
//ANSI-Farben://0=schwarz, 1=rot, 2=gruen, 3=gelb, 4=blau, 5=lila, 6=blaugruen, 7=weiss
//Zeichenfarbe Offset:30 (0="Farbreset")
//Hintergrundfarbe Offset:40int
main(int argc, char *argv[])
{
    printf("\033[2J\033[1;1H\033[m");// "clear"
    uint8_t byte_in;FILE *midi_in;
    midi_in =fopen(_MIDIin,"rb");
    setbuf(stdout,NULL);//Reste im Buffer weg, sonst hakts hier.
    while(1)
    {
        byte_in=fgetc(midi_in);
        switch (byte_in)
        {
//**************** Status (0b1sssssss) ******************
            case 0x80 ... 0xff:        //alle Statusbyte, 1 imMSBit, rot
                printf("\033[31m  0x%x ",byte_in);
                break;
//*************** Daten (0b0ddddddd) ************************
            case 0x00 ... 0x7f:
                printf("\033[0m%x ",byte_in);//alle Datenbyte, 0 im MSBit, weiss
                break;
        }
    }
return 0;
}

Und das ist im Augenblick eine (nachsortierte) Ausgabe:

0x90 37 7c
0x80 37 64
0x90 3c 79
0x80 3c 64
0x90 43 79
0x80 43 64
37
72
37
64
0xe0
0xe0
0xe0
0xfc
0xfe

Die ersten 6 Zeilen sind völlig O.K.

0x90 bedeutet Tastenanschlag auf Kanal1, die 37 danach bedeutet Tastennummer Hex 37, dann Anschlagwert Hex 7c

0x80 in der nächsten Zeile: Taste auf Kanal 1 losgelassen, dann kommt Tastennummer Hex 37, Loslaßgeschwindigkeit Hex 64 usw.

Wie man sieht, habe ich 3x eine Taste gedrückt und dann wieder losgelassen.

Was dann aber kommt, ist nicht mehr sinnvoll zu interpretieren, 4 Datenbyte ohne vorgestellten Status

und dann 5 Statusbyte, obwohl ich nur weiterhin Tasten gedrückt und losgelassen habe.

Quote from TE

Kann man herausfinden welche Codes fehlen? Vielleicht interpretiert der Driver immer noch irgendwas.

Nein, was hinter den sechs richtig erkannten Triplets kommt, kann z.T. nicht aus dem Keyboard kommen.

Der Status 0xfc z.B. bedeutet "stop sequence", das kann das Keyboard aber garnicht.

Das ist nurnoch Bitsalat.

Ich könnte ein paar Tasten drücken und die zu erwartenden Byte notieren, nur den Notenanschlag kann ich dabei nicht quantitativ voraussagen,

das ist nach Gefühl.

Quote from TE

Ich wuerde den auch so uebernehmen und dem switch einen default-Fall geben.

eigentlich sind alle Bytewerte abgedeckt und was anderes kommt ja garnicht rein:

0x00 bis 0x7f, dann 0x80-0xff, mehr Fälle gibts nicht.

Quote

Ist iutf8 jetzt ausgeschaltet?

Öh, wie gehtn das?

Hab jedenfalls ausdrücklichen Dank!

Ich Danke Dir nochmal,

ich habe die Einstellung mit stty gemacht, es ändert aber leider nix.

Das Kommando werde ich mir auch nochmal genau angucken, hat ja ne schicke man page

Zudem hab ich mir nochmal alles mit meinem alten Hameg angeguckt.

Direkt an RX sehen die Signale wirklich sauber aus.

Den Status für "modulation" kann ich am Oskar gut einfangen und breitziehen,

dahinter zappeln dann die zugehörigen Datenbyte, wenn ich das Modulationsrad

des Keyboards einigermaßen kontinuierlich betätige.

Genau so soll es sein und da dürfte der Raspi wirklich nix zu meckern haben.

Ich bin dann mal auf die Idee gekommen, den Pullup von den 3,3V abzuziehen

und -siehe da- der interne Pullup des Raspi scheint an RX enabled und,

wie das aussieht, sogar ohne zusätzlichen Pullup auszureichen.

Ohne den externen Pullup sehe ich an RX immernoch ein sauberes Signal,

von den 3V runter mit steilen Flanken und ohne Überschwingen auf <0,5V.

Da kann ich sogar die Bits abzählen.

Quote from Tell

fgetc gibt einen int zurueck

Ich habe in meinem Progrämmchen auch nochmal einen "cast" eigefügt in Zeile 17:

von byte_in=fgetc(midi_in); in byte_in=(fgetc(midi_in));

Ich hoffe, sorum ist es richtig , der Compiler meckert jedenfalls nicht,

aber machen tuts auch nix.

Na ja, mal gucken, wie stur ich noch bleibe, bischen nervig wird das langsam.

Der PL011 sollte sich jedenfalls, wenn er mit kontinuierlichen 48MHz läuft

und über den ganzzahligen Teiler >dez.1536 verfügt, auch ohne Verstellen durch Nachkalibrierung

o.ä. auf genau 31250Baud teilen lassen, deswegen wundert es mich schon, daß ich nur nen Output

kriege, wenn ich dem Kernel den "falschen" Parameterwert: console=serial0,38400

mitgeben muß, um überhaupt einen Input zu bekommen,

aber vlt. will es das Overlay "midi-uart0" ja so.

have a lotta fun

Quote from Tell

Gemeint war: den Returnwert in einem int ablegen und den switch um einen default-Fall erweitern,

der alle Werte groesser als 0xFF erfasst.

Nach der Beschreibung von fgetc sollte das nicht vorkommen,

aber irgendwas muss ja falsch sein, sonst wuerde das Programm doch laufen.

Ja gut, hab ich auch nochmal gemacht:

byte_in als int deklariert und:

default: //fuer alles, was uebrig ist....

printf("\033[33m%x ",byte_in); //... nach den cases angefügt.

//Das wuerde dann in Gelb angezeigt.

Läuft ohne Meldung durch den Compiler, aber im Augenblick macht mein Progrämmchen an ttyAMA0

wieder garnichts mehr, keine Ahnung, warum.

Der Oskar zeigt dabei immer noch saubere Signale an RX.

Mit /dev/snd/midiC1D0 vom USB MIDI Inputkabel als Eingabe kompiliert,

funktioniert es mit dem "int- byte_in" auch immernoch einwandfrei.

Ein "Default-Fall" ist dort auch nach Traktieren der Tasten

und Controllerräder nicht aufgetreten.

Oder, um es unkomplizierter zu sagen:

Das Programm funktioniert einwandfrei , wenn ich es für die USB Midischnittstelle kompiliere.