After two release in Aug 2007 and Nov 2009, and In the midnight of the last day in 2009, I'm pleased to announce the 1.0 release of OpenWSN, the fundamental sensor networks developing platform!
Currently, the 1.0 formal release is running on ICT's GAINz hardware. Compare to the 1.0 release candidate version, the formal release:
- fix bugs found;
- add binary hex files so you can directly download them into the gainz hardware and see openwsn's running;
- add experimental video( search tjopenwsn in www.youku.com)
专辑: 同济大学OpenWSN平台测试视频
http://www.youku.com/playlist_show/id_4052007.html
Currently, the OpenWSN 1.0 includes the following components
hal
- adc component (hal_adc)
- assertion (hal_assert)
- transceiver (hal_cc2420)
- cpu (hal_cpu)
- debug input/output (hal_debugio)
- interrupt (hal_interrupt and hal_foundation)
- led output (hal_led)
- luminance sensor (hal_luminance)
- rtc (hal_rtc)
- humidity sensor (hal_shtxx)
- spi (hal_spi)
- hardware timer (hal_timer)
- uart (hal_uart)
- watchdog (hal_wdt)
- target board (hal_target)
- startup (hal_startup)
osx
- event scheduling and dispatching kernel (osx_kernel)
- an ultra light os kernel inherited from old systems (osx_nano)
- event queue for communication between ISR and None-ISR programs (osx_queue)
- timer to generate tick to drive osx (osx_timer)
- debug agent (osx_dba)
rtl
this layer provides some general data structures to help embedded developing
- binary spliter of continuous data stream, will be provided in the next version) (rtl_binspliter)
- base64 codec (rtl_base64)
- crc checksum (rtc_crc)
- debugio support (rtl_debugio)
- event dispatcher (rtl_dispatcher)
- byte based iobuf (rtl_iobuf)
- event notifier (rtl_notifier)
- an lightweight collection data structure (rtl_lightcollection)
- an lightweight queue data structure (rtl_lightqueue)
- an lightweight vector data structure (rtl_lightvector)
- math functions (rtl_math)
- event notifier (rtl_notifier)
- open frame /802.15.4 frame (rtl_openframe)
- random generator (rtl_random)
- serial communication based on uart (rtl_siocomm) => replaced by svc_siocomm
- standard c library replacement. generally, you needn't this module. (rtl_stdc)
- high level stochastic generators (rtl_stochastic, not published and test yet)
- string utility functions (rtl_string)
- text codec which is similar to binary codec of continuous data streams (rtl_codec)
- time structure shared (rtl_time)
- version management macros (rtl_version)
svc / service
- svc_acceptor (next release)
- aloha medium access control (svc_aloha)
- tree based data collection protocol (svc_datatree, test failed. will be fixed in 2010 in the next release)
- debug input/output (svc_debugio)
- flood protocol (svc_flood)
- interpreter (svc_interpreter, formal release in the next version)
- gradient routing protocol (svc_gradient, formal release in the next version)
- input/output filter architecture (svc_iofilter, formal release in the next version)
- led tuning service to help experiments (svc_ledtune)
- one to many data collection (svc_one2many)
- power management service (svc_power. formal release in the next version)
- svc_sinknode, (refer to gatwsink demostration)
- serial input/output communication using uart (svc_siocomm)
- timer multiplexing of basic timer hardware (svc_timer)
- timer synchronization (svc_timesync, formal release in the next version)
Attention
Different from the release candidate version, the "datatree" service (data collection tree) will be upgraded as "gradient" in the next release.
Showing posts with label 设计与实现. Show all posts
Showing posts with label 设计与实现. Show all posts
Sunday, January 10, 2010
Saturday, May 31, 2008
如何开发更具鲁棒性的ZigBee解决方案
如何开发更具鲁棒性的ZigBee解决方案
[日期：2008-5-30]
来源：电子工程专辑 作者：Damon Stewart MaxStream公司
ZigBee 在无线传感器网络领域中受到了人们的密切关注，主要是由于ZigBee承诺能为可靠、高性价比和低功率的无线通信提供全球性统一规范。并且在目前的无线设备市场中，ZigBee联盟经过不懈地努力已经将ZigBee的地位提升了一大步。仅仅用了几年的时间，该联盟就发展了200多家联盟成员。ZigBee 芯片组和协议栈已经可以很容易地从许多供货商那里得到。去年市场上已经出现第一套ZigBee终端产品。
通过精心地定义ZigBee规范中的网络和应用层，ZigBee联盟希望独立的设备制造商能够开发出可以互操作的优秀终端产品。成员们对ZigBee芯片组给予了很高的期望，希望能够帮助OEM制造商进一步降低成本，从而为系统集成商和终端用户提供低成本的终端产品。
随着市场需求的增长以及大量的志愿者投入研究ZigBee规范，现在已经到了将一个低成本、低功率的无线网络的可行性方案提供给人们的时候了。本文将讨论设计和集成一个ZigBee方案时应该考虑的一些重要因素。文中的许多内容来自MaxStream公司在研发其首套ZigBee认证产品 ——XBee OEM无线模块过程中所获取的经验。
ZigBee一览
1. ZigBee网络
ZigBee定义了三种节点类型：协调器、路由器和终端设备。协调器可以通过选择网络的工作信道和个域网识别标志(PAN ID)来启动一个ZigBee网络。一旦网络启动，路由器和终端设备就能加入网络。协调器和路由器都能通过网络发射和路由数据，并且允许其它的路由器和终端设备加入。终端设备不能参与路由数据，因此在不发射和接收数据时可以休眠。当设备加入ZigBee PAN时，设备间的父子关系即形成，加入的设备为子，允许加入的设备为父。一个简单的ZigBee网络如图1所示。
2. ZigBee寻址
ZigBee设备支持两种地址类型：一种是64位IEEE地址，另一种是16位网址。64位地址在所有ZigBee设备之中是唯一，其中包含一个由IEEE分配、也是全球唯一的24位制造商特定组织识别符(OUI)。
当设备加入ZigBee个域网时，它可以从允许其加入的父设备上获取16位网址。该网址在个域网内被规定为唯一。该网址用于数据传输和数据包路由。用于路由数据包的路由表存放着各个目标设备和下一跳设备的网络地址。因此个域网的各设备都必须有明确且唯一的网络地址，以保证数据能到达正确的设备。
图1：简单的ZigBee网络。
然而，在有些条件下一个设备的地址可能会改变，或者是多个节点可能接收到同一个地址。例如，如果终端设备被移除或失去与父设备的联系，它就必须重新连接网络，这可能导致它接收到一个新的地址。另外，如果协调器被一台新设备所替换，新协调器会不知道哪些地址是之前的协调器分发的。新协调器分发给设备的地址很容易与已有的网址重叠。
ZigBee联盟正在加紧研究解决这些地址问题的对策，并将解决方案整合到ZigBee规范中去。但是，一些协议栈和模块提供者，譬如MaxStream公司已经研发出解决这些问题的方法。
3. ZigBee路由
ZigBee包括一个用于AODV网状路由的基本框架。如果一个设备需要向其它设备发送数据，它首先需要发现一条可能要经过多台路由器才能到达目标设备的路由。网状路由允许动态地建立、修改或替换传输路径，从而保持设备间有一条可靠的路径。
然而，除网状路由之外，ZigBee规范还经常依赖树状路由。在树状路由中，数据将在源设备和目标设备之间的“树”状路由上严格地按照从父到子或从子到父的路径传输。
图2：树状路由(左)和网状路由(右)的演示。
当节点移动或删除时路由可能出现问题。这时如果单个节点无法从一条路由中隔离开来，那么整个树状路由就无法定位故障点。而网状网络就能在现有路由发生故障时发现一条新路由。
ZigBee协议栈按照规范采用树状和网状路由的ZigBee 1.0标准而建立。两种路由之间的交互是相当复杂的，而且协议栈之间的交互也是不断变化的。但是，增强型ZigBee规范(2006)增加了一个 nwkUseTreeRouting功能，该功能可以使整个树状路由彻底断开，再由(NLME)路由发现请求(route-discovery- request)原语根据需要强制进行路由发现。这些功能可以解决与树状路由相关的问题，并且允许开发商充分发挥网状路由的优势。
图3：当所建通道上的一个节点失效时树状路由(左)和网状路由(右)的性能。
4. ZigBee互操作性
ZigBee规范包括一些可以用来定义各种网络的配置功能。开发商可以很容易地配置以下参数：目标系统中的路由器和/或终端设备数量；安全级别；路由表和邻居表规模；网络最大深度(从协调器到最远派生设备的连接深度)；协调器/父路由器允许的子路由器和终端设备的最大数量。
ZigBee联盟研发出了为这些不同协议栈建立通用设置的公共框架-可配置参数表。为了完成框架(如家庭控制协议栈框架就定义了开灯、关灯、或切换一个灯光的簇ID)内的共同任务，该框架还定义了一些称作簇ID的接口。
终端设备必须围绕可互操作的同一框架来设计。因此，应用开发商必须设置他们的协议栈参数以匹配公共框架所规定的参数值，从而确保与采用同一框架的其它解决方案的互操作性。另外，开发商也可以为了满足其设计而通过采用专用(定制)的框架来自由修改协议栈参数。不过，在专用框架中所定义的簇ID 不具备与基于公共框架的设备互操作的能力。
由于开发商具有选择框架的灵活性，从而并非所有的ZigBee设备都能互操作。虽然这种灵活性一开始会在市场上引起一些混乱，但允许开发商决定其产品是否要与其他供应商的设备进行互操作。在不需要互操作性的场合，功能强大的ZigBee可以围绕一个专用框架进行开发，并剪裁协议栈参数来满足特殊应用需求。
5. ZigBee认证
经认证的ZigBee硬件平台(芯片组和模块)和软件层(PHY层、MAC层和网络层)必须做ZigBee验证平台(ZCP)测试。通过ZCP认证的硬件平台和软件协议栈表明适用于ZigBee终端产品的研发。
在ZigBee兼容平台上开发的终端产品可以直接做产品认证测试。终端产品认证允许产品出现在ZigBee认证产品列表中，并打上ZigBee标识。ZigBee联盟已经开发了相关测试标准来认证基于公共和专用框架的终端产品是否是合格的ZCP产品。
尚未解决的ZigBee问题
ZigBee规范正在继续改进并将提供更多的功能，但同时ZigBee联盟也认识到该规范还存在一些问题：
1. 更改网络地址
如前所述，在ZigBee PAN中分配给节点的网络地址可以改变，甚至在某些条件下会重名。这就使得网络必须解决不可靠的寻址机制，以确保将数据发送到正确的设备中。
ZigBee联盟正在考虑改变寻址机制，以提供更具鲁棒性的寻址机制。同时，包括MaxStream在内的一些模块提供商研发出了基于唯一性64位地址的解决方案，能确保可靠的数据传输。
2. 固定工作信道
由于ZigBee采用802.15.4 MAC/PHY规范中所规定的直序扩频(DSSS)调制，因此可以工作在固定信道。在通过能量扫描筛选出具有较高能量的信道后选出工作信道。但是，一旦初始能量扫描完成后，在所选的信道质量变坏时ZigBee网络无法重置新的信道。因为有许多设备(包括蜂窝电话、微波和802.11网络)占用2.4GHz 频段，因此这可能是一个大问题。目前，终端设备开发商必须在其设计中解决干扰问题。ZigBee联盟也在研究此问题的解决方案。ZigBee规范的新版本可能会解决此问题。
3. 容量限制
ZigBee刚开始打算用64K闪存。但是，对于需要可靠的数据传输、网状组网、更高安全等级、低功率的终端设备等高级应用而言，这一空间将很难满足802.15.4 MAC/PHY、ZigBee网络层以及其它所期望的应用功能要求。随着ZigBee的持续发展，先进的应用似乎需要迁移至带有更多闪存的微控制器。
ZigBee实现方案
随着市场需求的增长和ZigBee自身要素的改善，部署一个经认证的ZigBee方案将具有极高的价值。随着ZigBee规范的最新进展，可以采用现有的ZigBee架构开发出可靠的ZigBee解决方案。开发商必须在从零开始研发自己的软硬件还是集成已经验证过的ZigBee模块解决方案之间作出慎重选择。
为了开发一个鲁棒的ZigBee解决方案，MaxStream公司在ZigBee规范方面付出了大量的时间和精力。以下一些建议都来自于我们的实际经验，对那些打算采用ZigBee解决方案的开发商将有所裨益。
1. 硬件选择
在开发ZigBee解决方案时，首先是要确定硬件平台。通常，硬件平台由一个芯片组或模块组成。如前所述，ZigBee联盟定义了一个用于平台验证的ZigBee ZCP，可用来验证平台是否支持ZigBee方案。如果ZigBee终端产品想携带ZigBee标识并作为ZigBee认证产品上市，所用的硬件平台和 ZigBee软件协议栈必须被ZigBee联盟认证为ZigBee兼容平台。
2. 采用模块
模块提供了比芯片组更多的优点。选用模块可以为开发商节省成本，省去痛苦的RF前端设计、样机设计、产品测试和EMC测试。模块提供商已经通过了严格的应用测试和网络协议栈测试，并且已经加入简化ZigBee接口的一些功能。特别是MaxStream XBee模块还提供了固件，这些固件提供了鲁棒性的网状组网、可靠寻址甚至信道迁移策略，为的是解决尚未解决的ZigBee问题。
如果模块固件不能满足某个特定应用的需求，某些模块提供商还提供了一个灵活的选择。某些情况下(包括MaxStream XBee模块)，设计师能够在模块硬件上开发自己的应用，并定制满足其需求的ZigBee应用。这样的方案虽然需要一些固件开发，但仍然节省了与RF设计、样机设计和EMC测试相关的时间和成本。
3. 采用芯片组
如果采用芯片组，设计师必须准备支持无线设计所需的大量设计、测试和生产要求。在定制板上使用芯片组要求支持硬件生产工艺，包括板级测试、调试和返工。如果选用此方案，必须从IEEE获得一个24位的OUI，以便为每个设备分配一个唯一的64位地址。
当定制板采用芯片组时，设计师还必须选用一个ZigBee网络层协议栈。设计师必须将协议栈连接到他们的硬件上，细心地测试ZigBee应用，并评估网络性能。上述未解决的许多问题甚至所有的ZigBee问题都必须在应用中解决，这将大大地增加研发时间方面的开销。
4. 设备开发
如果必须在芯片组或模块平台上开发定制固件，下面的步骤将会有用。
5. 选择框架类型
在着手开发ZigBee设备前，设计师必须确定是公共框架还是专用框架更能满足需求。设备是需要与与其它普通的ZigBee产品兼容，还是只适合特定的应用？协议栈参数是否需要调整到最佳性能？如果专用框架更合适，就需要向ZigBee联盟申请一个专用框架。
6. 确定路由策略
开发商应该清楚是否允许使用树状路由。对于简单的静态网络，树状路由将足够。如果某些节点有可能去掉，或者需要可靠的数据传输，树状路由就显得不足了。此时，就需要花些时间对协议栈何时调用路由发现进行评估。
如果所选的ZigBee协议栈符合增强型ZigBee规范，应用层就可以利用路由发现请求原语和nwkUseTreeRouting属性来控制路由发现和去除树状路由。如果采用的是网状路由，开发商应该考虑当所有的路由表入口都被占用的情况下系统将如何执行。因为ZigBee规范并不对老化路由和过期路由表条目进行监管，因此一些ZigBee协议栈实现不会去除旧的路由表条目。一旦所有的路由表条目被占用，设备将不能再参与路由发现。如果协议栈无法老化或取代过期条目，应用层就应该加入自己的监管措施来实现。
7. 考虑固定信道操作
对于许多应用，即便是存在突发干扰，ZigBee网络也可以可靠地工作在固定信道上。但是，对于那些必须与其它系统共同工作在同一频段的系统，或者无法允许数据包偶然丢失的系统，则有必要支持信道的迁移。因为目前的ZigBee规范还没有定义信道迁移机制，应用开发商可以自行决定将网络迁移到一个新信道的条件，并开发相应的实现方案。
8. 克服寻址限制
在许多应用中，目前的网络地址分配机制是足够的。但是，为了防止地址重复的可能，更具鲁棒性的ZigBee解决方案应具有复位网络地址的能力(如协调器被替换时)。
由于设备的网络地址不可靠而且会变化(例如，一个加电周期或复位后设备无法找到其父设备)，应用层可能也需要一个能够唯一识别每个节点的解决方案。
为了确保将数据发送到正确的设备上，包括MaxStream XBee在内的一些ZigBee解决方案依赖于唯一的64位地址。如果采用这样的方案，应用层中就必须有相应的配置功能，以便在传送数据之前将64位地址转换成16位的网络地址。
9. 测试
测试应该包括验证系统如何对本文所述的应用场景反应。当路由器关掉时系统有什么反应？在工作信道上出现干扰时系统将如何执行？如果设备接收到一个新的网络地址，该新地址如何被发现？需要重申的是，一些模块和协议栈开发商已经开发出了解决这些问题的配置方案，从而大大减轻了应用开发商的开发负担。
本文小结
虽然ZigBee在前进道路上面临一些重要的问题，但ZigBee联盟具有坚强的毅力、伟大的领导力，还有大批为标准升级积极贡献的优秀设计师。即使是初级阶段，能够为设计师提供强大的网络层功能和应用层灵活性的ZigBee规范的重要基础工作也已经完成。
由于在嵌入式设备领域中有着强大的领导联盟，ZigBee正成为嵌入式设备市场上的重要角色。目前ZigBee联盟正在讨论配置问题以便增加ZigBee价值，并试图解决ZigBee规范中尚未解决的许多遗留问题。经过ZigBee认证的模块和网络协议栈正在开始面市，他们提供强大的网状解决方案，并有效地解决了目前ZigBee规范中存在的许多(即便不是全部)限制。现在正是开始开发可靠的、低功率和更高性价比的ZigBee解决方案的时候了。
Friday, June 01, 2007
A ZigbeeTM-subset/IEEE 802.15.4TM Multi-platform Protocol Stack
A ZigbeeTM-subset/IEEE 802.15.4TM Multi-platform Protocol Stack
Author: Dr. Robert Reese
Associate Professor, Electrical/Computer Engr,
Mississippi State University
http://www.ece.msstate.edu/~reese/msstatePAN/
.
Author: Dr. Robert Reese
Associate Professor, Electrical/Computer Engr,
Mississippi State University
http://www.ece.msstate.edu/~reese/msstatePAN/
.
TinyOS2.0的任务和调度----评述
推荐一篇关于TinyOS 2.0任务和调度方面的文章
TinyOS2.0的任务和调度
http://ailexy.blog.hexun.com/7850138_d.html
顺便推荐一个Blog
http://ailexy.blog.hexun.com/
对TinyOS 2.0调度介绍的比较细致，不过，也许是TEP原文带有了明显的赞成性导向，所以我们看不到对TinyOS 2.0调度设计的负面评价。对其中的一些问题，事实上我们可以进一步思考一下
调度算法和调度器的设计应该说是一个相对比较成熟的问题，在任何一本OS课本中都可以找到有关的介绍，当然如果希望做到real time schedule，还是需要多花一点力气，可能要找几篇文章来看看，现有的很多课本在这点上内容还偏向陈旧。
既然有调度，自然也就引出了调度的对象，按TinyOS 2.0的术语，称之为Task任务，在其它嵌入式OS中，也常常干脆称之为thread。遵循Oram'z Razor原则，我们可以思考一下：如果我们自己设计一个调度机制，而且要求简单到极限，你会怎么做？
作为个人的一个观点，任何一个(函数或组件)，都是一个执行体，都应该可以顺理成章的成为被调度的对象，所以极端情况就是：系统中不必存在显示的Task，因为Task而引入的各种接口显然看上去就有些累赘。
需要思考的第二点是，有了调度器和被调度的任务，那自然就有了在动态执行的任务之间提供数据交换机制的必要，在这点上，传统OS已经有了相当成熟的久经考验的机制，这就是临界区/信号量等，当然也可以包括更高级的队列/邮箱/标志/共享内存等，但我想临界区和信号量应该是必要的。由此体会，TinyOS 2.0借Parameter接口来形式上实现上述通信机制，就显得还不够完备和灵活。
也许我对TinyOS 2.0的理解有错误，但我的确认为，TinyOS 2.0更多的是实验新想法的温床，而不是面向成熟可靠的工业应用而设计。
由此也想到OpenWSN调度器的设计。现在的OpenWSN，不过是一堆可重复利用的组件库，或者你也可以简单的把它看作是个函数库方便应用开发。事实上，我一直希望在其中加入一个调度器，现在可以明确这样说，未来的OpenWSN，将让任何一个普通的C函数，都可以成为调度的对象！我始终相信这样一个原则，Simple means efficient, robust, and elegant!
.
补记：
对一个完整的OS调度而言，还应该深入考虑两个额外的但很重要的问题：
一是多个任务之间的协调；二是多个任务之间的数据交换和传递
TinyOS2.0的任务和调度
http://ailexy.blog.hexun.com/7850138_d.html
顺便推荐一个Blog
http://ailexy.blog.hexun.com/
对TinyOS 2.0调度介绍的比较细致，不过，也许是TEP原文带有了明显的赞成性导向，所以我们看不到对TinyOS 2.0调度设计的负面评价。对其中的一些问题，事实上我们可以进一步思考一下
调度算法和调度器的设计应该说是一个相对比较成熟的问题，在任何一本OS课本中都可以找到有关的介绍，当然如果希望做到real time schedule，还是需要多花一点力气，可能要找几篇文章来看看，现有的很多课本在这点上内容还偏向陈旧。
既然有调度，自然也就引出了调度的对象，按TinyOS 2.0的术语，称之为Task任务，在其它嵌入式OS中，也常常干脆称之为thread。遵循Oram'z Razor原则，我们可以思考一下：如果我们自己设计一个调度机制，而且要求简单到极限，你会怎么做？
作为个人的一个观点，任何一个(函数或组件)，都是一个执行体，都应该可以顺理成章的成为被调度的对象，所以极端情况就是：系统中不必存在显示的Task，因为Task而引入的各种接口显然看上去就有些累赘。
需要思考的第二点是，有了调度器和被调度的任务，那自然就有了在动态执行的任务之间提供数据交换机制的必要，在这点上，传统OS已经有了相当成熟的久经考验的机制，这就是临界区/信号量等，当然也可以包括更高级的队列/邮箱/标志/共享内存等，但我想临界区和信号量应该是必要的。由此体会，TinyOS 2.0借Parameter接口来形式上实现上述通信机制，就显得还不够完备和灵活。
也许我对TinyOS 2.0的理解有错误，但我的确认为，TinyOS 2.0更多的是实验新想法的温床，而不是面向成熟可靠的工业应用而设计。
由此也想到OpenWSN调度器的设计。现在的OpenWSN，不过是一堆可重复利用的组件库，或者你也可以简单的把它看作是个函数库方便应用开发。事实上，我一直希望在其中加入一个调度器，现在可以明确这样说，未来的OpenWSN，将让任何一个普通的C函数，都可以成为调度的对象！我始终相信这样一个原则，Simple means efficient, robust, and elegant!
.
补记：
对一个完整的OS调度而言，还应该深入考虑两个额外的但很重要的问题：
一是多个任务之间的协调；二是多个任务之间的数据交换和传递
Wednesday, February 28, 2007
OpenWSN ----- Beyond ZigBee
OpenWSN与目前热吵的ZigBee有什么关系吗？
首先，需要明确OpenWSN的用途，该开源项目的提出，一是为了满足科研人员对高性能WSN平台的需要（包括我自己），二是附带的为工业应用提供一个可靠的基础开发平台，毕竟，研究的成果应该到实际应用中去检验。
由此，可以理解OpenWSN与ZigBee的不同：
- OpenWSN为Open Source，强调公益性；ZigBee强调商业利益，几乎所有ZigBee解决方案都存在某种程序的封闭性，比如说Chipcon的方案绑定在Atmega MCU，Freescale的方案绑定在自己的MCU，且源代码一般不开放，如果需要获得源码，就要付出高昂的费用。
- OpenWSN重点关注的内容之一就是ZigBee中被封闭的部分，且其覆盖范围更宽。比如说，MAC和Routing, Location, Time Synchronization等，ZigBee毕竟只规定了很小一部分。
- OpenWSN关注底层，放开应用层(Application Layer)，因为OpenWSN相信，应该赋予使用者最大的自由，而应用层又是变化最多的，因此，OpenWSN不限定应用层，只提供若干规范的开发接口。而ZigBee则一直规定到应用层。
- OpenWSN目标中包括了mobile sink和mobile node情形，而ZigBee可以说只考虑了固定结点情形；
- 如果说ZigBee主要是满足当前实际需要，那么OpenWSN更强调未来。
- OpenWSN与ZigBee都强调互联互通，规范化，标准化
由此可见，OpenWSN更学术化一些，更适合在研究和原型化阶段采用。
那么，OpenWSN和ZigBee有什么关联吗？
OpenWSN首选了ZigBee Compatible Transceiver CC2420作为通信芯片，这使得OpenWSN平台可以被用来开发ZigBee应用，OpenWSN平台资源丰富，可以在一定程度上方便开发。
.
首先，需要明确OpenWSN的用途，该开源项目的提出，一是为了满足科研人员对高性能WSN平台的需要（包括我自己），二是附带的为工业应用提供一个可靠的基础开发平台，毕竟，研究的成果应该到实际应用中去检验。
由此，可以理解OpenWSN与ZigBee的不同：
- OpenWSN为Open Source，强调公益性；ZigBee强调商业利益，几乎所有ZigBee解决方案都存在某种程序的封闭性，比如说Chipcon的方案绑定在Atmega MCU，Freescale的方案绑定在自己的MCU，且源代码一般不开放，如果需要获得源码，就要付出高昂的费用。
- OpenWSN重点关注的内容之一就是ZigBee中被封闭的部分，且其覆盖范围更宽。比如说，MAC和Routing, Location, Time Synchronization等，ZigBee毕竟只规定了很小一部分。
- OpenWSN关注底层，放开应用层(Application Layer)，因为OpenWSN相信，应该赋予使用者最大的自由，而应用层又是变化最多的，因此，OpenWSN不限定应用层，只提供若干规范的开发接口。而ZigBee则一直规定到应用层。
- OpenWSN目标中包括了mobile sink和mobile node情形，而ZigBee可以说只考虑了固定结点情形；
- 如果说ZigBee主要是满足当前实际需要，那么OpenWSN更强调未来。
- OpenWSN与ZigBee都强调互联互通，规范化，标准化
由此可见，OpenWSN更学术化一些，更适合在研究和原型化阶段采用。
那么，OpenWSN和ZigBee有什么关联吗？
OpenWSN首选了ZigBee Compatible Transceiver CC2420作为通信芯片，这使得OpenWSN平台可以被用来开发ZigBee应用，OpenWSN平台资源丰富，可以在一定程度上方便开发。
.
Sunday, February 11, 2007
OpenWSN Frame/Packet Summary (draft 20070210)
OpenWSN Frame/Packet Summary (draft 20070210)
this document describes the format of frames/packets in the OpenWSN system.
attention: this design may be different from what we have done now. we will adjust our system to the following. however, some detail are still in discussion.
IEEE 802.15.4 PPDU format
[4B Preamble][1B SFD][7b Framelength, 1b Reserved][nB PSDU/Payload]
QQQ: whether the higher 7 bit or lower 7 bit represent framelength? can any one answer me?
Note that the preamble byte and SFD (start of eliminator) will be processed by hardware chips. so the software only need care about the data from frame length byte. so the real OpenWSN PHY frame defined in OpenWSN software is as the following:
OpenWSN PHY format (TOpenFrame type defined in hal_openframe.h):
[7b Framelength, 1b Reserved][nB PSDU/Payload]
here, PSDU(or namely the payload of PPDU)
is essentially the MAC frame.
attention that OpenWSN MAC format may use the reserved values in IEEE 802.15.4 MAC in the future.
OpenWSN MAC/IEEE 802.15.4 MAC DATA (the payload of PHY frame)
Beacon Frame
[2B Frame Control] [1B Sequence Number][4 or 10 Address][2 Superframe Specification] [k GTS fields][m Padding address fields] [n Beacon payload][2 FCS]
Data Frame
[2B Frame Control] [1B Sequence Number][4 or 20 Address][n Data Payload][2 FCS]
ACK Frame
[2B Frame Control] [1B Sequence Number][2 FCS]
MAC Control Frame
[2B Frame Control] [1B Sequence Number][4 or 20 ADdress][1 Command Type][n Command Payload][2 FCS]
Frame Control
b2b1b0 frame type 000 beacon, 001 data 010 ACK 011 command 100-111 reserved
b12b13 reserved.
One problem puzzled the developer is the format of MAC address. the MAC address varies from 4 byte to even 20 bytes in 802.15.4. The type of address can be decided by the bit settings in Frame Control word in MAC frame.
In the current implementation of OpenWSN, it uses the short address of 802.15.4 MAC only. That is to say, the PAN id, source node id, and destination node id are all 16 bits.
In 802.15.4, the address(unique id) of a device/node, can be 16 bit/2 bytes (short address) or 64 bit/8 bytes (long address). The long 64 bits address is unique in the world. It should be allocated to the device before the device joins the network. While, the short 16 bit address is unique in a specific PAN. So the short address is only meaning full when combining with PAN id together.
However, there's some difference between OpenMAC and 802.15.4.
OpenMAC does more simplifications than 802.15.4 and also add some new features.
- OpenMAC doesn't provide Beacon Frame
- OpenMAC introduce RTS/CTS frame (not implemented till 20070130 in its simple MAC version, but the full version MAC will implement this mechanism)
- OpenMAC adopts the 802.15.4 MAC control frame and extend it to support RTS / CTS frame.
- OpenMAC adopts the 802.15.4 ACK frame. But the software implementation doesn't care this because the ACK frame is processed by cc2420 transceiver chip.
attention:
there's a macro defined in the OpenWSN software: MAC_HEADER_SIZE. this value is 7(???) = 2 frame control + 1 sequence + 4 address bytes (according to the DATA frame only).
OpenNET packet is essentially the payload of the OpenMAC frame.
NET layer also has its address. The NET layer address and MAC layer address are not same. In OpenNET design, every node is assigned a 16 bit unique id (node id) and 16 bit network id (the same as PAN id). So the design can be simplified ---- OpenMAC and OpenNET share the same address fields.
The OpenNET packet:
[4-20B Address] [1B packet control] [1B Command Type] [nB Data]
attention here the "type" byte is the network layer command/packet type. Don't confuse it with MAC layer command. The MAC layer command is used in MAC layer only.
[4-20B Address]
the 4-20B address is shared by OpenMAC frame and OpenNET packet. Due to the complexity address assignment mechanism of MAC address in full version 802.15.4, OpenNET may introduce self-owned address field in the future. But i think it isn't necessary now. So i still let OpenMAC and OpenNET share the same address field.
[1B packet control] = [b7,...b0]
the packet control byte are reserved for future use.
b0 REQUEST flag, default 0
b0 = 0, means this is a RESPONSE packet. the destination node does nothing when it received the packet. this type is usually sent from the sink node to all the other sensor nodes.
b0 = 1 means this is a REQUEST packet. the destination node is required to reply a RESPONSE type packet. this type is often sent from the sensor nodes to the sink nodes.
b1 BROADCASR flag, default 0
b1 = 0, not broadcast
b1 = 1, the current node should broadcast this packet out.
the above attributes can help to implement NET layer protocols such as SPIN.
[1B Command Type] = [b7,...b0]
b7 is used to distinguish whether the command is a OpenWSN system command or user command (namely, application defined command). b7 is 0 for openwsn system command and 1 for application command.
/* system used data types */
#define ODA_TYPE_DEBUG 0x00
#define ODA_TYPE_CONFIGURE 0x01
#define ODA_TYPE_DATA 0x02
#define ODA_TYPE_LOCATION 0x06
#define ODA_TYPE_UPGRADE 0x07
#define ODA_TYPE_PROBE 0x08 // probing neighbor nodes
/* user defined data type
* the developer can add more TYPE defines if necessary. */
#define ODA_TYPE_USER 0x80
#define ODA_TYPE_TEMPSENSOR (ODA_TYPE_USER + 5)
#define ODA_TYPE_VIBSENSOR (ODA_TYPE_USER + 6)
#define ODA_TYPE_STRAINSENSOR (ODA_TYPE_USER + 7)
#define ODA_TYPE_LIGHTSENSOR (ODA_TYPE_USER + 8)
#define ODA_TYPE_OTHER_USER_DEFINED (ODA_TYPE_USER + 100)
attention the values may be adjusted in the near future. however, i'll try my best to make they are stable.
UART frame is quite similar to the wireless PHY frame.
[1B SFD] [1B Length] [nB Payload]
in UART frame, a special byte is used to indicate the start of the frame. attention here OpenWSN uses the technique of ESCAPE character idea to avoid data confilications. The SFD (start of eliminator) byte is used to represent the start of the frame. if there are SFD characters in Length and Payload, then the UART driver will insert another SFD as ESCAPE character.
(??? i have forgot the detail of UART/SIO driver, so this idea need confirmation)
attention that the Payload of the frame is essentially anything. But in our reference implementation of OpenWSN, we makes the "TOpenFrame" describe above as the payload. So the host application can got all the information of the hardware wireless communications. This feature facilitate the developing of host GUI applications.
.
this document describes the format of frames/packets in the OpenWSN system.
attention: this design may be different from what we have done now. we will adjust our system to the following. however, some detail are still in discussion.
- OpenWSN PHY Frame (in wireless communication)
IEEE 802.15.4 PPDU format
[4B Preamble][1B SFD][7b Framelength, 1b Reserved][nB PSDU/Payload]
QQQ: whether the higher 7 bit or lower 7 bit represent framelength? can any one answer me?
Note that the preamble byte and SFD (start of eliminator) will be processed by hardware chips. so the software only need care about the data from frame length byte. so the real OpenWSN PHY frame defined in OpenWSN software is as the following:
OpenWSN PHY format (TOpenFrame type defined in hal_openframe.h):
[7b Framelength, 1b Reserved][nB PSDU/Payload]
here, PSDU(or namely the payload of PPDU)
is essentially the MAC frame.
- OpenWSN MAC Frame (in wireless communication)
attention that OpenWSN MAC format may use the reserved values in IEEE 802.15.4 MAC in the future.
OpenWSN MAC/IEEE 802.15.4 MAC DATA (the payload of PHY frame)
Beacon Frame
[2B Frame Control] [1B Sequence Number][4 or 10 Address][2 Superframe Specification] [k GTS fields][m Padding address fields] [n Beacon payload][2 FCS]
Data Frame
[2B Frame Control] [1B Sequence Number][4 or 20 Address][n Data Payload][2 FCS]
ACK Frame
[2B Frame Control] [1B Sequence Number][2 FCS]
MAC Control Frame
[2B Frame Control] [1B Sequence Number][4 or 20 ADdress][1 Command Type][n Command Payload][2 FCS]
Frame Control
b2b1b0 frame type 000 beacon, 001 data 010 ACK 011 command 100-111 reserved
b12b13 reserved.
One problem puzzled the developer is the format of MAC address. the MAC address varies from 4 byte to even 20 bytes in 802.15.4. The type of address can be decided by the bit settings in Frame Control word in MAC frame.
In the current implementation of OpenWSN, it uses the short address of 802.15.4 MAC only. That is to say, the PAN id, source node id, and destination node id are all 16 bits.
In 802.15.4, the address(unique id) of a device/node, can be 16 bit/2 bytes (short address) or 64 bit/8 bytes (long address). The long 64 bits address is unique in the world. It should be allocated to the device before the device joins the network. While, the short 16 bit address is unique in a specific PAN. So the short address is only meaning full when combining with PAN id together.
However, there's some difference between OpenMAC and 802.15.4.
OpenMAC does more simplifications than 802.15.4 and also add some new features.
- OpenMAC doesn't provide Beacon Frame
- OpenMAC introduce RTS/CTS frame (not implemented till 20070130 in its simple MAC version, but the full version MAC will implement this mechanism)
- OpenMAC adopts the 802.15.4 MAC control frame and extend it to support RTS / CTS frame.
- OpenMAC adopts the 802.15.4 ACK frame. But the software implementation doesn't care this because the ACK frame is processed by cc2420 transceiver chip.
attention:
there's a macro defined in the OpenWSN software: MAC_HEADER_SIZE. this value is 7(???) = 2 frame control + 1 sequence + 4 address bytes (according to the DATA frame only).
- OpenNET Packet (in wireless communication)
OpenNET packet is essentially the payload of the OpenMAC frame.
NET layer also has its address. The NET layer address and MAC layer address are not same. In OpenNET design, every node is assigned a 16 bit unique id (node id) and 16 bit network id (the same as PAN id). So the design can be simplified ---- OpenMAC and OpenNET share the same address fields.
The OpenNET packet:
[4-20B Address] [1B packet control] [1B Command Type] [nB Data]
attention here the "type" byte is the network layer command/packet type. Don't confuse it with MAC layer command. The MAC layer command is used in MAC layer only.
[4-20B Address]
the 4-20B address is shared by OpenMAC frame and OpenNET packet. Due to the complexity address assignment mechanism of MAC address in full version 802.15.4, OpenNET may introduce self-owned address field in the future. But i think it isn't necessary now. So i still let OpenMAC and OpenNET share the same address field.
[1B packet control] = [b7,...b0]
the packet control byte are reserved for future use.
b0 REQUEST flag, default 0
b0 = 0, means this is a RESPONSE packet. the destination node does nothing when it received the packet. this type is usually sent from the sink node to all the other sensor nodes.
b0 = 1 means this is a REQUEST packet. the destination node is required to reply a RESPONSE type packet. this type is often sent from the sensor nodes to the sink nodes.
b1 BROADCASR flag, default 0
b1 = 0, not broadcast
b1 = 1, the current node should broadcast this packet out.
the above attributes can help to implement NET layer protocols such as SPIN.
[1B Command Type] = [b7,...b0]
b7 is used to distinguish whether the command is a OpenWSN system command or user command (namely, application defined command). b7 is 0 for openwsn system command and 1 for application command.
/* system used data types */
#define ODA_TYPE_DEBUG 0x00
#define ODA_TYPE_CONFIGURE 0x01
#define ODA_TYPE_DATA 0x02
#define ODA_TYPE_LOCATION 0x06
#define ODA_TYPE_UPGRADE 0x07
#define ODA_TYPE_PROBE 0x08 // probing neighbor nodes
/* user defined data type
* the developer can add more TYPE defines if necessary. */
#define ODA_TYPE_USER 0x80
#define ODA_TYPE_TEMPSENSOR (ODA_TYPE_USER + 5)
#define ODA_TYPE_VIBSENSOR (ODA_TYPE_USER + 6)
#define ODA_TYPE_STRAINSENSOR (ODA_TYPE_USER + 7)
#define ODA_TYPE_LIGHTSENSOR (ODA_TYPE_USER + 8)
#define ODA_TYPE_OTHER_USER_DEFINED (ODA_TYPE_USER + 100)
attention the values may be adjusted in the near future. however, i'll try my best to make they are stable.
- OpenWSN UART/SIO Frame (in serial communication)
UART frame is quite similar to the wireless PHY frame.
[1B SFD] [1B Length] [nB Payload]
in UART frame, a special byte is used to indicate the start of the frame. attention here OpenWSN uses the technique of ESCAPE character idea to avoid data confilications. The SFD (start of eliminator) byte is used to represent the start of the frame. if there are SFD characters in Length and Payload, then the UART driver will insert another SFD as ESCAPE character.
(??? i have forgot the detail of UART/SIO driver, so this idea need confirmation)
attention that the Payload of the frame is essentially anything. But in our reference implementation of OpenWSN, we makes the "TOpenFrame" describe above as the payload. So the host application can got all the information of the hardware wireless communications. This feature facilitate the developing of host GUI applications.
.
Sunday, January 21, 2007
Q: OpenNET设计思想要点(代设计文档)
因为本Group要解决的问题,我们需要网络层协议支持mobile sink结点. 这个要求与孙利民老师06年NSF基金的要求是很接近的. 而现有的大部分协议要么不支持mobile sink特性,要么不支持多个sink node,所以我们不得不自己设计一个.
to be continued
.
to be continued
.
Q: OpenWSN为什么没有采用标准的802.15.4 MAC和ZigBEE协议？
我想首先纠正一个观点，不存在OpenWSN是否采用某一固定标准的说法。OpenWSN是一个开放的标准体系，它以Library的方式提供给开发人员和研究人员一套可灵活组合并且复用的组件。用802.15.4替换OpenMAC，用ZigBEE替换OpenNET没有任何问题，OpenWSN支持多种选择，而最终选择的自由是用户。OpenWSN不希望强加任何特定的约束给高层用户，它只是希望不同Group/Company的产品能够在底层上互通互换，即使做不到Hardware级别的互通，也可以提供自己特有的Software层次的HAL实现软件上的可移植。
为什么OpenWSN最初没有采用标准的802.15.4和ZigBEE，而是自己提出了一个OpenMAC和OpenNET是源于OpenWSN的定位之一，即它要服务于WSN领域的研究，换言之，MAC/NET本身就是研究的对象，将研究者约束在802.15.4和ZigBEE上显然是不合理的。
此外，实际应用的需求千差万别，802.15.4和ZigBEE并不是万能的。比如说，他们的设计都没有考虑移动mobile node/sink的情形，而我们在做的一个课题就遇到了mobile的问题，这时非得去用802.15.4和ZigBEE显然是没有必要的。而且，构建一套完整的ZigBEE开发环境对用户而言也是一笔不小的支出，至少在我们最初开始进入这个领域时，其价格还停留在十多万的级别。（很多报价很便宜的厂商最后能给802.15.4的代码就不错了，不仅如此，ZigBEE一般都是以二进制方式给出，因此无形中也就限制了使用者选择的硬件平台）因此，我们最初在从事无线Modem开发的基础上，选择了自己做一套。OpenMAC采用类似于802.11的Aloha方式，并没有许多人想象的那么复杂，在低负载时表现应该没有问题，高负载时时延会不确定（仅就目前版本而言）。
可以粗略的给出目前一些方案的定位示意，如下表格不严谨，仅供参考：
...........................|.......固定拓扑网络 .... 可变拓扑网络 ... 高速移动网络
低速率高延迟 ..|...802.15.4和ZigBEE ... OpenMAC ..................?
数据传输
高速率高延迟 ..|...........802.11 ................OpenMAC ..................?
数据传输
高速率低延迟 ..|.............. ?.............................. ?........................... ?
数据传输
标记?的表示目前尚没有好的解决方案。而且，上述解决方案的划分也没有考虑energy问题。如果再考虑energy，就会发现有更多的空白区域是15.4和ZigBEE没有覆盖的。
所以我们可以看出，802.15.4和ZigBEE作为鼓吹的WSN事实标准，也不是万能的，还有很大的研究空间。OpenMAC/NET不过是我们自己针对自己的应用设计的一个简单的MAC/NET协议实现而已。
欢迎其他的Group能够发布你们的MAC/NET研究成果，为OpenWSN提供更多的选择！当然，也非常希望有兴趣的开发人员能够为OpenWSN贡献一套802.15.4 MAC代码，这对高校研究人员构建异构层次网络拓宽研究内容是很有意义的。尽管我们可以拿到针对其他硬件平台的15.4 MAC实现，但是限于版权原因，不能将其加入OpenWSN项目，因此，有兴趣的开发者自己尝试一下还是有意义的。
.
为什么OpenWSN最初没有采用标准的802.15.4和ZigBEE，而是自己提出了一个OpenMAC和OpenNET是源于OpenWSN的定位之一，即它要服务于WSN领域的研究，换言之，MAC/NET本身就是研究的对象，将研究者约束在802.15.4和ZigBEE上显然是不合理的。
此外，实际应用的需求千差万别，802.15.4和ZigBEE并不是万能的。比如说，他们的设计都没有考虑移动mobile node/sink的情形，而我们在做的一个课题就遇到了mobile的问题，这时非得去用802.15.4和ZigBEE显然是没有必要的。而且，构建一套完整的ZigBEE开发环境对用户而言也是一笔不小的支出，至少在我们最初开始进入这个领域时，其价格还停留在十多万的级别。（很多报价很便宜的厂商最后能给802.15.4的代码就不错了，不仅如此，ZigBEE一般都是以二进制方式给出，因此无形中也就限制了使用者选择的硬件平台）因此，我们最初在从事无线Modem开发的基础上，选择了自己做一套。OpenMAC采用类似于802.11的Aloha方式，并没有许多人想象的那么复杂，在低负载时表现应该没有问题，高负载时时延会不确定（仅就目前版本而言）。
可以粗略的给出目前一些方案的定位示意，如下表格不严谨，仅供参考：
...........................|.......固定拓扑网络 .... 可变拓扑网络 ... 高速移动网络
低速率高延迟 ..|...802.15.4和ZigBEE ... OpenMAC ..................?
数据传输
高速率高延迟 ..|...........802.11 ................OpenMAC ..................?
数据传输
高速率低延迟 ..|.............. ?.............................. ?........................... ?
数据传输
标记?的表示目前尚没有好的解决方案。而且，上述解决方案的划分也没有考虑energy问题。如果再考虑energy，就会发现有更多的空白区域是15.4和ZigBEE没有覆盖的。
所以我们可以看出，802.15.4和ZigBEE作为鼓吹的WSN事实标准，也不是万能的，还有很大的研究空间。OpenMAC/NET不过是我们自己针对自己的应用设计的一个简单的MAC/NET协议实现而已。
欢迎其他的Group能够发布你们的MAC/NET研究成果，为OpenWSN提供更多的选择！当然，也非常希望有兴趣的开发人员能够为OpenWSN贡献一套802.15.4 MAC代码，这对高校研究人员构建异构层次网络拓宽研究内容是很有意义的。尽管我们可以拿到针对其他硬件平台的15.4 MAC实现，但是限于版权原因，不能将其加入OpenWSN项目，因此，有兴趣的开发者自己尝试一下还是有意义的。
.
Tuesday, January 16, 2007
Q: 软件开发环境建设
注1：为了以后便于维护，以及方便的在不同人的计算机间迁移开发成果，希望所有人的计算机遵循相同的设置，这包括：WSN项目开发路径，软件安装路径，环境变量设置等。
开发目录设置：
==========
d:\dev\ 开发主目录
d:\dev\openwsn\ OpenWSN核心项目主目录。其下设置如下子目录
bin 二进制可执行文件
data 实验数据
doc 设计文档
hardware 硬件设计
install 用于开发本项目需要的一些特有工具软件
knowledgebase 搜索到的各种资料
release
source 源代码
extern 使用到的各种外部库(目前没有)
include 头文件目录
lib 公共的C文件目录
test 测试代码
libsink
worldview
openwsn
hal
service
ucos-ii
svn 版本管理系统使用
temp 临时文件夹，编译使用
注：每个项目编译过程中产生的中间代码文件放在%WSN%/temp下面，为避免混淆，可以在temp下面建立子目录，输出的二进制文件可以放在%WSN%/bin下面。
应用软件设置
==========
\bin放置那些需要经过安装才能使用的软件
\binx放置那些无需安装，拷贝后即可使用或者设置一下路径就可使用的软件
\bin\ads
\bin\ccs
以下设置仅属于示例，安装目录名全部为小写，可以在安装目录名的后面加上版本号，例如\binx\eclipse-3.3
skyeye
d:\binx\skyeye
一个由清华大学陈渝博士收创的ARM7软件模拟器，在一定程度上可以代替硬件仿真板进行调试开发。
cygwin
d:\binx\cygwin
Windows下面的GNU开发环境
mingw
d:\binx\mingw
Windows下面的GCC开发环境
Eclipse 3.3
d:\binx\eclipse
非常优秀的Eclipse平台软件，用于GCC开发和代码书写，即使只使用其编辑和版本管理也不错
针对SVN系统的版本管理插件subclipse需要另外下载。有一个filesync插件也很有用。
基于Eclipse可以下载CDT从而搭建一套GCC开发环境
TinyOS操作系统
d:\binx\tinyos
针对ARM的GCC编译器
d:\binx\arm-gcc
.
开发目录设置：
==========
d:\dev\ 开发主目录
d:\dev\openwsn\ OpenWSN核心项目主目录。其下设置如下子目录
bin 二进制可执行文件
data 实验数据
doc 设计文档
hardware 硬件设计
install 用于开发本项目需要的一些特有工具软件
knowledgebase 搜索到的各种资料
release
source 源代码
extern 使用到的各种外部库(目前没有)
include 头文件目录
lib 公共的C文件目录
test 测试代码
libsink
worldview
openwsn
hal
service
ucos-ii
svn 版本管理系统使用
temp 临时文件夹，编译使用
注：每个项目编译过程中产生的中间代码文件放在%WSN%/temp下面，为避免混淆，可以在temp下面建立子目录，输出的二进制文件可以放在%WSN%/bin下面。
应用软件设置
==========
\bin放置那些需要经过安装才能使用的软件
\binx放置那些无需安装，拷贝后即可使用或者设置一下路径就可使用的软件
\bin\ads
\bin\ccs
以下设置仅属于示例，安装目录名全部为小写，可以在安装目录名的后面加上版本号，例如\binx\eclipse-3.3
skyeye
d:\binx\skyeye
一个由清华大学陈渝博士收创的ARM7软件模拟器，在一定程度上可以代替硬件仿真板进行调试开发。
cygwin
d:\binx\cygwin
Windows下面的GNU开发环境
mingw
d:\binx\mingw
Windows下面的GCC开发环境
Eclipse 3.3
d:\binx\eclipse
非常优秀的Eclipse平台软件，用于GCC开发和代码书写，即使只使用其编辑和版本管理也不错
针对SVN系统的版本管理插件subclipse需要另外下载。有一个filesync插件也很有用。
基于Eclipse可以下载CDT从而搭建一套GCC开发环境
TinyOS操作系统
d:\binx\tinyos
针对ARM的GCC编译器
d:\binx\arm-gcc
.
Monday, January 15, 2007
Q: 关于常用hal/service对象的简要功能说明？
这些对象是开发过程中最常用的，简要罗列于此（不全）．更准确的说明请参考source code和有关文档．
| 名称 | 说明 | 代码分配原则 |
| Timer | 定时器，提供硬件Timer对象的封装 | HAL层 |
| UART | 串行通信口对象，提供硬件Uart对象的封装 | HAL层，注意UART不同于串行通信对象Sio，Sio中包含更上层的frame处理，后者属于DRIVER层。 目前Uart以Driver形式实现，但仍属于HAL层。 |
| SPI | SPI接口对象，提供对SPI通信口的封装 | HAL层 仅仅包含SPI操作方法，提供一高度稳定可靠的SPI操作库。一切与被操作对象有关的代码都不应该放入SPI。目前以Driver形式实现，属于HAL层。 |
| Transcever | 接收发送器对象，如cc2420的软件封装 | HAL层 目前采用Driver方式实现，不要在该代码中引入任何RTOS调用。由于wireless通信的复杂性，该对象需要提供许多通用接口之外的函数接口如能耗和功率管理等。 |
| SIO | 串行IO通信对象，在UART基础上，进一步提供frame机制处理，包括frame帧头判断、帧尾判断、帧格式封装、帧格式解包、帧校验。 | Driver层 提供帧处理。 如果串行通信也组网的话，那还要包含地址处理 |
| MAC | Medium Access Control 以Driver方式实现，提供标准Driver读写接口，内部包含地址、信道访问冲突处理、帧处理、简单的时间配准、校验和重传、ACK机制等网络通信MAC层处理。 | DRIVER层 MAC内部包含ACK机制。 |
| NET | Networking Layer 拓扑和路由管理 以service方式实现 | SERVICE层 |
| Location | 分布式Location构建在MAC基础之上。 | Service |
| TimeSync | 时间同步，Time Synchronization | Service |
Q: 我为OpenWSN开发了一个模块，如何决定这个模块归入的层次？
此问题即代码分配原则，这对于今后维护，不把整个architecture弄乱是很重要的．
为了回答这个问题，我们需要clarify每个层次的作用以及我们架构设计时的考虑．本answer可以看作是架构设计的进一步详细补充说明：
.
为了回答这个问题，我们需要clarify每个层次的作用以及我们架构设计时的考虑．本answer可以看作是架构设计的进一步详细补充说明：
| 名称 | 说明 | 代码分配原则 依据该原则决定所写代码在何层 |
| BOOT | 启动/引导层 专用于初始化芯片和引导整个系统，例如初始化存储器映射、芯片内部连接、中断等。如果系统中引入了RTOS，则BOOT还要负责启动RTOS。一部分HAL代码的正常工作也需要依赖BOOT | BOOT应只包含MCU芯片的初始化代码，而与目标板(Target Evaluation Board)无关，因此，一切与板子设计有关的代码都不应该归入BOOT层。 |
| RTOS | RTOS层 提供一个实时调度内核。备选的RTOS有：eCos, FreeRTOS, uCOS-II, Linux 2.6 Embedded(准实时)，MANTIS, 和TinyOS(非实时)。 | 事实上，我们只是需要一个小的实时调度器，完全有能力自己开发一个或者移植一个。如果系统资源允许，我们可以引入更多的OS功能，如线程通信和同步、内存管理、调试和控制台等。 |
| HAL | 硬件抽象层 硬件抽象层(hardware abstraction layer)。为了最大限度保证上层代码的可移植性，提供HAL层。 | 可以认为，HAL层是各种硬件对象的软件代理。为了减小移植工作量，HAL中代码应尽可能精简。HAL中的代码是不允许使用RTOS功能的。 |
| DRIVER | 驱动程序层 在比HAL更高层次上提供对硬件功能的封装，比HAL更强调对上层的服务功能。DRIVER层次开发可以使用RTOS提供的调度、通信等功能。原则上，DRIVER中应该尽可能不出现强硬件依赖性代码，尽可能将此类代码放入HAL，但出于开发的便利性不对此做严格限制。 | 凡与硬件相关且不适合放在HAL中的代码都应该放在该层。如果该DRIVER的开发需要利用RTOS的功能，则只能归入DRIVER层。出于开发的方便，一部分没有必要利用RTOS功能的HAL层代码也直接做成了DRIVER，例如Uart, Transceiver, SPI，I2C等。 |
| SERIVICE | 服务层 从面向对象的角度看，一个系统，可以认为是由很多对象组成的，而系统的运行，就可以认为这些对象的动态交互行为。因此，我们需要重点设计和开发好各个对象。这也有助于提高软件代码的可重用性。可独立运行的进程/线程也可以认为是具有自治能力的对象。为了避免class/object名词的混淆，我们用service术语来表示对象，因为每个对象必然是要为其它对象服务的。每个service在设计的时候要牢记Hollywood原则：不要调用我，而要让我来调用你。 | 是系统的主要组成部分，包含了一个应用系统的绝大部分代码。 |
| APPLICATION | 应用层 设置各对象之间的连接方式，提供各对象之间的配置和粘合代码。 | 在一个完整的系统中，应尽可能将大部分代码对象化并归入SERVICE层，APPLICATION应尽可能保持精简。 主要的业务逻辑代码一定要放在SERVICE或DRIVER中，不允许放在APPLICATION层。 |
Q: OpenWSN软件平台参考实现
整个软件系统大致分成四层：
- 应用层 Application
- 服务层 Service
- 驱动层 DRIVER + RTOS
- 硬件抽象层 HAL + BOOT
HAL提供硬件的软件抽象，这是OpenWSN具有良好可移植性的主要原因。事实上，从诞生之日起，可移植性就是OpenWSN的重要目标。BOOT引导与HAL也处于同一层次。在代码中放在hal子目录下，并以"hal_"前缀标明。
DRIVER提供了更高层次的操作抽象。例如OpenWSN针对Uart提供一个Uart硬件抽象，提供基于byte的通信方式，在UART HAL基础上，系统提供SioComm串行通信对象，提供以行或者packet通信的方式。为简单实用起见，对很多硬件，系统只提供了Hal，因为没有必要再去提供额外的Driver. 在代码中放在service子目录下并以"svc_"前缀标明。
Service 更高层次的操作抽象。例如location服务。在代码中放在service子目录下并以"svc_"前缀标明。部分人所说的WSN Middleware也属于这个层次，但OpenWSN的Service目前只囊括了WSN Middleware中的基本必须部分，例如location, time sync等，还未包括诸如data aggregation等服务，原因是data aggregation非常接近于应用，应用相关性太强，难以抽象出来单独实现。
Application代表整个应用。在OOD/OOP体系下，由于service目录中已经提供了大多数可用对象，Application简化成为对象实例的初始化和对象之间的连接功能。代码中提供的rfmodem/analyzer等测试程序示例就展示了这点。当然，根据需要，用户也可以创建新的service对象并在Application中使用。OpenWSN鼓励用户开发新的service对象并反馈给OpenWSN项目。
由这个划分大家也可以看到，我们并未过多强调WSN系统本身的特性，这个设计是出于实用性考虑．目标是开发出的软件要足够的稳定可靠，可满足高可靠的工业实际应用要求．
- 应用层 Application
- 服务层 Service
- 驱动层 DRIVER + RTOS
- 硬件抽象层 HAL + BOOT
Fig. OpenWSN软件平台架构
HAL提供硬件的软件抽象，这是OpenWSN具有良好可移植性的主要原因。事实上，从诞生之日起，可移植性就是OpenWSN的重要目标。BOOT引导与HAL也处于同一层次。在代码中放在hal子目录下，并以"hal_"前缀标明。
DRIVER提供了更高层次的操作抽象。例如OpenWSN针对Uart提供一个Uart硬件抽象，提供基于byte的通信方式，在UART HAL基础上，系统提供SioComm串行通信对象，提供以行或者packet通信的方式。为简单实用起见，对很多硬件，系统只提供了Hal，因为没有必要再去提供额外的Driver. 在代码中放在service子目录下并以"svc_"前缀标明。
Service 更高层次的操作抽象。例如location服务。在代码中放在service子目录下并以"svc_"前缀标明。部分人所说的WSN Middleware也属于这个层次，但OpenWSN的Service目前只囊括了WSN Middleware中的基本必须部分，例如location, time sync等，还未包括诸如data aggregation等服务，原因是data aggregation非常接近于应用，应用相关性太强，难以抽象出来单独实现。
Application代表整个应用。在OOD/OOP体系下，由于service目录中已经提供了大多数可用对象，Application简化成为对象实例的初始化和对象之间的连接功能。代码中提供的rfmodem/analyzer等测试程序示例就展示了这点。当然，根据需要，用户也可以创建新的service对象并在Application中使用。OpenWSN鼓励用户开发新的service对象并反馈给OpenWSN项目。
由这个划分大家也可以看到，我们并未过多强调WSN系统本身的特性，这个设计是出于实用性考虑．目标是开发出的软件要足够的稳定可靠，可满足高可靠的工业实际应用要求．
Q: OpenWSN硬件平台参考实现---- OpenNode
OpenNODE是硬件规范的一个参考实现, 采用如下标准架构：
系统中的各个主要模块之间均通过标准的总线接口实现通信。最关键的是两个接口：wireless board的12 pin接口和sensor board的16 pin接口。母板可自行设计开发，板上可提供板载传感器电路，同时应提供一个16 pin扩展接口，使其可以利用第三方开放的sensor board。
目前的硬件平台方案有这样几条路线：
• low cost MCU based. 主要以Atmel和TI方案为主，实际中也可采用集成了wireless和MCU的Freescale和Chipcon方案。这些方案追求实用低成本。传感器数量有限且集成在母板上，不提供扩展插口。绝大部分目前的ZIGBEE方案都属于这一类。
• ARM 7 based + separate wireless board + separate sensor board。追求 灵活性和适度的处理能力，适合实验教学和原型化。由于处理能力较强，也适合在网络中担任sink、coordinator等责任。
我们现在走的路线是ARM7-based为主。
Sensor module和Processor module之间的连接通过一条简单的总线实现，并通过module selection pin实现模块选择。现在的设计中16根pin中有两根专用于片选功能，若每个sensor module支持译码功能，则可以最多支持四块module。考虑到要尽可能简单，我们并不推荐加译码，这样目前的设计最多支持两块sensor module，一块为母板集成，一块为扩展，足以满足绝大部分实际需要．
．
Fig. Architecture of OpenNODE
系统中的各个主要模块之间均通过标准的总线接口实现通信。最关键的是两个接口：wireless board的12 pin接口和sensor board的16 pin接口。母板可自行设计开发，板上可提供板载传感器电路，同时应提供一个16 pin扩展接口，使其可以利用第三方开放的sensor board。
目前的硬件平台方案有这样几条路线：
• low cost MCU based. 主要以Atmel和TI方案为主，实际中也可采用集成了wireless和MCU的Freescale和Chipcon方案。这些方案追求实用低成本。传感器数量有限且集成在母板上，不提供扩展插口。绝大部分目前的ZIGBEE方案都属于这一类。
• ARM 7 based + separate wireless board + separate sensor board。追求 灵活性和适度的处理能力，适合实验教学和原型化。由于处理能力较强，也适合在网络中担任sink、coordinator等责任。
我们现在走的路线是ARM7-based为主。
Sensor module和Processor module之间的连接通过一条简单的总线实现，并通过module selection pin实现模块选择。现在的设计中16根pin中有两根专用于片选功能，若每个sensor module支持译码功能，则可以最多支持四块module。考虑到要尽可能简单，我们并不推荐加译码，这样目前的设计最多支持两块sensor module，一块为母板集成，一块为扩展，足以满足绝大部分实际需要．
．
Sunday, January 14, 2007
Q: OpenWSN参考实现包含哪些组件？可否理解成为一个新的Sensor OS?
从系统层次的角度看，一个完整的Sensor Node System可以分成这样几个层次(从上到下)：
- Application
- Service
- Hal
- Hardware
Hal means Hardware Abstraction Layer. Service Layer包含构建在HAL之上的一些基础服务，如基于hal_timer实现的svc_actsche (action scheduler)，基于hal_cc2420实现的svc_openmac(MAC协议), svc_opennet(NET协议)，大部分OS的基础功能也将包含在Service中，例如调度可以部分的由action scheduler来承担。在WSN领域常出现的Location, Time Synchronization等常被归入Middleware，但在OpenWSN体系中，它们也将被归入Service。因为，从OOD/OOP的观点看，整个系统System是由多个对象object的实例instance组成的，location, time sync, mac, scheduler等都被设计实现成为一个个独立的小service，而Application，则被简化成为各个service实例的创建和连接（相当于TinyOS nesC中的配置Configuration）。
OpenWSN项目的参考实现，将提供Service和Hal，而Application将由开发者完成，不属于OpenWSN。
因此，从已经完成的工作看，Service中尚不包含完备的调度器，系统中也没有引入Thread/Process之类的概念，当然进程同步与互斥等问题更无从谈起。所以，认为现在的OpenWSN是一个Sensor Node OS为时尚早，但这不排除未来为其加入一个针对sensor应用的RTOS。事实上，目前里面已经包含一份uCOS-II，但uCOS-II用于低功耗sensor node并不合适，真希望uCOS-II的调度能够改进一下。
OpenWSN同TinyOS一样，非常强调组件，但是OpenWSN比TinyOS更强调编程模式，因为在TinyOS中，编程模式已经被固定，而OpenWSN中，编程模式在于程序员自己的掌握，因此灵活性也更大一些。
- Application
- Service
- Hal
- Hardware
Hal means Hardware Abstraction Layer. Service Layer包含构建在HAL之上的一些基础服务，如基于hal_timer实现的svc_actsche (action scheduler)，基于hal_cc2420实现的svc_openmac(MAC协议), svc_opennet(NET协议)，大部分OS的基础功能也将包含在Service中，例如调度可以部分的由action scheduler来承担。在WSN领域常出现的Location, Time Synchronization等常被归入Middleware，但在OpenWSN体系中，它们也将被归入Service。因为，从OOD/OOP的观点看，整个系统System是由多个对象object的实例instance组成的，location, time sync, mac, scheduler等都被设计实现成为一个个独立的小service，而Application，则被简化成为各个service实例的创建和连接（相当于TinyOS nesC中的配置Configuration）。
OpenWSN项目的参考实现，将提供Service和Hal，而Application将由开发者完成，不属于OpenWSN。
因此，从已经完成的工作看，Service中尚不包含完备的调度器，系统中也没有引入Thread/Process之类的概念，当然进程同步与互斥等问题更无从谈起。所以，认为现在的OpenWSN是一个Sensor Node OS为时尚早，但这不排除未来为其加入一个针对sensor应用的RTOS。事实上，目前里面已经包含一份uCOS-II，但uCOS-II用于低功耗sensor node并不合适，真希望uCOS-II的调度能够改进一下。
OpenWSN同TinyOS一样，非常强调组件，但是OpenWSN比TinyOS更强调编程模式，因为在TinyOS中，编程模式已经被固定，而OpenWSN中，编程模式在于程序员自己的掌握，因此灵活性也更大一些。
Saturday, January 13, 2007
Subscribe to:
Posts (Atom)