4. QextSerial droping data

QextSerial droping data


  • Hi

    Has anybody used QextSerialPort (v1.2b2) and maybe experienced the same issue of lost bytes on reception?
    I have set event driven mode (where the timeout value does nothing according doc) with 115k on Linux.

    Stripped down excerpt of my code:
    @void QTGUI_MainWindow::onComReadyRead()
    {
    static QByteArray RawPortData;
    uint iBytesAvailable;

    while(port->bytesAvailable())
    {
    iBytesAvailable = port->bytesAvailable();
    RawPortData = port->read(iBytesAvailable);

    do
{ /* evaluate data */ }

    }
    }
    @

    Thanks
    McL

    0

  • Hi.

    You can use "QtSerialPort":https://qt-project.org/wiki/QtSerialPort module instead of QextSerialPort. The QtSerialPort already are "present":http://qt-project.org/doc/qt-5/qtserialport-index.html in Qt5 (also this module can be compiled and for Qt4, see wiki).

    0

  • Do you know if it works on 4.6.3 on eLinux as well, since I am actually bound to this version?
    ... Where to download?

    0

  • Hmm.. I'm not sure about Qt 4.6.3, because QtSerialPort supports from the Qt 4.8.x.

    In any case you can try it, though, I am sure that there will be errors in case of compilation. This errors may related with QElapsedTimer (because this class introduced since Qt 4.7.0), then just replace QElapsedTimer to QTime class.. Also maybe are others errors, I don't know.

    0

  • OK, I'll try.
    With QextSerialPort I could simply add the project to my src folder and add @include(qextserialport/src/qextserialport.pri) @

    to my pro file.
    Does that work in a similar and easy way with QtSerialPort?

    0

  • bq. Does that work in a similar and easy way with QtSerialPort?

    Please read "Wiki":https://qt-project.org/wiki/QtSerialPort.

    0

  • I already did that. I have to admit that I am not very familiar with Qt and the Crosscompiling setup I am working on has not been set up by me (Working/compiling on windows and if OK compiling on Linux then use on target with eLinux).
    Basically this works perfect and with pri from the QextSerialPort this was possible to add this even for me as a novice regarding these things.
    I also tried as described in the wiki, replaced the QElapsedTimer but it returns me windows related errors like:
    @l:\target\src\sd\nf\qtgui\src\QtSerialPort\src\serialport\qserialportinfo_win.cpp:54:22: error: cfgmgr32.h: No such file or directory
    l:\target\src\sd\nf\qtgui\src\QtSerialPort\src\serialport\qserialportinfo_win.cpp:126: error: 'DEVINST' was not declared in this scope
    l:\target\src\sd\nf\qtgui\src\QtSerialPort\src\serialport\qserialportinfo_win.cpp:127: error: expected ',' or ';' before '{' token

    l:\target\src\sd\nf\qtgui\src\QtSerialPort\src\serialport\qserialportinfo_win.cpp:74: warning: 'QStringList portNamesFromHardwareDeviceMap()' defined but not used
    l:\target\src\sd\nf\qtgui\src\QtSerialPort\src\serialport\qserialportinfo_win.cpp:103: warning: 'QString deviceRegistryProperty(void*, _SP_DEVINFO_DATA*, DWORD)' defined but not used

    @

    Drive l is where the sources are - a mapped drive on the linux machine.

    0

  • You do -cross- compilation from the Linux host for the Windows target? I do not understand.. Can you give more detail, how you do it?

    0

  • I'll try to elaborate:

    • Working computer where I develop with QtCreator and 4.6.3: Win7
    • Debian VM on the same machine to compile for the eLinux target (STB)
    • Sources and a Qt 4.6.3 are on the Debian VM
    • QtCreator is accessing sources by a (local) network share

    If I do some lines of code and it compiles fine on Windows (QtCreator) I switch to the Debian VM and run make there as well which builds me the the executables I run on my eLinux device.

    This may not seem to be a classical cross-compilation scenario. However, it has been arranged this way by the SoC supplier and it works perfect.

    To use the QextSerialPort I simply copied all the sources of it into a subfolder on my sourcepath and included the pri ... et voila.
    I am looking for a similar way to include QtSerialPort to easily see if it works with 4.6.3.

    0

  • Let me add an additional question regarding the event loop and the readyRead signal:
    Looking at my first post: What happens if code inside readyRead (already exiting the bytesAvailable while loop) being executed (just about to exit the function) and new bytes are receiving on the port? Do I get a new readyRead event when the source for the event happens while I am already working on this event? Know what I mean ...?!?

    0

  • If I correctly understand you, then this code:

    @
    while(port->bytesAvailable())
    {
    iBytesAvailable = port->bytesAvailable();
    RawPortData = port->read(iBytesAvailable);

    do
{ /* evaluate data */ }

    }
    @

    no make sense. Because no any new bytes will be received until you do while().

    E.g.:
    @
    Foo::onReadyRead()
    {
    while (1) {
    qDebug() << port->bytesAvailable();
    }
    }
    @
    will print out same value, because no event loop works.

    Also no make sense do:
    @
    Foo::onReadyRead()
    {
    while (1) {
    qDebug() << port->readAll();
    }
    }
    @
    this code printed out once of data (at first call), in other cases (in next calls) will be "printed out' an empty QByteArray.

    0

  • IMHO, it makes perfect sense - and it works as intended.
    I am not leaving the readyRead slot when new bytes arrive, read these bytes immediately and leave when no more bytes have arrived.
    In practice (verified with debug outputs) this can look like follows: Let's say 50 bytes have been sent to the device.

    readyRead slot is called

    while(port->bytesAvailable()) is 30

    reading 30 bytes

    while(port->bytesAvailable()) is 20

    reading 20 bytes

    while(port->bytesAvailable()) is 0

    leaving readyRead slot

    This works perfect, just that some bytes are missing sometimes like in 1 out of 10 protocols sent some bytes are missing and 9 out of 10 are just perfect.

    0

  • I'll open a new thread regarding integration of QtSerialPort into 4.6.3 and leave this thread open for help on finding a solution with dropping bytes with qextserialport.

    0

  • Trying to find the byte drop ... I need some explanation how something works:

    I added a lot of debug outputs and don't uderstand the following: Calling
    @RawPortData = serial->read(iBytesAvailable);@

    ends up in
    @qint64 QextSerialPort::readData(char *data, qint64 maxSize)@

    I would expect to have maxSize if debugged inside this function being equal to iBytesAvailable, but it is not. Instead it is 16384 (size of buffer?).
    The further logic inside readData then makes no more sense and a read from the device is always triggered.

    Not that this is the bug I'm chasing. But I just don't understand the call flow. What is between serial->read and QextSerialPort::readData ?

    0

  • Back from vacation ... back to my issues with the serial port.
    No one ?

    0

  • Byte count that is returned by FIONREAD is not correct. So, I assume that something in the underlying native Linux must be buggy.
    Coming back ...

    0
Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.