MQX-RTOS與NOS統(tǒng)一的工程框架構(gòu)建與應(yīng)用研究

2016-05-09 07:07:38蔣建武王宜懷

計算機(jī)應(yīng)用與軟件 2016年4期

關(guān)鍵詞：嵌入式工程

蔣建武王宜懷

蔣建武1,2王宜懷1

1(蘇州大學(xué)計算機(jī)科學(xué)與技術(shù)學(xué)院江蘇蘇州 215006)

2(泰州職業(yè)技術(shù)學(xué)院信息工程學(xué)院江蘇泰州 225300)

嵌入式工程框架的構(gòu)建過程是一項技術(shù)性要求高且實(shí)用性價值大的專業(yè)性工作，必須將嵌入式軟件開發(fā)中構(gòu)件化設(shè)計思想與軟件工程中文檔優(yōu)先性、結(jié)構(gòu)合理性、代碼可重用性、可移植性和可維護(hù)性等理論相融合。針對帶嵌入式操作系統(tǒng)和無操作系統(tǒng)的兩種工程框架的共性特點(diǎn)，通過對MQX操作系統(tǒng)的啟動流程、中斷機(jī)制、調(diào)度算法等進(jìn)行深入剖析，提出一種有無操作系統(tǒng)相統(tǒng)一的層級架構(gòu)工程框架建模思想，構(gòu)建AMQXFW(All-In-One MQX Framework)工程框架。實(shí)驗(yàn)結(jié)果表明，該工程框架在不同內(nèi)核、芯片、開發(fā)環(huán)境和工程環(huán)境之間進(jìn)行移植時效率更高，同時為了保證系統(tǒng)穩(wěn)定性給出了工程框架的應(yīng)用原則。

實(shí)時操作系統(tǒng) 工程框架層次架構(gòu) 構(gòu)件封裝

Jiang Jianwu1,2Wang Yihuai1

2(DepartmentofElectronicandInformationEngineering,TaizhouPolytechnicCollege,Taizhou225300,Jiangsu,China)

0 引言

嵌入式工程框架是在IDE開發(fā)環(huán)境下進(jìn)行嵌入式工程項目開發(fā)的基礎(chǔ)，包含了工程目錄結(jié)構(gòu)、文件的布局以及相關(guān)配置等信息，通常利用開發(fā)環(huán)境的模板自動生成。通過對CodeWarrior、IAR以及Keil等主流嵌入式開發(fā)工具生成模板的研究發(fā)現(xiàn)，這些利用模板生成的工程框架存在很強(qiáng)的定制性。隨開發(fā)環(huán)境、所選內(nèi)核、主控芯片等因素的不同，生成的工程框架在目錄結(jié)構(gòu)和文件布局上存在著很大差異，特別是有無操作系統(tǒng)兩種情況下，工程框架的結(jié)構(gòu)更是大相徑庭。這顯然與軟件工程思想中對于工程架構(gòu)的結(jié)構(gòu)清晰、可移植性和可復(fù)用性要求相悖。基于以上原因，眾多文獻(xiàn)對于工程框架規(guī)范化進(jìn)行了研究：戴明華等探析了基于Linux內(nèi)核的Android操作系統(tǒng)的驅(qū)動框架實(shí)現(xiàn)[1]；蘇玉強(qiáng)等采用MVC/P及Observer等設(shè)計模式設(shè)計一種基于消息的應(yīng)用程序框架結(jié)構(gòu)[2]；朱仕浪等對工程框架進(jìn)行了初步研究，在分析MQX內(nèi)核特點(diǎn)與體系構(gòu)架的基礎(chǔ)上,提出了一種構(gòu)件化MQX-RTOS應(yīng)用工程框架[3]；石晶等重點(diǎn)研究了MQX中的中斷程序架構(gòu)[4]。在眾多研究中，主要還是針對使用特定的嵌入式操作系統(tǒng)時工程框架的設(shè)計，這些工程框架在無操作系統(tǒng)NOS(No Operation System)開發(fā)環(huán)境下難以使用，也無法在不同RTOS間相互遷移。本文通過分析MQX-RTOS工程框架結(jié)構(gòu)和實(shí)現(xiàn)機(jī)理，將與RTOS無關(guān)的部分剝離，使之獨(dú)立與RTOS之外，將RTOS實(shí)現(xiàn)部分封裝為工程框架的一個可選組件，由此形成了一個MQX-RTOS與NOS統(tǒng)一的工程框架AMQXFW。

1 AMQXFW工程框架建模

1.1 工程框架層次架構(gòu)模型

