当前位置:首页 >> 工学 >>

ZIGBEE开发

第 2 周工作总结
1. SmartRF 测试
对于上周遗留的问题,即在 SmartRF 中看到的帧控制域为 2 个字节,而在 ZIGBEE-2007 规范中,帧控制域为 1 个字节,本周首先解决了这个问题。 首先查看了 CC2530 用户指南 《CC253x SoC Solution User's Guide》 查看第 19 , 章 Radio, 其中关于帧格式问题, 其描述为: IEEE 802.15.4-2006 Frame Format。 原来,CC2530 使用的是 2006 规范,而我们之前所查阅的是 2007 规范。 在 IEEE 802.15.4-2006 规范中,帧控制域的定义如下:

图 1 IEEE 802.15.4-2006 帧控制域格式

对于前两个字节帧类型的定义如下:

图 2 帧控制域帧类型子域

为进一步了解通讯过程中,帧的类型及意义,我们使用 SmartRF 进行通讯 实验,并对实验结果与 2006 帧格式比对。 ①. 开发板 2 自动运行,处于发送状态;开发板 1 与 PC1 相连,运行 SmartRF, 处于普通模式,接收状态。 监测开发板 1 接收到的 MAC 帧如下:

图 3 开发板 1 接收到的 MAC 帧

将帧控制域分解:0x0803=0b 0000 1000 0000 0011 则帧类型为:Beacon。 ②. 开发板 2 与 PC2 相连,运行 SmartRF,处于专家模式,发送状态;开发板 1 与 PC1 相连,运行 SmartRF,处于普通模式,接收状态,运行设备。 在 PC2 的 SmartRF 中,选择 Text 模态,随机输入一串字符,运行设备。 监测开发板 1 接收到的 MAC 帧如下:

图 4 开发板 1 接收到的 MAC 帧

将帧控制域分解:0x8841=0b 1000 1000 0100 0001 则帧类型为:Data。 ③. 开发板 2 与 PC2 相连,运行 SmartRF,处于专家模式,发送状态;开发板 1 与 PC1 相连,运行 SmartRF,处于普通模式,接收状态,运行设备。 在 PC2 的 SmartRF 中,选择随机模态,运行设备。

图 4 开发板 1 接收到的 MAC 帧

将帧控制域分解:0XDB1C=0b 1101 1011 0001 1100 则帧类型为:MAC command。 ④. 开发板 2 与 PC2 相连,运行 SmartRF,处于专家模式,发送状态;开发板 1 与 PC1 相连,运行 SmartRF,处于普通模式,接收状态,运行设备。 在 PC2 的 SmartRF 中,选择 Hex 模态,随机输入一串 Hex 字符,运行设备。

图 4 开发板 1 接收到的 MAC 帧

将帧控制域分解:0XDB1C=0b 0010 0010 0010 0010 则帧类型为:保留。 然而,观察,接收到的 MAC 帧,发现从帧控制域开始,其后字符都与发送 的字符一模一样。也即,我们所看到的帧的类型与实际的帧类型完全无关,而只 取决于用户在发送机端输入了什么。 随后多次试验,总结结果如下: 如果发送机处于 Radom 模态,则直接将 Radom 中的内容(Radom 中的内容 为随机 Hex 数字)填充到从帧控制域起始以后的区域。 如果发送机处于 Text 模态, 则将 Text 中的内容 ASCII 码填充到从帧控制域起 始以后的区域。 如果发送机处于 Hex 模态, 则直接 Hex 字符填充到从帧控制域起始以后的区 域。 也就是说,无论采用发送机采用哪种模态,都是将要发送的内容直接填入从 帧控制域起始以后的区域。只要在 SmartRF 中配置时,使接收机的通道和发送机 相同,就可以接收到发送机发送的数据,完全不与先前下载的程序相关。因此, 使用 SmartRF 不能对下载到芯片中的程序起到调试作用。

