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:

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:

Delphi-Quellcode:

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 :lol:

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 :D
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

[Alloc]

Hi Robert,

hätte noch eine Frage bezüglich deiner HIDController-Klasse:
Du hast in deinem Thread ja eine extra Prozedur DoData, die nur die Evnet-Prozedur aufruft, also ungefähr sowas:

Delphi-Quellcode:

procedure DoData;
begin
  Parent.FData(...);
end;

procedure Execute;
begin
...
  Synchronize(DoData);
...
end;

Kann man da stattdessen auch einfach

Delphi-Quellcode:

procedure Execute;
begin
...
  Synchronize(Parent.FData(...));
...
end;

schreiben?

Gruß,
Chris

[Robert Marquardt]

Keine Ahnung. Probier es aus. Ich habe mich einfach an die Delphi-Hilfe gehalten.

[Alloc]

Funktioniert leider nicht ... hätte mir so gerne die 4 Zeilen Code gespart ;)

[Robert Marquardt]

Viel interessanter ist das Redesign das ich gerade im Kopf habe. Die Reports als eigene Klasse abspalten.
Das wird jetzt aber off-topic. Schreib mir unter robert_marquardt att gmx dott de

[DerDan]

Hört sich alles ganz interessant an.

Gibt es diese Klasse für den FT232RL-Chip als Download?


ich hab vor kurzem versucht einen FT232BM Chip im BitBang Mode zu betreiben, leider war die erreichte Transferleistung enttäuschend.


ich hab einfach die "FTD2XX.H" mit c2pas32 umgesetzt, von Hand korrigiert und die Funktionen quasi low-level angesprochen. Wie gesagt hat alles funktioniert aber eben langsam.

mfg


DerDan

[Alloc]

Hi DerDan,

hab ehrlich gesagt noch nie wirklich rausgefunden was dieser "BitBang"-Modus eigentlich ist :D
Aber die Klasse wollte ich eigentlich eh an FTDI senden wenn sie bereit zur Veröffentlichung ist (atm ist nur das Implementiert, was ich hier für ein Projekt brauche, also ListDevices, OpenByDescription, Einstellungen setzen, Read/Write).

Aber wenn du willst kann ich sie dir heut nachmittag schonmal schicken. Schreib mir einfach ne Mail an [e-mail].

Chris

[Robert Marquardt]

Ich antworte da erst mal privat.