Hallo Leute, ich bin aktuell etwas ratlos und könnte ein paar Denkanstöße gebrauchen. Es geht um einen STM32F103C8 als USB HID Keyboard. Umgesetzt mit der ST Standard Peripheral Library und der ST USB Lib nach http://www.dl1dow.de/inhalt/selbstbau/hid_keyboard/index.htm. Am PC funktioniert es und ich kann einzelne Zeichen senden. Aber an einem Display mit WIN CE drauf funktioniert es nicht. Leider sind dort die Möglichkeiten etwas zu überprüfen recht eingeschränkt. Was mir aufgefallen ist, am PC mit USB Tree View wird mir der Report Descriptor nicht angezeigt. Bei Error steht aber OK. Von meiner echten Tastatur wird der Report Descriptor angezeigt. Bei meiner Maus wird er aber auch nicht angezeigt. Also keine Ahnung, ob das ein Hinweis sein kann. Außerdem steht im USB Tree View noch ----------------- Device Qualifier Descriptor ----------------- Error : ERROR_GEN_FAILURE Hat vielleicht jemand eine Idee in welche Richtung ich noch gucken könnte?
Lutz K. schrieb: > T USB Lib nach > http://www.dl1dow.de/inhalt/selbstbau/hid_keyboard/index.htm. Am PC Nanu? Wie bist Du auf diesen alten -nicht funktonierenden- Link gestoßen? Der aktuelle Link (so seit 2014) lautet: http://www.dl1dow.de/artikel/hid_keyboard/index.htm Zu Deiner Frage: Kann Dein Windows CE-Gerät HID-Geräte mit Full Speed adressieren? Im HID-Standard ist das nicht explizit vorgesehen, funktioniert unter Windows und Linux trotzdem. Edit: Ich habe es gefunden. In der _Firmware.txt. Muss ich mal korrigieren.
:
Bearbeitet durch User
Walter T. schrieb: > Zu Deiner Frage: Kann Dein Windows CE-Gerät HID-Geräte mit Full Speed > adressieren? Im HID-Standard ist das nicht explizit vorgesehen, > funktioniert unter Windows und Linux trotzdem. Hallo Walter, da hat es ja der richtige gelesen ;-) Das ist eine gute Frage, ich habe keine Ahnung. Ich dachte es, da meine Maus am PC auch als Fullspeed angemeldet ist. Allerdings habe ich auch etwas von 2 Geschwindigkeitsprofilen gesehen. Was müsste ich denn tun, um "low speed" auszuprobieren? Müsste dazu der PullUp auch an D-?
Lutz K. schrieb: > da hat es ja der richtige gelesen ;-) Reiner Zufall. Das Projektchen liegt lange zurück. Lutz K. schrieb: > Was müsste ich denn tun, um "low speed" auszuprobieren? Keine Chance. Der STM32F103 kann meines Wissens nach nur "full speed". Deswegen auch diese seltsame Kombination.
Walter T. schrieb: > Keine Chance. Der STM32F103 kann meines Wissens nach nur "full speed". > Deswegen auch diese seltsame Kombination. Das wäre aber ärgerlich. Normalerweise geht doch auch immer "langsamer". Noch eine andere Frage, was hat es eigentlich mit 0x40, // bMaxPacketSize 64 <===== spaeter: 8 aus const uint8_t keyboard_DeviceDescriptor[KEYBOARD_SIZ_DEVICE_DESC] = auf sich? Mit 8 funktioniert es nicht...
Lutz K. schrieb: > Noch eine andere Frage, was hat es eigentlich mit > 0x40, // bMaxPacketSize 64 Siehe S. 21: http://pierrelib.pagesperso-orange.fr/buses/USB_in_a_Nutshell.pdf Lutz K. schrieb: > Mit 8 funktioniert es nicht... Ja, passt dann nicht mehr zu BUFFERSIZE (definiert in keyboard.c). Alle Tastaturen, von denen ich mir den Descriptor angeschaut habe, hatten 8 Bit. Deswegen war das mein ursprüngliches Ziel. Nachdem es allerdings an jedem getesteten Rechner mit 64 Bit auch funktioniert hat, habe ich es bei 64 Bit belassen, weil dann alle möglichen Telegramme an einem Stück hineinpassen und ich mir das lästige Warten erspare. Ohjeohje....eigentlich sollte man sich so alten Quelltext nicht mehr angucken. Und wenn doch, dann jede Urheberschaft abstreiten. Keine Ahnung, wer meinem Quelltext von vor 5 Jahren verzapft hat.
:
Bearbeitet durch User
Hehe, danke für die Antworten. Mit einem USB-HUB dazwischen funktioniert es. Könnte also wirklich am "Full Speed" liegen. Das hilft mir jetzt zumindest temporär etwas weiter. Aber wie komme ich nun am einfachsten ohne HUB zu "Low Speed"?
Lutz K. schrieb: > Aber wie komme ich nun am einfachsten ohne HUB zu "Low Speed"? Zeig mal den Schaltplan der USB-Anbindung Deines µCs. Gibt es da einen Pullup- oder Pulldown-Widerstand an einer der beiden USB-Datenleitungen?
> Gibt es da einen Pullup- oder Pulldown-Widerstand an einer > der beiden USB-Datenleitungen? Bei dem Stichwort fällt mir ein: Geht es um ein Blue-Pill Board? Da ist R10 meistens (immer?) falsch bestückt.
Lutz K. schrieb: > Aber wie komme ich nun am einfachsten ohne HUB zu "Low Speed"? Mit dem Controller gar nicht. Da jeder Host Full Speed können muss, macht es für einen Mikrocontroller keinen Sinn, Full Speed und low Speed zu unterstützen - verschwendetes Silizium. Daher können die immer nur genau eins von diesen beiden. Die Kombination High Speed + Full Speed ist allerdings Pflicht, da auch HS Geräte erst als FS starten.
Dr. Sommer schrieb: > Mit dem Controller gar nicht. Dann wäre natürlich irgendein AVR mit V-USB eine Alternative. Als HID ist das Bit-Banging von dem ja sogar spezifikationskonform.
Rufus Τ. F. schrieb: > Zeig mal den Schaltplan der USB-Anbindung Deines µCs. Gibt es da einen > Pullup- oder Pulldown-Widerstand an einer der beiden USB-Datenleitungen? Ich habe einen PullUp an D+ über einen Jumper damit der Host ein Device erkennt und ich einfach einen Reconnect durchführen kann. Das funktioniert am PC ja auch. Ist das denn wohl plausibel, dass es am "low speed" liegt, wenn es über einen USB-Hub funktioniert? Vielleicht gibt es ja einen "besseren" Treiber für das WIN CE Display.
Lutz K. schrieb: > dass es am "low speed" liegt, wenn es über einen USB-Hub funktioniert? Der Hub dürfte einen "transaction translator" enthalten und Low-/Full- auf High-Speed umsetzen: https://en.wikipedia.org/wiki/USB_hub#Transaction_translator
Lutz K. schrieb: > Ist das denn wohl plausibel, dass es am "low speed" liegt, wenn es über > einen USB-Hub funktioniert? Der Hub wird wohl kaum Low Speed am Uplink Port haben?! Der leitet das FullSpeed nur durch. Plausibel ist hier aber die Sache mit dem falschen Pullup - der PC erkennt ihn gerade noch, das WinCE Gerät nicht. Rufus Τ. F. schrieb: > Dann wäre natürlich irgendein AVR mit V-USB eine Alternative Oder V-USB auf den STM32 portieren.
Dr. Sommer schrieb: > Plausibel ist hier aber die Sache mit dem falschen > Pullup - der PC erkennt ihn gerade noch, das WinCE Gerät nicht. Wieso sollte der Pullup falsch sein?
Dr. Sommer schrieb: > Der Hub wird wohl kaum Low Speed am Uplink Port haben?! > Der leitet das FullSpeed nur durch. Aber er spricht auch dann FullSpeed mit dem Host, wenn das Device nur LowSpeed kann. Sonst wäre ja eine USB-Tastatur am Hub eine massive Bremse...
Dr. Sommer schrieb: > macht es für einen Mikrocontroller keinen Sinn, Full Speed und low > Speed zu unterstützen - verschwendetes Silizium. Daher können die immer > nur genau eins von diesen beiden. Das ist so allgemein nicht richtig. NXP LPC11U68 unterstützt z.B. beides. Lutz K. schrieb: > Ich habe einen PullUp an D+ über einen Jumper Wie groß ist der Pullup? USB will da 1k5 an 3,3V sehen laut Spec. Wenn Du da was anderes genommen hast, könnte das die Fehlerursache sein.
Mein Schaltung sieht wie angehängt aus. Pullup mit 1k5 nach 3,3V an D+. Die 4k7 nach GND habe ich mir auch irgendwo abgeguckt. War mir auch nicht ganz sicher ob besser vor oder nach der Diode und ob vor oder nach den 22R Serienwiderstand.
Jim M. schrieb: > NXP LPC11U68 unterstützt z.B. > beides. Ah, weil bei dem Low-Speed ohne Quarz geht, nicht weil man explizit Low Speed brauchen würde ;-) Also in https://www.usb.org/sites/default/files/documents/hid1_11.pdf heißt es auf S. 11: "This specification applies to both high-speed and low-speed HID class devices. Each type of device possesses various limitations, as defined in Chapter 5 of the Universal Serial Bus Specification." Kannst du auf dem WinCE Gerät Wireshark oder gar Linux installieren? Beide geben hilfreichere Details aus was da auf dem Bus passiert.
Dr. Sommer schrieb: > Kannst du auf dem WinCE Gerät Wireshark oder gar Linux installieren? > Beide geben hilfreichere Details aus was da auf dem Bus passiert. Ich kenne mich damit gar nicht aus. Muss ich probieren. Leider habe ich auch so etwas wie den Gerätemanager nicht gefunden. Ich weiß am Display quasi gar nichts zum Status. Ist die Beschaltung mit dem Pullup ok?
Lutz K. schrieb: > Ist die Beschaltung mit dem Pullup ok? Das mit den 1,5 kΩ gegen +3.3V sollte stimmen. Vielleicht sollte man die "rechts" von den Serienwiderständen anschließen? Die 4.7kΩ hab ich so noch nie gesehen, aber die haben ja keine Wirkung solange der Jumper steckt. C30/C31 finde ich spannend - möchtest du das Datensignal wegfiltern? Kannst du das USB-Signal am uC oszilloskopieren? Hast du mal eine komplett andere USB-Firmware auf den uC geflasht nur um zu sehen ob sie am WinCE-Gerät erkannt wird? Kannst du mit einem JTAG-Debugger gleichzeitig den Controller durchsteppen und schauen wie weit die Enumeration kommt? Da muss man etwas "clever" sein, weil das Anhalten des Controllers sofort PC-seitig Timeouts triggert und die Enumeration abbricht.
Also C30/C31 sind ja optional und nicht bestückt. Hab ich auch irgendwo mal gesehen und einfach mal vorgesehen. Kost ja kein Brot. Den Pullup zwischen USB-Buchse und Serienwiderständen kann ich auch noch mal ausprobieren. Interessanterweise funktioniert es an einem anderen WinCE Display (ganz anderer Typ) sogar mit einem älteren WinCE drauf. Leider laufen keine "normalen" Anwendungen auf dem WinCE. Das macht es schwieriger. Wenn es zu der Beschaltung keine Bedenken gibt, würde ich wohl mal mein Glück beim Display Hersteller versuchen. Vielleicht gibt es ja einen anderen Treiber oder so... Wenn es an meiner FW liegt, was könnte dann der HUB bewirken, mit dem es ja merkwürdigerweise funktioniert? Danke für eure Beiträge! Das hat mir schon geholfen.
Hm, jetzt hat es tatsächlich mal ohne HUB am Display funktioniert. Aber es klappt nicht immer. Gestern hat es nie geklappt.
An den einem von 2 USB Ports klappt es meist, wenn der Stecker "gefühlvoll" eingesteckt wird. Echt merkwürdig. Wenn man das mehrfach aufbauen will, dann benötigt man jedesmal zusätzlich einen HUB. Das ist doch irgendwie nicht so schön. Außerdem: "es muss doch irgendwie gehen" ;-)
Stefanus F. schrieb: > Ich würde zur Probe mal C30 und C31 entfernen. Die sind doch wie oben schon geschrieben und auch im Plan gekennzeichnet gar nicht bestückt!
Walter T. schrieb: > Was motiviert Dich, den Hub unbedingt zu vermeiden? Der Hub weist halt darauf hin, dass da irgendwo ein Problem besteht. Das zu ignorieren und immer den Hub zu nutzen ist doch Symptome bekämpfen. Irgendwann kommt das Problem dann wieder... Lutz K. schrieb: > An den einem von 2 USB Ports klappt es meist, wenn der Stecker > "gefühlvoll" eingesteckt wird. Echt merkwürdig. Hmm, vielleicht startet der Controller zu langsam? Wenn du den Stecker langsam einsteckst entsteht der Kontakt zu den Datenleitungen "lange" nachdem die Spannungsversorgung verbunden ist, und der Controller ist bis dahin hochgefahren und kann auf USB-Pakete reagieren. Wenn du schnell einsteckst ist die Datenleitung und damit der 1.5kΩ-Widerstand "sofort" angeschlossen aber der Controller vielleicht noch nicht bereit zum Antworten; dann könnte der PC in einen Timeout laufen. Allerdings sollte er es durchaus mehrfach versuchen und Resets senden bis das Device antwortet. Vielleicht ist WinCE hier besonders pingelig. Entferne mal den Jumper, stecke den USB-Stecker (schnell) rein, und stöpsele dann erst den Jumper ein. Funktioniert es dann? In dem Fall würde es helfen, wenn du den Pullup per Software schalten kannst, und zwar erst dann, wenn die Software bereit ist.
>> Ich würde zur Probe mal C30 und C31 entfernen. Lutz K. schrieb: > Die sind doch wie oben schon geschrieben und auch im Plan gekennzeichnet > gar nicht bestückt! Sorry, ich war unaufmerksam.
Ohne Jumper die USB Verbindung einstecken und dann den Jumper schließen klappt am Display auch nicht. Am PC allerding auch nicht immer. Am Display sieht es eher so aus, als ob es beim zweiten Mal einstecken klappt. Auch mit Jumper. Irgendwie scheint das Display pinkeliger zu sein, es scheint aber fast so, als wenn es generell nicht immer klappt. Nur am PC eben fast immer.
Wieviel Zeit muss man beim Jumper abziehen und wieder einstecken geben? Wenn ich länger warte klappt es idR zumindest am PC. Manchmal bekomme ich aber auch mit 5s Warten mehrfach die Fehlermeldung "unbekanntes Gerät". Dann geht es wieder mehrfach. Also irgendwie ist das ganze noch zu wackelig.
Vermutlich prellt der Jumper, sodass man das so nicht vernünftig testen kann. Hast du mal verschiedene PCs mit verschiedenen Betriebssystemen (Windows, Linux) probiert und vielleicht einen gefunden bei dem es auch nicht geht? Dann könnte man da Wireshark installieren...
Also der Pullup vor dem Serienwiderstand hat nichts verändert. Ich kann am "normalen" Windows PC mit Wireshark mal gucken. Da klappt es manchmal beim Einstecken ja auch nicht sofort.
Also mit Wireshark kann ich nichts finden. Am PC funktionierte es zuletzt aber auch zuverlässig. Am Display scheint es reproduzierbar zu funktionieren, wenn ich mein Gerät anstecke, es abziehe und wieder anstecke. Allerdings auch nur an einem von 2 USB Ports. Am anderen Port funktioniert es nur sehr selten.
Ich nochmal... es hat mir keine Ruhe gelassen. Ein kleines Testprojekt mit CubeMX und Standard HID Device (das ist dann eine Maus) erstellt und dann umgewandelt in eine Tastatur (https://damogranlabs.com/2018/02/stm32-usb-hid-mouse-keyboard) funktioniert einwandfrei am Display welches vorher etwas zickig war. Am Display (WinCE) kann ich nichts debuggen oder überhaupt etwas zum USB Status sehen. Es muss ja einen kleinen aber feinen Unterschied geben. Es kommt ja aber nicht nur rein auf die verwendeten Descriptoren an, sondern auch auf das Timing. Hat vielleicht noch jemand einen Tipp, wie ich den entscheidenden Unterschied meiner beiden Programme bei der USB Anmeldung identifizieren kann? Zumindest würde ich damit die HW erst einmal ausschließen wollen.
Lutz K. schrieb: > Hat vielleicht noch jemand einen Tipp, wie > ich den entscheidenden Unterschied meiner beiden Programme bei der USB > Anmeldung identifizieren kann? Zumindest würde ich damit die HW erst > einmal ausschließen wollen. Das ist etwas unglücklich formuliert. Auf Grund des erfolgreichen Testprogramms würde ich die HW erst einmal als Fehlerursache ausschließen und das Testprogramm als Möglichkeit sehen, den/die Unterschied(e) bei der USB Anmeldung zu finden.
Lutz K. schrieb: > Hat vielleicht noch jemand einen Tipp, wie > ich den entscheidenden Unterschied meiner beiden Programme bei der USB > Anmeldung identifizieren kann? Den hast du schon bekommen: Wireshark Ein besseres Tool dazu kenne ich nicht. > Auf Grund des erfolgreichen Testprogramms würde ich die HW erst > einmal als Fehlerursache ausschließen Ich auch.
Lutz K. schrieb: > Es muss ja einen kleinen aber feinen Unterschied geben Der wichtigste Unterschied wird sein, daß bei meinem alten Beispiel die Standard Peripheral Library Verwendung fand, während beim CubeMX-Beispiel der HAL verwendet wird - von der Programmierseite wird es Schwierigkeiten geben, überhaupt eine Gemeinsamkeit zu finden. Wahrscheinlich sind beide Seiten einfach unterschiedlich fehlerbehaftet. Ich würde jetzt einfach zur funktionierenden Basis wechseln.
:
Bearbeitet durch User
Lutz K. schrieb: > Am Display sieht es eher so aus, als ob es beim zweiten Mal einstecken > klappt. Das sieht doch sehr danach aus, als ob es am Startup Timing liegt. Entweder sind die Kondensatoren auf Deinem Board schon vorgeladen oder das Board geht zwischen dem Ansteckversuchen erst garnicht in den Reset. Kannst Du mal das Board extern/nicht aus dem USB mit Strom versorgen, damit die CPU beim Einstecken bereits läuft? Gruß, Stefan
Stefan K. schrieb: > Kannst Du mal das Board extern/nicht aus dem USB mit Strom versorgen, > damit die CPU beim Einstecken bereits läuft? Hab ich gerade mit der "nicht CubeMX" FW probiert. Board läuft über externe Spannung und ich verbinde das USB Kabel... dann klappt es nicht. Nur wenn ich das USB Kabel schon eingesteckt habe und dann die Spannung anschalte. Aber auch nicht immer.
Das Problem beim WinCE ist, dass nie klar ist wie viel USB-Unterstützung drin ist. Das kann der Hersteller des Gerätes bei der Konfiguration des Systems entscheiden. Leider gibt es sehr viele Abstufungen, bei denen auch partielle Unterstützung der HID-Klasse dabei sein kann. Möglicherweise verträgt diese WinCE-Version nur Tastaturen mit Boot-Report-Format, oder mag es nicht, wenn mehr Usage-Codes definiert sind, als ihr aus irgend einem Grund gefallen. Kurz gesagt: WinCE hat keinen zuverlässigen Support für USB.
Bitte 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.