2

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.

MPelletier
  • 16,256
  • 15
  • 86
  • 137
Genba
  • 854
  • 2
  • 10
  • 19

1 Answers1

0

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.
Martin Beckett
  • 94,801
  • 28
  • 188
  • 263
  • I am afraid I cannot find that function anywhere. However, I have not set the query mode to polling (unless I am not aware of having done so). I have not been able to use `queryMode()` either. – Genba Mar 22 '11 at 18:37
  • Event driven is the default (set in ctor). Are you using the new version http://code.google.com/p/qextserialport/ ? – Martin Beckett Mar 22 '11 at 19:05
  • I was using version 1.1 from [qextserialport.sourceforge.net](http://qextserialport.sourceforge.net/). I have already managed to solve the issue with blocking I/O. I have just downloaded the source code from Google Code using Mercurial, but I still have a problem with the character encoding. I shall ask another question for that. – Genba Mar 30 '11 at 09:05