Unsolved Help with QThread and Serialport
-
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 :) -
thank you all!
I will check it out
-
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.
-
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
-
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
-
-
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?
-
@millsey
Yes , have a look at QTimer :)