从最简单的IO驱动看出工程师的水平

从最简单的IO驱动看出工程师的水平

GPIO驱动是嵌入式系统中最简单的驱动，然而有多少电子类高材生在它身上栽了跟头? 　　从单片机到ARM7、ARM9、Cortex-A8，从uC/OS到WinCE、Linux，GPIO驱动都是最简单、最易编写的驱动。但看似简单、毫无技术含量的驱动，其是否完整?是否规范?是否安全? 典型案例 　　本节将选取两例典型案例，从反、正两个角度进行对比。 　　 反方案例 以某一源码中XXX驱动为例，截取XXX_IOControl部分的代码，如程序清单1所示;请留意代码突出显示部分。

程序清单1

PUBLIC BOOLXXX_IOControl(){}

从反方案例，实现GPIO电平状态的读或写的功能仅需要几行代码，非常简单。 正方案例 如程序清单2所示，代码截取自ZLG某核心板GPIO驱动，请留意代码中突出显示部分。 程序清单2

/* ************************************************ * Function name: * Description: * Input: * Output: * Note: * Created by: * Created Date: * ------------------------------- * Modified by: * Modified Date: * ------------------------------- *********************************************** */BOOLXXX_IOControl(){}

从正方案例，实现GPIO电平状态的读或写的功能却花费了2倍的代码工作量，差异为何如此大? 案例点评 一、指针使用 在反方案例中，函数传递进来的指针参数未经判断而直接使用，这种情况下若为空指针或野指针，则程序极可能出现异常甚至崩溃!反方案例在读取操作后，使用“*pBytesReturned = 2;”返回实际读取的字节数，但是，该指针依然未经判断而直接使用!而正反案例则在每一项参数使用前均对参数范围、有效性进行判断，从根本上避免了参数异常情况的发生! 二、错误提示 在反方案例中，XXX_IOControl只是返回TRUE或FALSE，返回FALSE时应用层无从获取或获知是什么原因造成了“FALSE”!对比正方案例，在参数判断时即开始添加错误提示，在return之前，调用SetLastError函数，应用层则可以通过GetLastError获取错误原因，允许用户更快速、准确的定位错误点。 三、注释 反方案例函数体内外几乎无注释;而正方案例，无论函数体内的关键位置还是函数体外，均做必要、详细的注释说明，为程序的后期维护带来极大的便利!包括最简单的GPIO在内，驱动实现功能非常容易，但驱动的完整性与可靠性却蕴藏着软件工程的大智慧。

（待续。。。） ​​​http://wtoutiao.com/p/i47dMb.html​​

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。