?
pargus schrieb:
In meinem Fall lege ich VID, PID, Versionsnummer und Interfaces der Platine selbst fest (bzw mein Prof.), aber es geht allgemein darum die DLL (z.b.) sobald zwei gleiche Platinen angesteckt sind, diese eindeutig voneinander unterscheiden kann (da der USB-Deskriptor ja gleich ist).
Und man kann sich ja von Windows den kompletten Pfad geben lassen
Genau so ist es. Und der Pfad, den Dir das System gibt, ist eindeutig. Über diesen unterscheidest Du die Geräte von einander -> Problem gelöst!
Falls dem Anwender Deiner Bibliothek das etwas zu lang und/oder zu kryptisch sein sollte, muss er eben Aliase verteilen. Und wenn Du das nicht dem Anwender überlassen willst, machst Du's Dir eben selbst, vielleicht in dieser Art:
DefineDosDevice(0, TEXT("MY_COOL_HID1"), TEXT("\\\\?\\hid#vid_16c0&pid_1001&mi_01#7&37a49a66&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}"));
hDevice = CreateFile(TEXT("\\\\.\\MY_COOL_HID1"), ...);
pargus schrieb:
Nun ist es anscheinend so, dass man sich Interfacenr., ParentID nummer und WinUsbId nicht so einfach ausgeben lassen kann (also aus dem Pfad irgendwie rauslesen muss).
Das macht rein gar nichts. Der String "\?\hid#vid_16c0&pid_1001&mi_01#7&37a49a66&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" ist bereits eindeutig, das reicht zur Identifizierung. Alles andere wird dem Anwender sowieso zu schwer. Bis heute kannst Du niemandem den Unterschied zwischen COM1 und COM2 erklären, das wird mit ParentID und WinUsbId nicht einfacher. Also: Gebe den ermittelten Pfad zum Gerät zurück und fertig.
pargus schrieb:
Außerdem hätte ich noch folgende Anforderungen an meine Bibliothek und würde gerne Hilfe bei der Umsetzung bekommen, speziell die Umsetzung oder Realisierung in C :
"use case 1":
Was will ein Nutzer typischerweise haben?
Geräte einfach finden und öffnen
Das finden der Geräte erledigst Du per SetupAPI. Die nötigen Funktionen habe ich Dir ja bereits genannt. Das Öffnen geschieht, wie bei allen Geräten, per CreateFile.
pargus schrieb:
Reports senden/empfangen
Lesen und schreiben funktioniert, wie bei allen Geräten, per ReadFile und WriteFile. Wenn Du nicht die vorgesehenen Endpunkte verwenden willst, sondern stattdessen die weniger effizienten Setup-Requests über den Endpunkt 0, kannst Du alternativ natürlich auch HidD_GetInputReport und HidD_SetOutputReport nehmen.
pargus schrieb:
Soll das Gerät in der Bibliothek erhalten bleiben, mit einer Meldung "entfernt"?
Soll die Bibliothek selber aktiv werden, wenn ein Gerät (alt,neu) enumeriert wird?
Wie kann das Freigeben eines ggf. blockierten Gerätes sinnvoll umgesetzt werden.
Derjenige, der bei Dir das Device-Handle hält, muss über das Ereignis unterrichtet werden und daraufhin eben dieses schließen. Zusätzlich muss der Client unterrichtet werden, damit dieser bei Bedarf sein UI aktualisieren kann.
pargus schrieb:
Vorab Info:
Ich habe eine Struktur angelegt die die Informationen zu den IN-,Out- und FEATURE-Reports und Vid, Pid, Revision, Interface, und buffer beinhaltet und diese Daten werden bei einem neuanstecken des USB Gerätes in einen freien Tabellenplatz, diese Tabelle wurde auch neu angelegt, eingetragen (d.h. die Tabelle zeigt via Pointer auf die Struktur und speichert somit die Adresse wo die Infos stehen in den einzelnen Tabellenplätzen und gibt nur die Indizes an Anwendungen zurück).
Passiert das Lesen und Schreiben der Struktur im selben Thread, der auch ReadFile und WriteFile aufruft?
