【精品】tinyos操作系统开发技术及实践（西电版第3章tinyos体系结构（可编辑.ppt

《【精品】tinyos操作系统开发技术及实践（西电版第3章tinyos体系结构（可编辑.ppt》由会员分享，可在线阅读，更多相关《【精品】tinyos操作系统开发技术及实践（西电版第3章tinyos体系结构（可编辑.ppt（89页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、TinyOS操作系统开发技术及实践（西电版）第3章 TinyOS体系结构第3章 TinyOS体系结构 2 23.1 概述概述TinyOS操作系统采用组件式结构，是一个基于事件的系统。系统本身提供了一系列的组件供用户调用，其体系结构如图3-1所示。TinyOS体系结构由下到上将一系列组件分为以下4大类：硬件抽象组件：将物理硬件映射到TinyOS的组件模型。综合硬件组件：模拟高级的硬件行为，如感知组件、执行组件和通信组件。高层软件组件：包含应用组件，其主要功能是向底层组件发出命令，底层组件向高层组件报告事件。任务调度组件：即主组件，负责对整个TinyOS进行任务的调度，它包括一个任务调度器。第3章

2、 TinyOS体系结构 3 3图3-1 TinyOS体系结构 第3章 TinyOS体系结构 4 4任务调度器具有两层结构，第一层维护着命令和事件，主要是在硬件中断发生时对组件的状态进行处理；第二层维护着任务，负责各种计算，只有当组件状态维护工作完成后，任务才能被调度。TinyOS调度模型主要有以下几个特点：任务单线程运行，且运行结束后，只分配单个任务栈，这对内存受限的系统很有利。没有进程管理概念，对任务按简单的FIFO队列进行调度。FIFO的任务调度策略具有能耗敏感性，当任务队列为空时，处理器进入休眠，随后由外部中断事件唤醒CPU进行任务调度。第3章 TinyOS体系结构 5 5两级的调度结构

3、，可以实现优先执行少量同事件相关的处理，同时打断长事件运行的任务。基于事件的调度策略，只需要少量空间就可获得并发性，与事件相关的任务可以很快被处理，不允许阻塞，具有高度并发性。任务之间相互平等，没有优先级的概念。第3章 TinyOS体系结构 6 6第3章 TinyOS体系结构 7 7第3章 TinyOS体系结构 8 8图3-2 硬件抽象架构 第3章 TinyOS体系结构 9 93.2.2 硬件表示层硬件表示层硬件表示层(Hardware Presentation Layer，以下简称HPL)由一系列组件组成，该层组件直接位于硬件与软件的接口之间。该层组件访问硬件的一般方法是通过内存或I/O映射

4、，并且硬件可以通过中断信号来请求服务。HPL组件提供的接口完全由平台的硬件模块本身功能决定。因此HPL组件和硬件的紧密联系会降低组件设计和实现的自由度。尽管每个HPL组件和底层硬件都是独一无二的，但这些组件都有类似的大体结构。为了能够和硬件抽象架构的其余部分更加完美地结合起来，每个HPL组件都应该具备以下几个功能：第3章 TinyOS体系结构 10 10为了实现更有效的电源管理，必须有硬件模块的初始化、开始和停止命令。为控制硬件操作的寄存器提供“get”和“set”命令。为常用的标识位设定和测试操作提供单独的命令。开启和禁用中断的命令。硬件中断的服务程序，HPL组件的中断服务程序只负责临界操作

5、，如复制一个变量、清空一些标识等行为。以mytinyos平台为例，此平台的HPL组件大都存在于与CC2530芯片相关的文件中。如图3-3所示，硬件表示层组件存在于“tos/chips/cc2530/”目录中。第3章 TinyOS体系结构 11 11图3-3 芯片目录 第3章 TinyOS体系结构 12 12以“tos/chips/cc2530/”目录下的HplCC2530GeneralIOC.nc文件为例，HplCC2530 GeneralIOC.nc文件是针对CC2530的I/O的实现，打开此文件如图3-4所示。第3章 TinyOS体系结构 13 13图3-4 HplCC2530Genera

