There are a lot of potential changes that software development teams can make to decrease the time they spend debugging and get it into single-digit percentages.
工程師喜歡解決問題。這就是我們所做的。不幸的是,嵌入式軟件工程師最大的問題之一是我們制造了很多問題,然后通過花費(fèi)大量時(shí)間來修復(fù)它們(調(diào)試?。┦棺约撼蔀橛⑿?。嵌入式軟件工程師花費(fèi) 20% 到 40% 的時(shí)間進(jìn)行調(diào)試的公司很常見!值得慶幸的是,團(tuán)隊(duì)可以做出很多潛在的改變來減少他們花費(fèi)在調(diào)試上的時(shí)間,并將其降低到個(gè)位數(shù)的百分比。在本文中,我們將研究幾個(gè)減少調(diào)試時(shí)間的技巧。
提示 #1 – 擁抱測(cè)試驅(qū)動(dòng)開發(fā) (TDD)
測(cè)試驅(qū)動(dòng)開發(fā)是一種允許開發(fā)人員增量構(gòu)建他們的生產(chǎn)軟件的技術(shù),他們依靠測(cè)試來指示他們編寫的代碼。例如,TDD 讓開發(fā)人員首先編寫一個(gè)測(cè)試用例,使其失敗,然后只編寫允許該測(cè)試用例通過的代碼。然后重復(fù)該過程。
傳統(tǒng)上,嵌入式軟件開發(fā)人員會(huì)在測(cè)試之前編寫整個(gè)代碼模塊。在幾周內(nèi)編寫數(shù)千行代碼是可能的。那么,到了測(cè)試它的時(shí)候,如果它不起作用,問題在哪里呢?只有天知道!開發(fā)人員必須煞費(fèi)苦心地回顧代碼并發(fā)現(xiàn)問題所在并修復(fù)它。執(zhí)行此操作所需的時(shí)間可能相當(dāng)可觀。
另一方面,對(duì)于使用 TDD 的開發(fā)者來說,如果出現(xiàn)錯(cuò)誤并在代碼中注入了 bug,測(cè)試用例會(huì)立即告訴開發(fā)者!由于他們正在逐步編寫代碼,因此他們更有可能確切地知道他們所做的更改并可以立即解決問題。TDD 似乎需要更多時(shí)間來練習(xí),但它創(chuàng)建了一組可以在回歸測(cè)試中運(yùn)行的測(cè)試用例,以確保一切都按預(yù)期工作。TDD 一石二鳥:減少調(diào)試時(shí)間和自動(dòng)化測(cè)試。
提示 #2 – 盡可能多地開發(fā)脫靶
當(dāng)一個(gè)項(xiàng)目開始時(shí),幾乎每個(gè)嵌入式軟件開發(fā)人員的第一反應(yīng)就是獲得一塊開發(fā)板并開始編寫嵌入式代碼。不幸的是,在許多情況下,嵌入式代碼并不是我們產(chǎn)品的差異化因素。這是應(yīng)用程序代碼。雖然許多應(yīng)用程序代碼最終需要與硬件交互,但許多模塊可以脫靶開發(fā),即在主機(jī)上。
開發(fā)脫靶代碼為開發(fā)人員提供了許多減少每個(gè)調(diào)試周期所花費(fèi)時(shí)間的機(jī)會(huì)。例如,通常,要為目標(biāo)微控制器編寫和測(cè)試代碼,開發(fā)人員必須:
交叉編譯代碼
啟動(dòng)調(diào)試會(huì)話
通過 SWD 對(duì)設(shè)備進(jìn)行編程
在目標(biāo)上運(yùn)行代碼
通過在目標(biāo)上運(yùn)行代碼來驗(yàn)證代碼是否正常工作(還必須具有所有低級(jí)代碼)。
如果代碼是在主機(jī)上開發(fā)的,開發(fā)人員必須為主機(jī)編譯它,然后使用單元測(cè)試工具、仿真器或自定義程序來運(yùn)行正在開發(fā)的代碼。如果發(fā)現(xiàn)問題,修復(fù)、重新編譯并重新開始會(huì)更快。在嵌入式目標(biāo)上,僅對(duì)目標(biāo)進(jìn)行編程就會(huì)使每個(gè)周期增加幾十秒,更不用說單步執(zhí)行代碼的誘惑了。
脫靶開發(fā)/調(diào)試可能會(huì)產(chǎn)生特定的錯(cuò)誤。但是,我現(xiàn)在編寫了大約 75% 的代碼偏離目標(biāo),并且發(fā)現(xiàn)我的速度更快、效率更高。我可以快速?gòu)?qiáng)制代碼中的問題,確定原因,修復(fù)它,然后繼續(xù)前進(jìn),而不是通過嵌入式目標(biāo)跟蹤問題。當(dāng)然,有些事情會(huì)出現(xiàn)在目標(biāo)上,而不會(huì)出現(xiàn)在主機(jī)上。
提示 #3 – 掌握調(diào)試策略
人類已知的效率最低的調(diào)試方法是單步調(diào)試代碼行。不要誤會(huì)我的意思,有時(shí)間和地點(diǎn),但往往會(huì)浪費(fèi)很多時(shí)間。不幸的是,嵌入式軟件開發(fā)人員默認(rèn)使用斷點(diǎn)和單步調(diào)試。為了更好地調(diào)試,開發(fā)人員需要掌握現(xiàn)代微控制器上可用的其他調(diào)試策略。
今天,至少有八種不同的調(diào)試技術(shù)可供開發(fā)人員使用。這些技術(shù)從最簡(jiǎn)單到最復(fù)雜的順序包括:
Watch / Expressions:為開發(fā)人員提供檢查 CPU 和外設(shè)寄存器的能力。它們通常可用于監(jiān)視變量、執(zhí)行計(jì)算或在更改時(shí)停止 CPU。
斷點(diǎn):為開發(fā)人員提供在特定代碼行上停止 CPU 執(zhí)行的能力。高級(jí)斷點(diǎn)可用于設(shè)置條件語句。
printf:為開發(fā)人員提供將字符數(shù)據(jù)打印到映射的串行接口的能力。根據(jù)實(shí)現(xiàn),這可能會(huì)或可能不會(huì)影響實(shí)時(shí)性能。
斷言:這些是用于驗(yàn)證程序中特定點(diǎn)的假設(shè)的條件語句。斷言失敗通常會(huì)停止 CPU 并提供失敗斷言的文件和行位置。
Statistical Profiling:對(duì)應(yīng)用程序中的各種寄存器進(jìn)行定期采樣,這些寄存器同時(shí)發(fā)生在其運(yùn)行中。通常不會(huì)影響實(shí)時(shí)性能。例如,可能想要對(duì)程序計(jì)數(shù)器 (PC) 進(jìn)行采樣以了解正在執(zhí)行的代碼模塊。
數(shù)據(jù)分析:對(duì)包含可變數(shù)據(jù)的各種內(nèi)存位置進(jìn)行定期采樣。當(dāng)與實(shí)時(shí)可視化工具一起使用來監(jiān)控系統(tǒng)狀態(tài)、感興趣的變量變化等時(shí),數(shù)據(jù)分析會(huì)非常有用。
任務(wù)和數(shù)據(jù)跟蹤:使開發(fā)人員能夠跟蹤實(shí)時(shí)操作系統(tǒng)應(yīng)用程序中的事件。因此,開發(fā)人員可以深入了解應(yīng)用程序性能、任務(wù)延遲、運(yùn)行時(shí)間等等。
指令跟蹤:使開發(fā)人員能夠記錄在處理器上執(zhí)行的每條指令。這可用于了解測(cè)試期間的代碼覆蓋率、調(diào)試編譯器問題等。
掌握所有這些技術(shù)并知道何時(shí)使用它們可以大大減少當(dāng)缺陷確實(shí)進(jìn)入系統(tǒng)時(shí)用于調(diào)試的時(shí)間。
結(jié)論
可能會(huì)花費(fèi)大量時(shí)間調(diào)試嵌入式軟件。有時(shí),調(diào)試時(shí)間是無法避免的;但是,在許多情況下,開發(fā)人員可能會(huì)花費(fèi)比他們需要的時(shí)間更多的時(shí)間。我們已經(jīng)探索了幾個(gè)您可以進(jìn)一步調(diào)查的領(lǐng)域,以減少您和您的團(tuán)隊(duì)花費(fèi)在調(diào)試上的時(shí)間。如果您花費(fèi)超過 20% 的時(shí)間進(jìn)行調(diào)試,請(qǐng)?jiān)诒局芑ㄒ粋€(gè)小時(shí)確定您可以立即開始進(jìn)行哪些更改,以控制您花在調(diào)試上的時(shí)間。
審核編輯 黃昊宇
-
嵌入式
+關(guān)注
關(guān)注
5046文章
18821瀏覽量
298631 -
調(diào)試
+關(guān)注
關(guān)注
7文章
551瀏覽量
33764
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論