Erstellen einer USB-Device-Liste mithilfe von win32-api

Hallo liebe LabVIEW-Gemeinde,

mein Anliegen ist folgendes:
Ich arbeite zur Zeit als Praktikant an einem automatisierten Testsystem. Das DUT (device under test) wird bislang per fbus angesteuert und ausgelesen und nun soll das ganze auch per usb möglich sein. Da unsere Abteilung für Treiber gerade stark beschäftigt ist wird meine Anfrage für eine Erweiterung der Gerätetreiber noch ne Weile dauern weshalb ich mich gerade selber in die Windows-Programmierung einarbeite um vielleicht selbst einen Weg zu finden die DUT per USB anzusprechen.

Im Moment versuche ich per LabVIEW eine Liste mit Infos (genauer gesagt der Describer-Infos) aller angeschlossenen USB-Geräte zu erstellen. Laut meinen Infos soll das Ganze mit den Funktionen der setupapi.dll möglich sein, nämlich wie folgt:

1. Per Funktionsaufruf "HDEVINFO x = SetupDiCreateDeviceInfoList( IN LPGUID ClassGuid..OPTIONAL, IN HWND hwndParent OPTIONAL );" wird erst einmal eine Liste erstellt in der nacher die Suchergebnisse stehen.

2. Aufruf "x = SetupDiGetClassDevs(NULL, 0, 0, DIGCF_PRESENT | DIGCF_ALLCLASSES );" füllt die Liste mit den gefunden USB-Instanzen

3. Per "SetupDiGetDeviceInterfaceDetai..??);" Kann ich nun die einzelnen Ergebnisse auslesen.

Soviel zum Prinzip. Laut den Infos die ich mir bislang erarbeitet habe macht es allerdings keinen Sinn diese Library per LV aufzurufen, da LV mit den Windowsdatentypen wie z.B. "Handle oder struct" ohnehin nicht viel anfangen kann. Wenn ich mich nicht irre müsste ich selbst noch eine sogenannte "Wrapper-Library" schreiben (C++ z.B.) deren Funktionen die setupapi.dll aufrufen und die ergebnisse in LV taugliche Daten umwandeln. Erst per Aufruf dieser Wrapper-Library bekomm ich dann die gewünschten Daten in LabVIEW.

Meine Fragen an Euch sind nun folgende:
a) Sind meine beschriebenen Gedankengänge im Prinzip richtig?
b) Hat Jemand schonmal derartiges gemacht und kann mir ein wenig Hilfstellung im Erstellen der Wrapper-Library geben (zugegeben meine C++ Künste sind mittlerweile doch recht eingerostet)
c) Ich weiß zwar dass in HDEVINFO die ganzen Daten gespeichert werden, aber eine genau Spezifikation wie sie dort gespeichert werden konnte ich bislang nicht finden (also hinweise bezüglich der daten-strukte etc.)

Gruß, wonx

Anzeige

Grundsätzlich hast Du das alles richtig gesehen auch wenn da einige Anmerkungen zu machen sind.

1) LabVIEW kann sehr wohl mit structs umgehen, die entsprechen ganz einfach den LabVIEW Clustern. Aber es gibt dabei verschiedenen Dinge zu berücksichtigen: Erstens müssen die structs "flat" sein, also keine Pointer enthalten und zweitens musst Du auf das "Alignment" der Elemente in einer struct aufpassen. LabVIEW packt die Daten in einem Cluster immer und daher musst Du gegebenenfalls Füllbytes in einen Cluster einfügen um die Datenelemente auf die Alignmentgebegebenheiten der C struct anzupassen.

2) Ein HDEVINFO wie alle anderen Handles in Windows ist eine opaque Dateneinheit. Meist handelt es sich um einen Pointer auf einen Speicherbereich oder einen Arrayindex in eine Windows interne Resourceliste, aber das Format der Daten die dahinter stecken ist normalerweise nicht dokumentieret und kann auch zwischen Windows Versionen sehr stark unterschiedlich sein. Um mit diesem Handle etwas tun zu können musst Du entsprechende Windows APIs benützen.

3) Ein Windows Handle ist im wesentlichen eine 32Bit Zahl (unter Windows 64 Bit in den meisten Fällen eine 64 Bit Zahl) deren Wert für Dich als Anwender normalerweise grundsätzlich unwichtig ist (es gibt Ausnahmen, so gibt es APIs die im Fehlerfall ein NULL Handle oder manchmal auch 0xFFFFFFFF zurückgeben aber alle anderen Werte sind als gültige Handles anzusehen). Du kannst in der LabVIEW Call Library Node so ein Handle Parameter am Besten als 32 Bit unsigned Integer konfigurieren oder in LabVIEW 8.6 eventuel als Pointer sized Integer um für spätere Windows 64 Bit Versionen gewappnet zu sein.

Auf dem LAVA Forum gibt es jemanden der sich auch schon mit diesen APIs rumgeschlagen hat, mit einem Teilerfolg aber seine C Kenntnisse waren am Ende doch etwas unzureichend um das wirklich vollumfänglich hinzukriegen.

Rolf Kalbermatter

Hallo rolfk,

ich wollte mich noch für deine ausführliche Antwort bedanken. (wennauch etwas spät da ich zu dem damaligen zeitpunkt nicht dazugekommen bin und es hinterher total vergessen habe)

Was das ursprüngliche Problem betrifft musste ich mich dann leider doch auf unsere Jungs von der Abteilung Treiberprogrammierung verlassen da meine C++ Programmierkünste doch recht eingerostet sind. Zudem meinte der Hauptprogrammierer zu meinem Ansatz, dass sie es damals auf die gleiche Weise versucht haben und es sie 2 Monate gekostet hat bis sie merkten dass es so nicht funktioniert. Der Grund waren wohl irgenwelche auftretenden Fehler bei der Datenübergabe zwischen den Windows-Objekten...

Lange Rede kurzer Sinn, sollte noch Jemand vor dem selbigen Problem stehen: Dieser Ansatz scheint nicht zu funktionieren!

Gruß, wonx

Habe jetzt den Code so schnell nicht bei der Hand aber das geht grundsätzlich schon mit den APIs. Dass da wohl ein API sein kann das nicht ganz das macht was in der MSDN Dok steht glaube ich ohne Zweifel, aber ich habe für einen Treiber für eine eigene USB-I2C Karte mal auch sowas in der Art gemacht und das funktionierte nach etwas Grübelei und Gepröbel auch einwandfrei.

Zwei Monate waren das aber sicher nicht :-)

Rolf Kalbermatter