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