[参考译文] CC1352P：加载分割图像支持

但那是3年前。  

因此，再次进行检查。  

因为如果TI不支持Split OAD，为什么这些宏仍存在于代码中。  

此外，它如何能够针对大型部署进行扩展。  

默认OAD(app+stack+lib)需要大量时间。

只有TI不支持此功能，或者无人支持？

另外， 如果TI继续忽略这一重要功能，实现这一目标的替代方法是什么。

您好Dhanraj，

TI开发的Zigbee OTA解决方案仍然仅支持 OAD_IMG_TYPE_APPSTACKLIB的图像类型，并且不打算在不久的将来扩展此功能。  ZCL 7规范允许单独的堆栈更新或应用程序修补程序，因此开发人员有责任整合此功能。  这包括找出一种方法，将应用程序部分与项目内的堆栈分离，以生成有效的OAD映像，因为这不是由SimpleLink SDK管理的。  宏仍然存在，允许用户扩展OAD的功能，BIM项目和OAD图像头文件在其他TI堆栈(BLE，15.4 等)之间共享。

此致，
Ryan

谢谢Ryan！

只是想了解-  

1)在设置/测试期间，只有1个协调员(使用OTA服务器工具)和1个路由器时，ZR/ZT软件_OTA_CLIENT项目需要多长时间进行升级？   

2) 在设置/测试期间 ，只有1个协调器/ZNP (带OTA服务器工具/网关)和10个以上的路由器(网络中有多个ZR 10节点，但OTA一次只更新1个)时，ZR_SW_OTA_CLIENT项目需要多长时间进行升级？   

根据我的经验，当其他路由器之间没有其他大量流量时，两种情况应该会有很大差异。 单台路由器的OTA过程应在5分钟内完成。

对于单台路由器，需要15分钟以上的时间。   

默认项目。  

使用CC2652P时，协调器和路由器在3米范围内。

在现实环境中，我想说这仍然是在预期范围内。

这次有没有改进的方法？

我们拥有大型网络设置，50多个节点。  

我不知道有什么方法可以改进这一点。