| HOME | PRODUCTS | TUTORIALS | COMMENTARY | CONTACT |
| tutorials |
|
Earn Continuing Education Units (CEUs) from the IEEE by learning more about Staccato™ and partitioning.
|
| Tutorial 1: Embedded Software Partitioning: Staccato™ versus an RTOS |
|
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. |
© 2010 Mapletech Productions LLC, All Rights Reserved