爲何咱們須要uCos

知道uCos是在2010年的暑假，老師要我爲畢業設計選一個課題，要求有關嵌入式實時操做系統，因而開始在網上搜索，瓜熟蒂落的就發現了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吧！