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. [SOLVED] QSerialPort and Data Loss on Linux
QtWS25 Last Chance

[SOLVED] QSerialPort and Data Loss on Linux

Scheduled Pinned Locked Moved General and Desktop
serial portdata losslinux
7 Posts 4 Posters 3.9k 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.
  • L Offline
    L Offline
    Leonardo
    wrote on 18 May 2015, 21:58 last edited by Leonardo
    #1

    Hello, everyone. I have a TTL printer and I send data to it using an USB-TTL converter. It works perfectly on Windows, but on Linux it's like some data is missing. I have some gaps in the printing output. As I said, it works fine on Windows, so I am assuming it's not really a problem related to Qt, but most likely to Linux. I've decided to ask here anyway, because I need to ensure a consistent behavior across platforms, and maybe some more experienced Qt programmer have already faced this before. I don't think QSerialPort itself can do much for me, but I don't know what else to try. I've been reading a lot about data loss in serial communication, but I haven't found anything applicable to Qt. Here's my code:

    port = new QSerialPort("/dev/ttyUSB0", this);
    port->setBaudRate(38400);
    port->setParity(QSerialPort::Parity::NoParity);
    port->setDataBits(QSerialPort::DataBits::Data8);
    port->setStopBits(QSerialPort::StopBits::OneStop);
    port->setFlowControl(QSerialPort::FlowControl::SoftwareControl);
    if(port->open(QIODevice::OpenModeFlag::ReadWrite)){
    ....
    

    Could anyone help me?

    Thank you.

    1 Reply Last reply
    0
    • M Offline
      M Offline
      mcosta
      wrote on 18 May 2015, 23:32 last edited by
      #2

      Hi,

      to exclude some programming error you should verify that all your data are correctly sent to the device.

      If the transmission is ok, probably the problem is inside the device driver; i suggest to read the device manual to see how to set-up the driver. (usually drivers are shipped with test programs that allows to test the configuration).

      Have you checked if the driver is correctly loaded?

      Once your problem is solved don't forget to:

      • Mark the thread as SOLVED using the Topic Tool menu
      • Vote up the answer(s) that helped you to solve the issue

      You can embed images using (http://imgur.com/) or (http://postimage.org/)

      1 Reply Last reply
      0
      • L Offline
        L Offline
        Leonardo
        wrote on 19 May 2015, 01:42 last edited by Leonardo
        #3

        Hi. I don't think it's a programming error, because it's working on Windows, but I've logged to a text file everything sent to the port anyway, right before

         port->write(data);
         port->waitForBytesWritten(-1);
        

        I did it both on Windows and Linux and the output was the same. So the binary data my application produces is consistent.

        The driver also loads without raising any error or warning.

        [ 6.510918] USB Serial support registered for generic
        [ 6.522729] usbserial: USB Serial Driver core
        [ 6.551413] usbcore: registered new interface driver cp210x
        [ 6.568382] USB Serial support registered for cp210x
        [ 6.584142] cp210x 3-1.4:1.0: cp210x converter detected
        [ 6.672059] usb 3-1.4: reset full-speed USB device number 4 using musb-hdrc
        [ 6.782817] usb 3-1.4: cp210x converter now attached to ttyUSB0

        I've tried updating it to the latest one I could find compatible with my kernel, but it didn't seem to have had any effect.

        Based on what I've been reading, I feel it's somehow related to these parameters:

        # stty -a -F /dev/ttyUSB0
        speed 115200 baud;stty: /dev/ttyUSB0
        line = 0;
        intr = ^C; quit = ^; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
        lnext = ^V; flush = ^O; min = 1; time = 0;
        -parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
        -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel -iutf8
        opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
        isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke

        But I have no idea what they mean. :-(

        1 Reply Last reply
        0
        • H Offline
          H Offline
          hpollak
          wrote on 19 May 2015, 05:15 last edited by
          #4

          Have you tried to call flush() after the write?

          1 Reply Last reply
          0
          • M Offline
            M Offline
            mcosta
            wrote on 19 May 2015, 05:26 last edited by
            #5

            @Leonardo Sorry no Idea.

            I only see the port support baudrate at 115200 and you're using 38400 (but I think is not an error)

            Once your problem is solved don't forget to:

            • Mark the thread as SOLVED using the Topic Tool menu
            • Vote up the answer(s) that helped you to solve the issue

            You can embed images using (http://imgur.com/) or (http://postimage.org/)

            1 Reply Last reply
            0
            • K Offline
              K Offline
              kuzulis
              Qt Champions 2020
              wrote on 19 May 2015, 07:07 last edited by
              #6

              Also maybe the reason is in SoftwareControl, because this mode (and HardwareControl) are not tested properly.. Maybe you can use "strace" to check for data that are really written to driver.

              1 Reply Last reply
              0
              • L Offline
                L Offline
                Leonardo
                wrote on 20 May 2015, 00:25 last edited by
                #7

                Hello, everyone. After some hours of debugging, I could finally find the problem. Long story short: apparently, the Linux driver for CP210x USB-TTL converter does not implement software flow control, but only hardware flow control. I've moved to the latter and it's working like a charm now. Thank you all for your help.

                1 Reply Last reply
                0

                4/7

                19 May 2015, 05:15

                • Login

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