硬件調(diào)試故事：從 printf 到 Flash監(jiān)視及其他方案

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

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

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

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

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

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

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

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

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

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

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

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

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

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

分布式開發(fā)團(tuán)隊(duì)、日益復(fù)雜的代碼庫、不斷增長的功能需求、標(biāo)準(zhǔn)化和時(shí)間壓力：即使在嵌入式軟件開發(fā)中，也只有通過更高程度的抽象和自動(dòng)化才能應(yīng)對(duì)在最短時(shí)間內(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)試接口與實(shí)際目標(biāo)硬件的連接，目的是盡可能接近實(shí)際硬件開發(fā)和測試嵌入式軟件。

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

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

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

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

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

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

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

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

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

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

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

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