構件化mbedOS工程框架研究與實現

劉長勇 王宜懷 彭 濤

1(武夷學院數學與計算機學院 福建 武夷山 354300) 2(蘇州大學計算機科學與技術學院 江蘇 蘇州 215006) 3(認知計算與智能信息處理福建省高校重點實驗室 福建 武夷山 354300)

0 引 言

隨著嵌入式技術的快速發展和硬件工藝水平的逐漸提高，微控制器(Microcontroller Unit，MCU)的性能、功能和種類也得到不斷更新，實時操作系統(Real-Time Operating System，RTOS)也逐漸成為嵌入式系統中不可或缺的部分。由于實時操作系統內核的底層性、代碼結構的復雜性、調度的實時性，從而增加了嵌入式軟件的開發難度、降低了開發效率。基于構件的設計技術越來越廣泛地應用于大規模、復雜嵌入式軟件開發[1]。通過對工程框架進行構件化的設計，將一個個相對獨立的、被充分證明為可靠的構件統一在一起，對外提供調用接口[2]，可以有效提高軟件的開發效率和軟件質量，并能縮短開發時間、降低開發費用[3]，使嵌入式軟件達到可適用、可移植和可修改性的目的。

目前已有很多關于嵌入式工程框架的研究，如劉宇傳等[4]提出基于Module-MSG(Module-Message)的軟件開發框架；戴巍等[5]利用組件的設計方法，將自頂向下和自底向上的開發方法相結合起來，提出了基于組件的嵌入式軟件框架設計；屈新懷等[6]采用抽象工廠設計模式和模型驅動思想，利用XML關系數據存儲機制和嵌入式SQL通信方式，提出可控嵌入式構件框架的開發方法；李運喜[7]從技術特征、能力組成、結構框架等角度對操作系統的軟件架構進行分析，提出一種統一的、開放的、彈性的操作系統軟件架構。

mbedOS是2014年由ARM公司出品的，是一種專為物聯網(IoT)中的“物體”設計的開源嵌入式操作系統[8-9]。其不僅兼顧不同的內核、不同的微控制器和不同的開發環境，而且也提供各種硬件驅動、多種網絡通信協議、各類測試用例和工具，這樣的RTOS無疑是全面且強大的。而對于一般的嵌入式應用開發，其針對的是某一特定的內核、具體型號的MCU和開發環境，要從龐大的RTOS中抽取出應用開發所需的內容是有較大難度的。因此，為了降低開發難度、提高開發效率，必須按照嵌入式軟件工程的基本思想和構件化的軟件技術的要求，對RTOS工程框架建立模型，以構件為基礎，規范文件組織結構，這樣才能使嵌入式系統開發者快速地使用RTOS進行軟件開發。本文闡述了RTOS軟件最小系統的概念，給出了mbedOS最基本功能要素的抽取原則，依據嵌入式軟件工程的基本理論和軟件構件化的基本方法，提出了工程框架的設計原則，形成了結構合理、可擴充的、構件化的mbedOS工程框架，分析了該工程框架的合理性和可移植性。實驗表明，該工程框架具有結構清晰、組織合理、可移植、可利用、可修改等特點。

1 RTOS軟件最小系統

1.1 系統定義

在嵌入式系統開發中，不僅涉及到硬件電路，而且還需要軟件編程。微控制器MCU的硬件最小系統是指包括電源、晶振、復位、寫入調試器接口等可使內部程序得以運行的、規范的、可復用的核心構件系統[10]。類比硬件最小系統，本文提出軟件最小系統的概念，它是包含工程最基本要素，能滿足點亮一個發光二管最基本要求，甚至帶有串口調試構件的工程框架，在此工程框架上用戶可以自行進行擴充，添加新的構件，形成新的工程框架。