6、lIOC.nc文件 第3章 TinyOS体系结构 14 14【代码3-1】HplCC2530GeneralIOC.nc#include cc2530.hmodule HplCC2530GeneralIOCprovides/*P0有关的接口*/interface GeneralIO as Port00;interface GeneralIO as Port01;interface GeneralIO as Port02;interface GeneralIO as Port03;interface GeneralIO as Port04;interface GeneralIO as Port05

7、;interface GeneralIO as Port06;interface GeneralIO as Port07;第3章 TinyOS体系结构 15 15/*P1有关的接口*/interface GeneralIO as Port10;interface GeneralIO as Port11;interface GeneralIO as Port12;interface GeneralIO as Port13;interface GeneralIO as Port14;interface GeneralIO as Port15;interface GeneralIO as Port1

8、6;interface GeneralIO as Port17;/*P2有关的接口*/interface GeneralIO as Port20;interface GeneralIO as Port21;interface GeneralIO as Port22;interface GeneralIO as Port23;interface GeneralIO as Port24;第3章 TinyOS体系结构 16 16第3章 TinyOS体系结构 17 17第3章 TinyOS体系结构 18 18此文件使用“get”和“set”命令直接操作寄存器，为上层提供软硬件的接口。HPL组件简化了对

9、硬件的操作，无须使用隐藏的宏和寄存器(其定义位于编译库的头文件中)，用户可以通过常见的接口访问硬件。硬件表示层的接口组件一般具有以下两个特点：除了自动操作常用的命令外，HPL层没有提供任何实质性的硬件抽象。它隐藏了最依赖于同一类别的不同HPL硬件模块。比如，在同一硬件平台中不同的微控制器，虽然它们具有相同的功能，但其使用的寄存器名称和中断向量却稍有不同。通过一致的接口，HPL组件可以将这些细小的差别隐藏，从而增强更高层抽象资源的独立型。用户只需简单地重新绑定HPL组件，而不必重新编写代码就可以在不同的USART模块之间进行切换。第3章 TinyOS体系结构 19 193.2.3 硬件适配层硬件

10、适配层硬件适配层由一系列组件组成，该层是硬件抽象架构的核心部分，它使用由HPL层提供的原始接口，建立起合适的硬件抽象，以降低与硬件资源使用相关的复杂性。硬件适配层组件有以下特点：硬件抽象架构允许HAL组件持有可用于资源仲裁和控制的状态变量。由于无线传感器网络对执行效率要求较高，HAL层的硬件抽象必须适合于具体的设备类型和平台特征。HAL接口并不隐藏通用模型的特殊硬件功能，而是提供特定的功能和最好的抽象来简化应用程序的开发，同时保证资源的利用效率，例如通常使用特定领域的硬件抽象模型，如Alarm、ADC或EEPROM等，而不是对所有设备都使用单一的统一的硬件抽象模型。第3章 TinyOS体系结构

11、 2020这些特定的模型为了实现对硬件抽象的访问，HAL组件应当使用丰富的、定制的接口，而不是通过重载命令隐藏所有功能的标准接口。这样的设计方式使得编译时对接口错误的检查效率更高。以mytinyos平台为例，在“mytinyostosplatformscc2530”目录下的PlatformLedsC.nc文件为此平台下的HAL组件之一，如图3-5所示。打开PlatformLedsC文件，如图3-6所示。第3章 TinyOS体系结构 21 21图3-5 MyTinyOS的HAL组件 第3章 TinyOS体系结构 2222图3-6 PlatformLedsC.nc 第3章 TinyOS体系结构 2

12、323其代码如代码3-2所示。【代码3-2】PlatformLedsC.nc#include“hardware.h”configuration PlatformLedsC provides interface GeneralIO as Led0;provides interface GeneralIO as Led1;provides interface GeneralIO as Led2;provides interface GeneralIO as Led3;uses interface Init;implementation第3章 TinyOS体系结构 2424components Ma

13、inC;components PlatformP;Init=MainC.SoftwareInit;components HplCC2530GeneralIOC as IO;/*LED0使用CC2530的P1.0*/Led0=IO.Port10;/*LED1使用CC2530的P1.1*/Led1=IO.Port11;/*LED2使用CC2530的P1.2*/Led2=IO.Port12;/*LED3使用CC2530的P1.3*/Led3=IO.Port13;第3章 TinyOS体系结构 2525另外，在tinyos-2.x的telosa平台使用Sht11芯片采集温度的示例中，在“cygwin o

