国产毛片a精品毛-国产毛片黄片-国产毛片久久国产-国产毛片久久精品-青娱乐极品在线-青娱乐精品

uCOS-II 初級程序員指南,了解一下!

發布時間:2018-9-27 12:07    發布者:xyd2018
關鍵詞: uCOS-II
(一) uC/OS-II 簡介
uC/OS-II是一種基于優先級的可搶先的硬實時內核。自從92年發布以來,在世界各地都獲得了廣泛的應用,它是一種專門為嵌入式設備設計的內核,目前已經被移植到40多種不同結構的CPU上,運行在從8位到64位的各種系統之上。尤其值得一提的是,該系統自從2.51版本之后,就通過了美國FAA認證,可以運行在諸如航天器等對安全要求極為苛刻的系統之上。鑒于uC/OS-II可以免費獲得代碼,對于嵌入式RTOS而言,選擇uC/OS無疑是最經濟的選擇。

(二) uC/OS-II 應用程序基本結構
應用uC/OS-II,自然要為它開發應用程序,下面論述基于uC/OS-II的應用程序的基本結構以及注意事項。

每一個uC/OS-II應用至少要有一個任務。而每一個任務必須被寫成無限循環的形式。以下是推薦的結構:
void task ( void* pdata )
{
INT8U err;
InitTimer(); // 可選
For( ;; )
{
// 你的應用程序代碼
…….
……..
OSTimeDly(1); // 可選
}
}

以上就是基本結構,至于為什么要寫成無限循環的形式呢?那是因為系統會為每一個任務保留一個堆棧空間,由系統在任務切換的時候換恢復上下文,并執行一條reti 指令返回。如果允許任務執行到最后一個花括號(那一般都意味著一條ret指令)的話,很可能會破壞系統堆棧空間從而使應用程序的執行不確定。換句話說,就是“跑飛”了。所以,每一個任務必須被寫成無限循環的形式。程序員一定要相信,自己的任務是會放棄CPU使用權的,而不管是系統強制(通過ISR)還是主動放棄(通過調用OS API)。

現在來談論上面程序中的InitTimer()函數,這個函數應該由系統提供,程序員有義務在優先級最高的任務內調用它而且不能在for循環內調用。注意,這個函數是和所使用的CPU相關的,每種系統都有自己的Timer初始化程序。在uC/OS-II的幫助手冊內,作者特地強調絕對不能在OSInit()或者OSStart()內調用Timer初始化程序,那會破壞系統的可移植性同時帶來性能上的損失。所以,一個折中的辦法就是象上面這樣,在優先級最高的程序內調用,這樣可以保證當OSStart()調用系統內部函數OSStartHighRdy()開始多任務后,首先執行的就是Timer初始化程序。或者專門開一個優先級最高的任務,只做一件事情,那就是執行Timer初始化,之后通過調用OSTaskSuspend()將自己掛起來,永遠不再執行。不過這樣會浪費一個TCB空間。對于那些RAM吃緊的系統來說,還是不用為好。

(三) 一些重要的uC/OS-II API介紹
任何一個操作系統都會提供大量的API供程序員使用,uC/OS-II也不例外。由于uC/OS-II面向的是嵌入式開發,并不要求大而全,所以內核提供的API也就大多和多任務息息相關。主要的有以下幾類:
1)任務類
2)消息類
3)同步類
4)時間類
5)臨界區與事件類

我個人認為對于初級程序員而言,任務類和時間類是必須要首先掌握的兩種類型的API。下面我就來介紹比較重要的:
1) OSTaskCreate函數
這個函數應該至少再main函數內調用一次,在OSInit函數調用之后調用。作用就是創建一個任務。目前有四個參數,分別是任務的入口地址,任務的參數,任務堆棧的首地址和任務的優先級。調用本函數后,系統會首先從TCB空閑列表內申請一個空的TCB指針,然后將會根據用戶給出參數初始化任務堆棧,并在內部的任務就緒表內標記該任務為就緒狀態。最后返回,這樣一個任務就創建成功了。

2) OSTaskSuspend函數
這個函數很簡單,一看名字就該明白它的作用,它可以將指定的任務掛起。如果掛起的是當前任務的話,那么還會引發系統執行任務切換先導函數OSShed來進行一次任務切換。這個函數只有一個參數,那就是指定任務的優先級。那為什么是優先級呢?事實上在系統內部,優先級除了表示一個任務執行的先后次序外,還起著分別每一個任務的作用,換句話說,優先級也就是任務的ID。所以uC/OS-II不允許出現相同優先級的任務。

3) OSTaskResume函數
這個函數和上面的函數正好相反,它用于將指定的已經掛起的函數恢復成就緒狀態。如果恢復任務的優先級高于當前任務,那么還為引發一次任務切換。其參數類似OSTaskSuspend函數,為指定任務的優先級。需要特別說明是,本函數并不要求和OSTaskSuspend函數成對使用。