因此,原来制定的工作计划需要修改,在串口还没有配置完成的情况下,在 IAR 编译环境中进行调试,观察通讯过程中变量的变化情况来判断通讯状况。

2. 读《基于无线传感器网络的电动汽车电池组综合测试技术研 究》
此文第 3 章详细阐述了形成 ZIGBEE 网络的理论步骤及数据打包发送的具体 实现过程。对于这俩部分的内容已经整理出来并保存,供以后研究参考使用。

(一)

ZIGBEE 网络形成的实现过程:

①. 网络协调器建立网络 ? 应用层使用NLME‐NETWORK‐FORMATION.request 原语并发送给网络层 管理实体,请求初始化设备。 ? 进行能量扫描和信道扫描,选择合理的信道。先后发送ScanType参数为 能量检测扫描和主动扫描的MLME‐SCAN.request原语。 ? 确定个域网络的PANID,保证不与任何其他网络的PANID产生冲突。 ? 确定MAC地址。网络层管理实体将选择0x0000作为16位的短MAC地址, 并且告知MAC层。 ? 配置相关参数。 ②. 终端设备 RFD 加入网络 ? 终端设备进行信道扫描。应用层向网络层发送扫描原语,网络层接收到 该原语后,请求MAC层执行一个主动扫描。 ? MAC层在扫描过程中一旦接收到有效长度不为零的信标帧时,将向其网 络层发送MLME‐BEACON‐NOTIFY.indication原语。该原语中包括的信息为 信标设备地址、是否允许连接和信标载荷。网络层将检查信标载荷中的 协议标识符域的值, 并验证它是否与ZigBee协议识别符匹配。 如果匹配, 设备从接收到的信标中,将相关信息复制到邻居表。网络层再向应用程 发送原语报告扫描得到的网络参数。 ? 终端设备选择合适的网络和父设备,发送请求连接原语。 ? 网络建立成功,将得到一个16位的MAC短地址,并更新邻居表。 ③. 网络协调器接收终端设备加入网络 协调器的网络层管理实体首先要确定设备是否愿意同已经存在的网络连接。 为了达到这一点, 网络层的管理实体将会首先确定在邻居表中是否能够寻找一个 匹配的64位扩展地址,然后检查设备类型是否匹配。如果都匹配,网络层管理实 体将得到一个相应的16位网络地址,并MAC层发出相应。 如果终端设备同意连接请求, 则网络协调器的网络管理实体将使用设备所提 供的信息在它的邻居表中为子设备创建一个新的入口。

(二) 终端设备发送数据包处理过程:
网络终端设备所对应的ZigBee协议栈由应用层,网络层,MAC层和物理层四

部分组成,每一层都有自己的协议数据单元PDU格式,网络终端设备要发送某一 数据帧从应用层开始。 ①. 应用层数据包处理 应用层通过aplFmtSendMSG()函数形成所要发送的数据帧,然后通过调用 void apsTxData(BOOL copy_payload)函数对数据打包,增加APS帧头,形成应用 层协议数据单元APDU,并通过apsTxFSM()函数把它发送到网络层。 ②. 网络层数据包处理 网络层接收到应用层发送过来的APDU数据包后,通过void nwkTxData (BOOLfwdFlag) 函数增加网络层帧报头。 当构造好网络层协议数据单元NPDU后, 通过static void nwkRxFSM(void)函数将数据包发送给MAC层。 ③. MAC层数据包处理 MAC层接收到网络层发送过来的NPDU数据包后,通过static void macTxData (void)函数将数据打包,增加MAC层帧头。当MAC层协议数据单元MPDU数据 包构造成功后,通过static void macTxFSM(void)函数将数据包发送给物理层。 ④. 物理层数据包处理 物理层接收到MAC层发送过来的MPDU数据包后,通过void phyFSM(void) 函数对数据打包处理,增加物理层包头和同步包头形成物理层协议数据单元 PPDU。物理层通过射频硬件,采用16相位的正交调制技术(O‐QPSK)将数据发 送出去。

