start
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| start [2018/06/11 21:04] – [Generate efficient source code from UML state diagrams and activity diagrams!] pmueller | start [2024/04/02 19:56] (current) – [How do I use it?] webmin | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | {{description>SinelaboreRT | + | {{htmlmetatags> |
| + | metatag-keywords=(UML StateMachine Codegenerator Codegeneration) | ||
| + | metatag-description=(Code generator to build modern and robust event-driven embedded real-time systems based on hierarchical | ||
| - | ====== Generate efficient source code from UML state diagrams and activity diagrams! ====== | + | ~~NOTOC~~ |
| - | ===== Build robust event-driven embedded real-time software based on hierarchical | + | ====== Generate production ready source code from UML state diagrams ====== |
| + | ===== What is Sinelabore? ===== | ||
| + | Sinelabore enables developers to effectively combine event-driven architecture, | ||
| - | Sinelabore// | + | {{:: |
| - | ---- | + | ===== What can Sinelabore do for me as a software developer for the IoT or for critical applications? ===== |
| - | ====== How does it work? ====== | + | Many systems are likely candidates for implementation as finite state machines. A system that must sequence a series of actions or that must handle inputs differently depending on the mode it is in is often best implemented as a finite state machine. Typical examples are control-logic-oriented applications such as metering, monitoring, workflows and control applications. For **IoT applications** where parts of the application are implemented in Java / Python / C# / Lua / Rust / JavaScript / Go or Swift, the code can also be generated in these languages. |
| - | Covert your UML state-machine | + | ===== What can Sinelabore do for me as an embedded software developer? ===== |
| + | Sinelabore// | ||
| - | {{: | ||
| - | **Key Features** | + | ===== How do I use the Code-Generator? |
| - | * Automatic generation | + | Use your existing favourite modelling tool and generate code from it with an **easy-to-use command line tool**. Or use the [[wiki: |
| - | * Can be used with any 8-, 16- or 32-bit target, with or without OS/RTOS. There is no run-time environment needed. | + | |
| - | * Fits well in different system designs. The code-generator does not dictate 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. | + | |
| - | * No gap between design and code | + | |
| - | <columns 80% 50% - -> | + | <WRAP center round download 100%> |
| - | * Use the UML tool of your choice: | + | [[wiki:accepted_download| Download & Try it! There are examples for various |
| - | * Cadifra | + | ]] |
| - | * UModel | + | </WRAP> |
| - | * Magic Draw | + | |
| - | * Enterprise Architect | + | |
| - | * SSC (built in editor) | + | |
| - | * Metamill | + | |
| - | <newcolumn> | + | |
| - | \\ | + | |
| - | * ArgoUML | + | |
| - | * astah* / astah SysML | + | |
| - | * Visual Paradigm | + | |
| - | * Modelio | + | |
| + | ===== Does the Code Generator run on my OS? ===== | ||
| + | The Sinelabore code generator runs on any OS that supports a modern Java Version e.g. Windows, | ||
| + | Linux, macOS or from within a container. | ||
| - | </columns> | + | ===== Can I use the generated code on my embedded platform? ===== |
| + | {{:: | ||
| + | * Generated code has production-quality. It is based on nested '' | ||
| + | * Can be used with any 8-, 16- or 32-bit CPUs. There is **no run-time environment needed** like with some other solutions. | ||
| + | * Fits well in different system designs. The code generator **does not dictate how you design your system**. Therefore it is no problem to use the generated code in the context of a real-time operating system (VxWorks, FreeRTOS, embOS, RTEMS, ...) or within an interrupt service routine or in a foreground / background (super loop) system. | ||
| + | * There will be **no problems when using static code analyzers**. | ||
| + | * Generated cpp code passes clang-tidy and is cpp11 ready (modernize-*). Set configuration parameters accordingly. | ||
| + | |||
| + | |||
| + | ===== How Sinelabore Improves Developer Productivity ===== | ||
| + | Avoid bugs that can waste countless hours of developer and end-user time before they are found. Developers spend a lot of their time coding state machines by hand. | ||
| + | {{:: | ||
| + | And have to do it whenever the design changes. Sinelabore avoids the error-prone and tedious hand-coding by generating high-quality source code directly from the state machine design document. | ||
| + | * No gap between design and code anymore. The documentation is always up to date. | ||
| + | * Use the UML tool of your choice: [[wiki: | ||
| + | * [[wiki: | ||
| * Use the code generator only for those parts of your software that benefit from state machine modeling and code generation. Use your existing development environment for all the other code. The code-generator does not dictate an “all or nothing” approach as many other commercial tools. | * Use the code generator only for those parts of your software that benefit from state machine modeling and code generation. Use your existing development environment for all the other code. The code-generator does not dictate an “all or nothing” approach as many other commercial tools. | ||
| * Automatic robustness tests, test-case generation, tracing and simulation | * Automatic robustness tests, test-case generation, tracing and simulation | ||
| - | * Extensive | + | * Extensive |
| + | ===== Secure, On-site Code Generation ===== | ||
| + | The code generator runs locally on your developer workstations, | ||
| + | {{:: | ||
| + | It does not use an internet connection and will never collect nor submit data, code, statistics, analytics, or any other information from your system over any channel. | ||
| - | ---- | ||
| - | ====== How to get started? ====== | + | ===== Generate code in the shortest time ===== |
| - | [[wiki:download| Download]] the demo version | + | To get an impression of the powerful capabilities of the tool [[wiki:accepted_download| download]] the demo version. |
| - | Then you have basically | + | To run the code you have two options. |
| - | * Run the examples on your PC. The example folder contains examples for all supported modelling tools and various languages (C, C++, ...). The examples realizes a microwave oven and can be executed and tested. Play with the model and enhance it. Regenerate the code and learn from the warning and error messages. | + | * Run the examples on your PC. The example folder contains examples for all supported modelling tools and various languages (C, CPP, ...). The examples realizes a microwave oven and can be executed and tested. Play with the model and enhance it. Regenerate the code and learn from the warning and error messages. |
| * Run examples on a Micro-Controller e.g. a MSP430 evaluation board using Energia. An example with all details is available [[https:// | * Run examples on a Micro-Controller e.g. a MSP430 evaluation board using Energia. An example with all details is available [[https:// | ||
| - | ====== What customers say ====== | + | ===== Customers and what customers say ===== |
| + | |||
| + | The Sinelabore Code Generator is used world wide by very well known tier 1 companies and OEMs. But also small engineering companies as well as single developers. | ||
| //" | //" | ||
| Line 62: | Line 76: | ||
| //"We like Your Tool, infact we will give intro for another local company next week."// | //"We like Your Tool, infact we will give intro for another local company next week."// | ||
| + | |||
| + | |||
| + | Study done by "// | ||
| ---- | ---- | ||
| - | ---- | + | |
| - | ====== Using State-Machines in (Low-Power) Embedded Systems ====== | + | ===== Using State-Machines in (Low-Power) Embedded Systems ===== |
| + | Reactive systems are characterized by a continuous interaction with their environment. They typically continuously receive inputs (events) from their environment and − usually within quite a short delay − react on these inputs. Reactive systems can be very well described with the help of state machines. State machines allow to develop an application in an iterative way. States in the state diagram often correspond to states in the application. The resulting model helps to manage the complexity of the application and to discuss it with colleagues from other departments (and domains). | ||
| + | State machines are very useful for control-oriented applications where attributes such as reliability, | ||
| + | |||
| + | {{ : | ||
| + | ===== System Architecture ===== | ||
| + | |||
| There are different ways how to integrate state machines in a specific system design. Some design principles are more applicable for developers of deeply embedded systems. Others more relevant for developers having not so tight resource constraints. | There are different ways how to integrate state machines in a specific system design. Some design principles are more applicable for developers of deeply embedded systems. Others more relevant for developers having not so tight resource constraints. | ||
| + | |||
| + | The Sinelabore// | ||
| + | Generated code fits well in different system designs. The code generator does not dictate 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. | ||
| ==== Using state machines in a main-loop ==== | ==== Using state machines in a main-loop ==== | ||
| - | In this design an endless loop — typically the main function — calls one or more state machines after each other. | + | In this design an endless loop — typically the main function — calls one or more state machines after each other. |
| - | {{:wiki:mainloop.png?150 |}} It is still one of the most common ways of designing small embedded systems. The event information processed from the state machines might come from global or local variables fed from other code or IRQ handlers. The benefits of this design are no need for a runtime framework and only little RAM requirements. | + | {{ :mainloop.svg?150|Using state machines in a main-loop}} |
| + | It is still one of the most common ways of designing small embedded systems. The event information processed from the state machines might come from global or local variables fed from other code or IRQ handlers. The benefits of this design are no need for a runtime framework and only little RAM requirements. | ||
| The consequences are: | The consequences are: | ||
| Line 91: | Line 119: | ||
| ==== Using state machines in a main loop with event queue ==== | ==== Using state machines in a main loop with event queue ==== | ||
| This design is like the one presented above. But the state machine receives its events from an event queue. The queue is filled from timer events, other state machines (cooperating machines) or interrupt handlers. | This design is like the one presented above. But the state machine receives its events from an event queue. The queue is filled from timer events, other state machines (cooperating machines) or interrupt handlers. | ||
| - | {{ :wiki: | + | {{ : |
| Benefits: | Benefits: | ||
| * Events are not lost (queuing) | * Events are not lost (queuing) | ||
| Line 112: | Line 141: | ||
| * The main loop has to check if events are stored for a state machine in its queue. If there are new events they are pulled from the queue and the state machine is called with the event. | * The main loop has to check if events are stored for a state machine in its queue. If there are new events they are pulled from the queue and the state machine is called with the event. | ||
| - | Example code with two state machines shows the general principle: | + | ++++ Example code with two state machines shows the general principle: |
| <code c> | <code c> | ||
| Line 154: | Line 183: | ||
| </ | </ | ||
| + | |||
| + | \\ | ||
| As indicated in the figure above also other state machines or interrupt handlers might push events to the queue of a state machine. An example how to do this is shown below. | As indicated in the figure above also other state machines or interrupt handlers might push events to the queue of a state machine. An example how to do this is shown below. | ||
| Line 163: | Line 194: | ||
| </ | </ | ||
| + | ++++ | ||
| ==== Using state machines in a main loop with event queue, optimized for low power consumption ==== | ==== Using state machines in a main loop with event queue, optimized for low power consumption ==== | ||
| In low power system designs a key design goal is to keep the processor as long as possible in low power mode and only wake it up if something needs to be processed. The design is very similar to the one described above. The main difference is that the main loop runs not all time but only in case an event has happened. The timer service for the small runtime framework is handled in the timer interrupt. | In low power system designs a key design goal is to keep the processor as long as possible in low power mode and only wake it up if something needs to be processed. The design is very similar to the one described above. The main difference is that the main loop runs not all time but only in case an event has happened. The timer service for the small runtime framework is handled in the timer interrupt. | ||
| - | + | \\ | |
| - | A skeleton for the MSP430 looks as follows: | + | ++++ A skeleton for the MSP430 looks as follows: |
| <code c> | <code c> | ||
| Line 206: | Line 237: | ||
| </ | </ | ||
| + | ++++ | ||
| + | \\ | ||
| + | |||
| + | The following temperature transmitter using a MSP430F1232 header board with just 256 bytes of RAM and 8K of program memory is based on this design principle. | ||
| + | {{ : | ||
| + | For more information on how to use state-machines in low-power embedded systems see [[wiki: | ||
| ==== Using state machines in interrupts | ==== Using state machines in interrupts | ||
| Sometimes state dependent interrupt handling is required. Then it is useful to embed the state machine directly into the interrupt handler to save every us. Typical usage might be the pre-processing of characters received by a serial interface. Or state dependent filtering of an analog signal before further processing takes place. | Sometimes state dependent interrupt handling is required. Then it is useful to embed the state machine directly into the interrupt handler to save every us. Typical usage might be the pre-processing of characters received by a serial interface. Or state dependent filtering of an analog signal before further processing takes place. | ||
| - | {{ :wiki:irq.png?100|}} | + | {{ :irq.svg?100|Using state machines in interrupts}} |
| Using state machines in an interrupt handler can be useful in any system design. | Using state machines in an interrupt handler can be useful in any system design. | ||
| - | For code generation some considerations are necessary. Usually it is necessary to decorate interrupt handlers with compiler specific keywords or vector information , etc. Furthermore interrupt service handlers have no parameters and no return value. To meet these requirements the Sinelabore code generator offers the parameters StateMachineFunctionPrefixHeader, | + | For code generation some considerations are necessary. Usually it is necessary to decorate interrupt handlers with compiler specific keywords or vector information , etc. Furthermore interrupt service handlers have no parameters and no return value. To meet these requirements the Sinelabore code generator offers the parameters |
| - | The example below shows an interrupt service routine with the compiler specific extensions as required by mspgcc. | + | ++++ The example below shows an interrupt service routine with the compiler specific extensions as required by mspgcc |
| <code c> | <code c> | ||
| Line 241: | Line 278: | ||
| Prefixes for the header and the C file can be specified separately. | Prefixes for the header and the C file can be specified separately. | ||
| + | ++++ | ||
| ==== Using state machines with a real-time operating system ==== | ==== Using state machines with a real-time operating system ==== | ||
| In this design each state machine usually runs in the context of an own task. The principle design is shown in the following figure. | In this design each state machine usually runs in the context of an own task. The principle design is shown in the following figure. | ||
| - | {{ :wiki:task_ab.png?400 |}} | + | {{ :task_ab.svg?400 |Using state machines with a real-time operating system}} |
| Each task executes a state machine (often called active object) in an endless while loop. The tasks wait for new events to be processed from the state machine. In case no event is present the task is set in idle mode from the RTOS. In case one or more new events are available the RTOS wakes up the task. The used RTOS mechanism for event signaling can be different. But often a message queue is used. Events might be stored in the event queue from various sources. E.g. from within another task or from inside an interrupt service routine. | Each task executes a state machine (often called active object) in an endless while loop. The tasks wait for new events to be processed from the state machine. In case no event is present the task is set in idle mode from the RTOS. In case one or more new events are available the RTOS wakes up the task. The used RTOS mechanism for event signaling can be different. But often a message queue is used. Events might be stored in the event queue from various sources. E.g. from within another task or from inside an interrupt service routine. | ||
| Line 258: | Line 295: | ||
| * Need of a real-time operating system (complexity, | * Need of a real-time operating system (complexity, | ||
| - | The evaluation version shows an RTOS example | + | In the how-to section |
| + | |||
| + | ++++ Example code for RTEMS | | ||
| <code c> | <code c> | ||
| // rtems specific task body | // rtems specific task body | ||
| Line 310: | Line 349: | ||
| } | } | ||
| </ | </ | ||
| + | ++++ | ||
| - | + | ++++ Example code for embOS RTOS from Segger. | |
| - | Here is a similar example | + | |
| <code c> | <code c> | ||
| // state machine instance | // state machine instance | ||
| Line 356: | Line 395: | ||
| } | } | ||
| </ | </ | ||
| + | ++++ | ||
| - | ---- | + | \\ |
| - | ====== Latest News ====== | + | ==== Events versus Boolean Conditions |
| + | Sinelabore supports two basic modes of operation. Either the generated state machines react on events. Only if an event is present a transition is taken (e.g. evDoorClosed, | ||
| - | === 29.12.2017 | Sparx new EA Version === | ||
| - | {{: | ||
| - | === 5.11.2017 | New version 3.7.2 === | ||
| - | {{: pix_mouse.png? | ||
| - | === 20.9.2017 | QuickStart tutorial on how to use the code generator with Energia on GitHub === | ||
| - | {{ : | ||
| - | {{: pix_mouse.png? | ||
| - | === 9.4.2017 | New version 3.7.1 with some small improvements | ||
| - | {{: pix_mouse.png? | ||
| - | === 6.11.2016 | Code Generator Features for High-Availability and Safety Systems === | + | ---- |
| - | {{: | + | |
| - | === 16.10.2016 | Generate Python Code from State Diagrams === | ||
| - | {{: | ||
| - | === 24.6.2016 | Windows Executable === | ||
| - | {{: | ||
start.1528743862.txt.gz · Last modified: 2018/06/11 21:04 by pmueller