這里，我重點講解如何結(jié)合RTOS進行處理數(shù)據(jù)。我們巧妙的利用了RTSO自帶的消息隊列，我們可以把每一個接收的數(shù)據(jù)看做一個消息元素。

先回顧一下知識點：

FreeRTOS消息隊列

基于 FreeRTOS 的應用程序由一組獨立的任務構(gòu)成——每個任務都是具有獨立權(quán)限的程序。這些獨立的任務之間的通訊與同步一般都是基于操作系統(tǒng)提供的IPC通訊機制，而FreeRTOS 中所有的通信與同步機制都是基于隊列實現(xiàn)的。

消息隊列是一種常用于任務間通信的數(shù)據(jù)結(jié)構(gòu)，隊列可以在任務與任務間、中斷和任務間傳送信息，實現(xiàn)了任務接收來自其他任務或中斷的不固定長度的消息。任務能夠從隊列里面讀取消息，當隊列中的消息是空時，掛起讀取任務，用戶還可以指定掛起的任務時間；當隊列中有新消息時，掛起的讀取任務被喚醒并處理新消息，消息隊列是一種異步的通信方式。

隊列特性1.數(shù)據(jù)存儲

隊列可以保存有限個具有確定長度的數(shù)據(jù)單元。隊列可以保存的最大單元數(shù)目被稱為隊列的“深度”。在隊列創(chuàng)建時需要設定其深度和每個單元的大小。

通常情況下，隊列被作為 FIFO（先進先出）緩沖區(qū)使用，即數(shù)據(jù)由隊列尾寫入，從隊列首讀出。當然，由隊列首寫入也是可能的。

往隊列寫入數(shù)據(jù)是通過字節(jié)拷貝把數(shù)據(jù)復制存儲到隊列中；從隊列讀出數(shù)據(jù)使得把隊列中的數(shù)據(jù)拷貝刪除。

2.讀阻塞

當某個任務試圖讀一個隊列時，其可以指定一個阻塞超時時間。在這段時間中，如果隊列為空，該任務將保持阻塞狀態(tài)以等待隊列數(shù)據(jù)有效。當其它任務或中斷服務例程往其等待的隊列中寫入了數(shù)據(jù)，該任務將自動由阻塞態(tài)轉(zhuǎn)移為就緒態(tài)。當?shù)却臅r間超過了指定的阻塞時間，即使隊列中尚無有效數(shù)據(jù)，任務也會自動從阻塞態(tài)轉(zhuǎn)移為就緒態(tài)。

由于隊列可以被多個任務讀取，所以對單個隊列而言，也可能有多個任務處于阻塞狀態(tài)以等待隊列數(shù)據(jù)有效。這種情況下，一旦隊列數(shù)據(jù)有效，只會有一個任務會被解除阻塞，這個任務就是所有等待任務中優(yōu)先級最高的任務。而如果所有等待任務的優(yōu)先級相同，那么被解除阻塞的任務將是等待最久的任務。

說些題外話，ucos中是具有廣播消息的，當有多個任務阻塞在隊列上，當發(fā)送消息的時候可以選擇廣播消息，那么這些阻塞的任務都能被解除阻塞。

3.寫阻塞

與讀阻塞想反，任務也可以在寫隊列時指定一個阻塞超時時間。這個時間是當被寫隊列已滿時，任務進入阻塞態(tài)以等待隊列空間有效的最長時間。

由于隊列可以被多個任務寫入，所以對單個隊列而言，也可能有多個任務處于阻塞狀態(tài)以等待隊列空間有效。這種情況下，一旦隊列空間有效，只會有一個任務會被解除阻塞，這個任務就是所有等待任務中優(yōu)先級最高的任務。而如果所有等待任務的優(yōu)先級相同，那么被解除阻塞的任務將是等待最久的任務。

消息隊列的工作流程1.發(fā)送消息

任務或者中斷服務程序都可以給消息隊列發(fā)送消息，當發(fā)送消息時，如果隊列未滿或者允許覆蓋入隊， FreeRTOS 會將消息拷貝到消息隊列隊尾，否則，會根據(jù)用戶指定的阻塞超時時間進行阻塞，在這段時間中，如果隊列一直不允許入隊，該任務將保持阻塞狀態(tài)以等待隊列允許入隊。當其它任務從其等待的隊列中讀取入了數(shù)據(jù)（隊列未滿），該任務將自動由阻塞態(tài)轉(zhuǎn)為就緒態(tài)。當任務等待的時間超過了指定的阻塞時間，即使隊列中還不允許入隊，任務也會自動從阻塞態(tài)轉(zhuǎn)移為就緒態(tài)，此時發(fā)送消息的任務或者中斷程序會收到一個錯誤碼 errQUEUE_FULL。

