51單片機的分時任務(wù)管理系統(tǒng)設(shè)計_coos

說一下任務(wù)管理的原理。學(xué)過微機的同學(xué)就知道，無非是直接或間接去修改PC指針。沒錯。我這里是間接修改PC指針的。怎么個間接法？利用出棧來修改！如果入棧的時候PC指針入棧，那么出棧的時候就是對PC指針的修改了。只要控制出棧時PC指針的值，就可以實現(xiàn)任務(wù)調(diào)度了。具體做法是：

1.      定時器產(chǎn)生中斷（分時的依據(jù)）

2.      中斷引起入棧，（PC指針入棧，其他寄存器也有）

3.      定時器響應(yīng)函數(shù)判斷需要執(zhí)行哪個任務(wù)

4.      修改SP指針為相應(yīng)任務(wù)的SP，（注意不是PC指針）

5.      定時器按照相應(yīng)的SP出棧，實現(xiàn)間接修改PC指針（任務(wù)調(diào)度）

最后說一次怎么使用吧。coos包含文件：（6個）

簡介到此結(jié)束，再慢慢為coos寫一份說明書吧，呵呵，源碼開發(fā)下載，上傳在我的百度網(wǎng)盤上。

歡迎同學(xué)們下載，當然coos會有bug，但是我還沒有發(fā)現(xiàn)，還請同學(xué)們多多支持多多反饋�。。�

第一章前言

第二章coos簡介

第三章任務(wù)管理詳解

第四章任務(wù)管理的幕后操作

第五章任務(wù)管理的幕后操作

第六章coos條件編譯

第七章coos的配置 裁剪 類型定義

前言

（以下所說的51特指STC89C52RC，晶振12M）

  經(jīng)過了七七四十九天的閉關(guān)修煉，終于把51的分時任務(wù)管理實現(xiàn)了？

有點夸張。從產(chǎn)生為51寫任務(wù)管理的念頭，到開始著手寫代碼，應(yīng)該有3，4天的時間。然后接下來就一直寫個不停了。本來是從開始寫到第二天，功能就實現(xiàn)了，剩下的就是慢慢完善。但是，事情總是沒那么順利，發(fā)現(xiàn)了一個又一個的bug，修改完一個又有另一個，再修改一個。這樣持續(xù)了好幾天。有時候一整天沒解決一個bug …

修改bug就是每天晚上睡不好，老是想著coos的bug，失眠是必須的。到最后發(fā)現(xiàn)了一個致命的bug，發(fā)現(xiàn)不得不用匯編來解決，然后就嘗試著C語言嵌入?yún)R編，但卻偏偏一個C語言函數(shù)匯編出來的代碼執(zhí)行有錯…讓我只能懷疑編譯器的問題的，因為本來沒嵌入?yún)R編那個函數(shù)是正常的，嵌入?yún)R編后，函數(shù)的返回值傳遞出錯了（編譯器把返回值放到R3還是哪個忘記了，然后卻從R4取返回值？問題我至今仍未能理解），我只能崩潰了。最后終于還是上火了，感冒發(fā)燒頭痛…到校醫(yī)院看病額。

  把coos擱一邊一兩個星期了，心里那個還真是不爽。把代碼全部重寫，并用回了最初的設(shè)計思想，任務(wù)調(diào)度完全在中斷里面實現(xiàn)，讓中斷負責(zé)任務(wù)切換所有工作，參考著自己上次寫的代碼，老樣子，功能是一兩天就實現(xiàn)了，幸運的是這次調(diào)試沒發(fā)現(xiàn)什么bug。然后，這樣一擱又是好多天。

