微波EDA网,见证研发工程师的成长!
首页 > 研发问答 > 无线和射频 > 射频无线通信设计 > Zigbee之路 一、Zigbee,想说爱你不简单

Zigbee之路 一、Zigbee,想说爱你不简单

时间:10-02 整理:3721RD 点击:
不知不觉,或者说 机缘巧合 也好,就像每天上下班挤公交,挤地铁一样,我真的就开始了zigbee的开发。
我说的是,我现在的工作是在 cc2530这款芯片上做开发,尽管还没使用到真正的zstack,真正的zigbee组网。

我不知道,你是怎么走上zigbee或者无线射频这条路。
不过,对我而言,这是一条比较曲折的路,而且中间,还有许许多多的拖延......
我不想把这个帖子,写成以前那种滥情路数的文章。

zigbee这个东东,我懒得再去复制那些又空又大多余的解释。
我只提一些我知道,并且我认为有真实意义的内容,那也是我最关心,而我也相信那会是你最想知道的:

1.zigbee是一种短距离自组网,它主要面向控制应用。因为它的网络容量不大,传输速度不高——所以,如果你老想着什么高清视频,我请你出门左拐去找wifi,实在不行也可以找蓝牙。
每一种东西都有自己的定位,过分的期待,只会让它失去自己存在的独特性。

2.关于zigbee技术的实现问题。
这是个很要命的东西,我知道你一定在网上看到很多定义,说道,但是说到底,我们到底要如何把它变成现实存在?
zigbee协议,尽管号称相对于蓝牙wifi是一个简单许多的协议,但这种东西的复杂程度,也绝对不是一个什么i2c之类的通信总线可以相比的。
考虑现实中的情形。据我自己所知,目前的 zigbee实现方案无非两种:
1.有一些无线射频芯片本身设计的符合zigbee的电气要求,并且硬件上具备了实现协议的能力;
我相信你一定比我还清楚,目前这个主要指的是 TI 的 CC1xxx cc2xxx以及最近刚听说的 cc3xxx系列芯片。
2.另一种是 SoC,可以理解为在 上述 的基础上,加入一个相对高性能的单片机内核。
这个,就是我们更加熟悉的cc2530,cc2430这几个系列。
它们的内核都是8051内核,是增强型的8051,单周期,而且加入了许多模拟的,数字的外设,甚至有传感器,几乎算得上真正意义上的SoC。
另一款,最近才知道的,就是现在越来越无所不在的ST芯片,STM32W系列。
但对于这个系列,我仅仅知道,它和cc2530非常类似,是一种带zigbee协议功能的SoC。

关于这个问题,我认为我们真正要关心的只有两个问题:
1.价格,货源。
有一条选型原则是:尽量不要选用那种只有独家能提供的芯片。
比方说,一个大家最熟悉的例子,ATMEL在成为8051事实上的标准以后,自己推出了完全属于自己的AVR系列十六位机。
我个人没使用过这款机型,但是从一些方面我也能了解它是一款非常优秀的芯片,而且,ATMEL为它营造了一个相当不错的生态。
比如现在相当火热的Arduino,又比如,有一次我在使用一个USB第三方库libusb时,我意外发现,居然有相当多的往AVR上移植这个软USB协议的资料。USB的自定义开发其实是相当复杂的。
有许多带USB外设的单片机,实际上都是提供了一个只能针对自己硬件的协议栈来实现的。

然而,AVR却是ATMEL一家提供的机型,结果,很不幸的是真的发生了这类让我们担忧的事情。
具体时间我记不太清楚,大概是一年左右以前,AVR突然全线提价,这件事情对我最直接的影响是
当时我使用的AT89S52单片机的下载器是基于 AVR mege8做的,由于AVR的全线提价,居然导致我没办法再买到这根线。

而此后,更听说一件事,ATMEL官方决定放弃 AVR中的mega8系列,专做中高档的 mega16和mega32。
另外,ATMEL在08年以及以后的几年里,都曾提过要出一个对AVR的增强系列,名字好像是 XMEGA之类的。
然而,关于这款芯片,我却从来没听说过,也就是说,它可能从来没有推向过市场,或至少没被开发者广泛使用。

我们不再轻易评论这些事情,厂商开发者各有各的难处,然而,这些事情恰恰验证了一个说法:一个只有一家提供的机型是非常危险的。
假设以后它停产了,不再升级.......你能怎么办?你不是年消费量上几十万几百万的大客户,你没有资格人家也不屑和你签订量产合约。
你其实只是一个一年下来可能就消费个几十上百,了不起几千片的个人或者小团队。有些事,你伤不起。人贵有自知之明,不要拿自己的身家性命系在别人的产品线调整上。

2.为了一个zigbee,你就要换一个芯片?
zigbee被炒得很火很火,但是不管如何,在我看来,它充其量只是等同于一个无线通信外设。
但是,cc2530这些系列,stm32w也好,似乎如果不用TI ST的这两款芯片,你就没办法获得这个功能。
当然你还可以选择 采用CC那几个系列的无线射频芯片,配合自己的单片机来做。

然而事实上,即便如此,面对相当复杂的zigbee协议,这是一套从硬件底层到应用层的复杂协议。
TI是提供了好几套协议,如果你选择上述的第二条路,你就只能移植,而这,真心的不会是一件很容易的事情——不然,TI的SoC,估计只能喝西北风去了。
所有这些,都是风险。

所以,很轻易可以得出一个结论:zigbee想说爱你不简单。

