RF Command Scheduling

RF command scheduling affects only those commands that are submitted through DMMSch_rfScheduleCmd() or DMMSch_rfPostCmd(). The actual scheduling behavior is defined by the scheduling policy. The current policy is updated by the application via DMMSch_updatePolicy() whenever the system state changes.

When a stack wants to schedule or post an RF command, the DMM Scheduler will treat the command based on the following parameters:

• the current stack’s priority in the current system state (DMMPOLICY_PRIORITY_HIGH or DMMPOLICY_PRIORITY_LOW),
• the timing constraint of the current stack’s state (DMMPOLICY_TIME_CRITICAL, DMMPOLICY_TIME_NONE_CRITICAL),
• the start time of the RF command
• the start trigger type of the command

When a command is submitted, the DMM scheduler tries to schedule the command into the RF queue based on the start time, disregarding the actual end time of the command. If there is a conflict with another command at the scheduled start time, the conflict resolution hook is invoked to rule on the conflict based on the current policy. In cases where the submitted command is using the “TRIG NOW” start trigger, the command will always be inserted in front of the queue, behind any already submitted “TRIG NOW” commands. If the command for any reason cannot be scheduled, for example in case of a conflict with a higher priority stack, it is rejected.

If a high-priority stack submits a command that conflicts with a low-priority stack’s queued commands, it always wins and preempts any ongoing operation belonging to the conflicting stack. An RF callback with the RF_EventCmdPreempted event is posted to the stack in that case.

Warning

If the conflicting low-priority stack was considered a high-priority stack at the time it put its command into the queue, the new high-priority stack will not be able to preempt the already posted commands. Once a command is posted, it’s priority will not change if the owning stack’s priority change.

If a low-priority stack submits a command and there are conflicting high-priority commands in the queue, it depends on the policy timing constraint whether the command is accepted or not. If the constraint is DMMPOLICY_TIME_CRITICAL, then the command is not accepted. Otherwise it is appended to the queue.

Warning

The current scheduler implementation is baseline that has limitations. The DMM scheduler will evolve in the coming releases to cover these limitations along with enhancements.

The flowchart below shows the complete DMM scheduling flow starting from interception of a RF command.

Figure 52. Scheduling flow for a newly posted command.