基于STM32的mbed OS移植與低功耗研究

張 翔，楊東升

1(中國科學院 沈陽計算技術研究所有限公司，沈陽 110168)

2(中國科學院大學，北京 100049)

E-mail:492490817@qq.com

1 引 言

物聯網操作系統的概念，最先來自于無線傳感器操作系統，知名的有TinyOS 和Contiki.與傳統的嵌入式設備相比，物聯網感知層具有更小的設備、更低的功耗、更高的安全性和更靈活的聯網能力；物聯網通信層需要支持各種通信協議和協議轉換；應用層需要云計算能力；在軟件方面，支持物聯網設備的軟件比傳統的嵌入式設備軟件更加復雜[1].于是就有了物聯網操作系統IoT OS，簡而言之，IoT OS就是具備物聯網需求的嵌入式操作系統.從2014年至今，陸續出現了支持不同廠商的MCU設備的IoT OS，ARM mbed OS正是其中突出的一員.

物聯網技術現已被廣泛應用于智能電網、智能交通、環境監測等各種領域[2,3]，為了適應新的物聯網時代的變化，ARM提供了一個全新的開發方式，Arm mbed將物聯網的所有基本組件(包括安全性，通信和設備管理)集成到一整套軟件中，以協助開發低功耗、產品級的物聯網設備和并優化生產流程.mbed包括了云服務、客戶端、mbed OS等幾大部分.在mbed 上可以使用mbed TSL實現網絡安全協議，也可以實現CoAP 這樣的物聯網協議，支持訪問Restful API來接入中國移動的OneNet物聯網云端服務[4].Arm 公司希望mbed成為物聯網領域的android，在mbed OS 中注入了大量的最新技術.本文正是在此背景下，針對mbed OS的功能需求進行研究，由于mbed OS目前僅支持受限的開發板型號，提出了一套mbed OS的移植流程，并在STM32設備上驗證，并提出了低功耗優化方案，增加了低功耗看門狗功能，測試了系統功耗水平.

2 mbed OS概述

mbed不僅僅指一個嵌入式系統,也是一個面向ARM處理器的設備開發平臺，Arm mbed提供高效，安全，快速開發下一個物聯網產品所需的操作系統，工具和云服務，內容涉及從硬件到軟件、從物端到云端等，功能包括安全、通信傳輸、設備管理等方面，為實現物聯網從原型、開發到生產的快速便捷.

mbed OS為免費的開源物聯網操作系統，面向Cortex-M系列處理器，它通過mbed web complier在線編譯，代替了傳統的離線編譯器，使整個開發在瀏覽器中完成，使用它編譯程序而不必安裝或設置任何東西，為了省去用戶開發環境搭建的麻煩，用戶只要上網就可以開發[5].mbed將硬件相關程序使用中間件封裝，因此基于mbed OS的開發只用專注于編寫調用硬件功能接口的C/C++應用程序，而不需要關心底層驅動，極大限度地降低了嵌入式開發的難度,簡化了軟件開發流程，縮短了開發中的學習過程[6].同時mbed OS搭載CMSIS框架,CMSIS專為Cortex-M而設計，是獨立于供應商的硬件抽象層[7].它屏蔽了微處理器之間的差異，使得基于mbed的用戶可以輕松地替換來自不同制造商的ARM微處理器，而不用更改工程代碼.

對于嵌入式開發，mbed OS最大的幫助就是提供了許多有用的組件，它提供的強大的API功能幾乎包含控制器內部各種模塊的使用，如串行通信、中斷、模擬/數字信號、網絡接口等，使用mbed編寫簡單的應用程序只需要短短的幾行代碼[8].它的Libraries提供了各種硬件、傳感器的庫，使得設備接入更加快捷.mbed OS與Arduino非常相似，Arduino具有便捷靈活、方便上手的特點，在嵌入式程序中非常流行[9].同樣的，它們易于使用，直觀的編程和設計，降低了開發門檻，使得初學者也能快速獲得足以創造具有某種技術水平的新產品的能力[10]，但是mbed的功能更加強大，應用領域更廣.

3 mbed在STM32上的移植

