qextserialport is taking its sweet time for sending data

[Cruz]

Hi!

I'm using qextserialport as a solution for serial communication on Windows with an FTDI chip over a USB port. I'm exchanging approx. 60 bytes packets with a device every 12 ms.

Well I measured the performance and it turns out that while sending out the 60 bytes is below 1 ms, reading them takes over 30 ms. Here is my port config:

port = new QextSerialPort("COM4");
port->setBaudRate(BAUD115200);
port->setFlowControl(FLOW_OFF);
port->setParity(PAR_NONE);
port->setDataBits(DATA_8);
port->setStopBits(STOP_1);
port->setTimeout(0,1);

port = new QextSerialPort("COM4");
port->setBaudRate(BAUD115200);
port->setFlowControl(FLOW_OFF);
port->setParity(PAR_NONE);
port->setDataBits(DATA_8);
port->setStopBits(STOP_1);
port->setTimeout(0,1);

To copy to clipboard, switch view to plain text mode 

I'm explicitely setting the timeout to 0,1 otherwise the reading takes over 500ms!!! If I set the timeout to 0,0 the read() never returns. Does anyone have an explanation why reading is so slow? Is there something I can do to make it faster?

I already set the latency of the COM port in the device manager to the minimum of 1 ms.

[wysota]

How exactly do you perform the read?

[Cruz]

The read looks like this:

port->open(QIODevice::ReadWrite);
 
char receiveBuffer[1024];
int bytesRead = port->read(receiveBuffer, qMin(port->bytesAvailable(), 1024));

port->open(QIODevice::ReadWrite);

char receiveBuffer[1024];
int bytesRead = port->read(receiveBuffer, qMin(port->bytesAvailable(), 1024));

To copy to clipboard, switch view to plain text mode 

I don't think there is anything more you can do there.

I got a hint from the mailing list that opening the port in unbuffered mode might do the trick:

port->open(QIODevice::ReadWrite|QIODevice::Unbuffered);

port->open(QIODevice::ReadWrite|QIODevice::Unbuffered);

To copy to clipboard, switch view to plain text mode 

And it's true. It reads lighning fast now. However, you don't get a nice packet stream anymore, where one read returns one or more complete packets, but some kind of byte mess of random sizes that you have to glue together to whole packets. This is not a problem though, it's just a couple of lines of code and it works reliably and faster than ever.

[wysota]

You shouldn't do the reading that way. If there is nothing to read, your application will freeze and wait until the operating system decides it's time to let your application know there is actually something waiting in the file descriptor. You should only call read() when you have checked bytesAvailable() reports any data waiting to be read.