發(fā)送緊急消息的過程與發(fā)送消息幾乎一樣，唯一的不同是，當發(fā)送緊急消息時，發(fā)送的位置是消息隊列隊頭而非隊尾，這樣，接收者就能夠優(yōu)先接收到緊急消息，從而及時進行消息處理。

下面是消息隊列的發(fā)送API接口，函數(shù)中有FromISR則表明在中斷中使用的。

消息隊列讀取

任務調(diào)用接收函數(shù)收取隊列消息， 函數(shù)首先判斷當前隊列是否有未讀消息， 如果沒有， 則會判斷參數(shù) xTicksToWait， 決定直接返回函數(shù)還是阻塞等待。

如果隊列中有消息未讀， 首先會把待讀的消息復制到傳進來的指針所指內(nèi)， 然后判斷函數(shù)參數(shù) xJustPeeking == pdFALSE的時候， 符合的話， 說明這個函數(shù)讀取了數(shù)據(jù)， 需要把被讀取的數(shù)據(jù)做出隊處理， 如果不是， 則只是查看一下（peek），只是返回數(shù)據(jù)，但是不會把數(shù)據(jù)清除。

對于正常讀取數(shù)據(jù)的操作， 清除數(shù)據(jù)后隊列會空出空位， 所以查看隊列中的等待列表中是否有任務等發(fā)送數(shù)據(jù)而被掛起， 有的話恢復一個任務就緒， 并根據(jù)優(yōu)先級判斷是否需要出進行任務切換。

對于只是查看數(shù)據(jù)的， 由于沒有清除數(shù)據(jù)， 所以沒有空間新空出，不需要檢查發(fā)送等待鏈表， 但是會檢查接收等待鏈表， 如果有任務掛起會切換其到就緒并判斷是否需要切換。

接下來，我們可以從中斷再到任務這樣一個流程去編寫代碼：

如下的框圖來說明一下 FreeRTOS 消息隊列的實現(xiàn)，讓大家有一個形象的認識。

1. 中斷如何處理：

///《LPUART0 中斷服務函數(shù)

void LpUart0_IRQHandler（void）

{

BaseType_t xHigherPriorityTaskWoken = pdFALSE;

uint8_t res=0;

// if（LPUart_GetStatus（M0P_LPUART0， LPUartPE）） /*奇偶檢驗錯誤*/

// {

// LPUart_ClrStatus（M0P_LPUART0， LPUartPE）;

// }

if（LPUart_GetStatus（M0P_LPUART0， LPUartRC）） ///接收數(shù)據(jù)中斷

{

LPUart_ClrStatus（M0P_LPUART0， LPUartRC）; ///《清接收中斷請求

res = LPUart_ReceiveData（M0P_LPUART0）;

xQueueSendFromISR（usart_Queue，（void *） &res，&xHigherPriorityTaskWoken）;

portYIELD_FROM_ISR（xHigherPriorityTaskWoken）;

}

}

任務中接收信號，這里并不是每一條消息都接收嗎，因為沒有空閑中斷，而是做了100ms絕對延時，確保一幀數(shù)據(jù)接收完成。

/**

** \brief 2400波特率：‘100ms = 24bytes’

**

**

** \param 1 ：void

** \retval void

void APP_LocalCOM_ReadData（void）

{

uint8_t temp_bytes = 0; /*隊列中字節(jié)長度new*/

uint8_t cnt;

static uint8_t buff［QueueSIZE］ = {0}; /*暫存接收協(xié)議，從0x68開始，用于crc計算*/

static TickType_t StartTick = 0;

static uint8_t ShadowBytes = 0; /*old*/

temp_bytes = uxQueueMessagesWaiting（usart_Queue）;//檢查消息數(shù)

if（temp_bytes == 0）//檢查隊列的長度

{

ShadowBytes = 0;

}

else

{

if（ShadowBytes ！= temp_bytes）//有新的數(shù)據(jù)

{

ShadowBytes = temp_bytes;

StartTick = xTaskGetTickCount（）;

}

else

{

if（xTaskGetTickCount（） - StartTick 》 100）

{

for（cnt = 0; cnt《temp_bytes; cnt++）

{

xQueueReceive（usart_Queue，（void*）&buff［cnt%QueueSIZE］，（TickType_t）100）;//接收數(shù)據(jù)

}

protocol_parse（buff，temp_bytes）;

//BSP_UARTx_SendBytes（M0P_UART0，temp_bytes， buff）; //test

}}}}
編輯：hfy