嵌入式μC/OS-II系統中基於ECB基本存儲單元實現信號量管理的設計

嵌入式μC/OS-II系統中基於ECB基本存儲單元實現信號量管理的設計

李巖；谷萍萍 發表於 2020-03-10 10:25:12

隨著嵌入式技術的發展，實時作業系統RTOS（Real Time Operating System）被越來越多地應用在嵌入式系統中，但是對現有基於軟體實現的RTOS，單純依靠改進調度算法已經不能使系統的實時性有很大提高。為提高系統的響應能力，國內外一些研究機構提出RTOS硬化的方法，並開始做這方面的研究工作。目前，軟體硬化常用的有兩種方法：（1）微程序方式，特點是成本較低，方便靈活；（2）組合邏輯方式，特點是速度快、可靠性高，隨著大規模集成電路的發展，這種方式逐漸顯示出優越性。信號量管理是RTOS中頻繁運行的程序段之一，如果將這一部分用硬體實現，對提高機器的速度將有很明顯的效果。本文採用組合邏輯方式參照μC/OS-II將信號量管理及ECB管理硬化到一片晶片上，作為獨立的模塊與處理器並行工作。

1、信號量管理的工作原理

μC/OS-II中信號量主要數據結構由兩部分組成：（1）信號量的計數值Cnt。當數值為正時用於記錄可使用的資源數，當數值為負，其絕對值表示等待當前信號量的任務個數；（2）等待該信號量的任務列表。信號量的基本數據結構需要申請一個ECB來存儲。一個任務或ISR可以通過ECB向另外的任務發信號，一個任務可以等待另一個任務或中斷服務子程序給它發送信號，多個任務可同時等待同一個事件的發生。當事件發生後，等待該事件的優先級最高的任務進入就緒狀態，觸發一次任務調度。任務或者中斷服務子程序都可以給ECB發信號，對ECB進行操作。

信號量管理的工作原理框圖如圖1所示。信號量管理模塊以及事件控制塊管理都是獨立於CPU的邏輯結構，都可以直接從數據總線上獲得數據信息進行處理，在信號量管理模塊與ECB的存儲模塊間建立一條數據通路，在不增加總線負擔的情況下加快二者間的通信。這些硬體邏輯獨立於CPU工作，減少了CPU的工作，從而提高系統的響應能力。

2、 信號量管理的硬體設計與實現

2.1 ECB的設計與實現

ECB是實現信號量管理的基本數據結構，因此在設計實現信號量管理之前，要先完成ECB管理的設計與實現。本系統中ECB的結構參照μC/OS-II中ECB的結構設計。每個ECB存儲單元包含一個EventType（事件類型），用於標記當前ECB被分配給信號量、互斥型信號量、郵箱還是消息隊列；當一個ECB被分配給信號量時，Cnt做為信號量的計數器；ECB中的等待表lut用於存儲等待當前信號量任務的優先級（μC/OS-II中沒有兩個任務有相同的優先級）。

ECB中等待表硬體實現的結構示意圖如圖2所示。等待表的結構類似一個8行8列的矩陣，存儲單元編號從00~77。當一個任務在申請當前信號量而沒有獲得時，應將當前任務設置為等待狀態，令Wr有效，以申請該信號量任務的優先級為地址，進行解碼，選通相應單元後再進行寫1操作。例如，申請該信號量的任務優先級Sid為111111時，對其進行解碼，高三位行地址解碼為10000000，低三位列地址解碼為10000000，選中77單元向其寫入1，則優先級為111111的任務進入等待狀態。若要將一個處於等待表中的任務刪除，令De有效，同樣，根據地址線選通某一存儲單元，向單元內寫0，從而刪除某一處於等待狀態的任務。在控制電路中設置EventGrp 8位寄存器，用於記錄當前各行中是否有等待任務；如圖2所示，第i行中某一位置為1，EventGrp（i）=1，圖中狀態EventGrp（7）=1、EventGrp（6）=1、EventGrp（0）=0。Rd有效時，控制電路根據EventGrp採用一定算法生成優先級的高三位；根據EventGrp讀出某行後生成優先級低三位；下一時鐘送出最高優先級。以上為對等待表進行基本讀寫操作的過程。

該硬體系統中ECB基本存儲單元通過調用系統的IP核來實現，根據存儲數據的不同，採用不同的IP核；多個基本單元通過一個上層文件生成一個ECB單元，每個單元再作為一個基本器件用於實現整個ECB的存儲體。通過地址的解碼選通ECB單元，根據控制信號對數據做讀寫操作。

2.2 創建/刪除一個信號量

ECB是公共數據結構，在傳統的作業系統中創建一個信號量時，首先需要申請一個ECB，初始化後才可以對這個信號量進行P/V等操作；在刪除一個信號量後，要對信號量佔用的ECB進行釋放。創建信號量時，信號量管理模塊首先要申請一個空ECB，查找ECB的整個存儲體判斷是否有空餘的ECB。如果沒有空餘ECB，則信號量管理模塊將獲得一個申請失敗信號；否則將獲得一個空ECB的地址，並將其返回給創建該信號量的任務；再根據地址初始化ECB。如果用硬體實現信號量管理後，按照以上過程進行操作會浪費很多時鐘，數據在模塊間來回傳送增加通信次數，必然降低系統的執行速度。針對這個問題，提出了在信號量管理模塊中設置一個用於記錄ECB使用情況的映射表，如圖3所示。為方便討論，假設系統中ECB有64個（可以根據系統中ECB的個數來改變表的大小），表的每個位置對應一個ECB，當某一位置為0時表示該位置對應的ECB空閒，為1時表示該位置對應的ECB被佔用。如圖3所示，第1行、第8列為1，表示偏移地址為000111的ECB被佔用；第2行、第2 列為1，偏移地址為010010的ECB被佔用。

