Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. QSerialPort::waitForReadyRead() delays at least 5-10ms, how to make it respond faster?

QSerialPort::waitForReadyRead() delays at least 5-10ms, how to make it respond faster?

Scheduled Pinned Locked Moved Unsolved General and Desktop
synchronousserialqserialportdelayslow
3 Posts 3 Posters 1.1k Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • D Offline
    D Offline
    DerManu 0
    wrote on 1 Oct 2020, 09:49 last edited by DerManu 0 10 Jan 2020, 10:55
    #1

    Hi there,

    I require a very tight back-and-forth between a fast 1GHz microprocessor and host PC, using the serial port (emulated via high-speed USB 2.0). Unfortunately the transferred data packets can't be batched, but are necessarily interleaved.

    Upon sending a few bytes via serialPort->write(); the processor receives the data approximately 200µs later and answers around 50µs after that. During that time, the host waits synchronously via serialPort->waitForReadyRead(1);. I intentionally avoid the event loop and the asynchronous readyRead() signal since it would yield to the OS and incur a time delay of at least one scheduler time slice (~10ms or more), if I'm not mistaken.

    Unfortunately, also the supposedly synchronous waitForReadyRead() doesn't return as soon as the data has arrived in the buffer, but it seems it also yields to the OS – it takes between 5 and 10ms at minimum, which is way too much for my application. In the QSerialPort code (see here), I believe it does this with a call to SleepEx, which according to the MSDN suspends the thread. I guess that's the root of the issue.

    Is there a way to receive serial data in Qt or otherwise without suspending the thread? I'd like to avoid these unnecessary waits, as I know the client will respond literally within a couple of microseconds. I've tried to just serialPort->read() in a tight loop, but it never reads any data.

    //EDIT: After digging into QSerialPort code a bit more, I believe the synchronous mode (waitForBytesWritten/waitForReadyRead) is not optimal as it is just propped on top of the asynchronous mode which is clearly the more common use-case.
    As such, in method QSerialPortPrivate::startAsyncRead, it uses ::readFileEx which is asynchronous and calls back to QSerialPortPrivate::ioCompletionRoutine.
    Wouldn't it be better to create a startSynchRead method which is then used for the synchronous operation of QSerialPort, which then uses the appropriate synchronous winAPI method ::readFile? Any thoughts or ideas for a quick fix not involving changing QSerialPort to be properly synchronous and not only pretend to?

    1 Reply Last reply
    0
    • K Offline
      K Offline
      kuzulis
      Qt Champions 2020
      wrote on 1 Oct 2020, 12:04 last edited by kuzulis 10 Feb 2020, 09:17
      #2

      You can create your own serial port module to read the data as you want, even to use it synchronously.

      PS: All Qt I/O classes use the asynchronous API, and all waitForXX() methods emulates it trougth the asynchronous calls (it waits for an completion events in blocking way).

      UPD: I don't know, if it is possible to implement what you want at all at using non real-time OS's. As an option, you can read your serial data using the MCU's instead of USB2.0 serial port adapter, where you can measure this short time intervals. Or, to use the native Win32 API as you want instead of Qt class, to see if it possible at all.

      1 Reply Last reply
      2
      • K Offline
        K Offline
        Kent-Dorfman
        wrote on 2 Oct 2020, 02:18 last edited by
        #3

        Sounds like you should not be using QSerial and instead design a custom solution outside of Qt. Qt is not for real-time processing and your description of the task seems to imply real-time constraints.

        1 Reply Last reply
        0

        3/3

        2 Oct 2020, 02:18

        • Login

        • Login or register to search.
        3 out of 3
        • First post
          3/3
          Last post
        0
        • Categories
        • Recent
        • Tags
        • Popular
        • Users
        • Groups
        • Search
        • Get Qt Extensions
        • Unsolved