QextSerialPort et le multithreading avec QThread

Version imprimable

17/10/2010, 13h00
neoirto

QextSerialPort et le multithreading avec QThread

Bonjour à tous,

Je cherche à intégrer qextserialport à une GUI.

Je pense donc à un thread de qextserialport qui devra :
- surtout pouvoir lire sur le port COM (et par la suite écrire) en continu ce que lui envoie un matériel embarqué,
- parser le contenu
- produire des signaux conditionnels personnalisés afin de reveiller le thread principal.

J'ai suivi des tats de tutos et les exemples de qextserialport, que j'ai bien réussi à compiler, mais maintenant que je dois intégrer un thread de qextserialport par moi même, je dois dire que je sèche un peu.

Je précise que je suis débutant en Qt C++, mais pas en programmation.

Merci d'avance pour vos réponses !
17/10/2010, 23h52
yan

Salut.
qextserialport n'as pas un fonctionnement asynchrone?
18/10/2010, 00h18
neoirto

Merci de ta réponse Yan,

En fait, j'ai vu dans un des exemples de qextserialport (qespta) que la lecture continue sur le port était effectuée par un Qthread.

J'ai essayé de modifier par moi-meme cet exemple pour l'intégrer dans une GUI Qt du thread principal. J'arrive à récupérer le flux du port COM, mais je dois avoir un bug, car j'ai un usage processeur à 56% (un des threads doit etre planté...).

