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 Timeout Using waitForReadyRead on Windows
QtWS25 Last Chance

QSerialPort Timeout Using waitForReadyRead on Windows

Scheduled Pinned Locked Moved Solved General and Desktop
qserialportarduinowindowslinux
4 Posts 2 Posters 1.3k 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.
  • ? Offline
    ? Offline
    A Former User
    wrote on last edited by
    #1

    Hello everyone

    As the title suggests, I'm having issues with being able to receive serial data when using
    waitForReadyRead() on Windows.

    The setup:
    Everything is being run in one non-GUI thread, so I am using blocking communication everywhere. I'm using QSerialPort to send commands to an Arduino (seems pretty common from what I've been reading), and then receive response messages from the Arduino.

    Below is the reader code:

     QString serialRead()
      {
        if (device.waitForReadyRead())
        {
          QString data = device.readAll();
          return data;
        }
        std::cerr << device.portName().toStdString() << ": " 
                  <<  device.errorString().toStdString() << "\n";
        device.clearError();
        return QString("-1");
      };
    

    This was all developed on Arch Linux, where the reading works beautifully. However, when I go to port the code to Windows, the reading fails with a timeout error.

    I've tried using the blockingMaster example in the qtserialport sources, and it will occasionally receive garbage data (I suspect something to do with inconsistent baud rates?), but more often than not it will also timeout.

    I have confirmed I am able to receive data using the Arduino's serial monitor when I just have the sketch send a string at a constant interval.

    Is this a bug with QSerialPort, or am I just missing something that is Windows Specific?

    Any help is appreciated :)

    1 Reply Last reply
    0
    • ? Offline
      ? Offline
      A Former User
      wrote on last edited by
      #4

      Ok well here's an interesting discovery I've made, for anyone who finds this thread in the future:

      There seems to be an issue with the driver for the off-brand Arduino Nanos possibly not signalling to the OS correctly, or the implementation that Qt uses just really doesn't like the way that the driver responds. I am referring specifically to the nano clone which uses the QinHeng HL-340 serial peripheral. Not sure why this caused a problem, but there it is. Once I used an official Uno the code worked no problem.

      If I were more patient and had better resources I could possibly trace back the issue, but I do not, so sorry everyone lol.

      As such I'm marking this as resolved.

      1 Reply Last reply
      2
      • Kent-DorfmanK Offline
        Kent-DorfmanK Offline
        Kent-Dorfman
        wrote on last edited by
        #2

        I have strong opinions about correctly doing serial comms, so may come across as terse.

        First place is to look at your serial transaction model. They are rarely well done and often encourage assumptions that conflict with the serial nature of reading streams of characters and processing them in a fault or delay tolerant manner. Unfortunately arduino and pi examples have done a lot of damage to quality coding practices.

        You are using hardware flow control, right? 3wire uart comms bug me to no end. ;^P

        Second. The "correct" way to implement a transactional model from a serial stream is to use the event loop and NOT do blocking IO. Trust readyread() then add any incoming characters to a buffer, after which you scan the buffer for one (or more) identifiable commands and delete them from the head of the buffer, using them to modify the state of you machine.

        Finally, I cannot remember the specifics but I think an older version of Qt5 had an issue with readyready() that was fixed in a more recent version..

        You did say "any help appreciated"

        Good luck

        ? 1 Reply Last reply
        6
        • Kent-DorfmanK Kent-Dorfman

          I have strong opinions about correctly doing serial comms, so may come across as terse.

          First place is to look at your serial transaction model. They are rarely well done and often encourage assumptions that conflict with the serial nature of reading streams of characters and processing them in a fault or delay tolerant manner. Unfortunately arduino and pi examples have done a lot of damage to quality coding practices.

          You are using hardware flow control, right? 3wire uart comms bug me to no end. ;^P

          Second. The "correct" way to implement a transactional model from a serial stream is to use the event loop and NOT do blocking IO. Trust readyread() then add any incoming characters to a buffer, after which you scan the buffer for one (or more) identifiable commands and delete them from the head of the buffer, using them to modify the state of you machine.

          Finally, I cannot remember the specifics but I think an older version of Qt5 had an issue with readyready() that was fixed in a more recent version..

          You did say "any help appreciated"

          Good luck

          ? Offline
          ? Offline
          A Former User
          wrote on last edited by
          #3

          @Kent-Dorfman I'm sure the event loop approach is the better one, since Qt is almost always meant to be used with one, though the application I am developing would require substantial rewrite to support that. I primarily chose Qt due to its cross-platform capabilities, though it would seem that I might be better served by using a different cross-platform serial library at this point, which is unfortunate because I generally really like Qt.

          I've seen older posts referring to the bug you are, but that was supposedly patched in 5.13, and I'm using 5.15.2 (maybe there's a regression?).

          1 Reply Last reply
          0
          • ? Offline
            ? Offline
            A Former User
            wrote on last edited by
            #4

            Ok well here's an interesting discovery I've made, for anyone who finds this thread in the future:

            There seems to be an issue with the driver for the off-brand Arduino Nanos possibly not signalling to the OS correctly, or the implementation that Qt uses just really doesn't like the way that the driver responds. I am referring specifically to the nano clone which uses the QinHeng HL-340 serial peripheral. Not sure why this caused a problem, but there it is. Once I used an official Uno the code worked no problem.

            If I were more patient and had better resources I could possibly trace back the issue, but I do not, so sorry everyone lol.

            As such I'm marking this as resolved.

            1 Reply Last reply
            2

            • Login

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