在電腦上安裝win8來玩玩，挺新鮮的，界面也挺好看。期間曾一度因為在win8上運行不了RVMDK而讓我再度崩潰多次。最終放棄win8，用回win7。

  重新在win7上把coos完善。也就是多寫了一些函數(shù)。像延時，任務(wù)刪除，條件編譯等等，也是搞了好多天，每個函數(shù)都需要調(diào)試看看正不正確啊…

  當然最終功能也差不多，而且發(fā)現(xiàn)暫時已經(jīng)不想再寫下去了，就發(fā)布一下新浪博客。雖然我知道沒人看，但是因為以前在網(wǎng)上看到一句話，原話我忘記了。意思就差不多是：經(jīng)歷了一段時間的學(xué)習(xí)，最好最后把學(xué)到的東西記錄下來，走的彎路也記下來，不然留不下什么東西，最終忘記了也就像一無所獲。學(xué)到的東西最好是發(fā)到網(wǎng)上分享。這些話我是接受了，因為我也是經(jīng)常在網(wǎng)上下載別人的資料學(xué)習(xí)，所以這次我就發(fā)了出來…雖然沒用。就當留作紀念吧呵呵。

第二章    coos簡介

  coos是一個專門為51寫的分時任務(wù)管理，完全由C語言實現(xiàn)，傳統(tǒng)的任務(wù)管理總會涉及到匯編，因為有些操作是C語言實現(xiàn)不了的，例如出棧入棧，現(xiàn)場保護等。設(shè)計coos是我就試著盡量減少匯編代碼，到最后居然真的實現(xiàn)了零匯編，是最理想的結(jié)果。不過我得先說明的是，任務(wù)管理的話，我也覺得從匯編的角度去理解效果會好一點。

coos是利用51的定時器0中斷作為分時依據(jù)，進入中斷后判斷需要運行哪個任務(wù)，中斷退出便切換到相應(yīng)的任務(wù)去執(zhí)行，實現(xiàn)了任務(wù)調(diào)度。這種管理機制類似于我們熟悉Windows，例如我們平時在Windows上運行多個任務(wù)時，有時會覺得卡。coos也一樣，如果任務(wù)多了，每個任務(wù)占用的CPU必然就減少，給我們的感覺也是有點卡。

  分時籠統(tǒng)的講就是把一秒鐘（比較容易理解的單位）劃分周期，我這里是劃分成10個周期，每個周期100ms，然后每個周期劃分成20個時間片，每個時間片為5ms，也即是每個任務(wù)運行時間的最小單位是5ms（一個時間片）。一個周期有20個時間片，當有多個任務(wù)時，每個任務(wù)輪流運行一個時間片。還需要說明的是一個周期有20個時間片，每個任務(wù)一個周期運行多少個時間片需要設(shè)置。例如有2個任務(wù)，其中一個任務(wù)設(shè)置運行時間片為4，另一個設(shè)置運行時間片為50，那么在coos管理的一個周期中，任務(wù)一運行4個時間片，任務(wù)二運行16個時間片。如果沒創(chuàng)建新任務(wù)或者刪除任務(wù)的話，下個周期也是這樣執(zhí)行。

  當然為了讓coos更靈活，我也用了不少的條件編譯。實現(xiàn)可配置，可裁剪。例如一個時間片的時間是5ms還是其他，用戶可自行配置。一個周期有多少個時間片也可配置。當然還提供了不少函數(shù)，例如任務(wù)刪除，任務(wù)主動放棄CPU，系統(tǒng)延時等。因為有些實在不需要用到，所以用條件編譯實現(xiàn)可裁剪。嘗試了裁剪掉除任務(wù)管理以外的功能，coos占用RAM ：44Byte + 1bit，code：692

  還需要說的是coos的包含的文件。

coos.c             任務(wù)管理實現(xiàn)源文件

coos.h             任務(wù)管理實現(xiàn)頭文件

coos_hook.c        鉤子函數(shù)源文件

coos_hook.h        鉤子函數(shù)頭文件

coos_conf.h        任務(wù)管理配置頭文件

coos_typedef.h      類型定義頭文件

coos的實現(xiàn)由coos.c完成，是coos最核心的文件。

coos_typedef.h是為了coos的移植性需要加入的，定義coos使用的變量類型，如uint8_t

coos_conf.h是coos的配置文件，實現(xiàn)的可裁剪功能都在這個文件設(shè)置，也就是條件編譯的開關(guān)。

coos_hook.c鉤子函數(shù)源文件是由用戶實現(xiàn)的，類似于ucos的鉤子函數(shù)，例如選擇啟用任務(wù)調(diào)度的鉤子函數(shù)，用戶將自己的鉤子函數(shù)寫好后每次任務(wù)調(diào)度都會調(diào)用任務(wù)調(diào)度的鉤子函數(shù)。

