Novos PPS: Pre-emptive Priority Scheduling Environment
The Novos PPS Environment is a complete RTOS that supports pre-emptive scheduling of prioritized Background tasks (BG tasks) and Foreground tasks (FG tasks). It has all the capability one would expect in an RTOS but there are some additional features that go beyond expectations.
Each BG task, including the Idle Task, is an independent entity, having a priority, a time quantum and a stack. The priority is changeable and defines the importance of the BG task in relation to the other BG tasks. The time quantum allows a set of tasks to run in a Round Robin manner provided they all have the same priority.
The stack allows the BG task’s context to be saved during an interrupt, a pre-emption or while waiting to synchronize with an event. When the BG task is resumed, the saved context is restored to permit it to resume its normal operation.
The Scheduler always selects the eligible BG task with the highest priority to be the Current Task, provided there is no Foreground operation taking place. If a BG task becomes eligible to take CPU control and its priority is higher than that of the Current Task, the Scheduler will pre-empt the lower priority BG task and give CPU control to the higher priority BG task. This is the essence of pre-emptive priority multitasking.
In addition to Pre-emptive Priority scheduling, the Novos PPS Environment supports BG task scheduling using a First Come, First Served policy, a Round Robin policy or any combination of the three policies. BG tasks scheduled using FCFS or RRS must have the same priority.
If a BG task needs to synchronize with some event, it can wait until the event occurs or for a defined period of time, whichever should occur first. When the event does occur, the task can immediately become eligible to run, which, depending on its priority and the priority of the task in control of the CPU, may result in a very timely response to the event.
A Foreground (FG) execution entity (Deferred Interrupt Handlers, Event Action Routines and FG tasks), regardless of its priority in the Foreground, has an inherent priority that is higher than that of any BG task. All Foreground execution entities use a run-to-completion model and have access to most Novos PPS services provided they do not block or pause their execution. However, they may be interrupted and even pre-empted by a higher priority Foreground entity. Foreground entity priorities chosen through Rate Monotonic Analysis can yield deterministic, real-time performance with provable schedulability.
Why Use the Novos PPS Environment?
Many embedded applications employ a multitasking model that use prioritized tasks within a pre-emptive scheduling policy. The Novos PPS Environment is a full RTOS and is a very versatile environment for embedded systems. It supports every class and every API in the Novos Environments. Its scheduling policies for BG tasks, whether periodic or aperiodic, makes it ideal for use in control systems, where a process is measured, calculations are made for new process conditions and those new conditions feedback to the process.
Because there are multiple Background priority levels, it can support application designs that include Round Robin scheduling within one of the available priorities. It can also support First Come/First Served processing at a different priority. All in the same application.
And if that isn’t enough, there is the Foreground that can handle the computational requirements of algorithmic processing such as digital signal processing (DSP), music playback or data acquisition in which a FG task performs the algorithm on a given block of data. The Foreground is also useful in Finite State Machine (FSM) designs built with different FG tasks handling the various state processing.
The Novos PPS Environment makes it easy to get the job done quickly and efficiently by:
- Providing a standard model for interrupt servicing that simplifies device driver design
- Recognizing and synchronizing application code with external or internal events
- Multitasking of Background tasks using Pre-emptive Priority, First Come, First Served, or Round Robin scheduling policies, individually or in combination
- Requiring each BG task to have its own stack and time quantum
- Pre-emptive scheduling of all Foreground execution entities
- Passing data between the execution entities, including interrupt service routines
- Handling time-based operations
- Requiring only one stack for all Foreground entities
- Requiring each BG task to have its own stack
- Providing two types of exclusive access management, including two methods of resolving priority inversions when using mutexes
Even though it is a complete RTOS, it has a surprisingly small ROM and RAM footprint. It is available in source code form, too. So whether you are just looking to learn something about RTOS design or want to deploy it in a product, you get to see how the foundation is built.
And our Novos PPS Environment source code is FREE. Two volumes of accompanying documentation are separately available for a small fee. A User Guide explains the Novos PPS design, its classes and how to use it. A Services Reference Guide gives a complete description of each Novos PPS API. See how all of it can help on your next application.
Most embedded applications need to service peripheral devices from time to time. Polling the devices is one way but a costly one in terms of cycles, power and performance. Interrupts are usually a better solution and the Novos PPS Environment is especially well suited to the job of servicing them rapidly and predictably.
The Novos PPS Environment uses two-level interrupt service model that is common to all Novos operating environments, providing a robust design and ease of handling interrupts. The highest level services the immediate needs of the interrupting device and schedules the second level handler, the Deferred Interrupt Handler (DIH). As a high priority Foreground execution entity, the DIH has full access to the Novos PPS API set, allowing it to communicate with other DIHs as well as FG tasks or the Idle Task about the device’s input or output data.
Synchronizing with Events
It is a common requirement in almost all embedded systems that the various execution entities know when an event takes place in order to synchronize with it. Timely response to events is often part of the application’s requirements. And if there is a real-time requirement, it is a necessity.
The Novos PPS Environment supports two ways to achieve event synchronization. One is the classical method using a semaphore associated with the event in which a Background task waits (pends) for the event to occur and another entity signals (posts) the event’s occurrence. Although it is well-proven and effective when used with appropriate priorities of the entities involved. However, if it is used with a group of cooperatively scheduled BG tasks, it can lead to unwanted timing issues, the so-called “Convoy Effect”.
The second choice the Novos PPS Environment gives you is to use Event Action Routines (EARs) for specific types of class-related events. By employing EARs, it is easy to respond to such events in a timely manner, further enhancing the capability of the Novos PPS Environment even for real-time applications.
Using EARs for rapid response to events is also a way of mitigating the Convoy Effect that can occur amongst BG tasks scheduled cooperatively. Instead of having to wait for a task to get to the head of the queue (the Robin) and gain CPU control before responding to an event, an associated EAR can deal with the event when it occurs. The time criticality of the task’s response to the event is thereby greatly reduced.
Novos PPS Classes of Services
The Novos PPS Environment supports 96 services distributed amongst ten classes, which include:
A Deferred Interrupt Handler (DIH) is a Foreground execution entity that runs as the result of an interrupt. It allows an interrupt service routine to connect with other execution entities in the application through the use of Novos PPS services in order to pass data between the device and those entities. A DIH can invoke a Novos PPS service that causes an event that schedules an Event Action Routine.
An Event Action Routine (EAR) is a micro-task that executes when a Novos PPS service invoked from any execution entity detects an event for which there is an associated EAR. The scheduled EAR always runs as a Foreground entity, meaning that it will pre-empt any Background or Foreground task operation. The association between an object, the event conditions and an Event Action Routine is user-defined. An EAR can invoke all services available to any Foreground execution entity.
Foreground Tasks (FG tasks) execute at priorities below that of an Event Action Routine but above that of the Background tasks. FG tasks are interruptible as well as pre-emptible by Event Action Routines and higher priority FG tasks. They can also schedule other FG tasks and may invoke Novos PPS services available to any FG task, which, in turn, can cause EARs to be scheduled, causing a pre-emption.
Background Tasks (BG tasks) are independent entities that run in the Background. Each BG task has a priority, a time quantum and a stack for local variables as well as for context saving, which enables it to block, suspend or otherwise pause in its execution path in order to synchronize its execution with events outside its scope. The Scheduler ensures that the Current Task is the highest priority BG task eligible to get CPU control at any given instant. Once in control of the CPU, a BG task maintains that control until it is interrupted, pre-empted by a higher priority BG task or any FG operation, blocks while waiting for an event or until it voluntarily gives it to another BG task or is forced to yield because its time quantum expires.
The Alarm and Counter classes provide services to handle time-based operations in the all execution entities including the Idle Task. A single system time-base counter supports any number of application-defined alarms, which can be either one-shot or cyclic in nature. Background tasks can block while waiting for alarms to expire. FG tasks cannot wait.
The Event Group class services provide execution entities ways to use groups of bit-level flags to set and detect one or more events in a simple and efficient way with AND/OR Boolean logic. One or more BG tasks can set up task-specific test conditions on an event group and wait with or without a timeout until its test flags match those of the event group. FG tasks can set and test the flags in an event group but they cannot block if the test does not produce a match.
The Queue class provides services to move data to/from the execution entities, including the Idle Task, DIH, EAR and FG task entities. Support exists for both First-In-First-Out (FIFO) and Last-In-First-Out (LIFO) queueing. Except for the Idle Task, blocking with or without timeouts while waiting to put data into or get data from a queue is permitted for BG tasks. FG tasks cannot block during queue operations.
The Semaphore class supports a full counting model that permits any execution entity to post a signal to one or multiple semaphores and/or detect the occurrence of a related event on one or multiple semaphores. Except for the Idle Task, BG tasks can wait for an entity to post a signal to a semaphore with or without a timeout. Posting a signal can result in one or all tasks waiting for the event to receive notice of its occurrence. The degenerate case of the counting semaphore model is the binary semaphore, which is also supported for simple exclusive access to resources.
The Memory Pool class allows RAM to be divided into pools of user-defined, fixed size blocks that all execution entities can allocate, use and release. Contiguous and non-contiguous RAM blocks are permissible, allowing a versatile means to manage a precious resource. If a RAM block is unavailable, a BG task can wait with or without a timeout for one to be freed to the memory pool, or under certain conditions, to allocate the block from available RAM.
Mutex classes provide a more complex exclusive access management method as compared to that offered by the Semaphore class. Once acquired, a Novos PPS mutex has a defined owner and only that owner can release it. Waiting with or without a timeout to acquire a mutex is supported. The Novos PPS Environment supports nested acquisitions of a mutex by its owner and user-selectable resolution of a priority inversion by either Priority Inheritance or Immediate Inheritance methods.