|
嵌入式系統設計不僅要了解硬件還應該了解它與軟件之間的相互影響和作用。硬件設計需要一定的設計范例，這點(diǎn)對于軟件設計卻不那么適用。如何從單純的硬件設計過(guò)渡到硬軟結合的設計，在你著(zhù)手開(kāi)發(fā)軟件時(shí)需注意以下八個(gè)軟件設計技巧。 1.設計控制流程圖 工程師進(jìn)行到開(kāi)發(fā)軟件這一步時(shí)會(huì )情不自禁地開(kāi)始書(shū)寫(xiě)代碼。這種思維定勢就像在原理圖還未完成之前就開(kāi)始嘗試畫(huà)PCB。當著(zhù)手開(kāi)發(fā)軟件時(shí)，克制寫(xiě)代碼的沖動(dòng)，取而代之的應該是軟件流程結構圖表的設計，這點(diǎn)非常重要。流程圖能清晰地呈現給開(kāi)發(fā)人員軟件的各個(gè)需要的組成部件，正如電路圖列出硬件設計所需的各種元器件一樣。做到這點(diǎn)能很大程度上使程序整體更易于組織，而且也會(huì )減少占開(kāi)發(fā)周期較長(cháng)的調試工作量進(jìn)而節省時(shí)間減少調試的繁瑣。 2.使用狀態(tài)機控制程序 流程狀態(tài)機是20世紀優(yōu)秀的軟件發(fā)明之一。應用程序一般被分解為多個(gè)不同的狀態(tài)，每一個(gè)狀態(tài)控制一個(gè)特定的程序分支。狀態(tài)機包括內部狀態(tài)和依據不同激勵所控制的狀態(tài)轉換。使用狀態(tài)機機制設計軟件能夠使模塊化的可維護的軟件開(kāi)發(fā)更加容易而且易于理解。狀態(tài)機原理與算法的示例隨處可見(jiàn)。 3.避免使用全局變量 在過(guò)去的函數式編程中，程序員使用函數編寫(xiě)程序，他們的唯一目標是使程序盡可能快的運行而不考慮程序的結構和重用性。這類(lèi)程序風(fēng)格在使用全局變量時(shí)不注意變量的作用范圍引起其他函數修改的危險性。這樣變量會(huì )被多次占用和重寫(xiě)。如今面向對象的程序設計中，成員變量被定義在最小的作用范圍之內并封裝起來(lái)避免被重新復值和濫用。所以建議盡量少地使用全局變量，實(shí)在需要的話(huà)，使用C語(yǔ)言中的關(guān)鍵字“extern”來(lái)修飾。 4.充分利用模塊化的設計理念 如果你問(wèn)一位工程師項目的哪一部分最有可能會(huì )拖延交付并超出預估時(shí)間，那答案一定是軟件周期了。軟件通常是復雜而且不易開(kāi)發(fā)和維護的，特別是當項目應用程序集中在一個(gè)單一的文件里，或者幾個(gè)結構松散的文件中時(shí)。為了便于代碼重用和軟件可維護并減小軟件的復雜度，強烈建議發(fā)揮高級程序設計語(yǔ)言模塊化的特性，在程序的結構中把公用的函數分離出來(lái)作為一個(gè)獨立的模塊。通過(guò)這種方式可以讓程序員開(kāi)始創(chuàng )建包含有常用函數和常用的聲明定義，它可以很容易的被其他的代碼重用，這在以后的測試階段不僅可以節省時(shí)間代價(jià)還能提高代碼的質(zhì)量。 5.中斷服務(wù)事件 保持簡(jiǎn)練中斷服務(wù)事件是中斷處理器正在執行的程序，轉而去處理觸發(fā)該中斷的外設的請求的一種機制。處理器響應中斷請求需要大量的系統開(kāi)銷(xiāo)，具體表現在保存被中斷程序的狀態(tài)（入棧下條指令的段地址、偏移地址和程序狀態(tài)寄存器，有時(shí)還會(huì )入棧若干寄存器的值），執行中斷服務(wù)程序然后恢復中斷點(diǎn)繼續執行（依次出棧各寄存器），雖然現在的處理器速度非�？斓沁@種系統開(kāi)銷(xiāo)仍然需要考慮。一般來(lái)說(shuō)，為了避免與主程序沖突程序員總想使中斷執行時(shí)間減小到最小。這就意味著(zhù)中斷服務(wù)事件應該短小簡(jiǎn)單。不能在中斷程序中調用函數。另外，如果中斷需要處理的事件特別復雜或者需要花費較長(cháng)的時(shí)間，這個(gè)時(shí)候中斷服務(wù)程序應該滿(mǎn)足最小的需求，例如將數據載入到緩沖寄存器、設置標志位，而讓主程序去處理讀入的數據。這樣處理器的工作大部分周期都在處理程序而不是中斷。 6.使用處理器示例代碼 測試設備對于硬件設計，在畫(huà)板之前標準的測試電路有助于工程師理解電路的特性。同樣可以適用于軟件設計，半導體廠(chǎng)商通常有測試微處理器各個(gè)部分的功能的示例程序提供工程師體驗各部分是如何工作的。據此可以提前組織軟件的結構并且預知在設計中的問(wèn)題。提前確定在設計潛在的障礙遠比在產(chǎn)品完成前幾個(gè)小時(shí)發(fā)現問(wèn)題更加科學(xué)合理。而值得注意的是廠(chǎng)商提供的代碼通常不是模塊化而且不做必要的修改是很難直接用于實(shí)際的軟件中的。 7.控制函數的復雜度 在工程設計中有句俗語(yǔ)叫“KISS”，意思是“Keep It Simple Silly”。在處理一些復雜的任務(wù)時(shí)最簡(jiǎn)單有效的方法是把它分解成若干個(gè)簡(jiǎn)單的子任務(wù)，當任務(wù)或者功能很復雜時(shí)，人們很難留意所有的細節也很難不出錯。當工程師寫(xiě)了一個(gè)在當時(shí)能夠理解的復雜函數，可一段時(shí)間后需要維護程序了還能不能清晰的呈現出當初的設計思想這是值得考慮的。有大量的技術(shù)來(lái)衡量函數的復雜度像“循環(huán)復雜度”。經(jīng)驗告訴我們，函數的循環(huán)復雜度應該低于10比較好。 8.詳細的文檔 在激烈的軟件開(kāi)發(fā)競爭中關(guān)注的焦點(diǎn)很容易就局限在代碼的書(shū)寫(xiě)和調試而忽略文檔的編寫(xiě)。有時(shí)迫于壓力要求寫(xiě)文檔，開(kāi)發(fā)人員通常把文檔安排在項目開(kāi)發(fā)的最后的一個(gè)環(huán)節集中編寫(xiě)。然而給代碼寫(xiě)文檔應該乘在頭腦里面還比較清晰的時(shí)候比較關(guān)鍵，這樣在后續的開(kāi)發(fā)或者自己閱讀注釋的時(shí)候能很快的回憶起當時(shí)的設計思想。 |
