從只有幾千字節存儲空間的簡單 8 位控制器，到現在先進的 32 位控制器，雖然微控制器經歷了諸多演變，但是許多開發人員仍在使用老舊的工具，拖慢了開發周期。

設計人員若要適應當今快速發展且復雜多變的開發環境，則需要確保擁有合適的工具才能應對。他們需要嵌入式工具，以便監視芯片并查看其軟件是否按照預期方式運行；他們還需要可指出錯誤或優化代碼規模的工具，以降低其 BOM 成本。

現在有許多工具可以幫助他們降低整體開發成本，加快調試過程，從而縮短上市時間。本文將介紹一些這樣的工具，然后說明如何通過它們獲得最大收益。

利用專業調試器節省時間和金錢

開發人員編寫的軟件程序第一次試運行就正常工作非常少見。因此軟件開發需要調試，所以對于軟件開發人員來說，最重要的工具就是調試器。利用調試器，開發人員可以將應用程序加載到目標微控制器上，逐步檢查代碼，查看存儲器和其他寄存器，并操縱硬件。

問題是，許多專業開發人員通常使用的調試器是其低成本開發板所附帶的。這些調試器方便、便宜，而且在演示時表現完美。但是，在開發專業軟件時，可能會出現以下限制：

斷點有限

時鐘速率降低

缺乏跟蹤功能

功能極少

換言之，有時真是一分錢一分貨：附送的簡化工具集可能不是快速有效地開發和調試軟件的最佳方式。

專業級調試器具有許多功能，可提高工程師的生產力，例如無限制的斷點。許多調試器只能使用微控制器的內部比較器來設置斷點，而在大多數情況下只有兩個可用。在有數萬行代碼的復雜程序中，只有兩個可用的斷點可能會導致開發人員把時間浪費斷點切換上，也可能會導致開發人員錯過軟件中的關鍵點，從而錯過潛伏的漏洞。這樣一來，可能會導致編碼時間更長，反而增加了開發成本并影響了上市時間。

專業級調試器提供的算法不僅可以使用硬件斷點，還可以使用軟件和閃存斷點，為開發人員提供了更多的靈活性，而且用來評估代碼的斷點數量幾無限制。

當然專業級調試器不便宜。它們的價格可以輕松標到幾百到幾千美元。但它們為開發人員帶來了不可計算的投資回報，并能使用多年，無需升級或更換。選擇調試器時，開發人員應該問自己幾個問題：

調試器的斷點數是否無限制？

這是一款可以與幾乎所有工具鏈和微控制器配合使用的第三方調試器嗎？

五年后這個調試器還能使用嗎？

這個調試器有很好的生態系統嗎？

調試器的能力可以擴展嗎？

因為符合上述標準而變得非常受歡迎的一款第三方調試器是 Segger J-Link。根據開發人員的需求，Segger J-Link 可提供不同的版本。其中包括 J-Link Base Unit、J-Link Plus、J-Link Ultra Plus 和 J-Link Trace（圖 1）。

圖 1：Segger J-Link 調試器型號比較。（來源：Segger）

使用調試器跟蹤和分支檢測來揪出潛藏的錯誤

高級調試器（通常也是最昂貴的）配備 ETM 跟蹤連接器，可以獲得大量跟蹤數據，這是使用 JTAG 或 SWD 的標準跟蹤無法實現的。

使用高級跟蹤功能，開發人員可以將調試器與商業工具鏈（如適用于 ARM 的 Keil MDK-PRO）連用，來監視系統中的每一行代碼在測試期間是否得到執行。如下例所示，針對 ARM 的 Keil MDK-PRO 與跟蹤調試器一并運行，檢測到了那些代碼行在測試期間得到執行（圖 2）。這種跟蹤對于需要 100％ 測試覆蓋的安全關鍵型系統非常有用。在未測試代碼之處，可能會潛藏錯誤并在以后導致問題。

圖 2：在調試模式下運行并對軟件執行分支分析的用于 ARM 的 Keil MDK-PRO。左側的綠色塊表示在測試期間得到執行的代碼行。（圖片來源：Keil）

如果開發人員不想購買成熟的跟蹤工具，則可以使用 SWD 進行跟蹤。在這種情況下，開發人員可以選擇使用如 Segger 的 SystemView 或 Percepio 的 Tracelyzer 之類軟件工具將跟蹤信息流傳輸到在 PC 上執行的應用程序。這些跟蹤系統通常在 RTOS 中工作，并且需要幾行代碼來設置跟蹤任務、捕獲數據并將其發送到調試器，然后再發送到 PC 上。