Ca ne semble pas idiot de procéder avec un thread comme dans l'exemple, car j'aurai des algos qui pourront prendre un peu de temps dans le thread principal (calculs 3D...), et je voudrai que le parsage se fasse en continu sur l'autre thread.
Mais je ne sais pas dans quel ordre déclarer tous ces modules (d'ou le bug je pense) :

- Thread lecture port COM + parsage,
- Thread principal contenant :
o Interface graphique Qt (Boutons, affichage de graphiques des données du port COM par exemple (mais ce sera un autre post !)),
o Fenêtre Ogre mise à jour à partir des données du port COM

Qu'en pensez-vous ?
18/10/2010, 09h32
yan

Citation:

Envoyé par neoirto

Qu'en pensez-vous ?

Si qextserialport as un fonctionnement synchrone il te faut un thread.

Ce que tu propose est bien. Pour faire transiter les info entre tes threasd, je te conseil d'utiliser les signal/slot (sans pointeur en paramètre). Car ceci te permet d'avoir un fonction quasi sans risque. Y as des exemplse dans la doc de Qt (leur serveur de doc étant en rade je ne peux pas te donner les liens pour l'instant).

Si qextserialport le permet tu pourrais éviter d'implémenter un thread. Regarde ces documents :
http://qt-labs.developpez.com/#thread

Ok, alors je progresse un peu...

Désormais je crois mon thread lecture sur le port COM commence à fonctionner correctement. Mais je n'arrive pas à déclarer mes propres SIGNALS et SLOTS. Et surtout je ne sais pas comment y accéder depuis mes autres threads.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
class SerialThread: public QThread
{
	QextSerialPort * port;
 
 
	protected:
		virtual void run()
		{
 
			int compteur_sans_com = 0;
 
			qDebug("THREAD lecture COM : %i", (int)currentThreadId());
 
			QextSerialPort * port = new QextSerialPort("COM6", QextSerialPort::EventDriven);
 
 
			while(1){
 
				/////////// si le port est ouvert, on lit les données :
				if( port->isOpen() ){
 
 
				Sleep(DELAI_lecture_port_COM); //////// pour eviter de surcharger ce thread et donc laisser les autres threads travailler
 
				char data[4096];
 
				int bytesRead = port->read(data, 4096);
				data[bytesRead] = '\0';
 
					////////////// si on a recu qq chose :
					if( bytesRead > 0 ){
					qDebug("%s ## %i", data, (int)currentThreadId());
					// qDebug(" %i", (int)currentThreadId());
					} else {
					qDebug("RIEN %i", compteur_sans_com);
 
						if (!(port->lineStatus() & LS_DSR)) {
 
							compteur_sans_com++;
 
							if( compteur_sans_com > NBR_sans_com_before_reopen_COM6 ){
							compteur_sans_com = 0;
							qDebug("On referme le port COM !!!");
 
							port->close();
 
							Sleep(10);
							}
 
 
						}
 
					}
 
				} else {
 
							port = new QextSerialPort("COM6", QextSerialPort::EventDriven);
							port->setBaudRate(BAUD9600);
							port->setFlowControl(FLOW_OFF);
							port->setParity(PAR_NONE);
							port->setDataBits(DATA_8);
							port->setStopBits(STOP_2);
							port->open(QIODevice::ReadWrite);
							port->setTimeout(500);
							qDebug("On essai de reouvrir !! ");
 
 
							Sleep(5000); ////////// la negociation avec le materiel peut prendre du temps 
 
				}
 
			}
 
		}
 
 
 
	signals:
	  // Émet un entier
	  void unEntier(int);
 
 
 
	public slots:
 
      void close_COM()
      {
          qDebug("demande fermeture port com !!!");
		  port->close();
      }
 
 
}; 
 
 
 
 
 
 
int main(int argc, char *argv[])
{
 
	int exec;
 
	QApplication app(argc, argv);
    //redirect debug messages to the MessageWindow dialog
	qInstallMsgHandler(MessageWindow::AppendMsgWrapper);
 
	MainWindow mainWindow(APP_TITLE);
	mainWindow.show();
 
 
	qDebug("THREAD MAIN : %i", (int)QThread::currentThreadId());
 
	// SerialThread * thread = new SerialThread(port);
	SerialThread * thread = new SerialThread();
	app.connect(thread, SIGNAL(finished()), & app, SLOT(quit()));
 
 
 
 
    QPushButton BOUTON_CLOSE_COM("Fermer COM");
    BOUTON_CLOSE_COM.resize(75, 30);
    BOUTON_CLOSE_COM.setFont(QFont("Times", 15, QFont::Bold));
 
    app.connect(&BOUTON_CLOSE_COM, SIGNAL(clicked()), thread, SLOT(close_COM()));
 
	BOUTON_CLOSE_COM.show();
 
	thread->start();
 
 
	exec = app.exec();
 
	return exec;
}

Par exemple je n'arrive pas à executer le slot close_COM depuis BOUTON_CLOSE_COM.

Et comment est-ce que je dois faire pour declencher le slot depuis ma classe
MainWindow please ?

Merci d'avance !

18/10/2010, 17h04
yan

Si tu commence avec Qt, je te conseil de commencer par les tuto ou du moins de faire un tours rapide :
http://qt.developpez.com/tutoriels/introduction-qt/

Sinon, regarde ces deux liens :
http://qt.developpez.com/faq/index.p...ots#signalslot
http://qt.developpez.com/faq/index.p...ECT-moc-header
18/10/2010, 18h25
neoirto

Il est vrai que je débute... Je sais que c'est pas marrant de repondre à des questions de base... Désolé Yan.

Donc pour éviter de passer pour un gros lourdot, bien sur, j'ai deja lu (ou au moins parcouru) la plupart des tutos avant de vous adresser mes questions. Mais l'architecture Qt reste quand meme assez obscure pour moi. D'ou mes questions de gros debutant !

Comme tu viens de me le conseiller, je viens d'essayer d'ajouter :

Code:

#include "main.moc"

Juste derriere la declaration de ma classe sans .h, mais le compilateur n'apprécie pas des masses :

Code:

main.cpp:121:101: error: main.moc: No such file or directory

Je dois éditer mon .pro ?

Je pédale dans le yaourt !
18/10/2010, 19h52
yan

Citation:

Envoyé par neoirto

. Mais l'architecture Qt reste quand meme assez obscure pour moi. D'ou mes questions de gros debutant !

y as pas de problème t'inquiète. Qt n'est pas aussi simple au début ;)

En faite il te manque Q_OBJECT dans ta classe.
18/10/2010, 20h07
neoirto

Merci, j'apprécie beaucoup ton aide !

Je comprends entre les lignes que comme ce n'est pas un objet qt valide à part entière, je ne peut pas utiliser les slot / signal ??

Bon je creuse cette piste, et je reviens vers toi si je tombe sur le fond du pot (de yaourt).

Merci encore ;)
18/10/2010, 20h39
yan