第三章 任務(wù)管理原理

  在這里最重要的是要知道PC指針是什么？翻譯成中文是程序計數(shù)器，它保存的是CPU下一個指令的地址。下一個指令是什么？PC指針不知道，但是它知道下一條指令放在哪里，就是PC指針指向的那個地址的內(nèi)容。修改了PC指針，就修改了下一條指令的位置，PC指針指向哪里，CPU就運行哪個指令。任務(wù)調(diào)度就是通過修改PC指針實現(xiàn)的，我這里是間接修改PC指針，當然修改前要將它保存，也就是入棧操作。修改它就是通過出棧操作完成的。還有51的PC指針是16位的。入棧占用了兩個字節(jié)。下面再詳細介紹：先看任務(wù)管理函數(shù)的截圖。

功能看截圖就大概可以理解了。我再說明一下大概思路：

606行之前：51產(chǎn)生定時中斷，C語言看不到的入棧操作：包含R0~R7，ACC，B，DP0L，DP0H，PSW，還有最重要的PC指針，也就是現(xiàn)場保護。

606行：一個賦值語句，保存的是當前的SP（棧指針），保存在當前任務(wù)的任務(wù)控制塊里面

607行：也是賦值語句，修改當前的SP，將當前棧指針修改為定時器函數(shù)專用的棧

609~627行：先別管

629行：賦值語句，修改SP指針為下一個任務(wù)的SP指針，中斷退出將按下一個任務(wù)的任務(wù)棧出棧，出棧時修改了PC指針，實現(xiàn)了現(xiàn)場還原和任務(wù)調(diào)度

至于為什么要這么做我也說明一下。任務(wù)調(diào)度最重要的就是現(xiàn)場保護和現(xiàn)場還原了�，F(xiàn)場保護利用的是51產(chǎn)生中斷時的入棧操作，這是C語言不用管也管不了的。現(xiàn)場還原是利用51退出中斷的出棧操作，也是C語言所管不了的。雖然說不用管，但是大部分時候現(xiàn)場保護并不完全。我們需要將每個任務(wù)用到的寄存器都入棧。經(jīng)調(diào)試發(fā)現(xiàn)，51入棧機制是，在中斷服務(wù)程序有用到的寄存器就一定會入棧，PSW和PC是一定會入棧的。

為了現(xiàn)場保護完全，我在中斷服務(wù)函數(shù)里面，用C語言把每個通用寄存器都訪問了一遍（因為有一些通用寄存器沒入棧保護），所以每個通用寄存器都入棧。其他像ACC，B寄存器等也入棧了。這些操作在606行之前完成的。要看匯編出來的代碼才知道，所以說任務(wù)管理還是從匯編的角度去理解好一點。

  能理解這些操作就好辦了，簡單的說就是定時器產(chǎn)生中斷會引起入棧，退出中斷會出棧，每個任務(wù)的任務(wù)棧不同，入棧由51中斷的現(xiàn)場保護完成，出棧由51中斷的現(xiàn)場還原完成。任務(wù)切換需要做的就僅僅是在退出中斷前修改出棧的SP指針（棧指針），629行就完成這個功能。剩下的就是51的現(xiàn)場還原了。還原后就回去上次被中斷的任務(wù)的斷點處所，繼續(xù)執(zhí)行上次被中斷的任務(wù)。

  詳細的任務(wù)管理將在下一章繼續(xù)介紹。

第四章 任務(wù)管理詳解

  有了上一章的任務(wù)管理原理的基礎(chǔ)，來理解整個中斷響應(yīng)函數(shù)的功能就容易多了。繼續(xù)上一章的截圖。（大概瀏覽一下代碼，不到20行）

609~612行，624~627行。這兩個實現(xiàn)相同的功能，為定時器賦初值，條件編譯的條件為是否使能精確延時，條件編譯結(jié)果是選擇其中的一個。

在coos_conf.h文件里有：

#define    OS_ACRT_TIM_EN     0