顯示軟件跟蹤的輸出示例（圖 3）。開發人員可以使用這些工具來檢測諸如優先級轉換、死鎖、線程饑餓以及許多在復雜系統中可能遇到的其他問題。每個任務都有一條生命線，顯示其何時就緒、何時執行、何時完成，以及在此期間可能發生的任何事件，例如發出和接收信號。

專業開發人員需要這樣的細節，同樣地，也要求他們使用的調試工具能夠檢索這類信息。

圖 3：使用如 Percepio 的 Tracealyzer 之類工具檢查軟件操作，并查看執行時間和時間長短。（圖片來源：Digi-Key）

最大限度利用調試器的技巧與竅門

調試工具有很多功能，但有時可能受限于為應用選擇的微控制器。開發人員需要了解其調試器的功能，并要將其與微控制器正確配對。現今的許多調試器都可與 ARM? Cortex?-M 微控制器配合使用，開發人員在調試這些系統時應考慮以下幾個因素：

避免通過 UART 進行 printf。而應使用 ITM 端口來獲得更好的性能

不要逐條查看代碼，使用高級斷點來提高調試效率

選擇一個通過服務器控制的調試器，以便為多個應用提供調試數據，即自定義分析儀、跟蹤、調試環境等等。

調整調試器使用的默認時鐘速率，因該速率通常比最大值慢得多

在開發周期的早期階段設置跟蹤，以建立比較基準

使 SWO 能夠從系統獲取更多信息

在硬件、軟件和閃存斷點之間進行選擇性選擇，以最小化實時性能影響

使用這些技巧可以幫助開發人員從調試器及其調試會話中獲取更多信息。

使用商業編譯器降低成本

GCC 是一款極受歡迎且大獲成功的編譯器。它與商業工具相比有一個優點就是免費！免費并不意味著編譯器的質量和輸出將產生與商業工具同等的可執行代碼。事實上，在許多情況下，將 GCC 與商業編譯器（如用于 ARM 的 Keil MDK-PRO 或 IAR Embedded Workbench）進行比較，得出的結果是，GCC 使用的代碼規模更大，占用的 RAM 空間更多。Renesas 甚至在他們的 Synergy 平臺規格書中顯示了這一點（圖 4）。

在圖中，Renesas 使用 EEMBC CoreMark? 對其編譯器進行了基準測試，顯示了 IAR 編譯的代碼比 GCC 編譯的代碼更快。

CPU工具鏈時鐘迭代時間（秒）CoremarkDK-S7G2GCC240 MHz1000021.93456GCC200 MHz1000026.32380GCC160 MHz1000029.39340GCC80 MHz600034.59173IAR240 MHz1000014.79676IAR200 MHz1000017.75563IAR160 MHz1000019.18521IAR80 MHz600022.61265DK-S3A7GCC48 MHz1000096.34104GCC24 MHz10000187.3153IAR48 MHz1000063.66157IAR24 MHz10000124.1881DK-S124GCC32 MHz10000199.1750IAR32 MHz10000125.9979

圖 4：Renesas Synergy 平臺 CoreMark? 結果。Coremark 值越大，性能越好。（來源：Renesas SSP 1.0.0 規格書）

基準測試還顯示，使用商業級編譯器可以顯著減少代碼規模。乍一看，開發人員可能會認為購買諸如用于 ARM 的 Keil MDK-PRO 之類工具不值得投資，而應該使用 GCC。但是，當開發人員使用包含 128 KB 代碼空間的微控制器（如 NXP MK20DX128）并發現使用 GCC 應用程序需要 132 KB 時，會發生什么？

若發生這種情況，開發團隊就被迫要尋找一個具有足夠內存但卻更為昂貴的引腳兼容器件，如 NXP MKD20DX256。如果該公司只能生產適量的產品，那么每年花在 MCU 上的成本可能會超過最初投資于商業編譯器上的成本。

使用商業編譯器也有其他優勢，有助于降低成本，例如：

代碼分析功能，如分支檢測

軟件復雜性測量

高效生成代碼

卓越的調試工具和功能

技術支持

集成到驅動程序庫和框架

結論

開發人員當然可以使用免費或便宜的開發工具。然而問題在于，這些低成本工具在大多數情況下并非是適合這種工作的最佳工具。它們往往缺乏每個開發人員所需的高級功能，不能節省時間和金錢，而且常常會導致項目延遲并增加成本。

購買好的專業調試器和工具鏈是一項投資，可以在未來幾年節省大量時間和金錢，并大幅提高開發團隊的工作效率和績效。