Code Models of Novos Tasks

All Novos environments support a mix of Foreground and Background operations. Foreground operations may consist of one or more Foreground execution entities such as Deferred Interrupt Handlers (DIH), Event Action Routines (EAR) or Foreground tasks (FG Task).

Background operations consist of one or more Background tasks (BG Task). Each type of execution entity has its own characteristics.

Foreground Tasks, DIHs and EARs

All Foreground execution entities operate in the same way – as a run-to-completion task at any of several priority levels. There is no restriction on what they can and cannot do other than the basic restriction of the run-to-completion design – it cannot pause or otherwise block its execution once it starts its execution burst. Another common characteristic of a these execution entities is that they require only one stack for all Foreground operations, which can mean greatly reduced RAM requirements.

In general, FG entities are not used to poll for something to do. They run because there is something to do – an interrupt requires handling, some block of data needs to be consumed or some input from a device has to be processed. Thus, it is highly likely you will schedule execution of the FG task as the result of some event occurring.

During its execution, a Foreground entity can be interrupted or pre-empted, assuming its priority level is lower than the priority of the interrupting device or pre-empting entity. A Foreground task has lower priority than any DIH or EAR and can be pre-empted by either of them. Any FG Task has a priority higher than any BG Task.

The code template for all Foreground entities is that of a C function with no input parameters and a void return as shown in Figure 1. Its entry point is the starting address of its execution burst but it can have one or more points of completion.

Figure 1 – Foreground Entity Code Template

Background Tasks

One of the distinguishing characteristics of a Background task is that it requires a stack. In the Novos FB and Novos EFB, the one Background task shares its stack with all Foreground entities. In all other Novos environments, each task must have its own stack that is separate from that used by the Foreground. The separate stack provides storage for temporary variables during execution but also processor context during a period of pre-emption or blocking. Because a BG Task can block its execution or be pre-empted, it is often the choice for many applications that involve sporadic or aperiodic operations.

Each of these Background tasks follow one of two code models – the Finite Life Model or the Infinite Life Model. Regardless of which model is used, a task is coded as a C function with no input parameter and a void return. It is a usual requirement that each BG Task have at least one kernel service that will cause the task to give up control of the CPU.

Infinite Life Model

In this code model, the task runs perpetually in a loop without ending. There is a general requirement that there must be at least one explicit call to a blocking service (e.g. Pend on a semaphore post, Pend on an alarm, etc.) within the loop to ensure that it gives up CPU control to a lower priority BG Task. However, that is not necessarily true for a BG Task scheduled under a Round Robin policy in which the task’s time quantum defines the duration of its CPU control. Figure 2 shows the template for this model.

Figure 2 – Infinite Life BG Task Model

 

Finite Life Model

If a BG Task’s lifespan is intended to be short, the Finite Life Task model can be very useful. It is also coded as a C function with no input parameters and a void return. In it, the infinite loop construct of the Infinite Life Task Model is eliminated in favor of a loop that executes either a fixed number of times or until something happens that causes a conditional test to yield a FALSE result, ending the loop and terminating the task. As in the Infinite Life Task model, there is a requirement that the task code include a call to a blocking service. Figure 3 shows this model.

 Figure 3 – Finite Life BG Task Code Model

A slightly different version of this code template is defines the lifespan as a number of execution cycles of the task loop as shown in Figure 4.

Figure 4 – Finite Life Task Code Model Using a Count

 

Comments are closed.