nesC编程迷你教程解读.docx

nesC编程迷你教程解读.docx

《nesC编程迷你教程解读.docx》由会员分享，可在线阅读，更多相关《nesC编程迷你教程解读.docx（38页珍藏版）》请在冰豆网上搜索。

nesC编程迷你教程解读

nesC编程迷你教程

寿颜波@Université de Franche-Comté, France

内容目录

1引子1

2基础概念1

2.1接口（interface）1

2.2命令与事件（CommandandEvent）3

2.3模块与配置（ModelandConfiguration）3

2.3.1模块3

2.3.2配置6

2.3.3可以提供接口的配置组件7

2.3.4任务和事件10

3工作环境12

4编程开发13

4.1Blink13

4.2TempRadio15

4.2.1数据的采集与发送16

4.2.2数据的接收23

5TOSSIM仿真29

5.1使用TOSSIM编译nesC程序29

5.2捕捉、生成运行记录30

5.3仿真30

5.4运行中的变量值32

6结束语33

1引子

目前在研究领域有多款针对无线传感器网络开发的操作系统，其中最为著名的项目之一便是TinyOS。

它最早由美国Berkeley大学负责开发和维护，并且支持多种传感器平台，例如在研究领域广泛使用的mica系列传感器节点和telos系列。

在本教程的编写过程当中，我们统一使用Crossbow公司开发的telosb节点。

TinyOS完全由nesC编写，nesC全名NetworkEmbeddedSystemC，它可以被看作是C语言的近亲，在语法上和C语言有非常多的相似之处，如果你有C语言的编写基础，那么针对nesC的学习就会变得轻松很多。

nesC主要是为事件驱动编程而设计的，它也是我们开发TinyOS应用程序的主要编程语言。

本文档的目的在于向读者展示TinyOS的基本运作模式，并且让读者可以在最短的时间掌握TinyOS下程序开发的要领。

而且在编写过程当中，作者假设读者已经具备了基本的编程经验。

如果你需要更为详细的nesC参考资料，可以查阅TinyOS官方网站上面的教程，或者阅读PhilipLevis编写的TinyOSProgrammingManual。

因为已经很久没用使用中文编写文档，所以文档中的一些语句可能显得生硬。

而且因为时间关系，文档中肯定还有不少的错误。

如对你的学习过程造成困扰，再次先表示歉意。

2基础概念

在开始正式学习nesC编程之前，我们需要先学习nesC的几个比较重要的概念。

相对于其他编程模式，例如面向过程编程和面向对象编程，事件驱动编程，或者是面向事件编程显得比较特别，尤其是在无线传感器网络当中。

因为无线传感器节点的程序储存空间十分有限，而且通常采用电池供电，所以要求我们的程序必须短小、精炼、高效。

2.1接口（interface）

一个完整的nesC程序是由一系列组件构成的，这些组件彼此之间通过事先定义好的接口进行沟通，从而协调程序各部分间的合作。

与Java语言相似，在一个接口的内部，我们定义一系列相关的方法，也就是相当于C语言中的函数。

在下面的代码中我们给出一个简单的例子，Read接口。

该接口主要用来读取某一个环境数据（温度、湿度等）。

它只包含两个函数，用于读取数值的read和表示读取结束的readDone。

我们可以看到接口内的函数只包含了函数的声明，但是并不包含函数体，也就是说它们是空的！

接口需要被某一个nesC组件实现才能具备真正的执行能力，如果一个接口没有被实现，那它就不具备实用价值。

负责实现某一个接口的nesC组件称之为该接口的提供者，而需要使用该接口的程序组件，则成为这一组件的使用者。

当我们开发一个nesC程序的时候，我们需要首先考虑以下几个问题：

•我们的程序需要实现哪几种功能？

•哪些功能是可以通过使用TinyOS自带的接口来实现的？

•实现这些接口的组件又是哪些？

•哪些功能是需要定义属于我们自己的接口？