有点晚了,先写到这里,暂时也没想到什么可写了,晚安。

对了,忘了说。
前面我似乎说了很多zigbee实现方面的麻烦。

然而我绝对没有教唆你 放弃而退 的想法。
否则,我也没必要 费那么多唇舌写这个,也可能是这系列帖子。

然而,在做一件事,对这件事有一定的优劣势分析,绝对是有利而无弊的。

最近开始关注和物联网中传感器层次的技术,NFC,ZIGBEE这些。
由于是纯做软件的,对于供货链这块也没资格关注,但是关于ZIGBEE的协议栈还是有些想法的。
不少公司都在做ZIGBEE的芯片,做法各有不同,包括其上的ZIGBEE的协议栈好像都有不同,这样的话不同公司之间的设备还不能通信,感觉有点群雄割据,抢地盘的架势。
门外汉的浅见,继续学习中。

其实这些都不是我们考虑的事,移植协议栈很麻烦,而且开源的有很多BUG,没什么人维护,即使又维护也未必会把你改善的代码上传

嗯,确实不是我们能左右的事情。
但总是要看清楚状况。
顺带看看有没形势扭转的时候

所见略同

楼主观点看起来很嫩……
总的来说,zigbee不面向控制应用,无线本身不稳定,容易有丢包和网络延时,控制应用不能接受。正确的答案是,zigbee主要面对小流量数据采集、非关键变量的非实时监测、以及……轻微的控制需求吧……点点灯拉拉窗帘啥的
就算你选了TI还是ST的zigbee方案,你还是没有办法找到一颗备选芯片,因为无论是ST还是TI的方案,simpleMAC和ZSTACK的核心部件都是不开源滴,移植到其他平台很不现实。
还有,世界上还是有不少自组网开源协议栈的,免费提供几个关键字:freakz、tinyOS、msstatePAN...

肺腑直言

记不得在哪看的了。说TI提供的公用协议栈还是有问题的,120个终端,丢包率就挺高的。
帖子作者最后换了商用协议栈才解决

非常感谢你这样的回复。
不知道你是做哪方面的应用的?

能看到源码的。
我回头看看是不是有些看不见的部分

恩LZ位的文字有些问题,给你指一下哈

1、AVR到今天也只有8bit和32bit两种,木有16bit的版本,而且大部分应用基于8bit的AVR处理器核心。AVR系列的命名规则很简单的,但是很明显你误解了
2、zigbee真正的价值在于那套自组网和具有路由能力的软件,跟硬件关系不大的,你可以去看看市场上的成品,普通的点对点或者点对基站的模块和具有网关能力的模块价格根本就是一个天上一个地下换句话说,软件是可以跨平台的,更何况TI新出的RF芯片都是cortex-m架构的,跟ST的一个妈生的,移植更容易

应届毕业生一个,喜欢电子论坛闲逛

只从温总提了提,这东西就开始火起来, 现在温总下台了, 可预知它们的结果, 在这块土地上永远是外行领导内行, 理想很丰满, 可惜现实很骨感.

真没觉得这个高不成低不就的东西有何前途可言.

除了ti, 飞思卡尔也在做.

我用的是cc2430, 那个恶心的微码结构的控制rf , 等于两个独立系统的一个拙劣的拼凑.

===========================================================
其实我更感兴趣的是版主所说的AVR mege8, 这个找替代品应该不是很难吧, 台系中可替换应该有很多, 据我所知, 国内已经有人盯上了avr, 准备做全线兼容品.

首先,关于AVR,我承认, 小蛋说得对,我对命名想当然了
另一方面是,因为没真正用过AVR,只是听说听说,都说AVR是16位——看来很多人都看错名字了,就不晓得那些人有没用过——是在杜样那听来的,看来他真的是没用过的。

AVR这个问题到此为止。

回LS的兄弟。
你有啥研究发现,记得回来知会一下俺们.......

你用的2430,我用2530,关于 那些 无线协议 的底层 细节,我还没开始看。
看样子,你也对代码有点洁癖吧

Chip vendors/devices [edit]
An XBee radio.To become ZigBee certified as a semiconductor company, vendors must ensure their applications are interoperable. Periodic interoperability events verify that devices work with other certified devices.

Atmel ATmega128RFA1,ATmega256RFR2, AT86RF230/231/233
Anaren A2530R24E, A2530R24R
Digi International XBee XB24CZ7PIS-004
Silicon Labs EM250, EM351, EM357
Freescale MC13224, MC13226
GreenPeak Technologies ZigBee RF4CE, ZigBee PRO, ZigBee Green Power, ZigBee IP
Jennic JN5148
NXP Semiconductors JN514x RF4CE and JN514x ZBPro
Renesas uPD78F8056/57/58, M16C/6B3 and R8C/3MQ
STMicroelectronics STM32W
Samsung Electro-Mechanics ZBS240
Telegesis (UK) Ltd ETRX2 and ETRX357
Texas Instruments CC2530 and CC2520
Microchip Technology MRF24J40MA, MRF24J40MB, MRF24J40MC

求楼主发个完整的Cc2530的开发过程的帖子。

同感 苦恼

移植协议栈很麻烦
比如你可以在NRF2401上去实现zigbee,你要做PHY,MAC。
要不要移植?
选择移植,会消耗时间。但是不移植zigbee,你如何去应对载波冲突,以及节点盲区?
要把无线通讯做好很不容易。

Copyright © 2017-2020 微波EDA网 版权所有

网站地图

Top