基于靈動微電子MM32 MCU的OS移植與應(yīng)用

近年來，物聯(lián)網(wǎng)IOT概念廣為普及，物聯(lián)網(wǎng)市場發(fā)展迅猛，嵌入式設(shè)備的聯(lián)網(wǎng)已然成為趨勢。終端聯(lián)網(wǎng)使得軟件復(fù)雜性大幅增加，傳統(tǒng)的 RTOS 內(nèi)核已經(jīng)越來越難滿足市場的需求。正是在這種情況下，物聯(lián)網(wǎng)操作系統(tǒng)（IoT OS）的概念應(yīng)運而生。

物聯(lián)網(wǎng)操作系統(tǒng)是指以操作系統(tǒng)內(nèi)核（可以是 RTOS、Linux 等）為基礎(chǔ)，包括文件系統(tǒng)、圖形庫等較為完整的中間件組件，具備低功耗、安全、通信協(xié)議支持和云端連接能力的軟件平臺。

一般簡單的嵌入式系統(tǒng)軟件的編程思路是下面這樣的：

main

{

{任務(wù)1}；

{任務(wù)2}；

{任務(wù)3}；

.......

{任務(wù)N}；

}

isr_server

{

{處理中斷}；

}

這是嵌入式工程師編程的一般思路，對于一個簡單的系統(tǒng)當(dāng)然是夠用了，但在這樣的系統(tǒng)中每個任務(wù)的實時性是很差的，比如如果“任務(wù)1”用于用戶輸入的檢測，當(dāng)用戶輸入時，如果程序正在執(zhí)行其他的任務(wù)進程，那么這次用戶輸入將失效，用戶的體驗是“這個按鍵不靈敏，這個機器很慢”。

而我們?nèi)绻阉腥蝿?wù)都放到中斷里去處理，雖然改善了實時性，卻會導(dǎo)致另外一個問題：一個任務(wù)在處理的時候有可能會引發(fā)其它的中斷丟失。這個后果有時候比“慢一點”更加嚴(yán)重和惡劣！又比如任務(wù)2是一個只需要1s鐘處理一次的任務(wù)，那么顯然任務(wù)2會白白浪費CPU的時間。

這時，我們可能需要改進我們的編程思路，一般我們會嘗試采用“時間片”的方式。這時候軟件結(jié)構(gòu)會變成下面的方式：

main

{

{如果任務(wù)1的時間片到了則執(zhí)行任務(wù)1}；

{如果任務(wù)2的時間片到了則執(zhí)行任務(wù)2}；

.......

{如果任務(wù)N的時間片到了則執(zhí)行任務(wù)N}；

}

timer_isr_server

{

{判斷每個任務(wù)的時間片是否到來，并進行標(biāo)記}；

}

isr_server

{

{處理中斷}；

}

我們可以看到，這種改進后的思路，使得任務(wù)的執(zhí)行時間得到控制，任務(wù)只在自己的時間片到來后，才會去執(zhí)行。但你可以發(fā)現(xiàn)，這種方式仍然不能徹底解決“實時性”的問題，因為某個任務(wù)的時間片到來后，也不能立即就執(zhí)行，MCU必須等到當(dāng)前任務(wù)的時間片用完，并且后面的任務(wù)時間片還沒有來，32位單片機才有機會獲得“執(zhí)行時間”。

這時候我們需要繼續(xù)改進思路。為了使得某個任務(wù)的時間片到來以后能立即執(zhí)行，我們需要在時鐘中斷里判斷完時間片后，改變程序的返回位置，讓程序不返回到剛剛被打斷的位置，而從最新獲得了時間片的任務(wù)處開始執(zhí)行，這樣就徹底解決了任務(wù)的實時問題。

我們在這個思路上進行改進。在每次進入時鐘中斷前，MCU保存當(dāng)前狀態(tài)和當(dāng)前任務(wù)的關(guān)鍵數(shù)據(jù)，然后進入時鐘中斷進行時間片處理。如果這時判斷有新的更緊急的任務(wù)的時間片到來，則執(zhí)行任務(wù)切換，恢復(fù)這個更緊急的任務(wù)的現(xiàn)場，然后返回中斷開始執(zhí)行這個更緊急的任務(wù)。

到這里，我們終于知道了操作系統(tǒng)的作用了。事實上，操作系統(tǒng)的用處遠不止幫你完成這個“任務(wù)時間片的處理”，操作系統(tǒng)還能幫你處理各種超時，進行內(nèi)存管理，完成任務(wù)間的通信等。有了操作系統(tǒng)，程序的層次也更加清晰，給系統(tǒng)添加功能也更方便，這一切在大型項目中越發(fā)的明顯！