Re: [boost] [MSM] Comparison with ad-hoc FSM implementation
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
Christophe Henry wrote:
I just added in the sandbox (msm/libs/msm/doc) a BoostCon09 subdirectory.
[ Does anyone know if the Boost svn / web server can be tweaked to show a directory listing when I visit http://svn.boost.org/svn/boost/sandbox/msm/libs/msm/doc/BoostCon09/ with a web browser? Currently I just see a blank page. I can see the contents only using svn ls. My own apache+svn server does show directory listings, so presumably it is down to a config setting somewhere. ]
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.
Well maybe not "exactly"....
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?)
I didn't generalize like you suggested.
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.
It looks to me as if your implementation has ignored the left button (previous track / rewind) entirely, right?. If you had implemented it you would need to do so by copying and pasting the code for the right button, which already shares nothing with the code for the other buttons. I feel that I have to mention this after your earlier complaints about how anyone maintaining my code would have to resort to copy and paste and how this would inevitably lead to errors: it now looks to me as if MSM is in fact more reliant on copy-and-paste, not less.
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" ;-)
Divide-and-conquer can be applied to most/all design approaches. It is not unique to MSM. Personally I do not find your code particularly easy to follow, but that may be due to my limited knowledge of UML terminology. Regards, Phil.
participants (2)
-
Christophe Henry -
Phil Endecott