硬件調(diào)試故事:從 printf 到 Flash監(jiān)視及其他方案
在 20 世紀(jì) 90 年代,在實(shí)際硬件上調(diào)試嵌入式軟件主要有兩種基于工具的解決方案:一種是監(jiān)控調(diào)試器,它是在嵌入式系統(tǒng)內(nèi)存中編程的軟件,可響應(yīng)來(lái)自外部的調(diào)試器軟件的請(qǐng)求。另一種是在線(xiàn)仿真器,它是一塊(大型)硬件,可通過(guò)適配替換和仿真位于目標(biāo)硬件中的微控制器/處理器。
監(jiān)控調(diào)試器解決方案價(jià)格低廉,可實(shí)現(xiàn)基本調(diào)試功能;在線(xiàn)仿真器解決方案價(jià)格昂貴,使用復(fù)雜,而且適配通常不穩(wěn)定且容易出錯(cuò)。作為回報(bào),開(kāi)發(fā)人員獲得了完全透明度并可以訪問(wèn)微控制器/處理器的所有總線(xiàn)。當(dāng)時(shí)已經(jīng)可以進(jìn)行時(shí)序測(cè)量和代碼覆蓋率分析。然而,半導(dǎo)體制造商必須為此開(kāi)發(fā)一種特殊的、帶有額外引腳的所謂仿真芯片。對(duì)于所有參與者來(lái)說(shuō),這都是一個(gè)關(guān)鍵的成本因素。
半導(dǎo)體的不斷小型化和片上調(diào)試接口的引入對(duì)調(diào)試器作為開(kāi)發(fā)工具本身的架構(gòu)產(chǎn)生了巨大影響。以前在硬件中實(shí)現(xiàn)的功能越來(lái)越多地在軟件中實(shí)現(xiàn)。開(kāi)發(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),這就是您可以簡(jiǎn)要描述調(diào)試的方式。原則上,調(diào)試用于驅(qū)動(dòng)程序開(kāi)發(fā)、電路板/硬件啟動(dòng)、啟動(dòng)過(guò)程等的開(kāi)發(fā)和故障排除,是“低級(jí)”硬件相關(guān)開(kāi)發(fā)的標(biāo)準(zhǔn)方法。可以快速將調(diào)試器放在桌面上,將軟件閃現(xiàn)到目標(biāo)硬件上,通過(guò)斷點(diǎn)開(kāi)始執(zhí)行或在代碼中的某個(gè)點(diǎn)停止執(zhí)行,檢查內(nèi)存區(qū)域和寄存器或操縱它們進(jìn)行測(cè)試,讀出調(diào)用堆棧等。
在應(yīng)用方面,它簡(jiǎn)單易懂,原則上是大多數(shù)開(kāi)發(fā)人員通過(guò)調(diào)試?yán)斫獾?。大多?shù)時(shí)候,人們沒(méi)有時(shí)間深入研究調(diào)試器本身,以發(fā)現(xiàn)“調(diào)試的圣杯”,這些附加功能最終可以節(jié)省大量調(diào)試和測(cè)試時(shí)間。例如,在這種情況下,跟蹤是一種被低估的技術(shù)。它可以洞察軟件的執(zhí)行情況,而不會(huì)影響運(yùn)行時(shí)行為。因此,開(kāi)發(fā)人員可以獲得軟件在硬件上執(zhí)行的真實(shí)圖像??梢园l(fā)現(xiàn)軟件中偶爾發(fā)生的錯(cuò)誤和瓶頸。這只是調(diào)試器眾多替代用例中的一個(gè)例子。
微控制器、處理器和 SoC 帶來(lái)了新的挑戰(zhàn)
調(diào)試的發(fā)展伴隨著半導(dǎo)體的小型化、復(fù)雜性和速度的提高。在過(guò)去的 15 年里,嵌入式行業(yè),尤其是汽車(chē)行業(yè),在其產(chǎn)品中引入了許多附加功能,以滿(mǎn)足當(dāng)前和未來(lái)的環(huán)境法規(guī),減少總體車(chē)禍數(shù)量,通過(guò)將功能分布在多個(gè)電子控制單元 (ECU) 上而不是按功能開(kāi)發(fā)專(zhuān)用 ECU 來(lái)更有效地開(kāi)發(fā)和生產(chǎn)車(chē)輛,并使自己在競(jìng)爭(zhēng)中脫穎而出。
為了實(shí)現(xiàn)所有這些,汽車(chē)行業(yè)需要半導(dǎo)體制造商通過(guò)開(kāi)發(fā)和生產(chǎn)更緊湊、更快的微控制器來(lái)滿(mǎn)足其要求。
這就是嵌入式多核微控制器(具有兩個(gè)或更多個(gè)內(nèi)核的控制器)的誕生。ECU 從單核架構(gòu)向多核架構(gòu)的轉(zhuǎn)變給每個(gè)人都帶來(lái)了新的挑戰(zhàn)。嵌入式軟件工具供應(yīng)商面臨著新的問(wèn)題,從如何輕松訪問(wèn)多核 ECU 的所有內(nèi)核到如何將嵌入式和舊版軟件分布在不同內(nèi)核上,以最高效的方式運(yùn)行,同時(shí)保持高性能。此時(shí),開(kāi)發(fā)嵌入式軟件的傳統(tǒng)方式已經(jīng)受到質(zhì)疑。
隨著高性能/計(jì)算平臺(tái)和多核系統(tǒng)的推出,現(xiàn)在更復(fù)雜的處理器架構(gòu)被用于開(kāi)發(fā)高度復(fù)雜的應(yīng)用程序。調(diào)試在這里仍然發(fā)揮什么作用?
原則上,它仍然基于基礎(chǔ)知識(shí)。除了微控制器的內(nèi)部閃存組件外,還必須操作 SoC 外部閃存組件。調(diào)試器首先幫助控制啟動(dòng)過(guò)程,然后在下一步中仔細(xì)檢查這些處理器的各個(gè)部分和核心以及在這些設(shè)備上運(yùn)行的軟件。除了標(biāo)準(zhǔn)調(diào)試功能外,由于這些軟件系統(tǒng)的復(fù)雜性不斷增加,諸如時(shí)序分析、功能分析或 CPU 負(fù)載測(cè)量等分析選項(xiàng)的使用也越來(lái)越多。前提條件是所使用的半導(dǎo)體上有跟蹤接口,并且相應(yīng)的調(diào)試器(其軟件可實(shí)現(xiàn)此類(lèi)功能)可用。
半導(dǎo)體行業(yè)的技術(shù)發(fā)展正在改變軟件開(kāi)發(fā)流程,進(jìn)而改變調(diào)試器作為流程工具的基礎(chǔ)工具。
軟件開(kāi)發(fā)流程和標(biāo)準(zhǔn)
分布式開(kāi)發(fā)團(tuán)隊(duì)、日益復(fù)雜的代碼庫(kù)、不斷增長(zhǎng)的功能需求、標(biāo)準(zhǔn)化和時(shí)間壓力:即使在嵌入式軟件開(kāi)發(fā)中,也只有通過(guò)更高程度的抽象和自動(dòng)化才能應(yīng)對(duì)在最短時(shí)間內(nèi)將可靠、安全的產(chǎn)品推向市場(chǎng)的挑戰(zhàn)。
因此,傳統(tǒng)意義上的開(kāi)發(fā)工具必須比以往更加通用。調(diào)試器以前僅由微控制器專(zhuān)家用作與硬件相關(guān)的開(kāi)發(fā)工具,現(xiàn)在越來(lái)越多地出現(xiàn)在各種軟件開(kāi)發(fā)環(huán)境中。調(diào)試器仍然是通過(guò)標(biāo)準(zhǔn)調(diào)試接口與實(shí)際目標(biāo)硬件的連接,目的是盡可能接近實(shí)際硬件開(kāi)發(fā)和測(cè)試嵌入式軟件。
除了簡(jiǎn)單地與目標(biāo)硬件接口之外,調(diào)試器還提供更高級(jí)的調(diào)試功能,包括測(cè)試功能。在這里,開(kāi)發(fā)人員可以跟蹤正在運(yùn)行的軟件的執(zhí)行情況。為此,可以檢查程序狀態(tài),并在某些條件下停止程序的執(zhí)行。這樣做對(duì)被測(cè)試的軟件的影響很小甚至沒(méi)有影響。專(zhuān)業(yè)的調(diào)試解決方案還可以實(shí)時(shí)記錄軟件中的進(jìn)程(跟蹤)、記錄時(shí)鐘周期范圍內(nèi)的執(zhí)行時(shí)間以及評(píng)估與測(cè)試相關(guān)的軟件處理部分(代碼覆蓋率)。
為了讓客戶(hù)能夠靈活地使用所有這些功能,調(diào)試器制造商提供了通用接口(API),使這些工具能夠集成到客戶(hù)的開(kāi)發(fā)和測(cè)試過(guò)程中。這些接口必須適合解決各種各樣的任務(wù)(開(kāi)發(fā)、測(cè)試、驗(yàn)證和確認(rèn)軟件和硬件)。這里的標(biāo)準(zhǔn)是支持編程(C、C++、C#、Java 等)和腳本語(yǔ)言(Python 等),以便從另一個(gè)(也是客戶(hù)特定的)應(yīng)用程序“遠(yuǎn)程控制”開(kāi)發(fā)工具?;旧希糠至鞒炭梢栽陂_(kāi)發(fā)和測(cè)試期間實(shí)現(xiàn)自動(dòng)化。
此外,當(dāng)今的調(diào)試器提供所謂的“迷你 HIL”功能(用于測(cè)試的硬件在環(huán)、測(cè)量和刺激模塊),用于生成或測(cè)量數(shù)字和模擬信號(hào),同時(shí)記錄和關(guān)聯(lián)程序執(zhí)行。這使得在軟件開(kāi)發(fā)過(guò)程中盡早進(jìn)行非常接近現(xiàn)實(shí)的測(cè)試成為可能。所有這些都是在已知環(huán)境中實(shí)現(xiàn)的,幾乎是即時(shí)的,無(wú)需學(xué)習(xí)新方法。
這些靈活的測(cè)試自動(dòng)化接口的一個(gè)典型用例是持續(xù)集成 (CI)。CI 通過(guò)將開(kāi)發(fā)人員的更改或新創(chuàng)建的代碼集成到與團(tuán)隊(duì)共享的存儲(chǔ)庫(kù)中,以短間隔支持敏捷/分布式軟件開(kāi)發(fā)和測(cè)試。有幾種適合此目的的持續(xù)集成服務(wù)器,例如 Jenkins、GitLab、TeamCity、CircleCI 或 GitHub Actions。通過(guò)集成,可以通過(guò)內(nèi)部或云端托管的 CI 軟件觸發(fā)一系列快速且高度自動(dòng)化的步驟(稱(chēng)為“管道”)。管道通常包括并結(jié)合構(gòu)建、靜態(tài)分析、單元和系統(tǒng)測(cè)試。
因此,經(jīng)典的調(diào)試器就成為了在真實(shí)硬件上進(jìn)行測(cè)試的測(cè)試工具。
通常,軟件也可以在 PC 平臺(tái)上進(jìn)行大量測(cè)試,與目標(biāo)硬件無(wú)關(guān)。然而,并非所有潛在錯(cuò)誤都能在模擬環(huán)境中檢測(cè)到:例如,所需的硬件外圍設(shè)備通常不可用,或者應(yīng)用程序的行為與真實(shí)硬件不同,時(shí)序行為不同,或者交叉編譯器生成特定于目標(biāo)的目標(biāo)代碼,因此與用于測(cè)試環(huán)境的編譯器的代碼不同。
因此,在早期階段盡可能接近真實(shí)硬件進(jìn)行測(cè)試是有意義的,以確保最終產(chǎn)品的正確功能以及應(yīng)用程序的準(zhǔn)確時(shí)序行為。
ISO26262 和 DO-178C 等安全標(biāo)準(zhǔn)對(duì)工具的功能范圍以及向客戶(hù)提供這些功能正確性的證明有影響。特別是在航空業(yè),工具制造商長(zhǎng)期以來(lái)一直需要在工具認(rèn)證方面進(jìn)行合作 - 但最近在汽車(chē)行業(yè)也開(kāi)始采用 ISO26262。
為此,工具制造商必須針對(duì)特定用例創(chuàng)建用于驗(yàn)證所用工具功能正確性的驗(yàn)證選項(xiàng)。這些可以是組織措施,例如對(duì)開(kāi)發(fā)過(guò)程進(jìn)行外部審計(jì)或由獨(dú)立第三方對(duì)工具進(jìn)行認(rèn)證,或支持客戶(hù)進(jìn)行正確性驗(yàn)證的參考工具套件。上述使用調(diào)試器自動(dòng)化測(cè)試過(guò)程的方法非常適合實(shí)施此類(lèi)工具鑒定過(guò)程。
結(jié)論:調(diào)試器更加復(fù)雜,新的商業(yè)模式正在不斷發(fā)展
調(diào)試器正越來(lái)越多地成為一種流程工具。調(diào)試器的基本功能已得到普遍應(yīng)用,并輔以強(qiáng)大的分析功能。軟件的復(fù)雜性不斷增加,軟件開(kāi)發(fā)本身所使用的軟件和硬件工具數(shù)量龐大,以及它們的相互依賴(lài)性推動(dòng)了工具制造商、芯片供應(yīng)商和客戶(hù)之間對(duì)知識(shí)轉(zhuǎn)移和咨詢(xún)服務(wù)的需求。
參與這些開(kāi)發(fā)的各方之間持續(xù)而開(kāi)放的溝通是成功的關(guān)鍵。如今,客戶(hù)不再想購(gòu)買(mǎi)工具,他們希望隨時(shí)隨地使用它們。嵌入式軟件開(kāi)發(fā)和軟件測(cè)試的新商業(yè)模式將發(fā)揮作用,其中工具、知識(shí)轉(zhuǎn)移和咨詢(xún)是一種常見(jiàn)的產(chǎn)品,最終是一種服務(wù)。正如軟件行業(yè)所發(fā)生的那樣,訂閱業(yè)務(wù)模式也適用于全球嵌入式軟件開(kāi)發(fā)和測(cè)試。