摘  要: 采用集射频与微控制器于一身的无线单片机CC2430作为网络节点设计的核心器件。介绍了CC2430芯片性能及特点,重点介绍了节点硬件设计,基于MSSTATE_LRWPAN协议栈的节点应用程序软件设计,设计并规定了PC机与协调器节点间的通信约定,给出了网络节点性能测试结果。 

　　关键词: Zigbee; CC2430; 无线单片机; MSSTATE_LRWPAN 

　　目前,短距离无线通信技术已成为无线通信技术领域的一个重要分支。在诸多无线数据传输应用中,其通信系统所传输的数据通常为小量的突发信号,即数据特征为数据量小,要求进行实时传送。如采用传统的无线技术,虽然能满足上述要求,但设备的成本高、体积大且能源消耗较大。针对这样的应用场合,人们希望利用具有成本低、体积小、能量消耗小和传输速率低的短距离无线通信技术。 

　　Zigbee技术是一种新的短矩离无线通信技术,由英国Invensys公司、日本三菱电气公司、美国摩托罗位公司以及荷兰飞利浦等公司在2002年10月共同提出,它具有成本低、体积小、能量消耗小和传输速率低的特性。该技术的提出旨在应用到诸如工业控制、环境监测、商业监控、汽车电子、家庭自动化等低速率网络应用场合,在这些场合中系统所需求的数据量小,传输速率要求不高,终端设备多采用电池供电的嵌入式设备。 

1 CC2430芯片性能及特点 

　　CC2430芯片沿用了CC2420芯片的架构,在单个芯片上集成了Zigbee 射频(RF)前端、内存和微控制器。使用1个8位MCU(8051内核),具有32KB、64KB、128KB三种可编程闪存和8KB的RAM,包含模拟数字转换器(ADC)、4个定时器(Timer)、AES128协处理器、看门狗定时器(Watch dog timer)、32.768kHz 晶振的休眠模式定时器、上电复位电路(Power On Reset)、掉电检测电路(Brown out detection),以及21个可编程I/O引脚。 

　　CC2430芯片采用0.18μm CMOS生产工艺,工作时的电流损耗为27mA;在接收和发射模式下,电流损耗分别低于27mA和25mA。CC2430的休眠模式和转换到主动模式的超短时间的特性,特别适合那些要求电池寿命非常长的应用。 

　　CC2430芯片的主要特点^[1]如下: 

　　(1)高性能和低功耗的8051微控制器核。 

　　(2)集成符合IEEE802.15.4标准的2.4GHz的RF无线电收发器。 

　　(3)优良的无线接收灵敏度和强大的抗干扰性。 

　　(4)在休眠模式时仅0.9μA的流耗,此时通过外部中断或RTC来唤醒系统。 

　　(5)在待机模式时少于0.6μA的流耗,此时通过外部中断来唤醒系统。 

　　(6)硬件支持CSMA/CA功能。 

　　(7)较宽的电压范围(2.0～3.6V)。 

　　(8)数字化的RSSI/LQI支持和强大的DMA功能。 

　　(9)具有电池监测和温度感测功能。 

　　(10)集成了8路8～14位模数转换ADC。 

　　(11)集成AES128安全协处理器。 

　　(12)带有2个强大的支持多种串行协议的USART口,以及1个符合IEEE 802.15.4规范的MAC计时器,1个常规的16位计时器和2个8位计时器。 

　　(13)强大和灵活的开发工具。 

　　(14)兼容RoHS的7mm×7mm QLP48封装。 

2 Zigbee网络节点硬件设计 

　　节点硬件设计框图如图1所示。为了实现网络的硬件基础架构,将硬件设计分为两大部分:无线收发模块及无线测试模块。无线收发模块作为节点间的数据接口,无线测试模块用于网络功能及性能测试。无线测试模块中采用RS232串口转换电路实现PC机与协调器节点间的数据传输。

　　无线收发模块电路包括CC2430芯片及其相关外围电路,由于CC2430将8051内核与无线收发模块集成到一个芯片当中,因而简化了电路的设计过程,省去了对单片机与无线收发芯片之间接口电路的设计,缩短了研发周期。该电路设计原理图如图2所示。该原理图主要包括接口电路、3.3V和1.8V电源滤波电路、芯片晶振电路、巴伦电路^[2]、入网指示电路及复位电路六部分。接口电路采用两个12脚排针,将CC2430所有的21个IO引脚以及电源引脚、复位引脚全部引出,以供用户在应用中根据实际情况进行相应的IO功能定义,增加无线模块的通用性;电源滤波电路根据不同的供电电源选用不同的滤波电容,该部分电路参考Chipcon公司滤波电容组设计;入网指示电路采用LED直连IO口P1.0。 

