zigbee协议栈osal任务分配机制

一、概述

OSAL (Operating System Abstraction Layer),翻译为“操作系统抽象层”。如何理解这个复杂的名词呢?表面上看它是作为操作系统存在的,可是为什么又加上“抽象层”呢?它的本质是什么?在Z-Stack协议栈中,它又扮演了什么角色呢?要解答这些问题,我们必须先从宏观入手,渐渐深入探究,最后答案自然会浮出水面。

下图是ZigBee协议的结构图:

555.jpg

从这幅图中,我们可以很清楚地从宏观上了解ZigBee协议的结构。可是,经过粗略的浏览,我们并没有发现任何OSAL的踪迹。当然,我们都知道,Z-Stack与ZigBee之间并不能完全划等号。Z-Stack是ZigBee的具体实现,所以存在于Z-Stack中的OSAL并不一定出现在ZigBee中。但是,我们可以在ZigBee中找到些许OSAL的踪影。

在ZigBee协议中,协议本身已经定义了大部分内容。在基于ZigBee协议的应用开发中,用户只需要实现应用程序框架即可。从上图可以看出应用程序框架中包含了最多240个应用程序对象。如果我们把一个应用程序对象看做为一个任务的话,那么应用程序框架将包含一个支持多任务的资源分配机制。于是OSAL便有了存在的必要性,它正是Z-Stack为了实现这样一个机制而存在的。

OSAL就是以实现多任务为核心的系统资源管理机制。所以OSAL与标准的操作系统还是有很大的区别的。简单而言,OSAL实现了类似操作系统的某些功能,但并不能称之为真正意义上的操作系统。

二、OSAL任务运行方式

弄明白了OSAL是何方神圣,接下来我们将深入Z-Stack,进一步研究OSAL。

为了方便,我们使用Z-Stack所提供的GenericApp这个例程为例来进行分析。此例程的默认路径为

C:\Texas Instruments\ZStack-1.4.3-1.2.1\Projects\zstack\Samples\GenericApp。

首先我们去繁就简,先来了解应用程序的运行方式。

在右侧工作空间窗口打开App文件夹,我们可以看到三个文件,分别是“GenericApp.c”、“GenericApp.h”、“OSAL_GenericApp.c”。我们整个程序所实现的功能都在这三个文件当中。

首先打开GenericApp.c这个文件。我们首先看到的是比较重要的两个函数:

GenericApp_Init和GenericApp_ProcessEvent。从函数名称上我们很容易得到的信息便是,GenericApp_Init是任务的初始化函数,而GenericApp_ProcessEvent则负责处理传递给此任务的事件。

大概浏览一下GenericApp_ProcessEvent这个函数,我们可以发现,此函数的主要功能是判断由参数传递的事件类型,然后执行相应的事件处理函数。我们可以由此推断Z-Stack应用程序的运行机制如下图所示:

fff.jpg

当有一个事件发生的时候,OSAL负责将此事件分配给能够处理此事件的任务,然后此任务判断事件的类型,调用相应的事件处理程序进行处理。

明白了这个问题,新的问题又摆在了我们的面前:OSAL是如何传递事件给任务的。

三、OSAL的事件传递机制

在试图弄清楚这个问题之前,我们需要弄清楚另外一个十分基础而重要的问题。那就是如何向我们的应用程序中添加一个任务。

我们先来看看GenericApp是如何添加任务的。

我们打开OSAL_GenericApp.c文件。这里我们可以找到一个很重要的数组tasksArr和一个同样很重要的函数osalInitTasks。

TaskArr这个数组里存放了所有任务的事件处理函数的地址,在这里事件处理函数就代表了任务本身,也就是说事件处理函数标识了与其对应的任务。

osalInitTasks是OSAL的任务初始化函数,所有任务的初始化工作都在这里面完成,并且自动给每个任务分配一个ID。

要添加新任务,我们需要编写新任务的事件处理函数和初始化函数,然后将事件处理函数的地址加入此数组。然后在osalInitTasks中调用此任务的初始化函数。在此例中,我们此前提到过的GenericApp_ProcessEvent这个函数被添加到了数组的末尾, GenericApp_Init这个函数在osalInitTasks中被调用。

值得注意的是,TaskArr数组里各任务函数的排列顺序要与osalInitTasks函数中调用各任务初始化函数的顺序必须一致,只有这样才能够保证每个任务能够通过初始化函数接收到正确的任务ID。

另外,为了保存任务初始化函数所接收的任务ID,我们需要给每一个任务定义一个全局变量来保存这个ID。在GenericApp中GenericApp.c中定义了一个全局变量GenericApp_TaskID;并且在GenericApp_Init函数中进行了赋值

{

GenericApp_TaskID = task_id;

}

这条语句将分配给GenericApp的任务ID保存了下来。

到此,我们就给应用程序中完整的添加了一个任务。

我们回到OSAL如何将事件分配给任务这个问题上来

在OSAL_GenericApp.c这个文件中,在定义TaskArr这个数组之后,又定义了两个全局变量。

tasksCnt这个变量保存了当前的任务个数。

tasksEvents是一个指向数组的指针,此数组保存了当前任务的状态。在任务初始化函数中做了如下操作

{

tasksEvents = (uint16 *)osal_mem_alloc( sizeof( uint16 ) * tasksCnt);

osal_memset( tasksEvents, 0, (sizeof( uint16 ) * tasksCnt));

}

我们可以看出所有任务的状态都被初始化为0。代表了当前任务没有需要响应的事件。

紧接着,我们来到了main()函数。此函数在ZMain文件夹的ZMain.c文件中。略过许多对当前来说并非重要的语句,我们先来看osal_init_system()这个函数。在此函数中,osalInitTasks()被调用,从而tasksEvents中的所有内容被初始化为0。

之后,在main()函数中,我们进入了osal_start_system()函数,此函数为一个死循环,在这个循环中,完成了所有的事件分配。

首先我们来看这样一段代码:

{

do

{

if (tasksEvents[idx])

{

break;

}

} while (++idx < tasksCnt);

}

当tasksEvents这个数组中的某个元素不为0,即代表此任务有事件需要相应,事件类型取决于这个元素的值。这个do-while循环会选出当前优先级最高的需要响应的任务,{

events = (tasksArr[idx])( idx, events );

}

此语句调用tasksArr数组里面相应的事件处理函数来响应事件。如果我们新添加的任务有了需要响应的事件,那么此任务的事件处理程序将会被调用。

就这样,OSAL就将需要响应的事件传递给了对应的任务处理函数进行处理。

四、事件的捕获

不过接下来就有了更加深入的问题了,事件是如何被捕获的?直观一些来说就是,tasksEvents这个数组里的元素是什么时候被设定为非零数,来表示有事件需要处理的?为了详细的说明这个过程,我将以GenericApp这个例程中响应按键的过程来进行说明。其他的事件虽然稍有差别,却是大同小异。

