越來越多的嵌入式系統依賴于實時操作系統（RTOS）的使用，以滿足實時需求，減少上市時間，簡化開發(fā)，增加代碼可移植性。盡管RTOS有許多好處，但它也有其缺點，如可能引入分配不當的任務優(yōu)先級、堆棧溢出、饑餓、死鎖、優(yōu)先級反轉等bug。

一些專門設計的工具，可以幫助基于RTOS的程序開發(fā)人員發(fā)現一些難以發(fā)現的錯誤。

RTOS是什么？

實時操作系統（RTOS或實時內核）是有效地管理CPU時間的軟件。大多數內核使用C編寫，僅需匯編語言編寫小部分代碼，使內核適配不同的CPU體系結構。在使用RTOS內核設計應用程序時，只需將工作分成任務，每個任務負責工作的一部分。任務（也稱為線程）是一個簡單的程序，認為自己完全擁有CPU。在單核CPU上，在任何給定時間內只能執(zhí)行一個任務。應用代碼還需要根據任務重要性為每個任務分配優(yōu)先級以及任務堆棧（RAM）。一般來說，增加低優(yōu)先級任務不會影響系統對高優(yōu)先級任務的響應。任務實現通常是一個無限循環(huán)，內核負責任務的管理，稱為多任務處理。多任務處理是在幾個順序任務之間調度和切換CPU的過程。多任務處理提供了具有多個CPU的錯覺，最大化地使用CPU，如圖1所示。多任務處理還有助于創(chuàng)建模塊化的應用程序。使用實時內核后，應用程序更容易設計和維護。

大多數商業(yè)RTOS都是搶占式調度方式，內核總是運行就緒的最重要的任務。搶占式內核也是事件驅動的，任務被設計為等待事件發(fā)生后才能執(zhí)行。如果任務等待的事件沒有發(fā)生，內核將運行其它任務。等待狀態(tài)的任務不消耗CPU時間。通過內核API調用來完成事件的發(fā)生和等待操作，避免輪詢操作，提高CPU時間的利用率。典型的任務實現示例，如下所示：

實時內核提供了許多服務，如多任務處理、中斷管理、任務間通信與同步、資源管理、時間管理、內存分區(qū)管理等。RTOS可以用于少量任務的簡單應用，在需要復雜和耗時的通信的應用中，如TCP/IP、USB（主機和/或設備）、CAN、藍牙、Zigbee應用等，RTOS是一個必備工具。當應用程序需要文件系統來存儲和檢索數據，以及當產品配備了圖形顯示（黑白、灰度或彩色）時，也強烈推薦使用RTOS。

硬件調試端口

ARM Cortex-M內核配備了強大的調試硬件。CoreSight提供了非侵入性的功能，允許工具在不停止CPU的情況下監(jiān)視和控制實時系統，例如：

動態(tài)內存/外設訪問（讀寫）

指令跟蹤（芯片需包括一個執(zhí)行跟蹤宏單元，ETM）

數據跟蹤

下圖顯示了Core Sight調試端口、CPU和內存外設之間的關系簡化框圖。

系統測試/調試工具

下圖顯示了CoreSight如何連接到開發(fā)環(huán)境：

1、嵌入式開發(fā)通常使用集成開發(fā)環(huán)境（IDE），IDE中通常包含代碼編輯器、編譯器、匯編器、鏈接器、調試器等工具。

IDE內置的調試器只提供了最基本的功能：下載代碼、啟動/停止應用、設置斷點等功能。一些調試器允許在目標運行時顯示和更改變量（如Live Watch），但這些功能僅限于數值。許多調試器內置RTOS插件，但通常需要停止應用程序才能檢查RTOS的狀態(tài)（對于調試實時系統不太實用）。

2、通過調試器，例如Segger J-Link，將代碼下載到目標系統。

