专利名称：一种Linux驱动程序调试方法
技术领域：
本发明涉及一种程序调试技术，尤其涉及一种Linux驱动程序调试方法。
背景技术：
目前，基于Linux下的驱动开发为最具技术含量的科技工作之一，驱动软件的编写中，最主要的是BUG的解决，其中核心在于错误和/或漏洞(BUG)的定位。对于任何一位驱动程序的编写者来说，最急迫的问题之一就是如何完成调试。现在Linux下驱动程序的代码量越来越大，复杂程度越来越高。这给Liunx下的驱动程序的调试，带来了极大的不便。同时Linux下的驱动程序的调试工具却发展缓慢，单步调试、实时监控都不是容易的事。现有的调试方法主要是串口打印信息的方法，该方法包括开启调试功能，设置内核；执行调试命令，获取内核中的串口打印信息；关闭调试功能，清除内核，停止获取串口打印信息。这种方法缺点非常明显和致命。比如使用很繁琐、不方便、无法实时获得程序出现BUG的运行环境等。严重的阻碍了开发人员对于程序BUG的调试和问题的解决。因此，急需一种易于实施的Linux下的驱动调试方法来解决上述技术问题，以使开发人员可以较快速、方便地定位、解决BUG。
发明内容
本发明所要解决的技术问题之一是需要提供一种较快速、方便地定位、解决BUG的Linux驱动程序调试方法。为了解决上述技术问题，本发明提供了一种Linux驱动程序调试方法，该方法包括步骤A :在单片机系统中运行待调试Linux驱动程序；步骤B :判断所述待调试Linux驱动程序是否运行正常，若运行正常，则进入步骤D，反之，进入步骤C ;步骤C :使用单片机集成开发环境和单片机硬件调试工具驱动程序源码以进行跟踪调试和/或单步调试，根据调试对所述待调试Linux驱动程序代码进行修改并重新编译得到所述待调试Linux驱动程序后，返回步骤A ；步骤D :运行正常的待调试Linux驱动程序作为调试好的Linux驱动程序并将其移植到Linux上。根据本发明一方面的方法，所述单片机系统是MCU系统。根据本发明一方面的方法，所述单片机系统是51芯片、AVR芯片、MIPS芯片和ARM芯片中任一。根据本发明一方面的方法，所述集成开发环境是Keil和IAR中任一，所述硬件调试工具是H-JTAG、ulink和Jlink中任一。根据本发明一方面的方法，在所述待调试Linux驱动程序是非通用输入输出的目标接口的待调试驱动程序时，先通过上述步骤A至步骤C调试通用输入输出的所述待调试驱动程序，再通过上述步骤A至步骤C调试基于所述目标接口的所述待调试驱动程序。根据本发明一方面的方法，所述目标接口为I2C串行接口。与现有技术相比，本发明的一个或多个实施例可以具有如下优点本发明通过基于单片机的调试方法，充分利用单片机中丰富功能强大的调试方法和手段来调试Linux驱动程序。充分利用单片机中丰富的集成开发环境、价格低廉的硬件调试器，可以帮助开发人员实时跟踪程序的运行，监控几乎所有需要监控的程序运行参数，可以方便开发人员进行当步执行、调试变量的改变等。由于是基于单片机的调试方法，克服了对驱动程序不易监控和调试的问题，提高了开发人员的效率。虽然在下文中将结合一些示例性实施及使用方法来描述本发明，但本领域技术人员应当理解，为并不旨在将本发明限制于这些实施例。反之，旨在覆盖包含在所附的权利要求书所定义的本发明的精神与范围内的所有替代品、修正及等效物。本发明的其他优点、目标，和特征在某种程度上将在随后的说明书中进行阐述，并且在某种程度上，基于对下文的考察研究对本领域技术人员而言将是显而易见的，或者可以从本发明的实践中得到教导。本发明的目标和其他优点可以通过下面的说明书，权利要求书，以及附图中所特别指出的结构来实现和获得。
附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例共同用于解释本发明，并不构成对本发明的限制。在附图中图I是根据本发明第一实施例的GPIO控制驱动程序的调试的流程示意图；图2是根据本发明第二实施例的AT24C02的I2C的驱动程序调试的流程示意图。
具体实施例方式以下将结合附图及实施例来详细说明本发明的实施方式，借此对本发明如何应用技术手段来解决技术问题，并达成技术效果的实现过程能充分理解并据以实施。需要说明的是，只要不构成冲突，本发明中的各个实施例以及各实施例中的各个特征可以相互结合，所形成的技术方案均在本发明的保护范围之内。另外，在附图的流程图示出的步骤可以在任意一种单片机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。第一实施例图I是根据本发明第一实施例的用于Linux系统的通用输入输出(GPIO,GeneralPurpose I/O)控制驱动程序的调试的流程示意图，下面根据图I详细说明本实施例的各个步骤。在本发明第一实施例中，优选地，将使用基于ARM内核的例如STM32F207VE等单片机系统进行驱动程序的调式。单片机集成开发环境则优选的使用IAR，单片机硬件调试工具优选的使用Jlink或ulink。
在本发明第一实施例中，主要是对一个编写好的GPIO的控制驱动程序(对应于待调试Linux驱动程序)进行调试，该GPIO的控制驱动程序用于实现5个LED灯间隔Is的流水闪烁效果。开发人员编写GPIO的控制驱动程序，准备好调试用的软硬件工具。步骤S110，在单片机系统中运行待调试Linux驱动程序。在本实例中，在STM32F207单片机板子上运行该GPIO控制驱动程序。步骤S120 :判断待调试Linux驱动程序是否运行正常，若运行正常，则进入步骤S140,反之，进入步骤S130。在本例中，出现异常，例如发现程序在第3个LED灯不亮，而第2个和第4个LED灯之间相隔2秒，因此进步骤S130。步骤S130，使用单片机集成开发环境和单片机硬件调试工具驱动程序源码以进行跟踪调试和/或单步调试，根据调试对所述待调试Linux驱动程序代码进行修改并重新编译得到所述待调试Linux驱动程序后，返回步骤 SI10。在本实例中，使用IAR集成开发环境，Jlink硬件调试器去驱动程序源码进行跟踪，单步调试。调试发现控制第三个LED灯的GPIO的控制寄存器设置不正确即查找问题根源。修正控制程序源码，重新编译，在STM32F207单片机板子运行，显示正常。步骤S140，将调试好的GPIO的控制驱动程序移植到Linux上，本实施案例结束。第二实施例在本实施例中，提供了一种非GPIO出的目标接口(亦即，该目标接口不是通用输入输出接口)的待调试驱动程序时、先通过上述SllO至S130的处理调试GPIO的待调试驱动程序，再通过上述SllO至S130的处理调试基于目标接口的所述待调试驱动程序的方法。图2是根据本发明第二实施例的用于Linux系统的AT24C02的I2C(Inter —Integrated Circuit)的驱动程序调试的流程示意图，下面参照图2对该实施例进行说明。AT24C02是一个2K位串行CMOS E2PR0M。本实例中的目标接口为I2C接口。在本发明第二实施例中，优选地，将使用基于ARM(也可以是AVR等)内核的STM32F207VE单片机(也可以是LPC2138、C8051F020等)系统进行驱动程序的调式。这里以STM32F207VE作为单片机系统的例子，是因为目前ARM内核的产业链最为成熟，调试工具最为丰富，而其中STM32系列则是ARM单片机中，为市场应用较广、占有率较高的单片机系统之一，因此较具有代表性。集成开发环境则优选的使用Keil，硬件调试工具优选的使用ulink。在本发明第二实施例中，主要是编写一个AT24C02的I2C的驱动程序(目标接口的驱动程序)，实现对于基于I2C串行接口的AT24C02的存储器的读写。本例使用芯片的GPIO模拟I2C的方式实现I2C的串行通信协议。开发人员编写基于GPIO的I2C串行通信协议的驱动程序和AT24C02的I2C的驱动程序，准备好调试用的软硬件工具。步骤S210，在STM32F207VE单片机板子上运行该基于GPIO的I2C串行通信控制驱动程序，如果运行正常，跳到步骤S230，否则进行步骤S220。步骤S220，使用Keil集成开发环境，ulink硬件调试器去驱动基于GPIO的I2C串行通信控制驱动程序的程序源码以进行跟踪，单步调试。调试发现问题的原因所在，修正控制程序源码，重新编译，在STM32F207单片机板子运行，直至显示正常，进入步骤230。步骤S230，在STM32F207单片机板子上运行该AT24C02的I2C的驱动程序，如果运行正常，跳到步骤S250，否则进行步骤S240。
步骤S240，使用Keil集成开发环境，ulink硬件调试器去驱动程序源码进行跟踪，单步调试。调试发现问题的原因所在，修正控制程序源码，重新编译，在STM32F207单片机板子运行，直至显示正常。步骤S250，将调试好的AT24C02的I2C的驱动程序移植到Linux上，本实施案例结束。这样，通过编写基于GPIO的I2C串行通信协议的驱动程序，并先调试基于GPIO的I2C串行通信协议的驱动程序，可以使得调试整个驱动程序的过程更加简化，使得每个驱动程序调试相对容易。此外，由于AT24C02的I2C的驱动程序可以分成I2C串行通信协议的驱动程序和AT24C02的I2C的驱动程序。前者作为一种通用的I2C串行通信协议的驱动程序可以被各种基于I2C协议的设备调用。AT24C02就是其中的一种设备。因此，进行这样的可分阶段调试的设计也可使得驱动的框架明确、层次分明，符合Linux驱动设计中设备模型的要求，可以简化整个驱动程序等。此外，本实施例也可以使用IAR等开发环境。需要说明的是，现有技术中，H-JTAG> ulink和Jlink等硬件调试器主要是用来调试单片机，难以用来进行Linux驱动程序调试。本发明利用在单片机的调试开发环境，使得H-JTAG> ulink和Jlink等硬件调试器可以较好地用来调试Linux驱动程序。此外，本发明的单片机系统指MCU (微控制单元，又称单片微型计算机)。包括例如51芯片、AVR芯片、MIPS芯片、ARM芯片等。本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的单片机装置来实现，这样，本发明不限制于任何特定的硬件和软件结合。虽然本发明所揭露的实施方式如上，但所述的内容只是为了便于理解本发明而采用的实施方式，并非用以限定本发明。任何本发明所属技术领域内的技术人员，在不脱离本发明所揭露的精神和范围的前提下，可以在实施的形式上及细节上作任何的修改与变化，但本发明的专利保护范围，仍须以所附的权利要求书所界定的范围为准。
权利要求
1.一种Linux驱动程序调试方法，其特征在于，包括 步骤A :在单片机系统中运行待调试Linux驱动程序； 步骤B :判断所述待调试Linux驱动程序是否运行正常，若运行正常，则进入步骤D，反之，进入步骤C ; 步骤C :使用单片机集成开发环境和单片机硬件调试工具驱动程序源码以进行跟踪调试和/或单步调试，根据调试对所述待调试Linux驱动程序代码进行修改并重新编译得到所述待调试Linux驱动程序后,返回步骤A ； 步骤D :将所述待调试Linux驱动程序作为调试好的Linux驱动程序并将其移植到Linux 上。
2.根据权利要求I所述的方法，其特征在于，所述单片机系统是MCU。
3.根据权利要求I所述的方法，其特征在于，所述单片机系统是51芯片、AVR芯片、MIPS芯片和ARM芯片中任一。
4.根据权利要求I所述的方法，其特征在于，所述集成开发环境是Keil和IAR中任一，所述硬件调试工具是H-JTAG、ulink和Jlink中任一。
5.根据权利要求I所述的方法，其特征在于，在所述待调试Linux驱动程序是非通用输入输出的目标接口的待调试驱动程序时，先通过上述步骤A至步骤C调试通用输入输出的所述待调试驱动程序，再通过上述步骤A至步骤C调试基于所述目标接口的所述待调试驱动程序。
6.根据权利要求5所述的方法，其特征在于，所述目标接口为I2C串行接口。
全文摘要
本发明公开了一种Linux驱动程序调试方法。该方法包括步骤A在单片机系统中运行待调试Linux驱动程序；步骤B判断所述待调试Linux驱动程序是否运行正常，若运行正常，则进入步骤D，反之，进入步骤C；步骤C使用单片机集成开发环境和单片机硬件调试工具驱动程序源码以进行跟踪调试和/或单步调试，根据调试对所述待调试Linux驱动程序代码进行修改并重新编译得到所述待调试Linux驱动程序后，返回步骤A；步骤D运行正常的待调试Linux驱动程序作为调试好的Linux驱动程序并将其移植到Linux上。使用本发明的方法能够较快速、方便地定位、解决漏洞和/或错误。
文档编号G06F11/36GK102929779SQ20121042802
公开日2013年2月13日 申请日期2012年10月31日 优先权日2012年10月31日
发明者姚培君, 蔡正龙 申请人:中标软件有限公司