mbed采用網頁編譯方式，通過在線選擇mbed支持的開發板型號，從而屏蔽掉硬件驅動部分，在方便的同時卻存在芯片的局限性，也存在無法調試等問題.目前mbed已經逐步支持200多種芯片，但是想讓mbed OS支持其他型號的MCU需要移植.mbed OS作為軟件層面的系統支持，移植則是必要任務.

3.1 mbed代碼目錄

圖1為mbed的代碼層次結構，它包括以下內容：

drivers：drivers目錄中存放的是用戶需要調用的mbed相關的.h頭文件;

events:事件框架;

features：支持的功能，包括BLE、LWIP、TLS等;

hal：mbed OS定義的API函數，依賴于TARGETS目錄提供的硬件適配支持;

RTOS：mbed實時操作系統文件;

CMSIS：MCU與外設之間的軟件接口標準及啟動鏈接文件;

targets：特定開發板實現hal需要的接口、連接腳本文件、使用的CMSIS頭文件.

其中drivers、events、features、hal、RTOS為MCU無關層，CMSIS、targets為MCU有關層.

圖1 mbed OS代碼目錄

3.2 mbed OS移植方案

本次移植在編譯環境Keil uvision 5上進行，通過導出mbed工程源碼，通過更改底層參數配置、部分代碼、芯片庫文件等方式，通過移植mbed OS到STM32L100R8T6及STM3-2F103RET6中，驗證了移植流程.

3.2.1 導出工程源碼

為了更快速地建立Keil工程，選擇在mbed在線編譯器中導出工程源碼.在mbed compiler中點擊Add Board,界面中展示的是mbed支持的開發板型號，使用這些開發板可以直接使用網頁編譯工程，并直接燒錄進mbed中，而其他芯片目前并沒有mbed支持，如需要移植mbed到STM32L100R8T6時選擇NUCLEO-L152RE開發板，因為該開發板搭載STM32L152RE，與STM32L100R8T6同屬于L系列，都搭載有Cortex-M3內核,是相同內核、相似型號的開發板，同理移植mbed到STM32F103RET6中時，可以選擇NUCLEO-F103RB開發板，同屬于F系列，都搭載有Cortex-M3內核.工程建立后右鍵 Export Program,toolchain 選擇 uvision5，導出后解壓并打開，即可得到一份 mbed OS的Keil uvision 5離線工程文件.

3.2.2 適配芯片型號

由于得到的工程文件是適配其他型號芯片的mbed OS工程，所以需要修改Keil配置以及工程中針對芯片型號的代碼文件.

1)在uvision 5的 Options for Target選項中點擊device,進入芯片型號選擇，將原本的芯片型號改為新的芯片型號.

2)更改頭文件stm32l1xx.h文件,文件可在工程中直接找到，也可在存放的文件夾目錄 targetsTARGET_STM TARGET_STM32L1TARGET_NUCLEO_L152REdevice中找到，(類似地，如STM32F103移植則修改stm32f1xx.h)

原代碼包含以下兩行(不連續)：

#define STM32L152xE

/* #define STM32L100xBA */

第一行為原芯片型號，注釋掉第一行，并取消注釋掉第二行，第二行為移植的目標型號.這一步是更改了代碼中芯片的宏定義.

3.2.3 修改配置文件

1)更改啟動文件和庫頭文件

mbed使用STM32 HAL庫，需從官方重新下載對應頭啟動文件和庫文件，刪除原工程中該部分文件并從新導出.

STM32L152re啟動頭件為startup_stm32l152xe.S(目標目錄targetsTARGET_STMTARGET_STM32L1TARGET_NUCLEO_L152REdeviceTOOLCHAIN_ARM_STD)

庫頭文件為stm32l152xe.h(目標目錄 targetsTARGET_STMTARGET_STM32L1TARGET_NUCLEO_L152REdevice)

例如，使用 stm32l100xb.h 替換掉了 stm32l152xe.h,startup_stm32l100xba.S替換startup_stm32l152xe.S，則該步驟完成.

2)PeripheralNames.h、PeripheralPins.c及PinNames.h引腳文件修改.

因為芯片差異，該部分需要對應芯片編程手冊，更改配置文件，引腳功能定義圖一般在芯片手冊的Table 8.

