基于 RTOS 的問題

在本節(jié)中，我們將探討開發(fā)人員在使用 RTOS 時遇到的一些常見問題，并展示如何檢測和糾正這些問題。

堆棧溢出：

在基于內核的應用程序中，每個任務都需要自己的堆棧。任務所需的堆棧大小是特定于應用程序的。 如果使堆棧大于任務所需，則會浪費內存。如果堆棧太小，您的應用程序很可能會覆蓋應用程序變量或另一個任務的堆棧。堆棧區(qū)域外的任何寫入都稱為堆棧溢出。當然，在這兩種選擇之間，為堆棧過度分配內存比分配不足要好。因此，您可以通過過度分配內存來減少堆棧溢出的機會。但是，通常只需要 25-50% 的額外堆棧空間。一些 CPU，例如基于 ARMv8M 架構的 CPU，具有內置的堆棧溢出檢測功能。但是，該功能無助于確定正確的堆棧大小。它只是防止堆棧溢出的負面后果。

參考文獻［1］解釋了如何確定每個任務堆棧的大小。簡而言之，您通過為任務堆棧過度分配空間來開始您的設計，然后在已知的最壞情況下運行您的應用程序，同時監(jiān)控實際的堆棧使用情況。

下圖是 μC/Probe 對一個測試應用的內核感知的截圖。Stack Usage列顯示每個任務在任何給定時間的最大堆棧使用量的條形圖。雖然截取了屏幕截圖，但 μC/Probe 會實時更新并顯示此信息，因此您無需停止目標即可查看此信息，因為它正在更新。

綠色表示最大堆棧使用率一直保持在 70% 以下。

黃色表示堆棧使用率介于 70% 和 90% 之間。

紅色表示堆棧使用率已超過 90%。

顯然，應該增加使用 92% 的任務的堆棧，使其回到 70% 范圍以下。黃色的任務堆棧是空閑任務，在 77% 的情況下，它通常不會成為問題，除非您將代碼添加到空閑任務回調函數（這取決于您使用的 RTOS）。

中斷響應：

在操作內部數據結構（即臨界區(qū)）時，RTOS 和應用程序代碼通常必須禁用中斷。RTOS 開發(fā)人員盡一切努力減少中斷禁用時間，因為它會影響系統(tǒng)對事件的響應。

一些 RTOS 實際上基于每個任務測量最壞情況下的中斷禁用時間，如下面的 μC/Probe 屏幕截圖所示。如果您試圖滿足實時截止日期，則此信息非常寶貴。

中斷被禁用的時間很大程度上取決于 CPU、它的時鐘頻率、您的應用程序和被調用的 RTOS 服務。禁用中斷時間最長的任務以紅色突出顯示。這使您可以快速識別潛在的異常值，尤其是在大型和復雜的應用程序中。

如果最大的中斷禁用時間是由 RTOS 引起的，那么您可能無能為力，除非：

查找中斷禁用時間較短的備用 RTOS API。例如，如果您只是向任務發(fā)出信號以指示事件發(fā)生，那么您可以簡單地掛起/恢復任務，而不是使用信號量或事件標志。換句話說，等待事件的任務會自行掛起，而發(fā)出事件信號的 ISR 會恢復任務。

提高 CPU 的時鐘頻率。不幸的是，這很少是一種選擇，因為其他因素可能已經決定了理想的 CPU 時鐘頻率。

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

優(yōu)先級反轉：

當低優(yōu)先級任務擁有高優(yōu)先級任務所需的資源時，就會發(fā)生優(yōu)先級反轉。當中等優(yōu)先級任務搶占低優(yōu)先級任務同時持有資源時，問題會更加嚴重。術語“優(yōu)先級倒置”指的是低優(yōu)先級任務的行為就好像它比高優(yōu)先級任務具有更高的優(yōu)先級，至少在共享該資源時是這樣。

優(yōu)先級反轉是實時系統(tǒng)中的一個問題，并且在使用基于優(yōu)先級的搶占式內核時會發(fā)生（大多數 RTOS 都是搶占式的）。如下圖所示，SystemView 用于說明優(yōu)先級倒置的場景。

