[Interest] Parsing data from serialport

[Martin Marmsoler]

Thank you Andre for the fast response.

Ok than I found the problem, why the program need so much RAM 😂

Am Di., 9. Apr. 2019 um 08:21 Uhr schrieb Andre Hartmann <
andre.hartmann at iseg-hv.de>:

> Hi Martin,
>
> > What is, when I ignore the ready read?
>
> The data will stay in the buffer, of course.
>
> > Has the internal buffer a max size?
>
> Your RAM or 2^32, whichever is lower.
>
> > Because at the moment I have a memory leak and maybe it comes from
> > that?
>
> I doubt that. A leak would mean, you cannot use the data anymore, which
> is wrong here - you just need to fetch the data from the buffer.
>
> Regards,
> André
>
> >
> > Martin
> >
> > Am Fr., 5. Apr. 2019 um 21:12 Uhr schrieb Konstantin Shegunov
> > <kshegunov at gmail.com <mailto:kshegunov at gmail.com>>:
> >
> >     On Thu, Apr 4, 2019 at 6:42 PM Jérôme Godbout <godboutj at amotus.ca
> >     <mailto:godboutj at amotus.ca>> wrote:
> >
> >         You jus did the same loop into your slot, the function I did
> >         made can be called as slot to the connect you just told, I agree
> >         the serial_port->waitForReadyRead(5); is not necessary, just
> >         often the transmission have partial or bunch of data by small
> >         burst (USB VCOM) and was handy for me, but it is not ncessary in
> >         any way.
> >
> >     A similar loop yes, however your loop goes until there's something
> >     to read on the port, mine is run a few times only when the port
> >     already has some information pending in its buffer. The QSerialPort
> >     class already knows if data has arrived and buffers it*, so what
> >     would be the point to loop over the port when there's no data? When
> >     you talk with someone do you ask every 5ms if [s]he has something to
> >     say to you? I really doubt it. You'd normally just wait for
> >     something to be said to decide if and how to respond to it.
> >
> >         Side note: ReadLines made it less general purpose, you will need
> >         a protocol that use endline to signal end of message which is
> >         not always the case.
> >
> >     Involving realistic protocol handling is another kettle of fish. It
> >     would require much more thought and effort and is beyond the scope
> >     of what was asked initially.
> >
> >     * Unless it's in unbuffered mode, as Thiago already noted.
> >
> >     _______________________________________________
> >     Interest mailing list
> >     Interest at qt-project.org <mailto:Interest at qt-project.org>
> >     https://lists.qt-project.org/listinfo/interest
> >
> >
> > _______________________________________________
> > Interest mailing list
> > Interest at qt-project.org
> > https://lists.qt-project.org/listinfo/interest
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20190409/a38682e8/attachment.html>