WSN/Zigbee开源协议栈
1. msstatePAN
http://www.ece.msstate.edu/~reese/msstatePAN/ Last Updated: Mar 6, 2007
较为简单，容易上手。附带一个较为详细说明文档。整个协议栈是基于状态机的实现的。只是其中程序排版不太规范。通过这协议栈使我对FSM重新的认识。如果 你的程序构架不是基于操作系统的，有限状态机应该是一个很好的选择。而且OS中进程的状态也是个各个状态间的切换。
Robert Reese 也出了本书《Finite State Machine Datapath Design, Optimization, and Implementation》
下载地址： http://www.elecfans.com/soft/35/2009/2009072237323.html
2. freaklabs：http://freaklabs.org/
这个是最近才发现，介绍很详细。程序排版很规范，让人看着舒服。而且自己做了硬件，貌似看着还是腐蚀的电路板。代码注释挺详细的，而且对于zigbee的各个层的也归纳性的介绍，详见网站。
硬件支持CPU: Freescal MC13244 / Atmel AT86RF230 + RF: TI CC2420/2520
防止翻译失真，还是附上原文。
http://freaklabs.org/index.php/FreakZ-Open-Source-Zigbee-Stack.html
Motivation:
One of the problems with the current state of Zigbee is that the software is either provided by semiconductor suppliers and bound to their hardware, or is proprietary and requires heavy licensing fees. This causes some major issues that I have a problem with:
1) It's very difficult for individual electronics enthusiasts to create their own Zigbee designs since they usually cannot afford the licensing fees or the costs of the proprietary tools (compilers, debuggers, etc) associated with developing a Zigbee application. In many cases, some of the most innovative creations come from individual enthusiasts or people with specific domain knowledge that might not be addressed by software or semiconductor vendors. I'm hoping that having a free stack with full source code access will allow people the freedom to create interesting things and hopefully create projects that can improve other people's lives.
2) It's almost impossible to mix and match hardware to optimize an application. Some designs are limited to using an ARM microcontroller since it may be part of an SOC that's needed for a specific application, ie: MP3 or video decoding. However the application would benefit from the addition of wireless communications. There currently isn't an easy way to take an MCU such as an ARM based one and mix it with an 802.15.4 radio from a different vendor to make a Zigbee application. This is because the Zigbee software given away by semiconductor vendors is either in binary form or contains a license clause which only permits the use of the software with their hardware. Software companies selling proprietary stacks usually charge stack licensing fees that can go upwards of $50k and also require fees for driver modification for specific MCUs. One of the goals of this project is to provide a free Zigbee stack which will give designer's flexibility in choosing their components with no proprietary lock-in.
3. TinyOS ： http://www.tinyos.net/
目前在WSN领域最权威的操作系统，里面完成协议设计自带仿真软件。看过不少文章，它最多。而且网上资料也很多。
TinyOS is an open-source operating system designed for wireless embedded sensor networks. It features a component-based architecture which enables rapid innovation and implementation while minimizing code size as required by the severe memory constraints inherent in sensor networks. TinyOS's component library includes network protocols, distributed services, sensor drivers, and data acquisition tools – all of which can be used as-is or be further refined for a custom application. TinyOS's event-driven execution model enables fine-grained power management yet allows the scheduling flexibility made necessary by the unpredictable nature of wireless communication and physical world interfaces.
成立了 TinyOS ZigBee Working Group 已经开始设计开源的zigbee，期待中.......
http://www.tinyos.net/scoop/special/working_group_tinyos_zigbee
---------------------------------------------------------------------------------------------
目前提供zigbee方案的有TI 、Atmel、Jennic、ST、Ember、NEC等. TI 是提供方案最全的公司，新出的CC2530，看到了WSN/zigbee的发展前景。还有Atmel基于ARM核的MC13244.在低功耗的情况下输出 功率更大。
WSN里面感觉比较重要的两个问题：
1. 低功耗情况下输出功率尽可能大一些而且可调。目前 CC2530 /MC13244基本解决这个问题。
2. 电源。高性能电池选用以及最近看得文章能量采集(EnergyHarvesting) 技术，利用电磁波转换成电流信号给传感器节点供电。
能量采集市场前景广阔 2019年超40亿美元
http://www.eeworld.com.cn/mndz/2009/0722/article_1616.html
诺基亚展示能量采集手机，藉无线电波充电（NOKIA也介入WSN，看过一篇相关的文章）
http://www.eeworld.com.cn/xfdz/2009/0617/article_1486.html
一直以来关注的是TI的产品，而且提供的协议栈也挺好，只是如果没有ucos一些基础知识的话，门槛高一些，下面是我对协议栈的简单总结。英文基础好的话 直接看document里面的说面文档，介绍很详细，即使不好多看几次也能明白。不过近来国内一公司对这部分资料翻译了（哈哈，偶没打广告） http://www.zigbee-sh.cn/zigbee_info.asp 看他们网站也没硬件方案和相关的代理，难道还真是为人民服务。
Z-Stack 是通过UCOS来实现的，其中协议的各个层被分配一个任务，共有如下任务：Hal、mac、nwk、MT（Monitor Test简称）、APS、ZDApp和SampleApp。 Hal、mac、nwk、APS就不介绍了（主要完成zigbee协议的各个层）。TI为了使用户调试方便而编写一些上位机软件（如 SmartRF04Prog、sniffer、Z-Location Engine等），而MT（Monitor Test）是用来完成协议栈与这些上位机软件的通信的，通过串口来完成，因而MT中主要完成的是串口指令的收发机解析，并经该消息发给OS，由操作系统对 这些消息进行处理。ZDApp（ZigBee Deviece Application）是zigbee设备的应用层处理函数，可以通过这层的函数来与网络层和APS曾进行通信，如完成组网那，加入网络，端点匹配、绑 定等。SampleApp是用户完成的部分（也分配了一个任务），主要在这里完成自己的编程设置。
OS中每个任务都有一个任务初始化函数和任务事件处理回调函数，如SampleApp_Init( taskID )和SampleApp_ProcessEvent( byte task_id, UINT16 events )。如果需要深入了解任务的工作机制，如任务管理、调度任务的同步与通信等，可以去看uC/OS得相关资料。而任务下面又划分很多事件（可以把事件理解为 当前任务下的一些小的任务）。在OS中事件是为了实现任务间的同步与通信的，如信号量、消息邮箱和消息队列。单片机基础对于OS不胜了解的可以这样来理 解，自己当初也是这样来理解的（可以把任务中的发送事件理解为置标志位，在本任务或另一个任务中查询标志位来完成相应操作）在uCOS中任务和事件的处理 是由操作系统来完成的，任务按照优先级来调度，每个任务有自己的任务控制块来决定和记录任务的执行情况，而事件有事件控制块。在实际应用中很多时候做得也 是这个工作，例如在SampleApp_ProcessEvent中来完成事件的功能，刚开始可以把各个事件按照C中的SWITCH CASE来理解，或者状态机的状态切换的理解（实际上应该据自己浅薄的理解，OS中任务及事件的跳转就如同状态机完成各个状态间的切换，只是每个任务都有 个优先级和任务的执行时间，uC/OS中的任务正是基于优先级的调度）
查看相关书籍，任务中的事件尽可能执行时间短，即把任务分成尽可能多一些事件，这样实时性更高一些，但是好像事件是有上限的，例如 Z-Stack 中规定每个task最多有个15个events。而操作系统是在一个个时隙下来完成（时间间隙）。在实际应用中要很好的利用好
osal_start_timerEx( TaskID,SEND_MSG_EVT,MSG_TIMEOUT）
osal_stop_timerEx( task_id, event_id );
osal_set_event( task_id, event_flag )。
---------------------------------------------------------------------------------------------
在ZStack 中协调器和路由节点是由主电源来供电的得一直工作，而终端节点采集数据并睡眠。但是在实际应用中有时候路由节点也不方便用主电源供电的，而且对于采集数据 不太频繁的网络，靠近终端的路由节点也没必要一直处于工作状态。基于上述思想，因而我想让部分路由节点也睡眠，前提是整个网络能够保持时间同步。
由于在ZStack中不支持路由睡眠，需要自己写相应的睡眠函数。我也是模仿其中的halsleep写得，但是在实际调试过程中，一进睡眠模式，程序就跑 飞，逐个屏蔽发现也是PCON | = 0X10 （启动睡眠）这语句导致的，相当于还是不能进睡眠。在协议栈外面单独调试，通过外部中断唤醒，能够正常工作电流也基本符合要求。在msstatePAN 协议栈中也做了类似的处理，预期的目标已达到。
4488
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
