多線程 RTOS 應用程序的一個更被低估的方面是，您不能只查看代碼來完全理解應用程序的工作原理。

你需要知道它的各個部分是如何相互通信的，你需要很多其他信息：任務需要多長時間才能執行，是否存在任何潛在的競爭條件或死鎖，你是否滿足你的計時要求等等。

您希望代碼執行的操作和實際執行的操作可能在許多方面有所不同，這些差異在代碼中既難以看到，也難以測試。對于所有使用多線程代碼的開發人員來說，無論他們使用 RTOS 還是 Linux，這都是一個挑戰，最好使用可視化跟蹤診斷工具進行管理，這些工具可以讓您深入了解我所說的代碼的“黑暗面”——您可以從字面上看到它在執行時的行為。

視覺時間線是一個很好的起點。在許多情況下，查看隨時間分布的軟件事件、消息和任務執行非常重要，例如，當從癥狀中看不出錯誤的確切位置時，計算機在數字處理和文本日志中搜索方面可能非常出色，但通常您不知道要搜索什么。在視覺模式識別方面，人腦表現出色。

顯示軟件事件的可視化時間線為您提供了嵌入式應用程序內部工作的概述，如果您需要深入挖掘以查找錯誤，這是一個很好的起點。

調試時更好的洞察力意味著猜測更少，找到根本原因的幾率更高。在無法使用傳統方法（如在斷點上停止系統）的情況下，它也有很大幫助。

你說printf調試呢？是的，printf 易于部署，有時它確實是您所需要的，但它的價格很高。將調試打印輸出放在對時間敏感的應用程序代碼中是有風險的，并且不能很好地擴展到更復雜的應用程序和更快的處理器。此外，printf 通常非常慢，每次打印輸出大約幾毫秒。相比之下，軟件事件跟蹤的優化解決方案可以比這快 100 倍左右，允許您在同一時間段內收集更多信息。

確保在整個開發項目中測量時間和性能。如果做得好，這可以確保您能夠在開發過程中檢測和解決任何問題，而不是在承諾的交付日期之前與時間賽跑。

滿足時序規格對于具有硬要求的實時系統至關重要，但對于幾乎任何嵌入式系統的用戶體驗也很重要。沒有人喜歡緩慢的觸摸屏或慢速的wifi路由器，因為它無法提供承諾的吞吐量。同樣，從源代碼來看，根本原因可能并不明顯，如果真正的問題是糟糕的軟件設計，簡單地切換到更快的處理器可能沒有任何好處。

如果您發現自己處于項目的“調試地獄”中，大量的調試會消耗房間中的所有能量并阻止項目向前發展，那么可視化跟蹤診斷可以幫助您。在基于 RTOS 的應用程序的軟件設計中未能遵循最佳實踐通常是一個主要因素，它可能以性能差、處理器負載高或瞬態錯誤等形式出現。任務之間的大量依賴關系是設計可以改進的另一個常見信號。

即使是架構不佳的系統今天也可能運行，但它們將具有復雜和混亂的行為，再加上糟糕的可測試性，這增加了難以捉摸的錯誤泄漏到生產設備的風險。而且它們幾乎肯定會很脆弱，因此代碼或環境中的微小更改可能會導致它們失敗。

可視化跟蹤診斷可幫助開發人員分析和改進其軟件設計，并確保穩定可靠的系統行為。當您能夠更早地發現軟件設計缺陷時，修復它們所需的更改更少。設計改進還可以帶來更好的系統性能和響應能力，這反過來又可以讓您選擇更具成本效益的處理器來降低 BoM 成本或使用較低的時鐘頻率以延長電池壽命。

使用跟蹤工具將跟蹤數據連續流式傳輸到主機，如有必要，您可以在主計算機上存儲很長的記錄，甚至可以在屏幕上實時顯示數據。跟蹤流使您能夠監視系統測試或查找難以重現的罕見錯誤。可視化跟蹤診斷允許在高級可視化概述中發現異常，并向下鉆取到特定事件以準確了解發生了什么。

最后，可視化跟蹤診斷可以作為純軟件解決方案實現，不需要額外的硬件，甚至不需要調試探針。內存和處理器使用量是有成本的，但通常不超過這個成本，你可以在整個開發、測試甚至部署過程中將其保留在系統中。在所有階段都提供這些信息意味著每個人都每天都能從中受益。

此方法允許記錄應用程序中的任何相關信息，包括運行時未公開的內部數據和狀態。數據可以與可視化執行時間線并行繪制，以便在運行時深入了解您的應用程序。這樣，您可以制作出擊敗競爭對手的出色產品。

遵循這五個最佳實踐，在系統級別獲得所需的實時行為可見性，以提高產品質量并加快開發速度，從而更快地進入市場。

審核編輯：郭婷