14、pttinyos-2.xtosplatformstelosachips sht11”目录下面可以看到有关Sht11的HAL组件，如图3-7所示。图3-7 telosa平台的HAL组件 第3章 TinyOS体系结构 2626打开HalSensirionSht11C.nc文件，如图3-8所示。图3-8 HalSensirionSht11C.nc文件 第3章 TinyOS体系结构 2727其代码如代码3-3所示。【代码3-3】HalSensirionSht11C.ncconfiguration HalSensirionSht11C provides interface Resource uint8_

15、t client;provides interface SensirionSht11 uint8_t client;implementation components new SensirionSht11LogicP();SensirionSht11=SensirionSht11LogicP;第3章 TinyOS体系结构 2828components HplSensirionSht11C;Resource=HplSensirionSht11C.Resource;SensirionSht11LogicP.DATA-HplSensirionSht11C.DATA;SensirionSht11Log

16、icP.CLOCK-HplSensirionSht11C.SCK;SensirionSht11LogicP.InterruptDATA-HplSensirionSht11C.InterruptDATA;components new TimerMilliC();SensirionSht11LogicP.Timer-TimerMilliC;components LedsC;SensirionSht11LogicP.Leds-LedsC;第3章 TinyOS体系结构 2929HAL层组件调用HPL层组件接口，如果底层硬件有变动，可以在HPL层修改有关的硬件模块即可，而HAL层可以不用修改，直接调用H

17、PL层接口即可。第3章 TinyOS体系结构 30303.2.4 硬件接口层硬件接口层硬件抽象架构的最后组成部分是硬件接口层(Hardware Interface Layer，简写为HIL)。HIL组件使用由HAL层提供的平台相关的硬件抽象，且表现为可跨平台使用的独立接口。这些独立接口提供了与平台相关的硬件抽象，从而隐藏了硬件之间的差异，简化了应用软件的开发。在硬件抽象架构里，将HIL分为强HIL和弱HIL两种不同的抽象级别：强HIL：HIL抽象具有完全的硬件无关性，称为强HIL。弱HIL：硬件抽象达不到与硬件完全无关性，称为弱HIL。第3章 TinyOS体系结构 31 311.强强HIL强H

18、IL符合硬件抽象架构中对HIL层的原始定义。HIL组件的例子有TimerMilliC、LedsC、ActiveMessageC和DemoSensorC组件。如果强HIL提供了对某些变量的操作，变量应采用platform-define类型，如Tinyos 2.x的消息缓冲抽象message_t。打开LedsC文件，如图3-9所示。第3章 TinyOS体系结构 3232图3-9 LedsC.nc文件 第3章 TinyOS体系结构 3333其代码如代码3-4所示。【代码3-4】LedsC.ncconfiguration LedsC provides interface Leds;implementa

19、tion components LedsP,PlatformLedsC;Leds=LedsP;LedsP.Init PlatformLedsC.Led0;LedsP.Led1-PlatformLedsC.Led1;LedsP.Led2-PlatformLedsC.Led2;LedsP.Led3-PlatformLedsC.Led3;第3章 TinyOS体系结构 34342.弱弱HIL弱HIL是指基于这类抽象可以编写可移植代码，但移植时必须包含平台的特定行为，虽然这种平台的具体行为可能是由一个平台无关的应用程序执行，但语义上仍需要知道具体的平台情况。例如，ADC抽象需要平台相关的配置情况，返回的

20、数据必须根据配置信息才能解释。在所有平台中，ADC配置信息通过AdcConfigure接口设定，以一个platform-define类型的adc_config_t变量作为参数。返回的ADC数据可能以一种与平台无关的方式处理，例如，计算多个ADC读取值的最大值、最下值或平均数。弱HIL的好处就是可以编写可移植的使用代码。虽然这类抽象的代码可能不是完全地被移植，但比起在HAL层代码上移植，工作量要少很多。这是因为弱HIL本身会提示某些功能是如何显露的，从而给平台开发者提供帮助。第3章 TinyOS体系结构 35353.3 综合硬件组件综合硬件组件综合硬件组件主要功能是模拟高级的硬件行为，现有的Ti

