Re: QSerialPort responces
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.
Re: QSerialPort responces
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.
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.