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 (when using absolute triggers)
the end time of the RF command provided in the scheduler parameters (if applicable)

If a stack submits a command and there are already posted commands in the queue, the scheduler will try to fit the command into a free slot in the queue. The decision on where in the queue the command is inserted depends on the trigger type, timings and priority of the command posted and those already in the queue. The scheduler can decide to put a posted command at the top, middle or end of the queue. If it doesn’t find a slot and the constraint is set to DMMPOLICY_TIME_NONE_CRITICAL, then the command is simply appended to the end of the queue. Otherwise 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 and pending commands belonging to the conflicting stack. The RF_EventCmdPreempted callback 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 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.

$@startuml :A stack wants to schedule \na RF command; :Update RF command parameters \naccording to current DMM state; if (Try to schedule the command) then (Schedule conflict) if (Current stack timing \nconstraints:) then (DMMPOLICY_TIME_\nCRITICAL) if (Try to preempt the conflicting stack \nbased on current stack priority) then (Preemption possible) :Abort commands that belongs \nto the conflicting stack; if (Try to schedule the command) then (Schedule conflict) :The command is not accepted; stop else (No scheduling conflict) :The command is added to the first \nfitting location in the queue; stop endif else (Preemption is not possible) :The command is not accepted; stop endif else (DMMPOLICY_TIME_\nNONE_CRITICAL) :The command is added \nto the end of the \nqueue; stop endif else (No scheduling conflict) :The command is added to the first \nfitting location in the queue; stop endif @enduml$

Figure 28. Scheduling flow for a newly posted command.¶