There are a lot of potential changes that software development teams can make to decrease the time they spend debugging and get it into single-digit percentages.

工程師喜歡解決問題。這就是我們所做的。不幸的是，嵌入式軟件工程師最大的問題之一是我們制造了很多問題，然后通過花費大量時間來修復它們（調試?。┦棺约撼蔀橛⑿邸?a target="_blank">嵌入式軟件工程師花費 20% 到 40% 的時間進行調試的公司很常見！值得慶幸的是，團隊可以做出很多潛在的改變來減少他們花費在調試上的時間，并將其降低到個位數的百分比。在本文中，我們將研究幾個減少調試時間的技巧。

提示 #1 – 擁抱測試驅動開發 (TDD)

測試驅動開發是一種允許開發人員增量構建他們的生產軟件的技術，他們依靠測試來指示他們編寫的代碼。例如，TDD 讓開發人員首先編寫一個測試用例，使其失敗，然后只編寫允許該測試用例通過的代碼。然后重復該過程。

傳統上，嵌入式軟件開發人員會在測試之前編寫整個代碼模塊。在幾周內編寫數千行代碼是可能的。那么，到了測試它的時候，如果它不起作用，問題在哪里呢？只有天知道！開發人員必須煞費苦心地回顧代碼并發現問題所在并修復它。執行此操作所需的時間可能相當可觀。

另一方面，對于使用 TDD 的開發者來說，如果出現錯誤并在代碼中注入了 bug，測試用例會立即告訴開發者！由于他們正在逐步編寫代碼，因此他們更有可能確切地知道他們所做的更改并可以立即解決問題。TDD 似乎需要更多時間來練習，但它創建了一組可以在回歸測試中運行的測試用例，以確保一切都按預期工作。TDD 一石二鳥：減少調試時間和自動化測試。

提示 #2 – 盡可能多地開發脫靶

當一個項目開始時，幾乎每個嵌入式軟件開發人員的第一反應就是獲得一塊開發板并開始編寫嵌入式代碼。不幸的是，在許多情況下，嵌入式代碼并不是我們產品的差異化因素。這是應用程序代碼。雖然許多應用程序代碼最終需要與硬件交互，但許多模塊可以脫靶開發，即在主機上。

開發脫靶代碼為開發人員提供了許多減少每個調試周期所花費時間的機會。例如，通常，要為目標微控制器編寫和測試代碼，開發人員必須：

交叉編譯代碼

啟動調試會話

通過 SWD 對設備進行編程

在目標上運行代碼

通過在目標上運行代碼來驗證代碼是否正常工作（還必須具有所有低級代碼）。

如果代碼是在主機上開發的，開發人員必須為主機編譯它，然后使用單元測試工具、仿真器或自定義程序來運行正在開發的代碼。如果發現問題，修復、重新編譯并重新開始會更快。在嵌入式目標上，僅對目標進行編程就會使每個周期增加幾十秒，更不用說單步執行代碼的誘惑了。

脫靶開發/調試可能會產生特定的錯誤。但是，我現在編寫了大約 75% 的代碼偏離目標，并且發現我的速度更快、效率更高。我可以快速強制代碼中的問題，確定原因，修復它，然后繼續前進，而不是通過嵌入式目標跟蹤問題。當然，有些事情會出現在目標上，而不會出現在主機上。

提示 #3 – 掌握調試策略

人類已知的效率最低的調試方法是單步調試代碼行。不要誤會我的意思，有時間和地點，但往往會浪費很多時間。不幸的是，嵌入式軟件開發人員默認使用斷點和單步調試。為了更好地調試，開發人員需要掌握現代微控制器上可用的其他調試策略。

今天，至少有八種不同的調試技術可供開發人員使用。這些技術從最簡單到最復雜的順序包括：

Watch / Expressions：為開發人員提供檢查 CPU 和外設寄存器的能力。它們通?？捎糜诒O視變量、執行計算或在更改時停止 CPU。

斷點：為開發人員提供在特定代碼行上停止 CPU 執行的能力。高級斷點可用于設置條件語句。

printf：為開發人員提供將字符數據打印到映射的串行接口的能力。根據實現，這可能會或可能不會影響實時性能。

斷言：這些是用于驗證程序中特定點的假設的條件語句。斷言失敗通常會停止 CPU 并提供失敗斷言的文件和行位置。

Statistical Profiling：對應用程序中的各種寄存器進行定期采樣，這些寄存器同時發生在其運行中。通常不會影響實時性能。例如，可能想要對程序計數器 (PC) 進行采樣以了解正在執行的代碼模塊。

數據分析：對包含可變數據的各種內存位置進行定期采樣。當與實時可視化工具一起使用來監控系統狀態、感興趣的變量變化等時，數據分析會非常有用。

任務和數據跟蹤：使開發人員能夠跟蹤實時操作系統應用程序中的事件。因此，開發人員可以深入了解應用程序性能、任務延遲、運行時間等等。

指令跟蹤：使開發人員能夠記錄在處理器上執行的每條指令。這可用于了解測試期間的代碼覆蓋率、調試編譯器問題等。

掌握所有這些技術并知道何時使用它們可以大大減少當缺陷確實進入系統時用于調試的時間。

結論

可能會花費大量時間調試嵌入式軟件。有時，調試時間是無法避免的；但是，在許多情況下，開發人員可能會花費比他們需要的時間更多的時間。我們已經探索了幾個您可以進一步調查的領域，以減少您和您的團隊花費在調試上的時間。如果您花費超過 20% 的時間進行調試，請在本周花一個小時確定您可以立即開始進行哪些更改，以控制您花在調試上的時間。

審核編輯 黃昊宇