　　无线测试模块电路主要有绑定测试电路、JTAG电路、供电电路及串口转换电路四部分,原理图如图3所示。绑定测试电路包括一个LED指示灯及一个按键,LED直连IO口P1.1,按键直连IO口P0.0。主要为实现节点程序的下载及在线调试、开关与灯光控制绑定模拟测试、节点信息数据以及网络数据传输提供硬件接口。供电电路采用低功耗电源芯片LP2985,该芯片通常用于电池供电的场合(例如膝上型/掌上型电脑、PDA、便携式数码照相机/数码摄像机),能够确保150mA的输出电流,极低的漏电电压,输出电压精确度为0.01V。输入电压范围为4V～10V,输出电压范围2.5V～5V。实际应用中选用LP2985-3.3V稳压模块。在电源供电部分也可以采用2节AA电池供电,当采用该供电方式时,需将P5跳线拔去。串口转换电路采用MAX3223双通道转换芯片(2-driver/2-receiver),工作电压范围为3V～5.5V。该电路主要作为协调器节点与PC之间的接口。 

　　对于射频电路来说,器件的相互干扰变得尤为敏感。建议在无线模块部分采用双层PCB板,顶层主要用于信号布线,底层主要用于电源和地布线,在无布线的开放区域采用少量过孔相连到地。另外CC2430芯片底部必须可靠接地,因而其底部必须采用少量过孔与地相连。芯片的需接地管脚如果需通过过孔接地则过孔应尽可能与该芯片管脚接近,与电源管脚相连的去耦电容(滤波电容)也应尽可能地与电源管脚接近并且电容接地端尽可能地通过过孔可靠接地。外围器件的体积应尽可能的小,建议使用0402规格的阻容器件。如果采用PCB天线,则为了减少板材对PCB天线的影响以及方便PCB天线的制作,使得天线获得最佳性能,建议采用FR4普通板材,其介电常数要求为4.5,板材厚度为1mm,敷铜厚度为0.35μm。 

3 Zigbee网络节点软件设计 

　　节点应用程序设计流程如图4所示,应用程序底层运行的是MSSTATE_LRWPAN协议栈^[3]。应用程序首先进行硬件及协议栈初始化。硬件初始化包括串口初始化、IO口初始化及状态指示LED初始化;协议栈初始化主要设置协议栈各层初始状态。由于射频数据接收及串口数据接收均采用中断形式,还需进行中断初始化,并开全局中断。端点注册目的是告知PC端应用程序每个节点定义的端点信息(含端点号及端点数量)。PC绑定状态初始化为空闲状态,即进行串口状态监测与串口命令解析。应用程序状态初始化为建(入)网状态。完成以上初始化过程后进入一个无限循环执行应用支持子层状态或PC绑定状态机及应用程序状态机。 

　　在用户应用程序中,首先需要指定节点上端点间基本的通信模式。一种简单的模式就是所有RFD节点均周期性地向协调器节点发送数据包。该模式相对来说比较简单,因为协调器节点地址始终为0。 

　　因为事先并不知道RFD节点的短地址,所以RFD节点间不太可能采用直接消息传输模式进行彼此间的通信,这主要是由于在簇树网络中各RFD节点的短地址的分配还与其入网的顺序以及各自所在的路径深度有关。当然可以通过在协调器节点的应用程序中写一段代码告知各RFD节点彼此的网络地址,但这种做法将使得用户程序变得非常复杂和冗长,而且占用了不必要的代码空间。RFD节点间通信可以采用一种更简便的方法,即采用间接消息传输模式。在该传输模式中,各RFD节点间并不需要知道间接消息的目的地址而仅仅需要将消息发送给协调器节点。此时协调器节点通过查询绑定表负责将消息转发到其正确的目的地。 

　　RFD节点应用程序还要考虑一个问题:当RFD节点与其父节点之间的链路中断时(也即与其父节点的关联被解除)如何处理(这种情况的发生可能是由于其父节点电源供电不足或者是其父节点与其父节点的父节点关联被解除等)。此时RFD节点应该能够检测到该断链情况并且恢复该连接,这就要求应用程序执行ping父节点过程及重入网过程。ping父节点过程用于检测中断情况,而重入网过程用于通信链路恢复。 

　　节点应用程序也采用有限状态机(FSM)^{[4, 5]}风格,其状态转换如图5所示。可分为四部分: 

　　(1)节点建(入)网状态(APP_STATE_START_JOIN),协调器节点在该状态下执行网络建立过程,路由器节点及终端节点在该状态下则执行入网过程,并同时点亮建(入)网成功状态指示LED; 

　　(2)节点信息发布状态(APP_STATE_SEND_INFO&APP_STATE_SEND_ANNOUNCE),协调器节点执行发送节点信息过程,向PC机发送自身节点信息以及向PC机转发其子孙节点信息,路由器节点和终端节点执行节点信息通告过程,向协调器节点发送入网节点信息; 

　　(3)用户应用程序状态(APP_STATE_RUN_APPx),在这里实现用户消息数据的发送以及用户其他的指定功能。在执行应用程序FSM之前,协调器节点需执行PC绑定FSM,以检测和解析来自PC机的各种命令。当来自PC机的命令为用户发送数据命令时,则在PC绑定FSM中立即调用回调函数接收来自PC机的用户数据,然后将该数据拷贝到发射缓冲区中等待用户应用程序读取,并将RCVDataFlag发射标志置为TRUE。在应用程序状态中,协调器节点只检测数据发射标志RCVDataFlag是否为TRUE。若RCVDataFlag为TRUE,说明发射缓冲区中有待发射数据,则调用消息数据发送过程来完成一次消息数据的发送;在该状态中,终端节点执行readPCdata()过程直接从串口读取数据,并以“<”、“>”为数据字符起止标记,将RCVDataFlag发射标志置为TRUE以执行消息数据发送过程来完成一次消息数据的发送。若RCVDataFlag为FALSE则立即转入网络维护状态进而发送ping数据包。 