PeripheralNames.h文件中，對ADC、DAC、UART、SPI、I2C、PWM功能進行了初始化，例:

typedef enum {

UART_1=(int)UART1_BASE,

UART_2=(int)UART2_BASE,

UART_3=(int)UART3_BASE,

UART_4=(int)UART4_BASE,

UART_5=(int)UART5_BASE，

} UARTName;

初始化了5個通用異步串口，而STM32L100R8T6中，只有三個UART串口，所以刪除或注釋掉UART_4和UART_5兩行.

PeripheralPins.c中是對具有ADC、DAC、UART、SPI、I2C、PWM功能的管腳一一對應，進行功能初始化，仍然以UART為例，如圖2所示，同樣注釋掉UART4和UART5兩行.

圖2 PeripheralPins.c部分代碼

同時，需要修改其他行，UART串口號與指定功能管腳一一對應，該文件中其他代碼如SPI、DAC等同理.

PinNames.h中對所有GPIO管腳初始化，對部分功能管腳進出了宏定義，如：

LED1 =PA_5,

I2C_SCL =PB_8,

I2C_SDA =PB_9,

也可按需修改.

3)us_ticker_data.h

us_ticker_data.h中是對CPU定時器的相關配置文件(目標目錄targetsTARGET_STMTARGET_STM32L1TARGET_NUCLEO_L152REdevice.

文件中部分代碼為：

#define TIM_MST TIM5

#define TIM_MST_IRQ TIM5_IRQn

#define TIM_MST_RCC __TIM5_CLK_ENABLE()

#define TIM_MST_DBGMCU_FREEZE __HAL_DBGMCU_FREEZE_TIM5()

由于STM32L100R8T6并不存在TIM5，則修改為可用定時器TIM4，然后修改定時器位數:

#define TIM_MST_BIT_WIDTH 32 // 16 or 32

原芯片中為32位定時器，是原芯片型號L152RE中特有，L100R8T6不存在32位定時器，則TIM4為16位定時器，則改為16；

4)修改mbed_config.h文件

該文件位置主目錄中，在該文件中有包括較多的數值參數，例波特率等，按照工程需求對應修改.

編譯程序，如編譯成功，則得到了一份mbed OS在Keil uvision 5上的離線移植程序.

3.2.4 實驗測試

mbed OS提供了比較多功能的API，此時我們將移植板與計算機通過UART串口連接，由于在移植過程中，引腳的幾個文件已經對UART等引腳標識并初始化，如果移植成功，則電腦與開發板間可以正常通訊.

使用以下代碼，使用定時器，通過串口使用計算機屏幕返回一次通訊成功所需要的運行時間.

#include "mbed.h"

Timer t; //定義定時器t

Serial pc(USBTX,USBRX);

int main(){

t.start(); //啟動定時器

pc.printf("The time taken was");//在屏幕上顯示

t.stop();//停止定時器

pc.printf("%f seconds ",t.read());

}

如圖3所示為計算機串口調試界面結果，至此表示mbed OS移植成功，并顯示了一次通訊時間為0.017秒.

圖3 串口通訊程序結果

4 低功耗模式設計

mbed OS通過void sleep()調用睡眠功能，它選擇最合適的睡眠模式，mbed OS有兩種可用的睡眠模式:1)睡眠模式，核心的系統時鐘停止，直到發生復位或中斷.這消除了處理器，存儲器系統和總線使用的動態功率.此模式保持處理器，外設和存儲器狀態，外設繼續工作并可產生中斷，可以通過任何內部外設中斷或外部引腳中斷喚醒處理器.這時所有線程都處于等待狀態.2)深度睡眠模式，此模式類似于睡眠但節省更多功率并具有更長的喚醒時間，它通過關閉高速時鐘節省了額外的電力.因此，只有在不使用高速時鐘的外設時才能進入該模式.在大多數情況下，只要系統空閑，mbed OS就會自動進入合適的睡眠模式.

4.1 低功耗模式優化

為實現最大限度的功耗優化，提出了可行性方案：

