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.
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.
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.
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.
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 :)
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.