　　(4)网络维护状态(APP_STATE_SEND_PING&APP_STATE_START_REJOIN),包括执行链路状态检测及重入网过程。链路状态检测中,周期性向父节点发送0负载数据包,周期为1s。一旦节点ping失败,则立即执行重入网过程并关闭入网指示LED,重入网成功点亮入网指示LED并立即转入用户应用程序状态。 

4 PC机与协调器节点通信约定 

　　PC机与协调器节点通过二进制编码的方式进行通信。其数据包格式如图6所示。排列顺序为数据包包头(HEADER)占2字节,其值设置为0x01、0x02,用于区分是正常的ASCII码输出还是数据包输出;数据包负载长度字节;数据包负载(PAYLOAD),长度由LENGTH指定;数据包CRC校验,占1字节。数据包负载的第1个字节为命令类型字节,指定了数据包类型。 

　　在本约定中,命令类型(CMD TYPE)字节作为数据负载的一部分,因而数据包命令类型字节长度包含在LENGTH长度中,如果为纯命令数据包,则数据负载长度只为命令类型字节长度也即为1。如果数据负载为纯用户数据则命令字节值为0xFF。当节点报告入网状态或ping数据到达或协调器节点发送绑定请求等事件发生时,协调器节点向PC客户端发送相应的命令数据包,其数据负载为0。 

　　当协调器节点收到命令类型为0xFF的数据包时,协调器节点立即调用PC绑定回调函数用于处理接收到的PC数据包,同时将发射标志RCVDataFlag设置为TURE。 

    命令类型包括用户数据命令、0端点命令、绑定初始化请求命令、绑定初始化响应命令、获取绑定信息请求命令、警报请求命令等。具体定义如表1所示。 

　　在协调器节点中,命令的解析与执行通过PC绑定有限状态机pbdFSM()完成,其状态转换图如图7所示。目前仅定义了3种状态:空闲状态,在该状态中进行串口数据的读取以及来自PC命令的解析,根据不同的命令实现不同的功能;发送警报状态,在该状态中根据在空闲状态解析出来的命令类型,执行节点警报发送过程;发送警报等待状态,在该状态中执行警报应答过程,即对每个收到的警报命令协调节点均向PC回复应答。 

5 网络节点性能测试 

　　在节点参数测试中,使用Chipcon公司的SmartRF? Studio测试软件来测试节点参数,测试中两节点连续互发固定大小(30B)的数据包;通信信道固定(0x0B信道),节点发射功率为0dBm,测试节点采用3V电池供电。 

5.1 节点接收灵敏度(RSSI)测试 

　　在接收灵敏度测试中采用两节点互发数据的方式进行,两节点间无任何障碍物。测试结果如表2所示。 

5.2 通信时延测试 

　　通信时延包括协议栈时延以及空中传播时延,空中传播时延可以忽略不计,因而协议栈时延即可记为节点通信时延。协议栈时延从执行aplSendMSG()发送消息函数开始到无线目标实际开始物理发射为止。在aplSendMSG()开始发送消息时,记录MAC计时器的值,使用函数aplGetLastTxTime()返回无线发射起始时间,两者之差即为协议栈发射时延。使用aplMacTicksToUs()函数将以tick为单位的时差值转为μs值。实际测量中,协议栈发射延时约为550μs,接收延时约为600μs;

    本文详细介绍了Zigbee网络节点的软硬件设计,提出了针对CC2430的射频设计要点。节点硬件设计上采用微型化结构,节点应用程序设计上采用了高效的程序设计方式——有限状态机(FSM)机制,提高了程序的运行效率。从测试结果可以看出,节点具有较高的接收灵敏度、较远的通信距离以及非常短的通信延迟,完全可以应用于一般的工业控制、楼宇控制、家庭自动化等实时性要求比较高的场合。 

参考文献 

[1] CHIPCON. CC2430 PRELIMINARY data sheet(rev.1.03) SWRS036A[M]:CHIPCON,2005. 

[2] ANDERSEN A. Implementation of microstrip balun for CC2420 and CC243x[R]. 2006. 

[3] REESE R. A ZigbeeTM-subset/IEEE 802.15.4TM multiplatform Protocol Stack. In:Electrical/Computer Engr MSU,editor.2006. 

[4] GRIESKAMP W, GUREVICH Y, SCHULTE W,et al.Generating finite state machines from abstract state machines[J]. Software Engineering Notes. 2002, 27(4):112-122. 

[5] HABIBI A, MOINUDEEN H, TAHAR S. Generating finite state machines from systemC[J]. International Workshop on Abstract State Machines.2005.