定義1無操作系統軟件最小系統是指依據嵌入式軟件工程的基本原則與基本思想，將說明文檔、內核相關文件、微控制器相關文件、用戶板構件、軟件構件、中斷服務程序和無操作系統主程序等嵌入式系統工程最基本要素，按照構件化技術的基本理論組織成具有層次目錄結構的工程框架。該工程框架能有效地降低項目的開發難度，提高開發效率，具備良好的可擴充性、可描述性、可移植性、可復用性的特性。

定義2RTOS軟件最小系統是指將任務管理、調度管理、內存管理、中斷管理、時間管理以及同步與通信等RTOS最基本功能要素，以構件的形式添加到無操作系統軟件最小系統上，構成能至少實現對兩個任務進行調度的工程框架。

1.2 mbedOS抽取原則

為了能構建RTOS軟件最小系統，現以mbedOS為例介紹如何抽取RTOS的最基本功能要素。本文以5.7.4版本的mbedOS為研究對象，其源代碼[9]可以從網站下載，解壓后共包括2 503個文件夾和12 369個文件，所占空間達395 MB。它主要提供了內核管理、各類開發板外設定義與驅動、外設訪問接口和各類應用程序的測試用例等，這樣的操作系統是非常復雜且龐大的。但對于一般的嵌入式系統開發應用來說，它所采用的開發板在一個項目中通常情況只有一種。因此，必須從mbedOS代碼中進行合理的抽取，以適用于自己的應用開發，可以遵循以下抽取原則：

1) 只針對某一內核的微控制器MCU。根據嵌入式系統開發中所涉及到的MCU內核，抽取與MCU相關的內核文件。

2) 最基本功能要素。其基本滿足任務管理、內存管理、定時器管理、中斷管理、調度管理、同步與通信等功能。

3) 保留CMSIS編譯器相關文件。如CMSIS編譯器GCC頭文件、通用頭文件和版本頭文件等。

1.3 mbedOS最基本功能要素來源分析

按照以上抽取原則，去除外接組件、文檔、中間設備訪問層、硬件適配層、中間設備組件接口、目標板外設驅動、工具、USB驅動及各類測試等，主要保留了CMSIS編譯器與芯片相關文件和系統內核等最基本功能要素文件。按“分門別類、各有歸處”原則，將抽取后的文件分為編譯器類、芯片類、mbedOS管理類、mbedOS內核類及mbedOS保護類，分別放在不同的文件夾內。以MKL36Z64VLH4[11]微控制器(ARM Cortex-M0+內核)為例，介紹這些文件來源，詳見表1。由于篇幅有限，相同來源的文件未列出，具體可到蘇州大學嵌入式學習社區網站(http://sumcu.suda.edu.cn)的“教學培訓-教學資料-mbedOS”位置，下載“SD-mbedOS-Frame(KL36)”，查看測試工程的源代碼。

表1 抽取后的mbedOS各文件來源表

2 mbedOS工程框架設計

2.1 設計原則

1) 遵循嵌入式軟件工程的基本理論。工程框架的設計必須做到可理解、可移植、可修改，這樣才能使開發的嵌入式軟件具有完備性、正確性、健壯性和可靠性[12]。

2) 遵循嵌入式軟件構件設計基本思想和基本原則。軟件構件封裝前，最關鍵的工作是要對構件的共性和個性進行分析，設計出合理的、必要的對外接口函數及其形參，以知識要素為核心，以模塊獨立性為準則進行封裝。盡量做到：當一個底層構件應用到不同系統中時，僅需修改構件的頭文件，對構件的源程序文件則不必修改或改動很小[10]。

3) 按照“分門別類、各有歸處”原則。對工程框架的文件夾和共性文件進行歸納分類，以編號的形式建立相應的文件夾存放源程序和頭文件。

2.2 結構分析

基于以上的設計原則，將各類驅動、mbedOS以及用戶程序等均以構件的形式進行設計，形成mbedOS的構件化工程框架SD-mbedOS。該工程框架采用三層邏輯架構，即硬件層、中間層和應用層。硬件層包括內核訪問層和微控制器訪問層，其中芯片訪問層包含硬件驅動構件、鏈接文件和啟動文件，內核訪問層包括編譯器頭文件、中斷嵌套控制寄存器和異常處理程序。中間層包括軟件構件、應用構件和實時操作系統。應用層包括中斷處理程序、無操作系統主程序、操作系統啟動程序、自啟動任務執行程序和用戶任務程序等。SD-mbedOS工程框架的層次模型與樹形結構的對應關系如圖1所示。