按键在我们的应用里面应该属于硬件资源,所以OSAL理应为我们提供使用和管理这些硬件的服务。稍微留意一下我们之前说过的tasksArr这样一个数组,它保存了所有任务的事件处理函数。我们从中发现了一个很重要的信息:Hal_ProcessEvent。HAL(Hardware Abstraction Layer)翻译为“硬件抽象层”。许多人在这里经常把将Z-Stack的硬件抽象层与ZigBee的物理层混为一谈。在这里,我们应该将Z-Stack的硬件抽象层与ZigBee的物理层区分开来。硬件抽象层所包含的范围是我们当前硬件电路上面所有对于系统可用的设备资源。而ZigBee中的物理层则是针对无线通信而言,它所包含的仅限于支持无线通讯的硬件设备。

通过这个重要的信息,我们可以得出这样一个结论:OSAL将硬件的管理也作为一个任务来处理。那么我们很自然的去寻找Hal_ProcessEvent这个事件处理函数,看看它究竟是如何管理硬件资源的。

在“HAL\Commen\ hal_drivers.c”这个文件中,我们找到了这个函数。我们直接分析与按键有关的一部分。

{

if (events & HAL_KEY_EVENT)

{

#if (defined HAL_KEY) && (HAL_KEY == TRUE)

/* Check for keys */

HalKeyPoll();

/* if interrupt disabled, do next polling */

if (!Hal_KeyIntEnable)

{

osal_start_timerEx( Hal_TaskID, HAL_KEY_EVENT, 100);

}

#endif // HAL_KEY

return events ^ HAL_KEY_EVENT;

}

}

在事件处理函数接收到HAL_KEY_EVENT这样一个事件后,首先执行HalKeyPoll()函数。由于这个例程的按键采用查询的方法获取,所以是禁止中断的,于是表达式(!Hal_KeyIntEnable)的值为真。那么osal_start_timerEx( Hal_TaskID, HAL_KEY_EVENT, 100)得以执行。

osal_start_timerEx这是一个很常用的函数,它在这里的功能是经过100毫秒后,向Hal_TaskID 这个ID所标示的任务(也就是其本身)发送一个HAL_KEY_EVENT事件。这样以来,每经过100毫秒,Hal_ProcessEvent这个事件处理函数都会至少执行一次来处理HAL_KEY_EVENT事件。也就是说每隔100毫秒都会执行HalKeyPoll()函数。

那么我们来看看HalKeyPoll函数到底在搞什么鬼!

代码中给的注释为:

/* Check for keys */

HalKeyPoll();

于是我们推断这个函数的作用是检查当前的按键情况。进入函数一看,果不其然。虽然这个函数很长很复杂,不过凭借着非凡的聪明才智,我们还是十分清楚的明白了,经过一系列的if语句和赋值语句,在接近函数末尾的地方, keys变量(在函数起始位置定义的)获得了当前按键的状态。最后,有一个十分重要的函数调用。

(pHalKeyProcessFunction) (keys, HAL_KEY_STATE_NORMAL);

pHalKeyProcessFunction这个函数指针指向了哪个函数我们现在依然不清楚,但是为了我们有个清晰而不间断的思路,我在这里先告诉大家。在这里调用的是

void OnBoard_KeyCallback ( uint8 keys, uint8 state )

这个函数。此函数在“ZMain\OnBoard .c”文件中可以找到。在这个函数中,又调用了void OnBoard_KeyCallback ( uint8 keys, uint8 state )

在这个函数中,按键的状态信息被封装到了一个消息结构体中(对于消息,我们稍后再说)。最后有一个极其重要的函数被调用了。

osal_msg_send( registeredKeysTaskID, (uint8 *)msgPtr );

与前面的pHalKeyProcessFunction相同,我先直接告诉大家registeredKeysTaskID所指示的任务正式我们需要响应按键的GenericApp这个任务。

那么也就是说,在这里我们向GenericApp发送了一个附带按键信息的消息。在

osal_msg_send函数中

osal_set_event( destination_task, SYS_EVENT_MSG );

被调用,它在这里的作用是设置destination_task这个任务的事件为SYS_EVENT_MSG。而这个destination_task正式由osal_msg_send这个函数通过参数传递而来的,它也指示的是GenericApp这个任务。在osal_set_event这个函数中,有这样一个语句:

{

tasksEvents[task_id] |= event_flag;

}

至此,刚才所提到的问题得到了解决。我们再将这个过程整理一遍。

首先,OSAL专门建立了一个任务来对硬件资源进行管理,这个任务的事件处理函数是

Hal_ProcessEvent。在这个函数中通过调用osal_start_timerEx( Hal_TaskID, HAL_KEY_EVENT,

100);这个函数使得每隔100毫秒就会执行一次HalKeyPoll()函数。HalKeyPoll()获取当前按键的状态,并且通过调用OnBoard_KeyCallback函数向GenericApp任务发送一个按键消息,并且设置tasksEvents中GenericApp所对应的值为非零。如此,当main函数里这样一段代码{

do

{

if (tasksEvents[idx])

{

break;

}

} while (++idx < tasksCnt);

}

执行了以后,GenericApp这个任务就会被挑选出来。然后通过

events = (tasksArr[idx])( idx, events );

这个函数调用其事件处理函数,完成事件的响应。

cyril3

2010-8-20 01:13:30

现在,我们回过头来处理我们之前遗留下来的问题。

第一、pHalKeyProcessFunction这个函数指针为何指向了OnBoard_KeyCallback函数。

在HAL\Commen\ hal_drivers.c这个文件中,我们找到了HalDriverInit这个函数,在这个函数中,按键的初始化函数HalKeyInit被调用。在HalKeyInit中有这样的语句:{

pHalKeyProcessFunction = NULL;

}

这说明在初始化以后pHalKeyProcessFunction并没有指向任何一个函数。那pHalKeyProcessFunction是什么时候被赋值的呢?

就在HalKeyInit的下方有一个这样的函数HalKeyConfig。其中有这样一条语句:

pHalKeyProcessFunction = cback;

cback是HalKeyConfig所传进来的参数,所以,想要知道它所指向的函数,必须找到其调用的地方。经过简单的搜索我们不难找出答案。在main函数中有这样一个函数调用:InitBoard( OB_READY );此函数中做了如下调用:

{

HalKeyConfig( OnboardKeyIntEnable, OnBoard_KeyCallback);

}

第二、registeredKeysTaskID为什么标识了GenericApp这个任务?

由于OSAL是一个支持多任务的调度机制,所以在同一时间内将会有多个任务同时运行。但是从逻辑上来讲,一个事件只能由一个任务来处理。按键事件也不例外。

那么如何向OSAL声明处理按键事件的任务是GenericApp呢?

在GenericApp_Init(GenericApp的任务初始化函数)中有这么一个语句:

{

RegisterForKeys( GenericApp_TaskID );

}

RegisterForKeys函数向OSAL声明按键事件将由GenericApp任务来处理。在RegisterForKeys函数中:

{

registeredKeysTaskID = task_id;

}

我想我不用再做多余的解释了,聪明的您肯定可以理解。

五、消息队列