也就是默認沒有使能精確延時，如果需要使能精確延時的話只要將0改為1就行了。

說明一下65535 - OS_TICK_CNT + OS_ETR_TICK_TIM

OS_TICK_CNT       是定時器計數(shù)個數(shù)，可配置（coos_conf.h），默認5000，分時時間片

OS_ETR_TICK_TIM   是定時器響應(yīng)周期，也就是入棧所用時間，默認0x2A

使能精確延時的結(jié)果是，coos提供的時鐘對外是比較精確的，例如做一個定時器時鐘，可以比較精確的運行一段時間。但是每個任務(wù)執(zhí)行的時間卻減少了，因為中斷響應(yīng)函數(shù)的執(zhí)行也是需要時間的，這對于分時任務(wù)管理來說是不公平的，因為任務(wù)調(diào)度的時間是不一定相同的,導(dǎo)致任務(wù)執(zhí)行的時間也不一定相同。

沒有使能精確延時，那么coos提供的延時默認是5ms + 任務(wù)調(diào)度的時間。分時任務(wù)管理的話，每個任務(wù)是公平的，執(zhí)行的時間相同。但是coos提供的延時對外是不精確的。

  接下來看一下619~621行。條件編譯，條件是如果使能定時器鉤子函數(shù)，在配置文件里是否使能（coos_conf.h）。

函數(shù)OS_Hook_Tick（）在coos_hook.c文件，默認函數(shù)體為空，該函數(shù)由用戶實現(xiàn)。

  最后就剩下614~617行，三個函數(shù)了，一個一個來，都是比較好理解的。

先看最簡單的617行，OS_ResSav（）；該函數(shù)訪問通用寄存器，引起定時器中斷函數(shù)執(zhí)行前，通用寄存器入棧(中斷服務(wù)函數(shù)訪問到哪些通用寄存器，那些通用寄存器就會入棧)，具體代碼是：

540行：讓res_ptr指向0x00，也就是51的工作寄存器組0的R0，這個還是從匯編的角度去看會好理解一點。51的256Byte的RAM，前8Byte * 4是四個工作寄存器組。

542~549行：訪問通用寄存器，用下標的形式訪問，自己給自己賦值，分別訪問R0，R1…R7，實際寄存器值沒改變，目的是要在定時器函數(shù)執(zhí)行前將通用寄存器入棧。完善現(xiàn)場保護工作。

接下來看614行，OS_TickTimDeal();

代碼也是相當簡單的，看截圖

該函數(shù)處理coos的時間，由于是分時任務(wù)管理，當然要知道當前運行到哪個時間片，并且每個任務(wù)一旦運行了一個時間片，也要將時間片減一。

499行：當前任務(wù)時間片減一，也就是當前任務(wù)運行了一個時間片

501行：系統(tǒng)時間片加一，分時管理任務(wù)，當然要有一個變量（OS_Tick）記錄當前時間片

502行：OS_TICK_PERIOD系統(tǒng)時間片周期，默認為20，判斷是否滿一個周期

504行：滿一個時間片周期，時間片清零

505行：滿一個時間片周期，置位系統(tǒng)周期標志位

508行：判斷是否滿一個系統(tǒng)周期，標志位是在505行置位的

510行：滿一個系統(tǒng)周期，標志位清零

512行~518行：條件編譯，如果使能系統(tǒng)提供參考時間，也就是延時時間才編譯這幾行

  513行：系統(tǒng)時間加一

  514行：如果時間滿一個時間周期

  516行：時間清零

520行：調(diào)用任務(wù)時間片初始化函數(shù)，重新刷新任務(wù)時間片，具體代碼如下截圖

477行：一個for循環(huán)，循環(huán)次數(shù)為任務(wù)個數(shù)，其中OS_TASK_NUM可配置，最大為8

479行：for循環(huán)的循環(huán)體，OS_TaskTimGrp數(shù)組記錄任務(wù)時間片，這里是按照任務(wù)創(chuàng)建時的時間片去刷新