21、nyOS系统提供了大多数传感网硬件平台和应用领域里都可用到的组件，如定时器组件、传感器组件、消息收发组件以及电源管理组件等，从而把用户和底层硬件隔离开。基于此，用户只需开发针对特殊组件和特殊应用需求的少量组件，从而提高了应用软件的开发效率。综合硬件组件包括感知组件、执行组件和通信组件等，它接收上层提供的的命令并向下调用硬件抽象组件执行此命令，它处于高层软件组件与硬件抽象组件之间，是TinyOS的一个过度层，它的出现方便了平台的移植。第3章 TinyOS体系结构 36363.4 高层软件组件高层软件组件高层软件组件即应用组件，通过向下层发送命令，并且绑定相应的配件最终实现一个具体应用。应用组件主

22、要有两部分组成：TinyOS操作系统或发布平台为用户提供的应用组件(即API组件)。用户应用程序本身的应用组件。第3章 TinyOS体系结构 37373.5 任务调度任务调度3.5.1 任务和调度任务和调度在TinyOS系统中，任务和调度是两个不同的概念，其说明如下：任务一般用于对实时性要求不高的应用中，其实质是一种延迟的计算机制。任务的调度是由调度器来完成。在TinyOS 2.x任务调度器被实现为一个TinyOS组件。每个任务调度器必须都支持nesC语法的任务，否则不能通过ncc编译器的编译。第3章 TinyOS体系结构 38381.TinyOS任务任务TinyOS 1.x中对任务的定义比较

23、简单，无参数要求，并采取简单的先进先出(First-In-First-Out，即FIFO)的调度策略。当多次提交一个任务进入任务队列时，可能会返回失败。因为当多次提交一个任务时，只有第一次提交是成功的，其他情况下都是失败的。这种情况导致即使收到提交失败的消息，任务依然会被运行。这中情况下虽然可以修改任务的调度策略，但是当策略发生改变时，开发人员将任务结合到nesC语言代码中非常困难。TinyOS 2.x中提供了两种类型的任务。一种是TinyOS 1.x中使用的基本任务模型，将任务调度器表示为组件形式。TinyOS的基本任务模型具体示例如示例3-1所示。第3章 TinyOS体系结构 3939【示

24、例3-1】基本任务uint8_t num=3;/任务函数声明post process Task();task void process Task()/任务需要处理的工作num-;if(num)/再次提交任务post process Task();第3章 TinyOS体系结构 4040一种是TinyOS 2.x中新出现的任务模型(本书称为接口任务模型)，即将任务表示为接口TaskBasic，从而可以扩展任务的种类。系统对该接口的定义如示例3-2所示。【示例3-2】TaskBasic.ncinterface TaskBasic async command error_t postTask();ev

25、ent void runTask();第3章 TinyOS体系结构 41 412.TinyOS调度器调度器TinyOS的调度器既支持最基本的任务模型，又支持接口任务模型，并且由调度器负责协调不同的任务类型(例如具有超时管理的任务、具有优先级的任务)。标准的TinyOS调度器组件定义在“tinyos-2.xtossystem”目录中，其声明形式如示例3-3所示。第3章 TinyOS体系结构 4242【示例3-3】SchedulerBasicP.ncmodule SchedulerBasicPprovides interface TaskScheduler;provides interface T

26、askBasicuint8_t id;uses interface ThreadScheduler;uses interface Leds;调度器提供了两个接口：TaskScheduler和TaskBasic。两个接口的详细说明如下。第3章 TinyOS体系结构 43431)TaskScheduler调度器必须提供Scheduler接口，这个接口定义了用于初始化和运行任务的命令，TinyOS使用该接口执行任务，其定义代码如代码3-5所示。第3章 TinyOS体系结构 4444【代码3-5】Scheduler.ncinterface Scheduler/调度器的初始化command void i

27、nit();/运行下一个任务，返回true表明有任务在运行，false表明没有任务在运行command bool runNextTask();/任务的无限循环command void taskLoop();第3章 TinyOS体系结构 45452)TaskBasic调度器提供了一个参数化的任务接口TaskBasic，每一个绑定到这个任务接口的任务都需要使用unique()函数来获取唯一的标识符，而且调度器就是通过这个标识符来调度任务的，例如示例3-4。【示例3-4】获取任务标识符NUM_TASKS=uniqueCount(“TinyTaskSchedulerC.TaskBasic”);当在程序

