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?

Quote:

---

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.

Quote:

---

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:

Quote:

---

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.

d_stranz is exactly right.

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