QSerialPort unable to detect framing error and parity error.
-
Hello all,
I have built an application that receives and transmits data through a USB serial port running on Windows 10. I am able to send and recieve data across using QSerialPort. But i want to detect the errors caused due to parity and framing error. I am doing this by simply shorting the Tx and Rx with Gnd pins. These errors are being detected by applications created using Labwindows but are not being emitted by the error signal as provided in Qt documentation. Below is the sample code for this.constructor{ setSerialConfig(serialport,"com5"); connect(&serialport,SIGNAL(error(QSerialPort::SerialPortError)),this,SLOT(handleError(QSerialPort::SerialPortError))); } void TwoWayComm::setSerialConfig(QSerialPort &port,QString name) { port.setPortName(name); port.open(QIODevice::ReadWrite); port.setBaudRate(QSerialPort::Baud9600); port.setDataBits(QSerialPort::Data8); port.setParity(QSerialPort::OddParity); port.setStopBits(QSerialPort::OneStop); port.setFlowControl(QSerialPort::NoFlowControl); } void TwoWayComm::handleError(QSerialPort::SerialPortError error) { qWarning("Error\n"); qDebug()<<"Error triggered\n"; }The slot is never triggered even when I remove the cables while the communication is taking place or shorting the pins while communication is taking place. Any suggestions regarding this will be really helpful.
Thanks in advance.
-
Hello all,
I have built an application that receives and transmits data through a USB serial port running on Windows 10. I am able to send and recieve data across using QSerialPort. But i want to detect the errors caused due to parity and framing error. I am doing this by simply shorting the Tx and Rx with Gnd pins. These errors are being detected by applications created using Labwindows but are not being emitted by the error signal as provided in Qt documentation. Below is the sample code for this.constructor{ setSerialConfig(serialport,"com5"); connect(&serialport,SIGNAL(error(QSerialPort::SerialPortError)),this,SLOT(handleError(QSerialPort::SerialPortError))); } void TwoWayComm::setSerialConfig(QSerialPort &port,QString name) { port.setPortName(name); port.open(QIODevice::ReadWrite); port.setBaudRate(QSerialPort::Baud9600); port.setDataBits(QSerialPort::Data8); port.setParity(QSerialPort::OddParity); port.setStopBits(QSerialPort::OneStop); port.setFlowControl(QSerialPort::NoFlowControl); } void TwoWayComm::handleError(QSerialPort::SerialPortError error) { qWarning("Error\n"); qDebug()<<"Error triggered\n"; }The slot is never triggered even when I remove the cables while the communication is taking place or shorting the pins while communication is taking place. Any suggestions regarding this will be really helpful.
Thanks in advance.
@sasanka said in QSerialPort unable to detect framing error and parity error.:
connect(&serialport,SIGNAL(error(QSerialPort::SerialPortError)),
It looks like you're using a non existing signal... From QSerialPort documentation (Qt 5.11), the signal is errorOccurred(QSerialPort::SerialPortError error)
You should have a runtime message in the application output.
As a side note, this situation could have been avoided by using the new signal/slot syntax since the connection is checked at compile time.
-
But i want to detect the errors caused due to parity and framing error.
QSP does not support this features, and the FramingError/ParityError are obsolete. Reason is that impossible to implement this features in common case, and it complicates a code.
The slot is never triggered even when I remove the cables while the communication is taking place
The QSP does not know about any cables, it works with a device handle. So, if an I/O operations does not return an errors when the USB cable unplugged it is a driver/hardware/system issue.
-
Hi Thanks for the reply. Still nothing is working, I was using Qt 5.9 so both the signals error and errorOccured were available.
But I switched to Qt 5.11 now and I have changed the source code as follows.connect(&serialport,&QSerialPort::errorOccurred,this,&TwoWayComm::handleError);
still the slot handleError does not receive any errors when I try to unplug the cables in middle of communication or try to short the Tx and Rx pins of the USB serial port cable.
-
But i want to detect the errors caused due to parity and framing error.
QSP does not support this features, and the FramingError/ParityError are obsolete. Reason is that impossible to implement this features in common case, and it complicates a code.
The slot is never triggered even when I remove the cables while the communication is taking place
The QSP does not know about any cables, it works with a device handle. So, if an I/O operations does not return an errors when the USB cable unplugged it is a driver/hardware/system issue.
-
If you want to detect for the plug/unplug events (e.g. for a USB/serial dongle), then you need to write own custom class which uses the WM_DEVICECHANGE on Windows (or udev monitoring on Linux).
If you want to detect a framing/parity errors, then I think, it is impossible with QSP...
But if you use only Windows, then you can write an own I/O serial port class which handles an extended event masks (like EV_BREAK, EV_ERR (for CE_FRAME, CE_OVERRUN, and CE_RXPARITY)). But, I'm not sure that it will work as you want for all serial ports (it depends on HW, driver and etc). It will not work in 90% cases, from our experience. For this reason we mark the Frame/Parity errors as deprecated (besides, this errors has not sense anyway, as need to use the protocols with a CRC fields instead).
-
If you want to detect for the plug/unplug events (e.g. for a USB/serial dongle), then you need to write own custom class which uses the WM_DEVICECHANGE on Windows (or udev monitoring on Linux).
If you want to detect a framing/parity errors, then I think, it is impossible with QSP...
But if you use only Windows, then you can write an own I/O serial port class which handles an extended event masks (like EV_BREAK, EV_ERR (for CE_FRAME, CE_OVERRUN, and CE_RXPARITY)). But, I'm not sure that it will work as you want for all serial ports (it depends on HW, driver and etc). It will not work in 90% cases, from our experience. For this reason we mark the Frame/Parity errors as deprecated (besides, this errors has not sense anyway, as need to use the protocols with a CRC fields instead).
