實時操作系統mbedOS的移植方法①

劉長勇,王宜懷,彭 濤,孫亞軍,程宏玉

1(武夷學院 數學與計算機學院,武夷山 354300)

2(蘇州大學 計算機科學與技術學院,蘇州 215006)

3(認知計算與智能信息處理福建省高校重點實驗室,武夷山 354300)

實時操作系統(Real-Time Operating System,RTOS)的運用不僅能夠更有效、更合理的利用現有的CPU 資源,而且能夠簡化應用軟件的設計,縮短應用的開發時間、降低開發費用[1],保證系統的可靠性和實時性,那么如何實現RTOS 在不同的內核、微控制器(Micro Controller Unit,MCU)、開發環境等方面的移植,一直是工程技術界研究的共性技術.

目前在RTOS 的移植上已經有了一些研究,也提出相應的移植解決方法.如常華利等[2]提出了一種基于MicroBlaze 軟核處理器的μC/OS-II 的移植方案;唐小平[3]在深入分析μC/CPU 移植文件編寫與修改的細節的基礎上,給出了基于STM32F103RC 產品平臺下的μC/OS-Ⅲ成功移植案例;候海霞[4]對Free RTOS 操作系統和LwIP 協議棧進行了深入的研究,在STM32F407芯片上實現了Free RTOS 與LwIP 協議棧的移植;羅名駒[5]研究了如何移植引入設備樹的U-boot 和Linux內核到Samsung Exynos4412 芯片上的關鍵技術.但是,這些移植解決方案僅停留在解決如何將RTOS 移植到某一特定的MCU 上,而對不同的內核、MCU、開發環境等的移植情況鮮有研究.同時,有關mbedOS 的研究主要集中在通信技術和安全訪問服務機制[6]、協議棧和IP 網絡組件[7]、物聯網設備平臺[8,9]等方面.

2014年ARM 公司推出了mbedOS,它是一種專為物聯網 (IoT)中的“物體”設計的開源嵌入式實時操作系統[10],具有任務管理與調度、時間管理、中斷處理、內存管理、同步與通信等基本功能,對外提供統一的底層驅動接口,能滿足多任務的運行,具有較高的實時性.本文在深入剖析mbedOS 的基本功能和實時性要求上,根據嵌入式軟件工程的基本思想,以可擴充、可移植的mbedOS 工程框架為基礎,分析了移植的共性問題和注意事項,給出了具體的移植方法,解決了mbedOS 在不同的內核、MCU、開發環境等上的移植關鍵技術問題,為mbedOS 的應用研究提供了基礎,為mbedOS 的移植提供了一條簡捷、有效的路徑.

1 可移植的mbedOS 工程框架簡介

這里對基于MKL36Z64VLH4(簡稱KL36)微控制器的無操作系統工程框架SD-NOS 和可移植的SDmbedOS 工程框架的構建方法做個簡要的概述.

首先,根據無操作系統軟件最小系統的含義,建立包括說明文檔、內核相關文件、微控制器相關文件、用戶板構件、軟件構件、中斷服務程序和無操作系統主程序等嵌入式系統工程最基本要素的無操作系統工程框架SD-NOS.該工程框架能夠滿足點亮一盞發光二極管的最基本要求,甚至帶有串口調試構件.

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

最后,按照“分門別類、各有歸處”原則,對工程框架的文件夾和共性文件進行歸納分類,以編號的形式建立相應的文件夾存放源程序和頭文件,基于KL36微控制器,構建了可移植的SD-mbedOS 工程框架.表1給出了利用SD-mbedOS 工程框架在采用ARM Cortex-M 處理器的MCU 上進行移植時,需要替換、修改或添加的內容,對不需要改動的內容直接進行復制,其中底層構件僅包含最基本的通用輸入輸出gpio 構件和串口通信uart 構件.

表1 基于SD-mbedOS 工程框架的移植說明