首先我需要想大家解释清楚消息与事件的联系。事件是驱动任务去执行某些操作的条件,当系统产生了一个事件,将这个传递给相应的任务后,任务才能执行一个相应的操作。但是某些事件在它发生的同时,又伴随着一些附加信息的产生。任务的事件处理函数在处理这个事件的时候,还需要参考其附加信息。最典型的一类便是按键消息,它同时产生了一个哪个按键被按下了附加信息。所以在OnBoard_SendKeys这个函数中,不仅向GenericApp发送了事件,还通过调用osal_msg_send函数向GenericApp发送了一个消息,这个消息记录了这个事件的附加信息。在GenericApp_ProcessEvent中,通过

{

MSGpkt = (afIncomingMSGPacket_t *)osal_msg_receive( GenericApp_TaskID );

}

获取了这样一个消息,然后再进一步处理。

OSAL在后台维护了一个消息队列,每一个消息都会被放到这个消息队列中去,当任务接收到事件以后,从消息队列中获取属于自己的消息,然后进行处理。

以上就是我就将OSAL这样一个事件驱动的多任务的资源分配机制做了一个简明扼要的介绍,希望对大家有所帮助。

Zigbee协议栈系统事件

系统常用事件处理函数: -按键事件 -接收消息事件 -网络状态改变事件 -绑定确认事件 -匹配响应事件 1、按键事件 Case KEY_CHANGE: 当有按键事件发生的时,调用按键事件处理函数Sample_HandleKeys()来处理按键事件。 在SampleApp例程中按键处理函数处理了以下2件事情 -如果按键1按下,将向网络中的其他设备发送LED闪烁命令 -如果按键2按下,检测组ID号为SAMPLEAPP_FLASH_GROUP的组是否已经注册。如果已经注册,调用aps_RemoveGroup()将其删除;如果没注册就在APS层注册

2、接收消息事件 Case:AF_INCOMING_MSG_CMD: 如果有接收消息事件发生,则调用函数SampleApp_MessageMSGCB(MSG)对接收的消息进行处理。一般的接收消息事件是通过用户自定义的端点输入簇和输出簇来处理的。 在LED闪烁命令的发送函数中的输出簇为SAMPLEAPP_FLASH_CLUSTERID,所以在接收消息事件的输入簇中为SAMPLEAPP_FLASH_CLUSTERID即收到LED闪烁命令

3、网络状态改变事件 Case:ZDO_STATE_CHANGE 当有网络状态改变事件发生后,会调用函数SampleApp_NwkState()来处理网络状态改变事件。在SampleApp例程中,网络状态改变事件主要处理了以下事件: -判断设备类型(区分协调器、路由节点、终端节点) -当协调器网络建立成功后或其他类型节点加入网络后点亮led1 -通过调用osal_start_timerEx()设置一个定时事件,当时间到达后启用用户自定义事件SampleApp_Send_PERIODIC_MSG_EVT 备注:在使用过程中这里的3种设备类型不是全选,写一个就可以了,其他的删除

ZigBee 协议架构

根据应用和市场需要定义了ZigBee 协议的分层架构,其协议的体系结构如图1 所示,其中物理层(physical layer,PHY)和媒介访问控制层(medium access control sub-layer,MAC)是由IEEE802.15.4-2003 标准定义的,在这个底层协议的基础上ZigBee 联盟定义了网络层(network layer,PHY)和应用层(application layer,APL)架构. 图1 zigbee协议栈体系结构 物理层规范 物理层定义了它与MAC 层之间的两个接口:数据服务接口PD-SAP 和管理服务接口PLME-SAP,其中PD-SAP 接口还为物理层提供了相应的数据服务,负责从无线物理信道上收发数据,而PLME-SAP 接口同时为物理层提供相应的管理服务,用于维护一个由物理层相关数据组成的数据库。物理层负责数据的调制、发送和接收、空闲信道评估(clear channel assessment,CCA)信道能量的监测(energy detect,ED)和链接质量指示(link quality indication,LQI)等。物理层帧结构由同步头、物理层帧头和物理层有效载荷三部分组成,如表1 所示。

同步头又包括32bit 的前同步码和8bit 的帧定界符,前同步码用来为数据收发提供码元或数据符号的同步;帧界定符用来标识同步域的结束及数据的开始。物理层帧头包括7bit 的帧长度和1bit 的预留位,帧长度定义了物理层净荷的字节数。物理层有效载荷就是MAC层的帧内容。 表一物理层帧格式 媒体接入控制层规范 MAC 层定义了它与网络层之间的接口,包括提供给网络层的数据服务接口MLDE-SAP 和管理服务接口MLME-SAP,同时提供了MAC 层数据服务和MAC 层管理服务。MAC层数据服务主要实现数据帧的传输;MAC 层管理服务主要负责媒介访问控制、差错控制等。 MAC 层主要功能包括以下几个方面: (1)ZigBee 协调器产生网络信标 (2)设备与信标同步 (3)支持节点加入或着退出操作 (4)信道接入方式采用免冲突载波检测多路访问(CSMA-CA)机制 (5)建立并维护保护时隙机制 (6)为设备提供安全支持 MAC 帧格式由三个基本部分组成:MAC 帧头、MAC 帧载荷和MAC 帧尾。不同类型的MAC 帧,其帧头和帧尾都是一样的,只是MAC 帧载荷有差别,通用MAC 帧格式如表2所示。 表二通用MAC帧格式 网络层规范 网络层定义了它与应用层之间的接口,包括提供给应用层的数据服务接口NLDE-SAP和管理服务接口NLME-SAP , 同时提供了网络层数据服务和网络层管理服务。网络层主要负责拓扑结构的建立和网络的维护,具体的功能如下:(1)初始化网络,即建立一个新的包含协调器、路由器和终端设备的网络(2)设备连接和断开时所采用的机制 (3)对一跳邻居节点的发现和相关节点信息的存储 (4)ZigBee 协调器和路由器为新加入节点分配短地址

Zigbee协议栈原理基础