圖1 mbedOS工程框架層次模型與樹形結構對應關系

SD-mbedOS工程框架的樹形結構包含8個帶編號文件夾，其簡明功能及特點如表2所示。

表2 SD-mbedOS工程文件夾內的基本內容

續表2

2.3 可移植性分析

工程框架的可理解、可移植、可復用是其價值的重要體現，良好的工程框架應該能在不同的內核、MCU、工程及開發環境之間進行有效移植。本文工程框架在設計時就已經考慮到可移植性問題，在設計文件夾時將文件按照“分門別類、各有歸處”的原則放到相應的文件夾中，在進行框架移植時只要修改少量的內容就可完成。由于篇幅有限，表3列出了SD-mbedOS工程框架在MKL36Z64VLH4(簡稱KL36)、S32K144[13]和MSP432[14]三款MCU上的移植比較。

表3 SD-mbedOS工程框架在多個MCU上移植

注：表中的數字采用十六進制表示。

3 SD-mbedOS工程框架的應用與測試

3.1 測試工程的基本功能

測試工程在Kinetis Design Studio 3.0.0 IDE集成開發環境和金葫蘆AHL-A系列Cortex-M0+內核的KL36微控制器(即AHL-AN100VL型號開發板)上進行。該開發板集成了SWD寫入器、串口、三色燈、光敏電阻、磁阻、熱敏電阻、LCD液晶、觸摸感應接口TSI及用標準排針引出芯片的所有引腳，可以滿足一般嵌入式應用開發的需要。本測試工程設計了三個任務，紅燈任務每3秒閃爍一次，藍燈任務每2秒閃爍一次，綠燈任務每1秒閃爍一次。

為實現以上各功能，需要在08_mbedOsPrg文件夾下添加自啟動任務執行函數app_init、紅燈任務thd_redlight、藍燈任務thd_bluelight和綠燈任務thd_greenlight。自啟動任務執行函數app_init的執行流程如圖2所示，紅燈任務(或藍燈任務、綠燈任務)的執行流程如圖3所示。

圖2 app_init執行流程

圖3 小燈執行流程

3.2 工程的運行測試

將測試工程編譯后下載到開發板上，重新上電啟動芯片，可以觀察到紅燈任務每3秒閃爍一次，藍燈任務每2秒閃爍一次，綠燈任務每1秒閃爍一次。同時可以通過串口調試器輸出各燈任務的切換情況。工程測試的運行結果如圖4所示。可以看出在mbedOS的調度下任務運行正常，程序執行邏輯準確，實時性能得到滿足。

圖4 測試工程運行結果

4 結 語

實時操作系統mbedOS為不同的內核、MCU、開發環境、芯片生產廠家和用戶提供了微控制器軟件接口標準、各類通用庫函數、目標板外設驅動、各類測試用例等豐富的資源，是一個龐大且功能強大的體系。任一工程師或用戶在某一特定的應用開發中，一般是選用某一具體內核的MCU，要從這樣一個龐大的資源體系中抽取出與開發相關的內容是有一定難度和困難的，需要花費大量的時間和精力。本文深入剖析mbedOS龐大資源的構成，厘清其結構關系、文件包含、宏定義、各類管理機制，根據嵌入式軟件工程的基本思想，基于mbedOS提出了以構件為基礎、以軟件最小系統為核心的可移植、易擴充的工程框架，為廣大嵌入式系統開發者快速應用、透徹理解mbedOS提供了基礎，也為mbedOS的升級、MCU的變更、硬件驅動的增加等提供了良好的擴充模板。未來將針對內核、MCU、開發環境、應用需求等有關mbedOS移植的問題作進一步的討論。