一、任務(wù)的通信方式
1.1 共享內(nèi)存
進程間的通信方式有兩種，一種是使用共享內(nèi)存，這種方式基本不依賴OS，也沒有相應(yīng)的系統(tǒng)開銷。另一種則需要OS支持，通過建立鏈接器實現(xiàn)任務(wù)間的通信。
Message Passing Share Memory
依賴內(nèi)核，需要預(yù)先建立Link，內(nèi)核負擔(dān)開銷 無需預(yù)先建立Link，用戶進程負責(zé)開銷
只有建立鏈接的雙方才可以通信 所有進程都可以訪問
需提供Link Creation、Link Capacity、 Message Lost等機制 需要提供互斥存取
兩種通信方式的區(qū)別
在UCOSii中，多個任務(wù)使用同一塊內(nèi)存區(qū)域需要提供一種互斥存取的方法。否則該段共享數(shù)據(jù)很有可能在被訪問前就被其他任務(wù)重置了。
利用關(guān)中斷宏OS_ENTER_CRITICAL()、OS_EXIT_CRITICAL()以及開調(diào)度鎖是利用函數(shù) OSSchedLock()、 OSSchekUnlock()可以實現(xiàn)單任務(wù)對某一資源的暫時性獨享。
用這種方法實現(xiàn)數(shù)據(jù)共享存在很大的局限性，一個簡單的例子，當一個共享資源允許被多個任務(wù)同時占用，這種方式就很低效。
RTOS會提供信號量、郵箱和消息隊列來支持任務(wù)間的通信與同步，即使是非實時性操作系統(tǒng)也同樣有這樣的接口，這已經(jīng)類似于一種規(guī)范。
1.2 信號量
信號量的概念最初由Edsger Dijkstra提出。
假定有多個任務(wù)需要讀寫一塊板卡上的flash芯片，如果他們之間沒有協(xié)商，而是各自單獨對flash進行讀寫，就會使flash的讀寫操作處于不可預(yù)料的狀態(tài)中。此時可以建立一個信號量，當有任務(wù)進行讀寫操作時，便申請該信號量，操作完成后再釋放。如果已經(jīng)有任務(wù)占用了該信號量，請求信號量就會失敗，任務(wù)可以等待該信號量被釋放，再進行相關(guān)的操作。一個共享資源也可能最多被幾個任務(wù)占用，這種情況下信號量可以為一個計數(shù)器，當有任務(wù)占用共享資源時，信號量減一。
1.3 郵箱
很明顯，信號量只解決了共享資源的占用的問題。它不能傳遞信息，假如某下位機有一個專門用來解釋上位機控制命令的任務(wù)，當上位機沒有數(shù)據(jù)傳送過來時，該任務(wù)處于掛起狀態(tài)。但當通訊中斷發(fā)生后，該任務(wù)不僅要知道已經(jīng)有控制字被傳送過來，還需要知道該控制字是什么。所以信號量在這里并不適用，解決的辦法是建立一個郵箱。由于要傳遞的信息很可能超過一個常規(guī)變量的大小，所以郵箱的內(nèi)容是一個指針。將命令解釋器的優(yōu)先級設(shè)置為高于其他任務(wù)，它始終調(diào)等待一個郵箱。將該郵箱里指針的值指向接收緩沖區(qū)，該任務(wù)就開始處理控制字。
1.4 消息隊列
消息隊列是一組指針，它可以被看成是一組郵箱的集合。
假設(shè)有一個流水線分揀系統(tǒng)，傳感器會檢測貨物的一些物理參數(shù)。每來一個產(chǎn)品，系統(tǒng)就建立一個關(guān)于該產(chǎn)品的結(jié)構(gòu)體用于描述該產(chǎn)品的屬性。如果使用郵箱，那么在一個產(chǎn)品被分揀任務(wù)處理前，新到產(chǎn)品就必須延時處理。使用消息隊列，可以將一組指針推入隊列，每一個指針都描述一個產(chǎn)品。這樣分揀任務(wù)可以根據(jù)先后入隊列的順序，依次分揀每個產(chǎn)品。
二、事件控制塊
2.1 Ecb的結(jié)構(gòu)
事件控制塊Ecb用來維護一個事件控制塊的所有信息，該結(jié)構(gòu)體不僅包含信號量/郵箱/消息隊列的值，還包含等待它的任務(wù)列表。
Ecb反映了一種樸素的簡化程序邏輯結(jié)構(gòu)的思想。用統(tǒng)一的數(shù)據(jù)結(jié)構(gòu)來描述對象的屬性，再在處理程序里統(tǒng)一處理。對信號量/郵箱/消息隊列的創(chuàng)建、維護都只是讀寫Ecb，在調(diào)度程序里，統(tǒng)一處理Ecb。
Ecb原型
typedef struct {
void *OSEventPtr; /* 指向消息或者消息隊列的指針 */
INT8U OSEventTbl[OS_EVENT_TBL_SIZE]; /* 等待任務(wù)列表 */
INT16U OSEventCnt; /* 計數(shù)器(當事件是信號量時) */
INT8U OSEventType; /* 事件類型 */
INT8U OSEventGrp; /* 等待任務(wù)所在的組 */
} OS_EVENT;
OSEventType表示事件類型，信號量/郵箱/消息隊列。
如果事件是信號量，OSEventCnt表示信號量的值。
如果事件是郵箱或者消息隊列，OSEventPtr表示指向消息或者消息隊列的指針。
OSEventTbl和OSEventGrp用來表示等待該事件的任務(wù)組。
2.2 Ecb通用操作
為了減少代碼量，UCOSii將一些與Event有關(guān)的，會被重用的操作寫成了獨立的函數(shù)。
初始化Ecb
當Ecb被建立時，需要對其進行清0，防止該段Ram里已經(jīng)被寫入了值。
使一個任務(wù)就緒態(tài)
使用OSSemPost(),OSMboxPost(),OSQPost(),和 OSQPostFront()發(fā)送一個事件后，事件等待列表中優(yōu)先級最高的任務(wù)要被置于就緒狀態(tài)，這時調(diào)用OSEventTaskRdy()函數(shù)。
該函數(shù)被用來使等待事件發(fā)生的最高優(yōu)先級任務(wù)得到該事件后，使他進入就緒狀態(tài)。
因為Ucosii強制所有任務(wù)不同優(yōu)先級，所以可以通過任務(wù)優(yōu)先級取得Tcb的指針。然后該函數(shù)將OSTCBDly和OSTCBEventPtr結(jié)束任務(wù)延時，標志事件結(jié)束，再將事件的相應(yīng)參數(shù)（信號量的指，消息和隊列指針的值）傳遞給Tcb。最后，該函數(shù)還要判斷該任務(wù)是否因為調(diào)用OSTaskSuspend()而被掛機。如果沒有，則進入就緒隊列。
OSTaskSuspend()是一個額外的機制，凡是調(diào)用OSTaskSuspend()被掛機的任務(wù)，只能調(diào)用OSTaskResume()來進行恢復(fù)。
使一個任務(wù)等待某事件
當使用OSSemPend(),OSMboxPend()或者 OSQPend()函數(shù)讓某個任務(wù)等待某事件時，要調(diào)用OSEventTaskWait()函數(shù)。
該函數(shù)將任務(wù)從就緒列表中刪除，再加入Ecb中的等待列表。
使一個任務(wù)因等待時間超時而進入就緒狀態(tài)
當使用SSemPend(),OSMboxPend()或者 OSQPend()讓任務(wù)等待某個事件，而等待事件超時后，將調(diào)用OSTimeTick()函數(shù)。
該函數(shù)清除Ecb等待列表里的任務(wù)，被將Tcb里標記事件的指針清0。
三、相關(guān)函數(shù)
3.1 信號量
信號量的建立，OSSemCreate()
初始化一個信號量要從劃給Ecb的內(nèi)存里申請一塊空閑區(qū)域，然后初始化一個Ecb，并將Ecb里的事件類型標記為信號量。
這個函數(shù)會返回一個指向Ecb塊的指針，之后對信號量的操作都要通過這個指針來實現(xiàn)。
等待一個信號量，OSSemPend()
OSSemPend()先判斷事件的類型，如果是信號量且值不為0。就把信號量的值減一，函數(shù)返回請求成功的標志。
在信號量被占用時，任務(wù)將被掛起。只有當?shù)却瑫r，或者得到該信號量時，任務(wù)才被喚醒。
發(fā)送一個信號量，OSSemPost()
OSSemPost()同樣先判斷參數(shù)里的指針是否指向一個信號量的Ecb。
如果有任務(wù)正在等待該信號量，那么把等待列表里優(yōu)先級最高的任務(wù)移除，讓它就緒。
否則就把信號量加1。
無等待地請求一個信號量，OSSemAccept()
OSSemAccept()用來在中斷程序中請求信號量，其實它只是取得當前信號量的值。
如果當前信號量的值不為0，那么OSSemAccept()會在取得該值后，將計數(shù)器減1。
查詢信號量狀態(tài)，OSSemQuery()
OSSemQuery()返回就緒列表和信號量的值，在查詢之前要先建立一個接收返回值的結(jié)構(gòu)體。因為無需包含Ecb中的類型和消息指針，所以該結(jié)構(gòu)體類型和Ecb是不同的。
3.2 郵箱
創(chuàng)建一個郵箱，OSMboxCreate()
和OSSemCreate()的區(qū)別是，Ecb的類型為郵箱，并且郵箱的初始值會被寫成參數(shù)傳遞來的值。
等待一個郵箱中的消息,OSMboxPend()
和OSSemPend()的區(qū)別是，OSMboxPend()判斷該指針是否是NULL，不是就取得該指針，否則就掛起開始等待該郵箱。
發(fā)送一個消息到郵箱中,OSMboxPost()
和Sem的Post函數(shù)區(qū)別是，如果郵箱已經(jīng)有非空指針存在里面，函數(shù)會返回郵箱滿了的錯誤。
無等待地從郵箱中得到一個消息, OSMboxAccept()
清空郵箱，并且返回郵箱里的指針。
查詢一個郵箱的狀態(tài), OSMboxQuery()
返回Ecb的部分內(nèi)容，不包含類型和信號量計數(shù)器。
3.3 消息隊列
UCOSii里針對消息隊列的函數(shù)有7個。分別是OSQCreate(),OSQPend(),OSQPost(),OSQPostFront(),OSQAccept(),OSQFlush()和 OSQQuery()函數(shù)
其中大部分和信號量/郵箱的函數(shù)在思想上是一致的。因為消息隊列是一個循環(huán)隊列的結(jié)構(gòu)，因此在推送消息的時候，存在先進先出和后進先出的問題。即新消息到來時，到底是插入在隊列的尾部，還是插入在隊列的前部。OSQPost(),OSQPostFront()分別對應(yīng)兩種不同的入棧方式。
OSQFlush()用來清空隊列。
為了支持消息隊列的特性，要在使用消息隊列時，預(yù)先定義隊列的最大值。而且為了支持隊列特性，在Ecb里的指針實際指向的是一個隊列控制塊，相關(guān)的算法就不列舉了。
下載文檔
