工程師喜歡解決問(wèn)題。當(dāng)然，這就是我們的工作。但不如人愿的是，嵌入式軟件工程師最大的問(wèn)題之一是我們自己制造了很多問(wèn)題，然后花大量的時(shí)間來(lái)解決這些問(wèn)題，最后使自己成為英雄(在調(diào)試上!)。有很多公司的嵌入式軟件工程師把20 - 40%的時(shí)間花在調(diào)試上。值得慶幸的是，從團(tuán)隊(duì)的角度可以做出很多潛在的改變，以減少他們花在調(diào)試上的時(shí)間，并將時(shí)間百分比壓縮到個(gè)位數(shù)。在本文中，我們將研究一些減少調(diào)試時(shí)間的技巧。

技巧1-測(cè)試驅(qū)動(dòng)開(kāi)發(fā)(TDD)

測(cè)試驅(qū)動(dòng)開(kāi)發(fā)是一種允許開(kāi)發(fā)人員增量地構(gòu)建他們的產(chǎn)品軟件，并依賴測(cè)試來(lái)規(guī)定他們編寫(xiě)代碼的技術(shù)。例如，開(kāi)發(fā)人員首先編寫(xiě)一個(gè)測(cè)試用例，如果測(cè)試失敗，則編寫(xiě)以通過(guò)測(cè)試為目的新代碼。然后重復(fù)這個(gè)過(guò)程。

傳統(tǒng)上來(lái)講，嵌入式軟件開(kāi)發(fā)人員會(huì)在測(cè)試之前編寫(xiě)整個(gè)軟件代碼模塊。 可能會(huì)在幾周內(nèi)編寫(xiě)數(shù)千行代碼。 當(dāng)?shù)搅藴y(cè)試代碼的時(shí)候，如果發(fā)現(xiàn)它不起作用，問(wèn)題在哪里？ 只有天知道！ 開(kāi)發(fā)人員必須煞費(fèi)苦心地回顧代碼并發(fā)現(xiàn)問(wèn)題所在并修復(fù)它。 執(zhí)行此操作所需的時(shí)間可能相當(dāng)長(zhǎng)。

另一方面，對(duì)于使用TDD的開(kāi)發(fā)人員來(lái)說(shuō)，如果出現(xiàn)了錯(cuò)誤并且在代碼中注入了bug，測(cè)試用例將立即告訴開(kāi)發(fā)人員!由于是逐步編寫(xiě)代碼的流程，所以更有可能確切地知道更改了程序的什么部分，并且能夠立即修復(fù)問(wèn)題。TDD似乎需要更多的時(shí)間來(lái)驗(yàn)證，但通過(guò)創(chuàng)建一系列的測(cè)試用例，可以在回歸測(cè)試中運(yùn)行這些用例，以確保一切都按照預(yù)期工作。TDD功能實(shí)現(xiàn)了一石二鳥(niǎo)的目的:減少調(diào)試和自動(dòng)化測(cè)試的時(shí)間。

技巧2-盡可能無(wú)機(jī)器依賴的開(kāi)發(fā)

當(dāng)一個(gè)項(xiàng)目開(kāi)始時(shí)，幾乎每個(gè)嵌入式軟件開(kāi)發(fā)人員的第一反應(yīng)就是獲得一塊開(kāi)發(fā)板然后開(kāi)始編寫(xiě)代碼。 但不如人愿的是，在許多情況下嵌入式軟件代碼并不是和對(duì)手之間產(chǎn)品的差異化因素，差別在于應(yīng)用程序代碼。 雖然許多應(yīng)用程序代碼最終需要與硬件交互，但許多模塊可以不依賴于主機(jī)器環(huán)境來(lái)進(jìn)行開(kāi)發(fā)。

實(shí)施無(wú)機(jī)器依賴的代碼開(kāi)發(fā)，為開(kāi)發(fā)人員提供了許多減少每個(gè)調(diào)試周期所花費(fèi)時(shí)間的機(jī)會(huì)。 例如，通常要為目標(biāo)微控制器編寫(xiě)和測(cè)試代碼，開(kāi)發(fā)人員必須做以下工作：

1.交叉編譯代碼

2.啟動(dòng)調(diào)試會(huì)話

3.通過(guò) SWD 對(duì)設(shè)備進(jìn)行編程

4.在目標(biāo)機(jī)器上運(yùn)行代碼

5.通過(guò)在目標(biāo)機(jī)上運(yùn)行來(lái)驗(yàn)證代碼是否有效（同樣的必須擁有所有Low-Level代碼）

如果代碼是在主機(jī)上開(kāi)發(fā)的，開(kāi)發(fā)人員必須在主機(jī)上編譯代碼，然后使用單元測(cè)試工具、仿真器或自定義程序來(lái)運(yùn)行正在開(kāi)發(fā)的代碼。 如果發(fā)現(xiàn)問(wèn)題，會(huì)更加快速的修復(fù)、重新編譯并重新開(kāi)始測(cè)試。

