RF Command Scheduling

RF command scheduling affects only those commands that are submitted through DMMSch_rfScheduleCmd(). 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 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 (when using absolute triggers)
• the end time of the RF command provided in the scheduler parameters (if applicable)

If a high-priority stack submits a command, it always wins and preempts any ongoing operation of a low-priority stack. The RF_EventCmdPreempted callback event is posted to the stack in that case. If there are low-priority commands pending in the RF driver’s queue, then the high-priority command is always put in front and the low priority commands are postponed.

If a low-priority stack submits a command and there are high-priority commands in the queue, it depends on the 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.

If a low-priority stack submits a command and there are other low-priority commands in the queue, then the scheduler will walk through the queue and try to fit the command in. If it doesn’t find a slot and the constraint is set to DMMPOLICY_TIME_NONE_CRITICAL, then the command is simply appended. Otherwise it is rejected.

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.