同一个接口可以由不同的组件来实现，例如我们此前提到过的，关于环境数据读取的问题。

我们知道我们需要通过使用Read接口来读取温度，但是如果传感器平台不同，Read接口的提供者就未必相同。

例如telosb节点和micaz节点未必使用同一组件来提供Read接口。

2.2命令与事件（CommandandEvent）

在此前的例子当中，有的读者可能已经注意到，read和readDone两个函数采用两个不同的前置关键字，command和event。

命令和事件是nesC中两种函数类型。

命令类型的函数由接口的提供者负责实现。

有别于C语言中的函数呼叫，我们需要等待函数运行结束，才能继续执行接下去的指令。

在TinyOS中，我们推崇一种叫做Split-Phase的程序运作模式，也就是说将一项任务分为任务的投递、执行和反馈三个步骤。

当我们呼叫一个命令时，该项任务就被投递到一个任务执行序列当中，等待逐一被系统执行。

而主进程不会被锁死，可以继续执行接下去的指令。

当此投递的任务被成功执行时，任务会返回一个事件给主进程，以告知任务运行结束。

相反事件类型的函数则由接口的使用者负责实现，因为在接口的使用者呼叫一个命令之后，使用者需要等待命令返回的事件，并且在事件函数内对返回的数据进行处理。

关于nesC编程中事件和任务的控制，将在稍后的小节中介绍。

我们举一个比较具体点的例子，某一个nesC程序有两个组件构成，A和B。

A（使用者）想读取环境温度，所以它就需要使用接口Read，而Read接口由B组件来实现，B就是接口的提供者。

A呼叫接口Read的read命令，然后继续忙自己的工作。

B通过接口收到该呼叫，开始调用传感器节点上的硬件设备读取温度。

一旦温度读取工作完成，B就发送一个readDone事件给A。

A作为接口Read的使用者，需要实现接口内的readDone事件。

在该事件内部，A取得读取的温度值，然后再计划下一步的工作。

2.3模块与配置（ModelandConfiguration）

nesC程序由两种类型的组件构成：

模块和配置。

2.3.1模块

在模块类组件主要包含了对它所操作接口的实现。

如果一个模块使用了某个接口，则需要实现该接口内的所有事件函数，如果它提供某个接口，则需要实现该接口的所有命令函数。

下面是例程Blink中的BlinkC模块的源代码，其主要功能是让传感器节点上的三枚发光二极管（LED）按照不同的频率闪烁。

•04-11行：

模块的声明。

我们可以看到该模块总共需要使用5个接口，其中3个计时器（Timer）接口。

每个计时器控制一枚LED。

Leds接口中包含了我们点亮和熄灭LED所需的命令函数，而Boot接口中则负责控制传感器节点的启动。

•12-38行：

所使用的接口的事件函数的实现。

•14-19行：

在一般情况下，booted是程序接收到的第一个事件，表示我们的传感器节点已经正常启动。

通常我们在booted事件函数内放置初始化代码。

对于Blink程序，当节点启动的时候，我们需要通过呼叫startPeriodic命令函数来初始化三个计时器，让它们以不同的时间间隔开始计时。

注意呼叫一个命令函数，我们需要使用call关键字。

•21-25行，27-31行，33-37行：

针对三个计时器的fired事件函数的实现。

当

timer0被激活时，我们变更0号LED的状态（点亮或者熄灭）。

timer1和timer2同理。

就目前而言，当读者尝试去理解这段程序时，不要太过拘泥于一些语法上的细节，把注意力集中在程序的总体构成上。

2.3.2配置

在此前的一个小节当中，我们列举出了BlinkC模块所需的各种接口。

正如此前我们所说的，一个接口必须被实现，也就是说必须找到提供该接口的组件（提供者），不然该接口无法真正接受任何工作。

所以一个完整的nesC程序还需要另外一类组件：

配置，主要负责将接口的使用者和提供者紧密联系起来。

