Hallo Froum, Nachdem ich mein neues Spielzeug, einen AVR USBKey (siehe http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3879) nun seit einigen Tagen in der Mache habe, bin ich etwas frustriert… Ich habe ein Problem mit den HID Demos des USBKey und bin etwas ratlos, wie ich weiter machen soll. Etwas konkreter: Ich habe von Atmel at90usb128-demo-hidgen-std herunter geladen und die SW läuft nicht… Noch konkreter: Ich habe hid_gen.a90 mit Hilfe von Flip auf den USBKey geladen und UsbHidDemoCode.exe gestartet. Es gab zwar eine Verbindung zum USBKey, aber weder wurden beim Bewegen des Joysticks Daten empfangen noch konnte ich die LEDs ein bzw. ausschalten. Als nächstes habe ich ein S65-Display an den USBKey angeschlossen (siehe http://www.superkranz.de/christian/S65_Display/DisplayIndex.html) und etwas Debug Code zu den at90usb128-demo-hidgen-std Sourcen hinzugefügt. Das Display arbeitet wunderbar und so bin ich letztlich drauf gekommen, dass die LEDs des USBKey nicht angehen, weil die Zeile if(Is_usb_receive_out()) in der Function void hid_task(void) nie true liefert. Der nächste Schritt war, UsbHidDemoCode.exe mit VC++ zu debuggen. Das Ergebnis: Immer, wenn ich versuche, die LEDs mit der Applikation zu schalten, erzeugt AtUsbHID.dll folgende Trace-Ausgabe: Write failed but no IO pending, Error code is 1784 Als nächstes habe ich versucht, mit USBSpy (http://www.everstrike.com/usb-monitor/) der Sache auf den Grund zu gehen. Das Ergebnis: Der USBKey sendet beim Bewegen des Joystick korrekte Daten, sie kommen nur irgendwie nicht im aufrufenden Programm an. Ich habe versuchsweise mal die 8 Bytes, die den Joystick-Status zurück liefern, durch einen konstanten String ersetzt und konnte diesen String in USBSpy als Transfer-Paket empfangen. Das letzte, was ich probiert habe, ist die Atmel AtUsbHID.dll durch SW zu ersetzen, die mir als Source vorlag (siehe http://www.lvr.com/hidpage.htm (http://www.lvr.com/files/HidTest.zip). Das Ergebnis: wenn ich mittels WrieFile versuche, an den USBKey daten zu schicken, quittiert mir Windows das mit Error 1784 (0x06F8, “The supplied user buffer is not valid for the requested operation.”) BTW: Der USBKey funktioniert wunderbar, wenn ich das Firmware-Original (FIRMWARE.HEX) flashe, bis auf eine Ausnahme: atmel_hid.exe (die blaue Hid-Demo) hängt. Ich kann aber irgendwie nicht glauben, dass die Hardwae defekt ist. Der „Memory-Stick-Modus“ und der „Maus-Modus“ der Original-Firmware funktionieren ganz wunderbar!!?? Da ich kein USB-Spezialist bin (das ist der Grund, warum ich die Atmel HID-Implementierung verwenden möchte) bin ich jetzt mit meiner Weisheit ziemlich am Ende. Hat jemand von Euch ähnliche Erfahrung und kann mir irgendeinen Tipp geben, was faul ist? Ein reichlich ratloser Josef
Push! (Bei der Menge an posts in diesem Forum ist der BEitrag ja vergessen, noch bevor ihn einer gelesen hat...)
Das Demo at90usb128-demo-hidgen-std sieht mir mit der heissen Nadel gestrickt aus und eher danach, als ob es aktuell für die STK525 Hardware übersetzt ist und nicht für die USBKEY Hardware. In der config.h Datei ist folgender Abschnitt
1 | // ...
|
2 | #include "conf/conf_scheduler.h" //!< Scheduler tasks declaration |
3 | |
4 | #define STK525 0
|
5 | #define USBKEY 1
|
6 | |
7 | //! Enable or not the ADC usage
|
8 | #undef USE_ADC
|
9 | //! To include proper target hardware definitions, select
|
10 | //! target board (USBKEY or STK525)
|
11 | #define TARGET_BOARD STK525
|
12 | // ...
|
Die Definitionen sind IMHO etwas konfus. #define STK525 0 #define USBKEY 1 Erscheint mir OK, um den Code für USBKEY zu produzieren. Aber dagegen spricht #define TARGET_BOARD STK525 Ich würde an dieser Stelle nachhaken und die Sache mir #define TARGET_BOARD USBKEY übersetzen. Auch das aktuelle GCC Makefile enthält die Rules, um die hid_gen.a90 Firmware für das STK525 Hardware zu machen. Ich vermute, du hast die falsche Firmware hid_gen.a90 in dem USBKEY drin. Das passt zu deiner Beobachtung, dass eine anderere Firmware mit dem USBKEY funktioniert. Blüd, dass in dem Demoarchiv keine fertige Firmware für beide Targetboards drin ist. Wie gesagt, IMHO heiss gestrickt.
Hi, ich hab ein recht ähnliches Problem in anderem Kontext: meine Hardware ist ein AT91SAM7S256 auf dem die USB Schnittstelle per firmware unter Zuhilfenahme des AT91 USB Framework als USB HID Device programmiert ist. Auf dem selben Weg hab ich den Chip schon erfolgreich als MSD am laufen. Auf der PC Seite habe ich als Ausgangspunkt ein C# Projekt verwendet (siehe http://www.codeproject.com/useritems/USB_HID.asp). Das daraus entstandenen Programm findet nun das HID Gerät problemlos und kann von diesem auch die caps (input report length, output report length, ...) korrekt erfragen. Wenn ich dann allerdings versuche, auf das Gerät zu schreiben (FileStream.Write) wird das ebenfalls mit einer Exception quittiert, der zu folge ein Parameter falsch ist. Soweit ähnelt die Situation bei mir also schon dem oben beschriebenen Problem. Die Lösung scheint mir eher auf dem PC zu liegen als in der Firmware, weil die Fehlermeldung ja in beiden Fällen die übergebenen Puffer betrifft. Eine Lösung hab ich noch nicht, aber ich experimentier grade mit der Puffer Länge. Bei einem Generic Data Transfer über HID muss - soweit ich weiß - die Pufferlänge exakt mir der Länge des out reports übereinstimmen ... Ich melde mich, wenn ich weiter komme und würd mich über jeden neuen Ansatz freuen... Sven
Sorry Stefan, was auch immer ich falsch gemacht hab ... klär mich einfach auf, bin lernwillig :-) Ich hab in der Zwischenzeit noch was interessantes gefunden: http://www.lvr.com/hidpage.htm Insbesondere die beiden Programm HidTest und SimpleHidWrite helfen weiter, die Kommunikation zwischen PC und Gerät in kleinen Schritten zu testen. In meinem Fall legen die nahe, dass doch was mit der Firmware nicht stimmt ... die Anzahl Strings kommt mir spanisch vor und bei GetPhysicalDescriptor kracht es auch. Wobei ich dachte, das ein HID die gar nocht unbedingt zurückgeben muss ... Stefan - was meinst Du mit kapern?
Du beziehst dich auf das Posting von mir, das ich (fast) direkt nach meiner Eingabe gelöscht habe. Leider war ich nicht schnell genug ;-) Der Thread war gegenüber meinen letzten Besuch nämlich markiert, dass es eine neue Nachricht gibt. Also habe ich in den Thread reingeschaut, weil ich eine Antwort von Josef vermutete. Dann sah ich nur dein Posting mit einem komplett anderen µC (ARM7 Architektur statt AVR) und habe es als ein Kapern/Übernehmen/Entführen der Diskussion zu Gunsten deiner Problemstellung empfunden. Beim zweiten Lesen war ich mir unschlüssig, ob ich 100% richtig liege und dann... im Zweifel für den "Angeklagten", d.h. laissez faire.
Threads kapern halt ich für eine sehr kuriose idee ... lassen wir sowas. Also Josef: was mich angeht, so ist das Problem gelöst: Das erste Byte, das zum Gerät gesendet wird, muss die Report ID sein, in meinem Fall 0x00 weil ich nur einen InputReport habe. Windows merkt sich wohl beim Aufruf von HidD_GetPreparsedData oder HidP_GetCaps die vom Gerät definierten Reports und parsed die via WriteFile gesendeten Daten. Wenn dort dann eine ungültige ReportID angegeben ist, kommt es zur Fehlermeldung "Falscher Parameter" (ich benutze C#). Grüße, Sven
Josef, Excuse I answer in English, but I cannot write in German - though I can read and understand most of it. I had the same problem and got the same fail code in VC++. I then changed the PID in the device and it went away. I think Windows may clutter the PIDs if it is once registered to a specific product. Hope this helps
Hi Leute, also ich hätte da eine Frage: Ich hab ein Device mit einem 3rd Prty driver entwicklet, das ich jetzt auf HID class driver umstellen will. Es wird nur vom Device gelesen . Keine Daten gehen an das Device. Ich habe mich schon ein bisserl eingelesen, doch meine Frage. Muss der Report ein bestimmtes Format sein, oder kann der wie bei einem Pipe meine 64 Byte Daten beinhalten? Woher bekomme ich die von AMTEL beschriebene DLL und wie binde ich sie in Delphi 7 ein? Besten DANK im vorraus. (Ich bin noch ein kompletter USB-Novice) Walter
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.