近達(dá)內(nèi)科技的嵌入式講師經(jīng)常在和學(xué)員講課的時候會聽到我們的學(xué)員反饋自己在學(xué)習(xí)的時候會經(jīng)常出現(xiàn)很多的開發(fā)錯誤，下面達(dá)內(nèi)科技的講師就以我們的學(xué)員出現(xiàn)多的嵌入式軟件開發(fā)錯誤的觀念來給大家講解下。也給大家整理下這些錯誤的觀念都有哪些?
一、特別大if-then-else和case 的描述
在嵌入式系統(tǒng)的代碼中有很大的if-then-else或case的結(jié)構(gòu)是不正常的，這會引起三個方面的問題。
1、由于代碼有很多不同的執(zhí)行路徑，所以它們將很難測試。假如是嵌套的話，就會變得更加的復(fù)雜。
2、和壞情況下的代碼執(zhí)行時間會明顯的不同。這將導(dǎo)致CPU效率低下，或者是當(dāng)執(zhí)行長路徑時可能出現(xiàn)時序錯誤。
3、結(jié)構(gòu)代碼覆蓋測試的困難將會隨著分支的數(shù)量成指數(shù)增長，所以結(jié)構(gòu)分支應(yīng)該少。
相反，用數(shù)學(xué)計算方法可以得到相同的結(jié)果。用布爾代數(shù)做一個跳轉(zhuǎn)表來實現(xiàn)一個有限狀態(tài)機(jī)，或用查找表來實現(xiàn)的話，可以把100行有if-else結(jié)構(gòu)的代碼減少為 不到10行的代碼。
二、用空循環(huán)實現(xiàn)時延
實時軟件經(jīng)常需要增加時延來保證通過I/O口能有足夠的時間來準(zhǔn)備收發(fā)數(shù)據(jù)。這些時延通常都是通過增加一些空語句或空循環(huán)來實現(xiàn)(如果編譯器有優(yōu)化功能，要使用volatile保證變量不被優(yōu)化)。如果這種代碼在不同的處理器上使用，甚至對于一種處理器，只是運(yùn)行在不同的主頻(比如25MHZ或33MHZ)下，在快一些的處理器上這種代碼很可能就會失效。這一點我們在設(shè)計時要特別注意，因為它將直接帶來一些實時性問題，這種問題很難跟蹤和解決，因為這類問題表現(xiàn)的癥狀是五花八門的。
其實，我們可以使用一個基于定時器的實現(xiàn)機(jī)制。一些實時操作系統(tǒng)(RTOS)提供了這樣的功能，如果沒有，我們也可以很容易造一個定時器。下面列舉了兩種通用的造時延函數(shù)delay(int usec)：
大多數(shù)的遞減定時器允許軟件讀取當(dāng)前遞減寄存器的值。我們可以使用一個系統(tǒng)變量來記錄定時器的速率，單位為usec/tick。假如值為2 usec/tick,現(xiàn)在需要一個10usec的時延，那么時延函數(shù)的忙等待時間為5個tick。就算換了一個不同速率的處理器，定時器的tick數(shù)還是一樣。若是定時器的頻率更改了，則系統(tǒng)變量需要跟著修改，并且忙等待需要的tick也需要修改，但時延時間仍然保持不變。
三、移植代碼并非為移植而設(shè)計
不是專門為移植而設(shè)計的代碼，形式上不會是一種抽象出來的數(shù)據(jù)類型或是對象。這種代碼很可能和其他代碼之間存在一定的交互性，因此如果采用所有的移植代碼，那么就會存在很多我們不需要的代碼在其中。如果只采用其中一部分，那么我們就必須象一個外科醫(yī)生一樣對代碼進(jìn)行解剖，如果我們對這些代碼沒有足夠的認(rèn)識，我們很可能在剔除這些不需要的部分時存在一定的風(fēng)險，或是無意中影響到了其功能。如果代碼不是為移植而設(shè)計，先分析一下現(xiàn)有程序的功能，然后重新設(shè)計和組合代碼，將它改造成結(jié)構(gòu)良好，可移植性好的軟件模塊。這樣代碼就可以移植了。重新編寫這個模塊代碼的時間將比直接修改和調(diào)試原始的移植代碼的時間短得多。
四、交互式的和不完整的測試程序
許多嵌入式設(shè)計人員創(chuàng)建了一系列的測試程序，每塊測試程序是為了測試特定的一種特性。每個測試程序都必須單獨(dú)運(yùn)行，而且有時候需要用戶輸入一些內(nèi)容(比如通過鍵盤或開關(guān))，然后觀察輸出響應(yīng)。這種方法的問題就是編程人員僅僅想測試一下他們正在修改的部分。但是既然不相關(guān)代碼之間需要共享資源，就必然有交互作用，每次修改后都必須將整個系統(tǒng)全面測試一次。
要完成這件事，就必須避免創(chuàng)建交互式的的測試程序。創(chuàng)建一個單獨(dú)的測試程序，讓他盡可能做到能自測，這樣，任何時候即使有一點小改動，也能很容易而且迅速地完成一次完整的測試。不幸地是，說的總比做的容易，比如一些測試特別是I/O口的測試，只能交互式地完成。盡管如此，任何開發(fā)人員在編寫測試用例前還是應(yīng)該優(yōu)先考慮到編寫自動測試用例的原則，而不是寫一步算一步，采用邊寫代碼邊測試的方法。
五、超負(fù)荷設(shè)計系統(tǒng)
如果處理器和存儲器的平均利用率小于90%，而峰值利用率小于，那么我們就說這個系統(tǒng)屬于超負(fù)荷設(shè)計。對于設(shè)計者而言，寫程序使用過多的資源實在是一種的行為。在某種情況下，這種能直接導(dǎo)致盈利和破產(chǎn)的區(qū)別!軟件工程師有責(zé)任盡量減少一個嵌入式系統(tǒng)的價格和能源消耗。如果CPU的利用率只有45%，那么就可以使用運(yùn)行速度只有一半的處理器，因而減少了4倍的能量，而且可能每個處理器還能省下1美元或者更多的錢。
如果這個產(chǎn)品大批量生產(chǎn)，每個處理器省下1美元，僅這一項整個產(chǎn)品就能省下100萬美元。如果該產(chǎn)品是電池驅(qū)動的，電池就可以延長壽命，從而提升該產(chǎn)品的市場上的需求量。作為一種計算機(jī)家族中電源消耗的一種極端例子——便攜機(jī)，一般使用一種很沉的電池，多能使用3個小時。而一塊手表，重量輕，電池便宜，卻能使用3年!盡管軟件通常和能量消耗沒有直接的關(guān)系，但它確實扮演了一個重要的角色。
六、次設(shè)計時過度優(yōu)化
與第21個問題相反的一個問題也是一種通用的錯誤。一些編程者預(yù)見到了這種不規(guī)則現(xiàn)象(有些是很實際的，有些則有些奇怪)有一種奇怪的不規(guī)則現(xiàn)象的例子就是乘法比加法要長得多。一些設(shè)計者會將3*x寫成x+x+x.而在有些嵌入式處理器中，乘法比加法處理時間的兩倍要少一些，因此x+x+x的處理時間比3*x要慢一些。
一個能預(yù)見所有的不規(guī)則現(xiàn)象的編程人員可能會為了優(yōu)化代碼，將個版本的代碼編得可讀性很差。那是因為他并不知道是否真正需要優(yōu)化。一般的原則是，在實現(xiàn)過程中不要使用完全優(yōu)化。
七、差異化的多晶硅浮柵嵌入式閃存
多年來，大多數(shù)IDM都在為需要嵌入式閃存的應(yīng)用使用類似的1T多晶硅浮柵堆疊解決方案。在過去二十年間，創(chuàng)新型分離柵極SuperFlash?技術(shù)憑借其差異化且高效的多晶硅間擦除和源極注入編程存儲單元，不斷推動行業(yè)向前發(fā)展。
以上就是達(dá)內(nèi)科技的嵌入式講師根據(jù)我們這邊的學(xué)員在學(xué)習(xí)嵌入式的時候會遇到的嵌入式軟件在開發(fā)的時候會遇到的錯誤的觀念整理出來的，希望對于大家是有用的。如果說你是想要學(xué)習(xí)嵌入式技術(shù)的話，那么達(dá)內(nèi)科技?xì)g迎大家來我們公司進(jìn)行實地考察，獲取是也可以點擊我們文章下面的獲取試聽資格按鈕來獲取我們的嵌入式培訓(xùn)免費(fèi)課程試聽資格，來和我們的講師進(jìn)行面對面的交流和互動。但是如果你是在學(xué)習(xí)的是遇到了什么不懂的問題，那么也可以點擊我們的在線咨詢來咨詢我們的講師專業(yè)上的問題。
