Is boost::fsm suitable for embedded systems?
Hi, forgive me for my ignorance but I'm a boost newbie... The rationale document for boost::fsm states that the library should meet a number of requirements, numbered from 1 to 9. Especially, the sixth requirement says "support the development of arbitrarily large and complex state machines.". Ok, this may be good - I guess it is in fact good. But I'm a bit anxious that this implies that the library is therefore not suitable for enviroments where no unnecessary overhead is acceptable, like in many embedded applications. However, the seventh requirement indicates that my worries are unjustified since it reads: "allow the user to customize all resource management so that the library could be used for applications with hard real-time requirements". And further down the Rationale document one can read a section on the Resource usage of Memory which looks good. So, just to be sure, is boost::fsm suitable for the development of embedded applications where constraints such as memory footprint is an issue? (Hopefully, someone can answer this based on the experience of using the library or by knowing the code - not by reading the documentation (like me ;-)). Thanks, Thomas S.
Hi Thomas
The rationale document for boost::fsm states that the library should meet a number of requirements, numbered from 1 to 9. Especially, the sixth requirement says "support the development of arbitrarily large and complex state machines.".
Ok, this may be good - I guess it is in fact good. But I'm a bit anxious that this implies that the library is therefore not suitable for enviroments where no unnecessary overhead is acceptable, like in many embedded applications.
I think it is virtually impossible to write a non-trivial library which incurs *no* overhead in all possible applications. While I tried hard to make the library as resource preserving as possible there undoubtedly are situations in which it will perform worse than equivalent hand-written code. How much worse and whether that will ever be noticeable to the "end-user" really depends on your application.
However, the seventh requirement indicates that my worries are unjustified since it reads: "allow the user to customize all resource management so that the library could be used for applications with hard real-time requirements".
IMHO hard real-time requirements are pretty much orthogonal to space/time requirements. Hard real-time simply means that you can calculate/measure upper limits for each and every operation the library performs. So, this requirement was in no way intended to make a statement on how fast the library should be or how small the memory footprint of FSMs should be.
And further down the Rationale document one can read a section on the Resource usage of Memory which looks good.
If these measurements look good to you then I'd encourage you to give it a try.
So, just to be sure, is boost::fsm suitable for the development of embedded applications where constraints such as memory footprint is an issue? (Hopefully, someone can answer this based on the experience of using the library or by knowing the code - not by reading the documentation (like me ).
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. Whether or not it is suitable for your particular application can only be answered if you provide me with some hardware data (memory, type of CPU, processor speed, etc.) and roughly what functionality you want to implement and the space/time requirements you need to satisfy. If you prefer you can send me this information by private email. HTH & Regards, Andreas
Andreas Huber <ah2003 <at> gmx.net> writes:
I think it is virtually impossible to write a non-trivial library which incurs *no* overhead in all possible applications.
Yes, of course (I guess I expressed myself kinda sloppy).
IMHO hard real-time requirements are pretty much orthogonal to space/time requirements.
Agreed. I believe I wanted to interprete and squeeze that requirement to suit my needs...
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. Thanks, /Thomas
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...
Darryl Green <darryl.green <at> unitab.com.au> writes: [boost::fsm experiences snipped] Thanks, that's good to hear! BTW, I haven't forgotten about BOOST_FSM_RELAX_TRANSITION_CONTEXT. I'm currently swamped with other stuff but I'm working on it whenever I find some free time. Hopefully I'll be able to churn out a relase (which also includes exit()) in the next two weeks. Thanks & Regards, Andreas
Thomas Stevens <thomathoma69@yahoo.com> writes:
Hi, forgive me for my ignorance but I'm a boost newbie...
The rationale document for boost::fsm states that the library should meet a number of requirements, numbered from 1 to 9. Especially, the sixth requirement says "support the development of arbitrarily large and complex state machines.".
Ok, this may be good - I guess it is in fact good. But I'm a bit anxious that this implies that the library is therefore not suitable for enviroments where no unnecessary overhead is acceptable, like in many embedded applications.
However, the seventh requirement indicates that my worries are unjustified since it reads: "allow the user to customize all resource management so that the library could be used for applications with hard real-time requirements".
And further down the Rationale document one can read a section on the Resource usage of Memory which looks good.
So, just to be sure, is boost::fsm suitable for the development of embedded applications where constraints such as memory footprint is an issue? (Hopefully, someone can answer this based on the experience of using the library or by knowing the code - not by reading the documentation (like me ;-)).
Thomas, That is a concern of mine, too. You might be interested in http://article.gmane.org/gmane.comp.lib.boost.devel/100599 and http://article.gmane.org/gmane.comp.lib.boost.devel/100637, which has the attachments announced in the earlier message. These FSM frameworks have minimal overhead, suitable for embedded systems. They also have fewer features (so far) than Andreas' design does. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams <dave <at> boost-consulting.com> writes:
That is a concern of mine, too. You might be interested in http://article.gmane.org/gmane.comp.lib.boost.devel/100599 and http://article.gmane.org/gmane.comp.lib.boost.devel/100637, which has the attachments announced in the earlier message.
These FSM frameworks have minimal overhead, suitable for embedded systems. Perfect, but I wonder if the compiler accepts the mpl-code... I'll give it a
This code looks very nice indeed! Neat transition table :-) try. Thanks! /Thomas
Thomas Stevens <thomathoma69@yahoo.com> writes:
David Abrahams <dave <at> boost-consulting.com> writes:
That is a concern of mine, too. You might be interested in http://article.gmane.org/gmane.comp.lib.boost.devel/100599 and http://article.gmane.org/gmane.comp.lib.boost.devel/100637, which has the attachments announced in the earlier message.
This code looks very nice indeed! Neat transition table :-)
These FSM frameworks have minimal overhead, suitable for embedded systems. Perfect, but I wonder if the compiler accepts the mpl-code... I'll give it a try.
Which compiler? It's possible that you'll need the "mplbook" branch of the boost/mpl subdirectory in the current CVS state. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
participants (4)
-
Andreas Huber -
Darryl Green -
David Abrahams -
Thomas Stevens