死鎖：

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

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

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

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

饑餓：

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

優化占用大部分 CPU 帶寬的代碼。

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

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

監控任務和 ISR 執行時間

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

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

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

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

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

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

測量用戶代碼的執行時間

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

elapsed_time_start（n）;

// 測量代碼

elapsed_time_stop（n）;

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

elapsed_time_tbl［n］.min

elapsed_time_tbl［n］.max

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

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

概括

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

幸運的是，有專門為調試基于 RTOS 的系統而設計的專用工具，但開發人員通常不知道這些工具。這些工具之一是 Segger 的 SystemView ，它在時間線上顯示 ISR 和任務，并收集運行時統計信息，例如最小和最大執行時間、ISR 和任務之間的關系、CPU 負載等等。

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

審核編輯：郭婷