1)覆蓋空閑循環任務：空閑循環是后臺系統線程，當沒有其他線程準備好運行時，調度程序執行.當應用程序等待事件發生時，會在后臺執行空閑循環任務.空閑循環任務為最低優先級進程，一旦有更高優先級進程進入就緒態時，空閑任務會立即切換至新任務，空閑任務處理時，會調用處理器入睡眠模式，是一種自動低功耗方法，所以可以通過定制空閑任務功能，系統會在每次空閑時低能耗執行該任務，是可行的省電方案.

2)創建異步回調任務：許多mbed庫依賴于某種I/O事務.無論是切換引腳，I2C，SPI還是串行傳輸，甚至是其他東西，他們都有一個共同點：它們往往需要執行時間.由于總線速度通常遠低于核心運行的頻率，因此這些庫往往會引入大量類似的等待代碼.由于這只是在沒有做任何有用的情況下燃燒CPU周期，設置一個異步的回調函數來實現傳輸，在程序流中調用，將他們發給外設執行，并在傳輸完成時獲得回調狀態，以來解放CPU，在回調執行期間可以做更多的其他操作或是讓CPU進入睡眠狀態以節省大量功耗.

event_callback_t functionpointer;//回調函數

void handler(int events){

//在此處理事件,events參數表示事件標志

}

void init_fp(){

//設置functionpointer對象以指向此對象上的′handler′方法

functionpointer.attach(handler);

}

3)利用超時和斷續中斷：超時表示在外部事件發生后按計劃時間以后觸發中斷，使用timeout函數實現，觸發一個延遲事件是一種常見的需求；斷續表示建立一個循環中斷，周期性調用ticker斷續函數，例如讓LED每隔幾秒閃爍一次，在嵌入式系統中創建一個周期性的事件也是最自然和常見的需求.然而上述兩種需求如果使用延遲函數wait()去實現，比如在循環中使用wait()創建時間周期達到周期性觸發事件的效果，該方法占用CPU，使CPU無法完成其他的任務，而使用超時和斷續，釋放CPU去做任何需要的事情，而測量變化時間的任務交給定時器硬件在后臺完成，從而在計劃時間觸發中斷，調用某一任務，而調用的頻率由程序決定，不限制所創建的裝置的數量.

在程序流中使用超時代替延遲函數是一種功耗的優化，它避免了CPU在等待延遲函數wait()到期時的阻塞狀態，還有一種低功耗超時方法，LowPowerTimer繼承自Timer類.在這種情況下，計時器即使在深度睡眠模式下也繼續運行.它依賴于lp_ticker，這是低功率的計時器，測量精度在毫秒左右,在某些精度要求低的情況下可以使用它創建超時.同時超時也可以以回調的方式運行，我們通過創建超時任務，并設計一個回調函數標記超時進行狀態，并開始睡眠直到超時結束，采用異步的方式，將睡眠程序包裝在超時狀態的while循環中，超時結束后繼續執行后續的程序，這種方式避免的以同步方式觸發睡眠的安全性問題，同時優化了功耗.例當我們希望停止程序流半秒時，使用低功耗計時器創建一個超時任務.

LowPowerTimeout Response;

bool flag=false; //回調狀態

void callback(void){

flag=true;

}

void main(void){

Response.attach(callback，0.5f);

//確保我們只在超時到期后繼續執行程序流程.

while(！flag)sleep();

.... //后續程序流程

}

4.2 看門狗實現

看門狗程序作為嵌入式設備的常用手段，保證設備的正常運行，看門狗定時器作為獨立的定時器，需要不斷的重啟計時，俗稱喂狗，如果沒有及時喂狗，則定時器溢出，看門狗程序判定為系統崩潰，會復位重啟系統[11].mbed OS中沒有實現看門狗功能，本文實現了在mbed OS中啟動看門狗任務，并同時提出了其在低功耗睡眠模式下的運行方法.

本文導入HAL庫的IWDG函數實現看門狗程序編寫并在mbed OS中啟動，已知的看門狗喚醒時間公式為：溢出時間=預分頻系數*重裝載值/40，單位為ms，HAL庫中IWDG_PRESCALER_表示預分頻系數，如預分頻系數采用64，重裝載值采用625，則可按公式計算出1000ms即1s的溢出時間，那么需要在溢出時間內1s內實行喂狗，否則系統會復位重啟.參考設置例程如下：

