TinyOS體系結(jié)構(gòu)PPT

1、第第 3 3 章章TinyOSTinyOS體系結(jié)構(gòu)體系結(jié)構(gòu)本章目標(biāo)掌握TinyOS體系結(jié)構(gòu)的各部分組成掌握硬件抽象組件的作用掌握硬件抽象組件的架構(gòu)掌握硬件表示層、適配層、接口層的作用掌握綜合硬件組件的組成熟悉TinyOS任務(wù)的調(diào)度理解跨平臺(tái)的應(yīng)用- 3 -3.1 概述硬件抽象組件：將物理硬件映射到TinyOS的組件模型。綜合硬件組件：模擬高級(jí)的硬件行為，如感知組件、執(zhí)行組件和通信組件。高層軟件組件：包含應(yīng)用組件，其主要功能是向底層組件發(fā)出命令，底層組件向高層組件報(bào)告事件。任務(wù)調(diào)度組件：即主組件，負(fù)責(zé)對(duì)整個(gè)TinyOS進(jìn)行任務(wù)的調(diào)度，它包括一個(gè)任務(wù)調(diào)度器。- 4 -3.1 概述第一層維護(hù)著命令和

2、事件，主要是在硬件中斷發(fā)生時(shí)對(duì)組件的狀態(tài)進(jìn)行處理；第二層維護(hù)著任務(wù)，負(fù)責(zé)各種計(jì)算，只有當(dāng)組件狀態(tài)維護(hù)工作完成后，任務(wù)才能被調(diào)度。 兩層- 5 -3.1 概述TinyOS調(diào)度模型主要有以下幾個(gè)特點(diǎn) l任務(wù)單線程運(yùn)行，且運(yùn)行結(jié)束后，只分配單個(gè)任務(wù)棧，這對(duì)內(nèi)存受限的系統(tǒng)很有利。l沒(méi)有進(jìn)程管理概念，對(duì)任務(wù)按簡(jiǎn)單的FIFO隊(duì)列進(jìn)行調(diào)度。lFIFO的任務(wù)調(diào)度策略具有能耗敏感性，當(dāng)任務(wù)隊(duì)列為空時(shí)，處理器進(jìn)入休眠，隨后由外部中斷事件喚醒CPU進(jìn)行任務(wù)調(diào)度。l兩級(jí)的調(diào)度結(jié)構(gòu)，可以實(shí)現(xiàn)優(yōu)先執(zhí)行少量同事件相關(guān)的處理，同時(shí)打斷長(zhǎng)事件運(yùn)行的任務(wù)。l基于事件的調(diào)度策略，只需要少量空間就可獲得并發(fā)性，與事件相關(guān)的任務(wù)可以很

3、快被處理，不允許阻塞，具有高度并發(fā)性。l任務(wù)之間相互平等，沒(méi)有優(yōu)先級(jí)的概念。- 6 -3.2 硬件抽象組件功能 l主要負(fù)責(zé)物理硬件的控制 優(yōu)點(diǎn) l提高代碼的可重用性和可移植性；l實(shí)現(xiàn)效率和性能的優(yōu)化。- 7 -3.2 硬件抽象層 硬件表示層與硬件的寄存器和中斷密切相關(guān)，不同芯片的硬件平臺(tái)的硬件表示層是不同的，這一層與平臺(tái)的移植息息相關(guān)。 硬件適配層帶有豐富的硬件相關(guān)的接口，有助于提高效率；不同平臺(tái)的硬件適配層有可能不同。 硬件接口層提供與平臺(tái)無(wú)關(guān)的接口，便于代碼的移植。這一層與平臺(tái)無(wú)關(guān)，上層可以調(diào)用這一層的接口實(shí)現(xiàn)對(duì)下層的控制。三層- 8 -3.2 硬件抽象層 硬件表示層（Hardware P

