死鎖：

死鎖（又名致命擁抱）是一種情況，其中（至少）兩個任務(wù)都在不知不覺中等待另一個擁有的資源。死鎖可能不會立即發(fā)生，因為很大程度上取決于兩個任務(wù)何時需要彼此的資源。如下圖所示，μC/Probe 的內(nèi)核感知屏幕有一列顯示每個任務(wù)執(zhí)行的頻率（即任務(wù)由 RTOS 切換的頻率）。您可以通過監(jiān)視此列來檢測死鎖，并注意您期望運(yùn)行的任何任務(wù)是否實際上正在運(yùn)行。換句話說，如果計數(shù)停止（μC/Probe 在 CPU 運(yùn)行時更新這些計數(shù)器），那么您可能檢測到死鎖。但是，對于這種情況，您還會注意到至少有兩個任務(wù)停止計數(shù)。您可能不需要使用像 μC/Probe 這樣的工具來檢測死鎖，因為在任何情況下，您都應(yīng)該注意應(yīng)用程序中這些任務(wù)的鎖定行為。但是，該工具使其更加明顯。

您可以通過以下方式避免死鎖：

總是獲取所有需要的資源，總是以相同的順序獲取它們并以相反的順序釋放它們。

在 RTOS API 調(diào)用上使用超時以避免永遠(yuǎn)等待資源可用。確保檢查來自 RTOS API 的返回錯誤代碼，以確保您對所需資源的請求確實成功。

饑餓：

當(dāng)高優(yōu)先級任務(wù)消耗所有 CPU 的帶寬時，就會發(fā)生饑餓，為低優(yōu)先級任務(wù)留下很少或沒有 CPU 時間。饑餓的影響的特點是響應(yīng)能力和產(chǎn)品功能的下降，例如嵌入式目標(biāo)的顯示更新緩慢、通信堆棧中的數(shù)據(jù)包丟失、操作員界面遲緩等。除了解決這些問題之外，您幾乎無能為力至：

優(yōu)化占用大部分 CPU 帶寬的代碼。

提高 CPU 的時鐘速度。由于其他系統(tǒng)考慮，這很少是一種選擇。

選擇另一個 CPU。這也很少是一種選擇，尤其是在開發(fā)周期的后期。

監(jiān)控任務(wù)和 ISR 執(zhí)行時間

了解任務(wù)和 ISR 的執(zhí)行時間對于幫助基于 RTOS 的系統(tǒng)分析（例如速率單調(diào)分析 （RMA））通常很有用。具體來說，通過這些信息，您可以確定是否所有時間緊迫的任務(wù)都可以按時完成，并幫助您為任務(wù)分配優(yōu)先級。不幸的是，這些信息只有在系統(tǒng)設(shè)計和運(yùn)行后才真正準(zhǔn)確和可用。換句話說，代碼的實際執(zhí)行時間通常要在實際目標(biāo)上執(zhí)行時才能準(zhǔn)確知道。然而，一旦可用，任務(wù)和 ISR 執(zhí)行時間對于確認(rèn)系統(tǒng)設(shè)計期間所做的假設(shè)非常有用。

SystemView 提供任務(wù)和 ISR 的最小/最大執(zhí)行時間，如下面的屏幕截圖所示。

1 -上下文窗格中 的Max Run Time列顯示所有任務(wù)和 ISR 的最大執(zhí)行時間。在SysTick（即tick ISR）的情況下，最長的執(zhí)行時間是0.5488 ms。我們可以通過搜索事件 #4016155 來確定何時（及時）發(fā)生了這個較長的執(zhí)行時間。您只需從 Go 菜單中選擇 Go to event 。.. 并鍵入 4016155，然后按 Enter。

2 - 事件窗口顯示這對應(yīng)于 ISR 出口。事實上，這是有道理的，因為只有在 ISR 退出時才知道 ISR 的最大執(zhí)行時間。

