<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">> Never ever ever do I/O in the main GUI thread of a Qt application.</div><div dir="ltr"><br></div><div>Why not? It is an asynchronous. You can do I/O in a main thread, but handle data in a separate thread (e.g. to parse it). Of course, it depends on the used communication protocol and etc.</div><div>A main limitation is that on Windows all I/O stops when a user hold-on the application window (ot to drag it, or do resizing). It is a Windows 'feature'. <br></div><div><br></div><div>So, yes, in a common case it is makes sense to move the QSerialPort object to the different thread (a concept of workers).</div><div><br></div><div>> Real world serial comm is fraught with peril. I've been doing it since the days of DOS 3.1.</div><div><br></div><div>It's not true.</div><div><br></div><div>> Unless something has dramatically changed in QSerialPort, readyRead is only emitted for the first character in the buffer because there is no concept of block or packet. A UART handles one byte at a time.</div><div><br></div><div>It's not true too. The readyRead() will be triggered when the device's handle/descriptor becomes 'signalled/activated' (when something comes into FIFO of driver), in this case the QSerialPort reads all data which are in this time in the FIFO (there are may be some bytes). So, no any byte-per-byte handling as you say.</div><div><br></div><div>> When you get a readyRead and fail to completely empty the buffer, that's it. You never get another one.</div><div><br></div><div>I'm don't understand what do you mean...</div><div><br></div><div>> When QSerialPort was taken from Playground and had all its method names changed, there was an odd timing bug too. In a production system running multiple ports of embedded target the code loading the next byte into the class buffer (perhaps not completely Qt code as it could have been in the device driver). The adding of the next byte could begin after readLine() determined how many bytes were in the buffer but prior to actually pulling them. The new byte got added. One less than a full buffer got read and readyRead never fired again because the next byte wasn't being written to a pristine empty buffer.</div><div><br></div><div>I don't know about what you say... It is trash for my opinion.. For you has been provided a good code example how to read the lines:</div><div><br></div><div>
>     QSerialPort * port;<br>
>     QObject::connect(port, &QIODevice::readyRead, port, [port] () -> void  {<br>
>         while (port->canReadLine())  {<br>
>             QByteArray data = port->readLine();<br>
>             // emit with data as argument and do the parsing<br>
>         }<br>
>     }); <br></div><div><br></div><div>BR,</div><div>Denis<br></div><div><br></div><div><br></div><div><br></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">пт, 5 апр. 2019 г. в 10:38, <<a href="mailto:roland@logikalsolutions.com">roland@logikalsolutions.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Quoting <a href="mailto:interest-request@qt-project.org" target="_blank">interest-request@qt-project.org</a>:<br>
<br>
> I think the point is that there's little reason to poll the serial port if<br>
> you can react to the event. Exactly what you'd do if you had a network<br>
> socket. Qt already does the heavy lifting for you, so you only need to<br>
> react to the signal and read as much as you want/need. Basically:<br>
><br>
>     QSerialPort * port;<br>
>     QObject::connect(port, &QIODevice::readyRead, port, [port] () -> void  {<br>
>         while (port->canReadLine())  {<br>
>             QByteArray data = port->readLine();<br>
>             // emit with data as argument and do the parsing<br>
>         }<br>
>     });<br>
><br>
> Whether you have the port in another thread or not is irrelevant in this<br>
> case, either can work fine (unlike your while-sleep loop).<br>
<br>
Never ever ever do I/O in the main GUI thread of a Qt application.  <br>
It's a recipe for disaster despite the countless examples you will  <br>
find posted on-line and even in the Qt examples themselves. Those  <br>
database examples are really nice. Try testing them with a million+  <br>
row table.<br>
<br>
Real world serial comm is fraught with peril. I've been doing it since  <br>
the days of DOS 3.1.<br>
<br>
Before anyone goes running off and using the above lambda, they need  <br>
to consider a few things.<br>
<br>
Unless something has dramatically changed in QSerialPort, readyRead is  <br>
only emitted for the first character in the buffer because there is no  <br>
concept of block or packet. A UART handles one byte at a time.<br>
<br>
When you get a readyRead and fail to completely empty the buffer,  <br>
that's it. You never get another one.<br>
<br>
When QSerialPort was taken from Playground and had all its method  <br>
names changed, there was an odd timing bug too. In a production system  <br>
running multiple ports of embedded target the code loading the next  <br>
byte into the class buffer (perhaps not completely Qt code as it could  <br>
have been in the device driver). The adding of the next byte could  <br>
begin after readLine() determined how many bytes were in the buffer  <br>
but prior to actually pulling them. The new byte got added. One less  <br>
than a full buffer got read and readyRead never fired again because  <br>
the next byte wasn't being written to a pristine empty buffer.<br>
<br>
<br>
-- <br>
Roland Hughes, President<br>
Logikal Solutions<br>
(630) 205-1593<br>
<br>
<a href="http://www.theminimumyouneedtoknow.com" rel="noreferrer" target="_blank">http://www.theminimumyouneedtoknow.com</a><br>
<a href="http://www.infiniteexposure.net" rel="noreferrer" target="_blank">http://www.infiniteexposure.net</a><br>
<a href="http://www.johnsmith-book.com" rel="noreferrer" target="_blank">http://www.johnsmith-book.com</a><br>
<a href="http://www.logikalblog.com" rel="noreferrer" target="_blank">http://www.logikalblog.com</a><br>
<a href="http://www.interestingauthors.com/blog" rel="noreferrer" target="_blank">http://www.interestingauthors.com/blog</a><br>
<a href="http://lesedi.us" rel="noreferrer" target="_blank">http://lesedi.us</a><br>
<br>
_______________________________________________<br>
Interest mailing list<br>
<a href="mailto:Interest@qt-project.org" target="_blank">Interest@qt-project.org</a><br>
<a href="https://lists.qt-project.org/listinfo/interest" rel="noreferrer" target="_blank">https://lists.qt-project.org/listinfo/interest</a><br>
</blockquote></div>