Easier, Faster, Smaller

A new concept RTOS

Traditional RTOS

Task
Subtask
Mailbox
Semaphore
Event
Timer
Byte malloc
Block malloc

........

Portos

Supertask
Priority Function
(Automatic)
(Automatic) or Signal
(Automatic) or Signal
Timer
Byte malloc
Byte malloc (constant size)

Traditional Task Model

Subtasks, dedicated stack, unique priority level and entry point per task, mailbox

Two tasks communicating

New Supertask Model

Priority functions, dedicated stack, multiple priority levels and entry points per supertask, no mailbox

Two supertasks communicating

No Tasks, No Messages, No Semaphores

When programming with Portos, you don’t need tasks, threads, messages, mailboxes, semaphores, events, etc. You focus on your main problem rather than on the details of the RTOS. Portos is the “one-click shopping” of Real Time Operating Systems.

Priority Function

At the heart of Portos is the priority function that allows simple, efficient and modular programming. If time to market is important to you, you may want to consider Portos. If code reuse and upgrade is important to you, take a look at Portos. Priority functions are like plain functions and can be called from anywhere. They are independent of the program’s architecture, and hence modularity is preserved and code upgrade is effortless. Contrast this with traditional tasks or threads where there are numerous kinds of dependencies, including inter-task communications. In a traditional RTOS, you cannot call a function from anywhere: modularity is lost and code upgrade is difficult.

In addition, priority function calls are automatically optimized by the compiler or preprocessor, and function arguments are automatically handled when temporary storage is needed.

Priority functions provide ultra-lightweight priority levels (no stack, no context switch). Therefore, you can at no extra cost, define a large number of priority levels to handle different session QoS, for example (while each level would use a thread in a traditional RTOS).

Priority Object

With ultra-lightweight priority levels you can create priority objects; a class and its methods can be instantiated at various priority levels, again at no extra cost. For instance, a modem's layer 2 object can be instantiated at priorities P1, P2, P3 and P4 for four different session QoS. The C++ language is not yet supported in Portos, however, the same ideas can be manually obtained in the C language.

Supertask

A supertask is a container of priority functions. It can act like a task but is only used when it is really needed: usually for time-slicing, for memory protection, for multi-processing, fast/slow stack, etc. There is no point in wasting context switches and stack memory for every minor subtask. Subtasks are lightweight priority functions in Portos, and can be easily grouped or ungrouped into supertasks. You could, for example, define more supertasks during the debugging phase to isolate certain modules. Then disable those supertasks once debugging is done.

A supertask is very powerful in Portos. It can have multiple priority levels as opposed to a task that has a unique priority level. And you can suspend a supertask partially: low priority functions are suspended but high priority functions continue to execute. Supertasks can have more efficient context switches (cf. documents for more details). Supertasks are not yet supported in Portos.

Signals, Timers

Signals and timers in the context of priority functions are very simple and efficient: rather than waking a thread up (context switch), in Portos, a signal or timer directly calls a priority function. It executes at the appropriate priority level. Moreover, a traditional RTOS may use a special thread to manage timers. In Portos, such a thread does not exist. We use an ultra-lightweight priority level (i.e. a set of priority functions).

Dynamic Memory Management

Portos uses a novel dynamic memory management algorithm that uses a combination of known techniques, plus an additional important trick: dynamic objects of fixed size (i.e. most objects) are mapped to corresponding storage list at compile-time . The algorithm is highly efficient and it is unnecessary to use block-type dynamic memory, commonly found in traditional RTOS. Programming in Portos is as simple as programming non-embedded software.

Stand-alone or Add-on Library

Portos can be used either as a stand-alone RTOS or as an add-on library that complements an existing RTOS. When using Portos as an add-on library to an existing RTOS, you benefit from the features of both operating systems. Another important advantage is that the Portos library is (nearly) automatically ported to all hardware platforms that are supported by that RTOS, and hence the hours of testing Portos on one platform are leveraged by all other platforms.

Supported Platforms

Portos is currently available as an add-on library to Texas Instruments DSP/BIOS. It runs on all DSPs supported by DSP/BIOS. A next version of Portos will support the ARM microprocessor.

Modem Layers Example

A modem implemented with traditional tasks (left side) and with priority functions (right side). Layer L2 transmits data to Layer L1 and starts a timer. A timeout occurs, which calls the retransmission code. In the traditional tasks implementation, each layer is usually a task (with different priority level). In the priority functions implementation, layers L2, L3 and the Timer utility layer execute outside any Tasks or Supertasks (they could execute inside one shared Supertask).

Modem layers using tasks vs priority functions