基于 RTOS 的問題

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

堆棧溢出：

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

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

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

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

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

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

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

中斷響應：

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

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

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

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

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

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

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

優先級反轉：

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

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

App HPT（High Priority Task）優先級最高

App MPT （Medium Priority Task） 具有中等優先級

App LPT （低優先級任務）的優先級最低

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

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

3 - HPT 使 MPT 準備好運行但繼續執行，因為 HPT 仍然具有更高的優先級。

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

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

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

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

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

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

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

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

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

3 - HPT 使 MPT 準備好運行但繼續執行，因為 HPT 仍然具有更高的優先級。

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

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

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

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

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

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

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

11 - LPT 現在可以恢復執行。

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

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

審核編輯：郭婷