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 !
:
Bearbeitet durch Admin
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: > Habe 42 getestet ging aber noch nicht. #define MAXBUF_ 120; HANDLE hUSB_Device_; OVERLAPPED myOVL_; BYTE myOutBuf_[MAXBUF_],myInBuf_[MAXBUF_]; hUSB_Device_ = CreateFile( detailData->DevicePath, GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, FILE_FLAG_OVERLAPPED, NULL); DeviceIoControl(hUSB_Device_, 42,&myInBuf_, 100,myOutBuf_, 8,&BackAnz_,&myOVL_);
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.
1 | #definiere GROEZWISPEICHER_ 120 |
2 | |
3 | GRIFF hUSB_Geraet; |
4 | UEBERLAPPT meinUEBL; |
5 | BISSEN MeinAusSpeicher_[GROEZWISPEICHER_],MeinEinSpeicher_[GROEZWISPEICHER_]; |
6 | |
7 | hUSB_Geraet = ErstelleDatei( kleinscheissDaten->GeraetePfad, |
8 | GENERISCHER_LES | GENERISCHER_SCHREIB, |
9 | DATEI_TEILE_LES | DATEI_TEILE_SCHREIB, |
10 | NULL, |
11 | OEFFNE_DA_SEIEND, |
12 | DATEI_FLAGGE_UEBERLAPPT, |
13 | NULL); |
14 | |
15 | GeraeteEinAusKontrolle(hUSB_Geraet_, |
16 | 42, ... |
Schon funktionierts. Naja, vielleicht noch ein paar Unterstiche mehr vorne und hinten an alles ranpappen... SCNR, WK
So hatte ich mir das in etwa vorgestellt. Aber ein Versuch war's wert ...
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.
So ganz ohne Englisch wird das schwierig. Aber für HID braucht man kein IOCONTROL, dafür gibts das HID API in Windows: https://docs.microsoft.com/en-us/windows-hardware/drivers/hid/introduction-to-hid-concepts
@usbman
Weil ich gestern kein Zeit ,mehr hatte.
Hier die Liste der Deskriptoren->
Connection Status Device connected
Current Configuration 1
Speed Full (12 Mbit/s)
Device Address 6
Number Of Open Pipes 1
Device Descriptor
Offset Field Size Value Description
0 bLength 1 12h
1 bDescriptorType 1 01h Device
2 bcdUSB 2 0110h USB Spec 1.1
4 bDeviceClass 1 00h Class info in Ifc Descriptors
5 bDeviceSubClass 1 00h
6 bDeviceProtocol 1 00h
7 bMaxPacketSize0 1 40h 64 bytes
8 idVendor 2 10CEh Silicon Labs
10 idProduct 2 EB70h
12 bcdDevice 2 0000h 0.00
14 iManufacturer 1 01h
15 iProduct 1 00h
16 iSerialNumber 1 00h
17 bNumConfigurations 1 01h
Configuration Descriptor 1 Bus Powered, 100 mA
Offset Field Size Value Description
0 bLength 1 09h
1 bDescriptorType 1 02h Configuration
2 wTotalLength 2 0022h
4 bNumInterfaces 1 01h
5 bConfigurationValue 1 01h
6 iConfiguration 1 00h
7 bmAttributes 1 80h Bus Powered
4..0: Reserved ...00000
5: Remote Wakeup ..0..... No
6: Self Powered .0...... No, Bus Powered
7: Reserved (set to one)
(bus-powered for 1.0) 1.......
8 bMaxPower 1 32h 100 mA
Interface Descriptor 0/0 HID, 1 Endpoint
Offset Field Size Value Description
0 bLength 1 09h
1 bDescriptorType 1 04h Interface
2 bInterfaceNumber 1 00h
3 bAlternateSetting 1 00h
4 bNumEndpoints 1 01h
5 bInterfaceClass 1 03h HID
6 bInterfaceSubClass 1 00h
7 bInterfaceProtocol 1 00h
8 iInterface 1 00h
HID Descriptor
Offset Field Size Value Description
0 bLength 1 09h
1 bDescriptorType 1 21h HID
2 bcdHID 2 0110h 1.10
4 bCountryCode 1 00h
5 bNumDescriptors 1 01h
6 bDescriptorType 1 22h Report
7 wDescriptorLength 2 002Eh 46 bytes
Endpoint Descriptor 81 1 In, Interrupt, 4 ms
Offset Field Size Value Description
0 bLength 1 07h
1 bDescriptorType 1 05h Endpoint
2 bEndpointAddress 1 81h 1 In
3 bmAttributes 1 03h Interrupt
1..0: Transfer Type ......11 Interrupt
7..2: Reserved 000000..
4 wMaxPacketSize 2 0040h 64 bytes
6 bInterval 1 04h 4 ms
Interface 0 HID Report Descriptor Vendor-Defined 1
Item Tag (Value) Raw Data
Usage Page (Vendor-Defined 1) 06 00 FF
Usage (Vendor-Defined 1) 09 01
Collection (Application) A1 01
Report ID (4) 85 04
Usage (Vendor-Defined 1) 09 01
Logical Minimum (0) 15 00
Logical Maximum (255) 26 FF 00
Report Count (5) 95 05
Report Size (8) 75 08
Input (Data,Var,Abs,NWrp,Lin,Pref,NNul,Bit) 81 02
End Collection C0
Usage Page (Vendor-Defined 1) 06 00 FF
Usage (Vendor-Defined 1) 09 01
Collection (Application) A1 01
Report ID (6) 85 06
Usage (Vendor-Defined 1) 09 01
Logical Minimum (0) 15 00
Logical Maximum (255) 26 FF 00
Report Count (7) 95 07
Report Size (8) 75 08
Feature (Data,Var,Rel,NWrp,Lin,Pref,NNul,NVol,Bit) B1 06
End Collection C0
@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.
:
Bearbeitet durch User
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 ?
Ich sehe da einen "off by one" Fehler:
1 | zIDX_=0; |
2 | Output_Buffer_[zIDX_++]= 0x06; Life Daten aus dem Datenverkehr ... |
3 | Output_Buffer_[zIDX_++]= 0xFE; |
4 | Output_Buffer_[zIDX_++]= 0xFD; |
5 | Output_Buffer_[zIDX_++]= 0x02; |
6 | Output_Buffer_[zIDX_++]= 0x64; |
7 | Output_Buffer_[zIDX_++]= 0x00; |
8 | Output_Buffer_[zIDX_++]= 0xBE; |
9 | Output_Buffer_[zIDX_++]= 0x80; |
10 | |
11 | BytesWritten_ = 0; |
12 | |
13 | status_ = WriteData(hWrite_,Output_Buffer_,zIDX_-1,&BytesWritten_); |
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.
You have really doing well for better programming skills you can meet the experts via link i'm providing here https://nareshit.com/python-online-training/
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
MaWin schrieb: > Thomas Z. schrieb: >> Was ist HIT? > > !!!!!! Menschlicher-Zwischengesichts-Peschreiper!!!!!elf
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.
Beitrag #7024666 wurde von einem Moderator gelöscht.
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.