Hallo Leute Ich bin von meiner Firma ermächtigt mir Support einzukaufen, bloß kenn ich keine Stelle, an die ich mich wenden kann. Deswegen an euch die Frage. Bitte gegebenenfalls per E-Mail Kontakt aufnehmen und Kosten abschätzen. Grobe Übersicht: Ich bau ein einfaches Messgerät, das mit einem Atmel 89C5131 (8051 Derivat) den Wert über USB an einen Windows Mobile 2003 (so was wie ein Palm) Rechner übergeben soll. Damit nicht auch noch eine Treiberprogrammierung nötig wurde, zielt das Projekt auf den bei Windows integrierten HID Treiber. µC wurde in Assembler programmiert. (ich weiß, ich weiß .... C .....) Auf der Seite des Palm soll C# verwendet werden, aber momentan verwende ich noch Visual Basic unter Windows XP, weil ich da mehr Praxis hab. Die gesamte Elektronik funktioniert, die Firmware geht, das Gerät wird als HID-Device enumeriert, bloß die Datenübertragung geht noch nicht, oder zumindest nicht so, wie sie soll. Unter Win2000 bekomm ich nur ein Handle (CreateFile) auf die HID, wenn ich weder Lesend noch Schreibend darauf zugreifen will. Unter Windows 98 bekomm ich lesenden Zugriff. Wenn der Computer und die Elektronik neu gestartet wurde, dann bekomm ich sogar auch mal einen Wert auf den Host, bevor Schluß ist. (Firmware Bug.... aber wo? Ist zum Verzweifeln...) Bei dem Projekt orientierte ich mich für die USB Kommunikation sehr stark an den veröffentlichten Beispiel von Atmel für eine USB Tastatur. Wenn ich das Teil als USB Tastatur programmiere, dann funktioniert es auch, bloß will ich aus Performance Gründen die Daten binär direkt in meine Anwendung übertragen. Aprobos Daten: 2 Byte In (in den Host), 1 Byte Out (Geht auch als Set_Feature oder ähnliches, weil unkritisch) Bisher hatte weder ich noch sonst jemand in unserer Firma die Freude, ein USB Projekt auf so niedriger Stufe umsetzen zu dürfen und ich bin jetzt nach ein paar Wochen an einen Point of no Return angekommen. Weiter gekommen bin ich allerdings auch nicht. In etlichen anderen Foren waren bei den Leuten ähnliche Probleme aufgetreten, aber an keiner Stelle wurde eine Lösung aufgezeigt. Einen Open Source Software-Protokoll-Analyser hab ich auch bemüht, ohne allerdings viel mit den Daten anfangen zu können. Brauch ich allerdings auch nicht, um zu erkennen, dass es zwangsläufig an der Firmware liegen muss... Wer hat Erfahrung mit USB, HID? Wer kann mir Unterstützung anbieten? Wer hat Tools, mit denen man vernünftig testen/debuggen kann? Wer kennt einen, der jemanden kennt, der ....... Alles an: E-Mail: root(at)andreas-knorr.de (Das @ Zeichen müsst ihr per Hand einsetzen) Danke
Mal ausgehend vom 2000er: Wenn CreateFile fehlschlägt, mit welchem Fehler? Wie sehen die Deskriptoren aus? Hast Du Dir das Ganze mal mit UVCView angesehen? http://www.microsoft.com/whdc/device/stream/vidcap/UVCView.mspx
Hallo, mit der Software kann man relativ gut sehen wo es bei der kommunikation hängt und was für Daten ausgetauscht werden. Um sicher zu gehen ob die firmware wiklich OK ist gibt es bei usb.org einen Compiance Check Programm. http://www.usb.org/developers/tools/ MfG Sebastian
CreateFile schlägt mit dem Rückgabewert 1 fehl, es sei denn, ich rufe es so auf: HidDevice = CreateFile(Text1.Text, 0, FILE_SHARE_READ, 0, OPEN_EXISTING, 0, 0) ...Man beachte die erste Null, die weder Schreiben noch Lesen wünscht.. Mit UVCView hab ich mir die Geschichte erst jetzt angesehen, da ich davor nur USBView kannte. Aber beide bringen mir doch nichts, denn die Enumeration läuft immer korrekt durch und ich sehe nur die Daten, die ich in meinen Deskriptoren eingegeben hab. Usbsnoop war das Tool, das ich oben gemeint hatte. Mit den Daten kann ich nichts anfangen. Ich hab mal zwei DatenSätze gespeichert und angehängt. Beim ersten Datensatz wird das Teil nur enumeriert, beim zweiten Satz schicke ich zweimal einen Report (Daten). Die Daten, die übertragen werden, müssten 7F FF sein. (das eine 7f sieht man ja... oder? ..... hmmm....) Den Compiance Check kenn ich natürlich auch. Die Tests (Chapter 9 Tests und HID Tests) werden meist bestanden. Allerdings gebe ich zu, das beim Chapter 9 Tests so ca. jedem zweiten Mal irgendwas schief läuft. Manchmal ist es der Idle_Test, manchmal der Enumerate_Test oder wie im Anhang zu sehen der SetConfigurationTest. (öfter mal was neues! Der letzte Fehler trat davor noch nie auf...) Alles im Anhang
> CreateFile schlägt mit dem Rückgabewert 1 fehl Das deutet auf den Fehlschlag hin, sagt aber nichts über das Warum. Nach einem Fehlschlag (und nur dann!) solltest Du die API-Funktion GetLastError aufrufen. Diese gibt Dir mehr Auskunft. BTW: Das Du keinen schreibenden Zugriff auf das Gerät bekommst, kann ich mir sogar vorstellen, da von diesem Gerät sowieso nur gelesen werden kann (es gibt lediglich einen Input-Report). > Aber beide bringen mir doch nichts, denn die Enumeration läuft > immer korrekt durch und ich sehe nur die Daten, die ich in meinen > Deskriptoren eingegeben hab. Das war's, was ich wissen wollte. Die Deskriptoren stimmen also überein. Nach der Enumeration beginnt der Host, im angegebenen Interval das Gerät zu pollen. Was antwortest Du daraufhin? Kann man sich das mit Usbsnoop anschauen (ich habe diese Software nicht installiert (deswegen kann ich mir Deine Logs leider nicht anschauen), ich verwende hier einen Hardware-Analyzer mit zugehöriger Software)? > Allerdings gebe ich zu, das beim Chapter 9 Tests so ca. jedem > zweiten Mal irgendwas schief läuft. Das sollte Dir zu denken geben. Beobachte diesen Vorgang mit einem Analyzer. Oder können das einfach nur Verbindungs-Schwierigkeiten sein (schlechte Leitung)? Wird der Bus zu sehr kapazitiv belastet? Wie sieht's mit falschen oder fehlenden Serien-Widerständen aus? Ist der PullUp-Widerstand an der richtigen Leitung angeschlossen? Andererseits scheinen die Probleme erst nach der Konfiguration aufzutreten. Es könnte also sein, daß es beim Freischalten des hochstomigen Teils passiert (zu hoher Einschalt-Strom, der Dir irgendetwas durcheinander bringt?). Was passiert, wenn Du den hochstormigen Teil nach dem SET_CONFIGURATION Request testweise nicht freischaltest?
was steht in Edit1.text drinen ? Ein Devicezugriff über CreateFile() beginnt mit Doppelslash. Gruß Hagen
Pedantischer Einwurf: Doppel_back_slash, in C/C++-Source also gleich vier davon ...
Naja, Andreas wird doch wohl hoffentlich das SetupAPI bemühen, um an die Namen zu gelangen und mit solchen Details gar nicht direkt in Berührung kommen. Die Namen werden doch bestimmt nicht per Hand eingegeben ... oder etwa doch?
Also Rene (King) das mit dem GetLastError, da hätte ich selbst drauf
kommen können, vor allem, weil es im späteren Verlauf sowieso mal
aufgerufen wird, um eine Buffergröße zu ermitteln. Das wird gleich
morgen mal ausprobieren - sobald ich kann, reiche ich dir das Ergebnis
nach.
Auch ist es mir völlig klar, dass ich keinen schreibenden Zugriff
bekommen kann, wenn ich weder im Report Descriptor Out Daten definiere
noch eine Interrupt Out Pipe habe.
Allerdings hab ich bis vor kurzem beide Möglichkeiten mit vorgesehen
und da hat das mit dem schreibenden Zugriff auch nicht geklappt. Aber
darauf wollte ich mich gar nicht konzentrieren mir reicht erstmal in
annehmbarer Geschwindigkeit lesen.
Ich brauch nur später eine Möglichkeit das Gerät zu aktivieren und
wollte das mit Set_Feature erschlagen. Dazu gibts eine Funktion im
HID.DLL
(allerdings gibts die wiederum nicht auf Windows Mobile-- es
ist zum heulen
.)
Nach der Enumeration beginnt der Host das Gerät zu pollen? Wirklich?
Hab ich echt nichts davon gelesen und auch nichts davon gemerkt. Nach
meinen Wissendstand kann der Client nach der Enumeration beliebig Daten
auf die Interrupt Out Pipe legen. Der Host holt sich das Zeug und
speichert es in einen Ringpuffer. Die Größe kann man zwar mit APIs
ändern, aber ist standardmäßig auf 8 Bytes. Wenn der voll ist, werden
die alten Daten überschrieben. Mit ReadFile kann man diesen Buffer
auslesen.
Ist das schon der Denkfehler?
Also ich konnte keinen Get_Report_Request ausmachen
Wegen den Chapter 9 Tests:
Nachgedacht hab ich selbstverständlich schon darüber, aber machen
konnte ich nicht viel. Mir steht nur das zur Verfügung, was frei
erhältlich ist, deswegen hab ich mich ja an euch gewendet. Es ist auch
so, dass der Fehler nur beim ersten Mal auftritt (beim ersten Test) und
nicht vorherzusehen ist, bei welchen Abschnitt es diesmal fehlschlägt
bzw. ob überhaupt. Wird noch mal getestet, ist alles ok. (kann man
danach beliebig oft testen) Wenn ich die Tests einzeln starte, dann ist
mir nicht in Erinnerung, dass es da jemals fehlschlug. Ich hab da ein
wenig den Hub in Verdacht, weil erstens von der ganz billigen Sorte und
zweitens, weil ich mit dem schon in anderer Hinsicht öfter mal Probleme
hatte. Aber der Hub ist nötig, weil über dessen Treiber ja der Test
ausgeführt wird. Hubmäßig ist schon ein besserer im Zulauf, auch hier
Gedult...
Die Stromaufnahme ist auch nicht der Übeltäter (so meine ich) weil die
Stromaufnahme der Gesamtschaltung so um die 30 mA liegt und weit von
der 100 mA Marke entfernt ist. Da dürften auch keine Spitzen mit drin
sein, die mir die Spannung zusammenbrechen lassen, weil immer alles
läuft, sobald versorgt. (Stromsparen lohnt nicht - ich muss alles sehr
klein halten, deswegen auch gar kein Platz für Schaltmöglichkeiten)
Das mit dem SET_CONFIGURATION Fehler trat halt diesmal auf
. Schieß
dich nicht zu sehr darauf ein, das war das erste Mal, dass er an dieser
Stelle einen Fail gemeldet hat.
>ich verwende hier einen Hardware-Analyzer mit zugehöriger Software
Jaaaa,
*lechtz*
Endlich mal gutes Werkzeug!
Das Teil ist so klein, wenn du mir Support gewährst, dann steck ich es
mal in einen Umschlag und lass es dir zukommen. Mal sehen, was das Teil
dann spricht.
Dann kannst du auch gern eine Rechnung schreiben (aber vorher Angebot,
na!)
Und für den Rufus und den Herrn Hagen:
Die Info reich ich morgen nach. Ich weiß allerdings düster aus dem
Gedächtnis, dass er mit //?/ beginnt.
Das Fragezeichen kennzeichnet ja, dass es ein langer Name ist
Und bei Visual Basic brauch ich auch keine vier Slashs..
DAS dürfte auch nicht der Fehler sein, denn wenn ich einen Handle mit
0-Rechten hole, dann kann ich mit weiteren APIS die Infos zu meinen
Gerät auslesen. Und das klappt ganz gut..
Abgesehen davon, ich hab irgendwo aus dem I-Net Software herbekommen,
die es auch nicht schafft einen Handle zu bekommen und die ist von so
einem USB Guru (Jan Axelson?)
Nein es liegt gewiss an der Firmware.
Und nein, den Namen hab ich nicht per Hand eingegeben
> Nach der Enumeration beginnt der Host das Gerät zu pollen? Wirklich? Ja, wirklich. :-) Du hast über Deinen EP-Descriptor sogar selbst angegeben, daß Du alle 32 ms mindestens einmal gefragt werden möchtest (bInterval). > Hab ich echt nichts davon gelesen und auch nichts davon gemerkt. Wird beim Endpoint-Descriptor beschrieben, Spezifikation 9.6.6, Table 9-13. Die genaue Funktion von Interrupt-Transfers erklärt Chapter 5. > Host holt sich das Zeug und speichert es in einen Ringpuffer. Die > Größe kann man zwar mit APIs ändern, aber ist standardmäßig > auf 8 Bytes. Die Größe des Puffers ist mindestens so groß, als das mindestens zwei komplette Reports hineinpassen (nicht Bytes). Verstellen kannst Du die Anzahl der Reports, die der Puffer aufnehmen kann (2..512, nicht Bytes). Per Default können 32 Reports aufgenommen werden (wieder: nicht Bytes). Siehe: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/Hid_r/hh/HID_r/hidfunc_d091d988-7b9d-44ef-ae48-e00af69c12f5.xml.asp?frame=true > Mit ReadFile kann man diesen Buffer auslesen. Ist das schon der > Denkfehler? Nein, das nicht. Der Denkfehler kommt erst jetzt: > Also ich konnte keinen Get_Report_Request ausmachen Ein solcher Request kommt auch nicht, es wird Dein EP1 gepollt. Wenn Du Daten in den FIFOs hast, werden diese gesendet. Sind keine Daten vorhanden, sollte die Hardware den Interrupt-IN Request schlicht NACKen. Insgesamt hat dieser Ansatz deutlich weniger Buslast zur Folge, genau deswegen wird das auch so gemacht. > Die Stromaufnahme ist auch nicht der Übeltäter (so meine ich) weil > die Stromaufnahme der Gesamtschaltung so um die 30 mA liegt und > weit von der 100 mA Marke entfernt ist. Das war ein Irrtum meinerseits. Dein Kommentar suggeriert eine Einstellung von 400 mA insgesamt, damit hättest Du schalten müssen. Den tatsächlichen Wert habe ich dabei aus dem Auge verloren. Bedenke aber, daß Du den Suspended-Mode unterstützen mußt. Gerade auch weil Dein Gerät über den Bus versorgt wird, ist das besonders wichtig.
Also hier mal ein paar Vorschläge: 1. Verwende mal den Treiber von wwww.thesycon.de (Demo reicht) Prüfe ob alles mit deren App so abläuft wie du erwartest. Verwende getrennte PID/VID dann kannst du problemlos umschalten 2. snoppy ist nicht so der Bringer bushound kann wesentlich mehr 3. Power und solche Dinge sind erst mal nebensächlich wenn da was fehl schlägt, bekommst du eine Fehlermeldung von Win. 4. Die FW von Atmel hist ziemlich daneben. Wenn dein Projekt darauf aufbaut kannst du schon mal einen USB Analzer bestellen. 5. Section 8.4.5 der Spec lesen bIntervall von 0x20 heist Daten alle 32 ms. Thomas
Also der Pfad auf das HID lautet bei mir:
\\?\hid#vid_03eb&pid_2003#6&17718542&0&0000#{4d1e55b2-f16f-11cf-88cb-001
111000030}
Warum der Chaptor 9 Test ab und zu fehlschlägt, hab ich auch
herausgefunden:
Wenn ich das Gerät normal teste, dann sehen die Ergebnisse ungefähr so
aus:
Testdurchlauf1: Enumeration failed at iteration 127
Testdurchlauf 2: Enumeration failed at iteration 122
Testdurchlauf 3: passed
Testdurchlauf 4: Enumeration failed at iteration 101
Testdurchlauf 5: passed
.
Testdurchlauf 8: Config Descriptor failed
.
Testdurchlauf 10: Enumeration failed at iteration 15
Hat auch nichts gebracht, als ich einen anderen Hub verwendete, aber
als ich die Interrupts in meiner Firmware deaktivierte, dann sah es so
aus:
Testdurchlauf 1: passed
Testdurchlauf 2: passed
Testdurchlauf 3: passed
Testdurchlauf 4: passed
Da die Interrupts überhaupt gar nichts mit USB zu tun haben, müssen das
dann wohl Timeouts sein, was da Fehler verursacht. Der µC hat dann
einfach zu viel zu tun, um sich um USB zu kümmern.
Der Rückgabewert für GetLastError nach dem fehlgeschlagenen CreateFile
ist 0.
(Der Vorgang wurde erfolgreich beendet)
Visual Basic Code im Anhang. (Warum?)
Nachdem ich die Interrupts ausgeschaltet hatte, versuchte ich auch noch
mal Snoopy:
Da du (Rene) die Software nicht drauf hast, hab ich einen ScreenShot
gemacht. Die Daten die zweimal übertragen worden sind waren 11h, 22h.
Die sieht man ja im Log ... wie greif ich jetzt darauf zu? CreateFile
klappt immer noch nur in Win98, ReadFile klappt nur ab und zu und wenn,
dann nur beim aller ersten Mal.
Verflixt, was mach ich falsch.....
Das mit dem Pollen:
Na, dann komme ich ja auch nicht mit dem Pollen in Berührung. Ich
dachte, dass du meinst, dass der Host den Client über Requests pollt.
(Auch bInterval mit 20h ist mir klar, ich habs ja geschrieben)
Da kann ich keinen Fehler gemacht haben, denn das ist in Hardware
gegossen und in Windows umgesetzt und nicht in der Firmware drin.
Na gut, mit dem Puffer lag ich ein ganz klein wenig daneben (ganz
wenig), aber das war schon lang her, dass ich darüber mal was gelesen
hab und später hats mich auch nicht mehr interessiert, weil es mich
eben auch nicht zu interessieren hat.
Stromaufnahme:
Ja, ich hab es auch erst jetzt gesehen, dass in meinen Kommentar noch
400 mA stand. Entschuldige, dass ich dich da auf die falsche Fährte
gelockt habe.
Suspended-Mode:
Ja, das kommt vielleicht später. Warum ist das so wichtig? Wenn der
Pocket PC nach ein paar Minuten Inaktivität aus geht, dann schaltet der
eh den Bus ab. Oder gibt es wichtigere Gründe? Ich hab keinen Platz mehr
für weitere Transistoren... Und der Suspend_Test im Chaptor 9 Test
klappt ja.
An den Thomas:
Zu 1:
Mach ich! Ich hatte mal von Jungo die Demo probiert, die einen
kompletten eigenen (generischen) Treiber erstellt und damit hat es
schon vor Monaten geklappt.
Zu 2:
bushound such ich mir auch. Wenn ich ein Stichwort bekomm, dann komm
ich schon klar, aber wenn man nicht weiß, dass es so was gibt, ist man
verloren.
Zu 3:
Richtig, sollte man meinen! Aber ich bekomm keine. (siehe oben)
Zu 4:
Ich hab mich auch schon gewundert, warum zum Beispiel in der
Enumeration bei einem Get_Descriptor Request für den
usb_configuration_descriptor nicht nur dieser sondern auch gleich der
interface_descriptor, der HID descriptor, der endpoint_descriptor und
der report_descriptor mit übertragen wird. So sollte es doch eigentlich
nicht sein, oder?
Aber es geht nicht anders. Komischerweise klappt es nicht, wenn ich die
einzelnen Requests auch nur die einzelnen descriptoren übertragen
lasse.
Außerdem schreibt ein anderer, dass wenn man USB per Interrupts laufen
lässt (anstatt pollen), er Werte im Eingangspuffer verliert wie zum
Beispiel die Werte für bRequest und bRequestType.
Atmel schweigt dazu....
Aber was wäre denn besser gewesen? (Für alle, die so was noch vor sich
haben)
USB Analzer beschaffen geht nicht, oder gibt es einen für wenig Geld?
Zu 5:
Ja ich weiß, siehe oben....
Ah sieh an! Ich bin schon wieder einen kleinen Schritt weiter.
Ich hab das Bus Hound Tool installiert und mir mein Gerät gleich mal
angesehen. Und da ist es mir in die Nase gefahren, dass das Tool mein
Gerät als USB Tastatur erkannt hat (ihr erinnert euch, dass ich das aus
dem Tastaturbeispiel von Atmel entwickelt habe)
Also hab ich die Product ID im device_descriptor geändert und siehe
da:
Ich bekomme einen Handel mit Leserechten unter Win2000/XP.
Ist ja klar, Win2000 verbietet im Gegensatz zu Win98 den direkten
Zugriff auf solche Systemgeräte wie Tastatur, Maus, Joystick, etc.
Aber: Ich kann jetzt immer noch keine Daten lesen. Alle 3 Bufferbytes
sind 0.
VB6 Code:
Private Sub Command6_Click()
Dim Wert As Integer
'Daten lesen
Result = ReadFile(HidDevice, _
ReadBuffer(0), _
CLng(Capabilities.OutputReportByteLength), _
NumberOfByteRead, _
0)
Label7.Caption = CStr(Result)
Label6.Caption = CStr(ReadBuffer(0)) & CStr(ReadBuffer(1)) &
CStr(ReadBuffer(2))
Wert = ReadBuffer(0)
Wert = Wert * 65535
Wert = Wert + ReadBuffer(1)
End Sub
Aber langsam kommt Bewegung in die Geschichte......ENDLICH!
> USB Analzer beschaffen geht nicht, oder gibt es einen für wenig > Geld? Gibt es, z.B. bei Ellisys. Wenn Dir Low-/ Full-Speed reicht, ist der USB Tracker 110 Dein Gerät. Der kostet fast nix. > Result = ReadFile(HidDevice, _ > ReadBuffer(0), _ > CLng(Capabilities.OutputReportByteLength), _ > NumberOfByteRead, _ > 0) Du willst vom Gerät lesen. Und da sich die Angabe der Datenrichtung immer auf den Host bezieht, fließen die Daten in Richtung IN. Deswegen ist der dritte Parameter falsch gesetzt, das muß Capabilities.InputReportByteLength heißen. Die OutputReportByteLength ist in deinem Fall immer 0. Da Du einen InputReport mit einer Länge von 2 Bytes hast, wird InputReportByteLength auf 3 gesetzt sein, da hier noch ein Byte für den Report-Identifier hinzukommt. Der Report-Identifier bestimmt den Report, den Du Lesen willst. Vor dem Lesen mußt Du dieses Byte initialisieren. Wenn ich mal davon ausgehe, daß ReadBuffer ein Byte-Array ist, müsste das so richtig sein: ' Report-ID setzen ' In diesem Fall 0, da nicht mit Report-Identifiern gearbeitet wird ReadBuffer(0) = 0 ' Erst jetzt versuchen zu Lesen Result = ReadFile(HidDevice, _ ReadBuffer(0), _ CLng(Capabilities.InputReportByteLength), _ NumberOfByteRead, _ 0) > Wert = ReadBuffer(0) > Wert = Wert * 65535 > Wert = Wert + ReadBuffer(1) 'Wert' ist vom Typ Integer. Die Multiplikation mit 65535 lässt diesen Gnadenlos überlaufen. Außerdem ist das erste Byte, wie gesagt, mit dem Report-Identifier belegt. So sieht das für meinen Geschmack besser aus: Wert = ReadBuffer(1) * 256 + ReadBuffer(2)
> Suspended-Mode: > Ja, das kommt vielleicht später. Warum ist das so wichtig? Zum einen ist es von der Spezifikazion gefordert (7.1.7.6: "All Devices must support the Suspend state"). Zum Anderen willst Du Dein Gerät an ein Mobiles Gerät anschliessen. Das Abschalten des Busses bezieht sich normalerweise nicht auf die Versorgung; es werden vielmehr einfach die Leitungen D+ und D- in Idle versetzt. Wenn Du darauf Dein Gerät nicht supspendest, wirst Du schön den Akku leerlutschen...
Also Rene, du bist dein Gewicht in Gold wert. Es funktioniert! Ich bin zwar Pessimist geworden und muss noch ein wenig testen und noch das ein oder andere mit umsetzen (Out Pipe) aber erst mal ist der Durchbruch geschafft. Schreib die Rechnung, bzw. beantworte die Mail, die ich dir geschickt habe. (nehm aber bitte das mit dem Gold und so nicht so erst....) Ich hoffe, dass ich auch weiterhin auf dich bauen kann. Das nächste Mal verspreche ich aber selbst ein wenig gründlicher vorzugehen. So viele Fehler in so wenig Code ... das ist arg peinlich. Suspend-Mode: Ich hab es extra noch mal ausprobiert. Wenn der Palm in Suspend geht, dann wird der Bus komplett zusammen mit Versorgungsspannung abgeschaltet. Der Rest ist mir ehrlich gesagt erst mal wurscht. Denn mir bereitet der Transistor immer noch unbehangen, den ich brauchen würde, um die Elektronik abzuschalten. Den µC abzuschalten ist kein Thema - da gibt es Funktionen für - aber den Rest - außerdem bringt jeder Transistor einen Spannungsabfall (wenn auch sehr klein) mit sich. Ganz abgesehen von dem Platz.. (Die fertige Platine ist 1 x 1,5 cm groß) Nein, das ist gar nicht gut..
> außerdem bringt jeder Transistor einen Spannungsabfall Deswegen nehme ich meist Spannungsregler dafür. Klein ist z.B. der LP2981. Für 5 Volt Anwendungen ist mir Microchips MCP1252-33X50 ans Herz gewachsen (der sich aber auch 3,3 Volt eignet). Von der Strombelastbarkeit dürften beide Deinen Anforderungen genügen. Aber wenn's jetzt eh egal ist...
zum Suspend: Die Compilancetests sagen da gar nichts. Dein Teil muss 3ms nach dem letzten SOF in den suspend mode wechseln (500µA inc Pullup) Ansonsten ist das aber nur ein Konformitätsfrage wenn das nicht funktioniert wirst du halt kein Plugfest bestehen. Ich kenne viele Geräte die das nicht machen. Das ist meistens Absicht weil es nur Probleme mit Win gibt (Gerät geht verloren Probleme mit dem Aufwachen...) Die Strategie mit dem Ignorieren ist nicht die schlechteste. Descriptorrequests: das hast du falsch verstanden. Du musst immer genau soviele Bytes wie der Host anfordert. Wenn du eine Anforderung mit wLength 0x0009 bekommst eben nur den Config Descriptor ansonten gehören Interface und Endpointdeskriptor zur Config(x). Wenn ein Configdeskriptor kürzer ist als angefordert dann halt weniger schicken. Es gibt theoretisch auch Devices mit mehreren Configs (ich hab mal sowas gemacht) Ich hatte zu Anfang auch keinen USB Analyzer und habe mir dehalb extra eine HW mit VonNeuman Ram gebaut damit ich mit dem Keil Monitor debuggen konnte. Das war schon sehr lehrreich. Da ich auch einiges mit den TUSBs gemacht habe habe ich mir rangewöhnt für jeden Chip eine passende USB Lib in C zu schreiben. 3 Tage vergeblich debuggen und der Elisys ist bezahlt. Thomas
> Die Strategie mit dem Ignorieren ist nicht die schlechteste.
genau. die spec ist eh nur schlampen-scheiß, steht nur dummes zeugs
drin. das ignorieren ist das beste was du machen kannst. alle geräte
mit logo lügen oder kommen nicht aus suspend wieder, jedenfalls unter
windows! deswegen beschalten auch nur völlige idioten beim ftdi /pwen
und oder oder /seelp. nach suspend funktioniert die schaltung sowieso
nicht mehr. es ist nicht möglich unter windows gemäs spec zu
entwickeln. geht schaltung auf entwicklungsrechner geht immer. spec
ignorieren!!!!!!!!!
Deutliche Worte......
Ich hab versucht mal ohne euch klarzukommen, aber irgendwie....
Also es ist jetzt eine gewisse Zeit vergangen und ich hab erst einmal
meine Firmware noch ein wenig verfeinert.
Aber ich stehe im Grunde immer noch vor dem selben Problem:
Kurze Zusammenfassung, damit ihr nicht noch mal das ganze Zeug oben
lesen müsst:
Ich will ein USB HID Gerät an einem Windows Mobile 2003 SE System
betreiben und schreibe dazu momentan eine Anwendung in C# und .NET CF
1.1
Mein Gerät arbeitet inzwischen einwandfrei in einer Win32 Umgebung. Ich
hab auch inzwischen die Methoden CreateFile, WriteFile und ReadFile im
Windows Mobile System eingebunden. Doch es fehlt mir der Pfad zum
Gerät.
Unter Win2K und WinXP sieht der Pfad für CreateFile zu meinem HID als
Beispiel folgendermaßen aus:
\\?\hid#vid_03eb&pid_3009#6&7ab9fb0&0&0000#{4d1e55b2-f16f-11cf-88cb-0011
11000030}
Unter Win98SE und ME zum Beispiel so:
\\.\0000000000000012#{4d1e55b2-f16f-11cf-88cb-001111000030}
Unter Win32 hab ich mir den über die Funktionen
SetupDiGetClassDevs
SetupDiEnumDeviceInterfaces
SetupdiGetDeviceInterfaceDetail
In der setupapi.dll geholt.
Wie bekomm ich jetzt den Pfad unter Windows Mobile?
Ich find nichts in der coredll.dll (und nicht im SDK, und nicht in
MSDN, und nichts im I-Net ...)
Dasselbe hab ich schon in ein paar anderen Foren gefragt, doch da kam
überhaupt keine Antwort...
Vielleicht kennt ihr jemanden, an dem ich mich wenden kann.
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.