481~483行：條件編譯，如果使能系統(tǒng)空閑任務(wù)。系統(tǒng)空閑任務(wù)是指在一個系統(tǒng)周期內(nèi)（例如20個時間片內(nèi)），如果沒有可運行任務(wù)（只需要執(zhí)行不到20個時間片的任務(wù)），也就是創(chuàng)建的各個任務(wù)時間片已經(jīng)執(zhí)行完，但是一個周期還沒到，就執(zhí)行空閑任務(wù)。coos默認提供的空閑任務(wù)是讓51進入低功耗模式，省電。當然可配置，用戶可以自行創(chuàng)建空閑任務(wù)。

482行：刷新空閑任務(wù)時間片

任務(wù)調(diào)度還剩下最后一個函數(shù)，繼續(xù)任務(wù)調(diào)度那張截圖：

看615行最后一個函數(shù)：目的是獲取下一個需要執(zhí)行的任務(wù)，為切換任務(wù)做準備

具體函數(shù)代碼如下截圖：

該函數(shù)的思路是：在任務(wù)狀態(tài)表上查找下一個任務(wù)。任務(wù)狀態(tài)表是579行的OS_TaskStatGrp，是一個8bit的變量，每一位為0或者為1代表是否創(chuàng)建了任務(wù)，1表示創(chuàng)建了任務(wù)，當然最多支持8個任務(wù)。

查找到有創(chuàng)建的任務(wù)，然后判斷該任務(wù)時間片是否為0，如果不為0，那么下一個任務(wù)就是被查找到的任務(wù)，如果為0，那么繼續(xù)查找下一個任務(wù)。如果所有被創(chuàng)建的任務(wù)時間片都為0，那么返回OS_TASK_NUM，代表著下一個任務(wù)執(zhí)行的是空閑任務(wù)。

567行：為id賦初值，為當前執(zhí)行任務(wù)的id

568行：i初值為0，循環(huán)控制用

570行：進入循環(huán)，循環(huán)次數(shù)為coos管理任務(wù)的個數(shù)，由OS_TASK_NUM決定，可配置

  572行：進入了循環(huán)，循環(huán)次數(shù)加一

  573行：id加一，表示下一個任務(wù)

  574行：判斷id是否溢出，超出coos管理任務(wù)的個數(shù)

  676行：id溢出則清零

579行：重點��！判斷該id的任務(wù)是否需要執(zhí)行，判斷的條件有兩個，分別是：

1、在該id上創(chuàng)建了任務(wù)

2、該任務(wù)時間片不為0

前半部分：(OS_TaskStatGrp & SET_BIT(id))

OS_TaskStatGrp是coos任務(wù)狀態(tài)表，8bit，每一位代表一個任務(wù)，為1表示創(chuàng)建了任務(wù)

SET_BIT()是一個宏操作，代碼是

#define SET_BIT(i) (1 << i)

表示置位某個位，這里SET_BIT(id)是置位id那一位

