Hallo zusammen, vor kurzem habe ich mich mal auch entschlossen meinen Horizont zu erweitern, und einen PIC 18F2455 als USB-Gamepad zu verwenden, indem ich mal das fertige usb_descriptor Programm von Microchip nehme. Also, C18 runter geladen, include-Dateien hinzugefügt, usw ... Wenn ich jetzt allerdings das Programm compilen will, bekomme ich immer eine Fehlermeldung, "Error: syntax error" bezogen auf usb_ch9.h und die Zeile "typedef struct _attribute_ ((packed)) _USB_DEVICE_DESCRIPTOR" Auch bei anderen verwendeten Programmen, z.B. von Sprut ist dies der Fall ... Im Microchip Forum wurde auch bereits darüber diskutiert, aber so richtig schlau wurde ich auch nicht daraus. Weiß jemand vielleicht weiter? Hab ich was übersehen? (Verwendetes Programm in Anhang)
Nun, die Headerdatei scheint für einen anderen Compiler als den von Dir verwendeten geschrieben zu sein.
1 | __attribute__ (packed) |
ist eine compilerabhängige Anweisung, Strukturelemente ohne Alignment unmittelbar nacheinander im Speicher anzuordnen. Das ist für manche 16-, 32- und 64-Bit-Architekturen kritisch. So wie es aussieht*, scheint das gewünschte Verhalten beim C18 eh' der Standard zu sein. Entferne also diese Anweisung, und Dein Problem sollte weggehen.
1 | // aus
|
2 | typedef struct __attribute__ ((packed)) _USB_DEVICE_DESCRIPTOR ... |
3 | |
4 | // wird
|
5 | typedef struct _USB_DEVICE_DESCRIPTOR ... |
*) http://www.microchip.com/forums/m901478.aspx
@rufus Vielen Dank für die schnelle Antwort =) zumindest der Fehler ist nun behoben. Aber nun taucht natürlich wieder ein neuer auf. In diesem Fall betrifft es usb_hal_pic18.h "ROM BYTE* bROM; //Size depends on compiler settings" ?!? Ich habe sämtliche Files mit einem Projekt von Sprut runter geladen. Anfangs dachte ich mir es reicht einfach die fertige HEX Datei auf den PIC zu brennen. Aber das wäre ja viel zu einfach gewesen wenn es gleich funktionieren würde :P http://www.sprut.de/electronic/pic/projekte/usbgame/usbgame.htm
Du solltest herausfinden, für was für einen Compiler der Code geschrieben ist. Dann kannst Du Dir dessen Dokumentation besorgen und nachsehen, was all die Dinge bedeuten sollen.
Philip schrieb: > indem ich mal das fertige usb_descriptor Programm von Microchip nehme. Das ist doch alles wirklich UR-alt. Ich würde dir raten die neuesten Microchip Libraries for Applications zu installieren und zu versuchen mit dem folgende Demoprogramm zu starten: ...\v2017_03_06\apps\usb\device\hid_joystick\firmware\picdem_fs_usb.x Dazu musst du natürlich auch die aktuelle Entwicklungssoftware aus MPLABX IDE und XC8 Compiler installieren. <edit> Seltsam, ich habe das Projekt von Sprut zum Test mal bei mir kompiliert. Der einzige Fehler der auftrat, war dass das Config-Bit FCMEN heisst und nicht FCMEM (MPLAB 8.92, C18 3.40/3.47)
:
Bearbeitet durch User
Selbst der Import in MPLABX 4.15 funktioniert absolut problemlos. (MPLABX Projekt gepackt im Anhang) Philip schrieb: > Also, C18 runter geladen... War das wirklich der C18 und nicht der XC8?
:
Bearbeitet durch User
Hallo Volker SK, ich habe jetzt den ganzen Firmware Ordner direkt auf C gepackt. Beim Compilen trat jetzt ebenfalls das Problem auf, dass FCMEM statt FCMEN drin stand ... ansonsten ging es endlich. Sobald ich nun den PIC an den USB-Anschluss stecke, sagt mir mein Computer aber, dass er das Gerät nicht erkennt. Gehe ich mit dem Oszi auf D+ oder D-, stelle ich fest, dass kurz für ca. 3 Sekunden nach dem einstecken, kommuniziert wird. Dann schaltet der PIC oder der PC ab. Liegt es vielleicht daran, dass die Software mit einem externen Brenner auf den PIC gebrannt wird, und nicht per Bootloader?!? Soweit ich verstehe sollte doch beides möglich sein. Ja, war natürlich XC8 ;)
Philip schrieb: > Sobald ich nun den PIC an den USB-Anschluss stecke, sagt mir mein > Computer aber, dass er das Gerät nicht erkennt. FehlerCode 43? Mal überprüft ob man nicht zufällig D+ und D- vertauscht hat? Ansonsten: Taktfrequenz und andere Grundlagen prüfen.
Ich hab die Anschlüsse natürlich mehrmals überprüft, stimmt soweit. Was mich allerdings wundert. Auf D+ ist der Pegel dauerhaft "high" und geht zur Signalübertragung auf Low, bei D- ist es umgekehrt ?!? Ich dachte es liegt normal an D- über den internen Widerstand am PIC dauerhaft "high". Sobald ich den PIC über eine externe Spannungsquelle laufen lasse (kein USB angeschlossen) liegt D+ auch sofort dauerhaft auf "high"??? Oder hab ich da was falsch verstanden bezüglich meiner USB Kenntnisse? Taktfrequenz ist da, externe Bauteile sollten auch alle stimmen.
Versuchs mal mit nem Linux PC. Das zeigt zu USB einigermaßen hilfreiche Fehler Meldungen im syslog an.
Hab leider keinen Rechner mit Linux ... Was jetzt noch Kurioses hinzu kommt. Stelle ich im oben genannten Joystick-Projekt von spurt den USB-Speed in usb_config.h von "FULL" auf "LOW" verhalten sich D+ und D- wiederum umgekehrt, so wie ich es erwartet habe. Heißt, USB D- ist auf "high" und geht für die ca. 3 Sekunden andauernde Signalübertragung auf "low". Nach der Signalübertragung sagt mein Computer wieder "Gerät konnte nicht erkannt werden" und D- bleibt dauerhaft auf "high"?!? Vergleiche ich das Signal allerdings mit meinem gekauften Joystick (aufgeschraubt und an der Platine gemessen), kommt mir die kurze Signalübertragung des PICs sehr sehr schnell vor. Ich weiß nicht was das Projekt gegen mich hat, ich weiß nur dass es nicht läuft :P
Philip schrieb: > Hab leider keinen Rechner mit Linux ... Starte ein Live System von DVD oder USB Stick, das geht ja fix. Jedenfalls deutlich hilfreicher als die Windows Meldungen "nicht erkannt"... Oszilloskop ist bei USB halt so mäßig hilfreich Sicher dass der PIC Low Speed "richtig" kann? Andere Controller die Full Speed haben können gar kein LS, weil es nix bringt da jeder Host mindestens FS kann
Habe jetzt gerade ein USB Analyzer Programm runter geladen. Leider sagt es mir auch nicht viel mehr als der Windows Geräte Manager "Dieses Gerät wurde angehalten, weil es Fehler gemeldet hat. (Code 43)" Stimmt schon, ein Oszilloskop ist nur mäßig hilfreich, trotzdem sieht es so aus, egal ob ich im usb_config.h LOW oder FULL auswähle, die Übertragungsrate bleibt gleich. Lediglich D+ und D- ändern sich wie in der Beschreibung der letzen Kommentare??? Ich weiß echt nicht was das Programm gegen mich hat :P Langsam regt mich diese Universal Shi* Bus Geschichte echt auf. Und ja, der PIC 18F2455 ist natürlich Low-Speed-fähig ;)
Philip schrieb: > Habe jetzt gerade ein USB Analyzer Programm runter geladen. > Leider sagt es mir auch nicht viel mehr als der Windows Geräte Manager Es wird kein einziges Datenpaket angezeigt? Kein GET_DESCRIPTOR? Philip schrieb: > Lediglich D+ und D- ändern sich wie in > der Beschreibung der letzen Kommentare??? Sicher dass das nicht einfach nur die Umschaltung der Pull-Ups ist? Philip schrieb: > Ich weiß echt nicht was das Programm gegen mich hat :P > Langsam regt mich diese Universal Shi* Bus Geschichte echt auf. Jetzt schon?! USB ist halt sehr komplex. Das kriegt man nicht einfach mit ein bisschen Try-And-Error ans Laufen. Lies die Spezifikation, nutze einen Debugger um zu gucken was für Pakete am PIC ankommen, nutze Linux und/oder Wireshark um die Kommunikation genauer zu betrachten, stelle sicher dass die Hardware korrekt ist, stelle sicher dass das Timing eingehalten wird und da nicht irgendwelche Warteschleifen drin sind - bei der Enumeration gibts Timeouts im Millisekunden-Bereich. Schau mal ob's ein vorkompiliertes Flash-Image gibt, um zwischen Soft- und Hardwarefehlern zu unterscheiden. Das "__attribute__ ((packed))" ist eine unportable Compiler-Erweiterung - wenn der XC8 sich da nicht genau so verhält wie gewünscht kann das auch schief gehen. Prüfe im Binär-Image ob die Deskriptoren korrekt sind und nicht irgendwelche Padding-Bytes haben. Ggf. leg die Deskriptoren als Array an.
Philip schrieb: > Taktfrequenz ist da Ist die PLL und USBDIV bzw. FOSC3:FOSC0 und CPUDIV denn auch richtig eingestellt, bekommt die USB-Peripherie den richtigen Takt?
Angehängte Dateien:
-
USBAnalyse.png
170 KB
Ohh, ich habe vergessen beim Analyser ein Hacken zu setzen :P Die Analyse hab ich als Screenshot im Anhang, ich selbst kann damit leider nicht viel anfangen. Dr. Sommer schrieb: > Sicher dass das nicht einfach nur die Umschaltung der Pull-Ups ist? Sicher bin ich mir nicht, für mein USB-Verständnis stellt sich das Signal aber sozusagen invertiert da. Ich will mich ja zur Zeit eigentlich gar nicht mit komplexen USB-Aufbauten und Protokollen befassen (auch wenn man scheinbar nicht drum herum kommt), ich will nur dass ein scheinbar simples USB-Joystick-sprut Projekt funktioniert. Dr. Sommer schrieb: > Das "__attribute__ ((packed))" ist eine unportable Compiler-Erweiterung Ich lösche mal alle "__attribute__ ((packed))" und schaue was dann passiert ;)
Philip schrieb: > Ich lösche mal alle "__attribute__ ((packed))" und schaue was dann > passiert ;) Ich vermute mal dann klappts gar nicht; der Code braucht das vermutlich, und wenn der Compiler das (so) nicht kann sind die Datenstrukturen falsch. Kenne mich mit PIC-Compilern aber auch nicht wirklich aus. Pures C garantiert jedenfalls nicht dass das so tut. Philip schrieb: > Die Analyse hab ich als Screenshot im Anhang, ich selbst kann damit > leider nicht viel anfangen. Ich kenn mich auch mehr mit den Ergebnissen von Wireshark aus. Sicher dass das die fraglichen Daten sind, und nicht welche von anderen USB-Geräten (Maus, Tastatur,...)? Welche von den Requests gehören zum fraglichen Hub, zum fraglichen Port? Mach mal Screenshots mit Wireshark unter Linux, da könnte zumindest ich dir eher helfen. Und wo du grad dabei bist auch die "dmesg"-Ausgabe. Philip schrieb: > ich will nur dass ein scheinbar simples > USB-Joystick-sprut Projekt funktioniert. USB ist halt nicht so simpel, auch wenn die Flut an billigen USB-Geräten anderes vermuten lässt. Fange vielleicht mit einem Beispiel für exakt diese Hardware und exakt diesen Compiler an.
Dr. Sommer schrieb: > ch vermute mal dann klappts gar nicht; der Code braucht das vermutlich, > und wenn der Compiler das (so) nicht kann sind die Datenstrukturen > falsch. Das ist eine 8-Bit-Maschine, die keine Alignment-Probleme kennt und deswegen Strukturen eh' gepackt anlegt. Das lässt sich auch mit drei Minuten Aufwand überprüfen: Eine entsprechende Struktur instanziieren und mit dem Debugger die Adressen der einzelnen Elemente anzeigen.
Rufus Τ. F. schrieb: > Das ist eine 8-Bit-Maschine, die keine Alignment-Probleme kennt und > deswegen Strukturen eh' gepackt anlegt. Und warum ist dann im Beispielcode das "packed" dran? Übrigens ist der Name _USB_DEVICE_DESCRIPTOR verboten, unterstrich + Großbuchstabe sowie zwei Unterstriche sind der Standard Bibliothek vorenthalten ... aber das hat natürlich nix mit dem Problem zu tun
Dr. Sommer schrieb: > Und warum ist dann im Beispielcode das "packed" dran? Weil die Beispiele für alle PICs waren. (8..32 Bit)
Dr. Sommer schrieb: > Ich kenn mich auch mehr mit den Ergebnissen von Wireshark aus. Ich hab jetzt Wireshark runter geladen und es damit probiert. Leider zeigt er hier, wenn ich "Capture form newly connected device" anhake und dann meine Schaltung anschließe nichts an (0 Pakete). Der Computer reagiert aber wie üblich. Das Programm (Wireshark) selbst funktioniert auch, wenn ich was anderes anschließe beginnt er sofort mit dem Protokoll ?!? Eigentlich widersprüchlich, aber so ist es nun mal leider :P
Angehängte Dateien:
-
Usb_Controller_Auswahl.png
24 KB -
Geraet_Erkannt.png
200 KB
Philip schrieb: > Leider > zeigt er hier, wenn ich "Capture form newly connected device" anhake und > dann meine Schaltung anschließe nichts an (0 Pakete). Wähle mal den ganzen USB Controller (dazu alle anderen USB Geräte trennen) - siehe Screenshot. Durch Try&Error den richtigen Controller finden, ggf. mithilfe eines anderen USB-Geräts was die gleiche Geschwindigkeit hat (LS/FS/HS/SS) - denn pro Port sind typischerweise mehrere Controller aktiv, einer pro USB-Version. Das "Newly connected device" verlangt wahrscheinlich dass das Gerät erst komplett korrekt erkannt wird, was ja schon nicht klappt. Bei mir sieht das dann so aus wie im Anhang - das ganze "USBHUB" Gedöns weist darauf hin dass der Controller irgendwas am Port sieht, das GET_DESCRIPTOR ist das erste Datenpaket an das Gerät. Kann sein dass Windows das anders macht.
Philip, hast du einen Debugger? (PICkit...) Dann könntest du das ganze mal im Debug Modus starten, und schauen was "USBDeviceState" für einen Wert hat.
Rufus Τ. F. schrieb: > Das ist eine 8-Bit-Maschine, die keine Alignment-Probleme kennt und > deswegen Strukturen eh' gepackt anlegt. Aber, aber... Also, das ist eine 8 Bit Maschine, die völlig getrennte Räume für RAM und FLASH hat. Das Lesen aus dem Flash geht völlig anders als mal eben nen Pointer wohin zeigen lassen und ihn dann benutzen. Und der Flash ist m.W. 14 oder 16 Bit breit, weswegen es eben eine ziemliche Besonderheit ist, dort die Deskriptoren anzulegen. Letzteres ist an sich ja völlig OK, denn die Deskriptoren sollten ja eigentlich nicht im RAM herumtingeln. Aber weiter oben hat der TO ja schon über dieses Problem berichtet: Philip schrieb: > "ROM BYTE* bROM; Das läßt mich vermuten, daß die Deskriptoren entweder garnicht vorhanden sind oder daß auf sie nicht richtig zugegriffen wird oder daß sie "packed" sind, ohne daß das wirklich möglich ist, wegen irgendwelcher Spezialitäten beim ROM-Zugriff, der m.W. so ähnlich zu erfolgen hat wie der auf ein einegbautes EEPROM. Das mit den 3 Sekunden ist schon OK so. Der Host versucht innerhalb dieser Zeit, die diversen Deskriptoren hereinzukriegen, aber was ihm da geliefert wird, ist wohl Müll. Deswegen dann nach dem dritten erfolglosen Versuch der Handtuch-Wurf seitens des Hosts. W.S. W.S.
Warum hartnäckig der falsche Compiler verwendet werden muss, ist mir übrigens auch ein Rätsel.
Der Aufbau sieht bei mir ein bisschen anders aus, er zeigt zwar "unknown device" in der Übersicht an, wenn ich das auswähle kommt aber nichts. Habe alle USB-Geräte außer Tastatur und Maus ausgesteckt, da hier ein Protokoll ja nur bei der Eingabe geschickt wird, kann ich leicht erkennen was was ist. Bei meiner PIC-Schaltung tut sich in Wireshark dennoch nichts, keine neunen Pakete. Ich vermute mal, dass Wireshark allgemein nur Protokolle anzeigt, die keine Fehler enthalten, bzw. von Geräten die sich korrekt mit dem host verbinden :P
Philip schrieb: > Ich vermute mal, dass Wireshark allgemein nur Protokolle anzeigt, die > keine Fehler enthalten, bzw. von Geräten die sich korrekt mit dem host > verbinden :P Nö. Wireshark zeigt auch kaputte Pakete bei der Enumeration an. Sogar wenn man nur den 1.5kOhm-Widerstand von D+ nach 3.3V verbindet und überhaupt keinen Controller dran hat müsste schon was passieren. Du machst also irgendwas komplett falsch.
Angehängte Dateien:
-
Wireshark.png
220 KB
Das wird bei mir angezeigt, wenn ich ein Gerät anschließe wo der 1.5kOhm-Widerstand diskret verbaut ist und ich den Reset-Button für den Controller gedrückt halte. Der PC erkennt dass ein FS-Gerät dran ist, aber es antwortet kein bisschen. Wireshark zeigt die Kommunikation mit dem Hub an, und in der Linux-Kernel-Ausgabe sieht man auch woran sich das OS stört - das Gerät antwortet nicht auf GET_DESCRIPTOR. So weit müsstest du auch kommen.
Angehängte Dateien:
-
Wireshark.png
88 KB
Rufus Τ. F. schrieb: > Warum hartnäckig der falsche Compiler verwendet werden muss, ist mir > übrigens auch ein Rätsel. Selbst wenn ich gar keinen Compiler verwende, also die fertige HEX-Datei nehme, funktioniert ja leider auch nichts Ich weiß nicht was ich komplett falsch mache. Bei mir sieht es so aus wie im angehängten Screenshot. Es wird das "Unknown device" in der Übersicht angezeigt. Das wars.
Mach den Haken bei "Capture from newly connected devices" weg, klicke Start, und schließe dann erst (!!!) das Gerät an.
Also zusammenfassend: - Windows erkennt dass ein Gerät da ist, kommuniziert mit dem Gerät, und zeigt dann was von unbekanntem Gerät an - Wireshark erkennt Kommunikation mit anderen USB-Geräten - Nur von deinem Gerät zeigt Wireshark absolut nichts an, sowohl bei USBPcap1 und USBPcap2 Versuchs doch einfach mal mit nem Linux-Live-System, da ist das alles einfacher.
Korrekt zusammengefasst ;) Außer das Wireshark in der Übersicht eben das "Unkown device" anzeigt, wie im Screenshot zu sehen, sonst nichts. Ja, ich erbarme mich mal und lade Knoppix herunter. Auch wenn es wieder Zeit kosten wird eine leere DVD oder einen geeigneten Stick zu finden :P Für mich steht leider der Aufwand in keinem Verhältnis zum bisherigen "Ertrag". Ich bewundere eh woher du so viel Geduld für mein USB-Problem her hast, Dr. Sommer :D
Philip schrieb: > Für mich steht leider der Aufwand in keinem Verhältnis zum bisherigen > "Ertrag". Also wenn dir DAS schon zu viel Arbeit ist... Wie gesagt lohnt sich die Verwendung von Linux für USB allgemein sehr. Wenn du davon ausgehst dass eine USB-Implementierung so einfach ist dass das Starten eines Linux-Systems einen signifikanten Arbeitsanteil bedeutet, bist du auf dem Holzweg... Philip schrieb: > Ich bewundere eh woher du so viel Geduld für mein USB-Problem her hast, > Dr. Sommer :D Purer Masochismus.
Dr. Sommer schrieb: > Also wenn dir DAS schon zu viel Arbeit ist... Ich will ja erstmal nur dass ein fertiges spurt Projekt läuft. Dachte das ginge einfach Copy ---> Paste. Hab ja erstmal nicht vor selbst irgendwas komplexes per USB anzusteuern. ... mit dem zweiten Anlauf hab ich jetzt Knoppix erfolgreich auf DVD gebrannt und davon gestartet. Mit dem Befehl "lsusb" mal alle angeschlossenen Geräte anzeigen lassen. Und ... welch Überraschung, meine PIC-Schaltung ist nicht dabei. Dr. Sommer schrieb: > Purer Masochismus Deswegen Dr. Sommer ? ;)
Philip schrieb: > Mit dem Befehl "lsusb" mal alle angeschlossenen Geräte anzeigen lassen. > Und ... welch Überraschung, meine PIC-Schaltung ist nicht dabei. > Logisch. Gib "dmesg -w" ein und steck das Gerät an und schau was passiert. Dann installiere Wireshark und gucks dir da an
Bei dem Befehl dmesg -w kommen die Fehlermeldungen (siehe Screenshot). Usb 2-6 entspricht hier logischerweise meiner Schaltung. Wireshark zeigt mir an dass es keine Schnittstellen gefunden hat, wobei es da auch Probleme bei der Installation gab.
Endlich mal eine Erkenntnis. Das Gerät antwortet also auch nicht auf GET_DESCRIPTOR, d.h. es funktioniert gar nix. Der Widerstand wird aber erkannt. Philip schrieb: > Wireshark zeigt mir an dass es keine Schnittstellen gefunden hat, wobei > es da auch Probleme bei der Installation gab. Hast du die Befehle eingegeben (danach Wireshark neu starten):
1 | modprobe usbmon |
2 | sudo setfacl -m u:$USER:r /dev/usbmon |
Funktioniert leider auch nicht, weder die Befehle, noch Wireshark als root auszuführen :P
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.