要试验的：
1串口查看数据
2用自己的温度传感器看
3串口通信，该代码，发送自己想发的数据。如果修改数据长度看路由代码。修改路由代码弄串口这边原理。两头拼。
要解决的问题：
1温度采集代码
2zigbee传输代码
3串口传输数据代码
4endpoint与任务的关系。与按键串口服务关系。
已经解决的问题：
1开发的流程
2如何添加新任务
3osal工作原理，任务调度机制。
难点：
几个关键回调函数的理解
关键点（总体规划）：
1、数据采集，这部分的关键是I-WIRE协议的理解。传感器与51的通信问题。
自己必须先把这部分搞定，现在要解决这个问题，即在TI提供的协议栈的基础上开发自己的应用。要弄懂温度，湿度，PH值传感器的工作原理，一般采用I-WIRE总线的协议。2、将数据传输到协调器（控制节点），这部分关键是zigbee通信协议，要充分利用TI的Z-STACK 协议栈来进行二次开发。主要关注数据的收发模块，数据的格式、特点。
3、数据从协调器传到PC，这部分关键是串口通信协议。正确的将数据传到上位机。
4、PC控制显示界面，这部分关键是找到关键的API，然后取出自己想要的数据显示。如果需要存储数据，要操纵数据库，选择数据库。
解决这几个问题这个项目就算完成了。
现在猜想：
一、开发一个新的应用应该做什么呢？
1获取模板标识符，簇标识符，设备标识符的相关信息，我要进一步了解这两个关键的概念。2在1基础上我要能注册application，taskID,endpoint，以建立自己应用与操作系统交互。这是一个关键的点。
二、必须弄懂传感器采集的原理，代码。
三、必须弄懂串口的原理，代码。
关键的概念
1、PAN标识符，PAN ID
2、模板标识符，profileID
3、簇标识符，clusterID 8bit
4、节点，ieee地址（扩展地址）网络地址（短地址）64bit/16bit
5、端点，endpoint 8bit
6、设备标识符，Device Description 16bit
7、应用任务ID，taskID
8、属性Attribute 16bit
9、Taskevents envents 16bit
申请到模板标识符后，可以为模板定义设备描述符、簇标识符、服务类型（KVP或MSG）属性（Attribute）。
模板三种类型：私有、公开、公用。
属性
属性Attribute是一个反映物理数量或状态的数据值，比如开关值（On/Off） ,温度值、百分比等。
群集
群集Cluster是包含一个或多个属性（attribute）的群组。简单的说，群集就是属性的集合。每个群集都被分配一个唯一的群集ID 且每个群集最多有65536个属性。
描述
设备描述Device Description是指一个大型目标应用的一部分，包括一个或多个群集，并且指定群集是输入还是输出。
端点
端点EndPoint是协议栈应用层的入口，也可以理解应用对象（Application Object）存在的地方，它是为实现一个设备描述而定义的一组群集。每个ZigBee 设备可以最多支持240这样的端点，这也意味着在每个设备上可以定义240个应用对象。端点0被保留用于与ZDO接口而端点255被保留用于广播，端点241-254则被保留用于将来做扩展使用。
节点
节点Node也可以理解为一个容器，包含一组ZigBee设备，分享一个无线信道。每个节点有且只有一个无线信道使用。
信息源：
1飞比论坛的资料：
1）葵花宝典
2）中文资料总索引
3）小峰笔记
4）奥特曼笔记
2 TI官方网站查找板子相关手册。
重要信息：
ZigBee协议的体系结构
Z-Stack在开发ZigBee中起到的作用，使用Z-Stack开发ZigBee我们需要做什么？如刚才的ZigBee协议体系图所示，ZigBee中包括很多的层和各个层之间的数据管理信息传输。如此庞大的体系，如果人为手动编写程序将是一个很浩大的工程。而Z-Stack则在其系统中为我们提供了详细的各个子模块的工作程序。那么我们在开发ZigBee项目的时候，其实我们只需要添加三个文件：主文件，主文件的头文件，操作系统接口文件。
一般情况下，用回只需额外添加三个文件就可以个一个项目FI，一个主文件，存放具体的任务事件处理函数（osal开头文件中的SampleApp_processEvent），一个主文件的头文件，一个操作系统接口文件，是专门存放任务处理函数数组（tasksArr[idx]）的文件。
ZDO位于应用框架和应用支持子层之间，它满足zigBee协议栈所有应用操作的一般要求。
AF
ZigBee应用层框架是应用设备和ZigBee设备连接的环境。在应用层框架中，应用对象
发送和接收数据通过APSDE．SAP，而对应用对象的控制和管理则通过ZDO公用接口来实现。APSDE．SAP提供的数据服务包括请求、确认、响应以及数据传输的指示信息。
有240个不同的应用对象能够被定义，每个终端节点的接口标识从l到240，还有两个附加的终端节点为了APSDE．SAP的使用。标识0被用于ZDO的数据接口，255则用于所有应用对象的广播数据接口，而241．254予以保留。使用APSDE-SAP提供的服务，应用层框架提供了应用对象的两种数据服务类型：主值对服务(Key Value Pair service，KVP)和通用信息服务(Generic MessageService，MSG)。两者传输机制一样，不同的是MSG并不采用应用支持子层(APS)数据帧的内容，而是留给profile应用者自己去定义。栈配置
栈参数的集合需要被配置为一定的值，连同这些值在一起被称之为栈配置。ZigBee联盟定义了这些由栈配置组成栈参数。
网络中的所有设备必须遵循同样的栈配置。
为了促进互用性这个目标，ZigBee联盟为ZigBee2006规范定义了栈配置。所有遵循此栈配置的设备可以在其他开发商开发的遵循同样栈配置的网络中。
栈配置是指对分布式应用的描述。它根据应用必须处理的数据包和必须执行的操作来描述分布式应用。使用描述符对配置文件进行描述，描述符仅仅是各种值的复杂结构。此配置文件使ZigBee 设备可以互操作。ZigBee 联盟已经定义了很多标准的配置文件，比如远程控制开关配置文件和光传感器配置文件等。任何遵循某一标准配置文件的节点都可以与其他实现相同配置文件的节点进行互操作。每个配置文件可以定义最多256 个群集，而且和我们在前面所看到的一样，每个群集可以最多有65536 个属性。此灵活性允许节点有大量的属性（或I/O 点）。
https://www.doczj.com/doc/9314458969.html,/view/061236fb0242a8956bece447.html
AF层为各个用户自定义的应用对象提供了模板式的活动空间，为每个应用对象提供了KVM和MSG服务
AF中，应用程序可以通过APSDE-SAP发送、接收数据，通过ZDO公共接口实现应用对象的控制与管理。
APSDE-SAP提供的服务：数据请求、确认、指示等原语。
请求：用在对等实体间实现数据传输
确认原语报告数据请求原语执行的结果，而指示原语用来指示APS向目的应用对象的数据传送。
APSDE_SAP保留两个附加端点。端点0作为ZDO的数据接口，端点255保留作为向所有应用对象的数据广播。241-254保留。
为适应APSDE_SAP提供的数据服务，应用框架可以为应用对象提供两种数据服务：价值匹配服务(KVP)和一般信息服务(MSG)。
通信方式：
1、直接：关键在于短地址的获得。无需绑定。
2、间接：必须绑定。
绑定的方法：
1、间接绑定：
2、直接绑定（OTA）：可用第三方节点进行绑定。
3、直接绑定（通过串口）：用的较少
绑定条件：
ENDPOINT描述信息中ClusterID必须相等，且属性方向相反。
绑定后的通信方式：通过endpoint和cluster信息进行通信。
通信部分消息帧有：
KVP与MSG两种方式，其中MSG方式的帧格式可以用户自定义。
MSG不对APS帧做任何假设，而将帧中的相应域保留，由模板开发者进行定义。
ZDO提供应用对象，模板和APS之间的接口，表示一类基本的功能。它处在应用框架和APS之间，满足Zigbee协议中所有的应用操作的公共需求。这些公共接口在应用框架中提供设备地址管理、发现、绑定和安全功能。
ZDO提供的五种管理：
1、发现管理：设备发现、服务发现
2、网络管理
3、绑定管理：可选
4、安全管理：可选
5、节点管理：可选
端点由应用程序开发者决定的，要保证结构简单，能够满足服务发现的需求。应用程序被安置在端点，它有一个简单的描述符。正是通过简单描述符和服务发现机制才能实现服务发现、绑定，功能互补的设备之间的信息交换更为容易。需要注意：服务发现是建立在模板标识符、输入簇标识符表、输出簇标识符表的基础上的。
绑定：
绑定是一种两个或者多个应用设备之间信息流的控制机制。在最新版的Z-STACK版本中，它被称为资源绑定，所有的设备都必须执行绑定机制。
Profile是这样一种规范，它规定不同设备对消息帧的处理行为，使不同的设备之间可以通过发送命令、数据请求来实现互操作。
端点：是一种网络通信中的数据通道，它是无线通信节点的一个通信部件，如果选择绑定方式实现节点的通信，那么可以直接面对端点操作，而不需要知道绑定两个节点的地址信息。它是zigbee无线通信中的一个重要参数。
为什么zigbee控制器和效应器的简单描述符endpoint ID要相同
Endpoint说明了通信参数。可以理解为类似端口号的东西，一定要匹配才能通信。在一个网络中可以有若干个通道通信。
描述符：
Zigbee设备使用描述符数据结构描述其自身。包含在这些描述符中的实际数据被定义在每个设备描述中。Zigbee总共有五个描述符：节点描述符、节点功率描述符、简单描述符、复杂描述符和用户描述符。
节点和节点功率描述符应用于整个节点。其他描述符由节点中所定义的端点指定。
简单描述符：简单描述符包含的信息指定了包括在节点中的每个端点，对存在于节点中的每个端点而言，它是强制的。
描述符是按照上面出现的顺序发送。
AF帧格式，这个帧是一个关键点。
这个帧的帧类型中可以选择KVP或MSG。此后的事件中的事件数据域是KVP帧格式或MSG 帧格式。
KVP命令帧的使用
CC2530内置温度传感器的设置方法：
（详情参见CC2530原理手册.pdf，网上也能找到，我改了手册名称。）
To configure a Port 0 pin to be used as an ADC input, the corresponding bit in the APCFG register must beset to 1. The default values in this register select the Port 0 pins as non-ADC input
由此可见，PO口可以通过把APCFG register中相应位置1才将其配置成AD输入。
the output of an on-chip temperature sensor can be selected as
an input to the ADC for temperature measurements. In order to do so, the registers
TR0.ADCTM and ATEST.ATESTCTRL must be set as described in the register descriptions in Section 12.2.10 and
Section 23.15.3 (CC253x)
Channel numbers 12 through 15 represent GND (12), temperature sensor (14), and
AVDD5/3 (15), with channel 13 being reserved. These values are used in the ADCCON2.SCH and ADCCON3.SCH fields.
关键函数的理解：
osal_start_system操作系统循环主体
osal_set_event设置事件标志位
osal_start_timerEx过一段事件设置相应的事件标志位
关键数据结构：
tasksEvents
taskArr
任务处理机制：
16位数据中的每一位都能代表一个事件。
工作流程：
事件（按键按下事件）发生，将tasksEvent 中的相应位置1；osal_start_system 中轮查到事
件发生（tasksEvent非零），然后通过events = (tasksArr[idx])( idx, events )来执行相应的任务。
下面介绍一下按键工作流程：
首先想，判断按键是否按下，哪个按键被按下的处理函数在哪呢？
由于按键是硬件，所以到HAL中看看，在里面的Target里面有hal_key.c文件,到里面寻找轮查函数。显然void HalKeyInit( void )这个函数里面没有，往下找，在void HalKeyConfig (bool interruptEnable, halKeyCBack_t cback)这个函数中我们发现了惊喜：osal_start_timerEx (Hal_TaskID, HAL_KEY_EVENT, HAL_KEY_POLLING_VALUE); 从函数的结构上我们可以看出每隔HAL_KEY_POLLING_VALUE时间，置一个HAL_KEY_EVENT事件。
问题来了，一、这个函数是否会得到执行，一般来说一定会的，二、这个函数是否通过置一个键盘事件让后面的处理函数扫描键盘，确定是否有按键被按下。
先解决第一个问题，通过搜索HalKeyConfig，我们能发现这个函数在Oboard.c的void InitBoard( byte level )这个函数中得到执行，也就是初始化中执行。由此我们可以得出，在初始化的时候置了一个HAL_KEY_EVENT事件。
第二个问题，就是在对HAL_KEY_EVENT事件进行处理的过程中是否进行了键盘扫描，判断是否有按键被按下。至此，有一个问题出来了，HAL_KEY_EVENT在哪得到处理的？
通过搜索HAL_KEY_EVENT，我们找到，这个事件在hal_drivers.c的uint16 Hal_ProcessEvent( uint8 task_id, uint16 events )这个函数中得到处理。找到HAL_KEY_EVENT这个函数的到处理的位置，我们上面的问题得到解决，回到我们的第二个问题。看看在对HAL_KEY_EVENT事件进行处理的过程中是否进行了键盘扫描，判断是否有按键被按下。我们从找到的对HAL_KEY_EVENT事件进行处理的代码中有下面关键的语句：
if (events & HAL_KEY_EVENT)
{
#if (defined HAL_KEY) && (HAL_KEY == TRUE)
/* Check for keys */这个注释似乎告诉我们按键检测在这里，我们还等什么，看吧。
HalKeyPoll();
/* if interrupt disabled, do next polling */这个注释似乎告诉我们如果按键不是已中断方式进行触发，而是轮查方式，则在100ms后将置一个HAL_KEY_EVENT事件。想必你也可以看出，每隔100ms，这个函数将得到一次执行。随之上面的HalKeyPoll()也一起执行。
if (!Hal_KeyIntEnable)
{
osal_start_timerEx( Hal_TaskID, HAL_KEY_EVENT, 100);
}
先看红字部分
找到HalKeyPoll()，我们从上面的注释中似乎感到，我们上面的第二个问题得到了解决。从具体代码中我们看到，这个函数在做键盘扫描工作，判断是否有相关的按键被按下，如果有按键按下，则调相应的程序进行处理。至此第二个问题得到解决。
在此我们做一下小结：这是什么样的过程呢？
通过初始化置了一个HAL_KEY_EVENT事件，通过OSAL的分配机制找到相应的处理函数对HAL_KEY_EVENT进行了处理。处理的过程就是判断是否有按键被按下，哪个被按下，并交给相应的程序处理。由此呢，我们也可以看出HAL_KEY_EVENT具体是一个什么事件了。
在对HAL_KEY_EVENT进行处理的过程中，我们说到，通过判断哪个键值被按下，交给相应的程序处理（上面红字），这是如何做到的呢？
我们继续看HalKeyPoll中的代码，在最后的部分我们又发现了惊喜：
/* Invoke Callback if new keys were depressed */如果有按键按下，回调函数。
if (keys && (pHalKeyProcessFunction))
{
(pHalKeyProcessFunction) (keys, HAL_KEY_STATE_NORMAL);
}
我们感到，(pHalKeyProcessFunction) (keys, HAL_KEY_STATE_NORMAL)这个函数将实现对不同键值的不同处理。通过搜索pHalKeyProcessFunction，我们发现，这是一个回调函数，在hal_key.c的void HalKeyInit( void )中得到初始化，代码如下：
/* Initialize callback function */
pHalKeyProcessFunction = NULL;
但是这个不是我们想要的，我们想知道这个回调函数到底指向了哪。所以我们继续寻找。我们发现在void HalKeyConfig (bool interruptEnable, halKeyCBack_t cback)函数中，有以下语句：pHalKeyProcessFunction = cback;
但是cback指向哪呢？我们看到cback是函数的形参，所以我们只要找到调用HalKeyConfig的地方，就可以找到cback。搜索HalKeyConfig，我们在Onboard.c的void InitBoard( byte level )中发现以下语句：
HalKeyConfig( OnboardKeyIntEnable, OnBoard_KeyCallback);
说明什么呢？回调函数pHalKeyProcessFunction最后调用的是OnBoard_KeyCallback，在Onboard.c中我们找到void OnBoard_KeyCallback ( uint8 keys, uint8 state )，至此我们可能会感到些什么，如果没有发现我复制个东西到这里对比下看看：
(pHalKeyProcessFunction) (keys, HAL_KEY_STATE_NORMAL);
发现了吧！在调用这个函数对相应的按键值做出响应时，实际上调用的是void OnBoard_KeyCallback ( uint8 keys, uint8 state )。那么下面我们就看一下这个函数吧。
在这个函数中，我们看到了一个函数OnBoard_SendKeys( keys, shift )。我们马上进行追踪，发现了osal_msg_send( registeredKeysTaskID, (uint8 *)msgPtr )这个关键的函数，想必大家对这个强大的函数有所了解，它的作用就是给相应的taskid发送一个消息（哪个按键被按下了）。如果我们感到好奇，可以追踪这个函数，在这个函数中我们发现下面两个主要语句：// queue message
osal_msg_enqueue( &osal_qHead, msg_ptr );
// Signal the task that a message is waiting
osal_set_event( destination_task, SYS_EVENT_MSG );
什么意思呢？
将消息加到消息队列中；然后通知相应的任务对其消息进行处理。也就是用下面这条语句把相应的任务（destination_task）对应的事件（SYS_EVENT_MSG）置1。
在上面的红字部分我们留下了一个问题，这个相应的taskid到底是谁呢？
从OnBoard.c中的osal_msg_send( registeredKeysTaskID, (uint8 *)msgPtr )这个函数，我们可以知道，是将消息发给了registeredKeysTaskID这个任务进行处理，我们搜索它的定义，出现了static byte registeredKeysTaskID = NO_TASK_ID，很遗憾没有解决，但是我们知道它一定被赋其他值了，所以我们要进行全工程搜索。我们发现，在OnBoard.c的byte RegisterForKeys( byte task_id )这个函数中我们看到下面语句：
registeredKeysTaskID = task_id;
很显然，在注册按键任务的时候对其进行了赋值，但是我们从这里还不能看到，我们继续搜索RegisterForKeys，在sapi.c的void SAPI_Init( byte task_id )函数中我们看到以下语句：RegisterForKeys( sapi_TaskID );
呵呵，是不是应该一阵狂喜？
到此，我们能看到什么呢？
osal_msg_send( registeredKeysTaskID, (uint8 *)msgPtr )这个函数是将一个按键信息发送给了应用层进行处理。
也就是说，当判断有按键被按下时，我们将哪个按键被按下的信息发送给了应用层任务进行处理。当然我们在应用层可以找到相应的处理函数对相应的按键值进行处理。
至此我们可以对按键工作流程进行总结了：
1初始化的时候出发一个HAL_KEY_EVENT，在相应程序对这个事件进行处理的过程中，进行了键盘扫描，确定是否有按键按下，如果有按键按下，回调相应的处理函数。并且有设置了一个HAL_KEY_EVENT事件在100后处理，这是什么过程？
呵呵，又一次印证了工作流程图。至此按键工作流程部分结束。
如果以上的知识全部掌握，可以自由的加自己的任务了。
也就是说，我们可以在终端中添加应用，例如，温度、湿度的采集。这些应用我们都能加了。
下面一个问题就是我们如何将自己采集的数据通过zigbee进行传输
如果看到了DemoSensor.c中的sendReport这个函数，估计通过zigbee发送数据的问题就能解决了。我们只需在pData后面添加数据，并修改数据长度SENSOR_REPORT_LENGTH 即可。
至此，我们在终端的开发可以结束了。
路由部分，只做数据转发，只要一帧数据没有超过定义的最大值即可。这部分代码Z-STACK都已经帮我们做好。（数据长度的部分是否需要修改，现在我还不能确定，我认为不用改了）
网关部分，这部分一要接收数据，利用相应的结构体（gtwData），对接受数据进行封装。然后通过串口将数据传输到PC.
下面要解决的就是将收到的数据通过串口传给PC.
在DemoCollector.c中我们发现static void sendGtwReport(gtwData_t *gtwData)这个函数，显然，这个函数封装了串口发送的数据帧。然后发送。我们如果需要发送自己的数据，只需要改变数据部分，并修改帧长度即可。
这里注意：
// Length
pFrame[FRAME_LENGTH_OFFSET] = 10;
ZB_RECV_LENGTH
注意区分二者。
串口初始化工作在DemoAppCommon.c中完成。
至此，我们可以利用串口发送自己的数据到PC。
如果仅从应用开发的角度，我们想采集各种数据这个应用来说，现在我们已经能够完成项目要求。但是还有很多细节的地方需要更深入的了解。
在实战中加深理解吧！