STM32F4 MidiDevice

Wenn du nicht unbedingt auf den F4 festgelegt bist, hier ein Beispiel:

Beitrag "STM32 USB-MIDI"

Das ist aber nicht so einfach auf den F4 portierbar, da der eine 
komplett andere USB Hardware hat. Wenn es Cortex M4 sein soll würden 
sich aber die stm32F3xx anbieten, die haben (fast) die gleiche USB 
Hardware.

Niklas Fischbach schrieb:
> - Kann jeder STM32 Midi?
> - Ich nutze als Pin Konfiguration CubeMX, wie muss ich den USB Modus
> einstellen?
> - Muss ich bei der Clock-Konfiguration etwas beachten?

So wie du die Fragen stellst, ist absehbar dass das ein steiniger Weg 
für dich wird. Such dir besser ein fertiges Projekt auf GitHub das du 
nur zu modifizieren brauchst.

ein ähnliches Thema gab es hier vor kurzem, da ging es aber eher um die 
andere Richung, Midi lesen, aber das ist im Prinzip egal.
Mein Vorschlag wieder Mbed, in der Doku ist ein fertiges Beispiel um 
Midi auszugeben. Für Noten, aber genauso geht z.B. Command Control.
https://os.mbed.com/docs/mbed-os/v6.9/apis/usbmidi.html
Es ist egal ob F1..H7 oder ein Kinetis oder NXP, um die USB 
Implementierung kümmert sich das OS und die Anwendung sieht immer gleich 
aus. Schade das sich hier jeder mittlerweile mit HAL quälen will.

Wenn man das so will geht es auch, beim Clock muss man aufpassen das USB 
seine 48 MHz bekommt. Da USB Midi nur auf low level USB aufsetzt geht 
das mit jedem Controller der nativ USB kann.

Johannes S. schrieb:
> Schade das sich hier jeder mittlerweile mit HAL quälen will.

Hast du dir die mbed Sourcen mal angesehen? Da geht ohne HAL bei STM32 
nichts. Man kann es auch anders ausdrücken, fetter geht es kaum. Ich 
schätze mal mindestens einen Faktor 10 zu meinem Beispiel oben.

Und ja, ich weiß, heute nimmt man einfach den fettesten Controller den 
man kriegen kann und alles ist gut. Jedenfalls solange in den Untiefen 
der ganzen Lib's keine Fehler schlummern.

temp schrieb:
> Hast du dir die mbed Sourcen mal angesehen? Da geht ohne HAL bei STM32
> nichts.

ja, habe ich. Weil es HAL gibt konnte ST das so schnell für viele MCU 
portieren. Und man kann HAL Code verwenden für Sachen die das OS nicht 
abdeckt, zu Lasten der Portabilität natürlich.

temp schrieb:
> Das ist aber nicht so einfach auf den F4 portierbar, da der eine
> komplett andere USB Hardware hat.

das ist der Haken an speziellen Implementierungen. Der F4 kann ja noch 
mehr als USB, es kann also noch mehr Gründe geben den zu benutzen. Und 
bei >= 512 kB Flash ist doch wohl eher die Entwicklungszeit relevant als 
ein paar kB im Codesegment zu sparen.
Auf einem F103 läuft das Ganze auch, dann muss man eben auf Luxus wie 
RTOS verzichten. Was für einen Midi Controller mit ein paar Encodern 
wahrscheinlich auch nicht nötig wäre.
Eine Encoder Komponente mit dem Algorithus aus dem Forum habe ich auch 
mal gebaut, ist mit einer Zeile instanziiert, ohne Codegenerator.
https://github.com/JojoS62/Encoder/blob/master/Encoder.cpp

Johannes S. schrieb:
> Auf einem F103 läuft das Ganze auch, dann muss man eben auf Luxus wie
> RTOS verzichten. Was für einen Midi Controller mit ein paar Encodern
> wahrscheinlich auch nicht nötig wäre.

RTOS ist auch nicht für alles die Lösung. Und das nackte mbed UsbMidi 
Sample belegt 38kb im Flash. Das passt noch auf ein BluePill Board. Aber 
wehe man muss in den MBED Quellen mal nach Fehlern suche und muss mit 
-O0 übersetzten. Da werden es schon knapp 70k und einem F103C8 platzt 
der Kragen.

Das Hauptproblem dabei sehe ich aber auch in den Flash-Größen bei STM. 
Die kleinen Gehäuseformen (32pin 48pin) sind häufig nicht so üpping 
ausgestattet und da wird es mit mbed schnell knapp. z.B. ist der 
stm32F042 im 32pin Gehäuse mit 32k Flash am Ende.

Aber egal, das muss jeder für sich und sein Projekt selbst entscheiden. 
Die minimalistische Variante hat genauso seine Vorteile und Nachteile 
wie der mbed-Hammer.

Für blutige Anfänger würde ich sogar empfehlen ganz auf USB-Midi zu 
verzichten. Ein billiges USB-Midi-Interface ist nicht größer als die 
USB-Buchse und damit preiswerter als eine Stunde Arbeitszeit.
https://www.thomann.de/de/swissonic_midiconnect_2.htm
Damit kann man sich erst mal in sein Projekt einarbeiten.
Ein weiterer großer Vorteil ist, dass nicht ständig die USB-Enumeration 
abläuft zwischen 2 Debug-Durchläufen. Die PC-Software kann damit auch 
mit geöffnetem Midi-Interface stehen bleiben. Da spart bei der 
Entwicklung viel Zeit und Arbeit.