App HPT（High Priority Task）優(yōu)先級最高

App MPT （Medium Priority Task） 具有中等優(yōu)先級

App LPT （低優(yōu)先級任務）的優(yōu)先級最低

1 - LPT 是唯一可以運行的任務，因此它獲取 CPU 并獲取信號量以訪問共享資源。

2 -為了模擬優(yōu)先級反轉的發(fā)生，LPT 使 HPT 準備好運行，因此 RTOS 上下文切換到 HPT。

3 - HPT 使 MPT 準備好運行但繼續(xù)執(zhí)行，因為 HPT 仍然具有更高的優(yōu)先級。

4 - HPT 需要訪問共享資源并嘗試獲取信號量。但是，由于信號量歸 LPT 所有，HPT 無法繼續(xù)執(zhí)行，因此 RTOS 切換到 MPT。

5 - MPT 一直執(zhí)行，直到它需要等待其事件再次發(fā)生，以便 RTOS 切換回 LPT。

6 - LPT 完成對共享資源的使用，因此它釋放信號量。此時，RTOS 注意到 HPT 正在等待資源，因此將信號量提供給 HPT 并使其準備好運行。HPT 恢復執(zhí)行并執(zhí)行它需要對共享資源執(zhí)行的任何操作。

7 - 一旦 HPT 完成對資源的訪問，它就會釋放信號量，然后等待其事件再次發(fā)生（在這種情況下，我們通過自掛起模擬了這一點）。

8 - LPT 恢復執(zhí)行，因為其他兩個任務都沒有準備好運行。

9 -發(fā)生優(yōu)先級反轉是因為 LPT 擁有 HPT 需要的資源。但是，當中等優(yōu)先級任務進一步延遲 LPT 釋放信號量時，問題會變得更糟。

您可以通過使用稱為 Mutex（互斥信號量）的特殊 RTOS 機制來解決上述優(yōu)先級反轉問題。下圖顯示了相同的場景，除了這里 LPT 和 HPT 都使用互斥鎖而不是信號量來訪問共享資源。

1 - LPT 是唯一可以運行的任務，因此它獲取 CPU 并獲取互斥體以訪問共享資源。

2 - 為了模擬優(yōu)先級反轉的發(fā)生，LPT 使 HPT 準備好運行，因此 RTOS 上下文切換到 HPT。

3 - HPT 使 MPT 準備好運行但繼續(xù)執(zhí)行，因為 HPT 仍然具有更高的優(yōu)先級。

4 - HPT 需要訪問共享資源并嘗試獲取互斥鎖。但是，由于互斥鎖歸 LPT 所有，因此 HPT 無法繼續(xù)執(zhí)行。但是，由于使用了互斥體，RTOS 會將 LPT 的優(yōu)先級提高到 HPT 的優(yōu)先級，以防止它被中等優(yōu)先級搶占。

5 - 然后 RTOS 切換到 LPT，它現在以與 HPT 相同的優(yōu)先級運行。

6 - LPT 完成對共享資源的使用，因此它釋放互斥鎖。RTOS 將 LPT 的優(yōu)先級降低回其原始（較低）優(yōu)先級，并將互斥鎖分配給 HPT。

7 - RTOS 切換回 HPT，因為它正在等待釋放互斥鎖。一旦完成，HPT 就會釋放互斥鎖。

8 - 一旦 HPT 完成其工作的執(zhí)行，它就會等待它正在等待的事件的再次發(fā)生。

9 - RTOS 切換到在就緒隊列中等待的 MPT。

10 -當 MPT 完成它的工作時，它還掛起將導致該任務再次執(zhí)行的事件。

11 - LPT 現在可以恢復執(zhí)行。

優(yōu)先級反轉現在受限于 LPT 訪問共享資源所需的時間量。如果沒有像 SystemView 這樣的工具，優(yōu)先級反轉將很難識別和糾正。

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

審核編輯：郭婷