(三) 协调器接收数据包处理过程:
协调器在初始化设置并成功组建网络后一直处于接收状态。 ①. 当它接收到网络终端节点发送过来的数据帧后,产生射频中断,在中断处理 程序中,它将RFD中的数据读出。(物理层) ②. MAC层通过调用void macRxCallback(BYTE *ptr, BYTE rssi)函数进行相应的 帧校验处理,去除ACK帧,获取MAC层有效载荷。 ③. 网络层将通过void nwkRxHandoff(void)函数获取MAC层帧数据包,数据帧 的目的地址与设备的网络地址相符合的帧将被传送到应用层。 ④. 应用层将通过调用void apsRxHandoff(void)函数获取数据包。应用层接收处 理函数对数据进行处理,我们通过aplGetRxMsgData()语句可以获得网络终 端节点发送的有效载荷的地址,从而接收到了数据。

(四) 总结:
这篇文章对网络形成过程、 终端设备发送数据包的过程和协调器接收数据包 的过程进行了详细的论述。 对我们学习理解ZIGBEE网络理论有很大帮助。应当对 这些理论知识进行记录并保存,供以后查阅。 但是, 文中提到的终端设备发送数据包过程所使用的函数,及协调器接收数 据包过程所使用的函数,在Z-Stack中找不到。在看这篇文章的同时,下载了一 篇内容与其相近的论文 《ZigBee技术无线传感器网络在工业监控系统中的应用研 究》,其中对现有的几种ZigBee协议栈进行了如下阐述: 无线传感器网络的最终性能取决于协议栈的设计和应用程序开发。ZigBee 协议栈是一个相当复杂而庞大的软件组合, 所以目前有能力提供ZigBee协议栈的 公司比较少,主要由飞思卡尔、TI/Chipcon、Microchip和Ember等公司。飞思卡 尔提供的BEE KIT协议栈需要购买才能使用;TI的协议栈是Figure 8 wireless

提供的F8W Z-Stack,目前是免费的,但协议栈复杂而且部分源代码不开放,不 利于对协议栈的学习和应用程序的开发;Microchip提供的协议栈是免费的,但 只支持PIC和MJ2440芯片; Ember公司提供的协议栈需要购买才能使用。这些公司 提供的协议栈虽然功能强大,但是程序复杂,部分公司的源代码没有完全公开, 部分协议栈还需要购买。 之后,作者提到了美国密西西比州立大学Robert Reese副教授设计的 MSSTATE_LRWPAN协议栈。此协议栈由Microchip公司的协议栈改进而产生。其功 能简单,程序代码量少,支持多种平台。目前我们已经找到了这个协议栈的源代 码。但是由于这个协议栈是私人设计,其维护和更新没有保障,最新版本是2007 年的0.2.6,并且只针对CC2430平台。 打开MSSTATE_LRWPAN协议栈, 《基于无线传感器网络的电动汽车电池组综合 测试技术研究》 一文中所提到的函数均能找到。因此可以肯定其所用的协议栈为 MSSTATE_LRWPAN。 但是,由于MSSTATE_LRWPAN只针对CC2430,并且几年没有更新,因此其不能 为我们所用,必须寻找Z-Stack的开发方法。

3. Z-Stack 开发笔记
Z-Stack 项目开发 以 Z-Stack 协议栈为基础进行 ZigBee 项目开发,通常遵循一定的步骤,总结 如下。 (1)参数配置。参数 ZDAPP_CONFIG_PAN_ID 定义了一个缺省的个域网标识符 (PAN ID),将本参数设置为介于 0 到 0X3FFF 之间的一个十六进制数。协调器使用 这个参数作为它的 PAN ID, 路由器和终端设备使用这个标识符加入个域网。 参数 DEFAULT CHANLIST 表示缺省信道值,对 2.4GHZ 频段而言,其值介于 11 到 26 之 间,默认为 11。上面两个参数是新工程中通常需要配置的,没特殊需要,其它 参数一般采用默认值即可。 (2)硬件相关文件修改。一般来说,不同应用中的硬件平台差别是很大的, 根据硬件资源的不同, 需要对硬件相关的文件进行修改。 通常需要修改的部分有: 1)在 ZMain/OnBoard.h 中去掉不用的硬件定义,或者添加自己新的硬件定义。例 如去掉 LCD 相关定义;2)在 HAL/Target/CC2430EB/hal_board_cfg.h 中修改硬件具 体的管脚、参数定义;3)在 HAL/Include 中修改相应的驱动定义。 (3)任务初始化。首先要把需要处理的时间函数定义在事件处理函数数组中, 数组中的每一项都是一个指向函数的指针。如图 5 所示。 然后初始化要处理的事件函数,实际上就是为每个事件分配一个 task id。如 图 6 所示。

