基于FreeRTOS同步與通信機制的CO濃度監(jiān)測報警裝置設計

李燕，馬強，鄧凱旋

（華北科技學院電子信息工程學院，北京，065201）

0 引言

上世紀70年代開始出現(xiàn)嵌入式系統(tǒng)，距今已有近50年的歷史。傳統(tǒng)的嵌入式裸機開發(fā)運行的程序代碼一般由一個main函數(shù)中的while死循環(huán)和各種中斷服務程序組成，異常情況或者需要執(zhí)行其他任務時，通過調(diào)用中斷服務程序進行處理，沒有多任務、線程的概念。但是引入操作系統(tǒng)后，程序執(zhí)行時可以把一個應用程序分割為多個任務，且系統(tǒng)內(nèi)核支持搶占式、合作式和時間片輪轉調(diào)度，極大地提高了系統(tǒng)實時性，降低了軟件開發(fā)難度。操作系統(tǒng)根據(jù)任務的優(yōu)先級，通過任務調(diào)度器使CPU分時執(zhí)行各個任務，保證每個任務都能夠高效執(zhí)行[1]。因此基于操作系統(tǒng)的嵌入式開發(fā)受到越來越多的開發(fā)者的青睞。

基于實時操作系統(tǒng)的軟件開發(fā)，由系統(tǒng)進行多任務的管理與調(diào)度。如果任務設計不合理，將會出現(xiàn)任務運行不穩(wěn)定、通信的實時性差等嚴重后果，所以軟件結構與多任務的同步與通信機制是基于操作系統(tǒng)的嵌入式開發(fā)的難點和關鍵點[2]。FreeRTOS是實時操作系統(tǒng)的一種，該系統(tǒng)免費而且開源，高可移植性，主要用C語言編寫；可以在資源有限的微控制器中運行，并且提供了用于低功耗的Tickless模式。本文以FreeRTOS為對象，對其同步與通信機制做了介紹，并在煤礦井下一氧化碳濃度監(jiān)測報警裝置的設計中應用。

1 FreeRTOS多任務管理機制

多任務管理是FreeRTOS系統(tǒng)的核心，采用了“分而治之”的思想，把大問題分解為許多個小問題，對其逐個擊破，大問題也就迎刃而解；各個任務均以并發(fā)的方式處理，由任務調(diào)度器決定任務執(zhí)行。FreeRTOS是基于搶占式內(nèi)核的系統(tǒng)，高優(yōu)先級的任務可以打斷低優(yōu)先級的任務運行，低優(yōu)先級任務必須等高優(yōu)先級任務運行完成之后，才能獲得CPU的使用權。

FreeRTOS系統(tǒng)內(nèi)核擁有隊列、信號量和事件標志組來完成不同任務之間，任務與中斷之間的消息傳遞。消息隊列通常采用先進先出(FIFO)的存儲緩沖機制，完成任務與任務、任務與中斷間的消息傳遞；信號量分為二制信號量、計數(shù)型信號量、互斥信號量和遞歸互斥信號量；主要用來完成共享資源訪問和任務同步的功能；事件標志組通過事件編號訪問事件，用于實現(xiàn)多個任務或事件的同步。

2 同步通信機制分析

■2.1 隊列

隊列擁有獨立權限的內(nèi)核對象，本身并不屬于或賦予任何任務。任何任務均可向同一隊列寫入或者讀出。隊列是為了任務與任務、任務與中斷之間的通信而準備的，可以在任務與任務、任務與中斷之間傳遞消息，隊列中可以存儲有限的、大小固定的數(shù)據(jù)項目，也可以發(fā)送不定長消息的場合。任務與任務、任務與中斷之間要交流的數(shù)據(jù)保存在隊列中，叫做隊列項目。隊列所能保存的最大數(shù)據(jù)項目數(shù)量叫做隊列的長度，創(chuàng)建隊列的時候會指定數(shù)據(jù)項目的大小和隊列的長度。通過字節(jié)拷貝將數(shù)據(jù)復制存儲到隊列中完成往隊列中寫入數(shù)據(jù)的任務；通過將隊列中的數(shù)據(jù)拷貝刪除完成從隊列中讀出數(shù)據(jù)的任務。讀寫隊列均會指定一個阻塞超時時間，在這段時間里，任務將保持阻塞態(tài)等待隊列數(shù)據(jù)有效；當?shù)却臅r間超過了阻塞超時時間，任務也會由阻塞態(tài)轉為就緒態(tài)。

