死鎖：

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

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

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

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

饑餓：

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

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

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

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

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

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

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

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

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

3 - 雙擊事件窗口中顯示事件 #4016155 的行會強(qiáng)制時(shí)間軸窗口顯示該事件?？梢钥闯觯琒ysTick 的執(zhí)行時(shí)間比其他執(zhí)行時(shí)間要寬。

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

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

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

elapsed_time_start（n）;

// 測量代碼

elapsed_time_stop（n）;

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

elapsed_time_tbl［n］.min

elapsed_time_tbl［n］.max

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

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

概括

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

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

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

審核編輯：郭婷