QSerialPort - opening port in non-blocking way causes readyRead not to be automatically emitted later on

michelson

Hello,

When QSerialPort::open is called program (GUI) freezes for a little bit (~3-5s) for the port to open. I wanted to avoid this small inconvinience by opeining it async way and reporting the result. However I found out that later on this causes QIODevice::readyRead signal not to be emitted.

    connect(m_port, &QSerialPort::readyRead, []() { qDebug() << "ready read!"; });
    connect(m_port, &QSerialPort::bytesWritten, [](int i) { qDebug() << "bytes written" << i; });

    //this makes readyRead work
    //m_port->open(QIODevice::ReadWrite); 

    // and this not
    using FW = QFutureWatcher<bool>;
    FW *w = new FW();
    connect(w, &FW::started, this, &RJ6::setBusy);
    connect(w, &FW::finished, w, &FW::deleteLater);
    connect(w, &FW::finished, this, &RJ6::onOpenFinished);
    connect(w, &FW::finished, this, &RJ6::setIdle);
    connect(w, &FW::canceled, this, &RJ6::close);

    QFuture<bool> f = QtConcurrent::run([=]() { return m_port->open(QIODevice::ReadWrite); });

    w->setFuture(f);

setBusy, setIdle, onOpenFinished are just emitting signals, nothing else is going on there.

This piece of code is triggered on write request

  qInfo() << QTime::currentTime().toString("hh:mm:ss.zzz") <<  "----- new write request - prev one should be already read-ready reported ----";
  qInfo() << "write" << data.toHex() << m_port->write(data);
  qInfo() << "flush" << m_port->flush();
  //qInfo() << "read all" << m_port->readAll().toHex();

And now I noticed that when I write data to the port, I need to manually read it since QIODevice::readyRead is not emmited autmatically, seems like only after I try QSerialPort::readAll port "realizes" that there is data available for reading

SerialWidget::onSendClicked "02"
"16:38:46.209" ----- new write request - prev one should be already read-ready reported ----
write "02" 1
flush true
read all ""
bytes written 1
SerialWidget::onSendClicked "02"
"16:38:58.218" ----- new write request - prev one should be already read-ready reported ----
write "02" 1
flush true
read all ""
bytes written 1
   ready read! <-------- this is only showed when I uncomment readAll() call
SerialWidget::onSendClicked "02"
"16:39:15.771" ----- new write request - prev one should be already read-ready reported ----
write "02" 1
flush true
read all "52454a3030364a4417"
bytes written 1
   ready read! <-------- this is only showed when I uncomment readAll() call

However when I just stick to the blocking way of simply calling m_port->open(QIODevice::ReadWrite) without any QFuture fanciness all works perfectly - readyRead is emitted correctly.

Do you know what is wrong here?

Environment: Qt\5.15.0\msvc2019_64 @ Win10

Kent-Dorfman

so if there is a delay during open, why do the open() in the main thread? Why not offload it and check the status when the worker thread completes?

michelson

@Kent-Dorfman
That is basically what I did! I mean - I don't explicitly create another thread, I just run QSerialPort::open on, what I understood from the docs, one of the threads from the global pool (QThreadPool::globalInstance()). I don't understand why this has influence on QSerialPort::readyRead signal.

SGaist

Hi,

You did just move the open call to another thread. What @Kent-Dorfman suggest is to implement a worker object to full manage your serial port in another thread.

michelson

Yes, I understand the idea. However I thought that this will be not necessary - I am using readyRead/bytesWritten to communicate with the device and it was working fine for me - no other thread was needed - until this open thing poped up.

Alright, I assume either a little lag on open is acceptable or rewriting while thing to be handled in separate thread is necessary...

SGaist

The fact that your serial port opens slowly does not mean there's a bug in Qt. Did you check with another application whether it behaves the same ?

kuzulis

@SGaist said in QSerialPort - opening port in non-blocking way causes readyRead not to be automatically emitted later on:

The fact that your serial port opens slowly does not mean there's a bug in Qt.

Is it related to this bug?

Environment: Qt\5.15.0\msvc2019_64 @ Win10

Ahh. no..

Most likelly the problem is in your HW device or driver. Also you should not call the QSP methods from the different threads (as daid before).

michelson

@SGaist I did not say that there is a bug, to be honest I was quiet sure that it is me who is doing something wrong. And yes - I tried Bluetooth Serial Terminal (from Win10 store) and it also takes a few seconds to connect to device as well. I assume it might be the device (it is a custom thing I'd say) that lags on open.

Alright, at least I understand now that either I need to move all the stuff to some kind of worker handling QSP on separate thread or accept that there will be a lag on open.

Thanks, guys!