3、J-Link連接到CoreSight調試端口，啟動/停止CPU，下載代碼，編程板載Flash等。即使目標系統正在執(zhí)行代碼，J-Link也可以讀寫內存。

4、Micrium的μC/Probe是一個獨立的、與CPU無關的Windows應用程序，它讀取工具鏈生成的ELF文件。ELF文件包含下載到目標系統的代碼以及所有全局變量的名稱、數據類型和內存位置。

5、μC/Probe允許用戶在運行時顯示或更改連接的嵌入式目標上的變量或內存位置（包括I/O端口）的值。用戶只需在μC/Probe圖形環(huán)境填充量規(guī)、數字指示器、表格、圖表、虛擬LED、條形圖、滑塊、開關、按鈕等控件，并將控件與嵌入設備中的變量或內存位置相關聯，即可在運行時顯示或更改變量。通過μC/Probe圖形界面中添加的虛擬滑塊或開關，你可以輕松地更改運行系統的參數（如過濾系數和PID回路增益）或啟動設備并測試I/O端口。

6、μC/Probe向J-Link發(fā)送讀取或寫入內存的請求。

7、J-Link請求將轉換為CoreSight命令，獲取變量值并顯示到μC/Probe圖形界面。

8、測試/調試實時嵌入式系統的另一個非常有用的工具是SEGGER的SystemView。此工具通常與RTOS一起工作，按時間順序顯示任務和ISR的執(zhí)行，可以查看每個任務需要執(zhí)行的時間（最小/平均/最大），任務何時就緒，每個任務實際開始執(zhí)行時間，ISR何時執(zhí)行等。SystemView可以幫助你發(fā)現不易發(fā)現的錯誤。但SystemView需要向目標系統添加記錄RTOS事件和ISR的駐留代碼（由SEGGER免費提供），SystemView還會消耗少量的RAM來緩存這些事件。

9、J-Link允許多個進程同時訪問CoreSight，因此你可以同時使用這三個工具。

基于RTOS應用中的問題

堆棧溢出

在基于實時內核的應用中，每個任務都需要自己的堆棧。任務所需堆棧的大小取決于應用程序。如果堆棧大于任務要求，則會浪費內存。如果堆棧太小，堆棧可能溢出。我們可以通過分配更多內存來減少堆棧溢出的機會，通常需要25-50%的額外堆?？臻g。一些CPU，比如基于ARMv8M架構的CPU，內置了堆棧溢出檢測機制。然而，該特性并不能幫助確定合適的堆棧大小，它只是防止堆棧溢出的負面后果。

堆棧分配時，首先為任務堆棧分配更多空間，然后在已知最壞情況下運行應用程序，監(jiān)視實際堆棧使用情況。

下圖顯示了μC/Probe對測試應用程序的μ/OS-III內核感知的截圖。Stack Usage列顯示每個任務在給定時間的最大堆棧使用情況。μC/Probe將更新并實時顯示堆棧使用信息，無需停止目標應用。綠色表示最大堆棧使用量一直保持在70%。黃色表示堆棧使用量在70%到90%之間。紅色表示堆棧使用量已超過90%。顯然，使用92%堆棧的任務應該增大堆棧，使其回到70%以下。

中斷響應

在臨界代碼處理時，RTOS和應用程序代碼通常必須禁用中斷。關中斷會影響系統對事件的響應，RTOS應用中盡量減少中斷禁用時間。

μC/OS-III會監(jiān)測每個任務最壞情況下的中斷禁用時間，下圖所示。如果應用需要滿足實時截止時間，這些信息非常有用。

中斷被禁用的時間很大程度上取決于CPU、其時鐘速率、應用程序和調用的RTOS服務。禁用中斷最長的任務用紅色高亮顯示，幫助用戶快速識別潛在的異常值。

如果最大中斷禁用時間是由RTOS引起的，可以：

查找并使用中斷禁用時間較低的RTOS API。

增加CPU的時鐘速率。

使用非內核感知中斷來處理高度時間敏感的代碼。