2 mbedOS 移植涉及的文件變動及共性技術分析

移植必然涉及文件覆蓋與改動,也涉及到開發環境、編譯器、內核等共性問題,下面給出簡要分析.

2.1 工程框架內的文件變動問題

SD-mbedOS 工程框架是基于ARM Cortex-M0+內核的KL36 微控制器進行構建的,當采用該框架在ARM 內核的MCU 上進行mbedOS 移植時,會涉及到不同內核、不同MCU、不同開發環境等因素,其共性問題分析如下:

(1)mbedOS 文件的添加

由于要將mbedOS 移植到特定MCU 的嵌入式系統工程中,因此需將SD-mbedOS 工程框架下的02_Core 和07_mbedOS 文件夾內容添加到指定的工程中.

(2)MCU 相關文件的替換

不同的MCU,其內核、異常處理程序、鏈接文件、MCU 頭文件、MCU 啟動文件、底層硬件驅動構件、應用構件都有所不同.因此,需要根據實際采用的MCU 和應用需求,替換這些文件.若采用的MCU 為KL36,則不需進行替換.

(3)內核與MCU 相關文件的修改

不同MCU,其RAM 的起始地址和大小是不一樣的,中斷向量的個數也不相同,堆棧指針的棧底地址也不同.因此,需要對這些內容進行重新設置,以符合特定MCU 的要求.若采用的MCU 為KL36,則不需進行修改.

(4)頭文件的設置

由于MCU 發生了改變,需要將CMSIS 編譯器、內核頭文件以及MCU 頭文件加入到相關的文件中,這樣在編譯時才能找到指定的文件.

2.2 移植的共性技術分析

本文涉及到的MCU 雖然內核不相同、所采用的開發環境也不一樣,但都屬于ARM Cortex-M 處理器范疇,都遵循微控制器軟件接口標準(Cortex Microcontroller Software Interface Standard,CMSIS).mbedOS 是由ARM 公司開發,其內核程序也遵循CMSIS,且采用C++語言和匯編語言混合編程,這就要求開發環境集成的編譯器不僅能處理C++語句,而且還能編譯匯編語言指令,故一般都采用GCC(GNU Compiler Collection,GNU 編譯器套件)編譯器.因此,當在不同MCU 上進行mbedOS 移植時,必須分析開發環境、編譯器和內核等方面的設置和使用問題.

(1)與開發環境相關問題分析.由于開發環境不相同,會出現有些宏、數據類型、函數調用、靜態內聯函數等未定義情況,一方面是要在工程屬性中設置各文件夾及其子文件夾的路徑,另一方面則需要在相關文件中添加宏定義或頭文件.例如,在MSP432 開發環境中,需要在cmsis.h 中添加“__WEAK”宏定義解決弱定義錯誤、在cmsis_gcc.h 中添加“sys/_stdint.h”解決數據類型未定義問題、在鏈接文件中修改heap 段的結束標志“__end”為“__end__”;在S32K 開發環境中,需要在mbed_critical.c 中添加“cmsis_gcc.h”解決__disable_irq 等函數調用問題、在os_systick.c 中添加“core_cm4.h”和“system_S32k144.h”解決OS_Tick_Setup 等函數調用問題、在rtx_core_cm.h 中添加“core_cm4.h”解決靜態內聯函數未定義問題.

(2)與編譯器相關問題分析.mbedOS 是采用C++和匯編語言混合編程,不僅開發環境的編譯器要設置成能同時處理C++語句和匯編指令,而且有的開發環境還要求對.c 的源文件要進行特殊處理,才能滿足其要求.例如,在MSP432 開發環境CCS 中,默認編譯器采用“TI V5.2.5”版本,對編譯匯編文件和C++文件支持不足,故建議改為“GNU V7.2.1”,運行支持的類文件選擇“libsupc++.a”,同時添加名為“c”的libc.a 庫文件,這樣才能更好地實現對匯編指令和C++的編譯;在S32K 和MSP432 開發環境中,對.c 程序的編譯時會出錯,要進行特殊處理:一方面可以采用直接將其擴展名改為.cpp 的方式,另一方面若該.c 文件同時存在同名的.h 文件時,則可以通過“ifdef __cplusplus”預處理告之編譯器要以c 的形式處理這些文件.

