mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik USB + HID + Atmel + Datenübertr.


Autor: Andreas Knorr (phantast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: René König (king)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Andreas Knorr (phantast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: René König (king)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
was steht in Edit1.text drinen ? Ein Devicezugriff über CreateFile()
beginnt mit Doppelslash.

Gruß Hagen

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pedantischer Einwurf:

Doppel_back_slash, in C/C++-Source also gleich vier davon ...

Autor: René König (king)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Andreas Knorr (phantast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 gibt’s eine Funktion im
HID.DLL…(allerdings gibt’s 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 API’s
ä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 API’S 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…

Autor: René König (king)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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 API’s ä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=...

> 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.

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Knorr (phantast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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 hat’s 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....

Autor: Andreas Knorr (phantast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: René König (king)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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)

Autor: René König (king)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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...

Autor: Andreas Knorr (phantast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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..

Autor: René König (king)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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...

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klaus Brinkmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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!!!!!!!!!

Autor: Andreas Knorr (phantast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.