Help with QThread and Serialport
-
Hi all
I am new to Qthread and need a little assistance.
I have used the blockingmaster example project to base my serial communication program on.
I have a mainwindow that creates a QDialog which provides a GUI to initiate and detect an instrument connected to an unknown COM port. When QDialog is contructed, QDialog creates a thread which handles the serial port for me (as seen in blockingmaster example)
I use the dialog to look for available ports, list the port and set baud rate, I then query the instrument and confirm it is there and responding.
I want to then close this thread off when I click "accept" on my dialog and then start a new thread (as well as a new serialport object) in the mainwindow...
Or I want to pass control of the thread to mainwindow...
I cannot seem to stop the thread so that I can create a new serialport object in a new thread to take over the communication with that port....
Or should I create a global thread to be accessed by any class?
In the blockingmaster example, how would you sto the thread? thread.stop and thread.exit dont seem to work... As when I try to open that same serial port in another thread I get process error
Thanks
-
Hi and welcome,
You will need to post code, or we won't be able to help you.
That said, there is no (immediate) reason to move QSerialPort into its own thread if you use the non blocking api. Why do you want to use the blocking one, do you not have an Operating System on your target platform?
-
Hi both
Thanks for your prompt response, I only used the thread method as that is what is in the example....
Maybe it has led me down a stupid path?
A path a noob like me can't cope with!
Im an electronics engineer so maybe thread are best avoided where possible!
Shall I just crerate a non block serial port object in mainwindow?
-
Why did they use a thread in this example?
https://doc.qt.io/qt-5/qtserialport-blockingmaster-example.html
-
@millsey
ideally you would create your own class that manages the Serialport / data exchange ( don't do it directly in mainwindow.cpp )that way, once that is working as expected, you can still move it into its own thread, via very very few lines of code ;)
Why did they use a thread in this example?
because its the
blockingmaster example ;)take a look at the selection:
https://doc.qt.io/qt-5/qtserialport-examples.htmleverything asynchronous is your friend!
-
Hi
I would take a copy of
https://doc.qt.io/qt-5/qtserialport-terminal-example.html
and use as a base.
It has most things setup and even a dialog where you can set the serial parameters.Sadly you found the BLOCKING examples which just show how to use the blocking version of the API but
its actually not the recommended one as it hangs the GUI. But has it uses.Typically you would only use a thread with serialPort if you need to do heavy processing of the data you read.
Then a thread can be used to process the data while main thread (the gui) just reads it when it get the signal.-Im an electronics engineer so maybe thread are best avoided where possible!
Well that goes for most others too :) -
Hi all
I have another question which I can sure you can help with.
I have now implemented the recommended non -blocking QSerialport which works well, I’m happy I have COM ports working and I can send and receive data. I am also able to read until I see a carriage return and then parse the data where I need it.
I also need to add LAN connection to the same instrumentation, I will need to send and receive ASCII commands over LAN to the instrument. Can you recommend a good example project to base my communication on?
Thanks!
-
Am I correct in saying that the non-blocking “asynchronous” behaviour is primarily achieved by the program sending the command and kind of “forgetting it has sent it”.
You can then continue to use the GUI as you which.
The connect statement below is what “wakes up” the program to a received message from the connected device...
connect(m_serial, &QSerialPort::readyRead, this, &MainWindow::readData);
Am I right? The connect statement provides the means to achieve a non-blocking program?
Thanks!
-
Hi
Am I correct in saying that the non-blocking “asynchronous” behaviour is primarily achieved by the program sending the command and kind of “forgetting it has sent it”.
Not quite, its more about that the actual task is not happening right there meaning the cpu sort of like stays there until its finished versus it comes a nanosecond later in form of a signal.
And, whether its forgetting or not is up to you. you can track commands/data,
Hope this makes sense :)The connect statement below is what “wakes up” the program to a received message from the connected device...
Well the device is not sleeping as such. internally in QSerialPort its thread see some data and reads it and then signal to the app that there is data.
The connect "merely" binds a signal to a response functionAm I right? The connect statement provides the means to achieve a non-blocking program?
yes as its based on signals. so you don't hang around in your app waiting for data. you get signal when something is ready and handle that there. and that is what “asynchronous” is mostly about.
-
Hi @millsey,
I also need to add LAN connection to the same instrumentation, I will need to send and receive ASCII commands over LAN to the instrument. Can you recommend a good example project to base my communication on?
You didn's specify the protocol that is used here, so probably QTcpSocket might fulfill your needs.
Regards
-