本工程框架采用三層邏輯架構(gòu)，即硬件抽象層、構(gòu)件層以及應(yīng)用層。硬件抽象層分為三部分：內(nèi)核級訪問層、芯片級訪問層和鏈接文件，主要包含芯片上電后復(fù)位啟動時所用到的相關(guān)文件。內(nèi)核級訪問層主要定義了核內(nèi)特殊寄存器、中斷嵌套控制寄存器以及調(diào)試子系統(tǒng)的訪問接口[4]。芯片級訪問層主要定義設(shè)備外設(shè)硬件寄存器地址以及中斷和異常號。為了保證應(yīng)用程序的安全性，硬件抽象層只能夠供底層驅(qū)動構(gòu)件調(diào)用，對于應(yīng)用層來說，硬件抽象層完全是屏蔽的。構(gòu)件層分為三個部分：底層驅(qū)動構(gòu)件、軟件構(gòu)件以及應(yīng)用構(gòu)件。用戶代碼包括中斷服務(wù)例程和用戶主程序，當(dāng)應(yīng)用工程不使用嵌入式操作系統(tǒng)時不需要包含MQX相關(guān)內(nèi)容。如圖1所示。

圖1 工程框架層次架構(gòu)圖

1.2 工程框架設(shè)計基本原則

(1) 遵循軟件工程中可復(fù)用、可移植、容易理解和維護(hù)的基本思想，為提高嵌入式軟件的開發(fā)效率、縮短開發(fā)周期打下基礎(chǔ)[5]。

(2) 目錄結(jié)構(gòu)合理分類，兼容無操作系統(tǒng)構(gòu)件化工程框架。通過分析MQX操作系統(tǒng)目錄名、文件名、文件內(nèi)容的共性，進(jìn)行歸納分類，實(shí)現(xiàn)兼容無操作系統(tǒng)構(gòu)件化工程框架NOS(NOS-Framework)，將MQX封裝為可選的獨(dú)立構(gòu)件，使用MQX設(shè)計應(yīng)用系統(tǒng)時將該構(gòu)件添加到AMQXFW工程框架中。

(3) 可復(fù)用與可移植的前提是以構(gòu)件為基礎(chǔ)，構(gòu)件封裝前,首先要研究同類構(gòu)件的共性以及待封裝構(gòu)件的個性特征，抽象出構(gòu)件的特性以及必要的接口函數(shù)及其相應(yīng)的接口參數(shù)。使得構(gòu)件在不同CPU、MCU、IDE間移植時，僅修改頭文件相關(guān)的配置參數(shù),包括對應(yīng)IO接口、寄存器接口、開關(guān)信號定義等，而相應(yīng)的源文件盡可能少做改動[6]。

2 AMQXFW工程框架的組織結(jié)構(gòu)

軟件工程思想中要求工程框架必須滿足結(jié)構(gòu)清晰，文件內(nèi)容安排合理，且具有可移植、易修改的特點(diǎn)[10]。根據(jù)工程框架層次架構(gòu)設(shè)計思想構(gòu)建了8個基本文件夾作為NOS工程框架，當(dāng)工程需要使用MQX操作系統(tǒng)時，增加一個MQX可選配文件夾，由此構(gòu)成了MQX-RTOS和NOS統(tǒng)一的工程框架AMQXFW。并按照工程框架層次架構(gòu)中自底向上的順序?qū)Ω魑募A進(jìn)行編號內(nèi)容如表1所示[7]。

為了適應(yīng)當(dāng)前時代的發(fā)展，相關(guān)部門要注重人才的培養(yǎng)，對播音主持行業(yè)的選聘制度進(jìn)行一定的完善，從而促進(jìn)新聞行業(yè)的不斷發(fā)展。為了提高人才的質(zhì)量，電視臺應(yīng)該根據(jù)實(shí)際情況建立一定的人才實(shí)習(xí)基地，為新聞主播行業(yè)培養(yǎng)一定的人才。電視臺在進(jìn)行主持人的選聘時，要對選聘者進(jìn)行全方面的考查，不只是理論水平，更為重要的是綜合實(shí)踐能力。同時，電視臺可以與當(dāng)?shù)氐母咝Ｂ?lián)系，從高校選拔優(yōu)秀的學(xué)生作為主持人的候補(bǔ)人選，然后為他們提供更好的平臺進(jìn)行深造，加強(qiáng)專業(yè)素質(zhì)。這在一定程度上激發(fā)了工作人員的積極性，對于電視臺新聞節(jié)目播音主持的發(fā)展有著非常重要的作用。

