2017-01-16 1 views
0

Ich schreibe eine QT-Desktop-Anwendung, die Informationen anzeigen wird, die von einem seriellen Port empfangen werden. Daher wurde eine Klasse erstellt und in eine DLL gepackt, wobei Standard-Windows-API-Funktionen verwendet wurden, um mit dem verbundenen Gerät zu kommunizieren (CreateFile, ReadFile, WriteFile, ...).Kommunikation mit seriellen Anschlüssen in C++ mit Qt

Im Moment ruft ein Timer die DLL mit einer vordefinierten Rate [< 200ms] auf, was dazu führt, dass die GUI für kurze Zeit einfriert. Aus diesem Grund denke ich darüber nach, einen Thread zu verwenden, um den seriellen Port zu machen, der auch alles anzeigen wird.

Ist es besser, Threads für dieses Problem zu verwenden, oder sollte ich die Klasse neu schreiben, um das Arbeitsereignis basierend zu machen? Das Ziel ist, dass die GUI nicht einfriert.

Edit: Ich löste das Problem mit einer QThread abgeleiteten Arbeiterklasse mit einer überschatteten run() -Funktion, die die Kommunikation der seriellen Schnittstelle im Hintergrund behandelt und die GUI aktualisiert, sobald neue Informationen verfügbar sind.

+1

Gibt es einen Grund, [QSerialPort' nicht zu verwenden (https://doc.qt.io/qt-5/qserialport.html#details)? – Mike

+0

'QSerialPort' übernimmt bereits die asynchrone Kommunikation mit einem seriellen Port. Die Verwendung von Threads für eine solche Aufgabe funktioniert, wenn Sie nicht nur die GUI einfrieren wollen, sondern es ist ein Overkill. Der asynchrone Ansatz funktioniert besser mit Qt und ist viel wartungsfreundlicher. – Mike

+0

Als das Projekt gestartet wurde, wollten wir nicht qt verwenden. Also haben wir angefangen mit nur den Fenstern api – Aeonos

Antwort

0

In vielen Anwendungsfällen ist es üblich, alle blockierenden (synchronen) E/A auf einem separaten Thread auszuführen, insbesondere wenn es sich um eine grafische Benutzerschnittstelle handelt. Here's a page I've referenced in Bezug auf die Herausforderungen mit synchroner I/O (im Gegensatz zu asynchron, wo Ihr Code nicht blockiert, aber immer noch single-threaded oder parallel ist, wie Sie diskutieren). Es gibt mehr Probleme als nur das, was Sie angesprochen haben, zum Beispiel:

  • Was passiert, wenn keine Daten verfügbar sind? Blockiert die GUI, bis Daten vorhanden sind? Beispiel: Wenn der Absender ausgeschaltet war, waren keine Daten vorhanden
  • Was macht das Programm, wenn das E/A-Gerät nicht mehr verfügbar ist? Wenn es sich beispielsweise um einen USB-zu-Seriell-Adapter handelt, was passiert, wenn der Adapter nicht angeschlossen ist?
+0

Danke für den Artikel. es war sehr hilfreich. Ich werde std :: thread versuchen, um das Problem zu lösen. Wenn die Daten nicht verfügbar sind, gibt die DLL einen Fehler zurück und wird in der GUI protokolliert. Wenn es nicht angeschlossen ist, wird auch eine Fehlermeldung angezeigt. Ich habe mich vorher um diese Möglichkeiten gekümmert ;-) – Aeonos

+0

Wie andere Kommentatoren vorgeschlagen haben: Es gibt Standardmethoden, dies in QT zu tun, Sie sollten ihre Ansätze berücksichtigen. Der Link diskutiert nur die Paradigmen. Es sei denn, du versuchst nur Threading zu lernen, um Spaß zu haben. –

Verwandte Themen