優(yōu)先級反轉

優(yōu)先級反轉發(fā)生在低優(yōu)先級任務持有高優(yōu)先級任務需要的資源時。當中等優(yōu)先級的任務搶占占用資源的低優(yōu)先級的任務時，問題就會加劇?！皟?yōu)先級反轉”一詞指的是，低優(yōu)先級任務似乎比高優(yōu)先級任務具有更高的優(yōu)先權，至少在共享該資源時是如此。

優(yōu)先級反轉是實時系統中的一個問題，當使用基于優(yōu)先級的搶占式內核時會發(fā)生。如下圖所示，SystemView展示了一個優(yōu)先級反轉場景。

App HPT具有最高優(yōu)先級，App MPT 具有中優(yōu)先級，App LPT優(yōu)先級最低。

可以使用RTOS的互斥量機制來解決上面描述的優(yōu)先級反轉問題。優(yōu)先級反轉被限定為LPT訪問共享資源所需的時間，下圖所示。LPT和HPT都使用互斥量而非信號量來獲得對共享資源的訪問權。如果沒有SystemView這樣的工具，優(yōu)先級反轉將很難識別和校正。

注意，如果LPT只是HPT的下一個優(yōu)先級級別，則可以使用信號量。在這種情況下，RTOS不需要更改LPT的優(yōu)先級，信號量是首選項，它比互斥信號量快。

死鎖

死鎖是至少兩個任務相互等待另一個任務擁有的資源。死鎖可能不會立即發(fā)生，它很大程度上取決于兩個任務何時需要彼此的資源。如圖8所示，μC/Probe的內核感知視圖有一列，顯示每個任務的執(zhí)行頻率（RTOS切換任務的頻率）。通過監(jiān)視此列可以檢測死鎖。如果至少兩個任務的計數已停止（μC/Prboe在CPU運行時更新這些計數器），則可能存在死鎖。對于這種情況，不需要使用μC/Probe等工具也可以判定鎖定行為，該工具使它更加明顯。

可以通過以下方法來避免死鎖：

1、任務先獲取所有必需的資源，以相同的順序獲取它們，以相反的順序釋放它們。

2、在RTOS API調用中使用超時機制，以避免永遠等待資源可用。檢查RTOS API返回的錯誤代碼，以確保對所需資源的請求成功。

任務饑餓

饑餓指高優(yōu)先級任務消耗了所有CPU帶寬，低優(yōu)先級任務沒有CPU時間或很少。饑餓的影響是響應性和產品特性的下降，例如嵌入式目標的顯示更新緩慢、通信堆棧中的數據包丟失、操作界面響應遲緩等。為解決饑餓問題，可以：

1、優(yōu)化消耗大多數CPU帶寬的代碼。

2、提高CPU的時鐘速度。

總結

IDE內置的調試器通常不足以調試基于RTOS的實時系統。

幸運的是，有專門為調試基于RTOS的系統而設計的工具。其中一個工具是Segger的SystemView，它會按時間順序顯示ISR和任務的執(zhí)行，收集運行時統計數據，如最小和最大執(zhí)行時間、ISR與任務之間的關系、CPU負載等。

另一個可以補充SystemView的工具是Micrium的μC/Probe，這是一個通用工具，它允許開發(fā)人員在不干擾CPU的情況下，可視化和改變正在運行的嵌入式目標的行為。μC/Probe可以用于裸機或基于RTOS的應用中。對于基于RTOS的應用程序，μC/Probe包括非侵入性的、實時內核感知以及TCP/IP協議棧感知功能。SystemView和μC/Probe可以在整個開發(fā)周期中使用，提供關于嵌入式目標的運行時行為的反饋。

原文標題：哪些工具可以在使用RTOS時發(fā)現實時系統的bug？

文章出處：【微信公眾號：RTThread物聯網操作系統】歡迎添加關注！文章轉載請注明出處。

責任編輯：haq