表1 工程框架目錄結(jié)構(gòu)

2.1 工程框架結(jié)構(gòu)分析

(1) 工程根文件夾與工程文檔Doc

為了便于管理將工程框架中所有的文件均存放在工程根目錄文件夾下，其名稱可根據(jù)實(shí)際工程內(nèi)容修改。根據(jù)軟件工程中文檔優(yōu)先的原則，在軟件編碼前要有詳細(xì)的功能文檔描述[8]，因而在工程框架中專門開辟了一個文件夾Doc用于存放系統(tǒng)文檔。其中文本文件Readme是整個工程項目的總描述文檔，記載了工程名稱、版本號、修改時間等基本信息。

(2) 內(nèi)核文件夾CPU

處理器內(nèi)核選擇是工程項目開發(fā)前必須要考慮的問題，ARM公司的內(nèi)核管理運(yùn)營模式興起后各內(nèi)核廠家紛紛效仿，內(nèi)核廠家只設(shè)計與維護(hù)內(nèi)核架構(gòu)而不直接生產(chǎn)芯片[9]。內(nèi)核相關(guān)的源代碼也由內(nèi)核廠家維護(hù)與發(fā)布，因而在工程框架設(shè)計時也將內(nèi)核相關(guān)文件從芯片文件中剝離獨(dú)立存儲于CPU目錄下，以便在內(nèi)核升級時減少代碼修改量，僅修改CPU夾下相關(guān)文件名稱及相關(guān)內(nèi)容即可。

(3) 芯片文件夾MCU

嵌入式系統(tǒng)的啟動過程與具體的芯片相關(guān)，一旦芯片確定，芯片頭文件、中斷向量表以及啟動代碼等內(nèi)容也是相對固定的。因而將這些文件統(tǒng)一存放在MCU文件夾中，為了提高啟動部分代碼的重用性，MCU文件夾中除了芯片頭文件可以更改文件名外，其他文件名相對固定。工程中使用不同的MCU或芯片文件升級時，僅需調(diào)整頭文件及部分代碼即可完成，芯片相關(guān)文件可從芯片廠商網(wǎng)站獲取。

(4) 鏈接文件Linker_Files

(5) 構(gòu)件文件夾

在AMQXFW工程框架中包含了底層驅(qū)動構(gòu)件文件夾Driver、軟件構(gòu)件文件夾Soft_Compenent和應(yīng)用構(gòu)件文件夾App_Compenent。

底層驅(qū)動構(gòu)件是和芯片功能模塊直接相關(guān)的驅(qū)動封裝，包括GPIO、UART等，此部分內(nèi)容為通用MCU所共有的功能。因而在設(shè)計時其文件名、接口函數(shù)名稱以及相關(guān)參數(shù)均被統(tǒng)一設(shè)計后不作修改，具體實(shí)現(xiàn)方法根據(jù)芯片寄存器不同而調(diào)整相關(guān)代碼。

軟件構(gòu)件是與CPU及MCU無關(guān)的通用軟件構(gòu)件，包括隊列、鏈表等，此文件夾中相關(guān)構(gòu)件的名稱和內(nèi)容均不允許更改。

應(yīng)用構(gòu)件通過調(diào)用底層驅(qū)動構(gòu)件和軟件構(gòu)件完成特定功能設(shè)計，例如led、lcd、電機(jī)等硬件驅(qū)動，此文件夾中的文件名及內(nèi)容封裝后均不可更改。使用不同芯片時只要修改底層驅(qū)動構(gòu)件內(nèi)容，而不需要更改應(yīng)用構(gòu)件的代碼。

(6) 源程序文件夾Source構(gòu)件文件夾

應(yīng)用層代碼是開發(fā)人員修改最多的部分，當(dāng)開發(fā)環(huán)境搭建好時其他文件夾中的內(nèi)容基本固定，所有后期的功能調(diào)試均集中在應(yīng)用層。為此將該部分內(nèi)容集中存儲于源程序文件夾Source，包含了工程項目的總頭文件include.h、主程序main.c以及中斷處理相關(guān)頭文件isr.h和源文件isr.c，這些文件名均固定不變，文件內(nèi)容根據(jù)工程項目內(nèi)容修訂。當(dāng)使用MQX操作系統(tǒng)時仍保留main.c文件，但是其完成的任務(wù)就是啟動MQX系統(tǒng)調(diào)度將系統(tǒng)控制權(quán)轉(zhuǎn)交給MQX操作系統(tǒng)的調(diào)度任務(wù)，相關(guān)應(yīng)用層的代碼也轉(zhuǎn)移到MQX文件夾中的app_inc.h和task_main.c中編制。由于有無操作系統(tǒng)對于中斷處理的流程是一致的，所以兩種情況下的中斷處理均在Source文件夾的isr.h和isr.c中完成[10]。

