State Machine to C code and back
-
Hello, I am searching for tools that allow you to design a state machine and generate the corresponding C code. As a bonus, I would like the tool to: - given the source code, generates the state machine - allow to easily switch between a State Machine view (high level), to source code view (detail, low level) - the State Machines are saved in a Git/CSV/SVN friendly format Any suggestions ? I easily found Home - Modern Embedded Software | Quantum Leaps[^], but found it to have a too steep learning curve.
-
Hello, I am searching for tools that allow you to design a state machine and generate the corresponding C code. As a bonus, I would like the tool to: - given the source code, generates the state machine - allow to easily switch between a State Machine view (high level), to source code view (detail, low level) - the State Machines are saved in a Git/CSV/SVN friendly format Any suggestions ? I easily found Home - Modern Embedded Software | Quantum Leaps[^], but found it to have a too steep learning curve.
There's a member on this website named Honey the Codewitch. This member is quite knowledgeable about compiler design and has written several articles that you might find very helpful. Search for articles by this member.
The difficult we do right away... ...the impossible takes slightly longer.
-
There's a member on this website named Honey the Codewitch. This member is quite knowledgeable about compiler design and has written several articles that you might find very helpful. Search for articles by this member.
The difficult we do right away... ...the impossible takes slightly longer.
Thanks, I will do so.
-
Hello, I am searching for tools that allow you to design a state machine and generate the corresponding C code. As a bonus, I would like the tool to: - given the source code, generates the state machine - allow to easily switch between a State Machine view (high level), to source code view (detail, low level) - the State Machines are saved in a Git/CSV/SVN friendly format Any suggestions ? I easily found Home - Modern Embedded Software | Quantum Leaps[^], but found it to have a too steep learning curve.
Hoping for some program to translate a C program (in the sense "an arbitrary C program") into a state machine is naively optimistic. Even if that C program was initially generated from a state machine model, so you could hope to recognize code key patterns allowing you to identify code fragments handling specific state transitions etc., most programmers feel the freedom to not give a sh*t about FSM principles, so they toss the code all over the place, making it impossible to recognize the pieces. What you can do is to provide a framework for editing the FSM as a FSM, and let the developer specify the actions of each individual transition within that framework. Then, the framework can lay out the code for each transition (as well as the common logic for the state transitions themselves). This is actually one of my current pet projects. Maybe I will write a CP article about it some day. It is far from ready yet, but if you would like to discuss it directly with me, send me an email. Maybe that could help pushing my hobby project forward :-)
-
Hoping for some program to translate a C program (in the sense "an arbitrary C program") into a state machine is naively optimistic. Even if that C program was initially generated from a state machine model, so you could hope to recognize code key patterns allowing you to identify code fragments handling specific state transitions etc., most programmers feel the freedom to not give a sh*t about FSM principles, so they toss the code all over the place, making it impossible to recognize the pieces. What you can do is to provide a framework for editing the FSM as a FSM, and let the developer specify the actions of each individual transition within that framework. Then, the framework can lay out the code for each transition (as well as the common logic for the state transitions themselves). This is actually one of my current pet projects. Maybe I will write a CP article about it some day. It is far from ready yet, but if you would like to discuss it directly with me, send me an email. Maybe that could help pushing my hobby project forward :-)
Quote:
Hoping for some program to translate a C program (in the sense "an arbitrary C program") into a state machine is naively optimistic.
100% agree with you. I meant that the tool/framework could generate the FSM some code itself had generated. It should be easier, although not trivial at all.
Quote:
What you can do is to provide a framework for editing the FSM as a FSM, and let the developer specify the actions of each individual transition within that framework. Then, the framework can lay out the code for each transition (as well as the common logic for the state transitions themselves).
That seems something more reasonable to do. My worries in this case is switching between the FSM view and the source code view. It should be easy to edit an FSM, generate the source code and then let the programmer add custom code to actions. But how to you proceed when the user wants to edit the FSM ? What happens to the custom logic that was added ?
Quote:
This is actually one of my current pet projects. Maybe I will write a CP article about it some day. It is far from ready yet, but if you would like to discuss it directly with me, send me an email. Maybe that could help pushing my hobby project forward
Will do :thumbsup:
-
Quote:
Hoping for some program to translate a C program (in the sense "an arbitrary C program") into a state machine is naively optimistic.
100% agree with you. I meant that the tool/framework could generate the FSM some code itself had generated. It should be easier, although not trivial at all.
Quote:
What you can do is to provide a framework for editing the FSM as a FSM, and let the developer specify the actions of each individual transition within that framework. Then, the framework can lay out the code for each transition (as well as the common logic for the state transitions themselves).
That seems something more reasonable to do. My worries in this case is switching between the FSM view and the source code view. It should be easy to edit an FSM, generate the source code and then let the programmer add custom code to actions. But how to you proceed when the user wants to edit the FSM ? What happens to the custom logic that was added ?
Quote:
This is actually one of my current pet projects. Maybe I will write a CP article about it some day. It is far from ready yet, but if you would like to discuss it directly with me, send me an email. Maybe that could help pushing my hobby project forward
Will do :thumbsup:
My approach is to do all model editing in the FSM editor. Anything related to state transitions, testing whether a transition is legal, possible transfer to an error state etc. etc. When the general FSM logic has done its job identifying a transition to be taken, there frequently is a set of updates to state variables, beyond the ID of the new state - it could be things like starting a timer, zeroing a buffer or setting flags that are tested by future state transitions. These are all specified in a general way in the FSM - think of it as quite formalized pseudocode. This is where code editing comes it: For that specific set of state variable updates, the coder writes a "real" implementation. This usually goes little beyond simple assignment statements. Then a transition may have side effects - generally: raising events in other FSMs. Sending a message is an example. Even this is specified in formalized pseudocode in the FSM, and the developer translates that logic to some real code. The FSM is edited as a state table - a set of squares in the crosspoint between current state and event. Each square identifies a condition for the transition to be legal (as a logic expression on a restricted set of bool functions). Then comes the ID of the next state if the transition is taken, followed by the ID of the function updating the state variables (which also is usually a limited set), and the ID of the function taking care of the side effects. Clicking on either of these four fields to take you to the details of the function. One thing I picked up from rather complex OSI protocol state machines: If the test on the state variables shows that a transition is not legal, maybe some other transition is legal. (The very trivial case: If a state variable x is true, make this transition, otherwise make that transition.) Purists say that this should be treated as two completely indepenent states, but allowing tests on other variables than just the current state is essential to avoid an explosion of states. The general FSM editing is independent of programming language. From the tables, a code skeleton can be genereated, calling those functions for testing and updating state variables and causing side effects that the programmer wrote. So you may have one common FSM model for different languages, provided that you have written a skeleton generator for each relevant language. One remaining "problem" (if it is): My generator will produce a complete set of source files that may be set up e.g. as a Visual
-
My approach is to do all model editing in the FSM editor. Anything related to state transitions, testing whether a transition is legal, possible transfer to an error state etc. etc. When the general FSM logic has done its job identifying a transition to be taken, there frequently is a set of updates to state variables, beyond the ID of the new state - it could be things like starting a timer, zeroing a buffer or setting flags that are tested by future state transitions. These are all specified in a general way in the FSM - think of it as quite formalized pseudocode. This is where code editing comes it: For that specific set of state variable updates, the coder writes a "real" implementation. This usually goes little beyond simple assignment statements. Then a transition may have side effects - generally: raising events in other FSMs. Sending a message is an example. Even this is specified in formalized pseudocode in the FSM, and the developer translates that logic to some real code. The FSM is edited as a state table - a set of squares in the crosspoint between current state and event. Each square identifies a condition for the transition to be legal (as a logic expression on a restricted set of bool functions). Then comes the ID of the next state if the transition is taken, followed by the ID of the function updating the state variables (which also is usually a limited set), and the ID of the function taking care of the side effects. Clicking on either of these four fields to take you to the details of the function. One thing I picked up from rather complex OSI protocol state machines: If the test on the state variables shows that a transition is not legal, maybe some other transition is legal. (The very trivial case: If a state variable x is true, make this transition, otherwise make that transition.) Purists say that this should be treated as two completely indepenent states, but allowing tests on other variables than just the current state is essential to avoid an explosion of states. The general FSM editing is independent of programming language. From the tables, a code skeleton can be genereated, calling those functions for testing and updating state variables and causing side effects that the programmer wrote. So you may have one common FSM model for different languages, provided that you have written a skeleton generator for each relevant language. One remaining "problem" (if it is): My generator will produce a complete set of source files that may be set up e.g. as a Visual
Your project might move along faster if you targeted your FSM editor to my session processing framework in the Robust Services Core sb[^] directory. I've yet to write any CP articles about it, because the lower level parts of that code base are useful to a much wider audience. But there's a fair amount of documentation[^] and examples; scroll to the bottom of that page. It's essentially the framework used in a GSM MSC that evolved to LTE and is still seeing development. It has run-time support, TLV messaging, state machines that can observe and override the behavior of others, and even overload controls. A tool would be very useful even if it simply generated the C++ boilerplate needed when deriving from the classes defined by that framework.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.