4) OS_ENTER_CRITICAL宏
很多人都以為它是個函數,其實不然,仔細分析一下OS_CPU.H文件,它和下面馬上要談到的OS_EXIT_CRITICAL都是宏。他們都是涉及特定CPU的實現。一般都被替換為一條或者幾條嵌入式匯編代碼。由于系統希望向上層程序員隱藏內部實現,故而一般都宣稱執行此條指令后系統進入臨界區。其實,它就是關個中斷而已。這樣,只要任務不主動放棄CPU使用權,別的任務就沒有占用CPU的機會了,相對這個任務而言,它就是獨占了。所以說進入臨界區了。這個宏能少用還是少用,因為它會破壞系統的一些服務,尤其是時間服務。并使系統對外界響應性能降低。

5) OS_EXIT_CRITICAL宏
這個是和上面介紹的宏配套使用另一個宏,它在系統手冊里的說明是退出臨界區。其實它就是重新開中斷。需要注意的是,它必須和上面的宏成對出現,否則會帶來意想不到的后果。最壞的情況下,系統會崩潰。我們推薦程序員們盡量少使用這兩個宏調用,因為他們的確會破壞系統的多任務性能。

6) OSTimeDly函數
這應該程序員們調用最多的一個函數了,這個函數完成功能很簡單,就是先掛起當起當前任務,然后進行任務切換,在指定的時間到來之后,將當前任務恢復為就緒狀態,但是并不一定運行,如果恢復后是優先級最高就緒任務的話,那么運行之。簡單點說,就是可以任務延時一定時間后再次執行它,或者說,暫時放棄CPU的使用權。一個任務可以不顯式的調用這些可以導致放棄CPU使用權的API,但那樣多任務性能會大大降低,因為此時僅僅依靠時鐘機制在進行任務切換。一個好的任務應該在完成一些操作主動放棄使用權,好東西要大家分享嘛!

(四) uC/OS-II 多任務實現機制分析
前面已經說過,uC/OS-II是一種基于優先級的可搶先的多任務內核。那么,它的多任務機制到底如何實現的呢?了解這些原理,可以幫助我們寫出更加健壯的代碼來。由于我們面向的初級程序員,本文不打算寫成又一篇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的多任務實現機制,我們在這里大費筆墨談論這個問題,是希望我們的程序員們可以善加利用這個機制,寫出更健壯,更富有效率的代碼來。
免費試聽C語言電子PCBSTM32LinuxFPGA、Python等。想學習的你和我聯系預約就可以免費聽課了宋工Q3/5/2/4/6/5/9/0/8/8   Tel/WX:1/7/3/1/7/9/5/1/9/0/8



本文地址:http://m.qingdxww.cn/thread-547744-1-1.html     【打印本頁】

本站部分文章為轉載或網友發布,目的在于傳遞和分享信息,并不代表本網贊同其觀點和對其真實性負責;文章版權歸原作者及原出處所有,如涉及作品內容、版權和其它問題,我們將根據著作權人的要求,第一時間更正或刪除。
您需要登錄后才可以發表評論 登錄 | 立即注冊

廠商推薦

  • Microchip視頻專區
  • 使用SAM-IoT Wx v2開發板演示AWS IoT Core應用程序
  • 使用Harmony3加速TCP/IP應用的開發培訓教程
  • 集成高級模擬外設的PIC18F-Q71家族介紹培訓教程
  • 探索PIC16F13145 MCU系列——快速概覽
  • 貿澤電子(Mouser)專區
關于我們  -  服務條款  -  使用指南  -  站點地圖  -  友情鏈接  -  聯系我們
電子工程網 © 版權所有   京ICP備16069177號 | 京公網安備11010502021702
快速回復 返回頂部 返回列表
主站蜘蛛池模板: 无人视频免费观看免费视频 | 色综合天天综合网站中国| 在线精品国内外视频| 超碰免费视频caopoom9| 久久久影院亚洲精品| 无码一区国产欧美在线资源| 亚洲一区二区三区91| 青娱乐自拍| 亚洲a在线播放| 星星动漫无删减在线观看| 在线亚洲免费| 国产综合18久久久久久软件| 日本美女毛茸茸| 欧美护士激情第一欧美精品| 色花堂视频| 亚洲成年网站在线777| 97视频在线观看免费播放| 久久99热狠狠色AV蜜臀| 中文人妻熟妇精品乱又伧| 亚洲精品福利在线| 日韩视频一| 中文字幕福利片| 与子乱刺激对白在线播放| 果冻传媒2021精品影视| 瑜伽牲交AV| 一级 在线播放| 五月激情综合网| 一个人看www免费高清字幕| 国产成年人在线观看| 日韩人妻精品久久日 | 亚洲乱码视频| 日韩欧美精品综合一区二区三区| 最新高清无码专区| 在线视频一区二区日韩国产| 蜜芽最新域名解析网站| 一级毛片免费的| 涩涩久久| 天天色天| chaopeng 在线视频| 香港日本三级亚洲三级| 三级毛片基地|