2.2 工程框架可移植性分析

工程框架的可移植性是其價值的重要體現(xiàn)，良好的工程框架應(yīng)該能在盡量少改動的情況下就能完成在不同內(nèi)核、不同芯片、不同工程以及不同開發(fā)環(huán)境之間進(jìn)行移植。本工程框架在設(shè)計時已經(jīng)考慮到可移植性問題，在設(shè)計文件夾時將文件按照功能集中歸口到相應(yīng)的文件夾中，在進(jìn)行框架移植時只要修改少量的幾個文件夾中的內(nèi)容就可完成[11]。在文件目錄可修改性分析中已對各目錄結(jié)構(gòu)中文件名稱內(nèi)容的修改性做了詳細(xì)分析，如表2所示。由于篇幅有限，關(guān)于移植性問題將另文詳細(xì)討論。

表2 工程框架目錄移植修改表

3 AMQXFW工程框架應(yīng)用

工程框架應(yīng)用到具體工程項目時首先根據(jù)所選內(nèi)核、MCU以及開發(fā)環(huán)境進(jìn)行框架移植，然后根據(jù)項目功能需求選擇相應(yīng)的構(gòu)件添加到框架中并完成配置，最后編制應(yīng)用層程序代碼。在編制應(yīng)用層代碼時為了使結(jié)構(gòu)清晰易于維護(hù)，提高系統(tǒng)穩(wěn)定性，要求遵循以下原則。

3.1 頭文件統(tǒng)一包含原則

為了避免交叉包含，應(yīng)用層使用的構(gòu)件頭文件均包含在項目總頭文件(NOS框架下的includes.h文件或MQX-RTOS框架下的app_inc.h文件)中，而其他使用到構(gòu)件的源文件均在其頭部添加對這兩個文件的引用。

3.2 全局變量統(tǒng)一聲明與初始化原則

全局變量的聲明操作在項目總頭文件中，且要求在申明的時候不賦值。全局變量的初始化在項目主程序(NOS框架下的main函數(shù))或主任務(wù)函數(shù)文件(MQX-RTOS框架下的task_main任務(wù)函數(shù))中完成。這樣在芯片熱復(fù)位后就可以跳過全局變量的初始化操作，使系統(tǒng)能恢復(fù)到熱復(fù)位前的工作狀態(tài)[12]。

3.3 外設(shè)模塊定期初始化與賦值原則

通常外設(shè)模塊的初始化和賦值在系統(tǒng)中僅執(zhí)行一次，然而在系統(tǒng)運(yùn)行過程中由于各種原因可能導(dǎo)致外設(shè)控制配置出錯或狀態(tài)非法改變，這樣就導(dǎo)致了外設(shè)出錯且不會恢復(fù)[12]。因而要求在系統(tǒng)運(yùn)行過程中要求將外設(shè)模塊的初始化操作和賦值操作定期地重復(fù)執(zhí)行一遍，由此保證即使有干擾對外設(shè)產(chǎn)生影響，外設(shè)也能很快地恢復(fù)正常。此操作也在項目主程序中(main函數(shù)或task_main任務(wù)函數(shù))完成，定期刷新的時間要根據(jù)具體工程項目測試獲得。

3.4 系統(tǒng)定期自動熱復(fù)位原則

當(dāng)系統(tǒng)長時間運(yùn)行后會產(chǎn)生一些難以預(yù)知的異常狀況，而且此類異常狀況具有不可復(fù)現(xiàn)性，但是通過復(fù)位操作可以解決大部分的未知異常，因而要求系統(tǒng)能定期自動完成復(fù)位重啟操作，從而提高系統(tǒng)的穩(wěn)定性。此操作在NOS工程中在main函數(shù)的主循環(huán)中通過計數(shù)定時實(shí)現(xiàn)，在帶MQX操作系統(tǒng)工程中可通過設(shè)計定時任務(wù)完成(定時任務(wù)函數(shù)存放于..

MQX-RTOS與NOS統(tǒng)一的工程框架構(gòu)建與應(yīng)用研究

0 引 言

1 AMQXFW工程框架建模

2 AMQXFW工程框架的組織結(jié)構(gòu)

3 AMQXFW工程框架應(yīng)用

0 引言