任何乙個作業系統都會提供大量的api供程式設計師使用,uc/os-ii也不例外。由於uc/os-ii面向的是嵌入式開發,並不要求大而全,所以核心提供的api也就大多和多工息息相關。主要的有以下幾類：
１）任務類２）訊息類 ３）同步類 ４）時間類
５）臨界區與事件類
我個人認為對於初級程式設計師而言,任務類和時間類是必須要首先掌握的兩種型別的api。下面我就來介紹比較重要的：
１） ostaskcreate函式
這個函式應該至少在main函式內呼叫一次,在osinit函式呼叫之後呼叫。作用就是建立乙個任務。目前有四個引數,分別是任務的入口位址,任務的引數,任務堆疊的首位址和任務的優先順序。呼叫本函式後,系統會首先從tcb空閒列表內申請乙個空的tcb指標,然後將會根據使用者給出引數初始化任務堆疊,並在內部的任務就緒表內標記該任務為就緒狀態。最後返回,這樣乙個任務就建立成功了。
２） ostasksuspend函式
這個函式很簡單,一看名字就該明白它的作用,它可以將指定的任務掛起。如果掛起的是當前任務的話,那麼還會引發系統執行任務切換先導函式osshed來進行一次任務切換。這個函式只有乙個引數,那就是指定任務的優先順序。那為什麼是優先順序呢？事實上在系統內部,優先順序除了表示乙個任務執行的先後次序外,還起著分別每乙個任務的作用,換句話說,優先順序也就是任務的id。所以uc/os-ii不允許出現相同優先順序的任務。
３） ostaskresume函式
這個函式和上面的函式正好相反,它用於將指定的已經掛起的函式恢復成就緒狀態。如果恢復任務的優先順序高於當前任務,那麼還為引發一次任務切換。其引數類似ostasksuspend函式,為指定任務的優先順序。需要特別說明是,本函式並不要求和ostasksuspend函式成對使用。
４） os_enter_critical巨集
很多人都以為它是個函式,其實不然,仔細分析一下os_cpu.h檔案,它和下面馬上要談到的os_exit_critical都是巨集。他們都是涉及特定cpu的實現。一般都被替換為一條或者幾條嵌入式彙編**。由於系統希望向上層程式設計師隱藏內部實現,故而一般都宣稱執行此條指令後系統進入臨界區。其實,它就是關個中斷而已。這樣,只要任務不主動放棄cpu使用權,別的任務就沒有占用cpu的機會了,相對這個任務而言,它就是獨佔了。所以說進入臨界區了。這個巨集能少用還是少用,因為它會破壞系統的一些服務,尤其是時間服務。並使系統對外界響應效能降低。
５） os_exit_critical巨集
這個是和上面介紹的巨集配套使用另乙個巨集,它在系統手冊裡的說明是退出臨界區。其實它就是重新開中斷。需要注意的是,它必須和上面的巨集成對出現,否則會帶來意想不到的後果。最壞的情況下,系統會崩潰。我們推薦程式設計師們盡量少使用這兩個巨集呼叫,因為他們的確會破壞系統的多工效能。
６） ostimedly函式
這應該程式設計師們呼叫最多的乙個函式了,這個函式完成功能很簡單,就是先掛起當起當前任務,然後進行任務切換,在指定的時間到來之後,將當前任務恢復為就緒狀態,但是並不一定執行,如果恢復後是優先順序最高就緒任務的話,那麼執行之。簡單點說,就是可以任務延時一定時間後再次執行它,或者說,
暫時放棄cpu的使用權。乙個任務可以不顯式的呼叫這些可以導致放棄cpu使用權的api,但那樣多工效能會大大降低,因為此時僅僅依靠時鐘機制在進行任務切換。乙個好的任務應該在完成一些操作主動放棄使用權,好東西要大家分享嘛！
uc osII實時操作
uc os ii 多工實現機制分析 前面已經說過,uc os ii是一種基於優先順序的可搶先的多工核心。那麼,它的多工機制到底如何實現的呢？了解這些原理,可以幫助我們寫出更加健壯的 來。由於我們面向的初級程式設計師,本文不打算寫成又一篇uc os ii的原始碼分析,那樣的文章太多了,本文打算從實現原...
ucosii實時作業系統的任務排程
嵌入式作業系統的任務排程演算法好壞在很大程度上決定了該系統的執行效率，由於其執行的頻率極高，所以在任務排程函式的實現上，對於效率的要求可以用苛刻來形容。基於優先順序的任務排程總結下來就是做了兩件事 1 找到優先順序最高的就緒態任務 2 切換任務上下文並開始執行該任務 第二步的切換上下文對個各個rto...
嵌入式實時作業系統ucos ii 原理與應用（六）
第七章 動態記憶體管理 7.1 記憶體控制塊 c os 對記憶體進行兩級管理，即把乙個連續的記憶體空間分為若干各分割槽，每個分割槽分為若干個大小相等的記憶體塊。作業系統以分割槽為單位來管理動態記憶體，而任務以記憶體塊為單位來獲取和釋放動態記憶體。7.1.1 可動態分配記憶體劃分 1.記憶體塊 c o...