Architectural Overview

The Dynamic Multi-protocol Manger (DMM) is an arbiter of RF commands between multiple protocol stacks and the RF Driver. It controls the scheduling of RF commands by providing a set of hooks to the RF driver, replacing the default scheduling behavior. The DMM bases the scheduling on the constraints and requirements set by the Policy table and has the ability to re-order the RF command queue provided by the RF Driver as needed. The DMM also intercepts RF Driver API calls and can, in certain scenarios, perform additional changes to the RF commands besides the scheduling order based on the current policy.

The diagram below shows how the DMM interacts with the protocol stacks and user application.

../_images/ditaa-81e7c48eca4ef7941c51ef840863f1a309328a5c.png

The blocks above with red fill are part of the DMM component. The other components (RF Driver, application task, protocol stack) would be present in a typical single mode application. From the diagram above, it can be seen that the DMM is made up of two primary components:

  • DMM scheduler
  • DMM policies and states table

The DMM scheduler is as a single component in the application. It keeps track of RF commands submitted by each stack and PHY switching events originating in the RF driver. The policy table contains the current state of each stack application as well as what scheduling parameters to use for a specific combination of states. The scheduler uses the policy table to perform scheduling of the associated stacks. Initialization of the policy table and scheduler happens in DMMPolicy_init() and DMMSch_init(). Before any of the modules are used, the modules need to be opened by calls to DMMPolicy_open() and DMMSch_open().

Setting up the antenna switching is important if one stack operates in the 2.4 GHz band while the other uses the Sub-1 GHz band. The DMM is not able to directly control the antenna switching, this is typically handled inside the RF driver callbacks registered inside the project board file.

The DMM scheduler software module mimes the command execution APIs of the RF driver module including RF_open(). Therefore, when using a function mapping table like below, no changes to the stack implementation would be needed:

#include <ti/dmm/dmm_scheduler.h>

#define RF_open             DMMSch_rfOpen
#define RF_postCmd          DMMSch_rfPostCmd
#define RF_runCmd           DMMSch_rfRunCmd
#define RF_scheduleCmd      DMMSch_rfScheduleCmd
#define RF_runScheduleCmd   DMMSch_rfRunScheduleCmd
#define RF_cancelCmd        DMMSch_rfCancelCmd
#define RF_flushCmd         DMMSch_rfFlushCmd
#define RF_runImmediateCmd  DMMSch_rfRunImmediateCmd
#define RF_runDirectCmd     DMMSch_rfRunDirectCmd

The DMM scheduler does not redefine all RF APIs. Some of them are just passed through and others should be called in the RF driver directly. Primarily, the DMM intercepts RF_open(). The DMM scheduler provides the RF driver hooks for scheduling and conflict resolutions.

When the scheduler hook is invoked from the RF driver, the DMM will update the priority based on the policy. It will then inspect the command and based on the current policy, it will either:

  • Put the commands in the queue as is
  • Put the command in the queue with a delayed start time
  • Call conflict resolution hook if there is a conflict in time
  • Cancel the command based on current policy

When the conflict resolution hook is invoked from the RF driver, the DMM will resolve the conflict based on the current active policy. This means it will either:

  • Cancel one of the conflicting commands
  • Delay one of the conflicting commands

A stack is registered by calling DMMSch_registerClient(). The DMM scheduler assumes that each stack operates in a separate TI-RTOS task. Since the remapped RF driver functions do not know anything about tasks, the task handle submitted during registration is later being used to deduce the current active stack in each function call.

The actual command scheduling is fully transparent for the application. It is only necessary to update the scheduler with the current system state and scheduling policy. This is done in DMMSch_updatePolicy().