[boost] Re: Is boost::fsm suitable for embedded systems?

From: Darryl Green (darryl.green_at_[hidden])
Date: 2004-08-30 20:37:10

Thomas Stevens <thomathoma69 <at> yahoo.com> writes:
> Andreas Huber <ah2003 <at> gmx.net> writes:
> > I very much believe that boost::fsm is suitable for many embedded 
> > applications running in confined environments but there definitely 
> > are applications for which the library is too heavy-weight. 
> 
> Ok, it is not just to drag in the boost::fsm then. I'll have to do a
> detailed analyze of the application and its enviroment. 
> 

Only you would know how detailed it needs to be. We did some initial 
prototyping by writing one of the concurrent state machines our system uses 
and testing it out. The generated code certainly isn't small, but it isn't 
bloatware by modern (increasingly decadent) standards. It scales in a 
predictable, basically linear way afaics, so it is reasonable to extrapolate 
if you do some experiments.

The embedded environment I'm using boost::fsm in has some significant resource 
constraints - similar RAM and CPU to a decent desktop PC of a decade ago. I 
don't know how that compares to your case. The most "real-time" part of the 
system uses boost::fsm and it isn't causing any dramas. That said, the hard 
deadlines are around the 1s mark, though it has to handle 100s of events 
inside that time.

We did try experiment with the earlier mpl example fsm (in mpl docs - I 
haven't experimented with the code in Dave's posts) and while it worked it was 
(understandably) much less comprehensive than Andreas's framework. Maybe an 
mpl expert could produce an extended fsm that was genuinely lightweight, but 
to be prefectly honest, while the mpl stuff is cool, I don't find the basic 
example fsms a big advantage over the sort of table driven fsm implementations 
that are common in C etc.

If all you really need is a very simple fsm, the alternatives to boost::fsm 
are many. OTOH, it is relatively less likely that you have a performance 
problem in the first place (but who knows - maybe you really need a fpga). If 
you need more complex nested and concurrent state machines, boost::fsm is the 
fastest way to assemble them I've seen. Other features, like the context 
concept, may be seen as unncessary overhead or a really important and 
efficient feature depending on your system design.

Regards
Darryl.

If what you want is a really lightweight fsm, use goto...