Re: [boost] [MSM] Comparison with ad-hoc FSM implementation

Subject: Re: [boost] [MSM] Comparison with ad-hoc FSM implementation
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2009-12-12 19:25:41

>One interesting feature is that there are several buttons that have
>different actions associated with short and long presses.  So I can
>imagine per-button state machines that do something like:
>
>  UP  --pressed-->  DOWN  --timeout-->  LONG_DOWN
>      <--released----                       |
>      <---------------------released--------+
>
>These could feed events like left_button_short_press,
>right_button_long_release etc into a main state machine.
>
>Can you outline how you would implement this in MSM?

I implemented it exactly as you described.

>I can see how you
>could store the button identifier as event state and send e.g.
>short_press(left_button) to the main state machine, but this would then
>need transition rules using guards to test the button id.  (I don't
>think this is an application for a sub state machine because each
>button's machine runs concurrently, right?)

To make the follwowing answer clear, I just added in the sandbox
(msm/libs/msm/doc) a BoostCon09 subdirectory. You will find the
diagrams (top fsm, menu and playing submachines) and an implementation
using a standard front-end and for the fun, another one using eUML
(tested with VC9 and g++-4.3).

I didn't generalize like you suggested. Though I like your solution
and it is probably going to work, I didn't want to make the example
more complicated (it is already complicated enough).
To solve the concurrency problems, I simply added more regions and
each button is handled in one of them. It is not such a big repetition
because the south button has its own handling anyway.

The interesting and complex part is not so much the button handling,
which could be done with an ad-hoc solution too, but the separation of
tasks between the regions. One handles the hold button and stops all
processing using an interrupt state, some handle the buttons, and
others are simply here to give to an hardware event (like using the
middle button) a different meaning according to the state where the
state machine is. For example, CheckMiddleButton is doing just this.
Only one state. All regions are small, and each handles a very
specific part of the problem. See it as a sort of "divide and conquer"
;-)

The whole point of the example was to show how, using UML techniques
supported by MSM, writing a mock-up for an iPod was easier than using
an ad-hoc solution.
We spent 90mn purely on diagram and used a tool to generate the code instantly.
And this was the second point, to show how MSM was supporting a
model-based approach and that such a tool was feasible.

Christophe