A5系列
ZC1 Cat.1,500MHz,AWorksLP
ARM9系列
M1106/M1107 双核,四核800MHz,1GHz HDMI
M7系列
M1052 528MHz,ZigBee,Mifare,WiFi,LoRa
M1062 528MHz,WiFi,双网口,三路CAN
A7系列
M6G2C 528MHz,双网口,8串口,双CAN
A6G2C系列无线IoT核心板 528MHz,ZigBee,Mifare,WiFi,蓝牙
M6Y2C 800MHz,8串口,双网口,大容量
A6Y2C系列无线IoT核心板  800MHZ,8串口,WiFi,蓝牙
M1126 瑞芯微四核,1.5GHz,GPU
A8系列
M335x-T 800MHz,6串口,双网口,双CAN
A3352系列无线IoT核心板 800MHz,WiFi,蓝牙,RFID
A9/A9+FPGA系列
M6708-T 双核/四核,800MHz/1GHz HDMI
M7015 双核Cortex®-A9 + FPGA,766MHz
A35系列
M1808  瑞芯微双核A35,1.6GHz,AI核心板,NPU
A53系列
M62XX 1.4GHz,3路CAN FD,2路千兆,9路串口
M65XX 1.1GHz,扩展18串口或6路千兆网口
M6442 1.0GHz,5路TSN千兆网口,支持EtherCAT,GPMC
A55系列
M3568 

瑞芯微四核A55,2GHz,NPU,GPU,
VPU,Android,ubuntu,debian,鸿蒙

MD9340/MD9350 

芯驰多核,1.6GHz,
2路千兆,4路CAN FD

Risc-V系列
MR6450/MR6750 15路串口,4路CAN FD,2路千兆
MIPS系列
MX2000 1.2GHz,快速启动,实时系统

最简单IO驱动的智慧

从单片机到Arm7、Arm9、Cortex®-A8,从uC/OS到WinCE、Linux,GPIO驱动都是最简单、最易编写的驱动。但看似简单、毫无技术含量的驱动,其是否完整?是否规范?是否安全?

典型案例

本节将选取WinCE下两例典型案例,从反、正两个角度进行对比。

反方案例

以WinCE下某一开源的GPIO驱动为例,截取IOControl部分的代码,如程序清单1所示;请留意代码突出显示部分。

程序清单1

从反方案例,实现GPIO电平状态的读或写的功能仅需要几行代码,非常简单。

正方案例

如程序清单2所示,代码截取自ZLG某核心板GPIO驱动,请留意代码中突出显示部分。

程序清单2

从正方案例,实现GPIO电平状态的读或写的功能却花费了2倍的代码工作量,差异为何如此大?

案例点评
一、指针使用

在反方案例中,函数传递进来的指针参数未经判断而直接使用,这种情况下若为空指针或野指针,则程序极可能出现异常甚至崩溃!

在反方案例中,函数传递进来的指针参数未经判断而直接使用,这种情况下若为空指针或野指针,则程序极可能出现异常甚至崩溃!

反方案例在读取操作后,使用“*pBytesReturned = 2;”返回实际读取的字节数,但是,该指针依然未经判断而直接使用!

而正反案例则在每一项参数使用前均对参数范围、有效性进行判断,从根本上避免了参数异常情况的发生!

二、错误提示

在反方案例中,XXX_IOControl只是返回TRUE或FALSE,返回FALSE时应用层无从获取或获知是什么原因造成了“FALSE”!

对比正方案例,在参数判断时即开始添加错误提示,在return之前,调用SetLastError函数,应用层则可以通过GetLastError获取错误原因,允许用户更快速、准确的定位错误点。

三、注释

反方案例函数体内外几乎无注释;

而正方案例,无论函数体内的关键位置还是函数体外,均做必要、详细的注释说明,为程序的后期维护带来极大的便利!

包括最简单的GPIO在内,驱动实现功能非常容易,但驱动的完整性与可靠性却蕴藏着软件工程的大智慧。