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

先回顧一下知識點：

FreeRTOS消息隊列

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

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

隊列特性1.數據存儲

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

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

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

2.讀阻塞

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

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

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

3.寫阻塞

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

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

消息隊列的工作流程1.發送消息

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

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

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

消息隊列讀取

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

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

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

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

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

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

1. 中斷如何處理：

///《LPUART0 中斷服務函數

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）） ///接收數據中斷

{

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

res = LPUart_ReceiveData（M0P_LPUART0）;

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

portYIELD_FROM_ISR（xHigherPriorityTaskWoken）;

}

}

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

/**

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

**

**

** \param 1 ：void

** \retval void

void APP_LocalCOM_ReadData（void）

{

uint8_t temp_bytes = 0; /*隊列中字節長度new*/

uint8_t cnt;

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

static TickType_t StartTick = 0;

static uint8_t ShadowBytes = 0; /*old*/

temp_bytes = uxQueueMessagesWaiting（usart_Queue）;//檢查消息數

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

{

ShadowBytes = 0;

}

else

{

if（ShadowBytes ！= temp_bytes）//有新的數據

{

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）;//接收數據

}

protocol_parse（buff，temp_bytes）;

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

}}}}
編輯：hfy