在 1990 年代，基本上有兩種基于工具的解決方案，用于在真實硬件上調試嵌入式軟件：一種是監視器調試器，一種在嵌入式系統內存中編程并響應外部調試器軟件請求的軟件. 以及在線仿真器，一個（大型）硬件，它通過自適應替換和仿真位于目標硬件中的微控制器/處理器。

圖 1：1980 年代末的在線仿真。

監控調試器解決方案價格便宜，并實現了基本的調試功能；在線仿真器解決方案非常昂貴，使用復雜，而且適配經常不穩定且容易出錯。作為回報，開發人員獲得了對微控制器/處理器所有總線的完全透明和訪問權限。那時，計時測量和代碼覆蓋率分析已經成為可能。然而，半導體制造商必須為此目的開發一種特殊的、所謂的帶有額外引腳的仿真芯片。對所有相關人員來說都是一個關鍵的成本因素。

半導體的日益小型化和片上調試接口的引入對調試器作為開發工具本身的架構產生了重大影響。越來越多的以前在硬件中實現的功能現在在軟件中實現。開發環境和調試器軟件變得更強大，硬件更小，帶寬和速度方面的性能不斷提高。但是，今天調試的基本用例仍然相同。

硬件調試進化，瞄準調試的“圣杯”

從 printf 到“just” flash 到斷點、實時監視和單步執行，這就是您可以簡要描述調試的方式。原則上，調試用于驅動程序開發、板/硬件啟動、啟動過程等的開發和故障排除，作為“低級”、硬件相關開發的標準方法。一個調試器被迅速拿出來，將軟件閃存到目標硬件上，開始執行或通過斷點在代碼中的某個點停止它，檢查內存區域和寄存器或操作它們測試，讀出調用堆棧等等。

在應用方面，它簡單易懂，原則上大多數開發人員通過調試都可以理解。大多數時候，人們沒有時間深入處理調試器本身，從而可能發現“調試的圣杯”，這些附加功能最終可以節省大量調試和測試時間。例如，在這種情況下，一種被低估的技術是追蹤。它在不影響運行時行為的情況下提供對軟件執行的洞察。因此，開發人員獲得了硬件上軟件執行的真實圖像。可以發現軟件中偶爾出現的錯誤和瓶頸。這只是調試器的許多替代用例的一個示例。

圖 2：硬件調試——嵌入式軟件開發人員的日常業務。

微控制器、處理器和 SoC 帶來了新的挑戰

調試的發展伴隨著半導體的小型化、復雜性和速度的增加。在過去的 15 年中，嵌入式行業，尤其是汽車行業，在其產品中引入了許多附加功能，以滿足當前和未來的環境法規，減少一般的車禍數量，通過分銷更有效地開發和生產車輛跨多個電子控制單元 (ECU) 的功能，而不是按功能開發專用 ECU，并在競爭中脫穎而出。

為了實現這一切，汽車行業需要半導體制造商通過開發和生產更緊湊、更快的微控制器來滿足他們的要求。

這是嵌入式多核微控制器的誕生，即具有兩個或更多內核的控制器。ECU 中從單核架構向多核架構的轉變給每個人帶來了新的挑戰。嵌入式軟件工具供應商面臨著新問題，從如何輕松訪問多核 ECU 的所有內核，到如何在不同內核上分發嵌入式軟件和遺留軟件，這些內核運行效率最高，同時保持高性能。開發嵌入式軟件的傳統方式此時已經受到質疑。

隨著高性能/計算平臺和多核系統的引入，現在甚至更復雜的處理器架構被用于開發高度復雜的應用程序。調試在這里仍然扮演什么角色？

原則上，它仍然是基礎。除了微控制器的內部閃存組件外，還必須運行 SoC 外部閃存組件。調試器首先幫助控制引導過程，然后在下一步中仔細檢查這些處理器的各個部分和內核以及在這些設備上運行的軟件。除了標準調試功能之外，由于這些軟件系統的復雜性越來越高，時序分析、功能分析或 CPU 負載測量等分析選項也越來越多地被使用（圖 3）。這樣做的先決條件是所用半導體上的跟蹤接口的可用性以及相應的調試器，其軟件實現這些功能。

圖 3：來自 iSYSTEM 的 winIDEA Analyzer；左邊是記錄的對象，右邊是它們的時間相關性。 （點擊展開）

半導體行業的技術發展正在改變軟件開發過程，進而將調試器作為工藝工具的基本工具。

軟件開發過程和標準

分布式開發團隊、日益復雜的代碼庫、日益增長的功能需求、標準化和時間壓力：即使在嵌入式軟件開發中，在最短的時間內將可靠和安全的產品推向市場的挑戰也只能通過更高程度的抽象和自動化。

