[参考译文] 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