Files:
The Blocking Slave example shows how to create a application for a serial interface using SerialPort's synchronous API in a non-GUI thread.
[Missing image blockingslave-example.png]
SerialPort supports two general programming approaches:
In this example, the synchronous approach is demonstrated. The Slave Example example illustrates the asynchronous approach.
The purpose of this example is to demonstrate a pattern that you can use to simplify your serial programming code, without losing responsiveness in your user interface. Use of Qt's blocking serial programming API often leads to simpler code, but because of its blocking behavior, it should only be used in non-GUI threads to prevent the user interface from freezing. But contrary to what many think, using threads with QThread does not necessarily add unmanagable complexity to your application.
This application is a Slave, that demonstrate the work paired with Master application Blocking Master Example.
The Slave application is receives the request via serial port from the Master application and send a response to it.
We will start with the SlaveThread class, which handles the serial programming code.
SlaveThread is a QThread subclass that provides an API for receive requests from Master, and it has signals for delivering responses and reporting errors.
You should be call startSlave() to startup Slave application. This method transfers to the SlaveThread desired parameters for configure and startup the serial interface. When SlaveThread received from Master any request then emitted the request() signal. If any error occurs, the error() or timeout() signals is emitted.
It's important to notice that startSlave() is called from the main, GUI thread, but the response data and other parameters will be accessed from SlaveThread's thread. Because we will be reading and writing SlaveThread's data members from different threads concurrently, we use QMutex to synchronize access.
void SlaveThread::startSlave(const QString &portName, int waitTimeout, const QString &response) { QMutexLocker locker(&mutex); this->portName = portName; this->waitTimeout = waitTimeout; this->response = response; if (!isRunning()) start(); }
The startSlave() function stores the serial port name, timeout and response data, and we lock the mutex with QMutexLocker to protect this data. We then start the thread, unless it is already running. We will come back to the QWaitCondition::wakeOne() call later.
void SlaveThread::run() { bool currentPortNameChanged = false; mutex.lock(); QString currentPortName; if (currentPortName != portName) { currentPortName = portName; currentPortNameChanged = true; } int currentWaitTimeout = waitTimeout; QString currentRespone = response; mutex.unlock();
In the run() function, we start by acquiring the mutex lock, fetching the serial port name, timeout and response data from the member data, and then releasing the lock again. The case that we are protecting ourselves against is that startSlave() could be called at the same time as we are fetching this data. QString is reentrant but \e not thread-safe, and we must also avoid the unlikely risk of reading the serial port name from one startup, call and timeout or response data of another. And as you might have guessed, SlaveThread can only handle one startup at a time.
The SerialPort object we construct on stack into run() function before loop enter:
SerialPort serial;
while (!quit) {
This allows us once to create an object, while running loop, and also means that all the methods of the object will be executed in the context of the run() thread.
In the loop, we check for changed or not the name of serial port for the current startup. And if the name is changed then re-open and re-configure the serial port.
if (currentPortNameChanged) { serial.close(); serial.setPort(currentPortName); if (!serial.open(QIODevice::ReadWrite)) { emit error(tr("Can't open %1, error code %2") .arg(portName).arg(serial.error())); return; } if (!serial.setRate(9600)) { emit error(tr("Can't set rate 9600 baud to port %1, error code %2") .arg(portName).arg(serial.error())); return; } if (!serial.setDataBits(SerialPort::Data8)) { emit error(tr("Can't set 8 data bits to port %1, error code %2") .arg(portName).arg(serial.error())); return; } if (!serial.setParity(SerialPort::NoParity)) { emit error(tr("Can't set no patity to port %1, error code %2") .arg(portName).arg(serial.error())); return; } if (!serial.setStopBits(SerialPort::OneStop)) { emit error(tr("Can't set 1 stop bit to port %1, error code %2") .arg(portName).arg(serial.error())); return; } if (!serial.setFlowControl(SerialPort::NoFlowControl)) { emit error(tr("Can't set no flow control to port %1, error code %2") .arg(portName).arg(serial.error())); return; } } if (serial.waitForReadyRead(currentWaitTimeout)) {
The loop will continue wait for reading request data:
// read request QByteArray requestData = serial.readAll(); while (serial.waitForReadyRead(10)) requestData += serial.readAll();
Warning: The method waitForReadyRead() should be used before each read() call for the blocking approach, because it processes all the I/O routines instead of Qt event-loop.
The timeout() signal is emitted if error occurs when reading data.
} else { emit timeout(tr("Wait read request timeout %1") .arg(QTime::currentTime().toString())); }
After a successful read, we try send response and wait completion of the transfer:
// write response QByteArray responseData = currentRespone.toLocal8Bit(); serial.write(responseData); if (serial.waitForBytesWritten(waitTimeout)) { QString request(requestData); emit this->request(request);
Warning: The method waitForBytesWritten() should be used after each write() call for the blocking approach, because it processes all the I/O routines instead of Qt event-loop.
The timeout() signal is emitted if error occurs when writing data.
} else { emit timeout(tr("Wait write response timeout %1") .arg(QTime::currentTime().toString())); }
After a successful writing is emitted request() signal containing the data received from the Master application:
emit this->request(request);
Next, the thread goes to re-reads the current parameters for serial interface, because they can be updated when new startSlave() and run loop from the beginning.
mutex.lock(); if (currentPortName != portName) { currentPortName = portName; currentPortNameChanged = true; } else { currentPortNameChanged = false; } currentWaitTimeout = waitTimeout; currentRespone = response; mutex.unlock(); }
See also Simple Terminal Example and Blocking Master Example.