4、resentation Layer,簡(jiǎn)稱(chēng)HPL）由一系列組件組成，該層組件直接位于硬件與軟件的接口之間。該層組件訪問(wèn)硬件的一般方法是通過(guò)內(nèi)存或I/O映射，并且硬件可以通過(guò)中斷信號(hào)來(lái)請(qǐng)求服務(wù)。 HPL組件提供的接口完全由平臺(tái)的硬件模塊本身功能決定 。- 9 -3.2 硬件抽象層HPL組件都應(yīng)該具備以下幾個(gè)功能 ：l為了實(shí)現(xiàn)更有效的電源管理，必須有硬件模塊的初始化、開(kāi)始和停止命令；l為控制硬件操作的寄存器提供“get”和“set”命令；l為常用的標(biāo)識(shí)位設(shè)定和測(cè)試操作提供單獨(dú)的命令；l開(kāi)啟和禁用中斷的命令；l硬件中斷的服務(wù)程序，HPL組件的中斷服務(wù)程序只負(fù)責(zé)臨界操作，如復(fù)制一個(gè)變量、清空一些標(biāo)識(shí)等行

5、為。- 10 -3.2 硬件抽象層以mytinyOS平臺(tái)為例，此平臺(tái)的HPL組件大都存在于與CC2530芯片相關(guān)的文件中 - 11 -3.2 硬件抽象層以“tos/chips/cc2530/”目錄下的HplCC2530GeneralIOC.nc文件為例，HplCC2530GeneralIOC.nc文件是針對(duì)CC2530的I/O的實(shí)現(xiàn) - 12 -3.2 硬件抽象層HplCC2530GeneralIOC.nc文件I/O的實(shí)現(xiàn)的代碼示例 /HplCC2530GenerallOC.nc文件async command bool Port00.get() return P0_0; async comma

