調試是每個開發人員都想避免的一項任務，但不幸的是，這是軟件開發的必然之舉。事實上，正如EDN的嵌入式研究所揭示的那樣，嵌入式開發項目平均花費超過其總體努力的20％用于單獨調試。當你的袖子卷起來并開始調試時，這里有一些提示可以幫助你。

提示1 -采取可控制的步驟

當一個bug進入嵌入式軟件時，開發人員的第一直覺往往是跳入代碼并啟動做出改變。但是，開發人員的方法通常是偶然的，幾乎是隨機的，而不是以受控制的方式進行更改。嵌入式軟件開發不是狂野西部。解決甚至最簡單的錯誤應該包括檢查可用數據，評估它，假設最可能的原因，更新代碼，然后測試更新。如果變更沒有解決問題，新數據至少應該被曝光，這有助于重復該過程。

提示2 -增加斷言密度

ASSERT 宏是一個很棒的工具，可以在運行時返回錯誤消息斷言的條件是錯誤的。開發人員可以使用此宏來驗證其代碼中的假設是否成立。令人驚訝的是，許多開發人員沒有花時間將斷言放入他們的代碼中。代碼庫的 ASSERT 密度通常可能是長期和痛苦的調試會話之間的差異，也可能是失敗假設發生時的陷阱。 ASSERT 可以幫助開發人員立即發現錯誤或假設失敗。您的代碼庫的 ASSERT 密度是多少？

技巧3 -使用數據記錄器

有關軟件運行方式的信息是嵌入式軟件工程師在調試時可以擁有的最佳工具。擁有諸如任務開始和完成時的性能信息，是否被搶占以及類似的細節都是至關重要的。記錄所采取的操作是開發人員深入了解軟件行為的好方法。日志可以像RAM緩沖區一樣簡單，文件寫入外部閃存，也可以像傳輸到遠程位置的編碼數據一樣復雜。

技巧4 -使用高級斷點

開發人員熟悉使用IDE中可以打開的標準斷點，只需雙擊一個斷點即可代碼的左邊距。但是，許多IDE還具有更高級的斷點功能，這是開發人員很少使用的功能。高級斷點的一個示例是在變量達到某個值時設置要斷開的行。使用高級斷點可以大大減少調試時間，并且難以發現很容易發現錯誤。

提示5 -再次查看數據表

調試外圍設備可能特別困難。現代微控制器可以在設置單個外設時涉及許多寄存器，這些外設設置并不總是很明顯或有很好的記錄。更糟糕的是，有關如何正確設置外設的詳細信息通常并非都在一個數據表中。相反，信息的形式是“面包屑”，散布在家庭和外圍數據表中，有時甚至在應用筆記中。僅僅查看一個文檔是不夠的。當硬件行為不端時，您需要反復查看數據表。

提示6 -監控調用堆棧

開發人員有時會質疑他們如何才能獲得特定的代碼行。 IDE包含一個可以準確顯示該信息的調用堆棧窗口。調用堆棧顯示調用了哪些函數以及以什么順序調用，顯示對于跟蹤錯誤非常有用的信息。

提示7 -休息一下

調試可能是一項繁重的工作。深入研究軟件和硬件的運作可以為開發人員提供隧道視野。開發人員有時需要通過繼續執行其他任務或休息來退后一步。通過散步或做一些放松的事情離開系統將允許潛意識在有意識的思維休息時處理解決方案，以便當再次開始查看代碼時，通常會有其他見解。

結論

無論是花費大量時間進行調試還是花費很少，事實上嵌入式軟件開發人員都無法避免。使用本文中的提示有助于使調試更成功，因此更加可口。