[Solved]QSerialPort::readyRead not emitted, QSerialPort::waitForReadyRead always return false with CH340

monegator

Hello there,
i opened this thread so that others facing the same issue may find a solution.
In the past we always used USB-UART cables based on FTDI232 chips (TTL-232R-5V-WE).
However, due to a huge price increase in the last couple of years (5€ for a cable became 35€, now dropped to 25€) we decided to ditch FTDI and bought cables that use the CH340 chip. And why shouldn't we, they cost less than 2€ each.

Our software based on VB6 worked flawlessly, even better (reduced latency) however we had issues with our Qt5 based software (Qt 5.15.2). Even if the data is available (QSerialPort::bytesAvailable return values greater than zero) the readyRead signal is never emitted, and waitForReadyRead always return false.

The issue was that readBufferSize was set to zero (default value), and there must be something in the interaction between CH340 driver, windows COM port object and Qt that prevented the event from being raised, but that was never an issue for FTDI cables.

The solution was to set readBufferSize to 1. Once readBufferSize is different than zero readyRead works again.

Hope this helps

SGaist

Hi and welcome to devnet,

Thanks for the informational post !

I would recommend making it a wiki article as it is usually more durable than a forum post.

monegator

Sure, why not.
Is there a preferred way to do that? (New to the community, i don't exactly know where to look at)

SGaist

You can start here. There are some useful links to help you.

kuzulis

The solution was to set readBufferSize to 1. Once readBufferSize is different than zero readyRead works again.

That's nonsence and wrong solution. All does work with CH340 chips.

monegator

@kuzulis Then please be kind, explain to me what happened then, because i had several windows PCs that exhibited te issue (serial port "not working" because of the serial port component not emitting readyRead signal) and changing readBufferSize was what solved the problem.

Or if you want me to find out on my own please give me some pointers on where to look at, as i'll have to do that in my free time and as my free time is priceless, i don't want to waste any.

Mind that this happened right after the usual weekly round of windows updates, on different PCs located in different parts of the world. For what we know something may have changed at a lower lever, i had also noticed some change in behaviour in ancient VB6 applications.