Hi,
> No offence but I don't think it's the matter of blocking or non-blocking. Also I don't think waitForBytesWritten is a "MUST" as long as I wait enough time before next transmission.
The QtSerialPort is event-based entity. So, the write() method returns immediately. Because he writes data to the internal buffer of a class and it is all.Further, the real data transfer is carried out asynchronously by tracking the descriptors of overlapped events.
To watch for this events is used the Qt-event loop. But in your case the Qt-event loop is stopped while you do not exit from the your constructor of Widget.
So, are two ways to run tracking:
1. It is use the waitForXXX() methods. But it can be a problem because these methods can contain errors. Therefore I don't recommend to use the waitForXXX() methods.
2. Or call the processEvents() method to force run the Qt-event loop.
> If QSerialPort is correct, I can only say that these APIs are out of my common sense.
Sorry, but it is your problem..
BTW: You should also provide the your debug outputs.
Best regards,
Denis
16.10.2013, 16:08, "nus1998" <nus1...@yeah.net>:
Hi,
No offence but I don't think it's the matter of blocking or non-blocking. Also I don't think waitForBytesWritten is a "MUST" as long as I wait enough time before next transmission.
If QSerialPort is correct, I can only say that these APIs are out of my common sense.
Best regards,
Je
At 2013-10-16 19:39:49,"Denis Shienkov" <scap...@yandex.ru> wrote:Hi.1. Do not use the blocking approach for the GUI app.2. After write() you should do waitForBytesWritten() or flush() in case of blocking approach.Summary: Use the non-blocking approach with the readyRead signal and do not use the waitForXXX() methods!Best regards,Denis16.10.2013, 12:24, "nus1998" <nus1...@yeah.net>:Hi, the simple code is followed, I use wizard to generate qt gui application in widget method
for "#if 1", the message is "port open, A, A, done", for "#if 0", the message is "port open, A, B, done"
#include <QDebug>#include <QtSerialPort/QtSerialPort>Widget::Widget(QWidget *parent) :QWidget(parent),ui(new Ui::Widget){ui->setupUi(this);QSerialPort *port = new QSerialPort(this);char c1, c2;port->setPortName("COM4");if(port->open(QIODevice::ReadWrite)){port->setBaudRate(QSerialPort::Baud9600);port->setDataBits(QSerialPort::Data8);port->setStopBits(QSerialPort::OneStop);port->setParity(QSerialPort::NoParity);port->setFlowControl(QSerialPort::NoFlowControl);qDebug() << "port open";}elseqDebug() << "port open error";port->clear();c1 = 'A';port->write(&c1, 1);port->waitForReadyRead(3000);port->read(&c2, 1);qDebug() << c2;c1 = 'B';port->write(&c1, 1);#if 1port->waitForReadyRead(3000);#elseport->waitForReadyRead(100);port->waitForReadyRead(100);#endifport->read(&c2, 1);qDebug() << c2;qDebug() << "done";}
At 2013-10-16 16:08:04,"Denis Shienkov" <scap...@yandex.ru> wrote:Hi.> I just test it, so I think blocking method is not the issue. and even when I use "connect(m_serial, SIGNAL(readyRead()), this, SLOT(serialRead())); "
mostly the serialRead slot can read nothing too..Seems, you do something wrong.>Can't read data:
>waitForReadyRead(1000);>read(data, 1);Same...Please provide the simple test application (sources) to reproduce the problem.Best regards,Denis16.10.2013, 12:03, "nus1998" <nus1...@yeah.net>:Hi,
I just test it, so I think blocking method is not the issue. and even when I use "connect(m_serial, SIGNAL(readyRead()), this, SLOT(serialRead())); "
mostly the serialRead slot can read nothing too..
I tested the following two sample on a loopthrough uart, which make me confused since there is no timeout error for both test.
Can't read data:
waitForReadyRead(1000);read(data, 1);
Can read data:
waitForReadyRead(100);
waitForReadyRead(100);
waitForReadyRead(100);
waitForReadyRead(100);read(data, 1);
.
Best regards,
Je
At 2013-10-16 15:50:57,"Denis Shienkov" <scap...@yandex.ru> wrote:Hi.You wrong do it, because it isn't recommended to use the waitForXXX() methods from an main GUI thread.You should use the non-blocking approach because it is preferred way, e.g. see the Terminal example or Master and Slave Examples from the QtSerialPort sources.Best regards,Denis16.10.2013, 07:51, "nus1998" <nus1...@yeah.net>:I write a workaround function as below which now works although the actual timeout doesn't match with "TIMEOUT" since sometimes "waitForReadyRead" will return immediately without data available. I have patched "https://codereview.qt-project.org/#patch,sidebyside,67962,2,src/serialport/qserialport_win.cpp" yet.
bool Widget::waitBytes(qint64 n){for(int i = 0; i < TIMEOUT; i++){if(m_serial->bytesAvailable() >= n)return true;m_serial->waitForReadyRead(1);}return false;}
At 2013-10-16 11:41:18,"Mandeep Sandhu" <mandeepsandhu....@gmail.com> wrote: >You can also try doing a raw read (non Qt way) on the device using >open/read system calls and check if data is actually available. >That'll make sure that the OS is indeed receiving data and the problem >can then be isolated to QSerialPort. > >HTH, >-mandeep > >On Wed, Oct 16, 2013 at 6:25 AM, nus1998 <nus1...@yeah.net> wrote: >> HI Denis, >> >> Thanks for the reply. >> >> Even if I don't use "waitForReadyRead" but polling "bytesAvailable" instead, >> the later always returns 0 although there is data received and I can use >> other terminal software to display it too. >> >> Best regards, >> Je >> >> >> >> >> >> At 2013-10-16 01:15:36,"Denis Shienkov" <scap...@yandex.ru> wrote: >> >> Hi. >> >> Seems it is a bug, see: https://bugreports.qt-project.org/browse/QTBUG-33987 >> >> You can test this patch. >> >> Besd regards, >> Denis >> >> >> 15.10.2013 18:37, nus1998 пишет: >> >> >> I found a strange issue, when I read from serial, first I will call >> "waitForReadyRead", it returns with true in specified time, however, when I >> call "read" function thereafter, I can't read even a byte. the hardware >> works fine since I checked it by logic analyzer. >> >> env: win7 64, qt 5.1 mingw version >> >> thanks >> Je >> ---- >> from iPad >> >> >> >> >> _______________________________________________ >> Interest mailing list >> Interest@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/interest >> >> >> >> >> >> _______________________________________________ >> Interest mailing list >> Interest@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/interest >>
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
