利用函數參數和返回值提高嵌入式軟件質量

3 狀態(tài)信息的使用
在調用μC／OS―II的每個系統(tǒng)函數時，只要被調用的函數提供狀態(tài)信息，都應該對這些狀態(tài)信息進行分析和處理。專業(yè)軟件設計者信奉這樣一個道理：“編寫無錯代碼的最好方法是把防止錯誤放在第一位”。以調用μC／OS―II的系統(tǒng)函數OSSemPend()為例，用戶不需要去改動OSSemPend()函數的代碼，假設這部分內容是沒有什么問題的?，F在我們要做的是檢測這個函數執(zhí)行時的狀態(tài)，也就是它產生的出錯信息。這個函數返回三種結果說明用戶使用的錯誤，如表1所列：0S_ERR_EVENT_TYPE表示用戶在調用OSSemPend()函數時提供的指針數據不是指向信號量的，發(fā)生了類型錯誤；OS_ERR_PEVENT_NULL表示用戶提供的用作實際參數的指針是一個空指針；OS_ERR_PEND_ISR表示用戶在中斷服務程序中調用了OSSemPend()函數；這三種狀態(tài)錯誤是在軟件設計階段由于用戶粗心或者對μC／OS―II系統(tǒng)函數不了解而導致的。只要用戶在設計過程中小心謹慎，這類錯誤可以避免。但是，從防止錯誤的角度來考慮，對這些錯誤的狀態(tài)進行檢測和處理是必要的，這樣在錯誤發(fā)生時錯誤處理程序會給出簡單的提示甚至對錯誤進行修改。錯誤處理程序防止在程序調試過程中反復閱讀程序代碼，避免了花費很大的精力去查找錯誤，提高了軟件設計效率。
按照以上方案設計出的嵌入式系統(tǒng)軟件可以認為是一個理想的編譯器。現在考慮一下，倘若編譯程序能夠正確地指出代碼中的所有問題，那相應程序的錯誤情況會怎樣?這不單指語法錯誤，還包括程序中的任何問題，不管它多么隱蔽。顯然，現在所有的編譯器都無法實現這種功能，所以要對編譯器的功能進行擴展。這種設計思路可以認為是：軟件設計者要設計出編譯器的擴展功能，使得在進行軟件設計時，編譯器能夠自己檢查錯誤。如果能夠做到，軟件設計的勞動量將大大降低。

4 軟件的調試版與交付版
前面的改進程序對OSSemPend()函數調用產生的所有可能狀態(tài)進行了處理，而這部分代碼中的大部分都是冗余代碼，為的是便于軟件的設計和調試。使用實時操作系統(tǒng)μC／0S―II進行嵌入式軟件設計，用到的系統(tǒng)函數當然不止OSSemPend()一個，如果每個函數調用結束后都像程序中那樣處理，代碼的空間會迅速增加，程序的效率則會大大降低。
為了解決這個問題，首先考慮，如果非常謹慎小心進行程序設計，多數的狀態(tài)檢測處理過程就可以省略。之所以對每個狀態(tài)信息進行檢測處理是為了提高軟件設計調試的效率。在軟件調試通過后，有些狀態(tài)信息的檢測就沒有必要了。這就像乘坐飛機出行前要買保險，等航班到達目的地后，保險就沒有什么用處了。軟件最終是作為一個產品提供給客戶的。這個產品是最終版本(當然還會不斷升級)。在進行產品設計時會有一個調試版本，這個調試版要貫穿整個軟件的生存周期。調試版是為了軟件的設計、調試和升級使用，不會提供給用戶，更不會出現在產品中。
具體到嵌入式系統(tǒng)軟件設計問題，仍然以調用OS―SemPend()函數的代碼為例來說明問題。調用OSSem―

通過觀察上述程序和前面的改進發(fā)現，本段程序中加了幾個條件編譯指令。如果沒有定義TEST標志，則有一部分代碼將不會被編譯，這就是交付版軟件。反之，如果定義了TEST標志，則表示為調試版，所有的指令代碼都會被編譯。通過比較這兩個版本看到：交付版的代碼比調試版的代碼在數量上大大減少。而且通過分析知道，在軟件調試通過以后，就不存在OS_ERR_EVENT_TYPE、0S_ERR_PEND_ISR和OS_ERR_PEVENT_NULL的錯誤了，這兩個版本實現的功能完全相同，這部分代碼確實沒有編譯的必要了。

結 語
嵌入式系統(tǒng)軟件設計過程中，大部分場合會用到嵌入式實時操作系統(tǒng)。用戶在保證自已設計代碼質量的前提下，還要充分考慮調用系統(tǒng)函數時產生的狀態(tài)信息，并進行適當的處理。只有這樣，才能夠提高軟件的設計效率，縮短設計周期。