基于 RTOS 的問題

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

堆棧溢出：

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

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

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

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

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

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

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

中斷響應(yīng)：

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

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

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

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

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

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

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

優(yōu)先級反轉(zhuǎn)：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

11 - LPT 現(xiàn)在可以恢復(fù)執(zhí)行。

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

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

審核編輯：郭婷