我们可以看到程序的开头始终是组件的声明，在这段程序中，我们声明了一个配置类型的组件，称之为BlinkAppC。

该组件不提供任何新的接口（没错，一个配置组件也可以提供接口，但是提供的方式方法有别于模块组件，我们将在接下来的小节中学习）。

•03-06行：

列举出了Blink程序所需要的各种组件，其中自然也包括了BlinkC模块。

MainC组件和LedsC组件分别提供了Boot接口和Leds接口。

TimerMilliC提供了Timer计时器接口，因为我们需要3个计时器，所以我们需要用as关键字对他们进行重命名，分别为Timer0，Timer1和Timer2。

•08-13行：

建立起接口使用者和提供者之间的联系。

例如第08行，我们读作“BlinkC模块中的Blink接口由MainC组件提供”。

第13行则是一种简化的书写，因为LedsC组件只提供一个叫做Leds的接口，所以nesC可以自动识别。

在建立起接口使用者和提供者之间的联系之后，我们的程序就可以编译了，因为MainC，LedsC和TimerMilliC三个组件已经包含在TinyOS的发行版当中，无需再重新编写。

一个完整的nesC程序包含至少一个配置组件。

2.3.3可以提供接口的配置组件

通常情况下，尤其是在小型的程序当中，在配置类组件内部，我们只做对接口使用者和提供者的连接。

但是在某些特定的情况下，我们需要配置类组件也能够扮演接口提供者的角色。

当一个模块类组件作为接口提供者的时候，我们需要在模块内部实现被提供接口的所有命令类函数，但是在一个配置类组件内部，我们无权放置接口的具体实现，所以我们唯一能做的，就是把该配置类组件所提供的接口直接与其真正的提供者连接。

但是这么做的意义何在呢？

为什么我们不直接把接口的使用者和提供者连接起来呢？

为什么需要通过一个配置组件来绕一个弯呢？

假设我们现在正在开发一个叫做Encryption的nesC程序，用于进行数据加密。

和Blink一样，该程序由两个组件构成，分别是TestEncryptC和TestEncryptAppC。

TestEncryptC为模块型组件，在其内部我们放置所有接口的实现，例如Boot.booted，Timer.fired，等等。

而TestEncryptAppC则是配置组件，在其内部我们将TestEncryptC所使用的接口连接到它们的提供者那里。

TestEncryptAppC的源代码如下：

这里我们可以看到TestEncryptC（被重命名为App）使用了一个叫做Encryption的接口，主要包含了数据加密、解密的命令函数。

该接口被连接到一个叫做EncryptionC的组件上，也就是说EncryptionC是Encryption接口的提供者。

那么EncryptionC到底是什么类型的组件呢？

模块？

配置？

前者不难理解，模块可以提供接口。

但是出于灵活性考虑，EncryptionC最好是配置型组件。

为什么呢？

请看接下去的代码：

我们看到EncyptionC是一个配置组件，但是它提供Encryption接口，而Encryption接口则是直接用=符号连接到另一个组件rsaP处，而rsaP才是真正实现Encryption接口的模块类组件。

直到这里我们还是要问，那我们为什么不直接把TestEncryptC.Encryption连接到rsaP.Encryption，而是要去EncryptionC那里绕一个远路呢？

是的，我们当然可以这么干，而且程序的运行也不会受影响。

但是如果哪天我们需要把RSA算法替换成ECC算法，那我们该怎么办？

如果我们有多款应用程序，同时用到了Encryption接口，那该怎么办呢？

如何以最便捷的方法实现对加密算法的替换呢？

难道我们把所有的应用程序的配置文件都打开，然后逐个替换？

那样效率太低了，而且容易出错。

但是如果我们通过EncryptionC配置组件一绕，一切就变得简单得多了。

只需要在EncryptionC内将rsaP替换成eccP即可。

新版本的EncryptionC的源代码就变成下面这样：

