|
|
||||||||||||||
|
Staccatotm should be considered for all microprocessor and microcontroller embedded applications; 8-bit through 32-bit. |
![]() |
![]() |
![]() |
||||||||||||
| Lean, Green Finite State Machines for Embedded Software No RTOS Required! | |||||||||||||||
| FAQ Tutorials Commentary Articles Contact Mapletech Productions LLC | |||||||||||||||
| Tutorials - Tutorial 2: A Basic Staccato™ Task State Diagram | |
|
This tutorial will show you some basic concepts of how to construct a basic state diagram of a task. The Staccato™ Architecture requires that your embedded system software be partitioned into individual application tasks, each of which is responsible for a device interface, a communication protocol layer, or some algorithmic processing of data. An embedded application therefore becomes a 'system of directly executed Finite State Machines (FSMs)' |
|
|
Each of your system tasks will be implemented as a finite state machine. Using state diagrams to convey the behavior of a task in response to events and conditions is oftentimes regarded a difficult task in itself. However, by considering the Basic Task State Diagram Template, as shown here, we can achieve a better understanding of how to get started with this important and necessary design process. The state diagram template shows the four states that will likely occur in most of your task designs. ALL tasks must have an initialization state, shown in the diagram as state 0.0 INIT. This initialization state code will be the first code executed for this task, and will likely occur immediately after system power-up and initialization. Within this state, your code will initialize any hardware devices and any task-related variables. Notice that if an error occurs during this initialization, the task will transit to state 3.0, the error state. Otherwise, execution continues in the idle state of 1.0, wait request, where the task will remain until an external request is set by another task. |
![]() |
|
When this request event
occurs, the task will clear the request event, and setup the requested
process, and transit to state 2.0 where the requested process is
performed. The task remains in this state, performing the process action
until either an error occurs, resulting in a transition to state 3.0, or
the process completes successfully causing a transition back to the idle
state of 1.0. Although this state diagram
representation of a task may seem simplistic, you should regard it as a
template for each of your tasks within a Staccato™ Architecture. It is
therefore recommended that you use this template to begin your designs
of each of your application tasks, until you become more proficient in
using state diagrams. The Staccato™ Crossroads SDK with Certified
Training program provides extensive coverage of how state diagrams can
be used to analyze and design both abstract and physical systems. Also,
encoding your task state diagrams to generate your module source-code is
a very straightforward process, especially with the assistance of the
Staccato™ System Calls. |
|
|
© 2008 Mapletech Productions LLC, All Rights Reserved |
|