毫無疑問，當你開始在嵌入式開發中使用實時操作系統(RTOS)時，會有一個學習曲線。你將在更高的抽象層次上工作，使用或多或少的并行任務，而不僅僅是子例程，并且你需要考慮你的任務應該如何彼此共享數據和處理器時間。你需要為這些任務分配運行時優先級，而最佳解決方案并不明顯。

　　最后但同樣重要的是，你需要學習如何使用RTOS本身，比如配置和用于控制任務和任務間通信的API函數。

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

　　調試RTOS系統(通常使用搶占式多任務處理)與調試單線程“超級循環”系統(所有代碼都是你自己編寫的)不同，這有幾個原因，最重要的兩個原因是：

　　l 隨著多個任務相互作用并爭奪共享資源，軟件行為可能會受到軟件定時和RTOS調度行為的影響，而這在源代碼中是不可見的。

　　l 你不再直接控制程序流——任務開關可能在任何地方、任何時間觸發。

　　這些問題真的沒有辦法解決，你必須處理這些問題，因為你必須信任操作系統來安排任務和管理計時器。某些任務切換可能是可預測的，因此是已知的，但通常你不知道它們將在程序流中的何處發生。在嵌入式開發中，隨著系統中任務/線程的數量增加，組合的數量也會增加——可能會有大量可能的執行場景，具有不同的時間和執行順序，其中大多數都會正常工作。

　　下面列出了一些典型的癥狀，如果你有RTOS相關的計時錯誤，你可能會看到這些癥狀。請注意，這些問題中的許多通常具有一定程度的隨機性;這個問題有時會出現，但并不總是出現。

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

　　l 任務單獨工作很好，但作為一個完整的系統就不行了

　　l 緩慢的性能

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

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

　　l 輸出時序的隨機變化

　　l 有時損壞的數據，或錯誤的輸出

　　l 隨機崩潰/硬故障

　　依賴于時間的錯誤可能很難再現或發現，尤其是因為大多數調試工具對多任務問題幾乎沒有支持。在嵌入式開發中，大多數工具仍然專注于靜態暫停系統，而不是動態軟件行為。相比之下，許多系統都有實時要求，無法停止調試。

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

　　在嵌入式開發中，如果你想了解應用程序和RTOS內部實際發生的事情的可靠時間線，你需要一個能夠感知RTOS的跟蹤，在事情發生時記錄下來，還需要一個工具來幫助你理解跟蹤信息。

　　站長幫手網(www.linkhelper.cn)

　　文章格式化編輯

　　繁簡體相互轉換

　　文字挑錯功能(1000個錯別字詞庫)

　　可定制段前是否空格

　　只需鼠標點擊

　　全傻瓜式操作