Results 1 to 4 of 4

Thread: QSerialPort responces

  1. #1
    Join Date
    Jun 2007
    Location
    Louisiana
    Posts
    77
    Thanks
    1
    Qt products
    Qt3 Qt4 Qt5
    Platforms
    Unix/X11 Windows

    Default QSerialPort responces

    I know that similar questions have been asked on this and other forums so don't bother with that response. None of them address my specific question.

    I have an application that communicates with an embedded processor through a serial interface. The data words are of variable but known data patterns

    I can open and read and write to the serial port just fine. Commands are sent to the serial port and data is read in response.

    My problem is that the embedded microprocessor does not respond to commands with the same response time. One command may only take milliseconds and another may take 2 seconds or more. That part is not within programmatic control.

    My problem is that I do not want an asynchronous read to block the GUI. For instance if a command is issued that takes 2-3 seconds to respond, the main thread does one of two things.

    1) When using a blocking approach. the application stalls waiting on the readyRead() signal.
    2) Using the non-blocking approach the application is much more responsive but has data from multiple commands intermixed.

    So, I think I know the answer to this problem but I seek the wisdom of the group. I think the probable answer would be to use a circular buffer and just wait for a readyRead() to dump data into it. In a separate process, evaluate the data and call the appropriate function to respond.

    The problem with this approach is that commands may be issued before the last response is complete.
    For instance, cmd1 is issued and it takes 2.5 seconds to respond and unload data. Before the response and data download has completed a new command (cmd2) is issued. The new command my have a quicker response time (700ms) than the older and longer responding command. That means that the data from the second command my be interleaved with the first.

    So how does one handle the command / response mixture?

  2. #2
    Join Date
    Jan 2006
    Location
    Munich, Germany
    Posts
    4,714
    Thanks
    21
    Thanked 418 Times in 411 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows

    Default Re: QSerialPort responces

    The problem with this approach is that commands may be issued before the last response is complete.
    how is that possible?
    If you have only one serial bus, and you are in the middle of downloading data from your device as a response to cmd1, how could you send cmd2 to the device while your still downloading data from the device over the same serial bus?

    From what you wrote, commands must be serialized due to the nature of the bus.
    You send cmd1, wait, download data, only then send cmd2 and respond to it, etc.
    ==========================signature=============== ==================
    S.O.L.I.D principles (use them!):
    https://en.wikipedia.org/wiki/SOLID_...iented_design)

    Do you write clean code? - if you are TDD'ing then maybe, if not, your not writing clean code.

  3. #3
    Join Date
    Jan 2008
    Location
    Alameda, CA, USA
    Posts
    5,230
    Thanks
    302
    Thanked 864 Times in 851 Posts
    Qt products
    Qt5
    Platforms
    Windows

    Default Re: QSerialPort responces

    how is that possible?
    I think what the OP is saying is that commands are processed asynchronously by the embedded microprocessor and that some commands may take significantly longer to process than others. So in a non-blocking implementation where a slow command is followed by a fast command the response to the fast command may arrive before the response to the slow command.

    But:

    The data words are of variable but known data patterns
    which implies that even if the responses do not arrive in the same order as the commands it should be possible to match up the command-response pairs.

    So I would go for a non-blocking approach and put some better smarts on the application side to match up the command-response pairs and process accordingly. Alternatively, consider moving communication with the device to a separate, non-GUI thread and use a blocking implementation. Communicate with the GUI through signals from the communication thread so the GUI stays alive.
    <=== The Great Pumpkin says ===>
    Please use CODE tags when posting source code so it is more readable. Click "Go Advanced" and then the "#" icon to insert the tags. Paste your code between them.

  4. #4
    Join Date
    Jun 2007
    Location
    Louisiana
    Posts
    77
    Thanks
    1
    Qt products
    Qt3 Qt4 Qt5
    Platforms
    Unix/X11 Windows

    Default Re: QSerialPort responces

    d_stranz is exactly right.

    The suggestion crossed may mind but I got stalled trying to resolve the processing. Thanks for the suggestion.

Similar Threads

  1. QSerialPort and QThread
    By maratk1n in forum Qt Programming
    Replies: 12
    Last Post: 5th May 2017, 23:50
  2. QSerialPort
    By fmarques in forum Qt Programming
    Replies: 0
    Last Post: 20th April 2016, 17:04
  3. QserialPort
    By arturs in forum Newbie
    Replies: 0
    Last Post: 13th May 2015, 21:37
  4. QSerialport in multithread
    By snow_starzz in forum Newbie
    Replies: 3
    Last Post: 3rd December 2013, 11:18
  5. Qt5 cmake and QSerialPort
    By Chris.Burner in forum Newbie
    Replies: 1
    Last Post: 21st April 2013, 17:13

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Digia, Qt and their respective logos are trademarks of Digia Plc in Finland and/or other countries worldwide.