Citation:

Envoyé par neoirto

Je comprends entre les lignes que comme ce n'est pas un objet qt valide à part entière, je ne peut pas utiliser les slot / signal ??

Ben c'est une des base de Qt... C'est pour cela que je t'ai dit de regarder les tuto.
EN gros raccourcie, Q_OBJECT permet de spécifier au moc que tu va déclarer des signal/slot.
Pour plus de détaille, regarde :
http://louis-du-verdier.developpez.com/qt/fondations/
18/10/2010, 22h57
neoirto

Oui, effectivement, c'est plus clair. Je suis passé à coté apparemment...
Merci encore

Bon, je ne suis toujours pas sorti d'affaires avec ces histoires d'heritages...

J'essaie d'hériter de Qwidget et de Qthread pour afficher une fenetre Opencv désormais. J'ai donc dans mon .h :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 class QOpenCVWidget : public QWidget, public QThread // class QOpenCVWidget : public QWidget { // Q_OBJECT // ca ne compile pas si j'ajoute ca... private: QLabel *imagelabel; QVBoxLayout *layout; QImage image; CvCapture * webcam; public: QOpenCVWidget(QWidget *parent = 0); ~QOpenCVWidget(void); void run(); void putImage(IplImage *); QImage getImageLabel(); };
Et dans le .cpp :
Code:

1 2 3 QOpenCVWidget::QOpenCVWidget(QWidget *parent) : QThread(parent), webcam(0) { ... }
Et ca compile, sans planter quoique ce soit.
Par contre lorsque je fais appel à QThread::start(); la fonction run(); s'exécute une fois... Et quitte aussitot !

J'ai beau chercher, je crois que j'ai besoin d'un sérieux coup de main !

Merci d'avance ;)

25/10/2010, 22h15
yan

Citation:

Envoyé par neoirto

J'essaie d'hériter de Qwidget et de Qthread

:weird: Là tu fait fausse route....
pourquoi tu cherche à faire cela???

Et bien j'ai besoin d'afficher dans un Qwidget le resultat d'un thread Opencv.

A la fin du script du Thread, le resultat est un QPixmap il me semble (voir ci dessous).

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 layout = new QVBoxLayout;
 
 
    imagelabel = new QLabel;
    QImage dummy(100,100,QImage::Format_RGB32);
    image = dummy;
    layout->addWidget(imagelabel);
    for (int x = 0; x < 100; x ++) {
        for (int y =0; y < 100; y++) {
            image.setPixel(x,y,qRgb(x, y, y));
        }
    }
    imagelabel->setPixmap(QPixmap::fromImage(image));
 
    setLayout(layout);

Tu vois une autre facon de faire ?

26/10/2010, 09h33
yan

Tous ce qui est IHM et QPixmap ne doivent pas être manipuler par un thread autre que le principale.

Si tu as réellement besoin de faire un thread pour OpenCV fait une classe à part et exploite QImage dans ce thread.
A chaque résultat emet un signal avec le QImage et créé un slot dans ta widget qui recevra cette QImage.

Mais l'utilité du thread dépend de ce que tu veux faire
26/10/2010, 12h24
neoirto
Ok, je vois

Mais alors, si la Qimage sera bien créé par un thread à part, l'intégration de cette Qimage sera effectuée par mon thread principal, non ?

Donc le code :
Code:

1 2 imagelabel->setPixmap(QPixmap::fromImage(image)); setLayout(layout);
sera executé par le thread principal, non ?

Tu dis qu'il faut toujours manipuler les QPixmap par un autre thread : pour des raisons de performances ? J'ai effectivement constaté que cela faisait ramer tout mon programme, sans que le processeur soit saturé, ce que j'ai du mal à comprendre.

Y a t il une autre facon d'intégrer des Qimages que QPixmap, et qui serait donc plus performante ?

Merci de ton aide !
26/10/2010, 12h29
neoirto

A ok, je viens de relire ta réponse :

Code:

Tous ce qui est IHM et QPixmap ne doivent être manipuler par un thread autre que le principale.

C'est pourtant clair, c'est du français, mais j'avais compris l'inverse, sorry !!!:oops:
26/10/2010, 13h35
yan