1Zigbee协议栈相关概念 1.1近距离通信技术比较: 近距离无线通信技术有wifi、蓝牙、红外、zigbee,在无线传感网络中需求的网络通信恰是近距离需求的,故,四者均可用做无线传感网络的通信技术。而,其中(1)红外(infrared):能够包含的信息过少;频率低波衍射性不好只能视距通信;要求位置固定;点对点传输无法组网。(2)蓝牙(bluetooth):可移动,手机支持;通信距离10m;芯片价格贵;高功耗(3)wifi:高带宽;覆盖半径100m;高功耗;不能自组网;(4)zigbee:价格便宜;低功耗;自组网规模大。?????WSN中zigbee通信技术是最佳方案,但它连接公网需要有专门的网关转换→进一步学习stm32。 1.2协议栈 协议栈是网络中各层协议的总和,其形象的反映了一个网络中文件传输的过程:由上层协议到底层协议,再由底层协议到上层协议。 1.2.1Zigbee协议规范与zigbee协议栈 Zigbee各层协议中物理层(phy)、介质控制层(mac)规范由IEEE802.15.4规定,网络层(NWK)、应用层(apl)规范由zigbee联盟推出。Zigbee联盟推出的整套zigbee规范:2005年第一版ZigBeeSpecificationV1.0,zigbee2006,zigbee2007、zigbeepro zigbee协议栈:很多公司都有自主研发的协议栈,如TI公司的:RemoTI,Z-Stack,SimpliciTI、freakz、msstatePAN 等。 1.2.2z-stack协议栈与zigbee协议栈 z-stack协议栈与zigbee协议栈的关系:z-stack是zigbee协议栈的一种具体实现,或者说是TI公司读懂了zigbee 协议栈,自己用C语言编写了一个软件—---z-stack,是由全球几千名工程师共同开发的。ZStack-CC2530-2.3.1-1.4.0软件可与TI的SmartRF05平台协同工作,该平台包括MSP430超低功耗微控制器(MCU)、CC2520RF收发器以及CC2591距离扩展器,通信连接距离可达数公里。 Z-Stack中的很多关键的代码是以库文件的形式给出来,也就是我们只能用它们,而看不到它们的具体的实现。其中核心部分的代码都是编译好的,以库文件的形式给出的,比如安全模块,路由模块,和Mesh自组网模块。与z-stack 相比msstatePAN、freakz协议栈都是全部真正的开源的,它们的所有源代码我们都可以看到。但是由于它们没有大的商业公司的支持,开发升级方面,性能方面和z-stack相比差距很大,并没有实现商业应用,只是作为学术研究而已。 还可以配备TI的一个标准兼容或专有的网络协议栈(RemoTI,Z-Stack,或SimpliciTI)来简化开发,当网络节点要求不多在30个以内,通信距离500m-1000m时用simpliciti。 1.2.3IEEE802.15.4标准概述 IEEE802.15.4是一个低速率无线个人局域网(LowRateWirelessPersonalAreaNetworks,LR-WPAN)标准。定义了物理层(PHY)和介质访问控制层(MAC)。 LR-WPAN网络具有如下特点: ◆实现250kb/s,40kb/s,20kb/s三种传输速率。 ◆支持星型或者点对点两种网络拓扑结构。 ◆具有16位短地址或者64位扩展地址。 ◆支持冲突避免载波多路侦听技术(carriersensemultipleaccesswithcollisionavoidance,CSMA/CA)。(mac层) ◆用于可靠传输的全应答协议。(RTS-CTS) ◆低功耗。 ◆能量检测(EnergyDetection,ED)。 ◆链路质量指示(LinkQualityIndication,LQI)。 ◆在2.45GHz频带内定义了16个通道;在915MHz频带内定义了10个通道;在868MHz频带内定义了1个通道。 为了使供应商能够提供最低可能功耗的设备,IEEE(InstituteofElectricalandElectronicsEngineers,电气及电子工程师学会)定义了两种不同类型的设备:一种是完整功能设备(full.functionaldevice,FFD),另一种是简化功能设备

2020年Zigbee协议栈中文说明免费

1.概述 1.1解析ZigBee堆栈架构 ZigBee堆栈是在IEEE 802.15.4标准基础上建立的,定义了协议的MAC和PHY层。ZigBee设备应该包括IEEE802.15.4(该标准定义了RF射频以及与相邻设备之间的通信)的PHY和MAC层,以及ZigBee堆栈层:网络层(NWK)、应用层和安全服务提供层。图1-1给出了这些组件的概况。 1.1.1ZigBee堆栈层 每个ZigBee设备都与一个特定模板有关,可能是公共模板或私有模板。这些模板定义了设备的应用环境、设备类型以及用于设备间通信的簇。公共模板可以确保不同供应商的设备在相同应用领域中的互操作性。 设备是由模板定义的,并以应用对象(Application Objects)的形式实现(见图1-1)。每个应用对象通过一个端点连接到ZigBee堆栈的余下部分,它们都是器件中可寻址的组件。 图1-1 zigbe堆栈框架 从应用角度看,通信的本质就是端点到端点的连接(例如,一个带开关组件的设备与带一个或多个灯组件的远端设备进行通信,目的是将这些灯点亮)。 端点之间的通信是通过称之为簇的数据结构实现的。这些簇是应用对象之间共享信息所需的全部属性的容器,在特殊应用中使用的簇在模板中有定义。图1-1-2就是设备及其接口的一个例子:

图1-1-2 每个接口都能接收(用于输入)或发送(用于输出)簇格式的数据。一共有二个特殊的端点,即端点0和端点255。端点0用于整个ZigBee设备的配置和管理。应用程序可以通过端点0与ZigBee 堆栈的其它层通信,从而实现对这些层的初始化和配置。附属在端点0的对象被称为ZigBee设备对象 (ZD0)。端点255用于向所有端点的广播。端点241到254是保留端点。 所有端点都使用应用支持子层(APS)提供的服务。APS通过网络层和安全服务提供层与端点相接,并为数据传送、安全和绑定提供服务,因此能够适配不同但兼容的设备,比如带灯的开关。APS使用网络层(NWK)提供的服务。NWK负责设备到设备的通信,并负责网络中设备初始化所包含的活动、消息路由和网络发现。应用层可以通过ZigBee设备对象(ZD0)对网络层参数进行配置和访问。 1.1.2 80 2.15.4 MAC层 IEEE 802.15.4标准为低速率无线个人域网(LR-WPAN)定义了OSI模型开始的两层。PHY层定义了无线射频应该具备的特征,它支持二种不同的射频信号,分别位于2450MHz波段和868/915MHz 波段。2450MHz波段射频可以提供250kbps的数据速率和16个不同的信道。868 /915MHz波段中,868MHz支持1个数据速率为20kbps的信道,915MHz支持10个数据速率为40kbps的信道。MAC层负责相邻设备间的单跳数据通信。它负责建立与网络的同步,支持关联和去关联以及MAC 层安全:它能提供二个设备之间的可靠链接。 1.1.3 关于服务接入点 ZigBee堆栈的不同层与802.15.4 MAC通过服务接入点(SAP)进行通信。SAP是某一特定层提供的服务与上层之间的接口。 ZigBee堆栈的大多数层有两个接口:数据实体接口和管理实体接口。数据实体接口的目标是向上层提供所需的常规数据服务。管理实体接口的目标是向上层提供访问内部层参数、配置和管理数据的机制。 1.1.4 ZigBee的安全性 安全机制由安全服务提供层提供。然而值得注意的是,系统的整体安全性是在模板级定义的,这意味着模板应该定义某一特定网络中应该实现何种类型的安全。 每一层(MAC、网络或应用层)都能被保护,为了降低存储要求,它们可以分享安全钥匙。SSP是通过ZD0进行初始化和配置的,要求实现高级加密标准(AES)。ZigBee规范定义了信任中心的用

从Zigbee协议栈底层添加自己的按键配置

