QextSerialPort blocks when trying to read

2.6k Views Asked by At

I am using QextSerialPort on Windows to enable my Qt/C++ application to read and write from/to the serial port.

I want to read bytes from the serial port only when there are bytes to read.

First, I tried connecting the QextSerialPort::readyRead() signal to a slot in my main class, but I noticed that the application hangs.

Then I tried using QextSerialPort::read(char *, uint64), which returns the amount of bytes read, and thereafter I made another unsuccesful attempt combining QextSerialPort::bytesAvailable() and QextSerialPort::read(char *, uint64) to see if that would help my application not to block.

However, the application always blocks and has to be killed, since it does not respond to any mouse or keyboard events. I pressume that the application freezes because the read routine blocks.

Is there a way to perform non-blocking reading with QextSerialPort?

If not, what library should I use to have non-blocking reading capabilities from serial port on Windows?

UPDATE: I have tried using QextSerialPort::atEnd() to check whether there are bytes to read instead of using QextSerialPort::bytesAvailable() or QextSerialPort::size() and it always returns false.

1

There are 1 best solutions below

3
On

Reads should be non-blocking, unless you have set the Query mode to polling

    inline QueryMode queryMode() const { return _queryMode; }

    /*!
     * Set desired serial communication handling style. You may choose from polling
     * or event driven approach. This function does nothing when port is open; to
     * apply changes port must be reopened.
     *
     * In event driven approach read() and write() functions are acting
     * asynchronously. They return immediately and the operation is performed in
     * the background, so they doesn't freeze the calling thread.
     * To determine when operation is finished, QextSerialPort runs separate thread
     * and monitors serial port events. Whenever the event occurs, adequate signal
     * is emitted.
     *
     * When polling is set, read() and write() are acting synchronously. Signals are
     * not working in this mode and some functions may not be available. The advantage
     * of polling is that it generates less overhead due to lack of signals emissions
     * and it doesn't start separate thread to monitor events.
     *
     * Generally event driven approach is more capable and friendly, although some
     * applications may need as low overhead as possible and then polling comes.