[参考译文] CC2652P：CC2652P

您好 Tarek、

非常感谢您的迅速和明确的答复!

我们将遵循您的建议—特别是使用数据包监听器进行检查以更好地了解连接延迟LightProfile_GetParameter()、并探索LightProfile_SetParameter()用于处理器件与 LightBlue 之间数据通信的和函数。

我们将运行一些测试、如果我们遇到任何其他问题或需要进一步澄清、我们将返回给您。

再次感谢您的支持！

此致、
Roberto

尊敬的 Tarek：

继上一次讨论之后、我想为您提供有关扩展 BLE 功能时遇到的问题的更多技术细节。

我们正在根据 dmm_zed_switch_remote_display_app_CC1352P_2_LAUNCHXL_tirtos7_ticlang 示例处理 DMM 工程。 在 Zigbee 方面、我们实现了对8个单独端点(例如、针对8个负载)的控制。 为了在 BLE 端镜像此功能、我们定义了8个 GATT 特性(每个端点一个)、以允许通过 LightBlue 等移动应用进行控制。

我们观察到的情况如下：

• 由于具有1或2个 BLE 特性、一切都按预期运行：我们可以从 LightBlue 写入值、在设备上接收这些值、并触发相应的操作。
• 当我们添加更多特性(例如端点3及以上)时、我们会遇到严重的不稳定性：

  • 针对索引度较高的特性(例如端点4)正确触发 WriteAttrCB 回调、并执行此操作：从 LightBlue 写入"1"正确打开端点、写入"0"则将其关闭。

  • 但是、在几次成功切换后、再次写入(例如、"1"到端点4)不会产生任何影响—端点不会做出反应。

  • 从那时开始、不再能通过 BLE 控制任何端点。 虽然 WriteAttrCB 在调试中继续被触发、但 BLE 任务不再运行、并且 RemoteDisplay_processAppMsg ()不再被调用。

  • 因此、BLE 事件不再被处理(例如断开连接事件)、器件会停止广播、在我们手动将其复位之前、它会变为"不可见"。

  • 由于只有1或2个端点特性(加上示例中的默认特性)、这种行为永远不会发生：即使在重复切换后、一切都能可靠地工作。

这导致我们怀疑堆栈溢出、事件队列溢出或任务耗尽问题—这可能是由于超出属性、堆或任务资源的内部限制而触发的。

您建议检查 BLE 任务队列、栈大小或相关配置、以识别瓶颈？

是否有任何堆或内存池设置我们应该调整以支持更多特性？

提前感谢您的支持。

您好、Roberto、

感谢您提供信息！ 我将研究这一点、并在明天作出回应。

此致、

Tarek

您好、Roberto、

这当然是奇怪的行为。 若要构建 GATT 表并相应地使用它、我建议查看 basic_ble 示例、特别是 Common -> Profiles 中的 simple_GATT 配置文件。 如果您对此有任何疑问、请随时提问。

这也可能与资源枯竭有关。 您是否检查过内存分配？

此致、

Tarek

尊敬的 Tarek：

感谢您的支持和有用的建议。

我们能够确定 BLE 不稳定的根本原因。 问题不是 GATT 表定义本身造成的、而是由从 BLE 上下文调用的 Zigbee 栈调用(特别是 zclSampleSw_updateCurrentSummationDeliveredAttribute)引起的。 这种交互偶尔会导致 BLE 任务停止(在就绪、运行和被抢占状态之间循环)并停止广播、尤其是在写入索引度更高的端点的特性时。

我们通过将 BLE 任务优先级从1增加到2来解决问题、现在这三个任务具有相同的值。 此更改允许进行适当的调度、并防止 BLE 任务在执行期间耗尽。 由于进行了此更改、现在所有特性都能在所有8个端点可靠地工作。

关于您关于在 basic_ble 示例中查看 simple_gatt 配置文件的建议：是的、我们已经对此进行了审阅、这在定义和使用自定义特性时在指导实现和确认最佳实践方面非常有帮助。

再次感谢您的帮助。

此致、
Roberto Nucera