FreeRTOS總共含有14個對消息隊列進行處理的函數(shù)，但是一般在使用時只需配置主要幾個函數(shù)即可，主要有動態(tài)或靜態(tài)創(chuàng)建隊列、向隊列發(fā)送消息、隊列上鎖和解鎖，從隊列讀取消息。在使用隊列之前，必須創(chuàng)建隊列，隊列創(chuàng)建有兩種方法，一種靜態(tài)創(chuàng)建，使用函數(shù)xQueueCreate Static();另一種是動態(tài)創(chuàng)建，使用函數(shù)xQueueCreate();兩者的區(qū)別在于：使用靜態(tài)創(chuàng)建隊列時，需要用戶自行分配內(nèi)存，動態(tài)創(chuàng)建則不需要。隊列是用來存儲消息的，因此必須要給消息分配存儲區(qū)。FreeRTOS使用參數(shù)uxQueuelength(隊列長度)和uxItemsize(消息長度)來指定存儲區(qū)域的大小。創(chuàng)建成功返回隊列句柄，創(chuàng)建失敗返回NULL。

■2.2 信號量

信號量可以用于兩種場合，一是控制控制共享資源的訪問，二是任務同步。信號量在控制共享資源訪問的過程中相當于上鎖機制，任務只有獲得開鎖的鑰匙才能獲得對共享資源的訪問權。在任務同步場合中，信號量用來執(zhí)行任務與任務，任務與中斷之間的同步。信號量可以分為二值信號量和計數(shù)型信號量。

2.2.1 二值信號量

二值信號量其實就是一個只有一個隊列項的隊列，這個特殊的隊列要么是滿的，要么是空的，所以在處理中斷與任務同步中，經(jīng)常使用隊列來代替二值信號量。下面三個步驟演示了二值信號量的工作過程：

(1)二值信號量無效

圖1中任務Task通過函數(shù)xSemaphoreTake()獲得該信號量，因為此時二值信號量處于無效狀態(tài)，所以任務Task進入阻塞態(tài)。

圖1 請求二值信號量

(2)中斷釋放信號量

當中斷發(fā)生時，在中斷服務函數(shù)中通過圖2函數(shù)xSem aphoreGiveFromISR()釋放信號量，所以此時信號量變?yōu)橛行顟B(tài)。

圖2 釋放信號量

(3)任務成功獲取信號量

此時信號量已經(jīng)有效，任務Task獲取信號量成功，阻塞態(tài)解除，可以執(zhí)行任務。

圖3 任務請求信號量成功

2.2.2 計數(shù)型信號量

計數(shù)型信號量從本質上講就是長度大于1的隊列，用戶并不需要知道隊列中存儲了什么數(shù)據(jù)，只需要知道隊列是否為空即可。計數(shù)型信號量常用于兩種場合，一是事件計數(shù)，二是資源管理。在事件計數(shù)場合中，每當有事件發(fā)生就在事件處理函數(shù)中增加信號量的計數(shù)值，其他任務信號量計數(shù)值減1。不同場合中，信號量值所代表的意思也不進行同。在計數(shù)場合中，信號量值就是隊列結構體成員變量uxMessagesWaiting，所創(chuàng)建的計數(shù)型信號量初始計數(shù)值為0。在資源管理場合中，信號量值代表當前資源的可用數(shù)量。任何任務想要獲得資源的使用權，必須首先獲取信號量，獲取成功之后信號量值就會減1。信號量值為0時說明此時已經(jīng)沒有資源了。每個任務使用完資源之后一定要將信號量釋放，這樣信號量值才會加1。在該場合中創(chuàng)建的信號量值的初始值應該是資源的數(shù)量。

2.2.3 互斥信號量

優(yōu)先級翻轉問題經(jīng)常在可剝奪內(nèi)核系統(tǒng)中出現(xiàn)，在這種情況下，高優(yōu)先級任務要一直等待低優(yōu)先級任務釋放占用的共享資源，而實際情況是中優(yōu)先級的任務剝奪了低優(yōu)先級任務對CPU的使用權，使得高優(yōu)先級任務無法先于中優(yōu)先級任務使用共享資源，導致優(yōu)先級翻轉。FreeRTOS中的互斥信號量實質上是一種擁有優(yōu)先級繼承的二值信號量，非常適合應用在需要互斥訪問的任務與任務或中斷與任務之間的同步?；コ庑盘柫烤哂袃?yōu)先級繼承的特性。當一個互斥信號量正在被一個低優(yōu)先級的任務使用時，此時有個高優(yōu)先級的任務需要獲得該信號量時就會被阻塞。但是在互斥信號量中高優(yōu)先級的任務會將低優(yōu)先級的任務提升到與自己相同的優(yōu)先級，即優(yōu)先級繼承特性。該特性是通過降低高優(yōu)先級任務處于阻塞態(tài)的時間，將“優(yōu)先級翻轉”的影響降到最低。但是優(yōu)先級繼承不能完全解決優(yōu)先級翻轉的問題，它只是盡可能降低優(yōu)先級翻轉帶來的影響。在使用互斥信號量時必須注意的是它只能在任務中使用，不能用于中斷服務函數(shù)中。

■2.3 事件標志組