图 5 事件处理函数数组

图 6 为事件分配 task id

(4)应用程序编写。对新工程有用的功能需要在应用层中进行添加。通过编 写新任务的初始化函数和事件处理函数完成应用程序的编写。 对于《基于无线网络的电子不停车计费技术的研究》一文作者的设计,其车 载节点的应用程序流程如下:

入口
车载节点

接收 afIncomingMSGPacket_t 读事件ID MSGpkt->?

SYS_EVENT_MSG

ETCAPP_SEND_MSG_EVT

UART接收读 卡器数据

接收数据

新网络加入 ETCApp_SendTheMessage()

数据打包

簇ID判断 数据簇

网络簇

等待激活

计费数据

网络维护CMD

AF发送数据

UART发送

系统维护

返回

图 7 《基于无线网络的电子不停车计费技术的研究》车载应用软件流程图

(5)编译调试。编写完程序,对程序进行编译处理、可在线调试其正确性。 (6)下载。将调试正确满足功能要求的函数,编译后下载到硬件平台 (如 CC2430 芯片)中。 总结:《基于 ZigBee 技术的室内定位系统研究与实现》及《基于无线网络的 电子不停车计费技术的研究》两篇文章,硬件平台都为 CC2430,使用了 Z-Stack 协议栈。两篇文章虽然具体的程序代码不详,但是程序流程图很清晰,有很好的 借鉴作用。

4. 串口配置
前期提到的 ZTOOL 测试工具在实验中不能正常运行,在阅读了几篇论文之 后,明白其原因为 ZTOOL 并不是使用 JTAG 接口与开发板进行通讯,而是使用串 口。 除了官方测试工具使用的串口之外,使用调试助手也必须使用配置串口。 另外,在正式的产品中,S3C2410 与发送器、接收器与上位机之间都是使用 串口进行通讯。 基于以上 3 点, 不管是开发调试阶段还是正式产品阶段,串口都不是不能缺

少的,而我们的开发板上并没有串口,因此,完善开发板配置迫在眉睫。 对于 CC2430,官方文档上并没有指明串口的管脚,操作办法是使用通用 I/O 接口,在程序中配置通用 I/O 接口的某些位为串口。关于串口的设计,我们决定 参考深圳鼎泰克电子有限公司的配置方法。原理图如下图所示。

图 8 串口连接图

在现有的开发板上,不仅要引出 4 个新号引脚,还要引出两个电源引脚给 SP3232 供电。 SP3232 的供电电压为 3-5V 供电, 可以使用开发板电源。 另外, SP3232 的封装形式有双列直插 DIP 形式,可以用于我们快速搭建的串口电路。 搭建串口电路所需要的器材如表 1 所示。 器材 数量 备注 SP3232(DIP-16) 3 2 串口 USB 转接线 3 11 针杜邦头插线 排针(11 管脚,2.54mm) 6 15 0.1uF 瓷片电容 玻纤实验板(10cm*10cm, 2 可焊接串口)

九针接头(母头) 底销 恒温电烙铁 焊台 万用表 镊子 斜口钳 焊锡丝 松香 Wire-Wrapping 线

2 8 1 1 1 1 1 1卷 1盒 1卷