Earn Continuing Education Units (CEUs) from the IEEE by learning more about Staccato™ and partitioning.

Click here...

One of the first activities in designing embedded system software is to partition the application into individual tasks. This 'divide and conquer' approach is necessary regardless of the type of operating system to be used. However, there are important differences in the criteria used to partition a system between a conventional RTOS and Staccato™.

In a RTOS-based embedded system, a task can be generically defined as a separate application process that 1) usually contains a 'forever' loop, 2) may have static and dynamic priorities assigned to it, and 3) may or may not require access to resources shared with other tasks. Tasks are run based on external events (interrupts) and their assigned priorities. Before running the next task, a context switch is required to save the state of the processor's registers for the current task, which are restored when the task is re-scheduled to run. Given this scenario, code reentrancy, or the ability to safely resume from the last instruction executed, is an important consideration in the coding of each task. Multiple RTOS tasks may require access to the same resources, necessitating the use of semaphores or mutexes to resolve these conflicts during runtime. The pre-emptive scheduling of tasks, supported by many RTOSes, may also be a consideration when partitioning your system, as the exact sequence of task execution may be difficult to determine. Additional considerations in using this architecture would include the debugging capabilities, the resulting real-time performance and RTOS overhead, and the ability to reliably validate and verify the design for this runtime environment. Partitioning embedded system software into application processes using RTOS tasks may be more dependent on the inherent operational complexity of the RTOS itself. In an attempt to visualize an RTOS-based embedded software system, consider the following diagram.

System resources are listed on the left, with RTOS tasks, as partitioned, listed across the top. Notice how resources must be shared across multiple tasks. Notice also that task priorities indicate the order in which tasks are to be run. Device interrupts (ISRs) are also shown as they are a necessary part of any embedded system.

Staccato™ Partitioning...

In contrast to this popular partitioning method, Staccato™ regards the resources themselves as 'task objects'- each designed and encoded as Finite State Machines (FSMs). The resulting embedded software application architecture becomes a 'system of directly and continuously executed Finite State Machines (FSMs)'.

The following diagram depicts the Staccato™ partitioning approach, in contrast with that of an RTOS. Notice that in addition to the 'resource' tasks, a Control Task is added, which manifests the 'state of the system' and provides supervisory control over all other tasks, using the inter-task communication constructs provided by the Staccato™ System Core. Notice that typical 'driver' tasks are shown in this example. The Staccato™ partitioning method can just as easily accommodate tasks responsible for the algorithmic processing of data, communication protocol layers and error detection.

It is important to note that there is no priority scheme: all tasks, including the Control Task, are run by the executive in the same manner. Interrupts, including the System Timer, are handled as they are in any system, with the corresponding ISR providing the necessary processing. Notice also that resource contention becomes a non-issue in this method of partitioning. The diagram also shows the 'current' state for each task as a highlighted state bubble. These unique states for each task are actually functions, which run through completion, thereby eliminating the concern for code reentrancy, a design issue for the RTOS tasks. Likewise, there is no need for 'context-switching' using this method: the Staccato™ System Core and Executive consider the tasks as integrated processes within the application, as opposed to individually-run applications in an RTOS partitioning, requiring the context switch. Although this diagram adequately contrasts Staccato™ versus the RTOS approach to system partitioning, it does not convey the direct and intuitive method used in the Staccato™ Design Method and Architecture for Embedded Systems. This subject matter is discussed thoroughly, with examples, in Staccato™ Course 2 - Design and Coding Guidelines. By contrasting the two approaches to software partitioning described here, it should be evident that the Staccato™ method will result in a more deterministic system architecture, that is easily maintained and verified.