4.3.1 Task Parameters

{

Message msg(“Hello”); t->SendMessage(msg);

if (t->Next() == Current() break;

}

Unfortunately, this approach has some drawbacks. First, the order in which this loop is performed is different when executed by different tasks. Second, it is assumed that all tasks are present in the task chain. Although this is the case in our implementation, one may consider to remove tasks that are not in state RUN temporarily from the task chain in order to speed up task switching. In this case, only tasks in state RUN would receive the message which is probably not what was desired. A better approach is to maintain a table of task pointers, which is indexed by an integer task ID. The task IDs could be defined as follows:

1 // TaskId.hh

2

3enum { TASKID_IDLE = 0,

4TASKID_MONITOR,

More task IDs can be added before the TASK_ID_COUNT, so that TASK_ID_COUNT always reflects the proper number of tasks handled this way. Task IDs and task pointers are mapped by a table:

As a matter of convenience, the task pointers can now be defined as macros:

This is nearly equivalent to defining e.g MonitorTask directly as a task pointer:

Task * MonitorTask;

The difference between using a table and direct declaration of Task pointers is basically that for a table, all pointers are collected while for the direct declaration, they are spread over different object files. For a reasonably smart compiler, the macros can be resolved at compile time so that no overhead in execution time or memory space is caused by the table. Instead, the code of our example is even simplified:

for (int t_ID = 0; t_ID < TASKID_COUNT; t_ID++)

{

Message msg(“Hello”); TaskIDs[t_ID]->SendMessage(msg);

}

The TaskIDs table is initialized to zero in the idle task’s main() function.

4.3.2 Task Creation

As a matter of style, for each task a function that starts up the task should be provided. This way, the actual parameters for the task are hidden at the application start-up level, thus supporting modularity. The function setupApplicationTasks(), which is called by the idle task in its main() function, sets the serial channels to their desired values (SERIAL_1 in this case) and then calls the start-up function(s) for the desired tasks. In this example, there is only one application task; its start-up function is defined in class Monitor (see also Chapter 5).

1 // ApplicationStart.cc

...

22void setupApplicationTasks()

23{

24MonitorIn = SERIAL_1;

25MonitorOut = SERIAL_1;

26ErrorOut = SERIAL_1;

27GeneralOut = SERIAL_1;

29Monitor::setupMonitorTask();

30}

The function setupMonitorTask() creates a new instance of class Task with task function monitor_main, a user mode stack of 2048 bytes, a message queue of 16 messages, a priority of 240, and the name of the task set to “Monitor Task”.

1 // Monitor.cc

...

13void Monitor::setupMonitorTask()

14{

The priority (240) should be higher than that of other tasks (which do not exist in the above example) so that the monitor executes even if another task does not block. This allows for identifying such tasks ??? What tasks ???. Creating a new instance of class Task (i.e new Task(...)) returns a Task pointer which is stored in the TaskIDs table, remembering that MonitorTask was actually a macro defined as TaskIDs[TASKID_MONITOR]. With the Task::Task(...) constructor, a new task which starts the execution of a function monitor_main() is created. The function monitor_main() itself is not of particular interest here. It

should be noted, however, that monitor_main() may return (although most task functions will not) and that this requires special attention. For task creation, we assume that a hypothetical function magic() exists. This function does not actually exist as code, but only for the purpose of explaining the task creation. Function magic() is defined as follows:

void magic()

{

Task::Terminate_0( monitor_main() ); /* not reached */

}

Note that Terminate_0() is actually defined to have no arguments, but since magic() is only hypothetically, this does no harm.

1 // Task.cc

...

99void Task::Terminate_0()

100{

101Terminate(0);

102}

...

104void Task::Terminate(int ex)

105{

106{

107SerialOut so(ErrorOut);

108so.Print("\n%s Terminated", currTask->name);

109}

110currTask->ExitCode = ex;

111currTask->TaskStatus |= TERMINATED;

112Dsched();

113}

magic() calls the task’s main function, which is provided when the task is created (in this case monitor_main()), as well as Terminate_0() in case the main function returns. Normally tasks do not return from their main functions; but if they do, then this return is handled by the Terminate_0() function, which merely calls Terminate(0). The functions Terminate_0() and Terminate(int ex) may also be called explicitly by a task in order to terminate a task; e.g. in the case of errors. If these functions are called explicitly, then a message is printed, an exit code is stored in the TCB, and the task’s state is set to TERMINATED. This causes the task to refrain from execution forever. The TCB, however, is not deleted, and the exit code TCB may be analyzed later on in order to determine why the task died. Setting the task status to TERMINATED does not immediately affect the execution of the task; hence it is followed by a Dsched() call which causes the task to be swapped out.

Now task creation mainly means setting up the TCB and the user stack of the task. The user stack is created as if the task had been put in state STARTED after calling Terminate_0() in magic, but before the first instruction of the task’s main function. First, several variables in the TCB are set up according to the parameters

supplied to the constructor. At this point, the TCB is not yet linked into the task chain.

35unsigned short qsz,

36unsigned short prio,

38)

39: US_size(usz),

40priority(prio),

41name(taskName),

42TaskStatus(STARTED),

43nextWaiting(0),

44msgQ(qsz),

45ExitCode(0)

...

Then the user stack of the task is allocated and initialized to the character userStackMagic (’U’). This initialization allows to determine the stack size used by the task later on.

46{

47int i;

The task’s program counter is set to the first instruction of its main function. If the task is swapped in later on, the execution proceeds right at the beginning of the task’s main function. Also all other registers of the CPU in the TCB are initialized. This is not necessary, but improves reproducibility of faults, e.g. due to dangling pointers.

53Task_A0 = 0xAAAA5555; Task_A1 = 0xAAAA4444;

54Task_A2 = 0xAAAA3333; Task_A3 = 0xAAAA2222;

55Task_A4 = 0xAAAA1111; Task_A5 = 0xAAAA0000;

56Task_A6 = 0xAAAA6666;

57Task_D0 = 0xDDDD7777; Task_D1 = 0xDDDD6666;

58Task_D2 = 0xDDDD5555; Task_D3 = 0xDDDD4444;

59Task_D4 = 0xDDDD3333; Task_D5 = 0xDDDD2222;

60Task_D6 = 0xDDDD1111; Task_D7 = 0xDDDD0000;

61Task_PC = main;

62Task_CCR = 0x0000;

The user stack pointer of the task is set to the top of the user stack. Then the address of Terminate_0() is pushed on the user stack. Task::Terminate_0() is called in case the task’s main function returns.