本实验是基于ZStack-CC2530-2.5.1a版本的协议栈来进行实验的,整个实验需要改动 hal_board_cfg.h、hal_board_cfg.h、hal_key.c、hal_key.h和自己定义的Coordinator.c这5个文件。 注意:添加自己的按键时尽量不要修改协议栈里面的按键程序,自己另行添加即可。 1、hal_key.h 在/* Switches (keys) */下面添加自己的按键定义 #define HAL_KEY_SW_8 0x80 图1: ---------------------------------------------------------------------------------------- 2、hal_board_cfg.h 在/* S6 */ #define PUSH1_BV BV(1) #define PUSH1_SBIT P0_1 #if defined (HAL_BOARD_CC2530EB_REV17) #define PUSH1_POLARITY ACTIVE_LOW #elif defined (HAL_BOARD_CC2530EB_REV13) #define PUSH1_POLARITY ACTIVE_LOW #else #error Unknown Board Indentifier #endif 下面模仿/* S6 */下的程序定义自己的按键值: /* S8 */ #define PUSH8_BV BV(4)//修改 #define PUSH8_SBIT P0_4//修改 #if defined (HAL_BOARD_CC2530EB_REV17)

zigbee协议栈代码主要名词解释

zigbee协议重要名词解释及英文缩写(转载)网络层功能: 1. 加入和退出网络 2. 申请安全结构 3. 路由管理 4. 在设备之间发现和维护路由 5. 发现邻设备 6. 储存邻设备信息 当适当的重新分配地址联合其他设备,ZIGBEE2006可以依赖于网络协调者建立一个新网络. ZIGBEE应用层由APS(应用支持)、AF(应用结构)、ZDO(ZIGBEE设备对象)和厂商自定义应用对象组成。 APS功能 1. 绑定维持工作台,定义一个两个合拢的设备进行比较建立他们的需要和服务。 2. 促进信息在设备之间的限制 3. 组地址定义,移除和过滤组地址消息 4. 地址映射来自于64位IEEE地址和16位网络地址 5. 分裂、重新组装和可靠数据传输 ZDO功能 1. 定义设备内部网络(ZigBee协调者和终端接点) 2. 开始和/或回答绑定请求 3. 在网络设备中建立一个网络安全关系 4. 在网络中发现设备和决定供给哪个应用服务 ZDO同样有责任在网络中发现设备和为他们提供应用服务。 1.1.4 网络拓扑 ZIGBEE网络层支持星状、树状和网状拓扑。在星状拓扑中网络受约束与单个设备,呼叫COORD。COORD有责任建立和维持在网络中发现的设备和其他所有设备,都知道的终端接点直接和COORD 通信。在网状和树状拓扑中,COORD有责任建立一个网络和选择几个关键网络参数,但是网络有有可能直接应用于ZigBee路由器。在树状网络中,利用分等级路由策略完成路由传输数据和控制消息直通网络。树状网络在802.15.4-2003中可以采用信标引导通信。网状网络将允许所有对等网络通信。ZIGBEE 路又将不能在网状网络中发射规则的IEEE802.15.4-2003信标。

一文读懂zigbee技术的协议原理

一文读懂zigbee技术的协议原理 一.前言 从今天开始,我们要正式开始进行zigbee相关的通信实验了,我所使用的协议栈是ZStack 是TI ZStack-CC2530-2.3.0-1.4.0版本,大家也可以从TI的官网上直接下载TI公司为cc2530写的协议栈代码,毕竟,我们作为初学者,应该先不要去深究协议栈是怎么用代码编写的,毕竟zigbee已经相当成熟了,我们应该先学会使用zigbee协议栈进行通信,并能应用于实际项目中,比如说智能家具,不知道大家是不是有同感,所以下面我就先给大家介绍一下zigbee通信的原理以及体系架构。 二.ZStack 体系架构 ZStack 的体系结构由称为层的各模块组成。每一层为其上层提供特定的服务:即由数据服务实体提供数据传输服务;管理实体提供所有的其他管理服务。每个服务实体通过相应的服务接入点(SAP) 为其上层提供一个接口,每个服务接入点通过服务原语来完成所对应的功能。 ZStack 根据IEEE 802.15.4 和ZigBee 标准分为物理层,介质接入控制层,网络层,应用层。物理层提供了基础的服务,数据传输和接收,网络层提供了各个节点连入的服务,是zigbee网络通信的关键,应用层是我们关注的重点,提供了应用的框架和ZDO。大家如果想了解体系结构的具体内容,可以自己去看说明文档,下面我给大家介绍一下zigbee 工作原理。 ZStack 采用操作系统的思想来构建,采用事件轮循机制,而且有一个专门的Timer2 来负责定时。从CC2530 工作开始,Timer2 周而复始地计时,有采集、发送、接收、显示…等任务要执行时就执行。当各层初始化之后,系统进入低功耗模式,当事件发生时,唤醒系统,开始进入中断处理事件,结束后继续进入低功耗模式。如果同时有几个事件发生,判断优先级,逐次处理事件。这种软件构架可以极大地降级系统的功耗。 整个ZStack 的主要工作流程,如图所示,大致分为以下6 步:(1) 关闭所有中断;(2) 芯

TI_zigbee协议栈结构分析应用

无线盛世《快速进入ZB世界》
Ver:1

进入Zigbee世界的准备工作
§ 首先,我们需具备一些硬件设备及平台。以下 我就罗列一下Zigbee开发基本工具: § 计算机:不管是设计电路还是编程开发都是离 不开它的。 § Zigbee开发板:对于初学者来说,Zigbee开发 板无疑是最佳选择。有了开发板,你可以在我 们成熟设计的基础上学习或者做自己的设计。 § Zigbee模块:集MCU,RF,天线设计于一体 的Zigbee模块。使用它,我们可省去设计天线 及IC周边电路设计的复杂工作。

进入Zigbee世界的准备工作
§ Zigbee仿真器:是集烧写程序、在线编程和在线仿真 功能于一身的开发过程工作中必不可少的开发工具。 编程器既能对CC243x芯片(其实包括TI产品中的CC 系列的大部分芯片)进行烧写程序(hex标准文件程序 ),也能对CC243x芯片进行在线编程和仿真,让我们 能方便地在线调试开发,从而大大地提高了开发效率 。 § Zigbee协议分析仪:ZigBee的设计开发者必不可少的 工具!ZigBee协议分析仪具有广泛的功能,包括:分 析以及解码在PHY、MAC、NETWORK/SECURITY、 APPLICATION FRAMEWORK、和APPLICATION PROFICES等各层协议上的信息包;显示出错的包以 及接入错误;指示触发包;在接收和登记过程中可连 续显示包。

进入Zigbee世界的准备工作
§ 再次,我们需要在将用于开发Zigbee的计 算机平台上安装这些软件: § Zigbee协议分析软件(sniffer) § 程序烧写软件(Flash Programmer) § IAR公司的EW8051 version 7.20I/W32 。

ZigBee协议架构

编号:_______________本资料为word版本,可以直接编辑和打印,感谢您的下载 ZigBee协议架构 甲方:___________________ 乙方:___________________ 日期:___________________