对于其他应用程序，不需要修改任何东西，因为他们只和EncryptionC打交道，而且Encryption接口还是一如既往由EncryptionC组件来提供。

虽然后台Encryption真正的提供者已经发生了改变，但是对于其他应用程序而言，它们对此并不感兴趣。

就好比你去家乐福购物，某件商品的真正供货商是谁，你无需知道，你也无法知道，因为你只对商品本身感兴趣。

最后请注意各组件的名称。

rsaP和eccP都以P结尾，意为“私有”，表示在我们自己开发的应用程序当中，应当避免直接使用这类组件。

这只是一种命名规则，并不能真正影响程序的执行，你完全可以在你的程序中，直接把一个接口连接到某个“私有”的提供者上，但是并不建议这么做。

当我们使用某个第三方nesC开发包时，我们不应直接碰那些私有组件。

另外以C结尾的是普通组件，AppC结尾的是应用程序的总配置组件。

2.3.4任务和事件

在之前的小节当中我们有提到，我们建议在TinyOS中将相对繁重的工作放置在一个任务函数中执行。

假设我们需要编写一个数据加密工具，我们定义一个接口Encryption，代码如下：

不用太多的解释，我们也可以大致看明白该接口的工作方式。

如果使用这个接口对数据进行加密，我们可以呼叫encrypt命令函数，因为加密运算通常需要耗费一定的时间，所以我们不希望在呼叫完encrypt之后，还得继续等待加密运算结束。

所以在这里就需要采用Split-Phase手法。

当我们呼叫encrypt命令函数之后，我们将加密运算投递到任务执行序列当中，等待被执行。

一旦该任务被成功执行，我们再返回encryptDone事件。

数据解密同理。

有了接口之后，我们就需要建立一个模块组件来实现该接口，称之为EncryptionC。

•05-06行：

用于保存被加密数据和密钥的全局变量。

实际应用中的密钥长度远远不只16位，此处只是一个例子。

12-16行：

encrypt命令函数。

在投递加密任务前，先将数据和密钥保存入全局变量data和key内。

因为任务型函数是不接受任何参数的。

最后使用post命令将加密任务投递至任务执行序列当中。

•07-11行：

用于数据加密的任务函数。

此处数据加密的算法与过程被略去了，因为不是我们要讲解的重点，在加密完成以后，我们使用signal命令返回encryptDone事件，同时返回保存有计算结果的cipher变量。

在编写我们自己的Split-Phase过程时，要注意格外注意两点。

需要注意task函数的复杂程度，因为TinyOS只有一条任务执行序列，如果你向其中投递了一个非常复杂庞大的任务，那会导致后续的任务无法被执行，导致整个系统失去响应。

所以当你的task非常负责的时候，建议将其分割成一系列小型的task。

也可以使用同一个task，但是需要被处理的数据保存入一个全局数组内，每次只处理其中的一小部分数据。

如果数组内的数据尚未被处理完，我们就再次post，如果数据已经被处理完毕，我们就signal运算结束的事件。

最后一点，永远不要在命令函数内signal事件，为了避免在事件函数内，接口的使用者再次呼叫该命令，从而使得整个系统陷入到无尽的函数呼叫循环当中。

我们总是在task任务函数内返回一个事件。

3工作环境

到目前为止，我们已经对nesC程序的构成有了简单的理解，现在我们可以开始做些简单的练习了。

在开始写程序之前，自然是需要一个稳定的开发环境。

在这里我们有一个好消息和一个坏消息。

好消息是在TinyOS的官网上面，他们提供了多种在你电脑上安装、配置TinyOS开发环境的方法；坏消息是这些方法几乎都已经过时，在新版的操作系统下很难为你创建一个良好的开发环境（囧rz）。

TinyOS实质上是一整套由nesC编写的开发包，其主要任务是实现应用程序与底层硬件之间的通讯。

对于nesC开发人员，他并不需要关心底层硬件的运作机制，他只需要把他的注意力完全集中到应用层。

