在 20 世紀 90 年代，在實際硬件上調試嵌入式軟件主要有兩種基于工具的解決方案：一種是監(jiān)控調試器，它是在嵌入式系統(tǒng)內存中編程的軟件，可響應來自外部的調試器軟件的請求。另一種是在線仿真器，它是一塊(大型)硬件，可通過適配替換和仿真位于目標硬件中的微控制器/處理器。

監(jiān)控調試器解決方案價格低廉，可實現基本調試功能;在線仿真器解決方案價格昂貴，使用復雜，而且適配通常不穩(wěn)定且容易出錯。作為回報，開發(fā)人員獲得了完全透明度并可以訪問微控制器/處理器的所有總線。當時已經可以進行時序測量和代碼覆蓋率分析。然而，半導體制造商必須為此開發(fā)一種特殊的、帶有額外引腳的所謂仿真芯片。對于所有參與者來說，這都是一個關鍵的成本因素。

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

硬件調試的演進，以及對調試“圣杯”的追求

從 printf 到“僅僅”閃現到斷點、實時監(jiān)視和步進，這就是您可以簡要描述調試的方式。原則上，調試用于驅動程序開發(fā)、電路板/硬件啟動、啟動過程等的開發(fā)和故障排除，是“低級”硬件相關開發(fā)的標準方法。可以快速將調試器放在桌面上，將軟件閃現到目標硬件上，通過斷點開始執(zhí)行或在代碼中的某個點停止執(zhí)行，檢查內存區(qū)域和寄存器或操縱它們進行測試，讀出調用堆棧等。

在應用方面，它簡單易懂，原則上是大多數開發(fā)人員通過調試理解的。大多數時候，人們沒有時間深入研究調試器本身，以發(fā)現“調試的圣杯”，這些附加功能最終可以節(jié)省大量調試和測試時間。例如，在這種情況下，跟蹤是一種被低估的技術。它可以洞察軟件的執(zhí)行情況，而不會影響運行時行為。因此，開發(fā)人員可以獲得軟件在硬件上執(zhí)行的真實圖像?？梢园l(fā)現軟件中偶爾發(fā)生的錯誤和瓶頸。這只是調試器眾多替代用例中的一個例子。

微控制器、處理器和 SoC 帶來了新的挑戰(zhàn)

調試的發(fā)展伴隨著半導體的小型化、復雜性和速度的提高。在過去的 15 年里，嵌入式行業(yè)，尤其是汽車行業(yè)，在其產品中引入了許多附加功能，以滿足當前和未來的環(huán)境法規(guī)，減少總體車禍數量，通過將功能分布在多個電子控制單元 (ECU) 上而不是按功能開發(fā)專用 ECU 來更有效地開發(fā)和生產車輛，并使自己在競爭中脫穎而出。

為了實現所有這些，汽車行業(yè)需要半導體制造商通過開發(fā)和生產更緊湊、更快的微控制器來滿足其要求。

這就是嵌入式多核微控制器(具有兩個或更多個內核的控制器)的誕生。ECU 從單核架構向多核架構的轉變給每個人都帶來了新的挑戰(zhàn)。嵌入式軟件工具供應商面臨著新的問題，從如何輕松訪問多核 ECU 的所有內核到如何將嵌入式和舊版軟件分布在不同內核上，以最高效的方式運行，同時保持高性能。此時，開發(fā)嵌入式軟件的傳統(tǒng)方式已經受到質疑。

隨著高性能/計算平臺和多核系統(tǒng)的推出，現在更復雜的處理器架構被用于開發(fā)高度復雜的應用程序。調試在這里仍然發(fā)揮什么作用?

原則上，它仍然基于基礎知識。除了微控制器的內部閃存組件外，還必須操作 SoC 外部閃存組件。調試器首先幫助控制啟動過程，然后在下一步中仔細檢查這些處理器的各個部分和核心以及在這些設備上運行的軟件。除了標準調試功能外，由于這些軟件系統(tǒng)的復雜性不斷增加，諸如時序分析、功能分析或 CPU 負載測量等分析選項的使用也越來越多。前提條件是所使用的半導體上有跟蹤接口，并且相應的調試器(其軟件可實現此類功能)可用。

半導體行業(yè)的技術發(fā)展正在改變軟件開發(fā)流程，進而改變調試器作為流程工具的基礎工具。

軟件開發(fā)流程和標準

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

因此，傳統(tǒng)意義上的開發(fā)工具必須比以往更加通用。調試器以前僅由微控制器專家用作與硬件相關的開發(fā)工具，現在越來越多地出現在各種軟件開發(fā)環(huán)境中。調試器仍然是通過標準調試接口與實際目標硬件的連接，目的是盡可能接近實際硬件開發(fā)和測試嵌入式軟件。

除了簡單地與目標硬件接口之外，調試器還提供更高級的調試功能，包括測試功能。在這里，開發(fā)人員可以跟蹤正在運行的軟件的執(zhí)行情況。為此，可以檢查程序狀態(tài)，并在某些條件下停止程序的執(zhí)行。這樣做對被測試的軟件的影響很小甚至沒有影響。專業(yè)的調試解決方案還可以實時記錄軟件中的進程(跟蹤)、記錄時鐘周期范圍內的執(zhí)行時間以及評估與測試相關的軟件處理部分(代碼覆蓋率)。

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

此外，當今的調試器提供所謂的“迷你 HIL”功能(用于測試的硬件在環(huán)、測量和刺激模塊)，用于生成或測量數字和模擬信號，同時記錄和關聯程序執(zhí)行。這使得在軟件開發(fā)過程中盡早進行非常接近現實的測試成為可能。所有這些都是在已知環(huán)境中實現的，幾乎是即時的，無需學習新方法。

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

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

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

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

ISO26262 和 DO-178C 等安全標準對工具的功能范圍以及向客戶提供這些功能正確性的證明有影響。特別是在航空業(yè)，工具制造商長期以來一直需要在工具認證方面進行合作 - 但最近在汽車行業(yè)也開始采用 ISO26262。

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

結論：調試器更加復雜，新的商業(yè)模式正在不斷發(fā)展

調試器正越來越多地成為一種流程工具。調試器的基本功能已得到普遍應用，并輔以強大的分析功能。軟件的復雜性不斷增加，軟件開發(fā)本身所使用的軟件和硬件工具數量龐大，以及它們的相互依賴性推動了工具制造商、芯片供應商和客戶之間對知識轉移和咨詢服務的需求。

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