QextSerial droping data
-
bq. Does that work in a similar and easy way with QtSerialPort?
Please read "Wiki":https://qt-project.org/wiki/QtSerialPort.
-
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 '{' tokenl:\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.
-
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?
-
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. -
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 ...?!? -
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. -
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.
-
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.
-
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 ?
-
Back from vacation ... back to my issues with the serial port.
No one ? -
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 ...