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

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

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

硬件調(diào)試的演進(jìn)，以及對調(diào)試“圣杯”的追求

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

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

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

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

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

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

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

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

半導(dǎo)體行業(yè)的技術(shù)發(fā)展正在改變軟件開發(fā)流程，進(jìn)而改變調(diào)試器作為流程工具的基礎(chǔ)工具。

軟件開發(fā)流程和標(biāo)準(zhǔn)

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

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

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

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

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

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

因此，經(jīng)典的調(diào)試器就成為了在真實硬件上進(jìn)行測試的測試工具。

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

因此，在早期階段盡可能接近真實硬件進(jìn)行測試是有意義的，以確保最終產(chǎn)品的正確功能以及應(yīng)用程序的準(zhǔn)確時序行為。

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

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

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

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

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