uC/OS-II 初級程序員指南

首先我們來看看為什么多任務機制可以實現?其實在單一CPU的情況下,是不存在真正的多任務機制的,存在的只有不同的任務輪流使用CPU,所以本質上還是單任務的。但由于CPU執行速度非常快,加上任務切換十分頻繁并且切換的很快,所以我們感覺好像有很多任務同時在運行一樣。這就是所謂的多任務機制。

由上面的描述,不難發現,要實現多任務機制,那么目標CPU必須具備一種在運行期更改PC的途徑,否則無法做到切換。不幸的使,直接設置PC指針,目前還沒有哪個CPU支持這樣的指令。但是一般CPU都允許通過類似JMP,CALL這樣的指令來間接的修改PC。我們的多任務機制的實現也正是基于這個出發點。事實上,我們使用CALL指令或者軟中斷指令來修改PC,主要是軟中斷。但在一些CPU上,并不存在軟中斷這樣的概念,所以,我們在那些CPU上,使用幾條PUSH指令加上一條CALL指令來模擬一次軟中斷的發生。

回想一下你在微機原理課程上學過的知識,當發生中斷的時候,CPU保存當前的PC和狀態寄存器的值到堆棧里,然后將PC設置為中斷服務程序的入口地址,再下來一個機器周期,就可以去執行中斷服務程序了。執行完畢之后,一般都是執行一條RETI指令,這條指令會把當前堆棧里的值彈出恢復到狀態寄存器和PC里。這樣,系統就會回到中斷以前的地方繼續執行了。那么設想一下?如果再中斷的時候,人為的更改了堆棧里的值,那會發生什么?或者通過更改當前堆棧指針的值,又會發生什么呢?如果更改是隨意的,那么結果是無法預料的錯誤。因為我們無法確定機器下一條會執行些什么指令,但是如果更改是計劃好的,按照一定規則的話,那么我們就可以實現多任務機制。事實上,這就是目前幾乎所有的OS的核心部分。不過他們的實現不像這樣簡單罷了。

下面,我們來看看uC/OS-II再這方面是怎么處理的。再uC/OS-II里,每個任務都有一個任務控制塊(Task Control Block),這是一個比較復雜的數據結構。在任務控制快的偏移為0的地方,存儲著一個指針,它記錄了所屬任務的專用堆棧地址。事實上,再uC/OS-II內,每個任務都有自己的專用堆棧,

彼此之間不能侵犯。這點要求程序員再他們的程序中保證。一般的做法是把他們申明成靜態數組。而且要申明成OS_STK類型。當任務有了自己的堆棧,那么就可以將每一個任務堆棧再那里記錄到前面談到的任務控制快偏移為0的地方。以后每當發生任務切換,系統必然會先進入一個中斷,這一般是通過軟中斷或者時鐘中斷實現。然后系統會先把當前任務的堆棧地址保存起來,僅接著恢復要切換的任務的堆棧地址。由于哪個任務的堆棧里一定也存的是地址(還記得我們前面說過的,每當發生任務切換,系統必然會先進入一個中斷,而一旦中斷CPU就會把地址壓入堆棧),這樣,就達到了修改PC為下一個任務的地址的目的。

以上就是uC/OS-II的多任務實現機制,我們在這里大費筆墨談論這個問題,是希望我們的程序員們可以善加利用這個機制,寫出更健壯,更富有效率的代碼來。