voidwatchdog(void){

hiwdg.Instance=IWDG;

hiwdg.Init.Prescaler=IWDG_PRESCALER_64

hiwdg.Init.Reload=625;

HAL_IWDG_Init(&hiwdg);

}

在喂狗時調用HAL_IWDG_Refresh(&hiwdg)函數實現喂狗，如在mbed中設置好watchdog函數后實現LED閃爍的喂狗程序如下：

while(true){

led1=！led1;

HAL_IWDG_Refresh(&hiwdg)；

wait(0.5);

}

LED燈與喂狗程序同處于延遲0.5s的循環中，每0.5s LED閃爍一次并實行一次喂狗操作，如果系統未正常運行，那么看門狗溢出，系統復位.

看門狗是為了檢測和解決由軟件錯誤引起的故障，然而在低功耗模式下CPU休眠，無法進行正常的喂狗程序，而看門狗定時器作為獨立的振蕩器存在，開啟后無法被關閉，在sleep模式下如果不進行喂狗操作，則整個系統會頻發復位.針對該情況，本文提出了采用超時喚醒的方式實行喂狗操作，設置一個超時中斷作為鬧鐘，設置一個標識標記中斷的觸發狀態，在中斷函數中實行喂狗操作和中斷觸發狀態標記，如設置一個5秒鐘的超時中斷，當超時到期時，喚醒CPU，并標記中斷觸發，判定中斷標識后執行喂狗操作并再次進入sleep()模式，如果CPU未成功喚醒，看門狗溢出，或CPU由其他未知錯誤導致喚醒，由于中斷觸發狀態標識未更新，不會進行喂狗操作，同樣導致看門狗溢出.其具體流程如圖4所示.

圖4 低功耗看門狗流程圖

4.3 低功耗性能測試

1)硬件環境：本實驗基于實驗室自主研發開發板，帶有M3內核的STM32L100RB芯片.

存儲記錄儀，用于測量板件程序運行時電壓變化情況，根據終端的電阻大小，通過公式I=U/R，得到運行電流.

2)實驗方案：通過對將mbed OS移植適配到該板件后編寫簡單的LED燈閃爍程序，測量在正常運行狀態下功耗情況，然后通過創建空閑循環任務實現LED閃爍的低功耗方案，使系統切換到低功耗模式下，觀測并記錄低功耗下功耗變化.選用μC/OS-II系統做功耗對比，μC/OS-II是知名的開源實時操作系統，它代碼結構清晰明了，可裁剪，系統短小精悍，是研究與學習實時操作系統的首選[12].同樣的，將功耗與無操作系統情況下和移植μC/OS-II操作系統做對比，同樣測量正常運行和低功耗情況下功耗情況，對比實驗結果.

圖5 電壓變化圖

如圖5為存儲記錄儀中顯示mbed的電壓變化情況，總的實驗數據結果如表1所示.

表1 功耗測試實驗數據表

Table 1 Power test experimental data sheet

操作系統模式平均電壓電阻平均電流-正常25mV10Ω2.5mA-低功耗6mV10Ω0.6mAμC/OS-II正常70mV10Ω7mAμC/OS-II低功耗20mV10Ω2mAmbed正常40mV10Ω4mAmbed低功耗12mV10Ω1.2mA

如上所示，可以得出結論，在無操作系統的情況下，裸板在運行和低功耗模式下功耗是最低的，嵌入式操作系統因為其更多功能的支持，功耗有所增加.但在在低功耗和正常運行情況下，mbed功耗仍相當可觀，相較于μC/OS-II操作系統，功耗均接近于其的二分之一.

5 結束語

本文基于mbed OS，根據其在物聯網中的參考架構，對其中的關鍵技術進行探討，基于本文提出的移植方案可以突破mbed OS芯片局限，使其支持更多的MCU設備，基于本文設計的低功耗終端、傳感器設備等可用于實際物聯網場景.實踐表明mbed確實代碼簡約、功能強大，極大程度地降低了開發難度和成本，在能耗上也完全符合物聯網低功耗的需求，具有實用價值.