Welchen (günstigen) µController für USB-MIDI?

[Eric A. (cybered)]

Hallo,
ich suche einen möglichst günstigen µController mit nativem USB Support 
den ich vorzugsweise über die Arduino IDE als USB-HID/MIDI Device nutzen 
kann.
Zur Zeit nutze ich meist Arduino Leonardos/Micro(Pro) sowie auch schon 
mal einen Arduino Uno mit umgeflashten 16U2 Controller.

Für manche Projekt ist das aber einfach zuviel  zu groß  zu teuer. Ich 
dachte an sowas wie einen ATTiny oder ähnliches wo auch die Platine 
entsprechend klein ist. Ich habe gesehen das manche Modelle zB. 3 
analoge Inputs bieten, das würde vollkommen ausreichen, leider scheint 
es so dass die ATtiny kein natives USB beherschen.

Welche µController mit nativem USB und Arduino-Kompatibilität wären 
eurer Meinung nach noch einen Blick wert?

Vielen Dank im Voraus und viele Grüße,
Eric

[Harald K. (kirnbichler)]

Eric A. schrieb:
> leider scheint es so dass die ATtiny kein natives USB beherschen.

Tun sie nicht. Aber wo ist das Problem? Für USB-MIDI ist nur 
Low-Speed-USB erforderlich, und das kann mit V-USB ein AtTiny 
spezifikationskonform emulieren. Mit einem AtTiny85 
(Digispark/Digistump) lässt sich die Arduino-Umgebung zusammen mit V-USB 
verwenden.

Hier ein Beispiel:

https://www.hackster.io/janost/diy-usb-midi-to-cv-0a5469

[Clemens L. (c_l)]

Harald K. schrieb:
> Für USB-MIDI ist nur Low-Speed-USB erforderlich

USB MIDI benutzt Bulk-Transfers, die Full Speed benötigen. Wenn du Low 
Speed mit Interrupt-Transfers benutzt, dann verlässt du dich darauf, 
dass der Treiber auf dem PC den Transfer-Typ nicht überprüft oder 
Interrupt-Transfers explizit unterstützt.

> und das kann mit V-USB ein AtTiny spezifikationskonform emulieren.

V-USB hat einige positive Eigenschaften (insbesondere, dass es in der 
Praxis oft läuft, wenn man keine USB-3-Ports benutzt), aber 
"spespezifikationskonform" ist keine davon.

[Harald K. (kirnbichler)]

Clemens L. schrieb:
> USB MIDI benutzt Bulk-Transfers, die Full Speed benötigen.

Ach? Dann wäre eine spezifikationskonforme Implementierung mit V-USB 
nicht möglich; aber wofür benutzt es die?

> aber "spespezifikationskonform" ist keine davon.

Magst Du verraten, wo bei HID dann das Problem liegen mag?

[Clemens L. (c_l)]

Eric A. schrieb:
> Welche µController mit nativem USB und Arduino-Kompatibilität wären
> eurer Meinung nach noch einen Blick wert?

Teensy. Ist aber als Board nicht kleiner als die Arduinos.

PIC16F1454. Ist aber anscheinend nicht Arduino-kompatibel.

[Clemens L. (c_l)]

Harald K. schrieb:
> Clemens L. schrieb:
>> USB MIDI benutzt Bulk-Transfers, die Full Speed benötigen.
>
> ... wofür benutzt es die?

Ich habe die Spezifikation nicht geschrieben. Anscheinend wollten sie 
nicht dauerhaft Bandbreite für MIDI reservieren.

>> aber "spespezifikationskonform" ist keine davon.
>
> Magst Du verraten, wo bei HID dann das Problem liegen mag?

objective development sagt:
> Fully USB 1.1 compliant low-speed device, except handling of communication
> errors and electrical specifications.

Ich weiß nicht, welche dieser beiden Ausnahmen bei USB 3 so oft Probleme 
machen. Ich vermute eher, dass es noch Timing-Problemen gibt.

[J. S. (jojos)]

Die Blackpill boards:
https://de.aliexpress.com/item/1005001456186625.html?gatewayAdapt=glo2deu

[Motopick (motopick)]

STM32L072

[Martin H. (horo)]

Clemens L. schrieb:
> USB MIDI benutzt Bulk-Transfers, die Full Speed benötigen. Wenn du Low
> Speed mit Interrupt-Transfers benutzt, dann verlässt du dich darauf,
> dass der Treiber auf dem PC den Transfer-Typ nicht überprüft oder
> Interrupt-Transfers explizit unterstützt.

Linux modifiziert den Typ:
https://forums.obdev.at/viewtopic6560.html?f=8&t=1352&start=15#p9092