因此，經典意義上的開發工具必須比以往更加通用。以前由微控制器專家專門用作與硬件相關的開發工具，現在越來越多地可以在各種軟件開發情況中找到調試器。調試器仍然是通過標準調試接口連接到實際目標硬件，目的是開發和測試盡可能接近實際硬件的嵌入式軟件。

除了簡單地連接到目標硬件之外，調試器還提供更高級的調試功能，包括測試功能。在這里，開發人員可以跟蹤正在運行的軟件的執行情況。為此，可以檢查程序狀態，并在某些條件下停止程序的執行。這是在對被測軟件的影響最小或沒有影響的情況下完成的。專業的調試解決方案還可以實時記錄軟件中的過程（跟蹤）、記錄時鐘周期范圍內的執行時間以及評估與測試相關的軟件處理部分（代碼覆蓋率）。

圖 4：如今，調試器提供的 API 可通過平滑和自動化的工具轉換來實現開發和測試流程。

為了讓客戶能夠靈活地使用所有這些功能，調試器制造商提供了通用接口 (API)，可以將這些工具集成到客戶的開發和測試過程中（圖 4）。這些接口必須適合解決各種各樣的任務（開發、測試、驗證和驗證軟件和硬件）。這里的標準是支持編程（C、C++、C#、Java 等）和腳本語言（Python 等），以便從另一個（也是客戶特定的）應用程序“遠程控制”開發工具。基本上，該過程的一部分可以在開發和測試期間實現自動化。

此外，當今的調試器提供了所謂的“mini-HIL”功能（用于測試的硬件在環、測量和激勵模塊）來生成或測量數字和模擬信號，同時記錄和關聯程序執行. 這使得在軟件開發過程中盡可能早地進行非常接近現實的測試成為可能。所有這些都是從已知環境中實現的，幾乎是即時的，無需學習新的方法。

這些用于測試自動化的靈活接口的典型用例是持續集成 (CI)。CI 通過將開發人員的更改或新創建的代碼集成到與團隊共享的存儲庫中來支持敏捷/分布式軟件開發和測試。為此目的，有幾個合適的持續集成服務器，例如 Jenkins、GitLab、TeamCity、CircleCI 或 GitHub Actions。通過集成，通過內部或云中托管的 CI 軟件觸發一系列快速且高度自動化的步驟（稱為“管道”）。管道通常包括并結合構建、靜態分析、單元和系統測試。

圖 5：持續集成基礎設施的管道，包括構建、靜態分析、單元測試、系統測試，最后是可交付產品。

經典調試器因此成為在真實硬件上進行測試的測試工具。

通常，軟件也可以在 PC 平臺上進行廣泛的測試，與目標硬件無關。然而，并非所有潛在錯誤都在模擬環境中檢測到：例如，所需的硬件外圍通常不可用，或者應用程序的行為與真實硬件不同，時序行為不同，或者交叉編譯器生成目標- 特定的目標代碼，因此與用于測試環境的編譯器的代碼不同。

因此，有必要在早期盡可能接近真實硬件進行測試，以確保最終產品的正確功能以及應用程序的準確時序行為。

ISO26262 和 DO-178C 等安全標準會影響工具的功能范圍以及向客戶提供這些功能正確性的證明。特別是在航空領域，工具制造商被要求在工具認證方面進行合作已經有很長一段時間了——但最近在汽車行業也需要通過 ISO26262 進行合作。

為此，工具制造商必須為與特定用例相關的工具的功能正確性創建驗證選項。這些可以是組織措施，例如開發過程的外部審計或獨立第三方對工具的認證，或支持客戶執行正確性證明的參考工具套件。上述使用調試器自動化測試過程的方法非常適合實施此類工具鑒定過程。

結論：更復雜的調試器，不斷發展的新業務模型

調試器越來越多地變成了一個過程工具。調試器的基本功能找到了它們的普通應用，并輔以強大的分析功能。軟件日益復雜，軟件開發本身使用的大量軟硬件工具及其相互依賴性，推動了工具制造商、芯片供應商和客戶之間對知識轉移和咨詢服務的需求。

參與這些發展的各方之間持續和開放的溝通是成功的關鍵。今天，客戶不再想購買工具，他們想隨時隨地使用它們。嵌入式軟件開發和軟件測試的新商業模式將發揮作用，其中工具、知識轉移和咨詢是一種常見的產品，最終是一種服務。正如軟件行業所發生的那樣，訂閱業務模式也越來越適合全球嵌入式軟件開發和測試。

審核編輯 黃昊宇