Problem with using QIODevice.read inherited by QSerialPort
-
Hi:
Some time ago i made an app to read data from an accelerometer we build in the university for doing some research in structure health...In this app i used, for example something like:
data=serial.read(252);
Where data is a QByteArray, and serial is a QSerialPort device...
According to documentation, this reads "AT MOST" 252 bytes from serial... if there were only 200 bytes available, it should read and return them... This was working as expected when i made the app, i gave it to the researchers and everything was just prefect...Now they asked me to do some changes, but now that instrucction freezes untill it has the 252 bytes, instead of reading only the ones that are available, although docummentations stills states the contrary...
I don't know if this is a bug of the newer qt version or what, by that time i was using ubuntu 14.10 and now im using ubuntu 15.04... but i desesperatly need some help... instructions like this are used a lot in my app and i didn't want to change everything...
Thanks -
Hi: thanks for the answer!
I'm using Qt Creator 3.4.2 based on Based on Qt 5.5.0. The previous Qt version i used i don't remember, but it was in december of last year, so it shouldn't be much older...The code is too long to post it here, however i can send you some partes where the program is freezing:
serial.waitForReadyRead(500);
resp=serial.read(1);
if(resp[0]==(char)0x01)
{
ui->texto->append("<span style=""color:green"">El sensor "+l->nombre+" se encuentra disponible...</span>");
}
else
{
ui->texto->append("<span style=""color:red"">El sensor "+l->nombre+" no esta disponible...</span>");
}this should read one byte if the device is available and read nothing if the device is not available, as the device will answer only if it's available... I can workarroun this replacing the read with readAll, but in other sections where the ammount of bytes to read is variable, so i'm having this trouble
-
I want to make clear that this was working previously, and for the information i read in documentation it should be working now too... perhaps it has something to do with my OS (i changed ubuntu version) and the handling of serial ports... i really don't know
-
Yes, i have also thought about that, but in that case, according to docummentation it should return an empty array... the problem persists if i read something but not the maxsize specified in the read argument, for example
{ auxiliar.append(serial.read(252)); l->datos.append(auxiliar); pag=pag+auxiliar.size(); auxiliar.clear(); }
in this case it should read 252 bytes or less... but when there are less than 252 bytes, it freezes there waiting, and nothing can be done
-
I will a little correct this sentence to:
Keep in mind that serial.waitForReadyRead(500) can return false if after 500ms no data are received
to:
Keep in mind that serial.waitForReadyRead(500) can return false if after 500ms no NEW data are received!
Use case:
- Your receiver is empty.
- The sender send 10 bytes
- You call the waitForReadyRead()
- The waitForReadyRead() returns true (and, we will assume that receiver accepted 10 bytes)
- You do read(1);
- In next time you call the waitForReadyRead() again. In this case the waitForReadyRead() returns false with the TimeoutError, because no any new data were received.
Besides, you should do not use the waitForReadyRead() in a main thread, because it will be freezes in any case, it is wrong way. You should use the readyRead() signal.
Qt BUG; in that case you can open a
The QSerialPort covers by the tests. So, it is improbable.. A more possibly that a problem is in your code. :)
-
Thanks for your reply...
I agree that may be my code is not the best practice, as i learn Qt by myself only with doc and tutorials... but the program was working perfectly when i delivered it to the researchers... In fact, is working perfectly if i compile it on windows... few hour ago i borrowed a windows machine, installed qt, compiled the same project and worked just fine... So i doubt is really a code problem, because it should appear in both Windows and Linux, as the code is exactly the same...
I'm starting to think that is a linux driver problem, so i will try in another linux when i get the chance...
If someone has ubuntu 15.04 and is kind enough to reproduce this problem and tell me i would be very happy!
If anybody else reproduce this problem in other linux machine i will start a bug report