Citation:

Envoyé par neoirto

du français, mais j'avais compris l'inverse, sorry !!!:oops:

arf, sans le pas c'est plus difficile à comprendre... dsl
pourtant je fais souvent attention à ne pas l'oublier

Bon alors j'ai encore tout faux... Gasp

Pour l'instant j'ai réduit le thread à sa plus simple expression :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
#ifndef QOPENCVWIDGET_H
#define QOPENCVWIDGET_H
#include <QThread>
#include <cv.h>
#include <highgui.h>
#include <QImage>
 
 
class QOpenCVWidget : public QThread 
{
 
	Q_OBJECT
 
    public:
        QOpenCVWidget( QObject * parent = 0 );
        ~QOpenCVWidget();
        void run();
 
    signals:
    void Emit_frame_webcam( QImage image_a_envoyer );
 
    private:
        QImage image;
		CvCapture *webcam;
 
}; 
 
#endif

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
QOpenCVWidget::QOpenCVWidget( QObject *parent ) 
	: QThread( parent ) 
{
}
 
 
QOpenCVWidget::~QOpenCVWidget() {
}
 
void QOpenCVWidget::run()
{
		Sleep(1000);
}

Et j'obtiens l'erreur suivante :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
obj/QOpenCVWidget.o: In function `QOpenCVWidget':
C:\CODE\CODEBLOCKS\TEST_QT\ogre_qt_test_2/QOpenCVWidget.cpp:7: undefined referen
ce to `vtable for QOpenCVWidget'
C:\CODE\CODEBLOCKS\TEST_QT\ogre_qt_test_2/QOpenCVWidget.cpp:7: undefined referen
ce to `vtable for QOpenCVWidget'
obj/QOpenCVWidget.o: In function `~QOpenCVWidget':
C:\CODE\CODEBLOCKS\TEST_QT\ogre_qt_test_2/QOpenCVWidget.cpp:48: undefined refere
nce to `vtable for QOpenCVWidget'
C:\CODE\CODEBLOCKS\TEST_QT\ogre_qt_test_2/QOpenCVWidget.cpp:48: undefined refere
nce to `vtable for QOpenCVWidget'
C:\CODE\CODEBLOCKS\TEST_QT\ogre_qt_test_2/QOpenCVWidget.cpp:48: undefined refere
nce to `vtable for QOpenCVWidget'

26/10/2010, 14h33
yan

http://qt.developpez.com/faq/index.p...ore#linkvtable
;)
Tu utilise code block? tu devrais essayer QtCreator.
26/10/2010, 15h08
neoirto

En fait, je n'arrive pas à compiler avec CODEBLOCKS, donc je le fais manuellement.

Et donc, il suffisait de lancer un qmake... Pfff, parfois ca tient à pas grand chose quand meme !!

Merci de ton aide, je galere encore un peu à la deconstruction, mais ça tourne !
26/10/2010, 15h33
yan

Citation:

Envoyé par neoirto

En fait, je n'arrive pas à compiler avec CODEBLOCKS, donc je le fais manuellement.

C'est pour cela que je te conseil QtCreator. C'est assez proche de code::block et c'est adapté à Qt
26/10/2010, 16h09
neoirto

Oui, il faut que je regarde ca...

J'ai encore une question d'ordre plus générale concernant les Qthread. J'ai un pentium E5300 2 cores.

Lorsque je crée 2 threads, le systeme les reparti un dans chaque thread ?

Et lorsque j'ai admettons 4 threads, c'est l'hyperthreading qui prends le relai c'est ca ?

Jusqu'à combien de thread peut-on monter raisonnablement en pouvant attendre un bénéfice sur les perfs ?
26/10/2010, 16h16
yan

Citation:

Envoyé par neoirto

Lorsque je crée 2 threads, le systeme les reparti un dans chaque thread ?

Pas forcement... C'est l'OS qui décide. Il me semble qu'il peut même switcher l’exécution du thread entre les deux proc suivant le besoin.

Citation:

Et lorsque j'ai admettons 4 threads, c'est l'hyperthreading qui prends le relai c'est ca ?

pareil

Citation:

Envoyé par neoirto

Jusqu'à combien de thread peut-on monter raisonnablement en pouvant attendre un bénéfice sur les perfs ?

Tous dépend de ce que tu fais... Il n'y as pas de réponse.

Citation:

Envoyé par yan

Je pense qu'il y as deux cas
1- Faire fonctionner plusieurs objet en parallèle.
* Si leur exécution bloque le thread, il faut faire un thread pour chaque objet.
* S'ils exploitent l'eventloop de Qt, tu peut créer un nombre restreins de thread et répartir leurs exécution sur ces threads.

2- Pour la rapidité.
Il faut savoir que chaque therad utilisé va ajouter du temps sur l’exécution de la tâche... Pour faire simple
* T le temps d'une tâche.
* t le temps ajouté par l'utilisation d'un thread.
* N nombre de thread.
Donc quand on exécute la tâche sur N threads, elle est en réalité exécuté en T+N*t. Mais comme ils sont N le temps d'un points de vue utilisateur est T / N + t.
Si on utilise trop de thread que va t'il se passer? t va augmenter et à un moment on aura T < T / N + t
Donc on aura rien gagner et même perdu.

Quand on parle de perf, en principe le nombre de thread ne devrait pas dépasser le nombre de coeur.
26/10/2010, 16h49
neoirto

Ok, donc il ne faut pas abuser des bonnes choses, c'est pigé... Et assez logique en fait.

Sinon, autre question (promi après j'arrete !) :
Les données transitants sur les SIGNAL / SLOT sont libérées de la mémoire automatiquement ?
Parce que j'ai l'impression que mes Qimage font gonfler la RAM en laissant le programme tourner ?
26/10/2010, 17h02
yan

Citation:

Envoyé par neoirto

Les données transitants sur les SIGNAL / SLOT sont libérées de la mémoire automatiquement ?

En principe oui.
Peut tu montrer la signature de ton emit et de ton slot?

Voila :

Le .h :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 class QOpenCVWidget : public QThread { Q_OBJECT public: QOpenCVWidget( QObject * parent = 0 ); ~QOpenCVWidget(); void run(); void putImage(IplImage *); signals: void Emit_frame_webcam( QImage image_a_envoyer ); private: QImage image; CvCapture *webcam; // private slots: // void close_COM(); };
Le slot :
Code:

1 2 3 4 5 void recoit_Qimage_Opencv( QImage FRAME_webcam ) { //////// ds un slot : imagelabel->setPixmap(QPixmap::fromImage(FRAME_webcam)); }
Que j'appelle avec :

Code:

emit Emit_frame_webcam( image );

La RAM gonfle tres lentement, car la résolution de la WEBCAM est limitée, mais si je commente :

Code:

// imagelabel->setPixmap(QPixmap::fromImage(FRAME_webcam));

...dans le slot, ca ne gonfle plus (la vidéo ne s'affiche plus egalement ce qui n'est pas exactement l'effet recherché !)

Merci de ton aide ;)

26/10/2010, 17h23
yan

Citation:

Envoyé par neoirto

La RAM gonfle tres lentement

c'est à dire?
es ce que tu as essayé de voir si elle ne stagne pas au bout d'un moment?
26/10/2010, 17h44
neoirto

Et bien la RAM passe de 76 Mo à 80 en 5-10 minutes, de facon très progressive, et apparemment, ça ne s'arrete pas en route !

Alors que quand je commente la ligne citée, ca reste stable à 76 ??!!
26/10/2010, 20h39
yan

Citation:

Envoyé par neoirto

Et bien la RAM passe de 76 Mo à 80 en 5-10 minutes, de facon très progressive, et apparemment, ça ne s'arrete pas en route !

Alors que quand je commente la ligne citée, ca reste stable à 76 ??!!

Il faut se méfier de cette mesure. Pour l'instant je dirais pas que tu as une fuite. Si tu était monté au dessus de 1Go je dit pas mais là ça me semble plutôt normale.
26/10/2010, 22h31
neoirto

Bon !

Et bah je suis content d'être étanche ! Merci pour ton aide. Je crois que je peux passer en [Résolu]. Si je m'aperçois que je prends l'eau, ca sera un autre topic...

Moulte gratitude :ccool: