《最新tinyos操作系统开发技术及实践（西电版第3章tinyos体系结构(共90张ppt课件).pptx》由会员分享，可在线阅读，更多相关《最新tinyos操作系统开发技术及实践（西电版第3章tinyos体系结构(共90张ppt课件).pptx（90页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、第3章 TinyOS体系结构 1 1第3章 TinyOS体系结构 3.1 概述 3.2 硬件抽象组件(z jin) 3.3 综合硬件组件 3.4 高层软件组件 3.5 任务调度 3.6 系统启动顺序 3.7 跨平台应用 小结 第一页，共九十页。第3章 TinyOS体系结构 2 23.1 概述概述TinyOS操作系统采用组件式结构，是一个基于事件的系统。系统本身提供了一系列的组件供用户调用，其体系结构如图3-1所示。TinyOS体系结构由下到上将一系列组件分为以下4大类：硬件抽象组件：将物理(wl)硬件映射到TinyOS的组件模型。综合硬件组件：模拟高级的硬件行为，如感知组件、执行组件和通信组件
2、。高层软件组件：包含应用组件，其主要功能是向底层组件发出命令，底层组件向高层组件报告事件。任务调度组件：即主组件，负责对整个TinyOS进行任务的调度，它包括一个任务调度器。第二页，共九十页。第3章 TinyOS体系结构 3 3图3-1 TinyOS体系结构 第三页，共九十页。第3章 TinyOS体系结构 4 4任务调度器具有两层结构(jigu)，第一层维护着命令和事件，主要是在硬件中断发生时对组件的状态进行处理；第二层维护着任务，负责各种计算，只有当组件状态维护工作完成后，任务才能被调度。TinyOS调度模型主要有以下几个特点：任务单线程运行，且运行结束后，只分配单个任务栈，这对内存受限的系
3、统很有利。没有进程管理概念，对任务按简单的FIFO队列进行调度。FIFO的任务调度策略具有能耗敏感性，当任务队列为空时，处理器进入休眠，随后由外部中断事件唤醒CPU进行任务调度。第四页，共九十页。第3章 TinyOS体系结构 5 5两级的调度结构，可以实现优先执行少量同事件相关的处理，同时打断长事件运行的任务。基于事件的调度策略，只需要少量空间就可获得并发性，与事件相关的任务可以很快被处理，不允许阻塞，具有高度并发性。任务之间相互平等，没有(mi yu)优先级的概念。第五页，共九十页。第3章 TinyOS体系结构 6 63.2 硬件抽象组件硬件抽象组件在TinyOS体系架构中硬件抽象组件主要负
4、责物理硬件的控制，采用(ciyng)硬件抽象架构的组件设计模型主要有以下优点：提高代码的可重用性和可移植性。实现效率和性能的优化。本节将介绍硬件抽象架构及其分层结构。第六页，共九十页。第3章 TinyOS体系结构 7 73.2.1 硬件抽象架构硬件抽象架构TinyOS 2.x提出了一个具有(jyu)3层结构的硬件抽象架构，并结合其组件特点形成一个高效的组织结构，如图3-2所示。硬件抽象架构的3层分别是硬件表示层、硬件适配层和硬件接口层。3层的作用描述如下：硬件表示层与硬件的寄存器和中断密切相关，不同芯片的硬件平台的硬件表示层是不同的，这一层与平台的移植息息相关。硬件适配层带有丰富的硬件相关的接
5、口，有助于提高效率；不同平台的硬件适配层有可能不同。硬件接口层提供与平台无关的接口，便于代码的移植。这一层与平台无关，上层可以调用这一层的接口实现对下层的控制。第七页，共九十页。第3章 TinyOS体系结构 8 8图3-2 硬件(yn jin)抽象架构 第八页，共九十页。第3章 TinyOS体系结构 9 93.2.2 硬件表示层硬件表示层硬件表示层(Hardware Presentation Layer，以下简称HPL)由一系列组件组成，该层组件直接位于硬件与软件的接口之间。该层组件访问硬件的一般方法是通过内存或I/O映射，并且硬件可以通过中断信号来请求服务。HPL组件提供的接口完全(wnqu
6、n)由平台的硬件模块本身功能决定。因此HPL组件和硬件的紧密联系会降低组件设计和实现的自由度。尽管每个HPL组件和底层硬件都是独一无二的，但这些组件都有类似的大体结构。为了能够和硬件抽象架构的其余部分更加完美地结合起来，每个HPL组件都应该具备以下几个功能：第九页，共九十页。第3章 TinyOS体系结构 10 10为了实现更有效的电源管理，必须有硬件模块的初始化、开始和停止命令。为控制硬件操作的寄存器提供“get”和“set”命令。为常用的标识位设定和测试操作提供单独的命令。开启和禁用中断的命令。硬件中断的服务程序，HPL组件的中断服务程序只负责临界操作，如复制一个变量(binling)、清空
7、一些标识等行为。以mytinyos平台为例，此平台的HPL组件大都存在于与CC2530芯片相关的文件中。如图3-3所示，硬件表示层组件存在于“tos/chips/cc2530/”目录中。第十页，共九十页。第3章 TinyOS体系结构 11 11图3-3 芯片(xn pin)目录 第十一页，共九十页。第3章 TinyOS体系结构 12 12以“tos/chips/cc2530/”目录下的HplCC2530GeneralIOC.nc文件为例，HplCC2530 GeneralIOC.nc文件是针对(zhndu)CC2530的I/O的实现，打开此文件如图3-4所示。第十二页，共九十页。第3章 Tin
8、yOS体系结构 13 13图3-4 HplCC2530GeneralIOC.nc文件(wnjin) 第十三页，共九十页。第3章 TinyOS体系结构 14 14【代码3-1】 HplCC2530GeneralIOC. nc#include cc2530.hmodule HplCC2530GeneralIOCprovides /*P0有关(yugun)的接口*/interface GeneralIO as Port00;interface GeneralIO as Port01;interface GeneralIO as Port02;interface GeneralIO as Port03
9、;interface GeneralIO as Port04;interface GeneralIO as Port05;interface GeneralIO as Port06;interface GeneralIO as Port07;第十四页，共九十页。第3章 TinyOS体系结构 15 15/*P1有关(yugun)的接口*/interface GeneralIO as Port10;interface GeneralIO as Port11;interface GeneralIO as Port12;interface GeneralIO as Port13;interface G
10、eneralIO as Port14;interface GeneralIO as Port15;interface GeneralIO as Port16;interface GeneralIO as Port17;/*P2有关(yugun)的接口*/interface GeneralIO as Port20;interface GeneralIO as Port21;interface GeneralIO as Port22;interface GeneralIO as Port23;interface GeneralIO as Port24;第十五页，共九十页。第3章 TinyOS体系结
11、构 16 16第十六页，共九十页。第3章 TinyOS体系结构 17 17第十七页，共九十页。第3章 TinyOS体系结构 18 18此文件使用“get”和“set”命令直接操作寄存器，为上层提供软硬件的接口。HPL组件简化了对硬件的操作，无须使用隐藏的宏和寄存器(其定义位于编译库的头文件中)，用户可以通过常见的接口访问硬件。硬件表示层的接口组件一般具有以下两个特点：除了自动操作常用的命令外，HPL层没有提供任何实质性的硬件抽象。它隐藏了最依赖于同一类别的不同HPL硬件模块。比如，在同一硬件平台中不同的微控制器，虽然它们具有相同的功能，但其使用的寄存器名称和中断向量却稍有不同。通过一致的接口，
12、HPL组件可以将这些细小的差别隐藏，从而增强更高层抽象资源(zyun)的独立型。用户只需简单地重新绑定HPL组件，而不必重新编写代码就可以在不同的USART模块之间进行切换。第十八页，共九十页。第3章 TinyOS体系结构 19 193.2.3 硬件适配层硬件适配层硬件适配层由一系列组件组成，该层是硬件抽象架构的核心部分，它使用由HPL层提供的原始接口，建立起合适的硬件抽象，以降低与硬件资源使用相关的复杂性。硬件适配层组件有以下特点：硬件抽象架构允许HAL组件持有可用于资源仲裁和控制(kngzh)的状态变量。由于无线传感器网络对执行效率要求较高，HAL层的硬件抽象必须适合于具体的设备类型和平台
13、特征。HAL接口并不隐藏通用模型的特殊硬件功能，而是提供特定的功能和最好的抽象来简化应用程序的开发，同时保证资源的利用效率，例如通常使用特定领域的硬件抽象模型，如Alarm、ADC或EEPROM等，而不是对所有设备都使用单一的统一的硬件抽象模型。第十九页，共九十页。第3章 TinyOS体系结构 2020这些特定的模型为了实现对硬件抽象的访问，HAL组件应当使用丰富的、定制的接口，而不是通过重载命令隐藏所有功能(gngnng)的标准接口。这样的设计方式使得编译时对接口错误的检查效率更高。以mytinyos平台为例，在“mytinyostosplatformscc2530”目录下的Platform
14、LedsC.nc文件为此平台下的HAL组件之一，如图3-5所示。打开PlatformLedsC文件，如图3-6所示。第二十页，共九十页。第3章 TinyOS体系结构 21 21图3-5 MyTinyOS的HAL组件(z jin) 第二十一页，共九十页。第3章 TinyOS体系结构 2222图3-6 PlatformLedsC.nc 第二十二页，共九十页。第3章 TinyOS体系结构 2323其代码(di m)如代码(di m)3-2所示。【代码(di m)3-2】 PlatformLedsC.nc#include “hardware.h”configuration PlatformLedsC
15、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 MainC;components PlatformP;Init = MainC.SoftwareInit;components HplCC2530Gene
16、ralIOC as IO;/*LED0使用(shyng)CC2530的P1.0*/Led0 = IO.Port10;/*LED1使用(shyng)CC2530的P1.1*/Led1 = IO.Port11;/*LED2使用(shyng)CC2530的P1.2*/Led2 = IO.Port12; /*LED3使用(shyng)CC2530的P1.3*/Led3 = IO.Port13; 第二十四页，共九十页。第3章 TinyOS体系结构 2525另外，在tinyos-2.x的telosa平台使用Sht11芯片采集温度的示例中，在“cygwin opttinyos-2.xtosplatforms
17、telosachips sht11”目录(ml)下面可以看到有关Sht11的HAL组件，如图3-7所示。图3-7 telosa平台(pngti)的HAL组件 第二十五页，共九十页。第3章 TinyOS体系结构 2626打开(d ki)HalSensirionSht11C.nc文件，如图3-8所示。图3-8 HalSensirionSht11C.nc文件(wnjin) 第二十六页，共九十页。第3章 TinyOS体系结构 2727其代码(di m)如代码(di m)3-3所示。【代码(di m)3-3】 HalSensirionSht11C.ncconfiguration HalSensirion
18、Sht11C provides interface Resource uint8_t client ;provides interface SensirionSht11 uint8_t client ;implementation components new SensirionSht11LogicP();SensirionSht11 = SensirionSht11LogicP;第二十七页，共九十页。第3章 TinyOS体系结构 2828components HplSensirionSht11C;Resource = HplSensirionSht11C.Resource;Sensirion
19、Sht11LogicP.DATA - HplSensirionSht11C.DATA;SensirionSht11LogicP.CLOCK - HplSensirionSht11C.SCK;SensirionSht11LogicP.InterruptDATA - HplSensirionSht11C.InterruptDATA; components new TimerMilliC();SensirionSht11LogicP.Timer - TimerMilliC;components LedsC;SensirionSht11LogicP.Leds - LedsC;第二十八页，共九十页。第3
20、章 TinyOS体系结构 2929HAL层组件调用HPL层组件接口，如果底层硬件有变动，可以(ky)在HPL层修改有关的硬件模块即可，而HAL层可以(ky)不用修改，直接调用HPL层接口即可。第二十九页，共九十页。第3章 TinyOS体系结构 30303.2.4 硬件接口层硬件接口层硬件抽象架构的最后组成部分是硬件接口层(Hardware Interface Layer，简写为HIL)。HIL组件使用由HAL层提供的平台相关的硬件抽象，且表现为可跨平台使用的独立(dl)接口。这些独立(dl)接口提供了与平台相关的硬件抽象，从而隐藏了硬件之间的差异，简化了应用软件的开发。在硬件抽象架构里，将HI
21、L分为强HIL和弱HIL两种不同的抽象级别：强HIL：HIL抽象具有完全的硬件无关性，称为强HIL。弱HIL：硬件抽象达不到与硬件完全无关性，称为弱HIL。第三十页，共九十页。第3章 TinyOS体系结构 31 311. 强强HIL强HIL符合硬件抽象架构(ji u)中对HIL层的原始定义。HIL组件的例子有TimerMilliC、LedsC、ActiveMessageC和DemoSensorC组件。如果强HIL提供了对某些变量的操作，变量应采用platform-define类型，如Tinyos 2.x的消息缓冲抽象message_t。打开LedsC文件，如图3-9所示。第三十一页，共九十页。
22、第3章 TinyOS体系结构 3232图3-9 LedsC.nc文件(wnjin) 第三十二页，共九十页。第3章 TinyOS体系结构 3333其代码(di m)如代码(di m)3-4所示。【代码(di m)3-4】 LedsC.ncconfiguration LedsC provides interface Leds;implementation components LedsP, PlatformLedsC; Leds = LedsP; LedsP.Init PlatformLedsC.Led0; LedsP.Led1 - PlatformLedsC.Led1; LedsP.Led2 -
23、 PlatformLedsC.Led2; LedsP.Led3 - PlatformLedsC.Led3;第三十三页，共九十页。第3章 TinyOS体系结构 34342. 弱弱HIL弱HIL是指基于这类抽象可以编写可移植代码，但移植时必须包含平台的特定行为，虽然这种平台的具体行为可能是由一个平台无关的应用程序执行，但语义上仍需要知道具体的平台情况。例如，ADC抽象需要平台相关的配置情况，返回的数据必须根据配置信息才能解释。在所有平台中，ADC配置信息通过AdcConfigure接口设定，以一个platform-define类型的adc_config_t变量作为参数。返回的ADC数据可能以一种与
24、平台无关的方式处理，例如，计算多个ADC读取值的最大值、最下值或平均数。弱HIL的好处就是可以编写可移植的使用代码。虽然这类抽象的代码可能不是完全地被移植，但比起在HAL层代码上移植，工作量要少很多。这是因为弱HIL本身(bnshn)会提示某些功能是如何显露的，从而给平台开发者提供帮助。第三十四页，共九十页。第3章 TinyOS体系结构 35353.3 综合硬件组件综合硬件组件综合硬件组件主要功能是模拟高级的硬件行为，现有的TinyOS系统提供了大多数传感网硬件平台和应用领域里都可用到的组件，如定时器组件、传感器组件、消息收发组件以及电源管理组件等，从而把用户和底层硬件隔离开。基于此，用户只需
25、开发针对特殊组件和特殊应用需求的少量组件，从而提高了应用软件(run jin)的开发效率。综合硬件组件包括感知组件、执行组件和通信组件等，它接收上层提供的的命令并向下调用硬件抽象组件执行此命令，它处于高层软件(run jin)组件与硬件抽象组件之间，是TinyOS的一个过度层，它的出现方便了平台的移植。第三十五页，共九十页。第3章 TinyOS体系结构 36363.4 高层软件组件高层软件组件高层软件组件即应用组件，通过向下层发送命令(mng lng)，并且绑定相应的配件最终实现一个具体应用。应用组件主要有两部分组成：TinyOS操作系统或发布平台为用户提供的应用组件(即API组件)。用户应用
26、程序本身的应用组件。第三十六页，共九十页。第3章 TinyOS体系结构 37373.5 任务调度任务调度3.5.1 任务和调度任务和调度在TinyOS系统中，任务和调度是两个不同的概念，其说明如下：任务一般用于对实时性要求不高的应用中，其实质是一种延迟的计算机制。任务的调度是由调度器来完成(wn chng)。在TinyOS 2.x任务调度器被实现为一个TinyOS组件。每个任务调度器必须都支持nesC语法的任务，否则不能通过ncc编译器的编译。第三十七页，共九十页。第3章 TinyOS体系结构 38381. TinyOS任务任务TinyOS 1.x中对任务的定义比较简单，无参数要求，并采取简单
27、的先进先出(First-In- First-Out，即FIFO)的调度策略。当多次提交一个任务进入任务队列时，可能会返回失败。因为当多次提交一个任务时，只有第一次提交是成功的，其他情况下都是失败的。这种情况导致即使收到提交失败的消息，任务依然会被运行。这中情况下虽然可以修改任务的调度策略，但是当策略发生改变时，开发人员将任务结合到nesC语言代码中非常困难。TinyOS 2.x中提供(tgng)了两种类型的任务。一种是TinyOS 1.x中使用的基本任务模型，将任务调度器表示为组件形式。TinyOS的基本任务模型具体示例如示例3-1所示。第三十八页，共九十页。第3章 TinyOS体系结构 39
28、39【示例(shl)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，从而可以扩展任务的种类(zhngli)。系统对该接口的定义如示例3-2所示。【示例3-2】 TaskBasic.ncinterface TaskBasic asy
29、nc command error_t postTask();event void runTask();第四十页，共九十页。第3章 TinyOS体系结构 41 412. TinyOS调度器调度器TinyOS的调度器既支持最基本的任务模型，又支持接口任务模型，并且由调度器负责协调不同的任务类型(例如具有(jyu)超时管理的任务、具有(jyu)优先级的任务)。标准的TinyOS调度器组件定义在“tinyos-2.xtossystem”目录中，其声明形式如示例3-3所示。第四十一页，共九十页。第3章 TinyOS体系结构 4242【示例3-3】 SchedulerBasicP.ncmodule Sch
30、edulerBasicPprovides interface TaskScheduler;provides interface TaskBasicuint8_t id;uses interface ThreadScheduler;uses interface Leds;调度(diod)器提供了两个接口：TaskScheduler和TaskBasic。两个接口的详细说明如下。第四十二页，共九十页。第3章 TinyOS体系结构 43431) TaskScheduler调度器必须提供Scheduler接口，这个接口定义了用于初始化和运行任务的命令，TinyOS使用(shyng)该接口执行任务，其定义
31、代码如代码3-5所示。第四十三页，共九十页。第3章 TinyOS体系结构 4444【代码3-5】 Scheduler.ncinterface Scheduler /调度(diod)器的初始化command void init();/运行下一个任务，返回true表明有任务在运行，false表明没有任务在运行command bool runNextTask();/任务的无限循环command void taskLoop();第四十四页，共九十页。第3章 TinyOS体系结构 45452) TaskBasic调度器提供了一个参数(cnsh)化的任务接口TaskBasic，每一个绑定到这个任务接口的任
32、务都需要使用unique( )函数来获取唯一的标识符，而且调度器就是通过这个标识符来调度任务的，例如示例3-4。【示例3-4】 获取任务标识符NUM_TASKS = uniqueCount(“TinyTaskSchedulerC.TaskBasic”);当在程序中使用“基本任务”模型编写程序时，如果使用了关键字task和post，nesC编译器将会自动将代码绑定到调度器组件。当组件使用关键字task声明任务时，此组件将调用TaskBasic接口的runTask事件。当组件使用关键字post时，它将调用postTask命令。第四十五页，共九十页。第3章 TinyOS体系结构 46463.5.2
33、调度器的具体实现调度器的具体实现任务调度的具体实现位于“tinyos-2.x/tos/system”目录中，组件是前述SchedulerBasicP.nc模块和对其进行封装的TinyScheduleC.nc配件。1. SchedulerBasicP.ncSchedulerBasicP.nc是调度器的核心模块，其实现代码(di m)如代码(di m)3-6所示(有关说明请参见注释)。第四十六页，共九十页。第3章 TinyOS体系结构 4747【代码(di m)3-6】 SchedulerBasicP.nc#include hardware.hmodule SchedulerBasicP safe
34、() provides interface Scheduler;provides interface TaskBasicuint8_t id;uses interface McuSleep;implementation第四十七页，共九十页。第3章 TinyOS体系结构 4848enum/获取任务(rn wu)个数NUM_TASKS = uniqueCount(TinySchedulerC.TaskBasic),NO_TASK = 255,;/队列头uint8_t m_head;/队列尾uint8_t m_tail;/任务(rn wu)队列，每个任务(rn wu)都有一个id，表明在队列中的位置
35、/m_nextid表示任务(rn wu)号为id后面排着的任务(rn wu)uint8_t m_nextNUM_TASKS;第四十八页，共九十页。第3章 TinyOS体系结构 4949/任务出队函数，返回下一个可执行(zhxng)的任务编号inline uint8_t popTask()/如果队列头不指向空任务if( m_head != NO_TASK )/获取任务编号uint8_t id = m_head;/队列头移向下一个任务m_head = m_nextm_head;/如果移动后的队列头指向空任务，则使队列尾也指向空任务if( m_head = NO_TASK )m_tail = NO_
36、TASK;第四十九页，共九十页。第3章 TinyOS体系结构 5050/将队列(duli)中的当前任务清空，以便下一个任务进来m_nextid = NO_TASK;/返回当前出队任务的编号return id;elsereturn NO_TASK;第五十页，共九十页。第3章 TinyOS体系结构 51 51/检查id号任务是否(sh fu)在队列中等待bool isWaiting( uint8_t id )return (m_nextid != NO_TASK) | (m_tail = id);/将id号对应的任务入队bool pushTask( uint8_t id )/如果id号所对应的任务
37、没有在队列中等待if( !isWaiting(id) )第五十一页，共九十页。第3章 TinyOS体系结构 5252/如果当前任务队列为空，则压入第一个任务if( m_head = NO_TASK )m_head = id;m_tail = id;elsem_nextm_tail = id;m_tail = id;/入队成功(chnggng)则返回TRUE，入队失败则返回FALSEreturn TRUE;第五十二页，共九十页。第3章 TinyOS体系结构 5353elsereturn FALSE; /任务(rn wu)队列初始化command void Scheduler.init()atom
38、icmemset( (void *)m_next, NO_TASK, sizeof(m_next) );m_head = NO_TASK;m_tail = NO_TASK;第五十三页，共九十页。第3章 TinyOS体系结构 5454/运行(ynxng)下一个任务command bool Scheduler.runNextTask()uint8_t nextTask;atomic/从队列中抽出一个任务nextTask = popTask();/如果抽出的任务为空，则返回Falseif( nextTask = NO_TASK )return FALSE;/触发该任务相应的运行(ynxng)事件并返
39、回TRUEsignal TaskBasic.runTasknextTask();return TRUE;第五十四页，共九十页。第3章 TinyOS体系结构 5555/循环(xnhun)运行队列中的任务command void Scheduler.taskLoop()for (;)uint8_t nextTask;atomic/当队列中无任务时进入休眠模式while (nextTask = popTask() = NO_TASK)call McuSleep.sleep();signal TaskBasic.runTasknextTask();第五十五页，共九十页。第3章 TinyOS体系结构 5
40、656/提交任务async command error_t TaskBasic.postTaskuint8_t id()/当队列已存在该任务且被执行(zhxng)时返回EBUSYatomic return pushTask(id) ? SUCCESS : EBUSY; default event void TaskBasic.runTaskuint8_t id()第五十六页，共九十页。第3章 TinyOS体系结构 57572. TinySchedulerC.ncTinySchedulerC.nc配件对SchedulerBasicP模块(m kui)进行封装，以输出接口。其代码如代码3-7所示。
41、【代码3-7】 TinySchedulerC.ncconfiguration TinySchedulerC provides interface Scheduler;provides interface TaskBasicuint8_t id;第五十七页，共九十页。第3章 TinyOS体系结构 5858implementation components SchedulerBasicP as Sched;components McuSleepC as Sleep;Scheduler = Sched;TaskBasic = Sched;Sched.McuSleep - Sleep;第五十八页，共九
42、十页。第3章 TinyOS体系结构 59593.6 系统启动顺序系统启动顺序3.6.1 TinyOS 2.x启动接口启动接口TinyOS 2.x的启动过程使用以下3个接口：Init：初始化组件和硬件状态，一个同步(tngb)接口，主要功能是使初始化有序的进行，其定义如代码3-8所示。【代码3-8】 Init.ncinterface Init command error_t init();第五十九页，共九十页。第3章 TinyOS体系结构 6060Scheduler：初始化和运行任务(rn wu)，具体讲解详见3.5.2节。boot：通知系统已经成功启动，在此接口中定义了一个booted()事件
43、，通过此事件通知系统已经被成功的启动，其定义如代码3-9所示。【代码3-9】 Boot.ncinterface Bootevent void booted();第六十页，共九十页。第3章 TinyOS体系结构 61 613.6.2 TinyOS 2.x启动顺序启动顺序(shnx)TinyOS 2.x的启动过程有以下几个步骤：(1) 硬件平台启动。(2) 调度器初始化。(3) 平台初始化。(4) 软件相关组件初始化。(5) 中断使能。(6) 触发启动完成的信号。(7) 循环运行任务调度。在应用程序中，直接接触到的启动组件是MainC组件。以LedOn为例，LedOnC组件的连接示意图如图3-10
44、所示，LedOnC组件与启动组件通过Boot接口相连接，其中Boot接口由MainC组件提供。第六十一页，共九十页。第3章 TinyOS体系结构 6262图3-10 LedOnC组件(z jin)示意图 第六十二页，共九十页。第3章 TinyOS体系结构 6363【代码3-10】 MainC.ncconfiguration MainC provides interface Boot; uses interface Init as SoftwareInit;implementation components PlatformC, RealMainP, TinySchedulerC;/调度(dio
45、d)器接口绑定RealMainP.Scheduler - TinySchedulerC;/平台初始化接口绑定RealMainP.PlatformInit - PlatformC;/软件初始化接口绑定SoftwareInit = RealMainP.SoftwareInit;Boot = RealMainP;第六十三页，共九十页。第3章 TinyOS体系结构 6464MainC组件的连接(linji)关系示意图如图3-11所示。图3-11 MainC组件(z jin)结构示意图 第六十四页，共九十页。第3章 TinyOS体系结构 6565由MainC组件结构可知，它封装了RealMainP模块，
46、位于“tinyos-2.x/tos/system”目录中，具体(jt)代码如代码3-11所示。第六十五页，共九十页。第3章 TinyOS体系结构 6666【代码(di m)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 Softwar
47、eInit;implementation 第六十六页，共九十页。第3章 TinyOS体系结构 6767int main() C() spontaneous() atomic/启动硬件平台(pngti)platform_bootstrap();/调度器的初始化call Scheduler.init(); /平台(pngti)的初始化call PlatformInit.init(); /检查是否有任务要运行while (call Scheduler.runNextTask();/软件的初始化call SoftwareInit.init(); /检查是否有任务要运行while (call Sched
48、uler.runNextTask();第六十七页，共九十页。第3章 TinyOS体系结构 6868/使能中断_nesc_enable_interrupt();/触发启动完成(wn chng)的事件signal 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
49、 Boot.booted() 第六十八页，共九十页。第3章 TinyOS体系结构 69691. 硬件平台启动硬件平台启动硬件平台启动platfprm_bootstrap( )函数，该函数将系统置于运行状态。可以在函数内配置内存系统，也可以设定处理器的工作模式。该函数的实现(shxin)在TinyOS顶层头文件tos.h中实现(shxin)，但是不做任何操作。其具体代码如代码3-12所示。【代码3-12】 tos.h#include #ifndef platform_bootstrap#define platform_bootstrap() #endif第六十九页，共九十页。第3章 TinyOS
50、体系结构 7070如果某个平台需要将这个默认的实现替换成其他具体的操作，需要在该平台的platform.h文件中用(zhngyng)#define语句声明，以mytinyos平台为例，platform.h位于“mytinyostos platformscc2530”目录内，文件将硬件启动时的时钟设置为32 MHz，具体代码如代码3-13所示。第七十页，共九十页。第3章 TinyOS体系结构 71 71【代码(di m)3-13】 platform.h/将时钟设置为32MHz启动#define platform_bootstrap() CLKCONCMD = 0 x00; while (CLKC