[参考译文] CC2652R：具有 BLE 外设的 DMM + Ti15.4协调器-在 DMM 调度程序中注册 MAC 线程

我收到了我们开发团队的反馈。

此更改的原因是15.4堆栈重构为 POSIX 线程(之前是 TI RTOS 线程)。

当您将7.40函数调用恢复为6.10函数调用时、它实际上抵消了 DMM 调度程序跟踪15.4堆栈的能力。

关于函数调用、我们建议 在7.40示例中将其保留为默认值。

现在、对于 BLE 广播间隔精度、这与它相对于15.4堆栈 RX 始终开启的默认优先级相关。 BLE 广播(包括广播)的默认优先级设置为低于15.4堆栈"始终开启"。 但是、如果错过了太多的连续广播、DMM 机制会暂时授予 BLE 广播更高优先级-这就是您看到600ms 广播间隔与预期100ms 广播间隔的原因。

您可以通过提高 BLE 广播事件的优先级来提高 BLE 广播的优先级：

在您的 CCS 项目中、dmm_priority_ble_154collector.c：

/* Global Priority Table: BLE connection is lower than 15.4 data */
StackActivity activityBLE_bleL154CollectorH[ACTIVITY_NUM_BLE*PRIORITY_NUM] =
{
    // ...

    DMM_GLOBAL_PRIORITY(DMM_BLE_BROADCASTING, DMM_StackPNormal, 95), // Toby: increase BLE broadcast priority to 95 from 60

    // ...
};


StackActivity activity154_bleL154CollectorH[ACTIVITY_NUM_154*PRIORITY_NUM] =
{
    // ...

    DMM_GLOBAL_PRIORITY(DMM_154_RX_BEACON, DMM_StackPNormal, 90), // Toby: BLE broadcast is higher priority than 15.4 RX beacon
    DMM_GLOBAL_PRIORITY(DMM_154_RX_BEACON, DMM_StackPHigh, 190),
    DMM_GLOBAL_PRIORITY(DMM_154_RX_BEACON, DMM_StackPUrgent, 240),



#if (CONFIG_PHY_ID == APIMAC_5KBPS_915MHZ_PHY_129 || CONFIG_PHY_ID == APIMAC_5KBPS_868MHZ_PHY_131)
    DMM_GLOBAL_PRIORITY(DMM_154_RXON, DMM_StackPNormal, 175),
#else
    DMM_GLOBAL_PRIORITY(DMM_154_RXON, DMM_StackPNormal, 80), // Toby: BLE broadcast is 95, higher priority than 15.4 RX on
#endif

    // ...
};

这样、他们能够观察到100ms 的广播间隔。

请注意、一般的权衡仍然适用、如以下文档所述： https://dev.ti.com/tirex/content/simplelink_cc13xx_cc26xx_sdk_7_40_00_77/docs/dmm/dmm_user_guide/html/dmm/performance.html

虽然上述更改提高了 BLE 广播的准确性、但它可能会影响15.4收集器侧的性能(例如错过更多数据包)。
需要牢记的一些事项、同时设计系统的其他部分。