在嵌入式板子上，僅對(duì)目標(biāo)程序進(jìn)行編程就會(huì)使每個(gè)周期增加幾十秒，更不用說(shuō)單步執(zhí)行代碼了。

無(wú)機(jī)器依賴的開(kāi)發(fā)/調(diào)試可能會(huì)產(chǎn)生特定的錯(cuò)誤。從我現(xiàn)在寫(xiě)了大約 75% 的相關(guān)代碼的例子上來(lái)看，發(fā)現(xiàn)會(huì)有速度更快、效率更高的效果。 我可以快速定位代碼中的問(wèn)題，確定原因并修復(fù)它，然后繼續(xù)調(diào)試，而不是只能在嵌入式板子上跟蹤問(wèn)題。 當(dāng)然，有些問(wèn)題會(huì)出現(xiàn)在主機(jī)上不會(huì)出現(xiàn)的板子環(huán)境上。

技巧3-掌握調(diào)試策略

我們已知效率最低的調(diào)試方法就是單步調(diào)試代碼。 但不要誤會(huì)我的意思，有具體的程序運(yùn)行時(shí)間和發(fā)生位置，往往更加會(huì)造成很多時(shí)間上的浪費(fèi)。 不幸的是，嵌入式軟件開(kāi)發(fā)人員通常默認(rèn)使用斷點(diǎn)和單步調(diào)試的方案。 為了更好地調(diào)試，開(kāi)發(fā)人員還需要掌握現(xiàn)代微控制器上可用的其他調(diào)試策略。

目前至少有八種不同的調(diào)試技術(shù)可供開(kāi)發(fā)人員使用。 這些技術(shù)從最簡(jiǎn)單到最復(fù)雜的順序排列如下：

Watch / Expressions:為開(kāi)發(fā)人員提供檢查 CPU 和外設(shè)寄存器的能力。它們通常可用于監(jiān)視變量、執(zhí)行計(jì)算或在更改時(shí)停止 CPU。

斷點(diǎn)：為開(kāi)發(fā)人員提供在特定代碼行上停止 CPU 執(zhí)行的能力，高級(jí)斷點(diǎn)功能可用于設(shè)置條件語(yǔ)句的情況。

打印：為開(kāi)發(fā)人員提供將字符數(shù)據(jù)打印到映射的串行接口的能力，有一定概率會(huì)影響實(shí)時(shí)性能。

斷言：用于驗(yàn)證程序中特定點(diǎn)假設(shè)的條件語(yǔ)句。斷言失敗通常會(huì)停止 CPU 并提供失敗斷言的文件和行位置。

統(tǒng)計(jì)分析：對(duì)在運(yùn)行中應(yīng)用程序中的各種寄存器進(jìn)行定期采樣。 通常不會(huì)影響實(shí)時(shí)性能。 例如，您可能想要對(duì)程序計(jì)數(shù)器 (PC) 進(jìn)行采樣以了解正在執(zhí)行的代碼模塊。

數(shù)據(jù)分析：對(duì)包含可變數(shù)據(jù)的各種內(nèi)存位置進(jìn)行定期采樣。當(dāng)與實(shí)時(shí)可視化工具一起使用來(lái)監(jiān)控系統(tǒng)狀態(tài)、感興趣的變量變化等時(shí)，數(shù)據(jù)分析會(huì)非常有用。

任務(wù)和數(shù)據(jù)跟蹤：使開(kāi)發(fā)人員能夠跟蹤實(shí)時(shí)操作系統(tǒng)應(yīng)用程序中的事件。因此，開(kāi)發(fā)人員可以深入了解應(yīng)用程序性能、任務(wù)延遲、運(yùn)行時(shí)間等等。

指令跟蹤：使開(kāi)發(fā)人員能夠記錄在處理器上執(zhí)行的每條指令。這可用于了解測(cè)試期間的代碼覆蓋率、調(diào)試編譯器問(wèn)題等。

掌握所有這些技術(shù)并知道何時(shí)使用它們，可以大大減少當(dāng)異常發(fā)生進(jìn)入系統(tǒng)時(shí)用于調(diào)試的時(shí)間。

結(jié)論

我們?cè)陂_(kāi)發(fā)階段可能會(huì)花費(fèi)大量時(shí)間調(diào)試嵌入式軟件代碼。 有時(shí)調(diào)試時(shí)間是不可避免的； 但在許多情況下，開(kāi)發(fā)人員可能會(huì)花費(fèi)超出預(yù)期更多的時(shí)間。 我們已經(jīng)探索了幾個(gè)您可以進(jìn)一步調(diào)查的領(lǐng)域，以減少您和您的團(tuán)隊(duì)花費(fèi)在調(diào)試上的時(shí)間。 如果您在調(diào)試上花費(fèi)超過(guò)整體軟件周期的20%時(shí)間，那么請(qǐng)?jiān)诒局芑ㄒ粋€(gè)小時(shí)時(shí)間確定您在以上哪些方面可以立即調(diào)整優(yōu)化，以控制花在調(diào)試上的時(shí)間。

審核編輯 ：李倩