操作(OS_TaskStatGrp & SET_BIT(id)表示判斷在任務(wù)狀態(tài)表上判斷id那一位是否創(chuàng)建了任務(wù)

后半部分：OS_TaskTimGrp[id] > 0

判斷任務(wù)時間片數(shù)組上該任務(wù)時間片是否為0

如果滿足前半部分和后半部分都為真，那么就需要切換到的任務(wù)就是臨時變量id了。

所以就有：

return id；

當然如果不能同時滿足兩個條件，就

return  OS_TASK_NUM；

表示下一個任務(wù)是空閑任務(wù)。

至此，任務(wù)調(diào)度講解是完了，不過還是再總結(jié)一下：

1、 進入任務(wù)調(diào)度函數(shù)前（定時器中斷服務(wù)函數(shù)），有C語言看不見的入棧操作，保存了寄存器和PC指針等

2、 入棧后就進入任務(wù)調(diào)度函數(shù)，第一步保存當前任務(wù)的SP在相應(yīng)任務(wù)的任務(wù)控制塊里面

3、 將SP修改為任務(wù)調(diào)度專用的SP，任務(wù)調(diào)度函數(shù)專用的棧

4、 系統(tǒng)時間處理，分時管理需要處理時間

5、 獲取下一個需要執(zhí)行的任務(wù)

6、 訪問通用寄存器，為了第一步入棧操作所有通用寄存器都入棧

7、 任務(wù)調(diào)度的鉤子函數(shù)（如果使能）

8、 定時器計時賦初值

9、 修改SP為下一個任務(wù)的SP，在相應(yīng)的任務(wù)控制塊里面讀�。ǖ�2步保存）

10、退出任務(wù)調(diào)度函數(shù)，按照下一個任務(wù)的SP出棧，還原寄存器，PC指針等，實現(xiàn)了任務(wù)調(diào)度

到這里其實還遺留一個問題：切換到的任務(wù)如果還沒被執(zhí)行過的話（定時器中斷入棧是入棧被中斷的任務(wù)，說明該任務(wù)已經(jīng)執(zhí)行了），那么相應(yīng)的PC指針，寄存器值是什么？下一章繼續(xù)介紹。

第五章 任務(wù)管理的幕后操作

來到這里，可以看到，要實現(xiàn)任務(wù)管理功能，還需要很多幕后操作的。這次我們實際來看任務(wù)管理從頭到尾怎么做的，要開始來弄清楚來龍去脈了。這一章，需要分幾個小節(jié)了。

5、1 coos的文件結(jié)構(gòu)和使用

看看coos的C語言工程吧。截圖：

先看左邊的文件，兩個文件夾coos和user。

coos里面兩個源文件coos.c和coos_hook.c。這兩個文件是任務(wù)管理文件，只要包含了這兩個文件和相應(yīng)的頭文件，再調(diào)用幾個函數(shù)就可以實現(xiàn)分時任務(wù)管理功能了。

user里面兩個源文件是用戶自己編寫的。main.c和task.c分別是主函數(shù)文件和被管理任務(wù)的文件。任務(wù)到底是什么，等一下再看。這里先介紹主函數(shù)應(yīng)該怎么樣寫，也就是前面啰嗦了那么多，那到底coos怎么用？

要先添加了coos的幾個文件到自己的工程，然后大概瀏覽一下那10來行代碼。可以看到主函數(shù)的操作分成三部分：

1、初始化coos

2、創(chuàng)建任務(wù)

3、開始運行coos

具體再看代碼：

12~14行：定義三個數(shù)組，用來做任務(wù)棧。可以看到該主函數(shù)創(chuàng)建了三個任務(wù)，因為每個任務(wù)要有一個任務(wù)棧，所以定義了三個數(shù)組來當作任務(wù)棧。

16行：主函數(shù)開始入口。

18行：coos初始化。調(diào)用coos的函數(shù)，一些coos運行必要的操作，等一下再說。

20~22行：創(chuàng)建任務(wù)。也是調(diào)用coos的函數(shù)，創(chuàng)建任務(wù)后準備交給coos管理。

24行：coos開始運行。同樣是coos的函數(shù)，coos開始分時管理被創(chuàng)建的三個任務(wù)。

可以看到，要使用來管理任務(wù)是非常簡單的，主要在主函數(shù)里面調(diào)用幾個coos提供的函數(shù)就行了。沒錯，但是這次我們要看coos是怎樣運行的，了解到具體的每一步。只要理解coos幾個重要的函數(shù)，就能很深入地理解coos了。

5、2 coos重要函數(shù)說明

1、void OS_Tick_Init();

coos定時器初始化函數(shù)，跟普通的51定時器初始化函數(shù)沒什么不同，但也看一下具體代碼。

功能是配置定時器0，讓51能夠產(chǎn)生中斷，相當好理解。

其中457行的TR0 = 1；被我注釋掉是因為我們并不是要在這個時候讓coos開始運行，等到創(chuàng)建好任務(wù)在讓它開始運行。

2、void  OS_TaskCreate(void Task(void), uint8_t *TaskStk, uint8_t TaskTim, uint8_t TaskID)

coos創(chuàng)建任務(wù)的函數(shù)，非常重要！！

可以說coos得以運行都是這個函數(shù)和定時器中斷函數(shù)在幕后的操作了，這個函數(shù)有這跟定時器中斷函數(shù)同樣級別的重要性�。〔⑶�coos的很多概念都在這個函數(shù)里面使用到。

先介紹一下一些基本概念，再來說明任務(wù)創(chuàng)建函數(shù)。

①在C語言中，函數(shù)名代表函數(shù)的地址。什么意思？舉個例子說明一下：

比如有一個函數(shù)：void  Func（）；

Func是函數(shù)名，

Func（）是這個函數(shù)。

要知道它們是有區(qū)別的。

首先我們可以把Func當成一個常量，這個常量是一個地址，也就是Func（）在ROM存放的地址，ROM在51上我們稱為code。這些屬于C語言的知識，大家有興趣在繼續(xù)深入了解。我們這里要用到的只是要知道Func就是一個常量，這個常量是一個地址，這個地址是函數(shù)Func（）在ROM上的地址。就行了。

但是它有什么用？如果跟PC指針聯(lián)系起來的話就知道了解這個是有作用了。

PC指針存放的是下一條指令的地址，如果把Func賦值給PC，那么CPU下一個執(zhí)行的指令就是Func（）函數(shù)的指令了，類似于C語言的函數(shù)調(diào)用，調(diào)用的函數(shù)是Func（）。其實調(diào)用函數(shù)的時候就是將PC指針修改成對應(yīng)函數(shù)的地址，CPU就跳轉(zhuǎn)去執(zhí)行相應(yīng)的函數(shù)了。但是調(diào)用函數(shù)的話還涉及到函數(shù)參數(shù)的傳遞和函數(shù)的返回值，與只修改PC指針也是有區(qū)別的。

②任務(wù)控制塊

先看代碼截圖：

要管理任務(wù)，當然要有任務(wù)的信息。任務(wù)控制塊就是用來保存任務(wù)信息的。因為51的RAM只有256Byte，所以任務(wù)控制塊我也盡量減小，只有任務(wù)棧和任務(wù)時間片是必要的。

任務(wù)棧地址：每個任務(wù)要有自己的棧，任務(wù)棧的地址用來記錄任務(wù)進入中斷的SP的值（棧指針），方便中斷退出按該任務(wù)棧出棧實現(xiàn)現(xiàn)場還原。在第二章講任務(wù)管理原理時，進入中斷的第一件事就是保存任務(wù)的SP到任務(wù)控制塊的棧地址，也就是606行的賦值語句。

任務(wù)時間片：每個任務(wù)還要有時間片。也就是任務(wù)在一個周期內(nèi)最多執(zhí)行多少個時間片。因為是分時任務(wù)管理，所以不能讓某個任務(wù)占用所有CPU，要按照時間片去執(zhí)行。

接下來看任務(wù)創(chuàng)建函數(shù)，截圖：

函數(shù)帶四個參數(shù)，每個參數(shù)都相當重要。

第一個參數(shù)：

void  Task（void）  ---  這個參數(shù)是一個函數(shù)，可能有點難以理解。但是函數(shù)的參數(shù)可以是一個函數(shù)，這個參數(shù)函數(shù)不帶參數(shù)，不帶返回值。這個參數(shù)函數(shù)就是我們用C語言寫的任務(wù)函數(shù)。也就是任務(wù)創(chuàng)建函數(shù)創(chuàng)建的任務(wù)就放在這個參數(shù)。

第二個參數(shù)：

uint8_t  *TaskStk  ---  這個參數(shù)是任務(wù)棧首地址。如果我們定義一個數(shù)組，那么數(shù)組名就是數(shù)組的首地址，一般這個參數(shù)傳遞的是數(shù)組名（數(shù)組的首地址），然后數(shù)組就作為該任務(wù)的任務(wù)棧。（當然動態(tài)分配內(nèi)存也行）

第三個參數(shù)：

uint8_t  TaskTim  --- 這個參數(shù)是任務(wù)的時間片。比較容易理解了，一個任務(wù)在一個周期內(nèi)最多運行多少個時間片就是看創(chuàng)建任務(wù)時傳遞進來的這個參數(shù)。

第四個參數(shù)：

uint8_t  TaskID  ---  任務(wù)的id。coos管理任務(wù)是根據(jù)任務(wù)的id管理的，只有任務(wù)掛在coos任務(wù)狀態(tài)表（OS_TaskStatGrp）上coos才管理這個任務(wù)，不然任務(wù)是不會被運行的，哪怕有再多的時間片。并且coos的任務(wù)狀態(tài)表是一個8bit的變量，每一位代表一個任務(wù)id。任務(wù)的id分別是從低位的0到高位的7。

開始看具體的函數(shù)代碼，現(xiàn)在應(yīng)該很好理解了。

099行：目的是判斷該id上是否已經(jīng)創(chuàng)建了任務(wù)。判斷條件是任務(wù)狀態(tài)表該為是否為1。其中操作SET_BIT（）是一個宏操作。在coos.h里面有：

#define  SET_BIT(i)    (1 << i)

目的是置位某個位，操作(SET_BIT(TaskID))是置位id那一位，然后跟OS_TaskStatGrp（任務(wù)狀態(tài)表）與一下是否為真。如果為真，該id上已經(jīng)創(chuàng)建了任務(wù)；如果不為真，該id上未創(chuàng)建任務(wù)。

如果任務(wù)id已被占用存在，那么運行101~104行。

101~103行：條件編譯，條件是是否使能系統(tǒng)錯誤統(tǒng)計，如果使能系統(tǒng)錯誤統(tǒng)計則運行OS_ErrCnt(); ，這個函數(shù)是當coos出錯時候統(tǒng)計錯誤次數(shù)的，這里不是重點。

104行：return，函數(shù)返回。因為不能創(chuàng)建任務(wù)（任務(wù)id被占用了）

如果任務(wù)id未被占用，則運行108~118行：

108行：因為要在該id上創(chuàng)建任務(wù)，所以置位任務(wù)狀態(tài)表在該id上的那一位

109行：記錄任務(wù)的任務(wù)棧，也就是任務(wù)的SP。記錄在對應(yīng)任務(wù)的任務(wù)控制塊里面。任務(wù)控制塊是一個結(jié)構(gòu)，任務(wù)控制塊在上面已經(jīng)說明了。我這里是定義一個結(jié)構(gòu)數(shù)組，結(jié)構(gòu)就是任務(wù)控制塊結(jié)構(gòu)，每個任務(wù)的任務(wù)控制塊就是在該結(jié)構(gòu)數(shù)組上的一個元素（結(jié)構(gòu)數(shù)組的元素是一個結(jié)構(gòu)）。

右邊(uint8_t)TaskStk  +  OS_TASK_STK_SIZE_MIN有兩部分。

第一部分(uint8_t)TaskStk 是任務(wù)創(chuàng)建函數(shù)的第二個參數(shù)，任務(wù)棧首地址，本來是一個指針，強制轉(zhuǎn)換成uint8_t，無符號八位的變量

第二部分 OS_TASK_STK_SIZE_MIN 是任務(wù)棧的大小，是一個常量，默認值為13，這個有點難理解。因為與定時器中斷服務(wù)函數(shù)相關(guān)，并且是從匯編的角度去看才能知道這個常量的大小。詳細說明一下：中斷服務(wù)函數(shù)執(zhí)行前有入棧操作，但是具體入棧寄存器多少事先難以預(yù)知，最好的辦法是查看編譯后的匯編代碼。我就是查看匯編代碼的，默認總共入棧的寄存器有13個，占用14個字節(jié)（PC指針占用兩個字節(jié)，其他寄存器占用一個字節(jié)）。除了PC指針還有額外的12個字節(jié)，分別是R0~R7，ACC，DP0H，DP0L，PSW。還需要了解的是51入棧機制，棧是向高地址增長的，而且是先增長再入棧（貌似專業(yè)一點講是一個是滿棧，UB，U是up，B是before，要入棧前先增長棧地址）。

了解了這些之后就可以推斷出 OS_TASK_STK_SIZE_MIN 這個常量是13了，當然我也順便說一下。總共入棧14個字節(jié)，數(shù)組名是首地址，數(shù)組名加上13就是棧頂了，總共是14個字節(jié)，這樣就模仿得跟中斷入棧后的棧頂?shù)闹凳且粯拥摹?/font>