在創建一個信號量時，查找ECB映射表，判斷是否有為0的位置。如果沒有則返回申請失敗；否則尋找一個為0的位置，生成ECB的地址，返回給創建該信號量的任務。在映射表中相應位置寫1表明該ECB已經被佔用，下一時鐘對申請到的ECB進行初始化，寫入信號量初始值。在刪除一個信號量時，首先根據信號量的ECB地址查詢映射表中對應位置是否為0，如果為0，則表示該信號量已經被其他任務刪除，返回刪除錯誤；否則清除該信號量在映射表中的記錄，通知ECB管理模塊將等待該信號的所有任務置為就緒態，觸發一次任務調度，清除ECB中的該信號量的所有信息。以上過程中不需要頻繁地去ECB管理模塊中進行整體查詢，因此節省了大量的通信時間。

2.3 申請/釋放一個信號量（P/V操作）

信號量管理中的主要操作就是P/V操作，P/V操作實現的RTL圖如圖4所示。

（1）P操作（申請某個信號量）。令pend_sem有效，首先應判斷申請信號量的任務是否為中斷服務程序（在μC/OS-II中，中斷服務程序不允許申請一個信號量），如果是則返回申請錯誤信息（pend_err為高），否則進行以下操作：令read_cnt有效去ECB管理模塊讀Cnt值；讀回後判斷Cnt的值。如果Cnt》0，當前申請任務獲得該信號量，任務繼續執行，返回申請成功信號pend_err為低；否則pend_err為高阻，根據申請類型Pend_type（申請類型在μC/OS-II中分為有等待申請和無等待申請）來決定是否修改Cnt值，是否將申請信號量的任務置為等待態。

（2）V操作。令post_sem有效，通過硬體電路使read_cnt有效，同時給出信號量的ECB地址，下一時鐘讀出Cnt值，並判斷；如果Cnt》0則表示沒有任務等待當前信號量，修改Cnt值；如果Cnt《0則表示當前有任務等待該信號量，修改Cnt值，令select_h有效，從ECB任務等待表中找出優先級最高的任務，通知任務管理器將該任務置為就緒態，觸發一次任務調度。　3 功能仿真

為驗證設計對系統性能的影響，採用ISE 8.2軟體對各個模塊進行時序仿真。P/V操作仿真結果如圖5所示。P/V操作需要在兩個模塊之間進行讀寫數據，操作過程中，P/V信號始終有效。

（1）pend_sem有效（P操作）。申請信號量任務的優先級為01，申請信號量的地址為05。pend_sem有效，令read_cnt為高，根據地址pend_addr讀當前信號量的值Cnt，下一個時鐘返回數值Cnt_in為0002，大於0；任務獲得信號量繼續執行，wr_cnt為高，Cnt值進行減1操作後送Cnt_out寫回ECB。

（2）post_sem有效（V操作）。根據地址讀Cnt值，Cnt值為FFFE《0（Cnt值以補碼形式存儲）。下一個時鐘Cnt進行加1操作後寫回ECB，同時Select_h為高，從等待該信號量的任務列表中選擇出優先級最高的任務設置為就緒態，觸發一次任務調度。

（3）申請一個信號量。申請信號量任務的優先級為03，申請的信號量的地址為09。如果下一個時鐘讀回的Cnt值為FFFD《0，並且申請類型為高（有等待申請），則修改Cnt值寫回，令wr_sid為高，將當前申請任務的優先級送pend_prio_out寫入等待該信號的任務列表中。

（4）申請一個信號量，讀回的Cnt值為FFFA《0，但當前申請類型為低（無等待申請），不進行任何操作，返回申請失敗，通知任務管理器將當前任務阻塞。

用戶程序在創建、刪除一個信號量以及申請某類共享資源進行P/V操作時，用軟體實現信號量管理中，一般先從用戶態轉到系統態，然後進行基本數據的查詢、讀出、比較、判斷等，再轉相應的程序入口，最後還要從系統態轉回用戶態。而用硬體實現信號量管理後進行以上操作只需一條讀或寫指令，並且這條指令在用軟體實現的信號量管理中也是必須的，其他操作都由硬體邏輯來實現，簡化了操作過程。因此，硬化信號量管理後對整個機器速度的提高是非常明顯的，特別是對資源種類多、數量大的計算機系統，速度的提高就會更加明顯。另一方面，由於硬體的可靠性遠超過軟體的可靠性，所以硬化後可提高RTOS的可靠性。

單片機處理器能力的提高和應用程式功能的複雜化、精確化，迫使應用程式劃分為多個重要性不同的任務，在各任務間優化地分配CPU時間和系統資源，同時還要保證實時性。靠用戶自己編寫一個實現上述功能的內核一般是不現實的，而這種需求又是普遍的。在這種形勢之下，由專業人員編寫的、滿足大多數用戶需要的高性能RTOS內核就是一種必然結果了。對程序實時性和可靠性要求的提高也是RTOS發展的一個原因。此外，單片機系統軟體開發日趨工程化，產品進入市場時間不斷縮短，也迫使管理人員尋找一種有利於程序繼承性、標準化、多人並行開發的管理方式。從長遠的意義上來講，RTOS的推廣能夠帶來嵌入式軟體工業更有效、更專業化的分工，減少社會重複勞動、提高勞動生產率。

責任編輯：gt

打開APP閱讀更多精彩內容

聲明：本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人，不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用，如有內容圖片侵權或者其他問題，請聯繫本站作侵刪。 侵權投訴