Hallo zusammen,
erst mal allen ein frohes neues Jahr 2023 mit Glück, Gesundheit und
lieferbaren Bauteilen!
Ich habe versucht, den USB-Code von W.S. auf dem STM32F042 zum Laufen zu
bringen und auf ein reines HID-Device umzubauen. Das Gerät wird
inzwischen sauber enumeriert, sowohl Windows als auch Linux sind damit
prinzipiell zufrieden.
Ich möchte auf EP1 Reports mit 64 Byte Größe senden (und in einem
zweiten Schritt empfangen). Der Host pollt auch fröhlich, aber ich
schaffe es absolut nicht, eine Antwort zu senden.
Beobachtungen:
* Double Filtering hatte ich mal aktiviert, aber inzwischen
auskommentiert.
* Wenn ich den EP Type korrekt auf "3" für "Interrupt" stelle, löst der
IRQ-Handler nicht aus. Wenn ich den EP Type (inkorrekt) auf "2" für
"ISO" stelle, löst der IRQ-Handler aus, aber Linux beschwert sich mit
-71 über einen Protokollfehler.
* Wenn ich in OnEpIntIn() versuche, zu antworten, scheinen immer 0 Byte
auf der Host-Seite anzukommen, auch wenn ich die Länge auf die
(korrekten) 64 stelle. Ob ich (entgegen dem User Manual) die oberen Bits
von USB_COUNTn_TX (also BL_SIZE und NUM_BLOCKS) auch noch setze, ist
dabei egal.
* Ich habe User Manual, USB in a Nutshell, eccelerator.com, usbmon,
Beyond Logic, jede Menge Forenbeiträge und natürlich das USB-Tutorial
von µC.net durch. Man werfe mir also gerne Blödheit vor, aber nicht
Faulheit...
Der (mit dem beiliegenden Skript etwas aufgepeppte) Trace von usbmon
sieht wie unten aus. Problematisch wird es nach dem letzten "Callback
Control In" (das ist die Antwort auf die Frage nach dem HID Descriptor).
Hat jemand der Anwesenden einen heißen Tipp, wo ich noch schauen könnte?
Langsam bin ich echt frustriert. Ach so: CubeMX ist mindestens genauso
frustrierend, und auf CDC zurück will ich nicht[1].
Vielen Dank!
Max
1
>> Ci:1:000:0 s 80 06 0100 0000 0040 64 < [submission Control In]
da war doch was mit der ReportID zumindest unter Windows
Du must ReportID + 64Bytes schicken für In also:
0x01 + "blablub"... insgesmmt 65 bytes aufgeteilt in 2 packets.
sorry hab schon lange nichts mehr mit HID gemacht.
Für out ist es genauso
Hallo Thomas usbman,
danke für die Unterstützung. Mit deiner Hilfe bin ich weiter gekommen.
Bei Full Speed können maximal 64 Byte in einem Paket übertragen werden,
ich habe deshalb die Report Size auf 63 reduziert.
Es sieht aus, als funktioniere nun endlich die Kommunikation. Extrem
verwirrend war, dass der Linux-Kernel mit dem Pollen bei Interrupts wohl
erst dann anfängt, wenn man einmal was auf das Device geschrieben hat -
aber vielleicht ist das Problem auch nur irgendwo zwischen Kernel,
USB-Spec, usblib, hidapi und Python versteckt. Oder ich habe doch noch
irgendwo einen Wurm drin. Aber nun kommen die Pakete und Interrupts auch
mit dem korrekten Endpoint Type.
Mit Windows habe ich noch nicht getestet. Morgen ist auch noch ein Tag
:)
Viele Grüße,
Max
(der sich viel, viel mehr freut, als aus diesem eher nüchternen Post
herauszulesen ist. Ich habe jetzt vier Tage mit dem blöden USB
gekämpft).
Wenn der Report keine ReportID verwendet (= 0), dann rechnet die auch
nicht zur Reportlänge dazu.
Der ST USB-Stack hat aber zwei spaßige Fehler die wir ST auch mitgeteilt
haben, die aber bisher in der Library nicht behoben wurden.
Einer davon betrifft bidirektionale Interrupt-Endpoints. Da kann
mittendrin plötzlich die Senderichtung einfrieren, weil die
Interrupt-Routine immer beide Interrupt-Flags, also für In und Out
gleichzeitig löscht.
Guido Körber schrieb:> Wenn der Report keine ReportID verwendet (= 0), dann rechnet die auch> nicht zur Reportlänge dazu.
Hallo Guido,
ja, danke. Im Moment bin ich ganz froh, dass es überhaupt funktioniert.
Der Rauswurf des (letztendlich unnötigen) Report Descriptors kommt dann
in v 0.02 :)
> Der ST USB-Stack hat aber zwei spaßige Fehler die wir ST auch mitgeteilt> haben, die aber bisher in der Library nicht behoben wurden.
Ach ja, ST und CubeMX. Wenn ich recht überlege, habe ich bis jetzt jedes
Mal am Ende den CubeMX-Code rausgeworfen und nur die HAL genommen.
Bloaty (ohne -Os eigentlich nie zu linken), buggy (siehe dein Beispiel)
und schlecht dokumentiert (habe zwei Tage gesucht, warum CAN nicht
funktioniert).
Deswegen habe ich (nach einem vegeblichen Versuch, das zu Fuß zu
stricken) auf die Library von W.S. aus dem Forum hier aufgesetzt und der
das Rauchen, nein das CDC abgewöhnt.
Grüße und frohes neues Jahr,
Max
Max G. schrieb:> Deswegen habe ich (nach einem vegeblichen Versuch, das zu Fuß zu> stricken) auf die Library von W.S. aus dem Forum hier aufgesetzt und der> das Rauchen, nein das CDC abgewöhnt.
Hier im Forum gibt es ja einige die sich mit dem Code von W.S. ausgiebig
beschäftigt haben und ihn auch benutzen. Vor einiger Zeit hatte ich hier
auch mal ein Beispiel für eine Midi-Implementierung eingestellt. Es wäre
jedenfalls schön, wenn du am Ende hier ein funktionierendes Beispiel
einstellen könntest.
Max G. schrieb:> ja, danke. Im Moment bin ich ganz froh, dass es überhaupt funktioniert.> Der Rauswurf des (letztendlich unnötigen) Report Descriptors kommt dann> in v 0.02 :)
Nicht den Descriptor raus werfen, nur das Element für die ReportID. Das
ist 0x85 gefolgt von einem Byte für die ID.
Wenn der Descriptor fehlt, wird das Device nicht enumeriert.
Den USB-Stack von ST haben wir mittlerweile recht gründlich umgegraben,
der kann jetzt mehr und braucht deutlich weniger Platz :)
Guido Körber schrieb:> Den USB-Stack von ST haben wir mittlerweile recht gründlich umgegraben,> der kann jetzt mehr und braucht deutlich weniger Platz :)
Kann man sich das irgendwo anschauen?
Guido Körber schrieb:> Nicht den Descriptor raus werfen, nur das Element für die ReportID.
Ja, ist klar. Da hatte ich mich falsch ausgedrückt. Nicht enumerierende
Devices hatte ich drei Tage lang, damit bin ich vorerst versorgt.
Im Moment lasse ich die Report ID aber drin. Es muss ja noch Potenzial
bestehen. :)
temp schrieb:> Es wäre> jedenfalls schön, wenn du am Ende hier ein funktionierendes Beispiel> einstellen könntest.
Das ist selbstverständlich. Ich habe noch aufgeräumt, Ergebnis ist nun
hier: Beitrag "USB mit HID für STM32"
Harry L. schrieb:> Kann man sich das irgendwo anschauen?
Nur als fertiges Produkt :)
Die Bugs haben wir an ST gemeldet, da waren zwei Klöpse drin die
gefährlich werden können, wenn das in irgend etwas wichtigem passiert.
Also so wie bei Kunden von uns, die damit z.B. Joysticks bauen und
teilweise sehr große Maschinen steuern. Wenn da mitten im Betrieb der
Controller absäuft, dann ist das nicht so witzig.
Die konstruktiven Änderungen sind aber unser Know How, das gibt es nicht
als Code, sondern nur im Produkt.
Thread beobachten
Seitenaufteilung abschalten