工程師喜歡解決問題，這是我們的工作，但是，嵌入式軟件工程師最大的問題之一是我們制造了很多問題，然后通過花費大量的時間來修復它們(調試！)。嵌入式軟件工程師花20–40%的時間進行調試的公司非常常見！令人欣慰的是，嵌入式開發團隊可以做出很多潛在的改變來減少他們花費在調試上的時間，并使其達到個位數的百分比。在本文中，我們將研究幾個減少調試時間的技巧。

 

技巧 1——擁抱測試驅動開發(TDD)

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

 

傳統上，嵌入式軟件開發人員會在測試之前編寫完整的代碼模塊。在幾周內編寫成千上萬行代碼是可能的。那么，到了測試的時候，如果不行的話問題出在哪里呢？開發人員必須費力地回顧代碼，發現問題所在并修復它，這樣做所需的時間可能相當長。

 

另一方面，對于使用TDD的開發者來說，如果犯了錯誤，在代碼中注入了bug，測試用例會立刻告訴嵌入式開發者！因為他們是增量地編寫代碼，所以他們更有可能確切地知道他們更改了什么，并且可以立即修復問題。TDD可能看起來需要花更多的時間來實踐，但是它創建了一個可以在回歸測試中運行的測試用例集合，以確保一切按預期運行。TDD一舉兩得：減少調試時間和自動化測試。

 

技巧2——盡可能遠離目標

當一個項目開始時，幾乎每個嵌入式軟件開發人員的第一反應都是拿到開發板，開始編寫嵌入式代碼。但是，在許多情況下，嵌入式代碼并不是我們產品中的區分器；這是應用程序代碼。雖然許多應用程序代碼最終需要與硬件交互，但許多模塊可以脫離目標開發，即在主機上開發。

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

l 交叉編譯代碼

l 啟動調試會話

l 通過SWD對器件進行編程

l 在目標上運行代碼

l 通過在目標上運行代碼來驗證代碼是否有效(還必須擁有所有底層代碼)。

 

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

技巧3——掌握調試策略

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

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

 

監視/表達式：為開發人員提供檢查CPU和外圍寄存器的能力。它們通常可用于監視變量、執行計算或在更改時停止CPU。

 

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

 

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

 

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

 

統計分析：在應用程序運行的同時，對應用程序中的各種寄存器進行定期采樣。通常不會影響實時性能。例如，可能需要對程序計數器（PC）進行采樣，以了解正在執行的代碼模塊。

 

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

 

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

 

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

 

掌握所有這些技術并知道何時使用它們可以顯著減少缺陷進入系統時調試所花費的時間。

 

結論

可能要花很多時間調試嵌入式軟件。有時候，調試時間就是無法避免；然而，在許多情況下，開發人員可能會花費比他們需要的更多的時間。我們已經探索了幾個領域，你可以進一步研究以減少你和你的嵌入式開發團隊花費在調試上的時間。如果你花了20%以上的時間調試，本周花一個小時來確定你可以立即開始做什么改變來控制你花在調試上的時間。