Not an RTOS

Novos EFB is NOT an RTOS

These comments compare and contrast RTOS features and capabilities with those of the Novos EFB Enhanced Foreground/Background environment (or, Application Framework, if that is a preferable term).

RTOS products are centered around the concept of multiple tasks or multiple users, which implies multiple tasks. Those tasks/threads are organized around a priority scheme that the RTOS Scheduler enforces and execute at a system priority level below that of interrupts. Essentially, the typical RTOS employs two processing levels: Interrupts at the highest level and tasks at the background level. 

Other than whatever processing takes place at the interrupt level, which is typically of short duration, most of the work in an application based on a RTOS takes place in the background. The priority ascribed to the tasks allows for an orderly execution in the background level. 

A prime characteristic of those RTOS tasks is that they have the ability to block while awaiting an event or availability of some resource needed in order to proceed. That ability puts demands on the available RAM as each task requires a control block (usually called a Task Control Block, or, TCB) as well as a quantity or RAM for a stack used for local variables and processor context in the event of a pre-emption. 

In addition, the RTOS needs another stack that handles the one task that every RTOS needs – the Idle Task. When all application tasks are idle for want of something to do, they are blocked. But the RTOS has to have something to schedule, so it executes the Idle Task. By definition, the Idle Task has to have the lowest priority in the application and it cannot block or otherwise suspend its operation. 

To do so would be catastrophic because the RTOS has no place to go but off the cliff. Because the Idle Task is a proper task, except for the restriction o non-blocking activity, it requires a stack, too. All totalled, the RAM requirement for the RTOS model can add up to a lot of RAM, which in many smaller or resource constrained applications, is not beneficial.

Novos EFB takes a very different approach

Most noticeable is the fact that in EFB there is only one task – the Background. The Background task is the application (except for what goes on at the interrupt level). There is no system requirement as to how the application must be structured as compared to the strict structuring of an RTOS task.

The only restriction is that the background task cannot block. It is equivalent to the Idle Task in the RTOS model. And similar to the RTOS model, it requires a stack for the application’s local variables and processor context in the event of an interrupt. The simplest way to describe the single background task is to call it the Super Loop – the oldest organization model for embedded system software.

The simplicity of the Novos EFB model becomes obvious compared to the RTOS model. That simplicity reduces RAM requirements and makes for a very controlled operation, which makes it easy to debug and test. But the simplicity of the Super Loop model can also lead to situations where the a less-than-thoughtful application design becomes convoluted or otherwise corrupted. That situation becomes what is commonly termed “spaghetti code”.

Just because the Super Loop is a simple model does not mean that it works efficiently with “throw down” code. Like the RTOS tasks, the Super Loop can be decomposed into processing units that can have little or no contact with other units in the application. Such encapsulation leads to an efficient design that is maintainable and sustainable. How is that possible?

The typical RTOS is built around a set of services that deal with various classes of data structures (called “objects”). Each object class is intended to provide a capability needed for efficient design of application tasks. An RTOS has a set of primary and secondary functions. These functions include, in addition to managing the system resources, moving data from place to place, synchronizing and responding to events and managing time. 

In addition, functions that permit exclusive access to resources and managing RAM usage are also found. The totality of what is provided is what gives each RTOS it’s flavor. Interestingly, almost all RTOS models provide the same set of functionalities. The functionalities are defined by the set of services that support each class. 

In a similar manner, EFB provides support for various classes of data structures, many of which are similar to those found in the typical RTOS. There are services for moving data from one place to another, there are services to manage time-based events, manage RAM usage, and handle events. The application, or each unit of the application, can make use of these services (or not) to achieve the level of encapsulation the developer wants. The concept is exactly the same as in the RTOS model. 

However, one thing EFB does not provide is a direct service to provide exclusive access to a resource. Such code can get quite complicated and involves tasks that can be blocked, something EFB simply cannot do. That said, EFB does support a class called “Semaphores” that use a counting model in which it is possible to create a very low level mutex that can give some degree of resource protection without violating the non-blocking dictum.

Novos EFB can achieve hard real-time performance through use of the foreground entities – a very efficient way to achieve a low level prioritization of background processes.

The RTOS  and EFB application code models are valid and useful in the proper circumstances. However, they are quite different in spite of some similarities of nomenclature. One does not use the same code structure for the application in one model as in the other. While each is valid, there are major differences, especially in the area of RAM utilization and ease of use. One is especially well suited to small, resource constrained processors and the other is not. 

Bottom line: Novos EFB, while it does provide services to support the application code, is not an RTOS. Novos EFB is a very powerful Application Engine (or Application Framework) and is an excellent fit for most small applications.