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

李燕，馬強，鄧凱旋

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

0 引言

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

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

1 FreeRTOS多任務管理機制

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

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

2 同步通信機制分析

■2.1 隊列

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

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

■2.2 信號量

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

2.2.1 二值信號量

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

(1)二值信號量無效

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

圖1 請求二值信號量

(2)中斷釋放信號量

當中斷發生時，在中斷服務函數中通過圖2函數xSem aphoreGiveFromISR()釋放信號量，所以此時信號量變為有效狀態。

圖2 釋放信號量

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

此時信號量已經有效，任務Task獲取信號量成功，阻塞態解除，可以執行任務。

圖3 任務請求信號量成功

2.2.2 計數型信號量

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

2.2.3 互斥信號量

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

■2.3 事件標志組

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

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

3 實際應用

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

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

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

圖4 軟件設計總體框圖

(1)任務開始函數START_TASK（）：任務開始函數主要用來創建其他任務，執行完任務開始函數，該任務將會被vTaskDelete(StartTask_Handler)刪除并退出臨界區。開始任務函數的優先級設置為1，任務堆棧大小為128個字節。通過調用vTaskStartScheduler()函數開始任務調度。

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

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

4 結論

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