科技网

当前位置: 首页 >智能

ZigBee空中下载技术研究及其优化设计

智能
来源: 作者: 2018-10-29 10:17:37

ZigBee空中下载技术研究及其优化设计

导读:

介绍了一种基于ZigBee的空中下载技术,非常适用于短距离的无线传感络应用场合。通过无线更新固件,免去了回收更新节点所需时间,可以达到更新完成后不破坏当前络拓扑结构的效果。

摘要:无线传感络是由大量体积小,供电资源有限,并配置一定计算能力和无线通讯能力的传感节点组成。对于传感络系统,一定存在程序代码更新和维护的需求,但由于传感节点分散部署的特点,使得络远程节点的程序升级变得异常困难。为此,空中下载(over the air, OTA)提供了一种有效的更新手段。本文首先介绍基于 ZigBee协议的OTA系统,并在CC2530F256 硬件平台作出验证。最后,在Z-Stack协议栈中,设计出一种镜像页请求的OTA更新方式,并通过实验测试,与原有的镜像块请求方式进行了比较分析。实验结果表明,镜像页请求方式可以大大减少络的更新流量,从而提高节点的更新效率。  0. 引言  近年来,由于硬件成本的下降以及制造工艺的进步,无线传感络技术逐步取得大规模商业应用,如医疗监控,智能电和智能家居[1]。对于任何一个嵌入式计算机系统,都存在程序代码升级的需要。在无线传感络的应用环境中,由于大量节点分散性部署,节点的回收工作变得异常困难,使传统的物理连接的程序更新手段不再适用。对此,一种有效的解决方案是OTA技术。  空中下载技术起源于移动络,能够通过移动通信络(如GSM)对SIM卡数据进行远程管理与更新[2]。借鉴于移动通信络,空中下载技术也能应用于无线传感络。与络层的路由协议[3]不同,代码分发协议[4]是支撑OTA的核心技术。前者关注的是如何迅速高效地中转络中的数据信息,后者关注的是如何向各节点完整无误地传递更新代码[5]。目前,成熟的代码分发协议已经提出,典型的如基于TinyOS系统的Xnp[6]与Deluge[7],前者提出了单跳络的更新方案,后者支持多跳络更新功能,但都需要具体的硬件平台支持。  本文移植并验证了一种基于ZigBee协议[8]的空中下载技术,其分发协议支持点对多传输更新功能,多跳络的代码分发功能由路由协议支撑。在Z-Stack协议栈[9]下,仅仅支持镜像块请求功能,更新效率并不理想。针对此问题,设计出一种高效的镜像页请求功能,能够提高点对多的传输更新效率,并减少络流量。  1. OTA概述  ZigBee协议规范使用了IEEE 802.15.4定义的物理层(PHY)和媒体介质访问层(MAC),并在此基础上定义了络层(NWK)应用层(APL)。针对无线传感络重编程技术的需求,ZigBee联盟在原有协议的框架上,提出了一种OTA规范[10],作为一个系统可选的功能模块。  图1为OTA系统的结构示意图,整个系统主要由3部分构成:OTA应用控制台,OTA服务器,OTA客户端。其中OTA应用控制台是上位机管理软件,负责OTA镜像管理,络节点信息陈列与发送更新命令;OTA服务器负责向远程节点无线发送升级镜像,并通过串口与上位机连接,向应用控制台汇报各节点更新进度信息等;OTA客户端是指远程络中的待升级节点。  根据代码的更新范围,分为整体代码更新与基于差异性的更新[11]。前者是把所有可执行的二进制代码打包成一个镜像分发给节点,后者是通过比较新旧镜像文件之间的差异,产生一个脚本,然后把这个脚本分发到络中的节点进行差异性更新。毫无疑问,前者需要传输的数据量较大,一般为上千字节级,增加了络负担,但代码更新操作相对简单;后者发送的数据量虽少,但增加了更新过程的复杂度,对处理器产生更大的负担,带来较大的能源损耗。由于ZigBee协议对络节点的低功耗标准有严格的要求,其OTA代码分发协议采用前者的镜像传输方式。  服务器与客户端之间的数据交互过程如图2所示。首先OTA服务器通过单播或者广播方式向OTA客户端(节点)发送镜像公告(Image Notify),指示新镜像已经准备好。收到镜像提示信息后,节点就向OTA服务器发送查询下一个镜像请求(Query Next Image Request),此请求信息包含了当前运行固件的版本信息。收到该请求后,OTA服务器作出响应(Query Next Image Response)。随后,OTA客户端与OTA服务器通过二次握制,镜像块请求(Image Block Request)和镜像块响应(Image Block Response),完成整个镜像传输过程。当OTA客户端收到镜像块数据后,把块数据写到第二存储区(客户端当前运行的镜像保存在第一存储区)。完成下载后,节点将对下载后的镜像进行CRC校验。最后,当节点需要更新时,把新镜像从第二存储区复制到第一存储区,新固件开始运行,从而完成了整个升级过程。  2. OTA系统设计  本文的OTA系统基于TI公司的ZigBee SOC芯片CC2530F256[12]设计,包括硬件与软件的设计。其中硬件部分主要涉及CC2530 F256内部Flash存储空间分配方式与镜像存储方式的选择;软件部分介绍了OTA启动代码工作流程。  2. 1硬件系统  CC2530F256内部集成一个增强型8051单片机,拥有8KB SRAM和256KB内部flash存储器。内部flash主要用来保存程序代码和常量数据。由于传统8051 代码存储空间寻址范围只有64KB,CC2530把内部256KB flash分成8个bank,每一个bank大小是32KB,通过寄存器P[2:0]选择不同的bank映射到代码存储空间,解决了寻址空间受限的问题。  对于OTA客户端,启动代码位于bank0的0x0000到0x0800地址区域,大小为2KB。其余的254KB的flash空间,用来存储当前固件和其他信息。值得注意的是,0x0888~0x088B区域存放了CRC校验信息,0x088C~0x0897区域存放了PREAMBLE,即镜像大小,制造商ID,镜像类型和镜像版本号信息。另外,bank7最后的14KB空间(0x7C800~0x7FFFF)用作非易失性(None volatile, NV)变量区(12KB)和特定信息保留区(2KB)。  OTA系统升级方案有两种,分别是片内flash升级和片外flash升级。片内flash的方案是把256KB的flash大小分成两半,前一半(第一存储区)提供给当前运行镜像存储,后一半(第二存储区)提供给新镜像存储;片外flash的方案是把片内flash作为第一存储区,外扩的flash作为第二存储区。考虑到一般程序固件大小都超过128KB,和以后程序功能升级的扩展性,本文采用片外flash的方案。采用的片外flash(M25PE20)容量为256KB,通过SPI总线与CC2530之间传输数据。  2. 2软件系统  对于基于任务事件轮询机制的Z-Stack工程,默认是没有添加OTA功能。如果节点需要开启OTA功能,首先需要烧写OTA的启动代码。当节点完成镜像接收之后,对新镜像进行CRC校验,并清空当前镜像的CRC信息,然后重启。当节点重启后,首先跳转到启动代。  码的地址,开始执行如图3所示的工作流程。由于内部镜像的CRC信息被清空,所以被判断为不正确而执行下一步。由于为0的CRC信息标志着不需要被重新校验,故执行将新镜像复制到片内Flash的操作,并产生新镜像的CRC信息。然后,重新执行启动代码。新镜像启动时读取其CRC信息,再次判断后跳转到应用程序区,完成整个启动过程。

123下一页>

成都会所
电动货车
推拉力计

相关推荐