與uCos見面還是大學的時候，老師讓我為畢業設計選一個課題，要求有關嵌入式實時操作系統，于是開始在網上搜索，順理成章的就發現了uCos，于是開始了uCos之路，但后來由于硬件平臺的問題，畢設沒有用uCos，而用了另外一個不開源的。

畢業后，自己做的項目用到過RTX51，uCos，Linux，當做linux下的項目時，研究過一陣子linux的源碼，后來又一天，閑來無事再去看uCos的源碼時，突然發現uCos里的一些原理，對于理解和構建一個操作系統這這么的經典和透徹！

今天就給大家來整理一下uCos里的一些原理，相信對于更透徹的理解RTOS定會有好處，如果你確實沒什么收獲，就當是打發時間吧！

首先，第一個要解決的問題是，為什么我們需要uCos？就像最開始學C編程時，老師告訴我們，指針很重要，那時你肯定有一個大的疑問，指針到底有什么好？心里一直犯嘀咕著：不用指針不一樣把程序編出來了？ 現在想想看c語言沒了指針，是不是寸步難行呢。回到正題，我們到底為什么需要uCos？

一般的簡單的嵌入式設備的編程思路是下面這樣的：

main

{

{處理事務1}；

{處理事務2}；

{處理事務3}；

。..。..。

{處理事務N}；

}

isr_server

{

{處理中斷}；

}

這是最一般的思路，對于簡單的系統當然是夠用了，但這樣的系統實時性是很差的，比如“事務1”如果是一個用戶輸入的檢測，當用戶輸入時，如果程序正在處理事務1下面的那些事務，那么這次用戶輸入將失效，用戶的體驗是“這個按鍵不靈敏，這個機器很慢”，而我們如果把事務放到中斷里去處理，雖然改善了實時性但會導致另外一個問題，有可能會引發中斷丟失，這個后果有時候比“慢一點”更加嚴重和惡劣！又比如事務2是一個只需要1s鐘處理一次的任務，那么顯然事務2會白白浪費CPU的時間。

這時，我們可能需要改進我們的編程思路，一般我們會嘗試采用“時間片”的方式。這時候編程會變成下面的方式：

main

{

{事務1的時間片到了則處理事務1}；

{事務2的時間片到了則處理事務2}；

。..。..。

{事務N的時間片到了則處理事務N}；

}

time_isr_server

{

{判斷每個事務的時間片是否到來，并進行標記}；

}

isr_server

{

{處理中斷}；

}

我們可以看到，這種改進后的思路，使得事務的執行時間得到控制，事務只在自己的時間片到來后，才會去執行，但我們發現，這種方式仍然不能徹底解決“實時性”的問題，因為某個事務的時間片到來后，也不能立即就執行，她必須等到當前事務的時間片用完，并且后面的事務時間片沒到來，她才有機會獲得“執行時間”。

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

我們在這個思路上，進行改進，我們需要在每次進入時鐘中斷前，保存CPU的當前狀態和當前事務用到的一些數據，然后我們進入時鐘中斷進行時間片處理，若發現有新的更緊急的事務的時間片到來了，則我們改變中斷的返回的地址，并在CPU中恢復這個更緊急的事務的現場，然后返回中斷開始執行這個更緊急的事務。

上面的這段話有些不好讀，事實上，這是因為要實現這個過程是有些復雜和麻煩的，這時候我們就需要找一個操作系統（OS）幫我們做這些事了，如果你能自己用代碼實現這個過程，事實上你就在自己寫操作系統了，其實從這里也可也看出，操作系統的原理其實并不那么神秘，只是一些細節你很難做好。uCos就是這樣一個操作系統，她能幫你完成這些事情，而且是很優雅的幫你完成！

到這里，我們終于知道了為什么我們需要uCos了。事實上，uCos的用處遠不止幫你完成這個“事務時間片的處理”，她還能幫你處理各種超時，進行內存管理，完成任務間的通信等，有了她，程序的層次也更加清晰，給系統添加功能也更方便，這一切在大型項目中越發的明顯！

我們知道了uCos能給我們提供這么多的便利，那么我們就開始使用uCos吧！

原文標題：為什么我們需要uCos？帶你透徹理解RTOS

文章出處：【微信公眾號：玩轉單片機】歡迎添加關注！文章轉載請注明出處。

責任編輯：haq