毫無疑問，當您開始在開發中使用實時操作系統 （RTOS） 時，會有一條學習曲線。您將在更高的抽象級別上工作，使用或多或少的并行任務而不僅僅是子例程，并且您將需要考慮您的任務應如何共享數據和處理器時間。您需要為這些任務分配運行時優先級，最好的解決方案是什么并不是很明顯。最后但同樣重要的是，您需要學習如何使用 RTOS 本身，例如用于控制任務和在它們之間進行通信的配置和 API 函數。

一旦你掌握了所有這些并且你正在編寫你的代碼，就到了下一個學習曲線的時候了——你現在也必須學習如何調試你的代碼。

調試 RTOS 系統（通常使用搶占式多任務處理）與調試您自己編寫所有代碼的單線程“超級循環”系統有幾個不同的原因，但我想說兩個主要原因是

由于多個任務交互并競爭共享資源，軟件行為可能會受到軟件時序和 RTOS 調度行為的影響，而在源代碼中是不可見的。

您不再直接控制程序流程——任務切換可能隨時隨地發生。

這些問題真的沒有辦法解決。您將不得不處理它們，因為您必須信任操作系統來安排您的任務和管理計時器。一些任務切換可能是可預測的，因此是已知的，但通常您不知道它們會在程序流的哪個位置發生。隨著系統中任務/線程數量的增加，組合的數量也在增加——可能存在大量可能的執行場景，具有不同的時間和執行順序，其中大多數都可以正常工作。但是，您的一位客戶報告了“噩夢錯誤”，只有在條件合適時才會出現，您無法重現。

下面的邊欄列出了一些典型癥狀，如果您有與 RTOS 相關的時序錯誤，您可能會看到這些癥狀。請注意，其中許多問題通常具有一定程度的隨機性；問題有時會出現，但并非總是如此。

依賴于時間的錯誤很難重現或發現，尤其是因為大多數調試工具對多任務問題的支持很少。在我看來，大多數工具仍然專注于靜態停止系統，而不是動態軟件行為。相比之下，許多系統具有實時要求，并且無法停止調試。

RTOS 相關時序錯誤的一些典型癥狀

任務可以單獨工作，但不能作為一個完整的系統

性能緩慢

系統鎖定，或有時停止響應

系統看起來很脆弱——微小的變化會導致奇怪的錯誤

輸出時序的隨機變化

有時數據損壞或輸出錯誤

隨機崩潰/硬故障

除了尋找癥狀之外，您當然應該使用您擁有的任何工具以及它們提供的工具來檢查您的 RTOS 和應用程序是否存在錯誤和不當行為。例如，您的 IDE 可能支持在調試期間輕松檢查 RTOS 對象（有時通過插件），甚至可以分析任務的堆棧使用情況。RTOS 可以讓您在較高級別測量 CPU 使用率，讓您了解每個任務平均需要多少 CPU 時間。一些調試器可以在系統執行時實時呈現變量（“實時監視”），盡管這可能不適合快速變化的變量。

如果您想查看應用程序和 RTOS 內部實際發生的事情的可靠時間線，您需要能夠在事件發生時記錄事情的 RTOS 感知跟蹤，以及可以幫助您理解跟蹤信息的工具。

審核編輯：郭婷