前述使用信號量進行同步中，任務只能與一個任務或者事件進行同步。在需要多個任務或者事件同步的應用場景中，信號量就束手無策了。FreeRTOS采用事件標志組解決該問題。一個事件組就是一組的事件位，通過編號訪問事件位。事件位用來標明某個事件是否發(fā)生，可以當作事件標志。收到一條消息并且已經(jīng)將這條消息進行了處理就可以將該消息的標志位置1，當隊列中沒有需要處理的消息時將該位置0；事件標志組的第零位表示隊列中的消息是否進行處理；事件標志組的第一位表示是否有消息需要從網(wǎng)絡中發(fā)送出去；事件標志組的第二位表示是否需要向網(wǎng)絡發(fā)送心跳信息。

事件標志組為EventGroupHandle_t結構體類型，其可以存儲8、24或者32個事件位，但對于STM32內(nèi)核而言，一個事件標志組最多可以存儲24個事件位。

3 實際應用

設計了一套基于FreeRTOS實時操作系統(tǒng)、以STM32 F407ZGT6為核心的一氧化碳濃度檢測和報警裝置，如圖4所示。該裝置可以實時檢測煤礦井下環(huán)境中一氧化碳濃度，采用紅外遙控裝置可以實現(xiàn)遠程修改一氧化碳濃度報警值，方便工作人員操作。該檢測報警裝置基于實時多任務系統(tǒng)，顯示任務、報警任務、RS485接收與發(fā)送任務的協(xié)調(diào)與配合的同步通信機制就是上述機制。

根據(jù)煤礦井下的特殊環(huán)境要求，本設計采用了NE-COBL這款工業(yè)級一氧化碳傳感器，其具有良好的應答性和較高的輸出電流，可達到80Na/ppm至110Na/ppm；能夠輕松應對復雜氣體；線性度較高，在清潔大氣中的輸出值小于10ppm；使用壽命長，達2年以上，穩(wěn)定性強；性價比較高。

該系統(tǒng)基于實時多任務系統(tǒng)，其顯示任務、運行狀態(tài)更新任務、紅外遙控任務、RS485接收與發(fā)送任務等的同步通信由前文所述的通信機制協(xié)調(diào)配合來實現(xiàn)。程序中使用了模擬量采集消息對列、RS485接收與發(fā)送消息二值信號量，設計創(chuàng)建了二值信號量RS485接收消息隊列和RS485發(fā)送消息隊列。軟件設計總體結構框圖設計如圖4所示。

圖4 軟件設計總體框圖

(1)任務開始函數(shù)START_TASK（）：任務開始函數(shù)主要用來創(chuàng)建其他任務，執(zhí)行完任務開始函數(shù)，該任務將會被vTaskDelete(StartTask_Handler)刪除并退出臨界區(qū)。開始任務函數(shù)的優(yōu)先級設置為1，任務堆棧大小為128個字節(jié)。通過調(diào)用vTaskStartScheduler()函數(shù)開始任務調(diào)度。

(2)二值信號量RS485_BinarySemaphore=xSemaph oreCreateBinary()：敏感元件采集到的信號經(jīng)調(diào)理電路處理后連接到STM32處理器的PC0引腳，即AD轉換的通道10，將PC0配置為模擬量輸入模式，對模擬信號連續(xù)轉換十次并取其平均值，以減小轉換誤差，經(jīng)數(shù)據(jù)換算后將結果通過消息隊列傳輸至模式處理任務以實現(xiàn)濃度顯示，然后判斷濃度是否超過設定的報警值以決定是否觸發(fā)聲光報警。任務最后判斷是否獲取到RS485處理任務發(fā)送的請求數(shù)據(jù)信號量，若信號量獲取成功，則將當前濃度發(fā)送至RS485處理任務。

(3)消息隊列 Message_RS485RXD_Queue():該 消息隊列用于讀取RS485總線上的消息。QueueHandle_t Key_value_Queue():按鍵掃描消息隊列QueueHandle_tAnalog_model_Queue():模擬模式消息隊列；隊列不是屬于某個特別指定的任務的，任何任務都可以向隊列中發(fā)送消息，或者從隊列中讀取消息。

4 結論

基于FreeRTOS同步與通信機制的CO濃度檢測設計中，系統(tǒng)功能由各種實時任務協(xié)調(diào)配合完成，根據(jù)實際需求設置任務執(zhí)行順序的先后，由FreeRTOS操作系統(tǒng)內(nèi)核解決任務間同步與通信問題。該系統(tǒng)實現(xiàn)了界面顯示、監(jiān)控報警以及RS485通信等功能，實際使用中證明了該系統(tǒng)具有較強的穩(wěn)定性和良好的實時性?；贔reeRTOS系統(tǒng)不僅完成了任務間的協(xié)調(diào)配合，也使得程序開發(fā)相對容易，對嵌入式裝置的研究與開發(fā)具有重要意義。