28、中使用“基本任务”模型编写程序时，如果使用了关键字task和post，nesC编译器将会自动将代码绑定到调度器组件。当组件使用关键字task声明任务时，此组件将调用TaskBasic接口的runTask事件。当组件使用关键字post时，它将调用postTask命令。第3章 TinyOS体系结构 46463.5.2 调度器的具体实现调度器的具体实现任务调度的具体实现位于“tinyos-2.x/tos/system”目录中，组件是前述SchedulerBasicP.nc模块和对其进行封装的TinyScheduleC.nc配件。1.SchedulerBasicP.ncSchedulerBasicP.

29、nc是调度器的核心模块，其实现代码如代码3-6所示(有关说明请参见注释)。第3章 TinyOS体系结构 4747【代码3-6】SchedulerBasicP.nc#include hardware.hmodule SchedulerBasicP safe()provides interface Scheduler;provides interface TaskBasicuint8_t id;uses interface McuSleep;implementation第3章 TinyOS体系结构 4848enum/获取任务个数NUM_TASKS=uniqueCount(TinyScheduler

30、C.TaskBasic),NO_TASK=255,;/队列头uint8_t m_head;/队列尾uint8_t m_tail;/任务队列，每个任务都有一个id，表明在队列中的位置/m_nextid表示任务号为id后面排着的任务uint8_t m_nextNUM_TASKS;第3章 TinyOS体系结构 4949/任务出队函数，返回下一个可执行的任务编号inline uint8_t popTask()/如果队列头不指向空任务if(m_head!=NO_TASK)/获取任务编号uint8_t id=m_head;/队列头移向下一个任务m_head=m_nextm_head;/如果移动后的队列头指

31、向空任务，则使队列尾也指向空任务if(m_head=NO_TASK)m_tail=NO_TASK;第3章 TinyOS体系结构 5050/将队列中的当前任务清空，以便下一个任务进来m_nextid=NO_TASK;/返回当前出队任务的编号return id;elsereturn NO_TASK;第3章 TinyOS体系结构 51 51/检查id号任务是否在队列中等待bool isWaiting(uint8_t id)return(m_nextid!=NO_TASK)|(m_tail=id);/将id号对应的任务入队bool pushTask(uint8_t id)/如果id号所对应的任务没有在

