Custom class for STM32 USB device library

[Vincent H. (vinci)]

Grüß euch

Ich hab über die Feiertage ein wenig Zeit mit der STM32 USB Device 
Library verbracht. Speziell hat mich interessiert wie man eigene USB 
Device Klassen in die Library einbinden kann.

Das ganze ist zu einer Art Tutorial geworden dass es hier gibt:
https://higaski.at/custom-class-for-stm32-usb-device-library/

In dem Tutorial setz ich ein Projekt auf einem NUCLEO H743 Board auf 
dass ASCII-Strings via USB hin- und herschickt und die 
Groß-Kleinschreibung umdreht. Das ganze geschieht interaktiv mit Hilfe 
eines Python Skripts und PyUSB.

Parallel zu dem Tutorial gibt es ein Repo wo man Schritt für Schritt 
nachvollziehen kann was gemacht wurde.

[Johannes S. (Gast)]

schöne Arbeit, hättest du aber auch schon fertig bekommen ;)
https://os.mbed.com/docs/mbed-os/v5.15/apis/usb.html
sogar ohne exclusiv Bindung an STM Controller.

[Vincent H. (vinci)]

Johannes S. schrieb:
> schöne Arbeit, hättest du aber auch schon fertig bekommen ;)
> https://os.mbed.com/docs/mbed-os/v5.15/apis/usb.html
> sogar ohne exclusiv Bindung an STM Controller.

Ich les bei Mbed nichts von "custom classes", insofern nein. In meinem 
Beispiel nutze ich keine(!) Device Klasse und nur eine Interface-Klasse 
(CDC-Data).

[W.S. (Gast)]

Vincent H. schrieb:
> In dem Tutorial setz ich ein Projekt auf einem NUCLEO H743 Board auf
> dass ASCII-Strings via USB hin- und herschickt und die
> Groß-Kleinschreibung umdreht. Das ganze geschieht interaktiv mit Hilfe
> eines Python Skripts und PyUSB.

War das nur zum Stillen deiner Neugier? Ich sehe ja ein, daß man 
gelegentlich die Lust drauf hat, mal sowas oder ähnliches 
auszuprobieren. Aber ein Device ohne irgend eine etablierte 
Geräteklasse? Das bedeutet auf der PC-Seite, daß man quasi im Regen 
steht, weil es am PC nix gibt, was in irgend einen standardisierten 
Kanal mündet. Folglich kann man auf dem PC auch nicht mit irgend einer 
sinnvollen Unterstützung des OS rechnen und man kann erst recht nicht 
übliche Programme nutzen. Als krasses Gegenbeispiel nenne ich mal nen 
virtuellen COM-Port. Den kann man dann mit allen möglichen 
Terminalprogrammen öffnen und zum Kommunizieren benützen.

W.S.

[Niklas G. (erlkoenig)]

W.S. schrieb:
> Das bedeutet auf der PC-Seite, daß man quasi im Regen
> steht, weil es am PC nix gibt, was in irgend einen standardisierten
> Kanal mündet.

Das ist halb so schlimm, mit libusb ist es ziemlich einfach mit eigenen 
Programmen auf eigene USB-Geräte zuzugreifen:

https://www.mikrocontroller.net/articles/USB-Tutorial_mit_STM32#Eigene_Anwendung_f.C3.BCr_PC-Seite

W.S. schrieb:
> Den kann man dann mit allen möglichen
> Terminalprogrammen öffnen und zum Kommunizieren benützen.

Dafür ist der aber weniger flexibel - man ist nur auf einen Kanal 
(Endpoint) festgelegt und kann nicht mit einer fixen Aufteilung auf 
USB-Pakete rechnen, wenn man mit den üblichen SerialPort-APIs zugreift.

Ist der Begriff "Custom Class" üblich? Ich dachte man nennt das 
Vendor-Specific, denn Klassen kann nur das USB-IF definieren...

[Vincent H. (vinci)]

Genau genommen ist "0" ja eh eine etablierte Klasse, nur halt eine wo 
man auf den Interface Descriptor verweist. Der Interface Descriptor 
wiederum nutzt CDC-Data (0x0A) das laut CDC-Spezifikation für 
Anwendungsfälle gedacht ist die via CDC Device Klasse (0x02) nicht 
abgedeckt werden. Übrigens ist laut CDC-Spezifikation sogar beim 
"normalen" CDC die Device-Klasse optional!

Ich persönlich hab eine simple Datenübertragung für ein Testgerät 
gebraucht und wollte eben nicht dass die Nutzer ständig explizit 
irgendeinen Port angeben müssen.

Niklas G. schrieb:
> Ist der Begriff "Custom Class" üblich? Ich dachte man nennt das
> Vendor-Specific, denn Klassen kann nur das USB-IF definieren...

Keine Ahnung. Den Begriff verwendet ST in ihren Dokumenten. Damit ist 
aber wohl eher die "Klasse" im Code gemeint. Eine Custom Class könnte 
damit auch alles andere sein was ST von Haus aus nicht unterstützt aber 
sehr wohl einen USB-Code besitzt.