[ 8848.456365] usb 1-2: config 1 interface 1 altsetting 0 endpoint 0x1 is Bulk; changing to Interrupt
[ 8848.456379] usb 1-2: config 1 interface 1 altsetting 0 endpoint 0x81 is Bulk; changing to Interrupt

Es funktioniert aber auch, wenn der Descriptor (nicht standard-konforme) 
Interrupt-Transfers nutzt.

Den MIDI-Hack für VUSB hatte ich vor langer Zeit zum Laufen gebracht, es 
gibt einen langen Thread dazu:

https://forums.obdev.at/viewtopic1613.html

Martin

[Thomas Z. (usbman)]

CH552 von WCH. Ich hab das mal vor einiger Zeit programmiert. Der Code 
lässt sich mit Keil und SDCC übersetzen

Beitrag "Usb Midi Firmare für die WCH CH55x Controller"

[Clemens L. (c_l)]

Martin H. schrieb:
> Clemens L. schrieb:
>> USB MIDI benutzt Bulk-Transfers, die Full Speed benötigen. Wenn du Low
>> Speed mit Interrupt-Transfers benutzt, dann verlässt du dich darauf,
>> dass der Treiber auf dem PC den Transfer-Typ nicht überprüft oder
>> Interrupt-Transfers explizit unterstützt.
>
> Linux modifiziert den Typ:

Aber manche Windows-Versionen tun das nicht.

> Es funktioniert aber auch, wenn der Descriptor (nicht standard-konforme)
> Interrupt-Transfers nutzt.

Ich kann das nur für Linux garantieren. Microsoft schreibt usbaudio.sys 
gerne mal komplett neu; hast du das mit Windows getestet?

[Eric A. (cybered)]

Vielen Dank, die Sache mit dem Attiny und den Blackpills schaue ich mir 
an ;-)

[N. M. (mani)]

Kleines RP2040 Board?
z.B. so was:
https://a.aliexpress.com/_ExLnNzv

[Martin H. (horo)]

Clemens L. schrieb:
> hast du das mit Windows getestet?

Ja, siehe den Thread auf obdev.at in meinem Beitrag oben. Wenn ich mich 
recht erinnere, ging es mit W2k, XP und möglicherweise auch noch mit W7. 
Da ich kein Win nutze, habe ich die Nachfolger ignoriert.

[Thomas Z. (usbman)]

Martin H. schrieb:
> Wenn ich mich
> recht erinnere, ging es mit W2k, XP und möglicherweise auch noch mit W7.

W2K sicher nicht usbaudio.sys hat erst ab XP usb-midi unterstützt. Bei 
W2K gabs einen Bluescreen. Da bulk und interrupt  Transfers bis auf die 
Latenz gleich funktionieren, könnte das durchaus unter Win funktioniert 
haben, MS ist dafür bekannt bei USB die Parameter nicht sehr sorgfältig 
zu prüfen. Bei W10 geht nur noch Bulk mit 64 Bytes. (Midi 1.0)

[Jürgen (temp1234)]

Ich hatte vor einiger Zeit mal Code für ein 1-4 Port Interface auf 
stm32f103 gepostet. Vielleicht hilft das:
Beitrag "STM32 USB-MIDI"

[Sigint 112 (sigint)]

https://github.com/DeqingSun/ch55xduino

[C-hater (c-hater)]

Thomas Z. schrieb:

> MS ist dafür bekannt bei USB die Parameter nicht sehr sorgfältig
> zu prüfen.

Auch Linux hat das sehr lange Zeit nicht geprüft und genau wie 
WindowsXP Bulk-Endpoints für Lowspeed-Devices einfach akzeptiert.

Erst als MS anfing, die diesbezügliche, aus den USB-Specs resultierende 
Restriktion zu prüfen (und ggf. die Geräteanmeldung einfach zu 
verweigern), sprang auch die Linux-Gemeinde auf den Zug auf und begann 
ebenfalls, diese Sache zu prüfen.

Sie fand dann aber immerhin einen brauchbaren (wenn auch natürlich immer 
noch standardwidrigen) Workaround, um den existierenden Geräten (deren 
Existenz vermutlich überhaupt erst die ganze Sache in's Rollen gebracht 
hat und wohl wirklich praktisch zu 100% V-USB war) doch noch ein 
Weiterleben zu ermöglichen.

Und der Trick ist einfach, das die Bulk-Endpoints als 
Interrupt-Endpoints behandelt werden, so lange sich die die im 
Descriptor deklarierte maximale Paketgröße im zulässigen Bereich für 
Interrupt-Endpoints befindet. Auch damit ist der technische Zweck des 
Verbots von Bulk-Endpoints für LowSpeed-Devices letzlich erreicht. Aber 
eben nicht standardgerecht.

Standardgerechtes Verhalten wären ganz klar das, was Windows tut: das 
Gerät wird einfach nicht akzeptiert.