32、队列中等待if(!isWaiting(id)第3章 TinyOS体系结构 5252/如果当前任务队列为空，则压入第一个任务if(m_head=NO_TASK)m_head=id;m_tail=id;elsem_nextm_tail=id;m_tail=id;/入队成功则返回TRUE，入队失败则返回FALSEreturn TRUE;第3章 TinyOS体系结构 5353elsereturn FALSE;/任务队列初始化command void Scheduler.init()atomicmemset(void*)m_next,NO_TASK,sizeof(m_next);m_head=NO_TA

33、SK;m_tail=NO_TASK;第3章 TinyOS体系结构 5454/运行下一个任务command bool Scheduler.runNextTask()uint8_t nextTask;atomic/从队列中抽出一个任务nextTask=popTask();/如果抽出的任务为空，则返回Falseif(nextTask=NO_TASK)return FALSE;/触发该任务相应的运行事件并返回TRUEsignal TaskBasic.runTasknextTask();return TRUE;第3章 TinyOS体系结构 5555/循环运行队列中的任务command void Sche

34、duler.taskLoop()for(;)uint8_t nextTask;atomic/当队列中无任务时进入休眠模式while(nextTask=popTask()=NO_TASK)call McuSleep.sleep();signal TaskBasic.runTasknextTask();第3章 TinyOS体系结构 5656/提交任务async command error_t TaskBasic.postTaskuint8_t id()/当队列已存在该任务且被执行时返回EBUSYatomic return pushTask(id)?SUCCESS:EBUSY;default eve

35、nt void TaskBasic.runTaskuint8_t id()第3章 TinyOS体系结构 57572.TinySchedulerC.ncTinySchedulerC.nc配件对SchedulerBasicP模块进行封装，以输出接口。其代码如代码3-7所示。【代码3-7】TinySchedulerC.ncconfiguration TinySchedulerC provides interface Scheduler;provides interface TaskBasicuint8_t id;第3章 TinyOS体系结构 5858implementation components

36、 SchedulerBasicP as Sched;components McuSleepC as Sleep;Scheduler=Sched;TaskBasic=Sched;Sched.McuSleep-Sleep;第3章 TinyOS体系结构 59593.6 系统启动顺序系统启动顺序3.6.1 TinyOS 2.x启动接口启动接口TinyOS 2.x的启动过程使用以下3个接口：Init：初始化组件和硬件状态，一个同步接口，主要功能是使初始化有序的进行，其定义如代码3-8所示。【代码3-8】Init.ncinterface Init command error_t init();第3章 Ti

37、nyOS体系结构 6060Scheduler：初始化和运行任务，具体讲解详见3.5.2节。boot：通知系统已经成功启动，在此接口中定义了一个booted()事件，通过此事件通知系统已经被成功的启动，其定义如代码3-9所示。【代码3-9】Boot.ncinterface Bootevent void booted();第3章 TinyOS体系结构 61 613.6.2 TinyOS 2.x启动顺序启动顺序TinyOS 2.x的启动过程有以下几个步骤：(1)硬件平台启动。(2)调度器初始化。(3)平台初始化。(4)软件相关组件初始化。(5)中断使能。(6)触发启动完成的信号。(7)循环运行任务调

38、度。在应用程序中，直接接触到的启动组件是MainC组件。以LedOn为例，LedOnC组件的连接示意图如图3-10所示，LedOnC组件与启动组件通过Boot接口相连接，其中Boot接口由MainC组件提供。第3章 TinyOS体系结构 6262图3-10 LedOnC组件示意图 第3章 TinyOS体系结构 6363【代码3-10】MainC.ncconfiguration MainC provides interface Boot;uses interface Init as SoftwareInit;implementation components PlatformC,RealMain

39、P,TinySchedulerC;/调度器接口绑定RealMainP.Scheduler-TinySchedulerC;/平台初始化接口绑定RealMainP.PlatformInit-PlatformC;/软件初始化接口绑定SoftwareInit=RealMainP.SoftwareInit;Boot=RealMainP;第3章 TinyOS体系结构 6464MainC组件的连接关系示意图如图3-11所示。图3-11 MainC组件结构示意图 第3章 TinyOS体系结构 6565由MainC组件结构可知，它封装了RealMainP模块，位于“tinyos-2.x/tos/system”目

40、录中，具体代码如代码3-11所示。第3章 TinyOS体系结构 6666【代码3-11】RealMainP.ncmodule RealMainP safe()/提供Boot接口provides interface Boot;/提供Scheduler接口uses interface Scheduler;/使用PlatformInit接口uses interface Init as PlatformInit;/使用SoftwareInit接口uses interface Init as SoftwareInit;implementation 第3章 TinyOS体系结构 6767int main(

41、)C()spontaneous()atomic/启动硬件平台platform_bootstrap();/调度器的初始化call Scheduler.init();/平台的初始化call PlatformInit.init();/检查是否有任务要运行while(call Scheduler.runNextTask();/软件的初始化call SoftwareInit.init();/检查是否有任务要运行while(call Scheduler.runNextTask();第3章 TinyOS体系结构 6868/使能中断_nesc_enable_interrupt();/触发启动完成的事件sign

42、al Boot.booted();/开启调度循环call Scheduler.taskLoop();return-1;default command error_t PlatformInit.init()return SUCCESS;default command error_t SoftwareInit.init()return SUCCESS;default event void Boot.booted()第3章 TinyOS体系结构 69691.硬件平台启动硬件平台启动硬件平台启动platfprm_bootstrap()函数，该函数将系统置于运行状态。可以在函数内配置内存系统，也可以设定

43、处理器的工作模式。该函数的实现在TinyOS顶层头文件tos.h中实现，但是不做任何操作。其具体代码如代码3-12所示。【代码3-12】tos.h#include#ifndef platform_bootstrap#define platform_bootstrap()#endif第3章 TinyOS体系结构 7070如果某个平台需要将这个默认的实现替换成其他具体的操作，需要在该平台的platform.h文件中用#define语句声明，以mytinyos平台为例，platform.h位于“mytinyostos platformscc2530”目录内，文件将硬件启动时的时钟设置为32 MHz，

44、具体代码如代码3-13所示。第3章 TinyOS体系结构 71 71【代码3-13】platform.h/将时钟设置为32MHz启动#define platform_bootstrap()CLKCONCMD=0 x00;while(CLKCONSTA!=0 x00);第3章 TinyOS体系结构 72722.调度器初始化调度器初始化调度器的具体实现前面已经讲过，这里不再赘述。3.平台初始化平台初始化平台初始化即硬件相关组件的初始化，是通过调用平台初始化命令PlatformInit.init()来进行的，并且把PlatformInit接口连接到特定平台的PlatformC组件上。以mytinyo

45、s平台为例，其PlatformC的实现代码如代码3-14所示。第3章 TinyOS体系结构 7373【代码3-14】PlatformC.ncconfiguration PlatformCprovides interface Init;implementationcomponents PlatformP;Init=PlatformP.Init;第3章 TinyOS体系结构 7474由代码分析可知，PlatformC将Init接口连接到PlatformP组件，PlatformP组件的实现代码如代码3-15所示。第3章 TinyOS体系结构 7575【代码3-15】PlatformP.nc#incl

46、ude cc2530.hmodule PlatformP provides interface Init;implementation command error_t Init.init()return SUCCESS;第3章 TinyOS体系结构 7676其中，PlatformP可以实现对平台的硬件进行初始化，上述代码并没有给出具体的平台初始化，在实际开发过程中，用户可以根据需要在PlatformP组件的implementation中实现平台的初始化。第3章 TinyOS体系结构 77774.软件相关组件初始化软件相关组件初始化TinyOS软件组件的初始化是通过SoftwareInit接口与

47、系统的各个不同的部分建立联系，如果有一些只需运行一次即可的代码，比如某些初始化或配置工作，就可以把他们连接到SoftwareInit接口。第3章 TinyOS体系结构 78785自动配线自动配线在TinyOS系统中，为了简化应用程序的开发，并减轻设计者的负担，需要初始化的服务组件会通过“自动配线”连接到SoftwareInit接口，不需要用户完成。自动配线是指一个组件把某个接口自动绑定到它所依赖的组件上，而不需要用户解决。在这种情况下，该组件不只提供Init接口，并且需要将它的Init接口与MainC组件的SoftwareInit接口相连接。例如，PoolC组件是一个存储相关的通用配件，其初始

48、化连接到MainC的SoftwareInit接口，其具体代码如代码3-16所示。第3章 TinyOS体系结构 7979【代码3-16】PoolC.ncgeneric configuration PoolC(typedef pool_t,uint8_t POOL_SIZE)provides interface Pool;implementation components MainC,new PoolP(pool_t,POOL_SIZE);MainC.SoftwareInit-PoolP;Pool=PoolP;第3章 TinyOS体系结构 8080在系统初始化时，MainC组件会自动完成PoolP

49、组件的初始化工作，无需用户来完成工作。在实际运行中，MainC组件调用SoftwareInit.Init命令，相当于在很多组件中调用Init.Init命令。在典型大型的应用程序中，初始化工作可能包含很多组件，但应用开发者只要编写合适的组件，组件之间会自动做好这些工作。第3章 TinyOS体系结构 81 816.中断使能中断使能当调用Init.init命令的所有函数都返回后才允许中断。如果组件的初始化过程需要处理中断，有以下几种解决方法。如果有中断状态标识，例如，某个I/O口在中断时是低电平，Init.init()函数应当使用循环检测的方法判断有无中断发生。如果没有中断状态标识，Init.ini

50、t()函数可以允许临时使能中断，前提是必须保证不会有其他组件来处理该中断，即如果某组件使能中断后，其中断处理程序会调用其他组件，那么就决不能开启中断。此外，当退出Init.init()函数时，必须关闭中断。第3章 TinyOS体系结构 8282如果没有中断状态表示且没有隔离中断处理程序的方法，则组件必须依赖初始化顺序以外的机制，如SplitControl接口。一般情况下，系统启动过程中主要采用第1种解决方法，但有些特殊情况下组件需要处理中断，需要谨慎使用上述后两种方法处理中断。第3章 TinyOS体系结构 83837.触发启动完成信号触发启动完成信号当完成以上步骤的工作后，MainC组件的Bo