構(gòu)件化mbedOS工程框架研究與實現(xiàn)

劉長勇 王宜懷 彭 濤

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

0 引 言

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

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

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

1 RTOS軟件最小系統(tǒng)

1.1 系統(tǒng)定義

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

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

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

1.2 mbedOS抽取原則

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

1) 只針對某一內(nèi)核的微控制器MCU。根據(jù)嵌入式系統(tǒng)開發(fā)中所涉及到的MCU內(nèi)核，抽取與MCU相關的內(nèi)核文件。

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

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

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

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

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

2 mbedOS工程框架設計

2.1 設計原則

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

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

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

2.2 結(jié)構(gòu)分析

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

圖1 mbedOS工程框架層次模型與樹形結(jié)構(gòu)對應關系

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

表2 SD-mbedOS工程文件夾內(nèi)的基本內(nèi)容

續(xù)表2

2.3 可移植性分析

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

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

注：表中的數(shù)字采用十六進制表示。

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

3.1 測試工程的基本功能

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

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

圖2 app_init執(zhí)行流程

圖3 小燈執(zhí)行流程

3.2 工程的運行測試

將測試工程編譯后下載到開發(fā)板上，重新上電啟動芯片，可以觀察到紅燈任務每3秒閃爍一次，藍燈任務每2秒閃爍一次，綠燈任務每1秒閃爍一次。同時可以通過串口調(diào)試器輸出各燈任務的切換情況。工程測試的運行結(jié)果如圖4所示?？梢钥闯鲈趍bedOS的調(diào)度下任務運行正常，程序執(zhí)行邏輯準確，實時性能得到滿足。

圖4 測試工程運行結(jié)果

4 結(jié) 語

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