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

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

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.

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?

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.

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.

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

STM32L072

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

1

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

2

[ 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

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"

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?

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

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

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.

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)

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

https://github.com/DeqingSun/ch55xduino

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.