Erkennen, dass der I2C Dongle abgezogen wurde

[StefanP]

Guten Tag,

welche Methode ist sinnvoll, um einfach zu erkennen, ob der I2C Dongle abgezogen wurde? Möglichst ohne in die Tiefen des USB Protokollstacks vorzudringen.

Einfach zyklisch z.B. die ProductID abfragen und bei einem Fehler von einem Disconnect ausgehen?

Gruß
Stefan

[friend-of-rq]

Hallo StefanP,

ich mach das im IOW-SocketServer über das WindowsMessage

Code: Select all

-----
OnMessage = Message
-----
declare sub Message(Hwnd as integer, Msg as integer, wParam as integer, lParam as integer)
-----
sub xxtest
   rem ... Hwnd as integer, Msg as integer, wParam as integer, lParam as integer
   changeDEV = wParam
end sub

Wenn sich was am USB geändert hat, ist changeDEV <> 0

Zusätzlich prüfe ich vor jedem IOW-DLL-Zugriff auf changeDEV = 0 ab.

Leider kann ich nicht im RQ erkennen ob ein IOW zu/ab gesteckt wird,sondern nur das sich was generell am USB-Port geändert hat ... ich warte dann eine kurze Zeit und führe dann ein ReOpen der DLL durch, erst dann erkenne ich ob sich eine Änderung im Bezug auf IOW getan hat.

Gruss Ralf

[Christoph Jung]

Wie friend-of-rq schon geschreiben hat gibt es entweder die WindowsMessage WM_DEVICECHANGE, die alles Änderungen am USB, CD und DVD erkennt oder Eine Timerfunktion, die alle X Sekunden schaut ob der Dongle noch da ist. Ich würde aber die WM_DEVICECHAGNE-Option wählen, da die etwas schonender mit den Systemresourcen umgeht. Einfach mal nach WM_DEVICECHANGE googlen, da gibt es unmengen an Beispielen.

[StefanP]

Danke für die Antworten. Nun habe ich also mehrere Möglichkeiten.

Schönes Wochenende
Stefan

[friend-of-rq]

siehe :
Geräte kommen und gehen
hätte ich auch gerne so gemacht nur im LParam wird ein IOW Wechsel nicht eindeutig angezeigt ...

[Wolf]

Unter Linux und mit Qt klappt das schon lange so:
An jeder Stelle im Programm, wo vom IOW gelesen wird, wird der Fehlercode abfangen.

#include <errno.h>
....
bytes = IowKitReadNonBlocking(ioHandle, IOW_PIPE_IO_PINS,(PCHAR) rep40, IOWKIT40_IO_REPORT_SIZE );
if (errno == ENODEV) // 19 /* No such device */
{
printf("IOW_IO::getPortStatus40 - IOWarrior40 getrennt!\n");
emit IOW_disconnected();
}

Nach dem Trennen wird ein Timer gestartet der seinerseits (z.B. alle 200 ms) eine Methode aufruft, die versucht den IOW wieder zu öffnen - wenn das erfolgreich war, wird der Timer gestoppt und weiter gehts wie vorher. Mit dem IOW 24 geht das natürlich genau so ;-)
Unter Windows sollte das doch mit GetLastError nach dem Lesen zumindest sehr ähnlich funktionieren, oder?

[Christoph Jung]

Ja es funktioniert schon, allerdings kann man nicht sehen, obs ein IO-Warrior ist oder halt irgend was anderes.
Der IO-Warrior fällt mehr oder weniger durchs Raster, da er halt kein Eingabegerät oder Datenträger ist. Windows erkennt nur das sich was geändert hat und sendet halt seine Nachricht ab. Aber das reicht ja im Prinzip schon, da man dann da eine Routine laufen lassen kann die die IO-Warrior sucht und abgleicht ob einer Neu oder Weg ist.

[Wolf]

Wenn ich das richtig verstehe, geht es doch darum, während der Laufzeit eines Programmes zu erkennen, ob der IOW abgezogen wurde, oder? Dein Programm weiß doch aber immer, welches Gerät es geöffnet hat. Ergo sind doch alle anderen Sachen die am USB hängen doch völlig egal. Ich habe mehrere verschieden IOWs für verschiedenste Anwendungen gleichzeitig im Einsatz. Bei allen Anwendungen wird eigentlich immer irgendwie der Status "gepollt". Dabei kann man doch mit der obigen Methode prima feststellen, ob ein IOW abgezogen wurde und darauf reagieren. Wo ist eigentlich genau das Problem?

[friend-of-rq]

@Wolf

Und wie erkennst Du so ob ein neuer unbekannter IOW hinzu gekommen ist ?

oder ob ein IOW entfernt wurde den Du gerade nicht verwendest(pollst) ?

z.B. bei meinem IOW-Socket-Server weiss ich nicht vorher mit welchen IOWs dieser zu tun hat.
Jeder IOW der am System an/ab gesteckt wird erkannt und in den Server durch ein ReOpen eingebunden. Ist ein IOW der angesteckt wurde dem Server bekannt, werden gespeicherte DEFAULT-Werte geladen und der IOW damit initialisiert. Die angeschlossenen Clients werden über die IOW-Änderungen am USB informiert.

[friend-of-rq]

Ich habe mehrere verschieden IOWs für verschiedenste Anwendungen gleichzeitig im Einsatz.

Wie machst Du denn das auf einem PC ... die aktuelle DLL(1.5) kann doch nur von einem Programm verwendet werden ?!

Oder verwendest Du noch die DLL 1.4 und musst somit auf den echt tollen IOW56 verzichten.

[Wolf]

Und wie erkennst Du so ob ein neuer unbekannter IOW hinzu gekommen ist ?
...
Wie machst Du denn das auf einem PC ... die aktuelle DLL(1.5) kann doch nur von einem Programm verwendet werden ?!

Oder verwendest Du noch die DLL 1.4 und musst somit auf den echt tollen IOW56 verzichten.

Ich verstehe jetzt nicht wirklich, was Du meinst.
DLL's gibt es auf meinem PC nicht, da ich mit Linux arbeite. Dort heißen die Bibliotheken libiowkit.a (statisch) bzw. libiowkit.so (dynamisch) - verwendet wird die Version 1.5. Dabei kommen IOW24, IOW40 und IOW56 zum Einsatz - je einer pro Programm. Selbstverständlich funktioniert das zeitgleich. Wäre dem nicht so, dann wäre es ja auch sinnlos, feststellen zu wollen, ob ein neuer IOW hinzugekommen ist, oder? Letzteres "erkennen" meine Programme natürlich auch: Wird ein Programm gestartet, ohne daß der zugehörige (wird über Typ und Seriennumer geprüft) IOW bereits angeschlossen ist, wird zunächst das GUI aufgebaut und ein Timer gestartet, mit dessen Hilfe versucht wird das entsprechende IOW-Objekt anzulegen (im Konstruktor wird der IOW geöffnet). Sobald das nicht fehlschlägt, wird der Timer gestoppt und los gehts. Funktioniert prima. Was soll daran falsch sein?
Ganz kleines Beispiel mit zwei Demo-Progrämmchen:


Oder reden wir hier völlig aneinander vorbei?

[friend-of-rq]

@Wolf

Oder reden wir hier völlig aneinander vorbei?

so sieht aus ...
Da merkt man das Linux gegenüber Windows einige vor teile hat, unter Windows benötigt man die besagte DLL und die kann nur von einem Programm verwendet werden.