Novos Task Model Selection
Selection of the right type of task model depends on what the task is trying to do and what its requirements are. The typical multitasking RTOS products only support one type of task which it schedules with a pre-emptive priority policy.
That may not be the best choice, especially for RAM-constrained microcontrollers where it could prove totally unworkable because of that model’s potentially large RAM usage for stacks.
The Novos family of environments offer task execution in two planes – Foreground and Background, each of which has specific operational capabilities and performance benefits. Selecting the right task model and operational plane can lead to usage of a smaller, less expensive microcontroller, or lower power consumption, or a simpler system architecture that is easier to debug, document and test.
So how does one go about making the determination? What we need to do is to look at each task and consider some of the pertinent issues. 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. Consider:
If the task overruns its deadline, is it catastrophic?
If you have this requirement, you have a task with hard real-time requirements. You might be able to satisfy that requirement by running the task in the Foreground with any of the Novos environments except Novos FB. Or, you could run it as a high priority Background task in the Novos PPS environment.
The choice depends on the task’s need to block, or otherwise synchronize with external events. If there is no such need, consider running it in as a Foreground task. If there is a need to block within the task’s normal operation, it should be run as a Background task.
If the task overruns its deadline, can it continue producing valuable results?
If you answer in the affirmative, you have a soft real-time requirement. Depending on the size of the deadline, almost any of the Novos environments are suitable
Are there other tasks in the application whose relative importance can affect this task?
If yes, and the task requires synchronization with external events, you should consider assigning a priority to it as a Background task with the Novos PPS environment. Or, if the task has a Run-to-Completion code model, you could assign it a Foreground priority and schedule it as a Foreground task in any Novos environment except Novos FB.
Is the task more, less or equally important when compared to other application entities?
If the task runs in the Background and is more important than other Background tasks, it needs a priority that is higher than all other Background tasks and should be used in a Novos PPS environment,
If the task runs in the Background and is less important than other tasks, it should have a priority that is less than other Background tasks and should be scheduled with the Novos PPS environment.
If the task runs in the Background and neither more nor less important than other Background tasks, it should be scheduled with the Novos FCFS or Novos RRS environment in which all tasks share the same priority.
If the task has a Run-to-Completion code model, it should be assigned a Foreground priority and run as a Foreground task in any Novos environment except Novos FB.
Does the task need to run from its entry point to a point of completion?
If yes, the task might be best suited to being scheduled as a Foreground task in any Novos environment except Novos FB, especially if it has a hard real-time requirement.
If not, the task should be assigned a priority and scheduled as a Background task in one of the multitasking Novos environments, Novos FCFS, Novos RRS or Novos PPS.
During its life cycle, does it need to synchronize with one or more events or data availability?
If so, the task should be assigned a priority and scheduled as a Background task in one of the multitasking Novos environments, Novos FCFS, Novos RRS or Novos PPS.
Does it need to run periodically or just whenever an aperiodic event occurs to trigger its release?
It is possible to run periodic tasks in both the Foreground and the Background. A periodic event can be used to trigger the task’s release in either domain.
In the Foreground, associate an event with an Event Action Routine that will schedule the task at its assigned Foreground priority. Time-based events as well as object-based events (e.g., semaphore posts, queue puts, etc.) can be defined to trigger the Foreground task when the event occurs. This method ensures the fastest response to the event.
In the Background, the task can be blocked on a Novos object (e.g., Semaphore, Queue, etc.) while waiting for the event to occur. When the object removes the blockage as a result of the event occurrence, the task will be released to the Background. The time for the Background task to respond to the event will depend on the Novos environment used for task scheduling and the task’s Background priority.
Does the task handle an associated peripheral device itself or depend on a separate entity to do it?
If it services a peripheral device itself, care must be exercised to ensure that the task’s deadline is not affected if the device is not serviced in time. Direct handling of a device is often found in Super Loop applications. While simple, it is not a recommended way to handle a device.
Does the task depend on a separate entity such as an interrupt service routine (ISR) to service an associated peripheral device?
Use of an ISR to service a device interrupt is the recommended way to handle the device. Because the ISR has two levels, one of which can communicate via standard Novos objects, both Foreground and Background tasks have easy access to the device’s operations.