蔣建武 王宜懷

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

蔣建武1,2王宜懷1

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

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

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

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

Jiang Jianwu1,2Wang Yihuai1

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

0 引 言

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

1 AMQXFW工程框架建模

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(3) 芯片文件夾MCU

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

(4) 鏈接文件Linker_Files

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

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

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

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

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

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

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

2.2 工程框架可移植性分析

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

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

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

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

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

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

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

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

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

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

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

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