当我们编译nesC程序的时候，系统会先用nescc将nesC代码翻译成指定传感器平台的C语言代码，然后再用对应的编译器进行真正的编译。

例如telosb平台使用的是MSP430单片机，那系统就会调用msp-gcc进行编译，但如果是micaz节点，就会调用avr-gcc。

通常此类编译器都是由单片机生产厂家直接提供，而且他们对系统的配置也有一定的要求。

如果我们尝试把TinyOS安装到最新版的Ubuntu或者Cygwin下面，那十有八九是要出问题的。

或者是一开始的时候可以正常工作，但是在一两次系统更新之后，所有系统配置会被重新打乱。

如果你不是Linux配置的高手，那我个人建议还是使用预先配置好的虚拟机。

毕竟我们需要的是一个稳定的工作，并且能尽快开展工作，而不是把大把的时间浪费在系统的调试和测试上面。

这里向大家推荐的是XubunTOS，是一套基于Xubuntu7.04的VMware虚拟镜像。

其内部已经安装配置好了TinyOS2.1.0，默认编辑器是Emacs。

读者可以在TinyOS的官方网站上面找到其下载链接，还可以在我的个人主页上面找到Emacs的基本操作教程。

下载完毕之后，只需将其导入到VMware内即可。

7.04版的Ubuntu系统早以失去了官方的支持，所以如果你想安装其他的软件会显得比较麻烦。

但是目前还有一些第三方软件源在为老版本的Ubuntu系统提供软件支持，我们只需修改/etc/apt/source.lst中的软件源链接即可。

4编程开发

终于可以开始讲解编程了，因为nesC的语法风格和标准C非常相似，所以我们不会花大篇幅讲解语法，而是直接通过更实际的例子来展现nesC程序的编写过程。

首先我们会学习如果为telosb节点编译、安装一个nesC程序，然后是编写我们的nesC程序：

TempRadio。

4.1Blink

此前在讲解模块与配置的时候，我们已经看过Blink的源代码，这是一个随TinyOS一起发布的例程，很多教程都用它作为例子来讲解TinyOS的应用。

Blink程序的源代码可以在/opt/tinyos-2.1.0/app/Blink下找到。

首先我们把Blink目录拷贝至我们的home下面，然后将一个telosb节点用USB电缆连接至PC。

在编译、安装Blink之前，我们需要检查，telosb节点是否被成功识别。

我们可以使用motelist命令来罗列出所有连接至PC并且被成功识别的传感器节点：

如果我们对这条命令进行解读，可以读作：

为telosb平台编译此程序，并且将其安装至/dev/ttyUSB2的设备上。

如果程序被成功编译、安装，我们就会看到telosb节点上的三枚LED开始有规则是闪烁。

如果我们打开Blink自带的Makefile，我们可以看到这个Makefile只包含两条语句。

•01行：

整个编译工序的切入口，也是Blink这则程序的根配置组件。

•02行：

将TinyOS自带的编译系统包含进来，继续接下去的编译工作。

TinyOS自带的编译系统非常完善，它可以根据目标平台，自动包含所需的头文件，以及其他编译指令。

我们可以在/opt/tinyos-2.1.0/support/make目录下找到TinyOS的整套编译工具。

4.2TempRadio

在这个小节当中，我们将学习如何一步一步地构建起我们的第一个nesC程序，TempRadio。

读者也可以把它当作是一份小型的家庭作业，因为它包含了nesC编程中的所有基础技术：

无线电通讯，串口通讯，温度测量。

这个小程序主要由两部分构成：

信号发送部分和信号接收部分。

前者被放置在远处，负责读取环境温度，并且把温度值通过无线信号发送回基站。

后者则扮演基站的角色，直接和PC通过USB电缆连接，把接收到的温度数据发送回PC。

而在PC上面还有另外一个Java程序把温度数值逐一显示出来。

