Eigene Klasse für USB-Zugriff soll Event erzeugen

[Alloc]

Hi,

hab hier mal wieder ein Problem
Ich habe eine eigene Klasse geschrieben, welche den Zugriff auf ein USB-Gerät (FT232RL-Chip) verwaltet. Funktioniert auch alles. Jetzt will ich aber, dass diese Klasse ein Event hat, welches dann ausgelöst wird, wenn Daten *empfangen* werden. Die USB-DLL liefert dafür natürlich kein Event, das heisst ich müsste irgendwie innerhalb der Klasse regelmäßig den Zustand des Empfangspuffers abfragen. Hab mir schon überlegt das über einen Timer zu machne, welchen ich in der Klasse erzeuge, das kommt mir aber relativ unschön vor ... Eine weitere Idee wäre, einen endlos-Thread in der Klasse zu erzeugen, bin mir aber auch hier nicht sicher, dass das das beste wäre.

Wie kann ich das ganze am Besten machen?

Grüße,
Chris

[Robert Marquardt]

In meiner HID-Komponente (Teil der JVCL oder als Standalone von http://www.soft-gems.net/HID.php) mache ich das mit einem Thread.
Setzt man den Event, so wird der Thread gestartet der dann permanent liest. Es wird dann ein Event im thread generiert, der natuerlich synchronisiert werden muss.

Ein Timer ist nicht nur unschoen, sondern komplett ungeeignet.

[oki]

Hi,

schreibe einen sogenannten Eventhandler der als Thread ausgelegt ist. Mit erzeugen eines Handle auf den USB-Port startest du diesen Thread, der permanent den Zustand des empfangspuffers abfragt und Änderungen nach "oben" reicht. Wie alloc sagt, syncronisieren nicht vergessen. Als Ereignis creierst du eine eigene Methode wie z.B. OnReceiveEvent ....

In dieser Form werden eigentlich alle üblichen klassen die schreib- leseereignisse handeln aufgebaut.

gruß oki

[Alloc]

Danke schonmal an euch beide für eure Antworten =)

Zitat von Robert Marquardt:

Es wird dann ein Event im thread generiert, der natuerlich synchronisiert werden muss.

Was genau bedeutet dabei das "synchronisieren"?
Und muss ich beim Thread irgendwas beachten? Also zB Sleeps einbauen, damit der nicht mit der Endlosschleife die CPU auffrisst?

Gruß,
Chris

[oki]

Hi alloc,

ja, syncronisieren mit:
procedure Synchronize(Method: TThreadMethod); Die Delphi-Hilfe erklärt das was und wie und warum sehr gut.

Im Execute macht sich ein Sleep(10) in der Schleife immer gut.

Gruß oki

[Alloc]

K, danke, es funktioniert wie ich mir das vorgestellt habe

Gruß,
Chris

[Robert Marquardt]

Das mit den Sleeps kommt auf die Lesefunktion an. Du erwaehnst das du ein von der DLL exportierte Read-Funktion verwendest (zumindest implizierst du es).
Das duerfte ein blockierendes Read sein, d. h. der Aufruf kommt erst zurueck wenn Daten angekommen sind (und hoffentlich auch wenn das Geraet ausgesteckt wird).
Damit hast du natuerlich ein Problem den Thread wieder zu beenden, denn er haengt ja in der Read-Funktion fest.

In meiner HID-Komponente ist das mit ReadFileEx und SleepEx geloest.
ReadFileEx kommt gleich zurueck und dann wird mit SleepEx gewartet bis bis der asynchrone ReadFileEx-Aufruf Daten liefert.
SleepEx bewirkt das der Thread regelmaessig aufwacht und damit beendbar ist.

[Alloc]

Die DLL exportiert auch eine Funktion mit der man den Queue-Status abrufen kann und somit wird nur dann die Read-Funktion aufgerufen, wenn auch was zum Lesen vorhanden ist. Sollte also hoffentlich keine Probleme bereiten =)

Chris

[Robert Marquardt]

Na dann hat der Thread einfach eine while not Terminated-Schleife in der er mit Sleep ein bischen schlaeft, den Queue-Status abfragt und bei Daten den Event ausloest.
Das muss man machen damit der Thread nicht zuviel Rechenzeit verballert. Das Sleep muss so abgewogen werden das man oft genug Daten bekommen kann, denn man kann sie dann nur noch im Sleep-Raster bekommen.
Natuerlich sollte man die queue immer komplett leerlesen und eventuell mehrere Events ausloesen, sonst laeuft die Queue moeglicherweise voll.

[Alloc]

Jo, genau so läuft es jetzt auch. Sind nur so 5 Code-Zeilen oder so im Execute
Allerdings ist das Leerlesen des Buffers Anwender-Prog-Sache. Dh das Event meldet nur dass Daten da sind und wieviele und das Prog muss die dann abholen (so macht es zb auch CPort).

Chris