紫陌才韵
TinyOS中两个基本组件分析：Timer.nc和ActiveMessageAddress.nc组件
Timer.nc组件
Timer组件相关函数说明如下： startPeriodic(uint32_t dt)
基本接口，设置一个周期性定时器每dt时间单位重复，代替任何当前定时器设置，相当于“startPeriodicAt(getNow(),dt)”，“fired()”函数在每个dt时间单位内被标记。
startOneShot(uint32_t dt)
为之后的一些单位时间设置一个单一的短定时器，代替任何当前定时器设置，相当于“startPeriodicAt(getNow(),dt)”，“fired()”函数在定时时间到后被标记。
stop()
取消一个定时器
fired()
当定时器到期时或重复时进行标记。
isRunning()
扩展接口，检查定时器是否在运行，
isOneShot()
检查这是否是one-shot定时器
startPeriodicAt(uint32_tt0, uint32_t dt) 每个dt时间单元设置重复周期定时器，
startOneShotAt(uint32_tt0, uint32_t dt) 设置一个段定时器从t0到t0+dt，
gett0()
为先前启动的定时器或以前的事件的时间周期性计时器返回的时间帧
getdt()
为先前启动的定时器返回延迟或时间间隔
ActiveMessageAddress.nc组件
ActiveMessageAddress.nc组件函数如下：
setAddress(am_group_tgroup, am_addr_t addr,uint8_t myChannel) 设置此节点的地址信息
setChannel(uint8_tchannel) 设置节点信道
amAddress() 返回节点地址信息
amGroup() 返回节点组群信息
amChannel()
返回节点信道信息
changed()
地址或组设置更改的通知
TinyOS系统捕捉用户中断示例(tmote) 示例
虽然官方的TEP文档（tep117）已经标注为final，不过还是有错误的地方，可见对于2.1.2，并不适用，本人以tmote平台为例展示捕捉用户中断port27口(usrint)。 硬件连接：中断源接6针扩展板的5口和10针9口。 程序：
----------myInterrupt.h---------- #ifndef MYINTERRUPT_H #define MYINTERRUPT_H enum {
TIMER_PERIOD_MILLI0 = 1000,//初始化亮灯间隔 TIMER_PERIOD_MILLI1 = 125,//闪烁间隔 }; #endif
----------myInterruptAppC.nc---------- configuration myInterruptAppC{ }
implementation {
components myInterruptC as App,MainC,LedsC; components new TimerMilliC() as Timer0; components new TimerMilliC() as Timer1;
components HplMSP430InterruptC as IOInterruptC; components new Msp430InterruptC() as Interrupt; App.Boot -> MainC; App.Timer0 ->Timer0; App.Timer1 ->Timer1; App.Leds -> LedsC;
Interrupt -> IOInterruptC.Port27;
App.Interrupt -> Interrupt; }
----------myInterruptC.nc---------- #include \module myInterruptC { uses {
interface Boot; interface Leds;
interface Timer
implementation {
uint8_t tick; //检测到中断后灯的闪烁计数 task void start_Timer0() {//初始化提示定时器 call Timer0.startPeriodic( TIMER_PERIOD_MILLI0); }
event void Boot.booted() {
call Interrupt.enableFallingEdge();//下降沿中断使能 call Leds.led0On();
post start_Timer0();//初始化完成，亮灯1s }
task void start_Timer1() {//闪烁间隔定时器
call Timer1.startPeriodic( TIMER_PERIOD_MILLI1); }
async event void Interrupt.fired() { //中断触发 tick = 7;
post start_Timer1(); }
event void Timer0.fired() {//灯亮1s call Leds.led0Off(); call Timer0.stop(); }
event void Timer1.fired() {//灯闪烁3次 uint8_t temp_tick; atomic{
temp_tick = --tick; }
if ( temp_tick != 0 ) { call Leds.led0Toggle(); } else {
call Timer1.stop(); }
} }
tinyos学习笔记(1)基本概念、tinyos与硬件关系
---- 基本概念、TinyOS与硬件关系、对底层基本操作 (支持原创，作者：叶雨荫城（阿雨）)
tinyos的基本概念（个人理解，如有错误请指正）
event-driven：tinyos是一个基于Event-driven驱动的操作系统。这个东西不理解的话是不可能对tinyos有深入了解的，尤其是在移植的过程中搞清楚硬件和软件的界限。 什么是事件驱动？
这里主要包含两个方面的含义：软件层面的事件驱动以及硬件事件驱动。在tinyos中软件层面的驱动主要由event以及signal关键字进行实现。而对于硬件事件驱动主要由硬件中断进行实现，产生中断后进入相应的中断处理函数进行处理。硬件事件驱动和软件驱动的主要的关联的部分可以说完全是由signal来完成的，什么意思？就是说在产生硬件中断后，在中断函数中一般是通过signal来通知注册事件的应用层（软件层）有相应的事件发生，而在软件层面的signal所表现的意义也完全如此。但是我们要注意的是，从event层面来看，硬件的event（中断）的事件句柄（即中断处理函数）是异步的，是抢占式的，即只要有硬件中断，无论在tinyos的任务队列中有多少个任务，都会被推迟执行。而在软件层中的event（完全由signal触发，不由硬件产生中断）是非抢占式的，即属于任务（task）的范畴，执行过程首先进入任务队列，只有在其之前的任务运行完成后才会去执行该event的事件句柄（处理函数），当然在软件层面如果声明command、event时，加上async后，这时命令或者event句柄将会成为抢占式的。
注：在抢占式函数中只能调用抢占式操作。这就是为何有时不在async声明的函数中调用call来完成相应的操作而采用task，原因是虽然task为非抢占式的，但是post task操作是抢占式的。所以在async中调用post task是完全合法的。另外一点就是在非抢占式任务中有时候不允许状态突变或者特殊操作时为了避免被抢占式任务抢占，可以用atomic将代码段进行包含，从而可以避免被抢占，唯一的要求就是不要把过多的操作放入atomic，这样会极大的降低tinyos系统的实时性!!!
模块化：这个是编程中普遍存在的概念，模块化的最大好处就是将功能的实现单位化，这样无论在可复用性、扩展、修改等方面都会有很大的好处，而tinyos在模块化方面表现的就更为明显，通过不同的module来实现不同的功能，并且通过configure组件来实现功能的扩展或者使用者和具体实现者的绑定。
接口（interface）：接口就是不同函数功能与事件的结合，这与c++中的类中的方法是极为相似的，只不过接口与具体的实现时分开的，这与c++中的方法还是有区别的。不同的组件会有不同的接口并负责这些接口中函数的各个实现。Tinyos系统标准的接口一般存放在tinyos-2.1.1/tos/interfaces中。而具体硬件的一些接口定义存放在chips文件下的不同功能模块文件下，大家可以看看。
Module组件：从本质来说就是一个功能的具体实现，在tinyos中一般是**P.nc文件来指出，
但我们要清楚，P结尾的组件我们在tinyos中使用很少直接与其绑定，而是通过configure对其进行封装后与该configure来实现绑定从而实现相应的功能。中间的configure主要起的作用就是透明化。
Configure组件：一般以**C.nc结尾，Configure组件大家都知道是完成绑定的操作（wiring）。但是从实现的功能看我个人理解主要有如下几种情形（当然这也是个人理解，如有错误请指正）：
（1）提供抽象的接口。隔离软件和硬件的具体实现，软件部分与这个抽象接口进行绑定实现相应的功能，而这些接口与特定的硬件平台的实现进行绑定实现硬件与软件的完全隔离。其实这就是我们说的硬件抽象层（HAL）。
（2）实现功能的扩展，不同的module实现的功能毕竟有限，通过configure可以把不同module提供的接口进行整合，从而实现功能的扩展。
（3）最后一个当然也是应用最普遍的一个就是将调用者与实现者进行绑定，这个也是其最大的功能。
注：最好理解这些不同功能的方式就是多看代码，由于时间关系，我不能一一进行列举，请大家见谅。
硬件与tinyos关系的及如何实现tinyos系统本身与硬件的分离？
大家都知道，tinyos的硬件部分分为三层：硬件表示层，硬件抽象层及硬件接口层。这三层听着是很抽象的，我个人理解，举个例子。硬件表示层主要是chips中各个功能模块的具体定义及实现，这就包括定义相应的接口及相应的模块实现，platform主要是将具体的平台与chips中引脚进行绑定，并实现相应的功能。而硬件接口层在哪？？大家可能觉得是在硬件或者平台中，这是错误的。真正的硬件接口层的接口定义及实现在具体模块实现tinyos-2.1.1/tos/interfaces及同目录下的system文件夹下，可以说这三者中属于tinyos系统软件级别的只有硬件接口层。让我举个简单的led灯的例子，我将从chips->platform->system进行解读。
下面是我画的一个基本框图： 1.jpg
TinyOS实验一·定时器使用及TinyOS的一般编 实验名称：基于TinyOS的定时器使用 使用平台：Telosb节点
使用环境：Linux下的TinyOS 2.x开发环境 实验时间：2012-06-27
实验内容：
本实验为自拟实验：节点上电之后启动定时器，同时已对应频率驱动Telosb节点上的LED灯 实验目的：
通过简单的实验理顺基于TinyOS编程的思路，为掌握TinyOS编程打下基础
【准备知识】
TinyOS是为无线传感器网络量身定做的基于模块的开源操作系统，其编程使用nesc语言。首先，从宏观上需要掌内容：
1）nesC的应用程序的基本结构式组件，即程序是以组件形式存在的 2）TinyOS是基于事件驱动型的，即由某事件的触发调用某事件响应函数