6、nd void Port00.set() P0_0 = 1; async command void Port00.clr() P0_0 = 0; async command void Port00.toggle() P0_0 = 1; async command void Port00.makeInput() P0SEL &= _BV(0); P0DIR &= _BV(0);async command bool Port00.isInput() return (P0DIR&_BV(0); async command void Port00.makeOutput() P0SEL &= _BV(0

7、); P0DIR |= _BV(0); async command bool Port00.isOutput() return P0DIR&_BV(0); HplCC2530GeneralIOC.nc文件使用“get”和“set”命令直接操作寄存器，為上層提供軟硬件的接口。HPL組件簡(jiǎn)化了對(duì)硬件的操作，無(wú)須使用隱藏的宏和寄存器（其定義位于編譯庫(kù)的頭文件中），用戶可以通過(guò)常見(jiàn)的接口訪問(wèn)硬件。 - 13 -3.2 硬件抽象層HPL的接口組件一般具有以下兩個(gè)特點(diǎn) ：l除了自動(dòng)操作常用的命令外，HPL層沒(méi)有提供任何實(shí)質(zhì)性的硬件抽象。它隱藏了最依賴(lài)于同一類(lèi)別的不同HPL硬件模塊。增強(qiáng)更高層抽象資源的獨(dú)立

8、型。l用戶只需簡(jiǎn)單地重新綁定HPL組件，而不必重新編寫(xiě)代碼就可以在不同的USART模塊之間進(jìn)行切換。- 14 -3.2 硬件抽象層硬件適配層（Hardware Adaptation Layer，簡(jiǎn)稱(chēng)HAL）由一系列組件組成，該層是硬件抽象架構(gòu)的核心部分，它使用由HPL層提供的原始接口，建立起合適的硬件抽象，以降低與硬件資源使用相關(guān)的復(fù)雜性。 - 15 -3.2 硬件抽象層硬件適配層組件有以下特點(diǎn)： l硬件抽象架構(gòu)允許HAL組件持有可用于資源仲裁和控制的狀態(tài)變量。l由于無(wú)線傳感器網(wǎng)絡(luò)對(duì)執(zhí)行效率要求較高，HAL層的硬件抽象必須適合于具體的設(shè)備類(lèi)型和平臺(tái)特征。lHAL接口并不隱藏通用模型的特殊硬件功

9、能，而是提供特定的功能和最好的抽象來(lái)簡(jiǎn)化應(yīng)用程序的開(kāi)發(fā)，同時(shí)保證資源的利用效率，。l為了實(shí)現(xiàn)對(duì)硬件抽象的訪問(wèn)，HAL組件應(yīng)當(dāng)使用豐富的、定制的接口，而不是通過(guò)重載命令隱藏所有功能的標(biāo)準(zhǔn)接口。這樣的設(shè)計(jì)方式使得編譯時(shí)對(duì)接口錯(cuò)誤的檢查效率更高。- 16 -3.2 硬件抽象層以mytinyos平臺(tái)為例，在“mytinyostosplatformscc2530”目錄下的PlatformLedsC.nc文件為此平臺(tái)下的HAL組件之一 - 17 -3.2 硬件抽象層打開(kāi)PlatformLedsC.nc文件- 18 -3.2 硬件抽象層PlatformLedsC.nc組件的 implementation 部

10、分implementation components MainC; components PlatformP; Init = MainC.SoftwareInit; components HplCC2530GeneralIOC as IO; Led0 = IO.Port10; Led1 = IO.Port11; Led2 = IO.Port12; Led3 = IO.Port13; - 19 -3.2 硬件抽象層硬件抽象架構(gòu)的最后組成部分是硬件接口層（Hardware Interface Layer，簡(jiǎn)寫(xiě)為HIL）。HIL組件使用由HAL層提供的平臺(tái)相關(guān)的硬件抽象，且表現(xiàn)為可跨平臺(tái)使用的獨(dú)立接

11、口。這些獨(dú)立接口提供了與平臺(tái)相關(guān)的硬件抽象，從而隱藏了硬件之間的差異，簡(jiǎn)化了應(yīng)用軟件的開(kāi)發(fā)。在硬件抽象架構(gòu)里，將HIL分為強(qiáng)HIL和弱HIL兩種不同的抽象級(jí)別：l強(qiáng)HIL：HIL抽象具有完全的硬件無(wú)關(guān)性，稱(chēng)為強(qiáng)HIL。l弱HIL：硬件抽象達(dá)不到與硬件完全無(wú)關(guān)性，稱(chēng)為弱HIL。- 20 -3.2 硬件抽象層強(qiáng)HIL符合硬件抽象架構(gòu)中對(duì)HIL層的原始定義。HIL組件的例子有TimerMilliC、LedsC、ActiveMessageC和DemoSensorC組件。如果強(qiáng)HIL提供了對(duì)某些變量的操作，變量應(yīng)采用platform-define類(lèi)型，如Tinyos2.x的消息緩沖抽象message_t

12、 。- 21 -3.2 硬件抽象層以LedsC.nc文件為例- 22 -3.2 硬件抽象層LedsC.nc組件代碼如下：configuration LedsC provides interface Leds;implementation components LedsP, PlatformLedsC; Leds = LedsP; LedsP.Init PlatformLedsC.Led0; LedsP.Led1 - PlatformLedsC.Led1; LedsP.Led2 - PlatformLedsC.Led2; LedsP.Led3 - PlatformLedsC.Led3;- 23

13、-3.2 硬件抽象層弱HIL是指基于這類(lèi)抽象可以編寫(xiě)可移植代碼，但移植時(shí)必須包含平臺(tái)的特定行為，雖然這種平臺(tái)的具體行為可能是由一個(gè)平臺(tái)無(wú)關(guān)的應(yīng)用程序執(zhí)行，但語(yǔ)義上仍需要知道具體的平臺(tái)情況。弱HIL的好處就是可以編寫(xiě)可移植的使用代碼。 - 24 -3.3 綜合硬件組件綜合硬件組件主要功能是模擬高級(jí)的硬件行為，現(xiàn)有的TinyOS系統(tǒng)提供了大多數(shù)傳感網(wǎng)硬件平臺(tái)和應(yīng)用領(lǐng)域里都可用到的組件，如定時(shí)器組件、傳感器組件、消息收發(fā)組件以及電源管理組件等，從而把用戶和底層硬件隔離開(kāi)。用戶只需開(kāi)發(fā)針對(duì)特殊組件和特殊應(yīng)用需求的少量組件，從而提高了應(yīng)用軟件的開(kāi)發(fā)效率。綜合硬件組件包括感知組件、執(zhí)行組件和通信組件等，它

14、接收上層提供的的命令并向下調(diào)用硬件抽象組件執(zhí)行此命令，它處于高層軟件組件與硬件抽象組件之間，是TinyOS的一個(gè)過(guò)度層，它的出現(xiàn)方便了平臺(tái)的移植。- 25 -3.4 高層軟件組件高層軟件組件即應(yīng)用組件，通過(guò)向下層發(fā)送命令，并且綁定相應(yīng)的配件最終實(shí)現(xiàn)一個(gè)具體應(yīng)用。應(yīng)用組件主要有兩部分組成：lTinyOS操作系統(tǒng)或發(fā)布平臺(tái)為用戶提供的應(yīng)用組件（即API組件）。l用戶應(yīng)用程序本身的應(yīng)用組件。- 26 -3.5 任務(wù)調(diào)度在TinyOS體系結(jié)構(gòu)中，位于最上層的是任務(wù)調(diào)度，即主組件。TinyOS的主組件由Main組件組成，該組件由操作系統(tǒng)提供，節(jié)點(diǎn)上電后會(huì)首先執(zhí)行該組件中的函數(shù)，其主要功能是初始化硬件、啟

15、動(dòng)任務(wù)調(diào)度器以及執(zhí)行應(yīng)用組件的初始化函數(shù)。- 27 -3.5 任務(wù)調(diào)度在TinyOS系統(tǒng)中，任務(wù)和調(diào)度是兩個(gè)不同的概念 ：l任務(wù)一般用于對(duì)實(shí)時(shí)性要求不高的應(yīng)用中，其實(shí)質(zhì)是一種延遲的計(jì)算機(jī)制。l任務(wù)的調(diào)度是由調(diào)度器來(lái)完成。在TinyOS2.x任務(wù)調(diào)度器被實(shí)現(xiàn)為一個(gè)TinyOS組件。每個(gè)任務(wù)調(diào)度器必須都支持nesC語(yǔ)法的任務(wù)，否則不能通過(guò)ncc編譯器的編譯。- 28 -3.5 任務(wù)調(diào)度在TinyOS2.x中提供了兩種類(lèi)型的任務(wù)： l一種是TinyOS 1.x中使用的基本任務(wù)模型，將任務(wù)調(diào)度器表示為組件形式 。l一種是TinyOS 2.x中新出現(xiàn)的任務(wù)模型（稱(chēng)為接口任務(wù)模型），即將任務(wù)表示為接口Ta

16、skBasic，從而可以擴(kuò)展任務(wù)的種類(lèi) - 29 -3.5 任務(wù)調(diào)度TinyOS 1.x中使用的基本任務(wù)模型如下：/任務(wù)函數(shù)聲明post process Task();task void process Task()/任務(wù)需要處理的工作num-;if(num)/再次提交任務(wù)post process Task();- 30 -3.5 任務(wù)調(diào)度TinyOS 2.x中使用的基本任務(wù)模型如下：interface TaskBasic async command error_t postTask();event void runTask();- 31 -3.5 任務(wù)調(diào)度在TinyOS 2.x系統(tǒng)中，任務(wù)具

17、有以下特點(diǎn) ： l在TinyOS2.x中，任務(wù)隊(duì)列不會(huì)出現(xiàn)多個(gè)同樣的任務(wù)，每個(gè)任務(wù)在任務(wù)隊(duì)列中都有它自己預(yù)留的緩存區(qū)。l任務(wù)可以被多次提交，但是只有一種情況下是提交失敗的，即任務(wù)已經(jīng)被提交，但沒(méi)有開(kāi)始執(zhí)行，此時(shí)再次提交該任務(wù)將會(huì)返回失敗。l在TinyOS 2.x中，每個(gè)任務(wù)都分配了一個(gè)任務(wù)ID號(hào)，此ID號(hào)的程度為一個(gè)字節(jié)，即范圍大小為0255。如果一個(gè)組件需要多次提交給同一個(gè)任務(wù)，可以在任務(wù)實(shí)現(xiàn)代碼的最后部分將自身再次提交入隊(duì)。- 32 -3.5 任務(wù)調(diào)度TinyOS的調(diào)度器既支持最基本的任務(wù)模型，又支持接口任務(wù)模型，并且由調(diào)度器負(fù)責(zé)協(xié)調(diào)不同的任務(wù)類(lèi)型（例如具有超時(shí)管理的任務(wù)、具有優(yōu)先級(jí)的任務(wù)

18、） - 33 -3.5 任務(wù)調(diào)度標(biāo)準(zhǔn)的TinyOS調(diào)度器組件定義在“tinyos-2.xtossystem”目錄中，其聲明形式如下：/SchedulerBasicP.nc/SchedulerBasicP.nc 文件module SchedulerBasicPprovides interface TaskScheduler;provides interface TaskBasicuint8_t id;uses interface ThreadScheduler;uses interface Leds;- 34 -3.5 任務(wù)調(diào)度調(diào)度器必須提供Scheduler接口，這個(gè)接口定義了用于初始化和運(yùn)行

19、任務(wù)的命令，TinyOS使用該接口執(zhí)行任務(wù)interface Scheduler /調(diào)度器的初始化command void init();/運(yùn)行下一個(gè)任務(wù)，返回true表明有任務(wù)在運(yùn)行，false表明沒(méi)有任務(wù)在運(yùn)行command bool runNextTask();/任務(wù)的無(wú)限循環(huán)command void taskLoop();- 35 -3.5 任務(wù)調(diào)度Scheduler接口提供三個(gè)命令： linit命令用來(lái)初始化任務(wù)隊(duì)列和數(shù)據(jù)結(jié)構(gòu)。lrunNextTask命令一旦運(yùn)行就必須運(yùn)行到結(jié)束，其返回值表示它是否運(yùn)行了任務(wù)：TRUE表明有任務(wù)在運(yùn)行，F(xiàn)ALSE表明沒(méi)有任務(wù)在運(yùn)行。如果調(diào)用runNe

20、xtTask（FALSE）可能返回TRUE，也可能返回FALSE；如果調(diào)用runNextTask（TRUE）總是返回TRUE。ltaskLoop命令會(huì)使調(diào)度器進(jìn)入無(wú)限任務(wù)循環(huán)中，并能夠在微處理器處于空閑時(shí)使其進(jìn)入低功耗模式。- 36 -3.5 任務(wù)調(diào)度調(diào)度器提供另外一個(gè)參數(shù)化的任務(wù)接口TaskBasic，每一個(gè)綁定到這個(gè)任務(wù)接口的任務(wù)都需要使用unique( )函數(shù)來(lái)獲取唯一的標(biāo)識(shí)符，且調(diào)度器就是通過(guò)這個(gè)標(biāo)識(shí)符來(lái)調(diào)度任務(wù)的 NUM_TASKS = uniqueCount(TinyTaskSchedulerC.TaskBasic);- 37 -3.5 任務(wù)調(diào)度當(dāng)在程序中使用“基本任務(wù)”模型編寫(xiě)程

21、序時(shí)，如果使用了關(guān)鍵字“task”和“post”，nesC編譯器將會(huì)自動(dòng)將代碼綁定到調(diào)度器組件： l當(dāng)組件使用關(guān)鍵字“task”聲明任務(wù)時(shí)，此組件將調(diào)用TaskBasic接口的runTask事件。l當(dāng)組件使用關(guān)鍵字“post”時(shí)，它將調(diào)用postTask命令。- 38 -3.5 任務(wù)調(diào)度任務(wù)調(diào)度的具體實(shí)現(xiàn)位于“tinyos-2.x/tos/system”目錄中。包括模塊和配件l模塊為SchedulerBasicP.nc模塊l配件為T(mén)inyScheduleC.nc配件。 - 39 -3.5 任務(wù)調(diào)度SchedulerBasicP.nc是調(diào)度器的核心模塊#include hardware.hmod

22、ule SchedulerBasicP safe() provides interface Scheduler;provides interface TaskBasicuint8_t id;uses interface McuSleep;- 40 -3.5 任務(wù)調(diào)度TinySchedulerC.nc配件對(duì)SchedulerBasicP模塊進(jìn)行封裝，以輸出接口 configuration TinySchedulerC provides interface Scheduler;provides interface TaskBasicuint8_t id;- 41 -3.5 任務(wù)調(diào)度TinySche

23、dulerC.nc配件對(duì)SchedulerBasicP模塊進(jìn)行封裝，以輸出接口 implementation components SchedulerBasicP as Sched;components McuSleepC as Sleep;Scheduler = Sched;TaskBasic = Sched;Sched.McuSleep - Sleep;- 42 -3.6 系統(tǒng)啟動(dòng)順序TinyOS 2.x的啟動(dòng)過(guò)程使用以下3個(gè)接口 lInit：初始化組件和硬件狀態(tài)，一個(gè)同步接口，主要功能是使初始化有序的進(jìn)行l(wèi)Scheduler：初始化和運(yùn)行任務(wù) 。 lboot：通知系統(tǒng)已經(jīng)成功啟動(dòng)，在此接

24、口中定義了一個(gè)booted（）事件，通過(guò)此事件通知系統(tǒng)已經(jīng)被成功的啟動(dòng) provides interface Boot; provides interface AtosScheduler; uses interface Init as SoftwareInit;- 43 -3.6 系統(tǒng)啟動(dòng)順序Init接口定義如下：interface Init command error_t init();- 44 -3.6 系統(tǒng)啟動(dòng)順序Boot接口定義如下：interface Bootevent void booted();- 45 -3.6 系統(tǒng)啟動(dòng)順序 TinyOS 2.x的啟動(dòng)過(guò)程有以下幾個(gè)步驟 l 硬

25、件平臺(tái)啟動(dòng)；main (intface3)l 調(diào)度器初始化；(-)l 平臺(tái)初始化l 軟件相關(guān)組件初始化l 中斷使能；l 觸發(fā)啟動(dòng)完成的信號(hào)；l 循環(huán)運(yùn)行任務(wù)調(diào)度。- 46 -3.6 系統(tǒng)啟動(dòng)順序 在應(yīng)用程序中，直接接觸到的啟動(dòng)組件是MainC組件，以LedOn為例， LedOnC組件與啟動(dòng)組件通過(guò)Boot接口相連接，其中Boot接口由MainC組件提供。 - 47 -3.6 系統(tǒng)啟動(dòng)順序MainC組件位于“tinyos-2.x/tos/system”目錄中，主要代碼configuration MainC provides interface Boot; uses interface Init

26、as SoftwareInit;- 48 -3.6 系統(tǒng)啟動(dòng)順序MainC組件位于“tinyos-2.x/tos/system”目錄中，主要代碼implementation components PlatformC, RealMainP, TinySchedulerC;/調(diào)度器接口綁定RealMainP.Scheduler - TinySchedulerC;/平臺(tái)初始化接口綁定RealMainP.PlatformInit - PlatformC;/軟件初始化接口綁定SoftwareInit = RealMainP.SoftwareInit;Boot = RealMainP;- 49 -3.6

27、系統(tǒng)啟動(dòng)順序 MainC組件的連接關(guān)系示意圖如下，它封裝了RealMainP模塊 - 50 -3.6 系統(tǒng)啟動(dòng)順序RealMainP模塊，它位于“tinyos-2.x/tos/system”目錄中 ，module RealMainP safe() /提供Boot接口provides interface Boot;/提供Scheduler接口uses interface Scheduler;/使用PlatformInit接口uses interface Init as PlatformInit;/使用SoftwareInit接口uses interface Init as SoftwareIni

28、t;- 51 -3.6 系統(tǒng)啟動(dòng)順序 RealMainP模塊中硬件平臺(tái)啟動(dòng)；l 硬件平臺(tái)啟動(dòng)platfprm_bootstrap( )函數(shù)，此函數(shù)將系統(tǒng)置于運(yùn)行狀態(tài) #include #ifndef platform_bootstrap#define platform_bootstrap() #endif - 52 -3.6 系統(tǒng)啟動(dòng)順序 RealMainP模塊中硬件平臺(tái)啟動(dòng)；l 如果某個(gè)平臺(tái)需要將這個(gè)默認(rèn)的實(shí)現(xiàn)替換成其他具體的操作，需要在該平臺(tái)的platform.h文件中用#define語(yǔ)句聲明l 以mytinyos平臺(tái)為例，platform.h位于“mytinyostosplatforms

29、cc2530”目錄內(nèi)，文件將硬件啟動(dòng)時(shí)的時(shí)鐘設(shè)置為32MHz，具體代碼如下 #define platform_bootstrap() CLKCONCMD = 0 x00; while (CLKCONSTA != 0 x00);- 53 -3.6 系統(tǒng)啟動(dòng)順序 RealMainP模塊中平臺(tái)初始化；l 平臺(tái)初始化即硬件相關(guān)組件的初始化，是通過(guò)調(diào)用平臺(tái)初始化命令PlatformInit.init（）來(lái)進(jìn)行的。并且把PlatformInit接口連接到特定平臺(tái)的PlatformC組件上。以mytinyos平臺(tái)為例，其PlatformC的實(shí)現(xiàn)代碼如下：configuration PlatformCprov

30、ides interface Init;implementationcomponents PlatformP;Init = PlatformP.Init;Init = PlatformP.Init;- 54 -3.6 系統(tǒng)啟動(dòng)順序 RealMainP模塊中平臺(tái)初始化；l PlatformC將Init接口連接到PlatformP組件，PlatformP組件的實(shí)現(xiàn)代碼如下：#include cc2530.hmodule PlatformP provides interface Init;implementation command error_t Init.init() return SUCCES

31、S;- 55 -3.6 系統(tǒng)啟動(dòng)順序 RealMainP模塊中軟件相關(guān)組件初始化；l TinyOS軟件組件的初始化是通過(guò)SoftwareInit接口與系統(tǒng)的各個(gè)不同的部分建立聯(lián)系，如果有一些只需運(yùn)行一次即可的代碼，比如某些初始化或配置工作，就可以把他們連接到SoftwareInit接口。 - 56 -3.6 系統(tǒng)啟動(dòng)順序RealMainP模塊中中斷使能；l當(dāng)調(diào)用Init.init命令的所有函數(shù)都返回后，才允許使能中斷。如果組件的初始化過(guò)程需要處理中斷，有以下幾種解決方法： p如果有中斷狀態(tài)標(biāo)識(shí)，例如，某個(gè)I/O口在中斷時(shí)是低電平，Init.init（）函數(shù)應(yīng)當(dāng)使用循環(huán)檢測(cè)的方法判斷有無(wú)中斷發(fā)生。 p如果沒(méi)有中斷狀態(tài)標(biāo)識(shí)，Init.init（）函數(shù)可以允許臨時(shí)使能中斷，前提是必須保證不會(huì)有其他組件來(lái)處理該中斷 p如果沒(méi)有中斷狀態(tài)表示且沒(méi)有隔離中斷處理程序的方法，則組件必須依賴(lài)初始化順序以外的機(jī)制，如Spl