再谈ZigBee中的绑定机制.docx

再谈ZigBee 中的绑定机制

这里主要再讨论一下绑定的机制，绑定是ZigBee中应该是比较重要的一个部分。前面的几篇文章也对绑定有了具体的分析，主要分析了两种绑定方式，介绍了绑定的流程，源代码方面。这里主要是理清整个绑定在组网中的概念。绑定是和EndPoint紧密联系在一起的，其中很多是自己通过看资料，自己的一些理解，当中肯定有不正确的地方，欢迎有兴趣的一起讨论。

ZigBee中还有一个重要的概念端点，理解的不是很清楚，现在再一次总

结分析一下，端点是应用对象存在的地方，ZigBee允许多个应用同时位于一个节点上，例如一个节点具有控制灯光的功能，又具有感应温度的功能，又具有收发文本消息的功能，这种设计有利于复杂ZigBee设备的出现。我们可以从ZigBee的体系结构图中可以看到可以有240个应用，也就是说一个物理的ZigBee设备的话，可以有240个具体的应用，例如上面提到的其中的三种具

体的应用。

一共有二个特殊的端点，即端点0和端点255。端点0用于整个ZigBee设备的配置和管理。应用程序可以透过端点0与ZigBee堆栈的其它层通讯，因而实现对这些层的初始化和配置。附属在端点0的对象被称为ZigBee设备对象(ZDO)。端点255用于向所有端点的广播。端点241到254是保留端点。

所有端点都使用应用支持子层(APS)提供的服务。APS透过网络层和安全服

务提供层与端点相接，并为数据传送、安全和固定服务，因此能够适配不同但兼容的设备，如带灯的开关。下面是终端的描述符的结构体定义。

typedefstruct

{

byteendPoint;//EP号

byte*task_id;//指向任务编号的指针.SimpleDescriptionFormat_t*simpleDesc;//设备的简单描述afNetworkLatencyReq_tlatencyReq; //枚举类型

}endPointDesc_t;

//设备的简单描述结构typedefstruct

{

byte EndPoint; //EPID

uint16AppProfId; //ProfileIDuint16AppDeviceId; //DeviceID

byte AppDevVer:4; //DeviceVersion

byte Reserved:4;//AF_V1_SUPPORTusesforAppFlags:4.

Reserved

byteAppNumInClusters;//输入命令个数cId_t*pAppInClusterList;//输入命令列表byteAppNumOutClusters;//输出命令个数cId_t*pAppOutClusterList;//输出命令列表

}SimpleDescriptionFormat_t;

下面是在SerialApp程序中简单描述符的定义。

constSimpleDescriptionFormat_tSerialApp_SimpleDesc=

{

SERIALAPP_ENDPOINT, // int Endpoint;

SERIALAPP_PROFID, // uint16AppProfId[2];

SERIALAPP_DEVICEID, // uint16AppDeviceId[2];SERIALAPP_DEVICE_VERSION, // int AppDevVer:4;SERIALAPP_FLAGS, // int AppFlags:4;SERIALAPP_MAX_CLUSTERS, // byte AppNumInClusters;(cId_t*)SerialApp_ClusterList, // byte*pAppInClusterList;SERIALAPP_MAX_CLUSTERS, // byte AppNumOutClusters;(cId_t*)SerialApp_ClusterList // byte*pAppOutClusterList;

};

constendPointDesc_tSerialApp_epDesc=

{

SERIALAPP_ENDPOINT,

SerialApp_TaskID,

(SimpleDescriptionFormat_t*)SerialApp_SimpleDesc,noLatencyReqs

};

在TI给的例子中都只是定义了一个端点，猜想是不是每一个应用中都必须有

一个相应的端