3 - 雙擊事件窗口中顯示事件 #4016155 的行會強(qiáng)制時間軸窗口顯示該事件。可以看出，SysTick 的執(zhí)行時間比其他執(zhí)行時間要寬。

在大多數(shù)情況下，您不需要找到（及時）任務(wù)或 ISR 的最大執(zhí)行時間發(fā)生在哪里，尤其是當(dāng)您僅將該信息用于 RMA 時。但是，在某些情況下，您可能需要找出執(zhí)行時間比預(yù)期或預(yù)期長得多的原因。不幸的是，SystemView 可能無法提供關(guān)于發(fā)生這種情況的原因的額外線索。您可能希望在此處使用代碼執(zhí)行跟蹤工具（例如 Segger 的 J-Trace）并檢查 ISR 在事件 #4016155 之前執(zhí)行的代碼。

測量用戶代碼的執(zhí)行時間

有很多方法可以測量代碼執(zhí)行時間。一種方法是使用具有跟蹤功能的調(diào)試探針。您只需運(yùn)行代碼、查看跟蹤、計算增量時間（通常是手動）并將 CPU 周期轉(zhuǎn)換為微秒。不幸的是，跟蹤為您提供了一個執(zhí)行實例，您可能需要進(jìn)一步查看跟蹤捕獲以找到最壞情況下的執(zhí)行時間。這可能是一個乏味的過程。另一種方法是檢測您的代碼并在代碼的不同位置拍攝可用的自由運(yùn)行計數(shù)器的快照，并計算快照讀數(shù)之間的差異。這實際上在嵌入式計算設(shè)計［7］上發(fā)表的一篇論文中有所描述對于 Cortex-M MCU，但該概念同樣適用于其他目標(biāo)。該論文提供了 API 來測量經(jīng)過的時間。您只需將要測量的代碼包裝如下：

elapsed_time_start（n）;

// 測量代碼

elapsed_time_stop（n）;

其中“n”指定“n”個 bin（0 到 n-1）之一，其中最小和最大執(zhí)行時間保存如下：

elapsed_time_tbl［n］.min

elapsed_time_tbl［n］.max

在 Cortex-M 的情況下，執(zhí)行時間以 CPU 時鐘頻率單位保存。

如下圖所示，您可以使用 Micrium 的 μC/Probe 輕松顯示以微秒為單位的結(jié)果。μC/Probe 允許對數(shù)字進(jìn)行縮放，在這種情況下，需要根據(jù)所用評估板的 CPU 時鐘頻率進(jìn)行調(diào)整。

概括

IDE 中內(nèi)置的調(diào)試器通常不足以調(diào)試基于 RTOS 的實時系統(tǒng)。

幸運(yùn)的是，有專門為調(diào)試基于 RTOS 的系統(tǒng)而設(shè)計的專用工具，但開發(fā)人員通常不知道這些工具。這些工具之一是 Segger 的 SystemView ，它在時間線上顯示 ISR 和任務(wù)，并收集運(yùn)行時統(tǒng)計信息，例如最小和最大執(zhí)行時間、ISR 和任務(wù)之間的關(guān)系、CPU 負(fù)載等等。

另一個可以補(bǔ)充 SystemView 的工具是 Micrium 的 μC/Probe ，它是一種通用工具，允許開發(fā)人員在不干擾 CPU 的情況下可視化和更改正在運(yùn)行的嵌入式目標(biāo)的行為。μC/Probe 在裸機(jī)或基于 RTOS 的應(yīng)用中同樣適用。對于基于 RTOS 的應(yīng)用程序，μC/Probe 包括非侵入式實時內(nèi)核感知以及 TCP/IP 堆棧感知。兩種類型的工具（SystemView 和 μC/Probe）都應(yīng)該在早期和整個開發(fā)周期中使用，以提供有關(guān)嵌入式目標(biāo)運(yùn)行時行為的反饋。

審核編輯：郭婷