[QT4] Programmdesign mit QThread

[methusalem]

Moin,

ich bin gerade dabei ein Programm zu schreiben, welches über eine USB Hardware 32 I/O Pins abfragt. Für die USB Hardware liegt mir eine Linux und eine Windows Bibliothek vor, die ich in einer eigenen C++ Klasse gekapselt habe. Ein Object dieser Klasse stellt also meine Hardware dar. Ich habe dort nun verschiedene Read und Write Methoden, um die Ports zu lesen bzw. zu schalten. Soweit so gut.

Mein Programm soll nun über diese Hardware per Lichtschranke Zeiten messen und auch LEDs und Readrelais schalten.

Meiner Meinung nach sollte dies alles nicht in der GUI passieren sondern in einen Thread ausgelagert werden. Ich stelle mir das so vor, das dieser Thread ein Signal an die GUI sendet, wann sich was an den Eingängen geändert hat. Was mit diesen Daten zu passieren hat, entscheidet dann wieder die GUI. Gleiches gilt für die Ausgänge. Entscheidet die GUI, das ein Ausgang geschaltet wird, sendet diese ein Signal an den Thread, der dann dies auf der Hardware umsetzt.

Da ich das hier noch sehr allgemein gehalten habe, folgende Frage: Geht das so wie ich das vorhabe? Oder mache ich einen grundlegenden Gedankenfehler? Wie würdet Ihr ein solches Problem angehen?

[uhu01]

Hy!

Meiner Meinung nach sollte das Problemlos funktionieren. Allerdings würde ich noch eine Klasse "zwischenschalten", da du, so wie du es beschrieben hast die Daten zweimal speichern müsstest, in beiden Threads einmal, da nur die Änderungen gesendet werden.
Machst du eine Klasse die die Daten speichert, diese Ändern lässt, und bei Änderung den anderen Thread benachrichtigt musst du diese zwar über einen Mutex schützen, bzw. sie muss sich selbst schützen. Die Daten sind jedoch nur einmal vorhanden, das Managen der Daten fällt einfacher.

mfg
uhu01

[methusalem]

Meiner Meinung nach sollte das Problemlos funktionieren. Allerdings würde ich noch eine Klasse "zwischenschalten", da du, so wie du es beschrieben hast die Daten zweimal speichern müsstest, in beiden Threads einmal, da nur die Änderungen gesendet werden.
Machst du eine Klasse die die Daten speichert, diese ändern lässt, und bei Änderung den anderen Thread benachrichtigt musst du diese zwar über einen Mutex schützen, bzw. sie muss sich selbst schützen. Die Daten sind jedoch nur einmal vorhanden, das Managen der Daten fällt einfacher.

Vielleicht ist es auch noch einfacher. Wenn der Thread, der von der Hardware liest, eine Änderung auf einem Port bemerkt, dann schickt er ein Signal raus, welches einen Zeitstempel, die Portnummer und den Status des Ports enthält. Wenn das passiert ist, kann er den Vorgang vergessen. Er muss also meiner Meinung nach keine Daten speichern. Da das ganze ja per Signal weggeht, dürften hier ja auch keine Daten verloren gehen. Die GUI arbeitet ja dann ein Event nach dem anderen ab.
Oder warum meinst du sollte der Hardware-Thread die Daten speichern?

[uhu01]

Hy!

...auch LEDs und Readrelais schalten.

Damit der Thread die Daten senden kann, muss er auch speichern welche Daten, ausser du sendest jedes Mal alle Daten die die LEDs und Relais betreffen durch den Slot.

PS: welches Gerät steuerst du an? Würde mich interessieren, da wir bei unseren Projekten momentan immer einen USB->seriell Konverterchip mit der entsprechenden Logik auf einem Board aufbauen, wäre vielleicht eine Alternative.

mfg
uhu01

[methusalem]

Damit der Thread die Daten senden kann, muss er auch speichern welche Daten, ausser du sendest jedes Mal alle Daten die die LEDs und Relais betreffen durch den Slot.

Jouu, so hab ich mir das vorgestellt! Spricht irgendwas dagegen, die Daten über den Slot in den Thread zu bringen. Ich brauch die Daten im Hardware-Thread später nicht mehr. Daher wollte ich mir das speichern dort sparen!

PS: welches Gerät steuerst du an? Würde mich interessieren, da wir bei unseren Projekten momentan immer einen USB->seriell Konverterchip mit der entsprechenden Logik auf einem Board aufbauen, wäre vielleicht eine Alternative.

Guckst du hier: http://www.codemercs.com

Die bauen gerade an einer neuen API. Aktuell ist die 1.4 herunterzuladen. Es soll aber demnächst eine 2.0 geben. Näheres dazu bei denen im Forum.