Differences

This shows you the differences between two versions of the page.

--- wiki:features [2012/10/22 19:56] – pmueller
+++ wiki:features [2012/12/18 10:42] – pmueller
@@ Line 15: / Line 15: @@
 SinelaboreRT does not force you in any way on how you design your system. Therefore it is no problem to use the generated code in the context of a real-time operating system or within an interrupt service routine or in a foreground / background system. The generation process can be influenced to meet specific needs.
-How does SinelaboreRT work? From a state-chart design file created with the Cadifra UML editor, Enterprise Architect, UModel or Magic Draw the code-generator generates the complete statemachine implementation. For an example design file called oven.cdd the command line looks like java -jar codegen.jar -p CADIFRA -o oven.cdd. As an result files will be generated:
+How does SinelaboreRT work? From a state-chart design file created with the Cadifra UML editor, Enterprise Architect, UModel or Magic Draw the code-generator generates the complete statemachine implementation. For an example design file called oven.cdd the command line looks like
+<code bash>
+java -jar codegen.jar -p CADIFRA -o oven oven.cdd
+</code>
+As an result files will be generated:
   * oven.c implements the state-machine as graphically specified in the oven.cdd file
@@ Line 26: / Line 33: @@
 ===== Supported State Chart Elements =====
-**Hierarchical state definition**: State machines can be hierarchical or flat. A state with sub-states is called a hierarchical state-machine. States can have entry code that is always executed if a state is entered. Exit code is executed whenever the state is left. A state can also have action code. The action code is executed whenever the state is active just before event transitions are evaluated. Presently three levels of state nesting are supported.
+**Hierarchical state definition**: State machines can be hierarchical or flat. A state with sub-states is called a hierarchical state-machine. States can have entry code that is always executed if a state is entered. Exit code is executed whenever the state is left. A state can also have action code. The action code is executed whenever the state is active just before event transitions are evaluated.
+** Regions **: Regions allow to model parallel behavior within the same state machine diagram. The benefit of using regions is to explicitly show the this parallel behavior instead of creating different state diagrams.
 **Transitions**: There are two types of transitions a) event based ones and b) conditional ones. Event based transitions are triggers coming from the outside of a state-machine. An event based transition has the following syntax:
@@ Line 37: / Line 46: @@
 **History States**:  When leaving a hierarchical state and entering it the next time the default state us usually entered. If the last active state should be entered instead a shallow history marker can be placed in the state. If you want to activate the history for all sub-states of the state then use the deep history marker instead. Macros are provided to reset the history if needed.
-**Interactive Test and Simulation**: If the command line flag ’-s’ (for simulation) is used, the code generator turns into interactive mode after parsing the input file. No code is produced then. After parsing the input file you can type in events and check what the state machine’s reaction is. During a simulation step all code that is executed as the reaction to an event is printed out (e.g. the OnEntry code). When using the command line flag ‘-S’ the graphical simulation is started.
+**Interactive Test and Simulation**: If the command line flag ''-s'' (for simulation) is used, the code generator turns into interactive mode after parsing the input file. No code is produced then. After parsing the input file you can type in events and check what the state machine’s reaction is. During a simulation step all code that is executed as the reaction to an event is printed out (e.g. the OnEntry code). When using the command line flag ''-S'' the graphical simulation is started.
 {{:builtin_editor.jpg|}}
@@ Line 43: / Line 52: @@
 **Debugging / Trace Support**: In the *_dbg.h file two helper functions are provided that are useful for debugging state machines. The function *_GetNameByState(id) returns the name of the state the function *_GetNameByEvent(id) returns the name of an event each identified by its id. Trace statements can be automatically added to the machine. This allows to follow the flow of events.
-**Integrated State-Diagram Editor**: Using the command line flag ‘-E’ brings up the integrated state diagram editor. It provides an efficient tree based entry method. The graphical representation is created automatically. So you can fully focus on the modeling task.
+**Integrated State-Diagram Editor**: Using the command line flag ''-E'' brings up the integrated state diagram editor. It provides an efficient tree based entry method. The graphical representation is created automatically. So you can fully focus on the modeling task.
 [[wiki:Download|Download]] the trial version and test the generator. Your feedback is welcome!