正如我们在教程开头时候所说的一样，在开始真正编写代码之前，我们需要把这则程序所需的全部功能统统列举出来：

•读取环境数据（温度、湿度、光）；

•无线通讯；

•串口通讯；

•PC上数据的解读与显示。

我们此前已经说过，在nesC中两个组件如果需要沟通，必须通过特定的接口。

假设我们的程序（模块1）想通过天线（模块2）来发送信息，那我们的程序就需要使用接口AMSend。

我们的程序（模块1）成为了AMSend的使用者，而天线模块（模块2）则是该接口的提供者。

下面的列表给出了我们这个程序当中所需要用到的全部接口。

•读取温度：

◦Timer：

每隔一段时间，读取一次温度。

◦Read：

对于telosb平台，该接口由SensirionSht11C提供。

这也是telosb平台自带的温度检测设备（SensirionSHT11）。

•无线数据发送：

以下三个接口均由ActiveMessageC组件负责提供。

◦Packet：

负责管理数据包的接口。

◦SplitControl：

负责启动、关闭天线的接口。

◦AMSend：

该接口的send命令可用于发送数据包。

•无线数据接收：

◦Receive：

也由ActiveMessageC提供。

•串口数据发送：

使用和无线数据发送一样的3个接口，但是由SerialActiveMessageC负责提供。

•PC端数据解读（Java）：

◦net.tinyos.message.MessageListner：

用于监听、收取串口数据的Java接口。

但是TinyOS已经内置了一个Java用具，net.tinyos.tools.MsgReader，用于显示收取到的串口信息。

有的时候为了找到某一个接口的提供者，我们还不得不去查阅相关传感器产品的Datasheet、各类例程，或者是去TinyOS的目录中逐级寻找。

4.2.1数据的采集与发送

我们首先从数据的发送端开始。

我们首先创建一个模块和一个配置，分别命名为SenderC和SenderAppC。

其中在SenderC内，我们列出所有我们需要使用的接口，然后实现所有这些接口内部的事件函数。

如果想查阅需要实现的事件函数，可以直接查看接口的源代码，然后找出所有前缀为event的函数。

绝大多数TinyOS的接口都可以在/opt/tinyos-2.1.0/tos/interfaces/目录内找到。

以下是对SenderC模块组件的简单点评：

•01行：

在Message.h头文件内我们定义了我们需要发送的数据包的结构，为了能够使用这一结构，所以我们需要将这个头文件包含到当前模块内。

•03行：

定义常量TIMER_PERIOD，我们要求每两秒读取一次温度。

•05-13行：

模块的声明。

在里面我们列出所有我们所需的接口。

其中我们可以看到一些接口需要我们提供额外的参数。

例如Timer接口，需要参数，表示计时器的等待时间是用毫秒来标注的。

另外Read接口需要参数，表示读取的温度数值，是一个长度为16位的正整数。

nesC中还有其他多种整数类型，例如int16_t，int8_t等等。

具体他们的定义可以在stdint.h头文件中找到。

•15行：

用来表示天线是否忙碌的布尔变量。

•16行：

用来表示我们需要发送的数据包。

•18-23行：

所有我们需要实现的事件函数。

我们发送的数据包结构被定义在头文件Message.h内。

•04-06行：

我们需要发送的数据包结构，其中包含了网络通讯中所需要用到的数据类型，都需要nx_前缀，其中包括无线通讯和串口通讯。

•08行：

我们需要发送的数据包的AM类型。

一个传感器可以发送多种不同用途的数据包，温度的数据包、湿度的数据包、光线的数据包。

但是在接收的时候任何区分这些包呢？

我们就需要给每种数据包提供一个标签，也就是所谓的AM类型。

AM类型的命名是有一定的规则的，永远是AM_+<数据包结构的大写>。

6这个数值没有实际意义，只要确保每种AM类型的数值不同即可。

我们之前还说过，对于任何一个nesC程序，都必须有至少一个配置型组件。

没有配置