Effects of Task Model Choice on RAM Usage in ARM Cortex M0/M0+ Applications

Selecting the right application framework (a.k.a. environment) for an embedded system can lead to use of a smaller, less expensive microcontroller, or lower power consumption, or a simpler system architecture supporting application code that is easier to debug, test and document.

The Cortex-M0/M0+ processors are ideal for small, high volume applications that are often very cost-sensitive. Selecting the right application framework and supported task models can have a substantive effect on ease of application development, maintainability and recurring costs, all of which affect the bottom line. This article will discuss some ways to capture those effects.

The process starts with decomposing the application into its various functions. For ease of discussion, let’s call each decomposed element a Task. After all, a Task is simply an element that performs some job in the application. It can be the code that treats an interrupt for a peripheral device or code that crunches numbers or controls a valve. It is simply code that does something. The right application framework is one that will allow each Task to do its job using the least amount of RAM and Flash/ROM and possibly in the least amount of time.

Conceptually, one can think of all code execution taking place in two planes – Foreground and Background (or, Data Plane and Control Plane), each of which has specific operational capabilities and performance benefits. The former takes care of interrupt handling and other such high priority operations. The latter typically handles data processing and other control-related functions. The issue is to determine which plane provides the best fit for each Task. The collective decomposition results ought to provide a clear choice for the right application framework.

For further purposes of discussion, let’s take code size off the table because it can vary widely and the way it is written has a very profound effect on how much processor time it uses. Similarly, power may not be an overriding concern. By eliminating the things over which there is little objective control, further discussion will concentrate on the one remaining objective parameter – RAM usage.

One of the most commonly encountered application frameworks used in embedded systems is the multitasking RTOS (a.k.a. real-time kernel, executive, etc.). In that model, there is usually one primary task model and one primary task scheduling policy – pre-emptive priority. They may support other task scheduling variants such as chronological (a.k.a. First Come/First Served, or FCFS) and/or time-sliced (a.k.a. Round Robin) policies. Those are all good policies for the typical multitasking RTOS but they come with a high price on a RAM-constrained Cortex-M0/M0+ microcontrollers: high RAM usage needed for stacks.

The Cortex-M0/M0+ architectures supports two stacks – the Main Stack and the Process Stack, only one of which is active at any given time. The Main Stack Pointer (MSP) and the Process Stack Pointer (PSP) point to the tops of the Main Stack and Process Stack, respectively. RTOS operation begins with MSP being the active stack pointer. The RTOS initialization procedure usually switches the active stack to PSP by setting bit 1 of the CONTROL register, putting the processor into Thread Mode. At this stage, the PSP usually points to the stack used by the RTOS’s Idle Task, which launches the other Tasks in the application.

When an exception (interrupt) occurs, the processor switches automatically to Handler Mode with the active stack pointer being MSP unless it is already in Handler Mode. When the exception processing completes, the return to the interrupted code will restore the processor mode and active stack to what they were when the interrupt occurred.

In addition to the Main Stack and the Process Stack used by the Idle Task, the typical multitasking RTOS model requires a separate stack for each Task in the application. For example, if there are ten Tasks in the application, there is a need for ten private Task stacks. They need not be of a fixed size but some RTOS designs use a standard size stack whether or not the Task requires it. However, each stack requires enough RAM to hold at least eight and as many as sixteen 32-bit registers plus any RAM required by the Task for local variables. The net result is that this model requires a good deal of RAM. But there is another approach.

The Novos family of environments offers five software architectures for use on a Cortex-M0/M0+. Of those five, two of them, Novos Foreground/Background (Novos FB) and Novos Extended Foreground/Background (Novos EFB) offer very good performance coupled with a small RAM requirement.

All Novos environments contain a Foreground priority queue that controls Foreground operations. Background operations in Novos FB/EFB are limited to a single Task, which may sound limited until one considers that Foreground Tasks in a Novos environment, like Tasks in the traditional RTOS, also have priorities and are scheduled preemptively with respect to those priorities. Foreground Tasks can be triggered by time or the occurrence of some event, whether externally or internally generated, or scheduled from the Background Task. They may be periodic, aperiodic or sporadic in nature just like the traditional RTOS Tasks. And if the application has a real-time requirement, Foreground Task priorities can be selected using Rate Monotonic Analysis to provide provable hard real-time performance.

Operationally, Foreground Tasks in the Novos environments must be a Run-to-Completion model, meaning that once released, their execution cycle must run to a point of completion. The Background Task operates as an endless loop. Whether a Foreground or Background Task, neither can block nor wait for some event to occur, although they can be interrupted. The Background Task, however, may put the system into a reduced power state when the system is idle.

The Run-to-Completion model of a Novos Foreground Task requires no restoration of context from a prior execution cycle nor the saving of context at the completion of the current execution. This reduction in task switch overhead produces Foreground Task switches that are much faster than that of the traditional RTOS model, making the environment well suited to such operations as DSP algorithms, block-oriented data processing, state machines, high speed I/O and more.

As previously stated, the use of multiple stacks in the traditional RTOS model can produce a large RAM requirement. By contrast, the Novos FB/EFB environments use only the MSP for the active stack pointer because both Foreground and Background operations take place totally in the Handler Mode of the Cortex-M0/M0+. Having only one stack permits the Novos environment to switch from one Foreground Task to another without the need to switch stacks as required by the RTOS model. The net result is a significant difference between the RAM requirements of a traditional multitasking RTOS as well as a measurable performance difference between the two types.

Because the Novos products are frameworks for building embedded applications, every Novos environment  contains a library of services specifically designed and scaled for the particular needs of Tasks in that environment. For example, Novos FB has a library of 31 services. The Novos EFB contains 53 services. Data structures used by those services are pre-scaled to minimize RAM and specific to the particular Novos environment. No configuration is required, unlike some RTOS products. To reduce code footprint, only those services actually referenced by the application become part of the target image. For a Cortex-M0/M0+, Novos FB and Novos EFB require less than 256 bytes of RAM (226 to 232 bytes for Novos FB and Novos EFB) and yield usable code sizes as small as 1.4 Kbytes to 1.6 Kbytes, respectively. Both frameworks provide a rich environment for developing a wide variety of applications without sacrificing performance or ease-of-use on a microcontroller with limited RAM.

More details on the Novos family of application frameworks are available at www.ee-novos.com.

Comments are closed.