znp-host-framework完美支持OTA和ZCL(zigbee没有支持一样能搞定，TI你还有什么可说的)

behold

Other Parts Discussed in Thread: Z-STACK, CC2530

由于TI提供的原始znp-host-framework太过于简陋，以至于都不支持OTA操作，但是标准的zigbee linux gateway又过于复杂了，好多人也遇到OTA出的各种问题，也不容易用在实际项目中，而且bug问题一堆，虽说最新的Z-Stack 3.0.1号称修复了ZNP不兼容老的zigbee linux gateway，但是也没有测试，不知道能不能用。

前段时间把OTA从gateway完美移植到znp-host-framework，但是修改了ZNP固件里面MT部分的代码为代价的，后来发现，ZCL层其实也可以放到znp-host-framework来实现的，这样ZCL就不用占用ZNP上及其有限的内存资源了，数据格式即使发生变化，也不需要修改znp.eww里面相关的代码了，相当于收到空中数据afIncomingData直接转发给host，然后host发出的数据，直接通过MT_AF.c提供的接口直接发出去。

尤其是对于像CC2530这种弱爆了的MCU，麻辣隔壁，留给用户使用的RAM空间几乎没有了，曾经尝试在上面增加一点点新的功能，都爆出XDATA编译错误，其实所谓ZCL也就是数据收发的一种组织方式，最后都是调用AF_DataRequest发出去的。

把zcl.c和zcl_ota.c全部移植到znp-host-framework，已经完美工作，只是endpoint注册还得放在AF.c里面做，主要是数据收发之前都要查询一下endpoint是否存在，不存在就不收发。这有点讨厌，本来内存已经很紧张了，还搞个endpoint链表，不耗费内存吗，放到host上来做，不是更好吗，我host有64MB内存，跑arm linux都秒杀，顶的上几千个CC2530的6KB了吧。

自己分析了zigbee linux gateway的源代码，刚开始还以为AF层的所有操作都给做了，其实gateway并没有做AF层的东西，AF层的afDataRequest和AfIncoming回调函数还是要放在ZNP固件里面实现，包括邻居表之类的，都是必须放在ZNP端实现，那么运行gateway的主机程序，强大的硬件性能(300Mhz处理器+64MB DDR2)根本派不上用场啊，也不能增加邻居表，更不能增加关联表。

8 年多前

0 Michael.Zhang 8 年多前

Intellectual 420 points

1、技术干货帖，学习了，感谢hold li大大的分享，

2、TI的linux gateway，只想说一句：麻辣隔壁！！！

0 behold 8 年多前回复 Michael.Zhang

Genius 5959 points

呵呵，我水平也是一般，只是很多时候不服气而已，最后还是把问题给解决了，我这边开发这么久，没有TI的任何支持，技术问题都是自己解决的，最后我都把解决方法分享出来，希望能帮助更多的人。

0 Michael.Zhang 8 年多前回复 behold

Intellectual 420 points

TI的技术支持是这样的：

1、首先他要看你片子的用量（这个是关键），一年要是有个100w级别的量，你就是爷，有啥问题，他们会第一时间给解决。这是芯片大厂的尿性，不仅TI这样，像NXP，OV也是这德性，这是我自己的亲身体验。

2、像我们这种一般般的公司，一年用个几K，十几K（有的前期做研发和测试，需求量可能几百片），他们是根本看不上眼的，你发邮件，也就象征性回答一下问题，而且周期比较长，论坛里发技术贴，无非是无关痛痒的回复一下，对解决问题没什么实际意义，总的来说就是效率很低。

3、大神对znp-host-framework整体逻辑分析的很到位，虚心学习之。

0 VV 8 年多前

TI__Guru 58556 points

@hold li,

关于ZCL的部分在ZNP中是不包含，而且主要跟实际应用相关，放在host上面扩展性会更好。

关于AF部分，有一些代码处理跟路由相关，如果直接放在host上面，即便使用UART还是SPI，都会都会影响路由的相应速度。除非把整个zigbee协议栈放在host上面。

0 behold 8 年多前回复 Michael.Zhang

Genius 5959 points

我也是偶尔的一个机会，发现了znp-host-framework，但是这东西功能过于简陋，没有实现ZCL的所有操作，也没有OTA功能，里面更是还有不少bug，我拿到这个代码以后，实现了没有的功能，但是我想提交一部分代码到TI的git仓库，奈何没有任何权限。
在我们打算做zigbee的开发之前，zigbee linux gateway源代码是没有开放的，要签订协议。另外我们host平台并不是TI的AM335x，TI的AM3xxx平台我们以前做过，这个平台对于很多公司来说，技术上做起来都是有困难的，所以他们很多只好买那种做核心板的厂商，核心板厂商很多都是做AM335x的。由于不开放源代码，我们host没法运行zigbee linux gateway，只好通过代理商渠道那边联系TI，最后他们还是开放了zigbee linux gateway源代码，我们这边也完全移植成功，但是后期运行总会出各种莫名其妙的问题，后来就不得不放弃了。
其实我现在觉得znp-host-framework已经能完全满足工程需要了，zigbee linux gateway太过于复杂，里面各种socket回调收发数据，很是复杂，不建议很多人用在实际工程中，出了bug也不一定能找到在什么地方。不过代码实现的架构还不错，至少我把OTA移植过来没怎么费劲，包括他们里面用的google的protobuf-c实现来传输数据，我也是在这里第一次接触到protobuf，这玩意比那些做互联网开发的用的Json强大多了，性能好太多了。
其实纵观整个zigbee linux gateway框架，里面其实有很多冗余的代码，包括AF层的endpoint链表实现，这个既然是无法完全脱离ZNP实现，那就干脆让它在ZNP上实现好了，但是zigbee linux gateway又实现了一遍，多此一举。
zigbee linux gateway里面用了一个SampleDb做数据库，也是TI自己实现的数据库，不依赖于平台，但是我是觉得这个意义不大，数据库有增删改查，但是这个貌似删除只是做个#标记，并没有真正删除，既然zigbee linux gateway对硬件也是有要求的，没有操作系统的平台能不能跑zigbee linux gateway呢，显然是不能的，它里面很多东西都要依赖操作系统实现，那还不如用sqlite3做数据库，功能强大。
zigbee linux gateway之所以用到数据库，很多原因是要64位的芯片IEEEAddr和16位的ShortAddr短地址做绑定关系，我们知道IEEE地址是不变的，是整个芯片生命周期都存在的，但是短地址每次入网都是随机生成的，所以需要绑定关系，就要用数据库来保存。