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.
Gast
#6103311
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.
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).
Gast
#6105311
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.
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...
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.