Zigbee设备有快有慢，能不能借鉴牙膏厂设计X86指令的一些思路？

zigbee_luo

当年牙膏厂的X86干不过RISC，主要原因就是X86指令有快有慢，快的指令要等慢的指令。然后牙膏厂引入了RISC才有的超标量技术，流水线技术和乱序执行技术。
网关在控制快慢不同的Zigbee设备上，目前主要还是采用轮询的方式，但是Zigbee设备有快有慢，常规的思路还是快的等慢的，比如典型的德州仪器的CC2652P适配器采用的ZNP指令。
如果Zigbee适配器上同时向多个不同的设备发送控制指令，并异步等待应答，理论上来说就可以有效规避快的等慢的。

relliky

wifi以前也是最基本的轮询，毕竟所有设备都在共享一个无线带宽，感觉按你的思路，是不是只要接入一些新的wifi的技术就行了？

wdmywm3

硬件层面和软件层面的技术不能混为一谈
而且即便是x86也一样要快的等慢的，不然不会在并行效率上被gpu摁着暴打了
通常轮询并不是导致卡顿的问题，而是某个设备慢了以后，影响了后续自动化的执行
你哪怕改成异步，你前一个设备的状态没有回来，后续自动化就必须等它

zigbee_luo

wdmywm3 发表于 2025-7-16 16:52
硬件层面和软件层面的技术不能混为一谈
而且即便是x86也一样要快的等慢的，不然不会在并行效率上被gpu摁着 ...

轮询是软件层可控的，所以软件层可以灵活处理。对于有快有慢的设备，控制端的软件可以异步等待返回。比如主机要轮询10个从机，假设每个从机都是1秒钟内有响应，那么系统就是超时1秒。如果从机设备自身原因未能在1秒内响应，主机就给这个慢的设备记一个超时，等这个掉队的设备回复响应后，主机再消除这个超时记录，并把返回信息当成正常数据处理。

zigbee_luo

relliky 发表于 2025-7-16 16:52
wifi以前也是最基本的轮询，毕竟所有设备都在共享一个无线带宽，感觉按你的思路，是不是只要接入一些新的wi ...

不是硬件技术，而是软件策略。理论上说慢的设备无论拖了多久才回复消息，只要回复了消息，就算正常。但是快的设备不能等慢的设备，也就是说主机轮询基本上就是每个从机独占主机一个任务进程。