(3)與內核相關問題分析.mbedOS 的SVC、PendSV、SysTick 等中斷服務程序是按照CMSIS 標準采用C++和匯編語言混合編程,對寄存器的使用遵循AAPCS 規范(ARM Archtecture Procedure Call Standard,ARM 架構過程調用標準).當MCU 的內核為Cortex-M0+時,采用R7 寄存器保存實際調用函數的入口地址;當采用Cortex-M4 或M4F 內核的MCU 時,則實際調用函數的入口地址保存在R12 寄存器中.因此,在編寫匯編程序時,要注意避開這兩個寄存器,改用其他寄存器,以避免程序執行時出現無法預計的情況.

3 mbedOS 的移植方法

在已有的無操作系統工程的基礎上,要將mbedOS移植到特定的嵌入式系統應用開發中,可以采用以下3 種方法進行移植:第1 種方法是自行分析mbedOS 代碼結構,根據應用開發的實際從中抽取相關文件加入到工程中,然后在工程進行編譯,修改相關的錯誤,對mbedOS 的移植有較大難度;第2 種方法是根據SDmbedOS 工程框架內的02_Core 和07_mbedOS 文件夾的內容,從mbedOS 代碼中直接抽取這些源文件,加入到工程中,然后進行編譯修改,對mbedOS 的移植有一定難度;第3 種方法是直接利用SD-mbedOS 工程框架,將其中的02_Core 和07_mbedOS 文件夾加入到工程中,根據工程具體情況只需少量的修改就可以使用,這樣可以少走彎路,更容易一些.下面介紹mbedOS 移植的第3 種方法.

3.1 幾款MCU 比較

本文分析的是基于KL36[11]的SD-mbedOS 工程框架在S32K144[12]和MSP432[13]等MCU 上的移植方法,這幾款MCU 均為ARM Cortex 處理器,但采用的內核、開發環境、Flash、RAM、中斷向量數以及生產廠家等都有所不同,具體對比如表2所示.

表2 不同MCU 的基本情況對比表

3.2 mbedOS 的移植步驟

當采用的MCU 為KL36 時,可以直接使用SDmbedOS 工程框架,只需根據實際應用的功能需求,修改08_mbedOsPrg 文件夾內的相關內容即可.當采用不同的MCU 時,mbedOS 的移植步驟分析如下:

(1)構建無操作系統工程框架.按照SD-NOS 工程框架的結構,根據所采用的MCU(其內核文件、鏈接文件和啟動文件等在購買該MCU 時廠家會提供或可從網絡上下載獲取),使用相應的開發環境搭建無操作系統工程框架.

(2)復制mbedOS 文件.由于02_Core 文件夾包含的內核頭文件、內核函數訪問頭文件、內核指令訪問頭文件以及編譯器頭文件等在mbedOS 中已有且略有不同.因此,先刪除這些文件,然后將SD-mbedOS框架中的02_Core 和07_mbedOS 文件夾的內容復制到無操作系統工程框架中,形成帶操作系統的工程框架.

(3)設置內核與MCU 相關文件.由于MCU 不同,其中斷向量個數、中斷向量表在RAM 的起始地址、RAM 的起始地址與大小、堆棧指針等也不一樣,要根據特定的MCU 進行重新設置;需要將MCU 的頭文件包含在微控制器軟件接口標準頭文件cmsis.h 和公共頭文件common.h 中;由于中斷向量表要從Flash 復制到RAM 中,需要在RAM 中預留出中斷向量數×4 的字節數來,故在鏈接文件中RAM 的起始地址要在原起始地址的基礎上加中斷向量數×4.具體需要設置的文件和內容如表3所示.