(application layer,APL )架构. 图1 zigbee协议栈体系结构 物理层规范 物理层定义了它与MAC层之间的两个接口:数据服务接口PD-SAP和管理服务接口PLME-SAP其中PD-SAP接口还为物理层提供了相应的数据服务,负责从无线物理信道上收发数据,而PLME-SAPg口同时为物理层提供相应的管理服务,用丁维护一个由物理层相关数据组成的数据库。物理层负责数据的调制、发送和接收、空闲信道评估(clear channel assessment,CCA)信道能量的监测(energy detect,ED )和链接质量指示(link quality indication , LQI)等。物理层帧结构由同步头、物理层帧头和物理层*效载荷三部分组成,如表1所示。 同步头乂包括32bit的前同步码和8bit的帧定界符,前同步码用来为数据收发提供码元或数据符号的同步;帧界定符用来标识同步域的结束及数据的开始。物理层帧头包括7bit的帧长度和1bit的预留位,帧长度定义了物理层净荷的字节数。物理层有效载荷就是MAC层的帧内容。 表一物理层帧格式

媒体接入控制层规范 MAC层定义了它与网络层之间的接口,包括提供给网络层的数据服务接口MLDE-SAFffi管理服务接口MLME-SAP同时提供了MAC层数据服务和MAC层管理服务。MA@数据服务主要实现数据帧的传输;MAC层管理服务主要负责媒介访问控制、差错控制等。 MAC层主要功能包括以下几个方面: (1) ZigBee协调器产生网络信标 (2) 设备与信标同步 (3) 支持节点加入或着退出操作 (4) 信道接入方式采用免冲突载波检测多路访问(CSMA-CA机制 (5) 建立并维护保护时隙机制 (6) 为设备提供安全支持 MAC帧格式由三个基本部分组成:MAC帧头、MAC帧载荷和MAC帧尾。不同类型的MAC帧,其帧头和帧尾都是一样的,只是MAC帧载荷有差别,通用MAC帧格式如表2所小。 表二通用MA#格式 网络层规范 网络层定义了它与应用层之间的接口 ,包括提供给应用层的数据服务接口 NLDE-SAP管理服务接口NLME-SAP,同时提供了网络层数据服务和网络层管理 服务。网络层主要负责拓扑结构的建立和网络的维护,具体的功能如下: (1) 初始化网络,即建立一个新的包含协调器、路由器和终端设备的网络 (2) 设备连接和断开时所采用的机制 (3) 对一跳邻居节点的发现和相关节点信息的存储 (4) ZigBee协调器和路由器为新加入节点分配短地址 (5)确保MAC正常工作,并且为应用层提供合适的服务接口 网络层帧结构包括网络层帧头(Network header, NHR和网络层载荷(Network payload,NPL)两部分,其中网络层帧头域由帧控制域、目的设备地址、源设备地址、广播半径和广播序列号等部分组成,通用网络帧的结构如表3所示。 表3通用网络层帧结构

ZigBee协议栈任务处理分析笔记

ZigBee协议栈任务处理分析笔记 ----(转载请注明出处774910349@https://www.360docs.net/doc/9711502288.html,)Everhuai写于2011-11-17 弄了这么久ZigBee协议栈,今天终于有一点头绪了,基本上知道了整个系统任务怎么被添加,又是怎么被切换的一个过程。下面就简单讲一讲这部分内容。 首先看的当然是main()函数,不过这个函数不是今天的重点,里面有我添加的注释,先就一笔带过吧。 int main( void ) { // Turn off interrupts osal_int_disable( INTS_ALL );//关闭全局中断EA=0,初始化过程不响应任何中断 // Initialization for board related stuff such as LEDs HAL_BOARD_INIT();//配置了时钟、LED、串口 // Make sure supply voltage is high enough to run zmain_vdd_check();//检查电源电压 // Initialize stack memory zmain_ram_init();//初始化堆内存 // Initialize board I/O /初始化板子用到的IO口 InitBoard( OB_COLD ); // Initialze HAL drivers HalDriverInit();//初始化外设 // Initialize NV System //系统初始化 osal_nv_init( NULL ); // Initialize basic NV items//任务初始化 zgInit(); // Initialize the MAC ZMacInit(); // Determine the extended address //确定长地址 zmain_ext_addr(); #ifndef NONWK // Since the AF isn't a task, call it's initialization routine afInit(); #endif // Initialize the operating system osal_init_system(); //系统初始化

zigbee协议栈源码

竭诚为您提供优质文档/双击可除 zigbee协议栈源码 篇一:zigbeez-stack协议栈构架 zstack基础 1、zstack协议栈构架 zigbee协议栈就是将各个层定义的协议都集合在一起,以函数的形式实现,并给用户提供一些应用层api,供用户调用。协议栈体系分层架构与协议栈代码文件夹对应表如下:整个协议栈的构架,如图所示 app:应用层目录,这是用户创建各种不同工程的区域,在这个目录中包含了应用层的内容和这个项目的主要内容,在协议栈里面一般是以操作系统的任务实现的。 hal:硬件层目录,包含有与硬件相关的配置和驱动及操作函数。 mac:mac层目录,包含了mac层的参数配置文件及其mac的lib库的函数接口文件。 mt:监控调试层,主要用于调试目的,即实现通过串口调试各层,与各层进行直接交互。nwk:网络层目录,含网络层配置参数文件及网络层库的函数接口文件,aps层库的

函数接口。 osal:协议栈的操作系统。 profile:aF层目录,包含aF层处理函数文件。 security:安全层目录,安全层处理函数接口文件,比如加密函数等。 services:地址处理函数目录,包括着地址模式的定义及地址处理函数。 tools:工程配置目录,包括空间划分及zstack相关配置信息。 zdo:zdo目录。 zmac:mac层目录,包括mac层参数配置及mac层lib 库函数回调处理函数。zmain:主函数目录,包括入口函数main()及硬件配置文件。 output:输出文件目录,这个ew8051ide自动生成的。 2、zigbee20xx协议栈源码库结构分析 了解了zigbee20xx协议栈整个构架后,再来看看协议栈源码库结构是什么样的,各层的具体文件是什么,建立不同的项目、添加自己的应用层任务及处理函数需要修改什么文件。zigbee20xx协议栈zstack-1.4.2文件目录及说明如下: 打开smapleapp项目工程 先看app层:

Zigbee协议栈学习总结教学提纲

典型的智能家居网络总体结构图 智能家居系统模块整体框图

ZigBee是一种标准,该标准定义了短距离、低速率传输速率无线通讯所需要的一系列通信协议。基于ZigBee的无线网络所使用的工作频段为868MHz、915MHz和2.4GHz,最大数据传输速率为250Kbps。 ZigBee无线网络共分为5层:物理层(PHY),介质访问控制层(MAC),网络层(NWK),应用程序支持子层(APS),应用层(APL)。 总体而言,ZigBee技术有如下特点:高可靠性,低成本,低功耗,高安全性,低数据速率

Zigbee网络中的设备主要分为三种: 1,协调器,协调器节点负责发起并维护一个无线网络,识别网络中的设备加入网络,一个ZigBee 网络只允许有一个ZigBee 协调器; 2,路由器,路由器节点支撑网络链路结构,完成数据包的转发;。ZigBee 网格或树 型网络可以有多个ZigBee 路由器。ZigBee 星型网络不支持ZigBee 路由器。 3,终端节点,负责数据采集和可执行的网络动作。 从功能上,zigbee节点应由微控制器模块、存储器、无线收发模块、电源模块和其它外设功能模块组成。 ZigBee/IEEE802.15.4定义了两种类型的设备:它们是全功能设备(FFD,Full Function Device)和精减功能设备(RFD,Reduced Function Device)。FFD可以当作一个网络协调器或者一个普通的传感器节点,它可以和任何其他的设备通讯,传递由RFD发来的数据到其他设备,即充当了路由的功能。而RFD只能是传感器节点,它只能和FFD进行通讯,经过FFD可以将自己测得数据传送出去。在ZigBee网络中大多是这两种设备,网络中结点数理论上最多可达65,536个,可以组成三种类型网络:星型、网状型和树型。 星状网络由一个PAN 协调器和多个终端设备组成,只存在PAN 协调器与终端的通讯,终端设备间的通讯都需通过PAN 协调器的转发。 树状网络由一个协调器和一个或多个星状结构连接而成,设备除了能与自己的父节点或子节点进行点对点直接通讯外,其他只能通过树状路由完成消息传输。 网状网络是树状网络基础上实现的,与树状网络不同的是,它允许网络中所有具有路由功能的节点直接互连,由路由器中的路由表实现消息的网状路由。 星型,如果用星型网络的话,在房间内的节点是否能够穿墙,与房间外的协调器进行正常通信。

zigbee协议名词解释

zigbee协议重要名词解释及英文缩写(转载) 网络层功能: 1.加入和退出网络 2.申请安全结构 3.路由管理 4.在设备之间发现和维护路由 5.发现邻设备 6.储存邻设备信息 当适当的重新分配地址联合其他设备,ZIGBEE2006可以依赖于网络协调者建立一个新网络. ZIGBEE应用层由APS(应用支持)、AF(应用结构)、ZDO(ZIGBEE设备对象)和厂商自定义应用对象组成。 APS功能 1.绑定维持工作台,定义一个两个合拢的设备进行比较建立他们的需要和服务。 2.促进信息在设备之间的限制 3.组地址定义,移除和过滤组地址消息 4.地址映射来自于64位IEEE地址和16位网络地址 5.分裂、重新组装和可靠数据传输 ZDO功能 1.定义设备内部网络(ZigBee协调者和终端接点) 2.开始和/或回答绑定请求 3.在网络设备中建立一个网络安全关系 4.在网络中发现设备和决定供给哪个应用服务 ZDO同样有责任在网络中发现设备和为他们提供应用服务。 1.1.4网络拓扑 ZIGBEE网络层支持星状、树状和网状拓扑。在星状拓扑中网络受约束与单个设备,呼叫COORD。COORD有责任建立和维持在网络中发现的设备和其他所有设备,都知道的终端接点直接和COORD 通信。在网状和树状拓扑中,COORD有责任建立一个网络和选择几个关键网络参数,但是网络有有可能直接应用于ZigBee路由器。在树状网络中,利用分等级路由策略完成路由传输数据和控制消息直通网络。树状网络在802.15.4-2003中可以采用信标引导通信。网状网络将允许所有对等网络通信。ZIGBEE 路又将不能在网状网络中发射规则的IEEE802.15.4-2003信标。

Zigbee协议栈原理基础

Zigbee协议栈原理基础

1Zigbee协议栈相关概念 1.1近距离通信技术比较: 近距离无线通信技术有wifi、蓝牙、红外、zigbee,在无线传感网络中需求的网络通信恰是近距离需求的,故,四者均可用做无线传感网络的通信技术。而,其中(1)红外(infrared):能够包含的信息过少;频率低波衍射性不好只能视距通信;要求位置固定;点对点传输无法组网。(2)蓝牙(bluetooth):可移动,手机支持;通信距离10m;芯片价格贵;高功耗(3)wifi:高带宽;覆盖半径100m;高功耗;不能自组网;(4)zigbee:价格便宜;低功耗;自组网规模大。?????WSN中zigbee通信技术是最佳方案,但它连接公网需要有专门的网关转换→进一步学习stm32。 1.2协议栈 协议栈是网络中各层协议的总和,其形象的反映了一个网络中文件传输的过程:由上层协议到底层协议,再由底层协议到上层协议。 1.2.1Zigbee协议规范与zigbee协议栈 Zigbee各层协议中物理层(phy)、介质控制层(mac)规范由IEEE802.15.4规定,网络层(NWK)、应用层(apl)规范由zigbee联盟推出。Zigbee联盟推出的整套zigbee规范:2005年第一版ZigBeeSpecificationV1.0,zigbee2006,zigbee2007、zigbeepro zigbee协议栈:很多公司都有自主研发的协议栈,如TI公司的:RemoTI,Z-Stack,SimpliciTI、freakz、msstatePAN 等。 1.2.2z-stack协议栈与zigbee协议栈 z-stack协议栈与zigbee协议栈的关系:z-stack是zigbee协议栈的一种具体实现,或者说是TI公司读懂了zigbee 协议栈,自己用C语言编写了一个软件—---z-stack,是由全球几千名工程师共同开发的。ZStack-CC2530-2.3.1-1.4.0软件可与TI的SmartRF05平台协同工作,该平台包括MSP430超低功耗微控制器(MCU)、CC2520RF收发器以及CC2591距离扩展器,通信连接距离可达数公里。 Z-Stack中的很多关键的代码是以库文件的形式给出来,也就是我们只能用它们,而看不到它们的具体的实现。其中核心部分的代码都是编译好的,以库文件的形式给出的,比如安全模块,路由模块,和Mesh自组网模块。与z-stack 相比msstatePAN、freakz协议栈都是全部真正的开源的,它们的所有源代码我们都可以看到。但是由于它们没有大的商业公司的支持,开发升级方面,性能方面和z-stack相比差距很大,并没有实现商业应用,只是作为学术研究而已。 还可以配备TI的一个标准兼容或专有的网络协议栈(RemoTI,Z-Stack,或SimpliciTI)来简化开发,当网络节点要求不多在30个以内,通信距离500m-1000m时用simpliciti。 1.2.3IEEE802.15.4标准概述 IEEE802.15.4是一个低速率无线个人局域网(LowRateWirelessPersonalAreaNetworks,LR-WPAN)标准。定义了物理层(PHY)和介质访问控制层(MAC)。 LR-WPAN网络具有如下特点: ◆实现250kb/s,40kb/s,20kb/s三种传输速率。 ◆支持星型或者点对点两种网络拓扑结构。 ◆具有16位短地址或者64位扩展地址。 ◆支持冲突避免载波多路侦听技术(carriersensemultipleaccesswithcollisionavoidance,CSMA/CA)。(mac层) ◆用于可靠传输的全应答协议。(RTS-CTS) ◆低功耗。 ◆能量检测(EnergyDetection,ED)。 ◆链路质量指示(LinkQualityIndication,LQI)。

ZigBee协议栈原理简介

第1章ZigBee协议栈原理 2007 年4 月,德州仪器推出业界领先的ZigBee 协议栈(Z-Stack)。Z-Stack 符合ZigBee2006 规范,支持多种平台,包括基于CC2420 收发器以及TI MSP430 超低功耗单片机的平台、CC2530 SOC 平台等。Z-Stack 包含了网状网络拓扑的几近于全功能的协议栈,在竞争激烈的ZigBee 领域占有很重要地位。 4.1 Zigbee 设备类型 在 ZigBee 网络中存在三种逻辑设备类型:Coordinator(协调器),Router(路由器)和End-Device(终端设备)。ZigBee 网络由一个Coordinator 以及多个Router 和多个End_Device组成。 下图是一个简单的ZigBee 网络示意图。其中黑色节点为Coordinator,红色节点为Router, 白色节点为End-Device。 1、Coordinator(协调器) 协调器负责启动整个网络。它也是网络的第一个设备。协调器选择一个信道和一个网络ID(也称之为PAN ID,即Personal Area Network ID),随后启动整个网络。协调器也可以用来协助建立网络中安全层和应用层的绑定(bindings)。 注意,协调器的角色主要涉及网络的启动和配置。一旦这些都完成后,协调器的工作就像一个路由器。 2、Router(路由器) 路由器的功能主要是:允许其他设备加入网络,多跳路由和协助它自己的由电池供电的子终端设备的通讯。通常,路由器希望是一直处于活动状态,因此它必须使用主电

源供电。但是当使用树型网络模式时,允许路由间隔一定的周期操作一次,这样就可以使用电池给其供电。 3、End-Device(终端设备) 终端设备没有特定的维持网络结构的责任,它可以睡眠或者唤醒,因此它可以是一个电池供电设备。通常,终端设备对存储空间(特别是RAM)的需要比较小。 注意:在Z-Stack 1.4.1 中一个设备的类型通常在编译的时候通过编译选项 (ZDO_COORDINATOR 和RTR_NWK)确定。所有的应用例子都提供独立的项目文件来 编译每一种设备类型。 栈配置(Stack Profile) 栈参数的集合需要被配置为一定的值,连同这些值在一起被称之为栈配置。ZigBee 联盟定义了这些由栈配置组成的栈参数。网络中的所有设备必须遵循同样的栈配置。为了促进互用性这个目标,ZigBee 联盟为ZigBee2006 规范定义了栈配置。所有遵循此栈配置的设备可以在其它开发商开发的遵循同样栈配置的网络中使用。

zigbee协议栈深入详解

zigbee协议栈 2010-03-10 15:11 zigbee协议栈结构由一些层构成,每个层都有一套特定的服务方法和上一层连接。数据实体(data entity)提供数据的传输服务,而管理实体(managenmententity)提供所有的服务类型。每个层的服务实体通过服务接入点(Service Access Point.SAP)和上一层相接,每个SAP提供大量服务方法来完成相应的操作。 ZigBee协议栈基于标准的OSI七层模型,但只是在相关的范围来定义一些相应层来完成特定的任务。IEEE 802.15.4—2003标准定义了下面的两个层:物理层(PHY层)和媒介层(MAC层)。ZigBee联盟在此基础上建立了网络层(NWK 层)以及应用层(APL层)的框架(framework)。APL层又包括应用支持子层(Application Support Sub—layer,APS)、ZigBee的设备对象(ZigBee Device 0bjects。ZD0)以及制造商定义的应用对象。 1物理层(PHY) IEEE802.15.4协议的物理层是协议的最底层,承担着和外界直接作用的任务。它采用扩频通信的调制方式,控制RF收发器工作,信号传输距离约为 50m(室内)或150m(室外)。 IEEE802.15.4.2003有两个PHY层,提供两个独立的频率段:868/915MHz 和2.4GHz。868/915MHz频段包括欧洲使用的868MHz频段以及美国和澳大利亚使用的915MHz频段,2.4GHz频段世界通用。 2媒体访问控制层(MAC) MAC层遵循IEEE802.15.4协议,负责设备间无线数据链路的建立、维护和结束,确认模式的数据传送和接收,可选时隙,实现低延迟传输,支持各种网络拓扑结构,网络中每个设备为16位地址寻址。它可完成对无线物理信道的接入过程管理,包括以下几方面:网络协调器(coordinator)产生网络信标、网络中设备与网络信标同步、完成PAN的入网和脱离网络过程、网络安全控制、利用CSMA—CA机制进行信道接入控制、处理和维持GTS(Guaranteed Time Slot)机制、在两个对等的MAC实体间提供可靠的链路连接。 数据传输模型: MAC规范定义了三种数据传输模型:数据从设备到网络协调器、从网络协调器到设备、点对点对等传输模型。对于每一种传输模型,又分为信标同步模型和无信标同步模型两种情况。 在数据传输过程中,ZigBee采用了CSMA/CA碰撞避免机制和完全确认的数据传输机制,保证了数据的可靠传输。同时为需要固定带宽的通信业务预留了专用时隙,避免了发送数据时的竞争和冲突。 帧结构定义: MAC规范定义了四种帧结构:信标帧、数据帧、确认帧和MAC命令帧。

ZigBee协议栈初始化网络启动流程

ZigBee协议栈初始化网络启动流程 ZigBee的基本流程:由协调器的组网(创建PAN ID),终端设备和路由设备发现网络以及加入网络。 基本流程:main()->osal_init_system()->osalInitTasks()->ZDApp_Init(),进协议栈初始化函数ZDApp_Init()。 1.1 进入程序入口main()。 ZMain.c中 C++ Code int main( void ) { // Turn off interrupts osal_int_disable( INTS_ALL ); // Initialization for board related stuff such as LEDs HAL_BOARD_INIT(); // Make sure supply voltage is high enough to run zmain_vdd_check(); // Initialize board I/O InitBoard( OB_COLD ); // Initialze HAL drivers HalDriverInit(); // Initialize NV System osal_nv_init( NULL ); // Initialize the MAC ZMacInit();

// Determine the extended address zmain_ext_addr(); // Initialize basic NV items zgInit(); #ifndef NONWK // Since the AF isn't a task, call it's initialization routine afInit(); #endif // Initialize the operating system osal_init_system(); // Allow interrupts osal_int_enable( INTS_ALL ); // Final board initialization InitBoard( OB_READY ); // Display information about this device zmain_dev_info(); /* Display the device info on the LCD */ #ifdef LCD_SUPPORTED zmain_lcd_init(); #endif #ifdef WDT_IN_PM1 /* If WDT is used, this is a good place to enable it. */ WatchDogEnable( WDTIMX ); #endif osal_start_system(); // No Return from here

相关文档
最新文档