TinyOS移植技術(shù)分析及在CC2430平臺(tái)的應(yīng)用
1.3 TinyOS的運(yùn)行機(jī)制
在TinyOS的總體框架中,物理層硬件層為框架的最底層,在該層中,傳感器、射頻收發(fā)器以及時(shí)鐘等硬件均能觸發(fā)事件(event)發(fā)生,交由上層組件處理;軟件層中相對(duì)下層的組件也能出發(fā)事件并交由上層處理,而上層會(huì)發(fā)出命令(command)交下層處理。為協(xié)調(diào)各組件間任務(wù)的有序處理,需要操作系統(tǒng)采取一定的調(diào)度模式。
TinyOS采用的是事件驅(qū)動(dòng)的兩級(jí)調(diào)度:任務(wù)(task)和硬件事件處理句柄(Hardware Event Handlers)。TinyOS使用兩種機(jī)制支持任務(wù),task和post。task聲明必須為無參數(shù)的函數(shù)聲明,執(zhí)行中的任務(wù)都具有原子操作性,任務(wù)完成前彼此之間不能被搶占。硬件事件處理句柄被執(zhí)行去響應(yīng)硬件中斷,可以搶占任務(wù)的運(yùn)行和其他硬件事件處理句柄。TinyOS的任務(wù)調(diào)度隊(duì)列只采用最簡(jiǎn)單的FIFO算法,內(nèi)核使用一個(gè)循環(huán)隊(duì)列來管理任務(wù)列表,默認(rèn)任務(wù)列表大小為8。這個(gè)任務(wù)隊(duì)列實(shí)際上是一個(gè)函數(shù)指針的數(shù)組,提交一個(gè)任務(wù)即是向隊(duì)列里插入一個(gè)函數(shù)指針。任務(wù)提交(post)到FIFO隊(duì)列中等待,當(dāng)任務(wù)隊(duì)列頭索引號(hào)等于尾索引號(hào)時(shí),表明任務(wù)隊(duì)列為空,系統(tǒng)進(jìn)入休眠狀態(tài)并等待,直到新的事件發(fā)生。如果新事件向隊(duì)列中提交了任務(wù),則處理器返回執(zhí)行狀態(tài),TinyOS規(guī)定當(dāng)且僅當(dāng)任務(wù)已經(jīng)推入隊(duì)列且沒有被執(zhí)行時(shí)post表達(dá)式才返回fail,否則將繼續(xù)休眠。當(dāng)被事件觸發(fā)后,TinyOS將中發(fā)出信號(hào)的事件關(guān)聯(lián)的所有任務(wù)將被迅速處理,當(dāng)這個(gè)時(shí)間和所有任務(wù)被處理完成后,未被使用的CPU將再次被置于睡眠狀態(tài)而不是積極尋找下一個(gè)活躍事件,從而大幅降低了功耗。
2 TinyOS的編譯過程分析
TinyOS的編譯系統(tǒng)采用GNU Make,首先將TinyOS應(yīng)用程序預(yù)編譯,形成一個(gè)“*.C”文件,然后將這個(gè)文件傳遞給與硬件平臺(tái)相對(duì)應(yīng)的編譯器。TinyOS的編譯系統(tǒng)放于support/make文件夾中,包含各個(gè)平臺(tái)的配置文件“*.target”和在這個(gè)平臺(tái)上建立應(yīng)用程序的“*.rul es”文件。所以TinyOS的編譯系統(tǒng)可以分為兩個(gè)部分:使用nesC編譯的公用部分和針對(duì)具體平臺(tái)的部分。目前TinyOS支持AVR的Mica系列節(jié)點(diǎn),還有基于MSP430芯片的Telos系列及基于PXA27芯片的Imote,而對(duì)于CC2430目前還在開發(fā)中。假設(shè)目標(biāo)平臺(tái)是MICA,其編譯過程如圖2所示。本文引用地址:http://www.ex-cimer.com/article/159772.htm
具體進(jìn)行編譯操作時(shí),編譯文件根據(jù)“TOSMAKE_PATH”變量中所列的路徑搜索“*.target”文件。“*.target”文件通常設(shè)置一些平臺(tái)相關(guān)變量和提供編譯平臺(tái)的名稱,并通過調(diào)用“TOSMake_include_platform”指向具體的“*.rules”文件。“*.rules”文件由平臺(tái)所配備的微處理器決定,因此通常幾個(gè)平臺(tái)共用一個(gè)“*.rules”文件。如果以命令行的形式給定一個(gè)虛擬平臺(tái),編譯系統(tǒng)會(huì)自動(dòng)尋找“*.ex tra”文件。
3 TinyOS操作系統(tǒng)在CC2430上的移植
3.1 CC2430的特點(diǎn)
CC2430單片機(jī)是TI公司生產(chǎn)的一款專用于IEEE 802.15.4和ZigBee協(xié)議通信的片上系統(tǒng)解決方案。它延用了以往CC2420芯片的架構(gòu),在單個(gè)芯片上整合了ZigBee射頻前端、內(nèi)存和微控制器。它使用1個(gè)8位MCU(8051),具有128 kB可編程閃存和8 kB的RAM,還包含模擬數(shù)字轉(zhuǎn)換器(ADC)、幾個(gè)定時(shí)器(Timer)、AES128協(xié)同處理器、看門狗定時(shí)器(Watchdog Timer)、32 kHz晶振的休眠模式定時(shí)器、通電復(fù)位電路(Pow er on Reset)、掉電檢測(cè)電路(Brownout Detection),以及21個(gè)可編程I/O引腳。CC2430芯片采0.18 μmCMOS工藝生產(chǎn);在接收和發(fā)射模式下,電流損耗分別低于27 mA或25 mA。CC2430非常適合那些要求能耗非常低的應(yīng)用,因?yàn)樗哂行菝吣J揭约稗D(zhuǎn)換到主動(dòng)模式的超短時(shí)間的特性。而無線傳感器網(wǎng)絡(luò)研究的一個(gè)核心問題就是節(jié)能,因?yàn)閭鞲衅鞴?jié)點(diǎn)經(jīng)常需要布置在環(huán)境惡劣的無人區(qū),所以能耗問題就成為一個(gè)關(guān)鍵問題。由于CC2430的低能耗特性,使其經(jīng)常作為傳感器節(jié)點(diǎn)的硬件平臺(tái)。
3.2 移植過程分析
TinyOS核心代碼經(jīng)nesC預(yù)編譯后形成的C文件可以被GCC理解編譯。而GCC適用的平臺(tái)包括telos系列,mica系列和intelmote2系列。但是一些平臺(tái)如Motorola HCS08,Intel MCS51則不適用于GCC編譯。所以將TinyOS移植到CC2430上的關(guān)鍵問題是,如何使GCC支持MCS-51系列的交叉編譯及支持CC2430硬件組件的編寫。
在Windows和Linux兩大主要平臺(tái)上有許多8051編譯器,其中使用最廣泛并且經(jīng)常進(jìn)行更新的有2種:KEIL和Small Device C Complier(SDCC)。由于SDCC是一個(gè)新興的開源項(xiàng)目,因此在移植過程中經(jīng)常會(huì)出現(xiàn)許多問題,使一些模塊無法正常工作。而且在調(diào)試中,SDCC只是簡(jiǎn)單地駐留在0地址,當(dāng)單步執(zhí)行代碼時(shí)也沒有任何調(diào)試信息。相比于SDCC,KEIL提供了一套良好的開發(fā)調(diào)試環(huán)境,因此,最終選用KEIL開發(fā)工具進(jìn)行TinyOS的移植工作。
具體流程如下:
(1)根據(jù)TinyOS上層組件接口的要求,用nesC語言編寫硬件表達(dá)層和硬件抽象層文件。
(2)使用TinyOS的NCC編譯器將編寫的應(yīng)用程序編譯成app.preMangle.c文件。
(3)將app.preMangle.c文件通過perl語言編寫的腳本將其原語法轉(zhuǎn)換為CC2430開發(fā)環(huán)境Keil支持的語法,生成app.c。
(4)利用KEIL開發(fā)工具將app.c編譯、連接,生成app.hex,再通過SmartRF04 Flash Programmer下載到目標(biāo)板。
3.3 TinyOS在CC2430上的移植過程
3.3.1 組件編寫
由于TinyOS的組件模式是基于不同抽象層組件的系統(tǒng),當(dāng)移植到新的平臺(tái)時(shí),可以通過添加新的底層硬件的抽象并使用已有的上層組件。為實(shí)現(xiàn)CC2430的基本功能,需要對(duì)各功能模塊進(jìn)行移植,文中移植的功能包括Timer定時(shí)器,UART通信,AD采樣,射頻通信等。具體模塊移植方法如下:
(1)通用I/O口。首先要對(duì)CC2430的各個(gè)接口進(jìn)行定義,CC2430共有21個(gè)可編程的I/O接口,通過設(shè)置一組寄存器來控制來控制這些接口作為通用I/O口或者是用作外部電路。在HplCC2430GeneralIOC文件及相關(guān)頭文件中對(duì)各個(gè)引腳進(jìn)行定義。由于需要用到CC2430的UART功能,ADC功能,射頻功能以及Timer定時(shí)器功能,所以需要對(duì)相應(yīng)的寄存器定義。
(2)UART通信。由于需要向上位機(jī)發(fā)送數(shù)據(jù),所以需要使用CC2430的UART通信功能。CC2430有兩個(gè)UART接口,分別為UART0和UART1。分別對(duì)應(yīng)CC2430兩個(gè)I/O接口。選用的UART1,RX和TX對(duì)應(yīng)P0_4接口和P0_5接口,通過SerialByteComm接口實(shí)現(xiàn)該功能。在HalCC2430SimpleUartP文件中實(shí)現(xiàn)SerialByteComm接口,該接口有兩個(gè)命令:get和put,分別用來對(duì)U1BUF寄存器進(jìn)行讀寫。在HplCC2430SimpleUartP文件中對(duì)CC24 30芯片串口通信所需要的配置的寄存器各位的值以及波特率等硬件信息進(jìn)行設(shè)置。
在PlatformSerialC文件中對(duì)這些接口進(jìn)行一個(gè)封裝,并對(duì)SerialByteComm接口的put操作作一個(gè)判斷,如果UART1的8位寄存器U1CSR的最低位為0,說明串口處于空閑狀態(tài),這是向串口發(fā)送數(shù)據(jù),否則串口處于繁忙狀態(tài),不進(jìn)行任何操作。
通過這3層組件對(duì)SerialByteComm接口的抽象,實(shí)現(xiàn)向串口發(fā)送數(shù)據(jù)的功能。
(3)數(shù)模轉(zhuǎn)換。通過傳感器感器采集到的模擬信號(hào),需要通過AD轉(zhuǎn)換為數(shù)字信號(hào)后才能進(jìn)行下一步的處理。CC2430的ADC有最高14 bit的轉(zhuǎn)換精度,可以采用內(nèi)部電壓或者外部電壓。ADCL和ADCH兩個(gè)8位寄存器存放采樣到的數(shù)據(jù),其中ADCL的有效位是2到7位,所以有效數(shù)據(jù)是14 bit。通過對(duì)READ接口的抽象實(shí)現(xiàn)該組件。在adc.h頭文件中配置CC2430的寄存器ADCCON1、ADCCON2、ADCCON3,可以設(shè)置轉(zhuǎn)換精度以及采樣到的數(shù)據(jù)傳輸?shù)叫酒墓苣_地址。
可以看到這里定義一組宏,對(duì)應(yīng)了寄存器需要的值。這里使用CC2430芯片的單次采樣,由于節(jié)點(diǎn)使用了外部傳感器這里將ADC的參考電壓設(shè)為外部電壓,精度設(shè)為14 bit,將P0_4引腳的電壓值數(shù)模轉(zhuǎn)換后傳入芯片處理器。
(4)定時(shí)器。CC2430有一個(gè)16位定時(shí)器Timer1和兩個(gè)8位定時(shí)器Timer3和Timer4,以及一個(gè)MAC定時(shí)器Timer2。這里完成了Timer1的移植。在HplCC2430Timer1P文件中定制相關(guān)配置,通過HplCC2430Timer16接口實(shí)現(xiàn)基本的計(jì)時(shí)功能。
(5)射頻模塊。傳感器節(jié)點(diǎn)采集到數(shù)據(jù)后需要通過無線射頻的方式發(fā)送出去,這就需要使用CC2430的射頻功能。TinyOS通過SimpleMac接口實(shí)現(xiàn)該功能,SimpleMac接口可以實(shí)現(xiàn)簡(jiǎn)單的數(shù)據(jù)收發(fā)功能。SimpleMac接口非常適合802.15.4協(xié)議,缺點(diǎn)是不支持?jǐn)?shù)據(jù)重傳和路由功能。在文件HPLCC2430RadioP文件及相關(guān)中對(duì)CC2430的的寄存器進(jìn)行讀寫,HALCC2430RadioP組建對(duì)它進(jìn)行進(jìn)一步的抽象。
3.3.2 編譯過程修改
為使TinyOS的編譯系統(tǒng)能夠找到目標(biāo)平臺(tái)CC2430,我們需要修改它的編譯環(huán)境?;赥inyOS開源代碼的約定,除核心程序外的其余項(xiàng)目開發(fā)放在contrib文件中。因此將代碼放于cygwin/opt/tinyos-2.x-contrib/ncepu中。這里需要在此文件夾中添加CC2430的編譯路徑以及具體的編譯方法。
評(píng)論