设备驱动调试和移植的一般方法（二）

一、 检查应用程序是否可以正常使用

如果驱动得到了正常的初始化，这时候你开始检查该设备驱动对应的应用程序是否可以正常使用（或者自己写设备驱动的测试应用程序）。如果可以正常使用，那你太幸运了，这说明芯片原厂为你考虑的很周到，你可以节省N多时间干别的事儿了。

但遗憾的是，往往事情不会这么顺利，当你检查应用程序的时候，你发现应用程序没有做出应有的反应——例如当你辛苦把camera的驱动添加到kernel而且顺利初始化之后，你兴奋地进入系统打开camera发现：黑屏！你郁闷了，但是郁闷不能解决问题，这时候真正的所谓设备驱动的“调”和“试”才来了。赶紧去找一个万用表和一个示波器吧。

二、 设备驱动的“调”和“试”

所谓“调”，就是你依据设备芯片datasheet、主控datasheet、相关的规格书等资料，以及观察与测量的结果，不断地对设备驱动 code进

行添加、删除和修改。

所谓“试”，就是你在添加、删除和修改的同时要不断地：

l   通过串口对反馈信息进行观察；

l   通过万用表对各电源引脚电压进行测量；

l   通过示波器对芯片的时钟（输入的和输出的）频率（包括测量晶振）、数据信号的波形、某种总线信号的波形，等各个引脚进行测量。

观察设备的上电时序，数据交互时序等等是否正常（参考datasheet）。

l   通过测试应用程序对驱动进行测试，并反复观察设备驱动的运行状态。

测试不光是测试员的事情，你必须保证自己调试的驱动可以运行稳定才可以提交代码，发给测试员进行大量测试。测试自己调试的设备驱动有以下几种：

（1）    利用系统里面现有的应用程序进行测试

这个是最直接的测试，也省去了你自己编写测试程序的时间。

（2）    自己编写linux应用程序来测试驱动

如果你对系统现有的应用程序不放心，或者不满意，就自己编写测试驱动吧。

（3）    利用proc或者sys文件系统的读和写函数

如果你在设备驱动里面添加了proc或者sys文件系统的读和写函数，你就可以在命令行通过cat或者echo命令来对设备驱动的各项参数进行手动测试。

注：以上测试方法是我习惯用的，除了这些，还是有其他一些测试方法我没有列举出来，感兴趣的话可以google一下。

此外，应该养成一个好习惯，那就是在测量各个引脚的同时，你最好创建一份excel表格，把各个引脚的电压、波形等情况记录下来，目的是在N多次修改之间作比较，也更有备忘的作用。

    这里的“调”和“试”的过程是最耗时的，也是设备驱动调试的最关键的步骤，所以你应该非常有耐心的走好这一步。还应该注意的是，设备驱动的调试不光是你一个人的事情，有时候你闷头苦干一个星期都不一定能搞定。所以，进行调试的同时，必须有一个硬件工程师配合你，因为驱动不能正常运行也很有可能是硬件的设计纰漏导致的。此外，不要闭门造车，毕竟你在一个大的开发团队里面，你需要及时和同事进行有效的交流，避免走弯路。最后，如果还是存在问题，你就得邀请芯片原厂的FAE过来喽。

补充说明

    要进行设备驱动的移植，一般的，你必须具备以下几个条件：

l   和当前设备芯片相近的或者相类似的芯片的现有驱动代码。

这句话有点拗口了，举个例子来讲吧。例如，你现在要移植一份驱动到g-sensor（BMA250E）上，你现在就应该尽可能

地去找到和芯片BMA250E相近的芯片所对应的驱动代码。这时候，你高兴的发现，咦？！手头上还有一份BMA250的代码,太幸运了。此时你就可以基于BMA250的代码来做移植。但有时候并没有这么幸运，那怎么办呢？这时候你完全可以去找其他类型的g-sensor啊，假如你手头上并没有BMA250的代码，但是你有一份ADXL345的代码，那当然也是可以的，你完全可以基于ADXL345的代码来做移植。至于为什么要选择与当前设备芯片相近的芯片所对应的驱动代码，原因就四个字“提高效率”。

l   当前芯片的详细datasheet，以及芯片的相关说明

l   开发板的原理图

如果有pads版本的原理图和贴片图，那是最好的了，方便以后测量引脚的各项参数。

l   万用表和示波器

这是调试、移植、开发设备驱动必不可少的设备。

具备了以上几个条件之后，接着走上文所讲的第一个和第二个步骤，尤其在第二个步骤，你可能得费好大力气来针对你当前的开发板进行驱动文件的修改。修改一般都包括I\O配置、中断的设置、总线的配置（例如I2C、SPI、SDIO等）、寄存器的配置、甚至驱动代码的框架都得修改。等你这一步做好了，接着进行上文谈到的第三步，然后一步一步往下走完即可。

用一句话概括一下驱动移植吧。驱动的移植实际上就是：“通过添加、删除和修改，使现有的一份芯片相近的驱动代码可以在目标芯片和目标板上跑起来并且跑的很稳定！”