RF Command Scheduling¶
RF command scheduling affects only those commands that are submitted through RF_scheduleCmd(). In the case of RF_postCmd(), the DMM redefines this to point to the RF_scheduleCmd() API using default parameters. The actual scheduling behavior is defined by the policy table entry for the current stack state combination. When an application updates its state via the DMMPolicy_updateStackState API, the DMM policy manager will evaluate and decide if the system state need to change. If the system state changes, the policy manager will update the DMM scheduler with the new policy.
When a stack wants to schedule an RF command, the DMM scheduler will process the command based on the scheduling parameters and the active DMM policy:
Scheduling parameters: | |
---|---|
|
|
Active DMM policy: | |
|
The resulting priority for each stack is then calculated as follows:
When RF_scheduleCmd() or RF_postCmd() is called the RF driver calls a scheduling hook into DMM. 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, a 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, assuming it takes priority. If the command
for any reason cannot be scheduled, for example in case of a conflict with a
higher priority stack, it is rejected.
A scheduling conflict occurs when a command from stack A is running and stack B is scheduling a command at the same time. To resolve the conflict the delay policy of the scheduled command is checked first. Regardless of the final priority, if the scheduled command is delayable it will be delayed until either the running command completes or the delay runs out. If the delay policy is not delayable, then the priority is checked. The running command is preempted if it has a lower priority. If the scheduled command is removed from the RF queue if it has a lower priority. Assuming the command is not IEEE or Proprietary RX command, an RF callback with the RF_EventCmdPreempted event is posted to the stack.
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 improvements.
The flowchart below shows the complete DMM scheduling flow starting from interception of a RF command.