Hallo zusammen, mit HID funktionieren USB-Geräte auch unter Windows "einfach so" ohne expliziten Treiber. Serielle Schnittstelle und CDC sind 2023 meines Erachtens längst reif für die Rente. Auf der Basis der Library von W.S. habe ich deswegen die angehängte kleine Library für STM32 geschrieben. Sie kann Reports mit 63 Byte zwischen Host (PC) und Device (µC) hin und her schicken. Bisher ist der Code nur auf einem STM32F042 getestet. Ich wäre dankbar, wenn jemand versuchen würe, das auf einem STM32F103 o.ä. zu testen und ggf. den Code anzupassen (bitte passende #define setzen) Code anbei. Anwendungshinweise: 1. Rechner samt USB in STM32CubeMX konfigurieren. USB-Middleware NICHT einbinden/konfigurieren. Wer mag, kann natürlich CubeMX ganz weglassen und die Register (Clock und GPIO) per HAL oder zu Fuß setzen. 2. usb.c und usb.h ins Projekt einbinden 3. Den USB_IRQHandler() in stm32xxx_it.c auskommentieren oder mit "__attribute((weak))" versehen bzw. (für die HAL-Fraktion) dafür sorgen, dass der USB-Interrupt USB_IRQHandler() in usb.c aufruft. 4. Der Rest sollte über die main.c und die Kommentare in usb.h halbwegs klar sein. 5. Test unter Windows mit SimpleHIDWrite (das Programm muss man an und ab neu starten). Reports von Host an Device haben die ReportID 2. Wenn man "Falscher Parameter (57)" in SimpleHIDWrite bekommt, hat man die falsche ReportID angegeben. Reports vom Device an den Host kommen mit ReportID 1. 6. Für Python gibt es PyWinUSB und HidAPI. Erfahrungsberichte willkommen. Wenn es nicht tut: 1. Passen alle Clocks, und sind sie aktiviert? USB braucht 48 MHz. 2. Ist der NVIC richtig eingestellt? Die Interrupt-Nummer für USB steht im Reference Manual unter "Interrupt and exception vectors" 3. Wird der Pullup für die USB-Erkennung aktiviert? Die neueren Devices machen das über DPPU, aber ältere wie der SM32F103 brauchen da etwas Handarbeit und einen externen Widerstand. Anpassung am Ende von UsbSetup(). Anmerkungen: * Über das "Warum" mag ich nicht diskutieren. * Ich erhebe nicht den Anspruch auf Perfektion. Sachliche Kritik an der Library ist willkommen, bevorzugt mit Korrekturvorschlag. * Wer nicht weiß, welche Polling Rate er nehmen soll, kann 125 reinschreiben (das ist der USB-Standardwert) * Mein Coding Style unterscheidet sich von dem von W.S. Das führt im Ergebnis zu einem etwas unschönen Mix. Ist so. * Ein paar Kommentare sind aus CDC-Zeiten übrig geblieben und sind noch aufzuräumen. Frohes neues Jahr allen!
Cool, werde ich mit meinem neuen Board mal ausprobieren, dass basiert auf einem STM32F070. Ben
Was macht man denn mit einem HID auf einem Controller? Bitte um Aufkläreung bzw. Bedarfsweckung. Bin da gerade etwas phanasielos, mache alles was ich brauche mit CDC und bin "glücklich" damit.
- Definierte Latenz bis runter zu 1ms (ok, real eher < 2) - Kein Raten „welcher COM-Port ist es denn“, sondern Identifikation mit PID/VID - Datenrate bis echte 64 KByte/s (das wären beim UART so 700 kBit/s durch Start- und Stopbits) - Keine Treiberinstallation unter Windows - Mehrere gleiche Geräte lassen sich über die Seriennummer unterscheiden. Aus Nutzersicht: Anstecken, läuft. Mir ist noch eingefallen, dass bei höheren Tempo die Library vermutlich zickt, weil sich ACK und zu sendende Pakete in die Quere kommen. Fixe ich, wenn es mich stört.
Max G. schrieb: > CDC sind 2023 meines > Erachtens längst reif für die Rente. Ethernet over USB ist reif für die Rente?
Ich nutze es zur Joystick/Gamepad emulation. Und unschlagbar: anstecken -> läuft.
Max G. schrieb: > mit HID funktionieren USB-Geräte auch unter Windows "einfach so" ohne > expliziten Treiber. Serielle Schnittstelle und CDC sind 2023 meines > Erachtens längst reif für die Rente. Da hast du eine recht eigentümliche Sichtweise. Also erstmal die technische Seite: Die HID-Geräteklasse ist vorgesehen für Geräte, die als Bedienelemente für den PC fungieren sollen, also Tastaturen, Mäuse und dergleichen. Jegliche anderweitige Verwendung ist eigentlich ein Mißbrauch, wengleich auch möglich. Virtuelle und echte COM-Ports sind hingegen genau dafür vorgesehen, Daten zwischen Geräten zu transportieren. Wenn du also mit deinem µC oder der Mondfähre oder deinem kleinen grünen Kumpel vom Mars kommunizieren willst, sind solche Kanäle wie COM-Ports (egal ob virtuell oder nicht) eigentlich das genau dafür Vorgesehene. So nun die eher untechnische Seite: Der ganze USB ist eigentlich eine geschlossene Gesellschaft: Man zahlt Eintritt und kriegt ein vid&pid und hat zu seinem Produkt eben auch den passenden Treiber für's OS mitzuliefern. Das gehört zu den Regeln des Clubs. Ehe jetzt all die Linuxer und FOSS-Leute aufkreischen, sollten sie sich fragen, ob sie eine vid&pid gekauft haben oder ob sie sich einfach nur breitgemacht haben wie damals die Goldgräber in Kalifornien mit dem Revolver. Ja, das ist eigentlich eine recht unbefriedigende Situation. Bildlich gesagt ist das Eis dünn für alle, die da etwas programmieren wollen ohne zuvor besagte Eintrittskarte bezahlt zu haben. Also nicht allzu laut herumtrampeln. W.S.
W.S. schrieb: > Also erstmal die technische Seite: Die HID-Geräteklasse ist vorgesehen > für Geräte, die als Bedienelemente für den PC fungieren sollen, also > Tastaturen, Mäuse und dergleichen. Jegliche anderweitige Verwendung ist > eigentlich ein Mißbrauch, wengleich auch möglich. Lieber W.S., alleine die Tatsache, dass ich deine Library umgeschrieben habe, zeugt von meinem Respekt dir gegenüber. Insofern hoffe ich, dass du dich durch mein Werk nicht angegriffen fühlst. Eher darauf, dass du die Library mal testest und mir sagst, wo ich überall einen Wurm drin habe. Unter praktischen Gesichtspunkten ist das Suchen nach COM-Ports einfach nur nervig, und ich sehe den Vorteil darin absolut nicht. Wenn es ein Missbrauch von USB/HID ist, das anwenderfreundlicher zu gestalten, sei es drum. Da hat jeder von uns schon bösere Sünden begangen. Abgesehen davon sind viele Geräte, mit denen wir herumspielen, letztendlich HIDs - jedes Messgerät ist doch eines. Nach meiner Erinnerung melden sich auch die schweineteuren Keysight-Spannungsversorgungen mit USB als HID-Geräte. Und die blöden KNX-Dongles ebenfalls. Auch KNX-USB-Schnittstellen sind als HID definiert, wobei das nur bei sehr großzügiger Auslegung von "HID" stimmt. Immerhin haben beide Firmen ihre VIDs bezahlt :) Deine Anmerkung zur geschlossenen Gesellschaft ist vollkommen richtig, wird aber selbst von großen Firmen in der Praxis gerne großzügig ignoriert. Und gilt für CDC/VCP-Devices ebenso. Hat deine Library eigentlich eine bestimmte Lizenz? Wenn nein, würde ich über mein Ergebnis (bei deiner Zustimmung) BSD drüber schreiben und das Ganze auf Gitlab packen. Gruß Max
:
Bearbeitet durch User
moin, ab STM32F4xx funktioniert dieser Treiber nicht mehr, andere USB-Core. Pieter
Max G. schrieb: > Serielle Schnittstelle und CDC sind 2023 meines > Erachtens längst reif für die Rente. Ist das Missbrauchen von HID aber auch... Max G. schrieb: > mit HID funktionieren USB-Geräte auch unter Windows "einfach so" ohne > expliziten Treiber. WinUSB-Geräte mit OS Compat Descriptor auch. Anstecken, funktioniert sofort. Braucht auch keine Admin-Rechte. Anzusteuern über WinUSB oder libusb. Dadurch hat man die volle Flexibilität von USB, man kann mehrere Endpoints beliebigen Typs nutzen. Auf Geräteseite ist nur minimaler Zusatzaufwand in Form der zusätzlichen Deskriptoren nötig. https://github.com/pbatard/libwdi/wiki/WCID-Devices Max G. schrieb: > Hat deine Library eigentlich eine bestimmte Lizenz? Da wurde schon ausführlich drüber gestritten. W.S. hat sich nach langem Betteln dazu herabgelassen hier eine "Lizenz" anzugeben: Beitrag "Re: USB CDC von Stefan Frings und WS" Ich hatte hier eine fehlerkorrigierte Version des W.S.-Code hochgeladen (aufgrund W.S.' Verweigerung gegenüber Debugging hatte er seit Jahren die Bugs in seinem Code nicht finden können): https://github.com/Erlkoenig90/WSusb
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.