3．nesC编程模式成因的简要分析

    实际上，编写nesC程序主要包括两个部分：编写组件，连接函数的使用者与提供者。

    每个组件有一个规范（说明），它是一个代码块，用来声明它提供的函数和使用的函数。对于提供的函数，组件必须定义这个函数，其他组件可以调用它。相反的，组件要调用某个函数，需要由其他组件来定义这个函数。组件可以调用自己提供（定义）的函数。

    组件通常由一组接口（Leds、Boot、SplitControl和AMSend等）来指定。实际编程中，在组件规范中很少声明单独的函数，更多是使用接口（interfaces）。接口是一组相关函数的集合。例如，管理和配置方面的应用经常需要启动和停止系统抽象（也就是某种系统服务），如打开传感器读取数据，打开无线协议栈接收分组等。StdControl 接口是表示这种功能的常用方式。被打开和关闭的抽象或服务的组件要提供stdControl，同时，需要打开或关闭的其他服务或抽象的组件要使用stdControl接口。接口简化了代码，并且使得代码更加清晰。因为组件之间的相互操作遵循标准的模式。

    将提供者与使用者连接起来称为“wiring”。例如，PowerupC 中的代码具有调用Leds.start()的函数的内容，如果Leds不连接到提供者，这些函数就是未定义的符号，即没有绑定到任何实际的代码上。如果Leds被连接到LedsC上，那么当PoewerupC调用Leds.start()时，就调用了LedsC中的Leds.start()。PoewerupC和LedsC是完全分离的，仅当在连接了的时候才绑定起来。这种连接在编译时进行，不需要运行时分配或在RAM中存储函数指针。而且，由于没有间接引用方式，nesC编译器清楚完整的函数调用关系可以进行一些跨越调用边界的优化。

    为什么在TinyOS或nesC中采用这种编程模式呢？

    这主要是由TinyOS面向应用的网络节点的特点与需求所决定的。TinyOS主要是面向无线传感网等低功率网络节点而设计的。这类网络节点与我们熟悉的功能强大、应用繁杂的互联网端用户节点存在很大不同。端节点上存在大量与用户即时交互的应用，比如使用浏览器上网，使用word编辑文档，使用邮件客户端下载邮件，使用QQ与朋友聊天等等，这些使得用户与节点的交互操作极其频繁。另外，由于商业等多方面的因素，节点上运行的软件程序功能也需要动态的维护更新。

    相对的，无线传感网一般具有如下几个特点。

    1）一般面向监测、感知等方面的应用，网络节点功能相对特定。通常工作在无人看管的状态下，节点周期性或触发性地向控制中心发回感知数据，控制中心主动与节点的交互非常少。

    2）网络通常布设在远端，网络功能在一段较长的时间内不会发生变化，也就是说，网络节点功能的更新周期很长，通常会是几个月或是几年。

    3）网络节点能力微小，包括处理能力、存储能力以及通信能力等。

    由此可见，该类节点上的软件程序采用静态组织的方法，在满足节点能力微小限制的同时，又可以满足网络节点的应用需求。