Architectural Overview

The Dynamic Multi-protocol Manger (DMM) is an arbiter of RF commands between multiple protocol stacks and the RF Driver. It will intercept calls to the RF driver and will potentially modify the order in which RF commands are scheduled based on constraints and requirements of the stacks and the application.

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

../_images/ditaa-9a806d7f76e7ad750ace9e304dcb365a99bcc5de.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. Initialization happens in DMMSch_open() in which the application can register a callback function to set the correct antenna path for the current stack configuration. 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 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() and RF_scheduleCmd().

The scheduler will inspect the commands being sent to the RF driver and based on the policy, it will either:

  • Schedule the commands as is
  • Cancel the command based on current policy and stack state
  • Change the priority of the command based on the policy and stack state

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().