Contiki：从不起眼的业余爱好者操作系统到博士论题
OSNEWS----还记得Contiki操作系统吗? 几年前它用来在非常古老的家用电脑象Commodore 64 和Apple II上运行网络服务器和网络浏览器。今天Contiki已经长大了，并从业余项目走到了严肃的，用于网络嵌入系统和无线传感器网络研究的嵌入式操作系统。它已经完善了，而且它的创始人Adam Dunkels宣布他的博士论题是Contiki及其组件； Protothread和捆绑有TCP/IP堆栈的 uIP。可能这是不起眼的业余操作系统要走的引人注目的方向，但可能这与它首次发布的时人们所期待的Contiki的方向相去甚远。
Ref
http://osfans-cn.blogspot.com/2007/01/contiki.html
http://www.sics.se/contiki/
http://web4.cs.ucl.ac.uk/staff/E.Rondini/Elisa%20Rondini/Home.html
Pyxos嵌入式控制平台以低成本无线传感器网络为目标应用
原文here
通体上我个人并不看好Pyxos，首先，它缺乏一个容易读且容易记住的好名字，hehe
不过，看看LonWorks/Echelon和ZIgBee两方的争论还是很有意思的，毕竟双方都不无道理
以下内容摘自原文
制造和供应链咨询公司ARC Advisory Group的高级分析师Harry Forbes同意这一点。“我们发现把ZigBee 1.0应用到工厂环境时会出现一些问题，”Forbes说。他最近完成了一份关于ZigBee的报告。
Forbes 在他的报告中写道：“ZigBee最显著的缺点是要为每个ZigBee网络选择单个RF通道，而且限制ZigBee协调器才有通道选择权。工业无线应用倾向于采用这样的无线电技术：即在极其嘈杂且充满变化的多径干扰模式的RF环境中，也能继续工作。出于这个原因，大部分工业无线应用采用跳频扩谱无线电技术。Forbes相信ZigBee联盟将做出某些改变以提高这项性能，但目前它仍是一个大问题。
不过，一些业内人士对Echelon公司借助Pyxos介入无线应用的计划表示了怀疑。
ZigBee联盟尤其提防再出现另一种用于嵌入式控制的专有技术。“ZigBee不同于以前创建的任何控制和传感技术。此前，没有一家开放标准机构（如IEEE）创制出一种简单、极其鲁棒同时又非常低成本的无线数据协议，”飞思卡尔半导体公司的无线技术和战略总监Jon Adams说。飞思卡尔是ZigBee联盟的成员，该联盟开发了利用此无线协议的开放性技术规范。
Jennic是一家基于 IEEE 802.15.4标准的无线微控制器的供应商，其首席执行官Jim Lindop持类似的看法。他表示Pyxos的专有形态以及Echelon公司缺乏开发无线协议的经验会带来一些问题。Lindop特意强调Jennic 公司的技术不涉及较高层协议，既不会同Echelon也不会同ZigBee协议栈有直接的竞争。他敦促Echelon以一种类似ZigBee的方式在 802.15.4标准的上层建立其Pyxos协议。
.
Wednesday, January 31, 2007
2006年度ACM Fellow获奖者列表
click here
attention:
Phillip B Gibbons ( Intel公司 ) won this pride because his work on:
并行计算；数据库；传感器网络
.
attention:
Phillip B Gibbons ( Intel公司 ) won this pride because his work on:
并行计算；数据库；传感器网络
.
Friday, January 26, 2007
Q: 如何用SVN实现OpenWSN的代码管理？
环境建设
Eclipse + Subclipse
Subclipse可以从这里下载
http://subclipse.tigris.org/install.html
一些使用说明
http://gforge.osdn.net.cn/forum/forum.php?thread_id=538&forum_id=521
ps:
for 使用sourceforge的普通用户
在TortoiseSVN的Responsitory Browser中，输入如下的URL：
https://openwsn.svn.sourceforge.net/svnroot/openwsn/trunk
可以浏览当前版本
ps:
关于SourceForge的SVN
After you have registered a new project on "sourceforge", you must enable SVN functionality in admin page before using it. -> it cost me serveral days to find this reason! :(
SourceForge SVN server:
https://openwsn.svn.sourceforge.net
SourceForge Path Responsitory:
/svnroot/openwsn
By default, the anonymous users can have "read" privelidge. Maybe you, the administrator needs to grant write access to the developers in the future.
SourceForge关于SVN的支持文档 Document E09
Eclipse + Subclipse
Subclipse可以从这里下载
http://subclipse.tigris.org/install.html
一些使用说明
http://gforge.osdn.net.cn/forum/forum.php?thread_id=538&forum_id=521
ps:
for 使用sourceforge的普通用户
在TortoiseSVN的Responsitory Browser中，输入如下的URL：
https://openwsn.svn.sourceforge.net/svnroot/openwsn/trunk
可以浏览当前版本
ps:
关于SourceForge的SVN
After you have registered a new project on "sourceforge", you must enable SVN functionality in admin page before using it. -> it cost me serveral days to find this reason! :(
SourceForge SVN server:
https://openwsn.svn.sourceforge.net
SourceForge Path Responsitory:
/svnroot/openwsn
By default, the anonymous users can have "read" privelidge. Maybe you, the administrator needs to grant write access to the developers in the future.
SourceForge关于SVN的支持文档 Document E09
Sunday, January 21, 2007
Q: 如何用SVN获取gforge上的source code?
Subversion相关文档 (英文)这里.
Subversion 匿名访问
svn checkout http://gforge.osdn.net.cn/svn/openwsn
开发者通过DAV访问Subversion
只有项目开发者才能通过这个方法访问SVN。用你的用户名替代developername，并在需要的时候输入你的口令。
svn checkout --username developername http://gforge.osdn.net.cn/svn/openwsn
以上操作可以在Eclipse中进行.
[下载每日快照]
浏览Subversion Tree浏览 SVN tree 可以让你了解项目代码的当前状态。你也可以看到代码的所有历史版本。
.Q: OpenNET设计思想要点(代设计文档)
因为本Group要解决的问题,我们需要网络层协议支持mobile sink结点. 这个要求与孙利民老师06年NSF基金的要求是很接近的. 而现有的大部分协议要么不支持mobile sink特性,要么不支持多个sink node,所以我们不得不自己设计一个.
to be continued
.
to be continued
.
Q:为什么Host上的应用开发优先选择Java?
大家注意到很多子项目的开发都优先推荐Java作为首选语言．这引起了很多年轻朋友们的激烈争辩，熟悉Windows开发的人认为选择C#会好一些，而做嵌入式方面的朋友，又不认可Java在自己这个领域的应用．本文希望能对这个问题作一些回答．
尽管相比于业务而言，语言和工具的选择比较次要，曾有人形象的说：一片树叶到了高手手中，也能成为致命的武器．所以我们不应该过度在意语言的选择．
这种观点有其正确的成分，但是，就一个具体的项目而言，是不能在不同开发环境之间摇摆的．更关键的是，我们当中的大多数人，精力有限，Focus到一种工具或者一种平台上，有助于我们积累经验和交流．
下面是我借鉴google搜索的结果，据说这种做法被某咨询公司用作市场占有率调查，准确度非常高 :)
搜索关键字 数量 搜索关键字 数量
Java语言...... 1,030,000 ...........C#语言 ........ 560,000
Java工具 ..... 2,260,000 ...........C#工具 ..........599,000
Java开发工具 1,030,000 ........C#开发工具.... 759,000
Java应用 ......7,820,000 ...........C#应用 ...........644,000
Java开源 ....1,300,000 .............C#开源 ...........974,000
Java........... 285,000,000 ..............C# ...........70,600,000
结论：C#网络资源大约是Java的 1/4 - 1/10．注意到我为了确认国内的情况，大量用中文搜索词．因为国内号称是Microsoft天下．我希望这个搜索对比能引起程序员朋友们的注意．
我想，这个结果应该能够反映这两种语言在现实世界中的地位．
此外，优选Java作为开发语言还有如下原因：
- Java有强大的开源社区支持，可以提供从操作系统／开发工具直至最终应用全系列的产品．而Windows世界中，开源的精神相对要欠缺很多．
- Java的很多资源可以"Free"获得，而Windows C#等却不可以，例如Java世界中的Eclipse可以做开发环境，非常优秀．这对于降低学术界的工作成本是非常必要的．因此，我们不难发现和理解，国外的大学中开源产品和非windows产品应用极为普遍，我们应该思考为什么．过去，盗版在中国的大学中盛行，而未来，license和费用将成为学术界的一个不得不认真对待的问题．毕竟，作研究的不会有很多钱．在这点上，我们应该学习国外大学．
- 国外学术界有使用Java的传统，网上可以找到大量的学术资源，例如各种算法实现，便于与国外同行作对比．
- Microsoft并不是一家技术上容易合作的公司，但愿我对它的这个评价是错的。
- 嵌入式系统领域Microsoft也不占统治地位，特别是在深度嵌入领域
综上，我希望未来Host上的应用开发能够以Java为主，可以选取Eclipse平台，GUI部分可以用Eclipse提供的SWT和JFace，这样我们可以充分利用国际上已有的资源，并且回避掉许多商业软件的license和费用问题．毕竟，我们不能要求我们的每一个位项目参与者都去买一套商业软件．而在一个公开的项目中采用盗版软件将是非常尴尬的事情．
补记：
参考著名杂志《国际电子工程EETimes》2007.03的一篇文章：
Java在嵌入式系统应用中迎来发展的好时光
说明:虽然现有的worldview客户端程序版本是采用C#开发的,但是我还是非常希望能够看到一个基于Eclipse和Java的新平台出现,这将赋予研究者们更多的资源
.
尽管相比于业务而言，语言和工具的选择比较次要，曾有人形象的说：一片树叶到了高手手中，也能成为致命的武器．所以我们不应该过度在意语言的选择．
这种观点有其正确的成分，但是，就一个具体的项目而言，是不能在不同开发环境之间摇摆的．更关键的是，我们当中的大多数人，精力有限，Focus到一种工具或者一种平台上，有助于我们积累经验和交流．
下面是我借鉴google搜索的结果，据说这种做法被某咨询公司用作市场占有率调查，准确度非常高 :)
搜索关键字 数量 搜索关键字 数量
Java语言...... 1,030,000 ...........C#语言 ........ 560,000
Java工具 ..... 2,260,000 ...........C#工具 ..........599,000
Java开发工具 1,030,000 ........C#开发工具.... 759,000
Java应用 ......7,820,000 ...........C#应用 ...........644,000
Java开源 ....1,300,000 .............C#开源 ...........974,000
Java........... 285,000,000 ..............C# ...........70,600,000
结论：C#网络资源大约是Java的 1/4 - 1/10．注意到我为了确认国内的情况，大量用中文搜索词．因为国内号称是Microsoft天下．我希望这个搜索对比能引起程序员朋友们的注意．
我想，这个结果应该能够反映这两种语言在现实世界中的地位．
此外，优选Java作为开发语言还有如下原因：
- Java有强大的开源社区支持，可以提供从操作系统／开发工具直至最终应用全系列的产品．而Windows世界中，开源的精神相对要欠缺很多．
- Java的很多资源可以"Free"获得，而Windows C#等却不可以，例如Java世界中的Eclipse可以做开发环境，非常优秀．这对于降低学术界的工作成本是非常必要的．因此，我们不难发现和理解，国外的大学中开源产品和非windows产品应用极为普遍，我们应该思考为什么．过去，盗版在中国的大学中盛行，而未来，license和费用将成为学术界的一个不得不认真对待的问题．毕竟，作研究的不会有很多钱．在这点上，我们应该学习国外大学．
- 国外学术界有使用Java的传统，网上可以找到大量的学术资源，例如各种算法实现，便于与国外同行作对比．
- Microsoft并不是一家技术上容易合作的公司，但愿我对它的这个评价是错的。
- 嵌入式系统领域Microsoft也不占统治地位，特别是在深度嵌入领域
综上，我希望未来Host上的应用开发能够以Java为主，可以选取Eclipse平台，GUI部分可以用Eclipse提供的SWT和JFace，这样我们可以充分利用国际上已有的资源，并且回避掉许多商业软件的license和费用问题．毕竟，我们不能要求我们的每一个位项目参与者都去买一套商业软件．而在一个公开的项目中采用盗版软件将是非常尴尬的事情．
补记：
参考著名杂志《国际电子工程EETimes》2007.03的一篇文章：
Java在嵌入式系统应用中迎来发展的好时光
说明:虽然现有的worldview客户端程序版本是采用C#开发的,但是我还是非常希望能够看到一个基于Eclipse和Java的新平台出现,这将赋予研究者们更多的资源
.
我的问题：关于规模 Help
回答了这么多问题
我也有一个问题
目前是否有上千个结点以上应用的真实实验？
或者是哪位朋友曾经做过5000个结点以上的网络仿真？包括ad-hoc领域研究也算上，我希望能取得一些测试数据来验证我对网络的一些想法。
.
我也有一个问题
目前是否有上千个结点以上应用的真实实验？
或者是哪位朋友曾经做过5000个结点以上的网络仿真？包括ad-hoc领域研究也算上，我希望能取得一些测试数据来验证我对网络的一些想法。
.
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项目，因此，有兴趣的开发者自己尝试一下还是有意义的。
.
Saturday, January 20, 2007
Thursday, January 18, 2007
开源，知识产权与商业模式问题
本想简简单单的publish，现在发现open source背后的问题还真不少
看来今后得多拨几个脑细胞关注一下这些问题：开源，知识产权和商业模式
预测：2010年开放源代码将大行其道
http://news.csdn.net/n/20060328/88737.html
陆首群：自由软件被误解 开源不代表全免费
http://news.csdn.net/n/20060123/86003.html
陆首群：建立开源社区开发创新机制
http://www.osdn.net.cn/index.php?option=com_content&task=view&id=257&Itemid=27
.
看来今后得多拨几个脑细胞关注一下这些问题：开源，知识产权和商业模式
预测：2010年开放源代码将大行其道
http://news.csdn.net/n/20060328/88737.html
陆首群：自由软件被误解 开源不代表全免费
http://news.csdn.net/n/20060123/86003.html
陆首群：建立开源社区开发创新机制
http://www.osdn.net.cn/index.php?option=com_content&task=view&id=257&Itemid=27
.
Tuesday, January 16, 2007
转载：如何看待开源软件的知识产权问题
如何看待开源软件的知识产权问题
中国开源软件推进联盟主席 陆首群
中国开源软件推进联盟主席 陆首群
近年来，开源软件在国内外发展很快，正在走向成熟，开始与传统私有软件形成并存的态势，甚至在某些领域内渐成主流。关于开源软件知识产权的纠纷也已浮出水面。在国内，也出现了一些违约、违法的问题，多数人首先在认识上存在误区：如对自由/开源软件性质和特征的界定，对开源软件各类知识产权保护法律规定的强度和范围的理解，对各种开源许可协议的内容或条款以及其解释的认知，在同时执行多项许可证时对各证间冲突处理的把握，对自由软件运动发展中迄今尚存的一些争议问题或在法律上出现的灰色地带在执行中的处置……等，存在着不少混乱认识和错误概念；必须指出，也确有一些造假、侵权、违法的行为和事件。
知识产权是法律赋予人们对智力劳动成果所享有的民事权利。
通常开源软件的知识产权表现在下列五个方面：
1. 著作权(或版权)
2. 专利权
3. 商标权
4. 商业秘密
5. 反不正当竞争
版权
=======
自由/开源软件是一种有版权的软件，自由/开源软件是一种得到许可的软件。自由/开源软件许可协议(或许可证)是其版权实施的延伸。
自由/开源软件采用“左版”(CopyLeft)的概念，虽然其“版权”也应考虑到保护“作者对其作品享有权益”的作用，但由于自由开源运动的本质是发扬 “自由、开放精神”，把重点放在扩大用户的自由和权益方面，放在用户在再传播(或再发布)时得到扩大的许可授权方面，而不是把重点放在对作者特权的保护方面(如表现为不收版权费，任何人都可自由获得、复制、修改、发布原创作品或升级产品的源代码，淡化作者的特权，甚至“模糊”可执行的“版权”，总之由原作者放弃自己的一些知识产权的权利，向公众公布许可等)。它不同于传统“版权”(即“右版”，CopyRight)在“保护作者对作品享有法定特权”方面所表现的刚性化的特征。
自由/开源软件的版权理论上属于原创软件作品的作者(writers、authors、developers)，以及升级软件作品的后续修改者(贡献者Contributors，志愿者Volunteers)，总称为所有者(owners)。
软件许可协议是一种契约和授权方式，是用户合法使用软件作品的一个凭证，相当于软件作品的作者(或所有者，或权利人，或许可人)与用户(或被许可人，或“你”)之间签订一个合同来规定双方当事人在处理软件作品时的权利、义务和责任。
多数人没有注意到开源软件许可的存在，这是因为它不同于传统的书面签字或上网点击那样“接受许可”的方式。开源软件的许可协议是开放的，只要具有相应行为就可“默认”接受的许可；但如“被许可人”不遵守有关许可条件，许可随时会被终止，“被许可人”持有开源软件的权利将自动终止，并需承担违约责任的风险。
BSD、GPL、LGPL、MPL是应用最为普遍的四种典型的自由/开源软件的许可协议(占自由/开源软件全部许可协议的80%以上)。
BSD许可证
========
BSD是一种自由软件，其许可协议为FreeBSD。FreeBSD的主要规定是：
公开BSD的源码，可让你自由获得、复制、修改、分发BSD原创软件作品(源码)；也可在BSD公开的源码基础上衍生你的软件作品。衍生的软件作品(其源码)可以公开，也可不公开。
k在你进行修改或衍生时，必须对哪些是你所获得的BSD原创软件作品所实行的BSD许可证，哪些是你在其上进行的再开发，或生成你自己的许可证，要区分清楚。当你依法处理的作品再分发时，必须作出相应的版权声明，列出相应条件，并表明BSD拒绝担保的声明。对于获得的BSD原创软件作品(源码)的版权(所有权)要明确表示出来，如标明它是加州大学伯克利分校的(
l必须明确，BSD软件版权所有者或贡献者是以“AS IS”(即“保持原样”)方式提供的。在你再开发的衍生作品中，未获得预先特定许可时，不得用伯克利<组织>或贡献者的名字来为你背书；原创作品版权所有者或贡献者均不对你使用、修改、再传播、再发行的BSD原创作品以及你的衍生作品提供任何直接或隐含的担保，同时也不承担相应的责任。
GPL许可
========
多数自由/开源软件采用通用许可协议：GNU/GPL(GNU General Public License，简称GPL)，这是自由软件基金会(Free Software Foundation，FSF)发布的一个软件授权许可证。现有40000个版本/方案(Projects)采用GPLV2。Linus Tovalds将Linux在GUN/GPL下发布，自由软件基金会将Linux作为GUN操作系统的内核。
GPL承认软件作品作者的著作权(所有权)，同时也要求作者必须允许任何人(或用户，或“你”)享有对其作品使用、复制、修改、衍生、发行的自由权利；作为一个限制条件，GPL还要求用户不能改变软件的授权协议(即要将GPL向各级用户传递下去)，要求用户在对该软件作品作出的修改或制作衍生作品并进行再发行时，都要一贯遵守GPL规则；如果执行GPL协议的原创软件是自由软件，则该自由软件经过修改或衍生后的软件也应是自由软件；自由软件在作二进制整体运行时，不允许一部分软件的源码是开源的，另一部分的源码是闭源的，即不允许出现混合源码的现象。GPL协议还规定，不得使用其它许可证进行再发布。
GPL协议是一个开放的协议，是在原创软件作品上实施“使用、复制、修改、衍生、发行”等相应行为时出现的“默认接受”的许可。“默认许可”是执行GPL协议的一大特点，不同于常规签署协议许可的做法。
如果有人对自由/开源软件进行修改、衍生、再发行时使之闭源，从而改变了自由软件的性质和形态，那就违反了GPL协议。有人认为：“在开源领域违反GPL 协议的行为就相当于在传统版权中的‘盗版’性质，同样可称为侵犯知识产权，要予以打击”；也有人认为：“如果违反了GPL协议，GPL协议在其再发行、再传播过程中就自动终止，这时如果还要按‘GPL规则’继续自由索取原创软件源码，而在进行衍生闭源后再发行，将遭致法律风险”。
GPL许可协议是由自由软件基金会制定的。执行GPL规则的软件作品其版权理论上属于该软件作品的“作者”或“开发者”，以及“修改者”或“贡献者”，他们可统称为版权“所有者”。
GPL虽然认承作者对其软件作品的所有权，但由于自由/开源软件是由全球志愿者集体开发的成果，开源社区的组织也较为自由松散，因此其版权或著作权的所有者似乎不可能明确认定为某些个人或某个社区。有人认为：对“自由/开源软件作品来说，迄今尚未被全球软件组织或软件工作者公认是拥有一种可执行的版权”。对linux内核(Kernel)，版权所有者们委托Linus Tovalds作为版权所有者的代表。几天前，OSDL首席执行官Stuart Cohen告诉我，Linus代表内核全体所有者持有的版权是“右版(CopyRight)”，我对此怀疑，似应为“左版(CopyLeft)”。
国内个别企业，根据GPL规则将自由获得的开源软件，在进行修改、衍生后，在再发行自己的版本时，将之变成违反GPL规则的闭源软件，这不但可看成具有负面影响的道德问题，还可能将面临侵犯知识产权遭受法律追诉的风险。
Ubuntu(社区)的Linux发布版是移植、剪裁Debian(社区)的软件资源进行再开发、再发布的成果。今年3月，Ubuntu的创始人Mark Shuttleworth对我说，Ubuntu在向社会、市场提供Linux发布版时，要取得Debian的“授权”(并向Debian支付相应费用)。我想这个“授权”不是“版权”的“授权”，是Ubuntu为了要不断取得Debian的软件资源、纠错升级、设计思想、技术诀窍、运作经验等方面的“支持”而采取的相应措施。
RedHat公司也认为，如果有人对RH发布版进行修改而不遵守GPL规则，则对修改后的软件，RedHat概不负责，不提供支持、服务，包括不提供补丁、升级及其他服务事项。但RedHat对自己的发布版则保证提供及时完善的支持和服务。
LGPL
=======
LGPL，早期称之为“库级-GPL”(Lib-GPL)，后来称之为“轻型-GPL”(Light-GPL)或“宽松-GPL”(Lesser-GPL)，它不同于GPL许可证，在执行LGPL许可证时，允许库函数可以自由地联接到私有软件。
MPL
=======
MPL的版权理论上也属于其原创软件作品的原始开发者与后续修改者、贡献者，通常由Mozilla.org(属Mozilla开源社区)代管。MPL包含四个不同的许可证，在使用中要注意协调好许可证之间的冲突。
专利权
=======
自由/开源软件在版权(包括许可协议)保护方面取得了较为宽松的环境，但自由/开源软件躲不开专利的旋涡。侵犯专利权，不但要追溯开源软件“发行者”的法律责任，还要追溯“使用者”(用户)的法律责任。
众所周知，2005年欧盟没有通过软件(整个软件)的专利法案，美国是支持软件专利最强有力的国家，不能低估美国做法对国际的影响。
对自由/开源软件来说，很多软件程序是由全球志愿者集体编写、合作开发的，其中难免携带“隐性专利”。
自由软件基金会首席律师Eben Moglen(也是我们中国开源软件推进联盟智囊团高级顾问)领导制定了GPL3.0，企图改变“GPL许可证只能解决版权问题，不能解决专利问题”的现状。GPL3.0解决专利问题的重要思路是：沉淀在互联网上绝大多数知识产权是属于开源的，在当代，很少有组织和个人不上网。如果持有隐性专利的组织或个人要状告开源软件发行者专利侵权，那后者也有可能反告前者在互联网上对“开源”的侵权，从而达到权利公平、法律平衡的制约效果。
商标权
=======
在美国有一个非盈利组织“Linux Mark Institute(LMI)”得到Linus Torvalds授权专门保护“Linux”商标的合法使用，年度授权许可费200-5000美元不等。在中国只有在国家商标局一旦批准“Linux” (文字商标)归属Linus Torvalds后，美国LMI才可指派中国境内律师机构来办理此事。
有人曾向美国专利商标局申请把“Open Source”作为商标，但未被批准。
商业秘密
=======
我们认为，自由/开源软件的全部技术是由：以开放源代码所表征的公开的技术，与不公开的工程化实现技术两部分组成。
所谓自由/开源软件的工程化实现技术表现为技术诀窍、熟练技巧、工程经验、隐性技术、测试分析，它着重于改善操作稳定性、优化计算效率、增强灵活扩展性、提高产品质量、催化产品成熟度。
在工程化实现技术中自然包含商业秘密。
反不正当竞争
==========
自由/开源软件在起步发展过程中，正在走向成熟、走上规模，现在还谈不上行业垄断问题，因此基本上也还不存在“不正当竞争”问题，反不正当竞争还有待时日。
Reference
http://www.oss.org.cn/index.php?option=com_content&task=view&id=254&Itemid=2
.
再论OpenWSN的定位
作为一个OpenSource项目,也是需要思考自己定位的, 如何才能更好的发展?
我们认为,在WSN领域, 目前正处于研究高潮期已过,但实际应用尚未大规模出现的产业准备阶段, 因此, 在这样一个带有不确定性的领域中, 我们探索性的作一些准备工作是可行的.
在未来, 有着大量的应用, 也将会有大量的解决方案, 形成如图所示的鱼尾形, 这在本质上是由这个领域所决定的, 客户对性能/成本/功能的需求决定了产品和解决方案的多样性. 那么,我们缺少什么呢? OpenWSN认为我们在丰富的应用和多样的硬件解决方案之间缺乏一个统一的中间层次. 而这个中间层的选择将只会有少数几种选择. OpenWSN将在这个层次多做一些工作. 至于TinyOS,我们希望将其作为OpenWSN中一个可选的服务组件,与之共存, 从而带给客户更多的选择.
.
我们认为,在WSN领域, 目前正处于研究高潮期已过,但实际应用尚未大规模出现的产业准备阶段, 因此, 在这样一个带有不确定性的领域中, 我们探索性的作一些准备工作是可行的.
在未来, 有着大量的应用, 也将会有大量的解决方案, 形成如图所示的鱼尾形, 这在本质上是由这个领域所决定的, 客户对性能/成本/功能的需求决定了产品和解决方案的多样性. 那么,我们缺少什么呢? OpenWSN认为我们在丰富的应用和多样的硬件解决方案之间缺乏一个统一的中间层次. 而这个中间层的选择将只会有少数几种选择. OpenWSN将在这个层次多做一些工作. 至于TinyOS,我们希望将其作为OpenWSN中一个可选的服务组件,与之共存, 从而带给客户更多的选择.
.
Q: 正在进行或者是已经列入计划的子项目清单(subproject list)
子项目清单 OpenWSN SubProject List
今后将逐步开源发布
T1: OpenNODE (by TJU)
OpenWSN Hardware Platform
T2: OpenWSN (by TJU)
OpenWSN Software Platform
T3: OpenWSN SinkService (libsink) (by TJU)
一个运行在Windows Host上的sink service，支持网络中存在多个sink node，支持mobile sink node
T4: WorldView (by TJU)
一个与libsink配套的GUI程序，用于展示通过WSN收集到的数据以及如何与libsink进行交互．
T5: OpenWDE for ARM (Hunting for leader now)
一个基于Eclipse 3.3, Eclipse CDT和WinARM的开源开发环境
集成SkyEye，以方便暂时不具备硬件环境的开发者．
T6: OpenAnalyzer
一个方便开发的小项目，用于侦听空中的数据包(sniffer部分)进行分析(analyzer部分)以及发送测试数据包．
完整的OpenAnalyzer包括一个硬件结点和Host上运行的一个GUI程序．目前可以只考虑cc2420射频芯片．
建议GUI部分作为Eclipse的一个插件，以更好的与集成环境相融合．
T7: 802.15.4 Protocol based on ARM (Hunting for leader now)
基于openwsn/hal提供802.15.4协议的实现，作为OpenWSN的一个可选组件
T8: OpenMESH
为OpenWSN系统增加一套MESH通信协议．不考虑功耗．
T9: Porting Plan: TI MSP430, Atmel Atmega128, cc2430, ... (Hunting for leader now)
向其它硬件平台的移植
T10: Porting Plan (Hunting for leader now)
其它软件平台向OpenWSN的移植
TinyOS, MANTIS
T11: GumTree Integrated (Hunting for leader now)
GumTree是一个优秀的开源软件，完全可代替WorldView子项目，对于一般性的使用已经足够．
但是要和OpenWSN配合使用，还缺乏一个Driver.
T12: WSN Network Measurement
T13: Remote Update 远程自动更新
OpenWSN Related Project：
以下为与OpenWSN相关的项目，属于与OpenWSN平行的应用层项目，目前尚未列入开源计划，只是在这里向大家通报一下我们的一些工作
R1: Mosaic Eye (research only, led by Dr. Jiang, Dr. Wu)
R2: Distributed Problem Solver (research only, led by Dr. Zhang Wei)
R3: Self-Organizing Topology Control (research only, led by Dr. Zhang Wei)
.
今后将逐步开源发布
T1: OpenNODE (by TJU)
OpenWSN Hardware Platform
T2: OpenWSN (by TJU)
OpenWSN Software Platform
T3: OpenWSN SinkService (libsink) (by TJU)
一个运行在Windows Host上的sink service，支持网络中存在多个sink node，支持mobile sink node
T4: WorldView (by TJU)
一个与libsink配套的GUI程序，用于展示通过WSN收集到的数据以及如何与libsink进行交互．
T5: OpenWDE for ARM (Hunting for leader now)
一个基于Eclipse 3.3, Eclipse CDT和WinARM的开源开发环境
集成SkyEye，以方便暂时不具备硬件环境的开发者．
T6: OpenAnalyzer
一个方便开发的小项目，用于侦听空中的数据包(sniffer部分)进行分析(analyzer部分)以及发送测试数据包．
完整的OpenAnalyzer包括一个硬件结点和Host上运行的一个GUI程序．目前可以只考虑cc2420射频芯片．
建议GUI部分作为Eclipse的一个插件，以更好的与集成环境相融合．
T7: 802.15.4 Protocol based on ARM (Hunting for leader now)
基于openwsn/hal提供802.15.4协议的实现，作为OpenWSN的一个可选组件
T8: OpenMESH
为OpenWSN系统增加一套MESH通信协议．不考虑功耗．
T9: Porting Plan: TI MSP430, Atmel Atmega128, cc2430, ... (Hunting for leader now)
向其它硬件平台的移植
T10: Porting Plan (Hunting for leader now)
其它软件平台向OpenWSN的移植
TinyOS, MANTIS
T11: GumTree Integrated (Hunting for leader now)
GumTree是一个优秀的开源软件，完全可代替WorldView子项目，对于一般性的使用已经足够．
但是要和OpenWSN配合使用，还缺乏一个Driver.
T12: WSN Network Measurement
T13: Remote Update 远程自动更新
OpenWSN Related Project：
以下为与OpenWSN相关的项目，属于与OpenWSN平行的应用层项目，目前尚未列入开源计划，只是在这里向大家通报一下我们的一些工作
R1: Mosaic Eye (research only, led by Dr. Jiang, Dr. Wu)
R2: Distributed Problem Solver (research only, led by Dr. Zhang Wei)
R3: Self-Organizing Topology Control (research only, led by Dr. Zhang Wei)
.
Q: 如何参加OpenWSN Project?
在现阶段，OpenWSN Project将主要是一个开发性组织．最新的代码在gforge上可以找到，也可以到sourceforge上下载（要旧一些）．
如果要参与 OpenWSN Project，请到gforge上注册，并且发email给 openwsn@gmail.com，陈述你的特长以及你想做哪一部分．如果可能的话，我们将安排有关的研究人员作为技术顾问．
http://openwsn.gforge.osdn.net.cn
http://openwsn.sourceforge.net
此外,由于一些开发要依赖具体的硬件结点,我们暂时会照顾优选的协作成员.
如果要参与 OpenWSN Project，请到gforge上注册，并且发email给 openwsn@gmail.com，陈述你的特长以及你想做哪一部分．如果可能的话，我们将安排有关的研究人员作为技术顾问．
http://openwsn.gforge.osdn.net.cn
http://openwsn.sourceforge.net
此外,由于一些开发要依赖具体的硬件结点,我们暂时会照顾优选的协作成员.
背景材料：陆首群谈开源软件知识产权保护(2006)
关于自由/开源运动发展和知识产权保护问题，过去Linux创始人Linus Torvalds 曾说，“开源的成功显然也带来了很多新问题，我最担心的是一些非技术性障碍，比如司法方面的挑战、软件专利权等等。软件专利权是一个非常糟糕的东西，不过好在技术行业的大多数人已经开始意识到这一弊病了”。自由/开源软件的版权采用“左版(Copy Left)”的概念，在版权保护方面取得较为宽松的环境，但自由/开源软件躲不开专利的旋涡。在这次峰会上，北京大学张平教授认为，开源领域所有的东西都是开放式的授权，不论是Copy Left 或Copy Right, 不同于传统的知识产权授权，不是one by one的授权。MySQL创始人David Axemark说，软件专利对自由软件构成了威胁，它阻碍了信息共享；我们非常反对软件的专利权，它是维护大公司利益的。
Gartner副总裁James M. Popkin说：开源运动确实有点法律风险。所以，在合作创新愈来愈重要的今天，如何调整窗体底端知识产权适合当今社会创新的状况，减少开源软件遭受专利侵扰的风险，尤为重要。OSDL的专家认为，国际上众多软件公司把自己的专利贡献给OSDL，放在其“专利池(pool)”中，用以遏制开源软件遭遇“专利侵权”的法律风险。IBM专家还介绍了“公开发明网络(open invention network)”这个组织(由IBM、Novell、Philips、Red Hat、Sony、NEC出资共建不谋盈利的企业型组织)，出资购买有关专利，建立专利组合，放在专利公域(commons)中，用以保护Linux生态系统减少其受专利指控的风险；凡是申请加入该组织者，不但可以享受有关专利保护，也要做出承诺，不能利用其专利去诉讼其他Linux开发者、分发商与Linux用户。
2006年1月16日，自由软件基金会(FSF)首席法律顾问Eben Moglen在讨论由他起草的GPL3时说：GPL所关注的主要问题并不是技术细节而是维护用户的自由。我们强调了软件专利对整个软件产业(特别是自由软件)所构成的严重威胁，我们采取的对应策略是：“假若某人利用专利侵权指控某人有关该项专利程序的行为，那么，起诉原告方使用和修改遵守新版GPL规则的自由软件的一切权利立即被终止”。即：“你若控告某个自由软件的用户，你就不得再使用任何自由软件。”试想，在当今互联网时代，谁心里都明白，只要你使用互联网，你就必须使用某些自由软件，完全避开使用自由软件是不可能的。那么，以专利侵权起诉自由软件(使用者)就不是一件简单事情了。
O’Reilly媒体集团编辑Andy Oram对此评论道：“此举把对抗最大法律风险的途径转化为世界所有GPL支持者的团结一致。”对此，也有专家认为，Eben Moglen的上述说法似乎过于空洞。SUN公司首席开源技术官Simon Phipps在会上说，专利实际上是一种社会契约，各国政府在本国实施专利问题上有主导权，中国政府、中国企业对此应有明确认识，希望学习欧盟做法，才能在贯彻世贸规则、保护知识产权、扶持开源运动方面，排除别人滥用“专利权”。
“北京峰会”在8月24-25日召开前早已获知Linus Torvalds本人反对GPL3的提案，他坚持还不如执行GPL2为好。“北京峰会”的组织者会前曾征询GPL3提案起草者、自由软件基金会(FSF)首席法律顾问Eben Morglen对“反对意见”的看法，Eben Morglen先生在回信中未表示具体的看法，只是告之即将公布GPL3草案第二版，可供“北京峰会”研究。 北京的专家认为，新版GPL如果不能获得妥善处理，可能导致开源运动的分裂。
Reference
http://www.yuanma.org/data/2006/1020/article_1686.htm
.
Gartner副总裁James M. Popkin说：开源运动确实有点法律风险。所以，在合作创新愈来愈重要的今天，如何调整窗体底端知识产权适合当今社会创新的状况，减少开源软件遭受专利侵扰的风险，尤为重要。OSDL的专家认为，国际上众多软件公司把自己的专利贡献给OSDL，放在其“专利池(pool)”中，用以遏制开源软件遭遇“专利侵权”的法律风险。IBM专家还介绍了“公开发明网络(open invention network)”这个组织(由IBM、Novell、Philips、Red Hat、Sony、NEC出资共建不谋盈利的企业型组织)，出资购买有关专利，建立专利组合，放在专利公域(commons)中，用以保护Linux生态系统减少其受专利指控的风险；凡是申请加入该组织者，不但可以享受有关专利保护，也要做出承诺，不能利用其专利去诉讼其他Linux开发者、分发商与Linux用户。
2006年1月16日，自由软件基金会(FSF)首席法律顾问Eben Moglen在讨论由他起草的GPL3时说：GPL所关注的主要问题并不是技术细节而是维护用户的自由。我们强调了软件专利对整个软件产业(特别是自由软件)所构成的严重威胁，我们采取的对应策略是：“假若某人利用专利侵权指控某人有关该项专利程序的行为，那么，起诉原告方使用和修改遵守新版GPL规则的自由软件的一切权利立即被终止”。即：“你若控告某个自由软件的用户，你就不得再使用任何自由软件。”试想，在当今互联网时代，谁心里都明白，只要你使用互联网，你就必须使用某些自由软件，完全避开使用自由软件是不可能的。那么，以专利侵权起诉自由软件(使用者)就不是一件简单事情了。
O’Reilly媒体集团编辑Andy Oram对此评论道：“此举把对抗最大法律风险的途径转化为世界所有GPL支持者的团结一致。”对此，也有专家认为，Eben Moglen的上述说法似乎过于空洞。SUN公司首席开源技术官Simon Phipps在会上说，专利实际上是一种社会契约，各国政府在本国实施专利问题上有主导权，中国政府、中国企业对此应有明确认识，希望学习欧盟做法，才能在贯彻世贸规则、保护知识产权、扶持开源运动方面，排除别人滥用“专利权”。
“北京峰会”在8月24-25日召开前早已获知Linus Torvalds本人反对GPL3的提案，他坚持还不如执行GPL2为好。“北京峰会”的组织者会前曾征询GPL3提案起草者、自由软件基金会(FSF)首席法律顾问Eben Morglen对“反对意见”的看法，Eben Morglen先生在回信中未表示具体的看法，只是告之即将公布GPL3草案第二版，可供“北京峰会”研究。 北京的专家认为，新版GPL如果不能获得妥善处理，可能导致开源运动的分裂。
Reference
http://www.yuanma.org/data/2006/1020/article_1686.htm
.
如何保护OpenWSN的发展？－－我关于OpenWSN和知识产权的态度
发起OpenWSN Project并且将其Open Source花了比我预想更多的时间，我不得不考虑仔细回答朋友们的一些提问，也包括要打消我自己的一些顾虑．尽管现在支持的声音很多，但未来怎么走却仍然需要认真规划，艰苦的工作还有不少．而且，在国内，以这样一种方式开展一个项目，成功的例子还比较少．在这点上，我不得不批评国内开源的环境和意识．尽管过去也有诸如SkeEye等一些很成功的项目，但客观地说，他们没有面临象我所要面对的这么多Group．但是，我还是坚持开源，正如我在前面一篇Blog中所说，United, We Stand! 如果我们不能学会协作，那么现有很多高校中WSN Group的成果就会死掉．为什么不贡献出来谋求共赢呢？在WSN基础软硬件平台方面，可以说基本的问题已经在过去被学术界解决，已经不是Research的富矿．我想这点做Research的大部分人都会同意．那么我们每个参与者以个人名义参加并贡献一点自己的努力，应该谈不上技术窃取吧！毕竟，我们采用的都是通用技术．
不过，我最担心的倒不是没有人参与，而是在于体现知识产权保护的专利对这样一个开源项目的阻碍．如果出现这样的事情，将会把这样一个开源项目的成果推到非法的地位，这显然不是我想看到的结果．但是，我们也不能阻止某些人申请专利，因此一个理想的策略是，借助专利制度来保护开源．这个想法来自一些开源组织的做法．因此，我草拟下面几点约定，提起各位参加者注意．
1) 我们的态度：发展是我们的最终目的，专利决不能成为我们技术进步的阻碍！
2) OpenWSN项目允许参加者申请专利，申请者必须尊重OpenWSN成员的劳动．如果该专利的内容用到了OpenWSN的成果并且内容与OpenWSN项目涵盖的内容重复，那么该专利必须免费授权给OpenWSN开发者使用，专利收益只能向非OpenWSN开发者收取．这里的＂免费授权使用＂是要保证开发者和研究人员能够自由获得并免费使用，以保证整个开源项目和自己的非营利性工作顺利进行．这里所说的OpenWSN项目涵盖内容包括硬件层次以上（不含硬件）和应用层以下（不含应用层）的软件，主要包括Hal,各种Driver和一些WSN系统正常运行所需要的基本服务（包括MAC媒介访问, NET路由，Location, Time Synchronization，Sink Service等领域）．开发者针对硬件设计和应用层系统设计可自由申请专利，也不受约束．属于应用层的Data Aggregation, Signal Processing服务也不受此限制．
3) OpenWSN项目允许参加者申请软件著作权，申请者必须尊重OpenWSN成员的劳动. 如果该申请的内容用到了OpenWSN的成果并且内容与OpenWSN项目涵盖的内容重复，那么该著作权必须免费授权给OpenWSN开发者使用，要求同２）
4）所有授权给OpenWSN项目的专利组成专利池，以抵御潜在的专利风险．如果就某项知识产权产生争议，不论结果如何，OpenWSN项目组都有权要求知识产权持有人从其产品和代码中剔除全部与OpenWSN有关的代码．
5) 作为项目发起人，为了保护这个项目不受恶意知识产权的影响，以及考虑到本人陈述上的不严谨之处，我保留变更开源协议licence的权利．但是将坚持"Open Source"并秉承"既往不咎"原则，其中"既往不咎"原则是指一个在协议更新日之前利用了OpenWSN成果的项目不受新协议内容影响，例如已经制造销售的产品．新协议的影响仅对新项目新产品以及老产品的新版本生效．
6)以上约定，自参加者参加该项目后自动生效．
.
不过，我最担心的倒不是没有人参与，而是在于体现知识产权保护的专利对这样一个开源项目的阻碍．如果出现这样的事情，将会把这样一个开源项目的成果推到非法的地位，这显然不是我想看到的结果．但是，我们也不能阻止某些人申请专利，因此一个理想的策略是，借助专利制度来保护开源．这个想法来自一些开源组织的做法．因此，我草拟下面几点约定，提起各位参加者注意．
1) 我们的态度：发展是我们的最终目的，专利决不能成为我们技术进步的阻碍！
2) OpenWSN项目允许参加者申请专利，申请者必须尊重OpenWSN成员的劳动．如果该专利的内容用到了OpenWSN的成果并且内容与OpenWSN项目涵盖的内容重复，那么该专利必须免费授权给OpenWSN开发者使用，专利收益只能向非OpenWSN开发者收取．这里的＂免费授权使用＂是要保证开发者和研究人员能够自由获得并免费使用，以保证整个开源项目和自己的非营利性工作顺利进行．这里所说的OpenWSN项目涵盖内容包括硬件层次以上（不含硬件）和应用层以下（不含应用层）的软件，主要包括Hal,各种Driver和一些WSN系统正常运行所需要的基本服务（包括MAC媒介访问, NET路由，Location, Time Synchronization，Sink Service等领域）．开发者针对硬件设计和应用层系统设计可自由申请专利，也不受约束．属于应用层的Data Aggregation, Signal Processing服务也不受此限制．
3) OpenWSN项目允许参加者申请软件著作权，申请者必须尊重OpenWSN成员的劳动. 如果该申请的内容用到了OpenWSN的成果并且内容与OpenWSN项目涵盖的内容重复，那么该著作权必须免费授权给OpenWSN开发者使用，要求同２）
4）所有授权给OpenWSN项目的专利组成专利池，以抵御潜在的专利风险．如果就某项知识产权产生争议，不论结果如何，OpenWSN项目组都有权要求知识产权持有人从其产品和代码中剔除全部与OpenWSN有关的代码．
5) 作为项目发起人，为了保护这个项目不受恶意知识产权的影响，以及考虑到本人陈述上的不严谨之处，我保留变更开源协议licence的权利．但是将坚持"Open Source"并秉承"既往不咎"原则，其中"既往不咎"原则是指一个在协议更新日之前利用了OpenWSN成果的项目不受新协议内容影响，例如已经制造销售的产品．新协议的影响仅对新项目新产品以及老产品的新版本生效．
6)以上约定，自参加者参加该项目后自动生效．
.
Q: OpenWSN的路线图（未来）
2006 硬件平台 Ver 1.0, Ver 2.0
软件平台 架构完成，hal和部分service完成
2007 硬件平台 Ver 2.1, and 为特定应用开发
软件平台：提供初步稳定的软件，可运行在OpenWSN和GAINZ等主流硬件平台上
提供初步可用的开发环境，完善各种开发测试工具
2008 经过实际考验的可满足工业使用要求的稳定版本
在OpenWSN hal和service基础上，可支持MANTIS和TinyOS
软件平台 架构完成，hal和部分service完成
2007 硬件平台 Ver 2.1, and 为特定应用开发
软件平台：提供初步稳定的软件，可运行在OpenWSN和GAINZ等主流硬件平台上
提供初步可用的开发环境，完善各种开发测试工具
2008 经过实际考验的可满足工业使用要求的稳定版本
在OpenWSN hal和service基础上，可支持MANTIS和TinyOS
Q: OpenWSN的维护由谁进行？发现了Bug如何处理？
请反馈给OpenWSN项目组：
方式1：我们的 mailing list
mailto: openwsn-commits@gforge.osdn.net.cn
方式2：论坛 forum
forum
说明: 有关问题今后将由OpenWSN Community维护。由于我们采用松散的协调，可能无法及时回复或修正。
方式1：我们的 mailing list
mailto: openwsn-commits@gforge.osdn.net.cn
方式2：论坛 forum
forum
说明: 有关问题今后将由OpenWSN Community维护。由于我们采用松散的协调，可能无法及时回复或修正。
Q: OpenWSN自身如何发展？能否长期提供？
OpenWSN由TJU发起，作为开源而存在, 由开源社区提供支持.
作为我们长期研究方向的一个成果, 我们将努力延续之.
对非营利用途，如高校和研究所用做研究用途以及企业前期做产品评估和验证性开发都是完全免费的。
对盈利性用途，OpenWSN项目组希望能通过您的Donate方式获得支持。
OpenWSN鼓励大家在工作中积极使用并反馈自己的成果回来.OpenWSN相信这种方式可以实现共赢.
作为我们长期研究方向的一个成果, 我们将努力延续之.
对非营利用途，如高校和研究所用做研究用途以及企业前期做产品评估和验证性开发都是完全免费的。
对盈利性用途，OpenWSN项目组希望能通过您的Donate方式获得支持。
OpenWSN鼓励大家在工作中积极使用并反馈自己的成果回来.OpenWSN相信这种方式可以实现共赢.
Q: OpenWSN如何处理专利？我是否可以申请专利？
可以申请专利，但是应该遵从一些约束。这些约束自您进入OpenWSN项目自然生效。
详细参见BLOG文章：
如何保护OpenWSN的发展？－－我关于OpenWSN和知识产权的态度
详细参见BLOG文章：
如何保护OpenWSN的发展？－－我关于OpenWSN和知识产权的态度
Q: OpenWSN采用何种License?如果用做商用是否可以？
采用eCos style license, 但是有一些补充约定，详细参见BLOG文章：
如何保护OpenWSN的发展？－－我关于OpenWSN和知识产权的态度
总体上讲，对商用是比较友好的，以不影响OpenWSN本身的发展为限。
如何保护OpenWSN的发展？－－我关于OpenWSN和知识产权的态度
总体上讲，对商用是比较友好的，以不影响OpenWSN本身的发展为限。
作为OpenWSN的使用者，有什么要承担的义务吗？
作为OpenWSN的使用者(不是项目参与者)，有两条需要承担的义务:
一是向项目组反馈您对现有OpenWSN代码的修正和更改（这是eCos style licence的要求），以帮助我们改进之
二是将您从事的项目名称，项目简介和起始时间发给我们 openwsn@gmail.com 并准许我们开列在网站上作为宣传.
一是向项目组反馈您对现有OpenWSN代码的修正和更改（这是eCos style licence的要求），以帮助我们改进之
二是将您从事的项目名称，项目简介和起始时间发给我们 openwsn@gmail.com 并准许我们开列在网站上作为宣传.
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，一块为母板集成，一块为扩展，足以满足绝大部分实际需要．
．
关于WSN硬件平台性能的争议------再谈OpenWSN的定位
目前,还在有人跟我争论WSN的硬件结点应该是选用低功耗MCU芯片还是高功耗ARM芯片的问题. 我想, 这对我们的未来应该不是个问题. 但争论的人多了, 所以作为OpenWSN的发起者, 我也不得不公开的表明我的观点, 也算作是OpenWSN Project的观点.
需求是WSN领域能否获得发展的最终决定因素．客观地说，经过99-05年的发展，特别是众多高校的参与，许多基本问题已经有了解决方案，尽管还不完美，但是毕竟可以满足相当多实际应用的需求．在这个阶段，如果不能满足需求，仍沉迷于纯粹的paper，我想是不合适的．（尽管我本人非常希望重新回去写写paper）
所以满足实际需求是根本，对这一点怎么强调都不为过．OpenWSN不同于TinyOS，TinyOS是学术界用于验证前瞻性idea的测试温床，而OpenWSN尽管目前着重在高校应用，但本质上是为了提供工业界一个Robust的可实际应用的软硬件平台．Crossbow公司自己用于实际应用的产品并没有采用TinyOS不是很能说明这个问题吗？
由此出发，能够满足需求的方案既可，又何必过多的争论它是采用MCU还是ARM呢？特别是争论Atemel好还是TI MSP430好更没有必要，每个产品都各有特点，我们选自己熟悉欣赏的用就好．
客观上看，8bit的MCU在静态功耗上确实比32 bit的ARM要低，ARM再低恐怕也难以达到MSP430的水平，但是就动态功耗而言，情形却未必．一是ARM的处理性能高，对复杂的任务可以争取到短的时间然后就进入休眠，功耗管理是个涉及各个层次的系统级问题，所以单纯争论MCU选型意义并不大．选型的问题在我眼里更多是个人偏好的问题，比如说，我喜欢和熟悉430，那就优先选430好了，没关系．二是为了满足需求对性能的要求，有时我们也不得不放弃MCU而选用更高性能的解决方案．OpenWSN项目开始的时候之所以采用ARM就是为了满足处理image数据的需求，总不能硬性的让我倒退回去，非得采用MCU吧！而且，一个性能较高的方案具有较多的性能余量，方便实验研究，何必在性能上把自己的脖子卡得那么紧呢？Standford 在2006下发过一篇会议文章，叙述了他们基于Atmel ARM7芯片的结点设计，只可惜我们从2005起步，慢了一些．Crossbow官方网站上叙述了Intel在BP轮船上的实验，为了满足信号处理对性能的要求，最后也是放弃MCU，而采用Xscale方案．不也很正常吗？
所以，在今天这样一个WSN发展的新阶段，还去争论这些意义不大．而且，我可以很明确地说，超高性能和超低功耗都可以在实际应用中找到很好的用途，我们不必太经院式的执著于WSN的经典定义．
由此，OpenWSN项目不会约束你究竟采用高性能方案还是低功耗方案，还是二者并存．它只强调两点：一是硬件和软件接口标准化，各家方案尽可能互联互通；二是提供基础软件平台实现，至于怎么用，则完全取决于使用者，满足应用需求即可．所以我们看到，OpenWSN目前的工作几乎不涉及上层应用，而着重在底层基础软件部分．我希望这部分将来能演化成一个独立的Sensor OS．至于对功耗关心的朋友，我希望能够转移你们的注意力在Energy Collection或Energy Generator上面，希望在这方面能有一个OpenWSN的子项目出现．我想这一点意义重大．如果有兴趣的话，可以和我联系．
当然，现阶段的OpenWSN硬件实现是采用了ARM7芯片，相对于绝大多数MCU方案而言，这是一个追求Performance的方案，比如说用于研究Mesh Networks，但这并不排斥那些低功耗方案．就是这样．牢记一切以满足需求为根本出发点．
．
需求是WSN领域能否获得发展的最终决定因素．客观地说，经过99-05年的发展，特别是众多高校的参与，许多基本问题已经有了解决方案，尽管还不完美，但是毕竟可以满足相当多实际应用的需求．在这个阶段，如果不能满足需求，仍沉迷于纯粹的paper，我想是不合适的．（尽管我本人非常希望重新回去写写paper）
所以满足实际需求是根本，对这一点怎么强调都不为过．OpenWSN不同于TinyOS，TinyOS是学术界用于验证前瞻性idea的测试温床，而OpenWSN尽管目前着重在高校应用，但本质上是为了提供工业界一个Robust的可实际应用的软硬件平台．Crossbow公司自己用于实际应用的产品并没有采用TinyOS不是很能说明这个问题吗？
由此出发，能够满足需求的方案既可，又何必过多的争论它是采用MCU还是ARM呢？特别是争论Atemel好还是TI MSP430好更没有必要，每个产品都各有特点，我们选自己熟悉欣赏的用就好．
客观上看，8bit的MCU在静态功耗上确实比32 bit的ARM要低，ARM再低恐怕也难以达到MSP430的水平，但是就动态功耗而言，情形却未必．一是ARM的处理性能高，对复杂的任务可以争取到短的时间然后就进入休眠，功耗管理是个涉及各个层次的系统级问题，所以单纯争论MCU选型意义并不大．选型的问题在我眼里更多是个人偏好的问题，比如说，我喜欢和熟悉430，那就优先选430好了，没关系．二是为了满足需求对性能的要求，有时我们也不得不放弃MCU而选用更高性能的解决方案．OpenWSN项目开始的时候之所以采用ARM就是为了满足处理image数据的需求，总不能硬性的让我倒退回去，非得采用MCU吧！而且，一个性能较高的方案具有较多的性能余量，方便实验研究，何必在性能上把自己的脖子卡得那么紧呢？Standford 在2006下发过一篇会议文章，叙述了他们基于Atmel ARM7芯片的结点设计，只可惜我们从2005起步，慢了一些．Crossbow官方网站上叙述了Intel在BP轮船上的实验，为了满足信号处理对性能的要求，最后也是放弃MCU，而采用Xscale方案．不也很正常吗？
所以，在今天这样一个WSN发展的新阶段，还去争论这些意义不大．而且，我可以很明确地说，超高性能和超低功耗都可以在实际应用中找到很好的用途，我们不必太经院式的执著于WSN的经典定义．
由此，OpenWSN项目不会约束你究竟采用高性能方案还是低功耗方案，还是二者并存．它只强调两点：一是硬件和软件接口标准化，各家方案尽可能互联互通；二是提供基础软件平台实现，至于怎么用，则完全取决于使用者，满足应用需求即可．所以我们看到，OpenWSN目前的工作几乎不涉及上层应用，而着重在底层基础软件部分．我希望这部分将来能演化成一个独立的Sensor OS．至于对功耗关心的朋友，我希望能够转移你们的注意力在Energy Collection或Energy Generator上面，希望在这方面能有一个OpenWSN的子项目出现．我想这一点意义重大．如果有兴趣的话，可以和我联系．
当然，现阶段的OpenWSN硬件实现是采用了ARM7芯片，相对于绝大多数MCU方案而言，这是一个追求Performance的方案，比如说用于研究Mesh Networks，但这并不排斥那些低功耗方案．就是这样．牢记一切以满足需求为根本出发点．
．
来一点不一样的声音---- MANTIS项目
当国内很多Group几乎清一色追随TinyOS方案的时候,我们是不是也应该清醒一些,仔细的思考TinyOS方案的优点和缺点,以及我们自己未来在这个领域中的"定位"?
前面曾经提到过MANTIS,有的朋友问起,所以在这里列出网址,供有兴趣的朋友参考. 在我的观点来看,MANTIS的很多观点和设计都是很值得采纳的. 比如说,它打破了人们认为Multi-thread方式比event driven方式耗电多的误区, 以实证的方式验证了multi-thread方式的有效; 以thread的方式设计了TinyMOS, 可以将TinyOS作为MANTIS的一个线程(或多个线程)运行, 兼容了已有的TinyOS成果.
Colorado大学的MANTIS项目
http://mantis.cs.colorado.edu
虽然暂时还没有列上议事日程,但是我们会考虑将MANTIS构建在OpenWSN项目的Hal和Service上面, 增强OpenWSN的适用范围. 这样也可以让我们少做不少工作.
附: MANTIS Introduction (refer to the homepage of MANTIS project)
The MANTIS Group at CU Boulder has developed an open source, multi-threaded operating system (MOS) written in C for wireless sensor networking platforms. Some key features of MOS:
前面曾经提到过MANTIS,有的朋友问起,所以在这里列出网址,供有兴趣的朋友参考. 在我的观点来看,MANTIS的很多观点和设计都是很值得采纳的. 比如说,它打破了人们认为Multi-thread方式比event driven方式耗电多的误区, 以实证的方式验证了multi-thread方式的有效; 以thread的方式设计了TinyMOS, 可以将TinyOS作为MANTIS的一个线程(或多个线程)运行, 兼容了已有的TinyOS成果.
Colorado大学的MANTIS项目
http://mantis.cs.colorado.edu
虽然暂时还没有列上议事日程,但是我们会考虑将MANTIS构建在OpenWSN项目的Hal和Service上面, 增强OpenWSN的适用范围. 这样也可以让我们少做不少工作.
附: MANTIS Introduction (refer to the homepage of MANTIS project)
The MANTIS Group at CU Boulder has developed an open source, multi-threaded operating system (MOS) written in C for wireless sensor networking platforms. Some key features of MOS:
- developer friendly C API with Linux and Windows development environments
- automatic preemptive time slicing for fast prototyping
- diverse platform support including MICA2, MICAz, and TELOS motes
- eCOS-style license that allows developers to keep their own non-OS code (e.g. applications, drivers), but requires modifications to the core MOS to be given back to the project. Please see the text of the license here for full details. This is not GPL.
- energy-efficient scheduler for duty-cycle sleeping of sensor node
- small footprint (less than 500B RAM, 14KB flash)
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
Q: OpenWSN项目的定位?
OpenWSN项目的定位是什么? 它究竟要干什么?最终要达到一个怎样的目标?它与目前国内外的一些WSN项目是否重合或冲突? 要回答这些问题, 首先需要看看国内外这一领域发展的现状以及存在的问题.
国内外现状
o 在国际范围上,美国的TinyOS项目一花独秀, 但OpenWSN与TinyOS是不太一样的,以后有时间将专门陈述;
o 就企业而言, 如TI, Freescale, Atmel, Microchip等, 都有各自的低功耗近距wireless解决方案, 但是从这些解决方案的内容可以发现,企业所关心的内容与TinyOS偏重研究的策略有很大不同, 很多方案根本与TinyOS不沾边;
o 回到国内, 从04年WSN开始在国内风行到现在,尽管国内做的人看似很多并出了不少文章, 但大多停留在跟踪国外发展并作一些小打小闹的改进. 以硬件平台为例, 尽管也有不少的group可以开发出结点,但大多是模仿国外的方案,属于自己的创新和贡献并不多.
综合国内外的情况以及我们对TinyOS的理解, 我们不难发现这样一些问题:
o 缺乏规范性的WSN基础软件平台.厂商提供的硬件五花八门,导致开发者浪费了大量时间与每种硬件的特性打交道, 这在很多情况下其实是完全没有必要的, 特别是对Research类课题而言, 要求博士生们去学习具体硬件的开发, 从Research降格成为Developing是不合适也是不现实的. 如果能够有一套近似标准的基础软件,能够屏蔽具体硬件的差异, 对推动WSN在高校的研究和简化厂商的开发将会是有益的推动;
o 缺乏标准的可互换的WSN基础硬件平台.
目前国内已经有多家厂商和单位,都可以提供类似的平台,但是每个平台都各有特点.对Research而言,我们没有必要每次都重新搞一个新的平台,但是不同的平台之间却难以互换通用. 最起码的,富于变化的传感器子板和射频子板的接口应该首先规范起来,其次还应该包括电源和能量管理部分,试想,如果我们能够根据研究的需要,自由组合各个模板,当Atmel方案不能满足性能要求的时候能够自由替换为ARM/MIPS等方案,岂不是更加理想? 进一步的,学术界的统一也可进一步影响到公司, 进而形成标准的结点规范.
o TinyOS的定位与工业界的要求有差异.
TinyOS本身还是一个定位在研究和新想法试验的温床角度. 它的一些做法和观点作为超前性研究是可以的,但是要用于实现稳固可靠的工业应用,并不合适. 这是学术界和工业界固有的差异,也是TinyOS的管理者难以权衡的地方. 美国最近对TinyOS/WSN领域观点的分化也验证了这点.
o TinyOS的可移植性差.
TinyOS 1.x几乎是与Mica和Telos硬件平台绑定在一起的,这非常不利于其推广应用. 不是每个人都愿意接受Ateml/Crossbow的方案, 硬件平台千差万别,有成本\性能\熟悉程度\开发方便等各方面的区别, 应将这种硬件平台选择的灵活性赋予客户而不是将他们绑定在少数一两家方案上. 当然, 我们也发现, 2006年下发布的TinyOS 2.0已经接受了人们的批评,在这点上作了很多改进,增加了所支持硬件平台的数量. 顺便说一句, 早期,我们曾尝试TinyOS向OpenWSN硬件平台的移植,但最后放弃了, 待TinyOS 2.0稳定后,我们将在合适的时候, 启动TinyOS 2.0向OpenWSN硬件平台的移植.
o TinyOS的开发环境单一, 且与Atmel / Mica等硬件平台绑定太紧
TinyOS因为从大学首发,所以局限在GNU/Cygwin平台,这是可以理解的. 但是对实际开发而言,几乎没有实际的项目会选择GNU系列作开发工具, TI有CCS, ARM有ADS/Keil/RealView, Microchip有MPLAB等, 每个工具都各有特色,我们很难想象, 对一个实际的项目,一部分是厂商提供工具,而一部分又是GNU系列. 理想的方式是提供一套ANSI的源代码,只需在新的环境下编译即可, 而不应对开发工具作出什么约束. OpenWSN努力做到这一点.
o TinyOS不能保护原有的投资
工业界和中国的大学中存在大量的熟练C Programmar, 也有大量经过实际考验的稳固C代码, 这些都是以后开发项目的重要资源, 抛弃这些是完全没有必要的. TinyOS设计了nesC来开发,强调事件驱动方式降低能耗. 就我个人观点而言, 这都是完全没有必要的事情. 我们不可能大量培训我们的C程序员去开发nesC,尽管对善于学习的程序员而言这并非难事. 借用Java领域常见的一个观点, C是语言, 而nesC所强调的接口/组件(Interface/Component)和事件驱动(Event Driven)都应该是编程模式(Programming Pattern),我们应训练我们的开发者掌握这些编程模式,而不是设计一个新的语言. nesC是学术界的尝试,但不论是TI/Chipcon还是Freescale,我从未听到他们强调nesC对于开发的意义. 而且,Event Driven模式相比于目前常用的Multi-thread模式是不是就可以更好的节能, 也并未达成一致意见. Colorado大学计算机系的MANTIS操作系统我就非常喜欢,它就是一个采用了MultiThread方式的Sensor Node OS,顺便说一下,如果有人能够Port MANTIS到OpenWSN的话,我会非常开心. 不仅如此, TinyOS过分强调了事件编程, Event Driven Programming Pattern对付很多问题也是很麻烦的. 在我的眼里, C/C++语言已经足够承担上述指责, 只要我们灵活应用各种编程模式.
o 国外产品价格偏贵
相比于国内各个group实际情况而言, 国外产品的价格还是贵了点. 限于经费原因,很多学校并不能投入大量经费购买国外的结点, 坦率说,买多了也是浪费. 特别是对做研究的主力博士生而言, 也不可能要求他们在短时间内去把整套系统做出来. 而很多试验又要求有一定的规模,所以我们现在很多group的研究不得不停留在算法仿真层面,也是很无可奈何. OpenWSN项目希望能改变这种现状.
最后,还有一个是我们国内的缺点,就是国内对TinyOS中广泛使用的各种开源工具不熟悉, 也妨碍了国内在TinyOS平台上作开发的激情.
因此,我们希望OpenWSN项目能够:
定位在基础软硬件平台(以基础软件平台为主), 创立相应的开放规范,提供可方便移植的参考实现,以开源方式推动国内这一领域的发展. 而OpenWSN的参考实现本身,就将是一套能够满足实际需求并具有工业强度的软件组件集合,可以拿来直接应用.
开放的规范意味着组件化和可互换性, 而且赋予每个Group在力所能及时遵照规范开发自己产品的自由,当然也可以为了进度和可靠性购买现成的产品; 参考实现方便了应用软件的开发, 毕竟,每个Group完全从头做起是没有必要的,如果小小的代价可以换来2个月的进度提前, 何乐而不为? 而开源而是延续我们理想的精神,以群众运动的方式加速它的成熟与发展. 套用西方的一句谚语, United, We Stand!
国内外现状
o 在国际范围上,美国的TinyOS项目一花独秀, 但OpenWSN与TinyOS是不太一样的,以后有时间将专门陈述;
o 就企业而言, 如TI, Freescale, Atmel, Microchip等, 都有各自的低功耗近距wireless解决方案, 但是从这些解决方案的内容可以发现,企业所关心的内容与TinyOS偏重研究的策略有很大不同, 很多方案根本与TinyOS不沾边;
o 回到国内, 从04年WSN开始在国内风行到现在,尽管国内做的人看似很多并出了不少文章, 但大多停留在跟踪国外发展并作一些小打小闹的改进. 以硬件平台为例, 尽管也有不少的group可以开发出结点,但大多是模仿国外的方案,属于自己的创新和贡献并不多.
综合国内外的情况以及我们对TinyOS的理解, 我们不难发现这样一些问题:
o 缺乏规范性的WSN基础软件平台.厂商提供的硬件五花八门,导致开发者浪费了大量时间与每种硬件的特性打交道, 这在很多情况下其实是完全没有必要的, 特别是对Research类课题而言, 要求博士生们去学习具体硬件的开发, 从Research降格成为Developing是不合适也是不现实的. 如果能够有一套近似标准的基础软件,能够屏蔽具体硬件的差异, 对推动WSN在高校的研究和简化厂商的开发将会是有益的推动;
o 缺乏标准的可互换的WSN基础硬件平台.
目前国内已经有多家厂商和单位,都可以提供类似的平台,但是每个平台都各有特点.对Research而言,我们没有必要每次都重新搞一个新的平台,但是不同的平台之间却难以互换通用. 最起码的,富于变化的传感器子板和射频子板的接口应该首先规范起来,其次还应该包括电源和能量管理部分,试想,如果我们能够根据研究的需要,自由组合各个模板,当Atmel方案不能满足性能要求的时候能够自由替换为ARM/MIPS等方案,岂不是更加理想? 进一步的,学术界的统一也可进一步影响到公司, 进而形成标准的结点规范.
o TinyOS的定位与工业界的要求有差异.
TinyOS本身还是一个定位在研究和新想法试验的温床角度. 它的一些做法和观点作为超前性研究是可以的,但是要用于实现稳固可靠的工业应用,并不合适. 这是学术界和工业界固有的差异,也是TinyOS的管理者难以权衡的地方. 美国最近对TinyOS/WSN领域观点的分化也验证了这点.
o TinyOS的可移植性差.
TinyOS 1.x几乎是与Mica和Telos硬件平台绑定在一起的,这非常不利于其推广应用. 不是每个人都愿意接受Ateml/Crossbow的方案, 硬件平台千差万别,有成本\性能\熟悉程度\开发方便等各方面的区别, 应将这种硬件平台选择的灵活性赋予客户而不是将他们绑定在少数一两家方案上. 当然, 我们也发现, 2006年下发布的TinyOS 2.0已经接受了人们的批评,在这点上作了很多改进,增加了所支持硬件平台的数量. 顺便说一句, 早期,我们曾尝试TinyOS向OpenWSN硬件平台的移植,但最后放弃了, 待TinyOS 2.0稳定后,我们将在合适的时候, 启动TinyOS 2.0向OpenWSN硬件平台的移植.
o TinyOS的开发环境单一, 且与Atmel / Mica等硬件平台绑定太紧
TinyOS因为从大学首发,所以局限在GNU/Cygwin平台,这是可以理解的. 但是对实际开发而言,几乎没有实际的项目会选择GNU系列作开发工具, TI有CCS, ARM有ADS/Keil/RealView, Microchip有MPLAB等, 每个工具都各有特色,我们很难想象, 对一个实际的项目,一部分是厂商提供工具,而一部分又是GNU系列. 理想的方式是提供一套ANSI的源代码,只需在新的环境下编译即可, 而不应对开发工具作出什么约束. OpenWSN努力做到这一点.
o TinyOS不能保护原有的投资
工业界和中国的大学中存在大量的熟练C Programmar, 也有大量经过实际考验的稳固C代码, 这些都是以后开发项目的重要资源, 抛弃这些是完全没有必要的. TinyOS设计了nesC来开发,强调事件驱动方式降低能耗. 就我个人观点而言, 这都是完全没有必要的事情. 我们不可能大量培训我们的C程序员去开发nesC,尽管对善于学习的程序员而言这并非难事. 借用Java领域常见的一个观点, C是语言, 而nesC所强调的接口/组件(Interface/Component)和事件驱动(Event Driven)都应该是编程模式(Programming Pattern),我们应训练我们的开发者掌握这些编程模式,而不是设计一个新的语言. nesC是学术界的尝试,但不论是TI/Chipcon还是Freescale,我从未听到他们强调nesC对于开发的意义. 而且,Event Driven模式相比于目前常用的Multi-thread模式是不是就可以更好的节能, 也并未达成一致意见. Colorado大学计算机系的MANTIS操作系统我就非常喜欢,它就是一个采用了MultiThread方式的Sensor Node OS,顺便说一下,如果有人能够Port MANTIS到OpenWSN的话,我会非常开心. 不仅如此, TinyOS过分强调了事件编程, Event Driven Programming Pattern对付很多问题也是很麻烦的. 在我的眼里, C/C++语言已经足够承担上述指责, 只要我们灵活应用各种编程模式.
o 国外产品价格偏贵
相比于国内各个group实际情况而言, 国外产品的价格还是贵了点. 限于经费原因,很多学校并不能投入大量经费购买国外的结点, 坦率说,买多了也是浪费. 特别是对做研究的主力博士生而言, 也不可能要求他们在短时间内去把整套系统做出来. 而很多试验又要求有一定的规模,所以我们现在很多group的研究不得不停留在算法仿真层面,也是很无可奈何. OpenWSN项目希望能改变这种现状.
最后,还有一个是我们国内的缺点,就是国内对TinyOS中广泛使用的各种开源工具不熟悉, 也妨碍了国内在TinyOS平台上作开发的激情.
因此,我们希望OpenWSN项目能够:
定位在基础软硬件平台(以基础软件平台为主), 创立相应的开放规范,提供可方便移植的参考实现,以开源方式推动国内这一领域的发展. 而OpenWSN的参考实现本身,就将是一套能够满足实际需求并具有工业强度的软件组件集合,可以拿来直接应用.
开放的规范意味着组件化和可互换性, 而且赋予每个Group在力所能及时遵照规范开发自己产品的自由,当然也可以为了进度和可靠性购买现成的产品; 参考实现方便了应用软件的开发, 毕竟,每个Group完全从头做起是没有必要的,如果小小的代价可以换来2个月的进度提前, 何乐而不为? 而开源而是延续我们理想的精神,以群众运动的方式加速它的成熟与发展. 套用西方的一句谚语, United, We Stand!
Q: 如何理解OpenWSN Project所倡导的开放?
OpenWSN项目所倡导的开放有两重含义,一是开源,二是标准化.
开源主要是针对软件平台而言, OpenWSN提供所有底层源代码,方便您的开发工作,同时,OpenWSN也鼓励您将OpenWSN移植到自己的硬件平台上并将成果回馈给OpenWSN项目, 您可以按照OpenWSN license的要求持有自己的专有代码并用于商业目的. 特别强调的一点是, OpenWSN重在基础软件平台部分, 不涉及在此平台上开发的各种应用软件.
标准化主要是针对硬件平台而言. 尽管WSN领域硬件平台的多样化是不争的事实,仅常见的方案就有Atmel, ARM, Freescale, TI/Chipcon, Crossbow, Microchip等公司提供, 所以客观上希望统一硬件平台是不现实的. 但是,对硬件平台做出适当的约束, 特别是在传感器\射频通信等模块的接口方面统一起来是非常有意义的,至少在现阶段可以很大程度上促进产品互换,节省社会资源,推动这一领域的发展.
开源主要是针对软件平台而言, OpenWSN提供所有底层源代码,方便您的开发工作,同时,OpenWSN也鼓励您将OpenWSN移植到自己的硬件平台上并将成果回馈给OpenWSN项目, 您可以按照OpenWSN license的要求持有自己的专有代码并用于商业目的. 特别强调的一点是, OpenWSN重在基础软件平台部分, 不涉及在此平台上开发的各种应用软件.
标准化主要是针对硬件平台而言. 尽管WSN领域硬件平台的多样化是不争的事实,仅常见的方案就有Atmel, ARM, Freescale, TI/Chipcon, Crossbow, Microchip等公司提供, 所以客观上希望统一硬件平台是不现实的. 但是,对硬件平台做出适当的约束, 特别是在传感器\射频通信等模块的接口方面统一起来是非常有意义的,至少在现阶段可以很大程度上促进产品互换,节省社会资源,推动这一领域的发展.
Q: OpenWSN常用资源网址
Homepage of OpenWSN Project
http://www.openwsn.net
this site contains the necessary Internet links.
Source Code and Project Management
http://gforge.osdn.net.cn (active and newest)
http://openwsn.sourceforge.net (mirror of gforge, contains stable versions)
Dr. Zhang's Informal Blog on OpenWSN Project
http://openwsn.blogspot.com
Forum
http://www.nabble.com/openwsn-f15619.html
Wiki on Project OpenWSN (not stable yet! I hope this can be settled soon)
http://wiki
邮件列表 Mailing list
openwsn-commits@gforge.osdn.net.cn
邮件列表信息在：
http://gforge.osdn.net.cn/mailman/listinfo/openwsn-commits
邮件列表管理：
http://gforge.osdn.net.cn/mailman/admin/openwsn-commits
attention: the newest code will be placed on gforge.osdn.net.cn, because it is much faster than sourceforge. The project leader will transfer the released version from gforge to sourceforge occasionaly. so you should turn to gforge to get the new versions.
.
http://www.openwsn.net
this site contains the necessary Internet links.
Source Code and Project Management
http://gforge.osdn.net.cn (active and newest)
http://openwsn.sourceforge.net (mirror of gforge, contains stable versions)
Dr. Zhang's Informal Blog on OpenWSN Project
http://openwsn.blogspot.com
Forum
http://www.nabble.com/openwsn-f15619.html
Wiki on Project OpenWSN (not stable yet! I hope this can be settled soon)
http://wiki
邮件列表 Mailing list
openwsn-commits@gforge.osdn.net.cn
邮件列表信息在：
http://gforge.osdn.net.cn/mailman/listinfo/openwsn-commits
邮件列表管理：
http://gforge.osdn.net.cn/mailman/admin/openwsn-commits
attention: the newest code will be placed on gforge.osdn.net.cn, because it is much faster than sourceforge. The project leader will transfer the released version from gforge to sourceforge occasionaly. so you should turn to gforge to get the new versions.
.
Wednesday, January 03, 2007
写在岁末年初
时间过得如此之快，眨眼之间又是新的一年
尽管平时的工作很忙，但是想想我的Blog不应如此荒芜，还是应该过来浇点水 ^-^
过去的工作小结，算是向朋友们报告一下进度
－Ver 1.0：06上完工，采用LPC214x系列 ARM 7 + Chipcon 2420方案，不带Sensor，未公开发布。同时，花了很大力气在射频driver上；
－Ver 2.0: 11月份完工，基本方案同上，规范了接口，支持的sesnor包括震动，温度，光敏，电量检测（中科院的产品不带电量检测，说实话，我是很失望的），以及一个形变测量前端（传感器需要另外接），体积也大大缩小，比两节五号电池大不了多少。同时，投入了更大力量设计和实现软件部分，初步确立了软件架构，估计以后也不会大动了，自己还是比较满意的。希望能够找到合适人接手去生产之，否则，过去的一切心血就白费了，毕竟，截止到目前为止，还是以面向研究的平台开发为主，缺乏实际项目的支撑，将努力在新的一年里解决这几个关键问题。
尽管平时的工作很忙，但是想想我的Blog不应如此荒芜，还是应该过来浇点水 ^-^
过去的工作小结，算是向朋友们报告一下进度
－Ver 1.0：06上完工，采用LPC214x系列 ARM 7 + Chipcon 2420方案，不带Sensor，未公开发布。同时，花了很大力气在射频driver上；
－Ver 2.0: 11月份完工，基本方案同上，规范了接口，支持的sesnor包括震动，温度，光敏，电量检测（中科院的产品不带电量检测，说实话，我是很失望的），以及一个形变测量前端（传感器需要另外接），体积也大大缩小，比两节五号电池大不了多少。同时，投入了更大力量设计和实现软件部分，初步确立了软件架构，估计以后也不会大动了，自己还是比较满意的。希望能够找到合适人接手去生产之，否则，过去的一切心血就白费了，毕竟，截止到目前为止，还是以面向研究的平台开发为主，缺乏实际项目的支撑，将努力在新的一年里解决这几个关键问题。
Subscribe to:
Posts (Atom)