表3 mbedOS 在不同MCU 上移植主要內容修改對比表

(4)設置工程屬性.為了便于在函數調用中能找到相關的文件聲明位置,可以在工程配置文件中添加各個文件夾及子文件夾的路徑,同時添加相關宏定義,以便在函數調用時能找到這些頭文件和宏.

(5)與應用開發相關的內容設置.在實際的應用開發中,若有新增底層硬件構件、應用構件、軟件構件、用戶任務程序、中斷服務程序等,需要在總包含頭文件includes.h 中要包含各類構件頭文件、用戶函數聲明和中斷聲明.這一步根據需要進行設置,若無增加則不需要進行設置.

(6)編譯工程.在開發環境中對工程進行編譯,檢查并修改錯誤,編譯成功之后下載到開發板上運行,觀察運行結果.

3.3 移植測試

通過以上移植步驟,按照表3的修改內容以及共性技術分析的要點,就可以利用KL36 的SD-mbedOS工程框架將mbedOS 移植到以S32K 和MSP432 為MCU 的工程上.由于是針對mbedOS 進行移植測試,因此,在三款MCU 的工程中實現相同的任務功能,可以將KL36 工程中的藍燈任務、綠燈任務和紅燈任務這3 個任務程序代碼直接復制到S32K 和MSP432 工程中進行移植測試.移植測試工程實現藍燈任務、綠燈任務和紅燈任務分別每2 s、每1 s 和每3 s 閃爍1 次,由于篇幅有限,僅給出藍燈任務的程序代碼,綠燈任務和紅燈任務的程序代碼與藍燈任務的程序代碼基本一樣,只是延時時間不同而已,更加詳細的工程代碼與移植說明可到蘇州大學嵌入式學習社區網站(網址:http://sumcu.suda.edu.cn)的“教學培訓-教學資料-mbedOS”位置,下載“The Protability of mbedOS in MCUs_190928”查看.

藍燈任務代碼:

void run_bluelight(void)

{

while (true){

printf(" ***2-1.藍燈任務開始.*** ");

light_change(LIGHT_BLUE);//切換藍燈的亮暗

Thread::wait(2000);//延時2 秒

printf(" ***2-2.延時2 秒到切換藍燈亮暗.*** ");

printf(" ***2-3.藍燈任務結束.*** ");

}

}

圖1給出了mbedOS 在KL36 上的運行結果,以及在S32K 和MSP432 上的移植測試結果,從中可以看出在mbedOS 的調度下任務運行正常、程序執行邏輯準確,本測試工程涉及到RTOS 的任務調度、時間嘀嗒、延時函數、事件、消息隊列等基本要素,這些要素具有普適意義,程序的正常運行,表明移植成功.

圖1 mbedOS 在多個MCU 的移植測試結果

4 結論與展望

實時操作系統mbedOS 具有任務管理與調度、時間管理、中斷處理、內存管理、同步與通信等基本功能,能提供調度的實時性、響應時間的可確定性、系統高度的可靠性,在物聯網終端、工業控制設備、軍事設備、航空航天等領域得到廣泛應用.本文通過對mbedOS 的基本功能和實時性等方面進行深入剖析,根據嵌入式軟件工程的基本思想和嵌入式軟件構件設計的基本原則,以可移植、易擴充的SD-mbedOS 工程框架為基礎,分析了移植的共性技術和注意事項,給出了mbedOS 在ARM Cortex-M 系列的不同內核、MCU、開發環境等的移植解決方案,并完成了移植測試,為廣大嵌入式系統開發者在mbedOS 移植上少走彎路,提供了簡潔、方便的路徑,也可為其他RTOS 的移植提供參考.后續將針對mbedOS 的啟動、系統服務調用、任務調度等做進一下的研究探討.