sequential execution of commands using serial communication between PC and device

[anita.niharika@gmail.com]

Hi d_stranz,

I gone through the link which you mentioned above. In examples, state transition or connect method uses graphical signal mechanism (I mean by clicking a button).
In my case, through serial communication based on response success/failure result.

For example, The request to device connect request is from sender and response is updated in serial handler by reading a particular bit to decide device is connected/disconnected. So based on this, the now sender side has to take a call for further command processing. How does sender get this info? I don't have any graphical button to connect state transition.

Similarly, I have another device where it would require same mechanism. When both device connected, then rest of my application starts running.
Could you please give sample, which would help me to implement further.

Best Regards,
Anita

[d_stranz]

I don't have any graphical button to connect state transition.

Start thinking outside of the box. Any QObject-based class can emit signals, and any QObject-based class can have slots that are connected to signals.

I have implemented a very complex state machine using the Qt framework. Almost none of the state transitions are triggered by buttons (or any other UI thing). It has several hundred states and transitions and the diagram I drew is almost 1m^2. Most transitions are triggered by a signal from some other state, based on some status value.

In your case, you have at least four states: the "not started yet" state, the "execute next command" state, the "process reply" state, the "no more commands" (final) state and maybe an "error" state, and at least four transitions: the "start executing" transition that moves the machine from the "not started" into the "execute next command" state. The "execute command state" pulls the next command off the queue and starts executing. The "readyRead" signal from your serial port causes the transition into the "process reply" state, which evaluates the response and either causes a transition back to the "execute next command" state or into the "error" state. When the "execute next command" state runs out of things to do, it emits a signal that causes the transition to the "no more commands" state.

When you build the state machine in code, you have to define all of these states and transitions (by deriving from QAbstractState or QAbstractTransition if needed) and connecting the correct signals to slots.

It will probably be helpful you (like it was for me) to draw your state machine on paper, with a box for each state, and arrows that label the transitions between states and the things that trigger them. You might discover that you need more or fewer states or transitions than the ones I have described above.