Help with QThread and Serialport

millsey

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

jsulm

@millsey Why do you need threads? QSerialPort has an asynchronous API.

J.Hilk

@millsey

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?

millsey

@J-Hilk

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?

millsey

Why did they use a thread in this example?

https://doc.qt.io/qt-5/qtserialport-blockingmaster-example.html

J.Hilk

@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.html

everything asynchronous is your friend!

mrjj

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

millsey

thank you all!

I will check it out

millsey

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!

millsey

@mrjj

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!

mrjj

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 function

Am 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.

millsey

Ok thanks so much for the response

I am still not comfortable how these connect signals work when passing messages between different classes so I need to do some background reading on those.

Thanks

aha_1980

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

millsey

@aha_1980

Hi there

Sorry, iPv4 :-)

millsey

Hi guys

One other question about QSerialport

Is the best way to implement a timeout without blocking the GUI to start a thread timer which emits a timeout signal and calls a timeout function?

mrjj

@millsey
Yes , have a look at QTimer :)