MQX-RTOS與NOS統一的工程框架構建與應用研究

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

計算機應用與軟件 2016年4期

關鍵詞：嵌入式工程

蔣建武王宜懷

蔣建武1,2王宜懷1

1(蘇州大學計算機科學與技術學院江蘇蘇州 215006)

2(泰州職業技術學院信息工程學院江蘇泰州 225300)

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

實時操作系統工程框架層次架構構件封裝

Jiang Jianwu1,2Wang Yihuai1

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

0 引言

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

1 AMQXFW工程框架建模

1.1 工程框架層次架構模型

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

圖1 工程框架層次架構圖

1.2 工程框架設計基本原則

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

(2) 目錄結構合理分類，兼容無操作系統構件化工程框架。通過分析MQX操作系統目錄名、文件名、文件內容的共性，進行歸納分類，實現兼容無操作系統構件化工程框架NOS(NOS-Framework)，將MQX封裝為可選的獨立構件，使用MQX設計應用系統時將該構件添加到AMQXFW工程框架中。

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

2 AMQXFW工程框架的組織結構

軟件工程思想中要求工程框架必須滿足結構清晰，文件內容安排合理，且具有可移植、易修改的特點[10]。根據工程框架層次架構設計思想構建了8個基本文件夾作為NOS工程框架，當工程需要使用MQX操作系統時，增加一個MQX可選配文件夾，由此構成了MQX-RTOS和NOS統一的工程框架AMQXFW。并按照工程框架層次架構中自底向上的順序對各文件夾進行編號內容如表1所示[7]。

為了適應當前時代的發展，相關部門要注重人才的培養，對播音主持行業的選聘制度進行一定的完善，從而促進新聞行業的不斷發展。為了提高人才的質量，電視臺應該根據實際情況建立一定的人才實習基地，為新聞主播行業培養一定的人才。電視臺在進行主持人的選聘時，要對選聘者進行全方面的考查，不只是理論水平，更為重要的是綜合實踐能力。同時，電視臺可以與當地的高校聯系，從高校選拔優秀的學生作為主持人的候補人選，然后為他們提供更好的平臺進行深造，加強專業素質。這在一定程度上激發了工作人員的積極性，對于電視臺新聞節目播音主持的發展有著非常重要的作用。

表1 工程框架目錄結構

2.1 工程框架結構分析

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

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

(2) 內核文件夾CPU

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

(3) 芯片文件夾MCU

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

(4) 鏈接文件Linker_Files

(5) 構件文件夾

在AMQXFW工程框架中包含了底層驅動構件文件夾Driver、軟件構件文件夾Soft_Compenent和應用構件文件夾App_Compenent。

底層驅動構件是和芯片功能模塊直接相關的驅動封裝，包括GPIO、UART等，此部分內容為通用MCU所共有的功能。因而在設計時其文件名、接口函數名稱以及相關參數均被統一設計后不作修改，具體實現方法根據芯片寄存器不同而調整相關代碼。

軟件構件是與CPU及MCU無關的通用軟件構件，包括隊列、鏈表等，此文件夾中相關構件的名稱和內容均不允許更改。

應用構件通過調用底層驅動構件和軟件構件完成特定功能設計，例如led、lcd、電機等硬件驅動，此文件夾中的文件名及內容封裝后均不可更改。使用不同芯片時只要修改底層驅動構件內容，而不需要更改應用構件的代碼。

(6) 源程序文件夾Source構件文件夾

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

2.2 工程框架可移植性分析

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

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

3 AMQXFW工程框架應用

工程框架應用到具體工程項目時首先根據所選內核、MCU以及開發環境進行框架移植，然后根據項目功能需求選擇相應的構件添加到框架中并完成配置，最后編制應用層程序代碼。在編制應用層代碼時為了使結構清晰易于維護，提高系統穩定性，要求遵循以下原則。

3.1 頭文件統一包含原則

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

3.2 全局變量統一聲明與初始化原則

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

3.3 外設模塊定期初始化與賦值原則

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

3.4 系統定期自動熱復位原則

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

MQX-RTOS與NOS統一的工程框架構建與應用研究

0 引 言

1 AMQXFW工程框架建模

2 AMQXFW工程框架的組織結構

3 AMQXFW工程框架應用

0 引言