[参考译文] CC2674P10：调试过程-处理时间

admin

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1408230/cc2674p10-commissioning-process---processing-time

器件型号：CC2674P10

工具与软件：

您好！

我有一个关于使用 "网络转向"命令在 Zigbee 上进行配置的过程的问题。执行此命令时、应用程序将被完全阻止、并且所有应用任务不再在介于之间的不同时间段内执行 350和550ms . 目标是减少此时间。

在分析过程中,我们发现:

当定期提出调试请求并且不存在控制器时、Zigbee 堆栈仍会每次使用相同的初始化时间、而不与控制器进行任何实际交换。
针对每个请求系统地重复初始化阶段。

它让我有3个问题:

即使没有控制器、使用网络转向命令进行调试的预期处理时间是否为400 ms？
在应用程序定期启动该命令的情况下、是否有办法减少在该例程中花费的时间(先初始化一次、然后跳过)？或者是否必须重复所有步骤？
最后、根据文档中> 12.5 Network Steering Procedure (非网络节点的网络转向过程)、
(https://software-dl.ti.com/simplelink/esd/plugins/simplelink_zigbee_sdk_plugin/1.60.00.14/docs/zigbee_user_guide/html/zigbee/developing_zigbee_applications/z_stack_developers_guide/z-stack-overview.html#commissioning)有一些可配置参数。减少处理时间的一个想法是禁用辅助通道(仅在主通道上搜索)。您会推荐它吗？

谢谢！

Geoffrey

4 个月前

0 admin 4 个月前

TI__Guru**** 1783340 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

尊敬的 Geoffrey：

请参考正确的文档、此处是 TI Resource Explorer 提供的最新 Z-Stack 用户指南。您当然应该移除辅助通道组、减少主通道组中扫描的通道数量、并可能减少 BDB_DEFAULT_SCAN_DURATION (未测试)。请注意、这些更改将降低在附近识别开放 Zigbee 网络的可能性。

此致、
Ryan

0 admin 3 个月前

TI__Guru**** 1783340 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好、Ryan、

感谢您的反馈、我现在提供更多信息。

移除辅助通道不会对调试时间有太大影响。
图37。不在网络上的节点的网络转向过程会使您认为交换密钥等需要更长的时间。然后查找网络。但是、使用网络转向命令时、无论是否找到网络、调试时间都是相似的。

我们也尝试了以下操作:

networkStateNV == ZDO_INITDEV_RESTORED_NETWORK_STATE :在这种情况下调用 ZD447State App_Restore ()以恢复以前的网络
- ZDOInitDeviceEx()(368 ms)
- zgInitItems()(210ms)
- zgInitItems()(155毫秒)
networkStateNV != ZDO_INITDEV_RESTORED_NETWORK_STATE：默认设置网络参数
- ZDOInitDeviceEx()(401毫秒)
- zgInitItems()(210ms)
- NLME_InitNV ()(80、71 ms)
- NLME_SetDefaultNV ()(92、5ms

如您所见,ZDOInitDeviceEx()函数是调用 Zstackapi_BdbStartCommissioningReq ()函数时出现延迟的主要原因。更特别的是,它主要是由于某些子功能的执行,如 zgInitItems ()、 ZD4.72 App_Restore State ()、 NLME_InitNV ()、和 NLME_SetDefaultNV ()。

这些功能似乎是在调试期间系统执行的、即使未检测到开放网络也是如此。这就引出了几个问题：

为什么即使网络不可用也要执行这些操作？例如、如果器件尚未连接到网络、为什么我们需要恢复或重置网络设置？这似乎在我们尝试扫描开放网络时引入了不必要的延迟。
是否有可能在调试环境中优化这些功能的执行？ (它们位于 bdb.c 中)

例如、通过添加自身的执行条件(仅在还原现有网络或初始化新网络时运行这些条件)？通过修改 ZDOInitDeviceEx (delay、x)内的延迟参数

此致

Geoffrey

0 admin 3 个月前

TI__Guru**** 1783340 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

这样做是为了恢复自上次执行网络转向以来可能已更改的 NV 设置、例如信道和 PanID。
如果客户确信不会更新 NV 项目、则可能会减少在启动时调用 zgInitItems 的次数。他们还可以进一步评估对扩展延迟长度的更改、并确定它是否影响 ZR 正确加入网络的能力。非易失性(NV)子函数是列出的唯一客户无法修改的 API、因为它们驻留在源代码中。

    // Only delay if joining network - not restoring network state
    extendedDelay = (uint16_t)((NWK_START_DELAY + startDelay)
              + (OsalPort_rand() & EXTENDED_JOINING_RANDOM_MASK));

此致、
Ryan

Zigbee®︎ 和 Thread（参考译文帖）

Zigbee®︎ 和 Thread（参考译文帖）(Read Only)

[参考译文] CC2674P10：调试过程-处理时间