tinyOS programming 阅读笔记

1，TEP: TinyOS Enhancement Proposals

2，首先讲了半天的C/C++/Java的namespace，然后说nesC是purely local namespace，而没有全局可见的函数，所以组件不仅需要实现它所提供的函数，还需要声明所调用的函数。它无法声明其他组件的变量或函数，但可以声明使用其他组件所提供的函数。

3，实现时，nesC程序可以直接在module定义中声明它提供（provide）或使用（use）某个函数，但实际上一般都是把几个相关的函数放在一起，组成一个集合，那就是接口interface，然后程序在module定义中声明它提供或使用某某接口，这样更加方便和模块化。

4，由于函数调用流程图在编译时刻已经可以确定，nesC程序一般都在编译时就进行内联扩展，避免了运行时动态确定被调用函数，所以执行速度很快。（static rather than dynamic）

5，nesC语言相对于传统的C/C++语言，最大的特殊之处在于wiring（配线），即需要将不同的组件连接起来组成一个系统，nesC提供了两个操作符=和-->来完成这个任务。

6，tinyOS的重要目标之一是定义一个灵活的软硬件界面，相同功能可以由软件实现，也可以由硬件实现。（最典型的，interface就相当于一个硬件设备，既可以接受指令command并调用相应执行函数，也会在完成操作时发出事件消息event触发事件处理函数）

7，sensor的OS需要强调实时性，但阻塞进程循环查询又会耗费大量的能量，传统OS采用多线程技术，在一个进程阻塞时再执行其他进程以提高CPU利用效率，由于sensor node的RAM存储器容量所限，并且节能比处理器利用效率更重要，所以TinyOS没有采用多线程，而是在进程阻塞时让节点进入一个低功耗模式，当操作完成时再唤醒节点进行下一步处理，这里就体现了上述的灵活软硬件界面思想，将硬件的分阶段(Split phases)概念引入到软件中，具体实现在interface接口里，它既包含command又包含event，既能用它来发起一个操作，又能通过它来接收操作完成的信号。这里的interface就相当于一个硬件设备。
# 即使采用了分段执行，那么当进入interface的command函数之后，不也相当于blocking住了么？个人觉得是，只是不需要循环查询浪费能量，这个interface相当于一个硬件设备，能接受命令执行，在完成之后发出信号，
# tinyOS是什么类型的操作系统？
我个人觉得它不是多线程操作系统，而更应该算作一种单线程多任务的操作系统，因为tinyOS由于RAM容量及能源所限而无法采用多线程，如果遇到并发任务那也是按优先顺序串行执行，且在任务较少的等待期间让节点进入低功耗休眠状态。

8，接口的数据类型:类似int read() { } ，interface的参数类型也可能仅仅用于类型检查。

9，为了模拟得更像硬件，tinyOS的模块不能像类实例一样想用几个就new几个，它只有一个。P33页：为何实现所使用接口的command，――可能只是为了写在那里方便观察。

10，为了避免在command里发出event而导致多重循环调用及其他便利，tinyOS引入了任务概念：
         task void readDTask();//声明任务
         post readDTask();//将任务加入队列
在实现文件中声明任务，在需要发出event的command函数中将任务加入队列（post这个任务即可），然后在任务处理函数中再发出event。由于任务是非强占的，所以必须限制每个任务的执行时间在几毫秒之内，以改善系统响应时间。队列中不能保存多个相同的任务，如果一个任务需要执行多次，只能以通过自己调用自己实现，即在自己的处理函数中再post自己，当然需要设置终止条件，不然会导致无限循环。这是tinyOS 1.x与2.0的重要差别之一，1.x允许队列中保存多个相同任务，而且当post任务成功时post函数返回SUCCESS，失败时返回FAIL。而2.0则是当队列中已有相同任务时返回FAIL，不将任务插入队列；如果没有相同任务时则返回SUCCESS，并将其插入队列。问题是，当post任务失败时如何判断呢？或许是不用判断。。。