Hi zusammen,
beschäftige mich seit Wochen (USB Neuling!) damit mein kleines USB
Display auszulesen. Das Lesen klappt einwandfrei nur das Schreiben will
nicht klappen. Habe die CAPs gelesen und da steht beim Parameter
für lesen (also das Display sendet beim Tastendruck den Tastencode)
die Anzahl 6. Genau diese 6 Zeichen kommen auch. Da kommt eine 4 die
steht wohl für Joystick oder Controler (habe ich irgendwo in einer Liste
gelesen) und da kommen dann noch ein paar Bytes darunter 2 mal die Zahl
für die Taste.
Beim Parameter für Schreiben steht >0<. WriteFile klappt nicht. Gibt
NULL zurück und auch keine Fehlermeldung
Ich habe den Pfad für das Gerät zunächst auf die Übliche Weise gesucht
und dann sobald gefunden mit
CreateFile(USBPFAD...,....,OVERLAPPEDMODUS,0)
die HANDLE geholt. Dann mit ReadFile, gespickt mit CreateEvent usw.
klappt das Lesen einwandfrei.
Das Display ist in der Lage Zeichen zu empfangen und darzustellen.
Mit einem USB Tool habe ich die Daten die das Display benötigt
herausfinden können.
Nur nutzt mir das nichts, wenn ich es nicht aus meinem Programm
beschreiben kann. Habe schon gegoogelt jeden Tag aber fasst alles auf
englisch und da verstehe ich das meiste leider nicht.
DeviceIOControl wäre noch ne Möglichkeit. Weiß aber nicht wie der Code
für den zweiten Parameter heißen sollte. IOCTL_......?
BOOL DeviceIoControl(
HANDLE hDevice,
DWORD dwIoControlCode,
LPVOID lpInBuffer,
DWORD nInBufferSize,
LPVOID lpOutBuffer,
DWORD nOutBufferSize,
LPDWORD lpBytesReturned,
LPOVERLAPPED lpOverlapped
);
Wäre dankbar für'nen Tip !
Am besten fängst du noch Mal an....
Was ist HIT?
Was ist CAPs?
Was erhoffst du dir von DeviceIoControl? Hast Dokus des Treibers?
Wie ist der übliche Weg den handle zu bekommen?
Schau doch mal libhidapi an, die kapselt da einiges an Gedöns und geht
auch für Windows:
https://github.com/libusb/hidapi
Aber um etwas Englisch wirst du nicht herumkommen.
>>Am besten fängst du noch Mal an....<<
Leider verstehe ich nicht was Du mir damit sagen möchtest ?!?
1. Die CAP's lesen geht und die Handle funzt weil lesen geht ja schon.
2. Was ein Hit ist ? Das ist ein Gerät das einfach gesagt keinen Treiber
von einem extra Hersteller benötigt, weil Windows da Dll's für bereit
stellt und wohl auch HIT - Treiber.
Ich habe mir auch ein Buch gekauft von Jan Axelson. Aber in dem Buch
steht nicht drin wie assyncrones Schreiben geht oder ich habe es noch
nicht entdeckt. Ist ja durch weg in Englisch was deutsches fand ich
nicht.
Komisch was ich fand, war durch weg Englisch oder anders sprachig.
Was ich auch oft fand, waren in Foren ähnliche Fragen, spärlich auf
Deutsch meißt auch alles Englisch. Aber da war Programmcode dabei, so
habe ich schon einiges verstanden, sonst hätte ich das Lesen nicht
hinbekommen.
Was meine ich mit Assyncron? Nun irgendwann drücke ich eine Taste und
dann
soll mein Programm darauf reagieren und in das Display ein paar Zahlen
schreiben. Das Original Prog kann das ja auch. Es geht nicht um riesige
Datenmengen, die auch noch irgend wie in bestimmten Abständen
gesendet und empfangen werden müssten.
Das Display wird vom Original Programm auch beschrieben wenn sich die
Zahlen im Programm auf der PC Seite ändern ohne das eine Taste gedrückt
wird.
Was ich mir von DeviceIoControl verspreche? Nun ich habe den Eindruck
das
über diese Funktion das Gerät Daten empfangen kann. K.A.
Roland schrieb:> Roland schrieb:>> Habe 42 getestet ging aber noch nicht.
Kann so ja nicht gehen, ist ja Englisch. Es scheint ja um ein
Menschliches Zwischengesichts-Geraet zu gehen, eine Unterabteilung der
Umfassend Systematischen Bindung.
Alzond hinne middn weichen Dee, ned middn haddn.
OK du redest von HID. Ich würde als erstes mal die den HID Report
descriptor anschauen dort ist festgelegt was dein Device beim Schreiben
erwartet.
DeviceIoControl führt nur in Ausnahmen zum Ziel, nämlich dann wenn du
die im Treiber verwendeten ControlCodes kennst.
HID wird ganz normal mit ReadFile WriteFile angesprochen. Ab Seite 329
ist das in der 4 Ausgabe von USB Complete beschrieben. So wie du
schreibst hast du bei WriteFile ein Problem, also schau in den
Reportdeskriptor. Vernünftige Literatur gibt's nur in Englisch bei MS
manchmal nicht automatisch übersetzt in deutsch.
Hi nochmal,
Ich habe mich nun eine weitere Woche eingelesen und getestet was das
Zeug hält.
Jedoch konnte ich nicht ein einzige Byte zum Display schicken. Immer
kommt nur
als Fehler der Spruch "Falscher Parameter". Das deutet darauf hin, das
die Daten wie
gesendet so vom Treiber nicht verwendet werden können.
Was mir jedoch gelungen ist, das ich mit einem USB Analyse Prog die
Deskriptoren auslesen
konnte.
Nur eines ist mir völlig schleierhaft und zwar, wie kann es sein, das
beim lesen mit ReadFile keinerlei Deskriptoren interessieren.
Es werden mit ReadFile anscheinend auch keinerlei Verpackungsdaten
Empfangen, sondern nur Nutzdaten. Es kommen mit jedem Tastendruck oder
Loslassen immer genau 6 Bytes.
Zunächst immer eine 4 und dann die Tastennummer. Dann ein paar Nullen
und nochmal die Tastennummer oder beim Loslassen jeweils Null für die
Tastennummer. Immer insgesamt
6 Bytes.
Für Schreiben habe ich im Analyse Prog 6 Datensätze mit jeweils 8 Bytes
mit vorangestellter
6 erkannt. Dies kommt mit jeder Änderung im Display.
Es schwant mir, das die Daten aus den Deskriptoren irgendwie mit in die
zu schreibenden
Daten eingebunden werden müssen. Nur konnte ich dies noch nirgends
finden.
Grundsätzlich möchte ich noch sagen, das ich es schade finde, das dem PC
und damit dem gemeinen Bastelfreak oder Semiprofessionllen Anwender die
relativ einfachen Schnittstellen
weggenommen wurden. Die VCT (Virtuelle Comporttreiber) sind nicht ein
Ersatz ohne Nachteile
wie ich leider feststellen musste. Denn wenn ich z.B. so etwas machen
will, wie ein beliebiges HID Gerät
für mein eigenes Programm zu benutzen, aber der Hersteller
keine passende DLL mitliefert, kommt man doch nicht umhin sich mit USB
zu beschäftigen.
Andererseits bin ich froh, das es USB und damit ne einheitliche
Schnittstelle gibt.
Und was das Lesen angeht, bin ich echt begeistert wie easy das geht, da
der passende Treiber
von Windows mitgeliefert wird und auch noch alles Plug und Play
funktioniert.
Es wäre doch bestimmt für ne Menge von Leuten interessant eine Anleitung
zuhaben wie Schreiben und Lesen beim HID Gerät funktioniert ohne das man
dafür fasst studieren muss oder
Berge weise Bücher bzw. Dokus lesen, die auch noch fasst durchweg in
Englisch geschrieben sind.
Es ist klar bei dem Umfang was die Schnittstelle USB bietet, ist das
auch nicht einfach mal eben beschrieben. Aber HID sollte wenigstens
bekannt sein, also das der gemeine Selfmade Maker
damit zurecht kommt.
Roland schrieb:> Es schwant mir, das die Daten aus den Deskriptoren irgendwie mit in die> zu schreibenden> Daten eingebunden werden müssen. Nur konnte ich dies noch nirgends> finden.
Die bei USB HID zu übertragenen Daten sind im Report Deskriptor
definiert. Eine gute Referenz dazu ist mir aber nicht bekannt.:(
Den für Tastaturen gibt es meisten schon im USB Hersteller Beispielcode
bei beliebigen USB µCs.
Roland schrieb:> Es wäre doch bestimmt für ne Menge von Leuten interessant eine Anleitung> zuhaben wie Schreiben und Lesen beim HID Gerät funktioniert ohne das man> dafür fasst studieren muss oder
Es gibt reichlich HID Beispielcodes. Reverse Engineering eines
vorhandenen Geräts ist trotzdem nicht-trivial.
Roland schrieb:> Was mir jedoch gelungen ist, das ich mit einem USB Analyse Prog die> Deskriptoren auslesen> konnte.
Und warum zeigst du die Deskriptoren nicht? Im Besonderen wäre der
HidReportDescriptor interessant da dort das Format beschrieben ist wie
dein writeFile aufgebaut werden muss.
Jim M. schrieb:> Eine gute Referenz dazu ist mir aber nicht bekannt.:(
Jan Axelson USB Complete allerdings ist das auch auf Englisch. Wegen den
wenigen Programmierern die kein Englisch können wird kein Verlag eine
deutsche Übersetzung rausbringen.
@turboj
Es gibt reichlich HID Beispielcodes. Reverse Engineering eines
vorhandenen Geräts ist trotzdem nicht-trivial.
Ok-Habe das lesen ja hinbekommen und das nur durch Beispielcode den ich
für mein Bedürfnisse etwas abgeändert habe.
Lesen klappt ohne einen einzigen Deskriptor zu beachten - kratz Kopf?!?
Ich mach alles mit USB2Serial. Auf der Embedded Seite einen FT232 oder
aehnlich von FTDevices rein und gut ist. Was anderes wuerde ich mir
nicht antun. Ich habe zuviele an einem eigenen USB Treiber scheitern
sehen. Fuer professionelle Ansaetze allenfalls mal bei thesycon.de
reinschauen. Die machen das.
OK ich versuch mal eine Erklärung:
Dein Device hat 2 Reports, einen Input mit 5 Bytes und vorangestellter
ReportID 4. Den zu lesen ist einfach dazu musst du in ReadFile einfach 6
Bytes lesen die Bedeutung dieser Bytes bestimmt deine LeseApp. Das ist
sehr wahrscheinlich einfach eine HidTastatur die auf Vendor gestellt ist
damit die Keycodes nicht an den System Tastaturtreiber weitergeleitet
werden.
Nun zum WriteFile der Report erwartet 7 Bytes + ReportID 6. Über die
Bedeutung dieser Bytes kann man nur spekulieren. Da es ein Display ist
würde ich annehmen dass es einen KomandoCode + Parameter gibt. Wie das
auszusehen hat, wurde beim Erstellen der Firmware festgelegt. Wenn es
also keine Doc gibt bleibt dir nur mit einem Sniffer die Reports zu
protokollieren und zu entschlüsseln. Vendor heißt eben das kann alles
sein, es gibt kein vordefinierte Format.
Ich geb dir mal ein Beispiel:
SetPosStart(x1,y1)
SetPosEnd(x1,y1)
Clearscreen(color)
Sowas ähnliches sollte in den Reports auftauchen wenn du den Bildschirm
löschst.
Thomas Z. schrieb:> OK ich versuch mal eine Erklärung
Ich habe jetzt ne gute Erklärung von dem Firmware Hersteller Silicon
Labs
gefunden->https://www.silabs.com/documents/public/application-notes/AN249.pdf
Darauf hin habe ich mal genauer hin gesehen was mein Free USB Monitor
Tool
zeigt.
Tatsächlich 2 Geräte oder Interfaces auf einem Port für mein Display.
Dann habe ich diese Phad Strings mal extrahiert und an CreateFile
übergeben.
Tatsächlich bekam ich zwei verschiedene Handle Nummern und habe diese
getestet. Lesen funktionierte wie gehabt aber schreiben wieder nicht.
Mit SetOutputReport kam keine Reaktion auch kein Fehler.
Mit WriteFile kam auch keine Reaktion aber ein Fehler Namens Falscher
Parameter ?!?
Poste hier mal den Text->
hRead_ =
CreateFile("\\\\?\\hid#vid_10ce&pid_eb70&col01#7&77f644d&0&0000#{4d1e55b
2-f16f-11cf-88cb-001111000030}", //col01
GENERIC_READ|GENERIC_WRITE,
FILE_SHARE_READ|FILE_SHARE_WRITE, NULL,
OPEN_EXISTING, FILE_FLAG_OVERLAPPED, NULL);
hWrite_ =
CreateFile("\\\\?\\hid#vid_10ce&pid_eb70&col02#7&77f644d&0&0001#{4d1e55b
2-f16f-11cf-88cb-001111000030}",
GENERIC_READ|GENERIC_WRITE,
FILE_SHARE_READ|FILE_SHARE_WRITE, NULL,
OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,0);
ovlw.hEvent = CreateEvent(NULL,FALSE,FALSE,NULL);
ovlr.hEvent = CreateEvent(NULL,FALSE,FALSE,NULL);
print_zahl_text_((LONG) hRead_,10,10,"<- Handle Read "); // zahl hin
print_zahl_text_((LONG) hWrite_,10,10,"<- Handle Write "); // zahl hin
zIDX_=0;
Output_Buffer_[zIDX_++]= 0x06; // Life Daten aus dem Datenverkehr
...
Output_Buffer_[zIDX_++]= 0xFE;
Output_Buffer_[zIDX_++]= 0xFD;
Output_Buffer_[zIDX_++]= 0x03;
Output_Buffer_[zIDX_++]= 0x01;
Output_Buffer_[zIDX_++]= 0x00;
Output_Buffer_[zIDX_++]= 0xE8;
Output_Buffer_[zIDX_++]= 0x83;
test_ = HidD_SetOutputReport(hWrite_,Output_Buffer_,zIDX_-1);
print_zahl_text_(test_,300,10,"<- SetReport...1"); // zahl hin
zIDX_=0;
Output_Buffer_[zIDX_++]= 0x06; Life Daten aus dem Datenverkehr ...
Output_Buffer_[zIDX_++]= 0xFE;
Output_Buffer_[zIDX_++]= 0xFD;
Output_Buffer_[zIDX_++]= 0x02;
Output_Buffer_[zIDX_++]= 0x64;
Output_Buffer_[zIDX_++]= 0x00;
Output_Buffer_[zIDX_++]= 0xBE;
Output_Buffer_[zIDX_++]= 0x80;
BytesWritten_ = 0;
status_ = WriteData(hWrite_,Output_Buffer_,zIDX_-1,&BytesWritten_);
print_zahl_text_((LONG) status_,300,10,"<- Succses ?..."); // zahl
hin
print_zahl_text_((LONG) BytesWritten_,300,10,"<- BytesWritten_
?..."); // zahl hin
Frage mich was das sein kann ?
Der Code schreibt nur 7 der 8 Bytes im Array Output_Buffer.
Ich empfehle dringend eines der Frameworks für HID zu benutzen (HID.DLL
oder HIDAPI.DLL). Das will man nicht zu Fuß machen.
Zwei Dinge fallen mir auf. Du benutzt kein WriteFile sondern WriteData.
Wie Jim schon angemerkt hat, schickst du ein Byte zuwenig. Dein PDF
beschreibt HID Beispiele allgemein, dein Display ist aber nicht dabei.
Gibt es keine Doc dazu?
Spekulation:
02 FD FE könnte LJMP 0FDFEh bedeuten (8051)
Dazu müsste man aber in die Firmware schauen. Vielleicht hat die
Firmware ja eine Art Funktionstabelle.
Thomas Z. schrieb:> Zwei Dinge fallen mir auf.
Ich vergaß gestern noch Deine Erklärung zu bestätigen was Du aus den
Report Deskriptoren gelesen hast stimmt.
Zu dem 8051, das kann hinkommen. Ist aber ungewöhnlich, weil die
einzelnen Aufrufe für Displayausgabe ziemlich oder relativ viel Text
sind,
habe mich lange damit beschäftigt und habe solchen Text auch noch da.
Nachher teste ich mal weiter, geht iMo nicht. Melde was es war.
In der realen Interaktion mit dem Programm werden immer 6 * 8 Bytes
geschickt.
Hatte das damals einige Tage o. Wochen untersucht und notiert.
Inzwischen
ist die Testzeit für das Monitor Prog abgelaufen und ich weiß nicht mehr
wie es hieß. Mittler Weile bin ich bereit die ca. 70 Teuronen dafür
auszugeben.
An meinem Programmier-PC habe ich kein Internet mit Absicht. Dadurch
kann
ich leider keinen USBlyser verwenden, weil der sich offenbar einloggt
und
die Startzeit bei dem Vertrieb meldet.
Kennst Du ein gutes Prog was ich dafür verwenden kann, bezahlbar?
Zu dem WriteData: Das ist meine eigenen Funktion in der WriteFile
natürlich verwendet wird. Es wird ja nicht nur WriteFile aufgerufen
sondern noch paar andere Funktionen wie z.B. die Fehlerbehandlung usw.
Roland schrieb:> Kennst Du ein gutes Prog was ich dafür verwenden kann, bezahlbar?
Ich benutze USBPcap in Verbindung mit wireshark, das ist Open Source.
Da du offensichtlich keine Docs zum Display hast ist nun der harte Weg
angesagt... Dieser ist übrigens unabhängig von der Schnittstelle. Bei
einer ser. Verbindung wäre der Aufwand genau der Gleiche, vielleicht
sogar mehr wenn CRC und Checksummen im Spiel sind.
Thomas Z. schrieb:> USBPcap in Verbindung mit wireshark
iMo habe ich nur das Problem das ich mit WriteFile wzw. keiner Funktion
die mir bekannt ist etwas beschicken kann.
Eben kam mit WriteFile in der OverlappedStrucktur unter dem Punkt
ovlw.Internal die Code Nummer 259
Auf der Seite Beckhof sind die Codes gelistet nur deuten vermag ich's
nicht.
Win32 Error Codes->
https://infosys.beckhoff.com/index.php?content=../content/1031/TcDiagnostics/HTML/TcDiagnostics_WIN32_ErrorCodes.htm&id=
Dies ist der Fehler der mit WriteFile kommt.
259, 0x00000103, No more data is available, ERROR_NO_MORE_ITEMS
ev. weiß jemand was das bedeutet ...
0x103 ist kein Errorcode. Errorcodes haben immer das MSB gesetzt.
Aus dem Gedächtnis, ich habs nicht überprüft, ist das WaitForComplete
oder so. Mehr gibt's nicht zu sagen da dein Code ja immer noch geheim
ist.
Thomas Z. schrieb:> 0x103 ist kein Errorcode
Auf der Errorliste steht die 259 als ein Fehlercode. Ich habe nach
gelesen,
das in der Overlappetstrucktur unter Internal ein Fehlercode zurück
gegeben wird. Diese Nummer wird jeweils nur mit WriteFile
eingeschrieben.
Es müsste wenn WriteFile auch was geschrieben hat unter dem Punkt
InternalHigh die Anzahl der Bytes auftauchen wie es beim lesen auch
passiert.
Welchen geheimen Code meinst Du?
Geschafft !!!
Endlich zeigt das Display Zahlen :-)
Wie kommt das? Nun ich habe nicht nach gelassen heraus zu finden warum
keine einzige
Funktion für HIT Daten Senden wollte. Jedenfalls zeigte mir kein
einziges Prog das USB Daten
anzeigt das etwas gesendet wird.
Aus den Diskreptoren wurde ich nicht schlau. Habe mir dann ein Tool
gekauft um die 70 Teuronen, das mir als USB Monitor diente. Dann habe
ich das Original Prog zusammen mit dem
Display laufen lassen und immer wieder getestet und die Daten Byte für
Byte verglichen und zu deuten versucht.
Warum der Hersteller kein Datenblatt heraus gibt weiß ich nicht, das
würde die Sache wesentlich vereinfachen. Aber das scheint deren
Geschäftsmodell zu sein und da werde ich nicht zwischen funken. Mir geht
es hier darum ein Feedback zugeben und die Sache aufzuklären.
Ev. hilft das jemanden, der ein ähnliches Problem hat. Mein Lehrer sagte
öfters: Meine Herren denken Sie daran, das Netz lebt auch von Ihren
Eingaben!
Na ja und schließlich soll Edison über 3000! Versuche mit der Glühbirne
gemacht haben bis es endlich funktionierte. Bei mir waren es zwar
weniger aber doch einige Stunden.
Wenn ich mehr Ahnung von den Funktionen für HIT hätte, wäre es bestimmt
schneller gegangen.
Die Diskreptoren geben offensichtlich fasst keinen Hinweis darauf was
wirklich gesendet werden muss.
Die Analyse der Daten hat ergeben, das weder 46 noch 80 noch 64 Bytes
gesendet oder empfangen werden jedenfalls nicht die Nutzdaten betreffend
und um die geht es mir ja.
Sondern es werden stets 12 Pakete empfangen, das zeigte der USBLyser auf
dem Monitor. Jedes Paket das empfangen wurde, wurde von meinem Gerät
wieder zurück geschickt.
So habe ich dann die Daten die das Original Prog gesendet hat mit allen
mir bekannten Funktionen aus probiert.
Zu nächst mit den ermittelten Pfads jeweils eine Handle für Lesen und
eine für Schreiben geholt.
Dann kopierte ich die Nutzdaten aus dem USB Monitor in meinen
SendeBuffer.
Jeweils 6 mal 8 Bytes mit WriteFile, ging nicht.
Auch mit SetOutputReport brachte keinen Erfolg.
Dann nahm ich SetReport weil mir dafür ja alles zur Verfügung stand. Die
Sendehandle und die
Adresse des Buffers, sowie auch der jeweilige Offset des Buffers für die
zu sendenden Daten.
SetReport hat Request. Das heißt diese Funktion ist es wahrscheinlich,
die Sendet (Host) und der Device
mein Display reagiert. Tatsächlich hat es mit dieser Funktion endlich
funktioniert.
Mein Fazit:
Es gibt offensichtlich kein Analyse Prog für Privat, was auch bezahlbar
ist, das alles
zeigt was man wissen muss. Also wie viele Pfade hat mein Device und wann
wird etwas gesendet
auch wenn das Device darauf noch nicht reagiert. Der Monitor zeigte nur
etwas mit den echten
Daten. Also das was die Interaktion mit dem Device und dem Host für
Daten sind wenn es geklappt hat. Es zeigte nichts an, wenn das Display
trotz gesendeter Daten nichts anzeigte.
Es war ein Weg heraus zu finden, das mein Device 2 Pfade hat. Einen zum
Senden und einen zum Empfangen.
Meine Such-Routine hatte stets beim Finden meines Gerätes sofort die
Suche beendet um mit CreateFile die Handle zu holen. Durch Zufall sah
ich eines Tages mit einem USB Testtool,
das ich irgendwo geladen hatte, das da auf der gleichen VID & PID 2
Pfade angezeigt wurden.
Man muss sich bei HIT anscheinend auch um keinerlei Rohdaten kümmern,
sondern nur um die Nutzdaten.
https://www.usb.org/sites/default/files/documents/hid1_11.pdf
Mein Erfolgstext sieht so aus->
(Das hat aber kaum bis gar nichts mit dem was im PDF steht zu tun!?!)
SetReport // geholt mit LoadLibrary aus der HIT.DLL von Windows 7 geht
aber auch mit 10!
SendeBuffer[0] = 0x6 // Sende ID ...
SendeBuffer[1] = 0xFD // Spezieller Header Chunk Erkennungs-Code des
Device...
SendeBuffer[2] = 0xFE // Spezieller Header Chunk Erkennungs-Code des
Device...
SendeBuffer[3] = 0
SendeBuffer[4] = 0xnn // erstes Daten-Byte von insgesamt 48 ...
......
SendeBuffer[47] = 0x0 letztes Daten-Byte ...
....
SetReport(hWrite_,&SendeBuffer , 8) // der Header Chunk mit den ersten
Daten aus dem Buffer ...
SetReport(hWrite_,&SendeBuffer+8 , 8) // die nächsten 8 Bytes aus dem
Buffer ...
SetReport(hWrite_,&SendeBuffer+16 , 8) // die nächsten 8 Bytes aus dem
Buffer ...
SetReport(hWrite_,&SendeBuffer+24 , 8) // die nächsten 8 Bytes aus dem
Buffer ...
SetReport(hWrite_,&SendeBuffer+32 , 8) // die nächsten 8 Bytes aus dem
Buffer ...
SetReport(hWrite_,&SendeBuffer+40 , 8) // die nächsten 8 Bytes aus dem
Buffer ...
Die Zurück gesendeten Daten habe ich bis her noch nicht entdeckt. Ev.
werden die direkt in den
SendeBuffer geschrieben K.A.
Wäre ev. ganz gut die zu überprüfen.
Wer weiß da was ?
Moin,
Roland Klutschewski schrieb:> Ev. hilft das jemanden, der ein ähnliches Problem hat.
Ja das hilft ganz bestimmt. Wenn mal jemand wissen will, was ein Tool
kostet, dann weiss er jetzt, dass es ungefaehr 70 Teuronen sind.
SCNR,
WK
Dergute W. schrieb:> Ja das hilft ganz bestimmt. Wenn mal jemand wissen will, was ein Tool> kostet, dann weiss er jetzt, dass es ungefaehr 70 Teuronen sind.
... was es aber eh nicht braucht, weil man das mit Wireshark auch
kostenlos bekäme...
Reverse Engineering ist immer aufwendig. Und wenn man dann konsequent
auch noch die korrekte Schreibweise ignoriert, hat man auch noch die
unpassenden Suchbegriffe. Die mehrfach erwähnten HID Libs hätten dir
viel Arbeit abgenommen. HID Datentransfer kann man ganz wunderbar mit
Wireshark analysieren
Die Mehrfach erwähnten HID LIBs wollte ich aber nicht. Aus verschiedenen
Gründen. Ich wollte ganz einfach die USB Schnittstelle für meine
Projekte
auch benutzen können, so wie früher LPT, RS232 oder Midi über ne
Soundkarte.
Ganz selbstverständlich auch alles selbst Programmiert und nicht mit
Fremdmitteln. Wer dazu kein Bock hat kann ja auf diverse Angebote
zurückgreifen, ganz wie einer mag. Ist doch O.K.
Ganz offensichtlich ist das mit HID (nicht HIT!!!) gar kein Hexenwerk.
Übrigens habe ich leider >>SetReport<< geschrieben was gar nicht stimmt.
Denn es ist >>SetFeature<<.
iMo teste ich wie ich den Request in meinem Prog auch lesen kann.
Hi alle zusammen,
ich hab hier das ding rauf und runter gelesen hab keine Antwort auf mein
problem gefunden obwohl genau hier mein problem beschrieben wurde, finds
traurig das hier nach lösungen gesucht wird aber hier selber fehlerhafte
Lösungen gepostet wurden.
Aber egal ich brauchte selber eine Lösung und ich hab folgendes gefunden
Das war zumindest meine Lösung Danke an Chris.
https://www.chrisbot.com/usb-hid-ml example-microsoft-c
Mein Problem war das die Byte Anzahl beim Senden und Empfangen nicht 64
sondern 65 war.
Ich find links Scheiße die dann weg sind aber mag keine fremde quellen
posten aber www.chrisbot.com unter google müsst sich ja finden.
