| Real-Time Workshop® Embedded Coder™ | ![]() |
| On this page… |
|---|
Task Scheduling Code for Multirate Multitasking Model on Wind River Systems VxWorks Target |
Using the rtmStepTask macro, targets that employ the task management mechanisms of an RTOS can eliminate certain redundant scheduling calls during the execution of tasks in a multirate, multitasking model, thereby improving performance of the generated code.
To understand the optimization that is available for an RTOS target, consider how the ERT target schedules tasks for bareboard targets (where no RTOS is present). The ERT target maintains scheduling counters and event flags for each sub-rate task. The scheduling counters are implemented within the real-time model (rtM) data structure as arrays, indexed on task identifier (tid).
The scheduling counters are updated by the base-rate task. The counters are, in effect, clock rate dividers that count up the sample period associated with each sub-rate task. When a given sub-rate counter reaches a value that indicates it has a hit, the sample period for that rate has elapsed and the counter is reset to zero. When this occurs, the sub-rate task must be scheduled for execution.
The event flags indicate whether or not a given task is scheduled for execution. For a multirate, multitasking model, the event flags are maintained by code in the model's generated example main program (ert_main.c) . For each task, the code maintains a task counter. When the counter reaches 0, indicating that the task's sample period has elapsed, the event flag for that task is set.
On each time step, the counters and event flags are updated and the base-rate task executes. Then, the scheduling flags are checked in tid order, and any task whose event flag is set is executed. This ensures that tasks are executed in order of priority.
For bareboard targets that cannot rely on an external RTOS, the event flags are mandatory to allow overlapping task preemption. However, an RTOS target uses the operating system itself to manage overlapping task preemption, making the maintenance of the event flags redundant.
The rtmStepTask macro is defined in model.h and its syntax is as follows:
boolean task_ready = rtmStepTask(rtm, idx);
The arguments are:
rtm: pointer to the real-time model structure (rtM)
idx: task identifier (tid) of the task whose scheduling counter is to be tested
rtmStepTask returns TRUE if the task's scheduling counter equals zero, indicating that the task should be scheduled for execution on the current time step. Otherwise, it returns FALSE.
If your target supports the Generate an example main program option, you can generate calls to rtmStepTask using the TLC function RTMTaskRunsThisBaseStep.
The following task scheduling code, from ertmainlib.tlc, is designed for multirate multitasking operation on a Wind River Systems VxWorks target. The example uses the TLC function RTMTaskRunsThisBaseStep to generate calls to the rtmStepTask macro. A loop iterates over each subrate task, and rtmStepTask is called for each task. If rtmStepTask returns TRUE, the VxWorks semGive() function is called, and the VxWorks RTOS schedules the task to run.
%assign ifarg = RTMTaskRunsThisBaseStep("i")
for (i = 1; i < %<FcnNumST()>; i++) {
if (%<ifarg>) {
semGive(taskSemList[i]);
if (semTake(taskSemList[i],NO_WAIT) != ERROR) {
logMsg("Rate for SubRate task %d is too fast.\n",i,0,0,0,0,0);
semGive(taskSemList[i]);
}
}
}Redundant scheduling calls are still generated by default for backward compatibility. To change this setting and suppress them, add the following TLC variable definition to your system target file before the %include "codegenentry.tlc" statement:
%assign SuppressSetEventsForThisBaseRateFcn = 1
![]() | Replacement of STF_rtw_info_hook Mechanism | Target Function Libraries | ![]() |
| © 1984-2008- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |