最簡單IO驅動的智慧

從單片機到ARM7、ARM9
、Cortex-A8，從uC/OS到WinCE
、Linux，GPIO驅動都是最簡單、最易編寫的驅動。但看似簡單、毫無技術含量的驅動，其是否完整



？是否規範？是否安全？

典型案例

本節將選取兩例典型案例，從反、正兩個角度進行對比。

反方案例

以某一源碼中XXX驅動為例，截取XXX_IOControl部分的代碼，如程序清單1所示；請留意代碼突出顯示部分。

程序清單1


從反方案例
，實現GPIO電平狀態的讀或寫的功能僅需要幾行代碼，非常簡單。

正方案例

如程序清單2所示，代碼截取自ZLG某核心板GPIO驅動，請留意代碼中突出顯示部分。

程序清單2


從正方案例，實現GPIO電平狀態的讀或寫的功能卻花費了2倍的代碼工作量，差異為何如此大
？

案例點評

一

、指針使用

在反方案例中，函數傳遞進來的指針參數未經判斷而直接使用，這種情況下若為空指針或野指針，則程序極可能出現異常甚至崩潰！

反方案例在讀取操作後，使用“*pBytesReturned = 2;”返回實際讀取的字節數，但是，該指針依然未經判斷而直接使用！

而正反案例則在每一項參數使用前均對參數範圍
、有效性進行判斷，從根本上避免了參數異常情況的發生！

二、錯誤提示

在反方案例中
，XXX_IOControl隻是返回TRUE或FALSE，返回FALSE時應用層無從獲取或獲知是什麼原因造成了“FALSE”！

對比正方案例，在參數判斷時即開始添加錯誤提示

，在return之前
，調用SetLastError函數，應用層則可以通過GetLastError獲取錯誤原因，允許用戶更快速
、準確的定位錯誤點。

三
、注釋

反方案例函數體內外幾乎無注釋；

而正方案例，無論函數體內的關鍵位置還是函數體外，均做必要
、詳細的注釋說明
，為程序的後期維護帶來極大的便利！

包括最簡單的GPIO在內
，驅動實現功能非常容易，但驅動的完整性與可靠性卻蘊藏著軟件工程的大智慧。

相關閱讀：

解析DC-DC變換器參與電動汽車能量驅動的過程
具備超寬輸出電壓和高功率因數的LED驅動器設計
設計方案解讀：解析工業伺服驅動器的保護設計