Zigbee读书日记(八).docVIP

原文链接: /forum.php?mod=viewthreadtid=389 Zigbee读书日记（八） --freakz移植之物理层 Freakz是什么?Contiki又是什么？这和我们现在学习的Zigbee有什么关系？也许看到这篇文章的读者有不少对此还一无所知。如果您在学习Zigbee，相信对TI的CC系列IC应该有所了解吧，那您肯定听过ZStack和OSAL这两个词，ZStack是TI公司按照Zigbee标准实现的一个Zigbee协议栈，而OSAL则为ZStack所使用的“操作系统”。如果这两个概念搞得清楚，相信freakz和contiki就不难理解了。其实，freakz也是一个zigbee协议栈，相应的contiki则为freakz所使用的操作系统。　　[注：本文源自--“飞比”Zigbee论坛，为尊重劳动者成果，如需转载请保留此行，并通知作者]　　那我们为什么不直接用ZStack+OSAL，而费这么大的劲用freakz+contiki呢？其实原因很简单，不同于ZStack的“应用层开源”，freakz是一个彻底的开源zigbee协议，而contiki也是一个彻底的开源操作系统，而且这个操作系统短小精悍，非常适合“物联网”时代的MINI型设备，同时，这套系统在全球已经拥有了众多的支持与使用者，已经开发了非常多的应用，甚至有像IPV6这么强大而且的应用，可以在其官方网站上下载到全套的代码！　　相对于另外一个开源的WSN(Wireless Sensor Networking，无线传感网)操作系统TinyOS来讲，contiki的代码全部为C语言写成，用GCC进行编译，对广大应用C语言多年的开发者来说，减少了学习另外一种语言与编译平台所带来的时间花费。同时，我们考虑到很多开发者，尤其是初学者，对Linux+GCC的平台也并不熟悉，所以，我们选用了IAR这个极其稳定、易用的编译平台，对contiki进行移植。您可以在其官方网站上下载试用版进行学习，对于商业用途的开发，请您购买正版。　　至于我们为什么最终选择了freakz而不是别的开源协议，主要是因为这是目前我们找得到的相对最完整的，也是代码写得比较规范的一套协议。不过，为什么我们总得用别人的？这个问题确实值得思考！！　　不扯远了，回到主题上来。目前这个项目，断断续续已经做了将近两个月了，采用的思路是，从操作系统的核心到周边，再到基本的物理层和MAC层通讯一点点地进行修改和编译，理解一点就修改一点，成功后再继续下一步。到现在为止，已经实现了节点1应用层发送一个字符串“feibit”，MAC层按照协议规范进行编码，由物理层发送出去；节点2收到信息后，完成上述的反过程，直至收到字符串“feibit”，而且整个过程是在contiki系统框架内完成的。　　这个时候，我在犹豫一个问题。实际上，freakz已经用“软件模拟器”实现了MAC层以上的协议内容，并且在一个基于AVR的硬件平台上进行了移植。理论上讲，现在我们已经在FB2530EB的平台上基本实现了CC2530的MAC层通讯，与上层对接后实现协议栈的基本功能应该不是太难了。但反复考虑后，我觉得这不是一个好的方法。也许现在一股脑地把所有的代码都加进来，解决一些warning与error后，我可以骄傲地跟人讲，我实现了开源zigbee移植。但这并不是我的目的。我希望论坛有一个“开放”跟“踏实”的氛围，也希望自己跟论坛里的每一位学习者有一个不急功近利的心态。我们学习的目的不是跟随，而是创造！　　在freakz移植的过程中，我有一个感受，虽然我们做的只是“移植”而不是原创，但这种学习方式比由上而下的方式来得有效，并且深入得多。当然，让一个完全对zigbee的基本概念与功能完全不懂的初学者来说，这可能也不是个最好的方法。所以，我觉得这两种方式应该结合起来，“what”与“how”这两个问题采用由上而下的方式，而“why”这个问题，就采用由下而上，从零搭建的方式，当然前提要是开源！而且我希望后面的事情，不是由我来写，大家来读，而是希望有更多的人能参与进来。哪怕我把整个协议栈重新写了一遍，对于读者来讲，并不一定能对其中的重点内容有深刻的体会。而且，如果能有更多的人参与，大家共同讨论，共同进步，这样的学习效率是单兵作战所无法比拟的！　　所以，在FB2530EB开发板发行之前，移植的工作准备暂时告一段落。我会把这几天物理层与MAC层移植的相关内容，以笔记的形式写出来，作为一个起点。有兴趣的朋友可以在此基础上继续一点点地理解，一点点地移植。同时也希望我们能有组织、有规划地去实现一个共同的目标！ 在前面的笔记（五）中，我们已经对物理层的基本概念做了详细的介绍。本篇可作为其理论知识的实践篇，从一个基本的字符串“feibit”