當使用實時操作系統(RTOS)時，嵌入式開發人員可以在更高的抽象級別上工作，類似于從匯編語言編程到c語言的轉變。在這一更高的級別上工作可以更容易地設計復雜的應用程序，但是盡管RTOS降低了應用程序源代碼的復雜性，但它并沒有降低應用程序本身的固有復雜性。這會使應用程序難以驗證和調試。

　　使基于RTOS的開發比編寫裸機超級循環應用更困難的是，RTOS任務不是孤立的實體，它們具有可能以意想不到的方式延遲任務執行的依賴性。微妙的編碼選擇會導致最終產品中難以捉摸的錯誤或性能問題。當作為一個系統一起執行時，一組看似簡單的RTOS任務可能導致驚人復雜的運行時行為;可能有無數的執行場景不可能被測試或代碼審查完全覆蓋。

　　多任務處理，但控制更少

　　開發人員面臨的挑戰是，當開發沿著抽象的階梯向上發展時，調試工具卻沒有跟上。雖然標準調試工具仍然主要關注斷點和單步執行源代碼，但可視化跟蹤診斷讓開發人員能夠在系統級別全面了解應用程序的行為。

　　RTOS的主要工作是提供多任務處理，幾個任務可以并行執行以實現一個共同的目標。基于RTOS的應用程序的嵌入式開發人員可以保留對任務優先級等參數的一些控制，這反過來支持確定性的實時行為，但他們失去了對更精細細節的控制。例如，程序流在源代碼中不再明顯，因為操作系統決定在任何給定時刻執行哪個任務。

　　使用RTOS和可視跟蹤診斷，開發人員可以在這個更高的抽象級別上工作，并捕獲他們的應用程序的定時和同步方面，這是傳統調試器根本無法看到的。

　　我們已經確定了這種類型的五個常見實時應用程序錯誤。

　　l CPU資源匱乏

　　l 振動

　　l 優先級反轉

　　l 僵局

　　l 內存泄漏

　　這些只是五個最常見的RTOS開發錯誤，但代碼中可能隱藏著無數其他錯誤。你可以嘗試通過調試來猜測自己的方式，嘗試一件又一件的事情來讓應用程序正常運行。但要解決這個問題，你需要了解導致它的軟件事件的具體順序，包括應用程序和RTOS之間的交互。傳統的調試工具無法提供這種見解。在嵌入式開發中，RTOS跟蹤可視化可以被認為是應用程序內部的慢動作視頻，它提供了RTOS應用程序按設計運行的信心，是檢測和糾正錯誤的最快方法。