CN113741988A

CN113741988A - Drive debugging method, device and computer readable storage medium

Info

Publication number: CN113741988A
Application number: CN202111029541.3A
Authority: CN
Inventors: 岳顺; 李亚菊
Original assignee: Shenzhen Skyworth RGB Electronics Co Ltd
Current assignee: Shenzhen Skyworth RGB Electronics Co Ltd
Priority date: 2021-09-02
Filing date: 2021-09-02
Publication date: 2021-12-03

Abstract

The invention discloses a drive debugging method, which refers debugging plug-ins which realize different debugging commands to a command mapping table in advance; after traversing all the existing debugging plug-ins, acquiring the input of a command line, and analyzing the command line to obtain a command field and a parameter field; and matching the command field with the command identification number of the debugging plug-in, if so, automatically calling a system interface to load a target debugging plug-in corresponding to the command identification number from the command mapping table, and transmitting the parameter field to the target debugging plug-in to execute debugging operation. The invention also discloses a drive debugging device and a computer readable storage medium. The invention provides a programming mode based on plug-in, which realizes a universal drive debugging method, reduces the repeated development of a drive debugging program and improves the development efficiency of drive debugging.

Description

Drive debugging method, device and computer readable storage medium

Technical Field

The present invention relates to the field of driver debugging, and in particular, to a driver debugging method, device and computer readable storage medium.

Background

With the development of various hardware and software, many electronic devices run on the os, and the open source feature of LINUX is used by various manufacturers, and different hardware is also used to implement various innovative functions. For the control of different hardware, corresponding drivers need to be implemented in the kernel. Drivers are typically provided by hardware vendors. In order to debug the device driver, a system call interface at the bottom layer is needed to be used for implementation, and different devices need to write corresponding debugging programs. But the basic flow of different driver debuggers is consistent. The existing driver debugging programs are developed aiming at equipment independently, so that a lot of repetitive work can be brought, the debugging efficiency is not high, and a user needs to be familiar with various debugging methods. In order to avoid repeated development and improve software development and debugging efficiency, a general driving debugging method is introduced.

Disclosure of Invention

The invention mainly aims to provide a driver debugging method, aiming at solving the technical problem of low efficiency caused by repeated development of a driver debugging program.

In order to achieve the above object, the present invention provides a driver debugging method, including:

a debugging plug-in which different debugging commands are realized is quoted into a command mapping table in advance;

after traversing all the existing debugging plug-ins, acquiring the input of a command line, and analyzing the command line to obtain a command field and a parameter field;

and matching the command field with the command identification number of the debugging plug-in, if so, automatically calling a system interface to load a target debugging plug-in corresponding to the command identification number from the command mapping table, and transmitting the parameter field to the target debugging plug-in to execute debugging operation.

Optionally, the driving debugging method includes: :

when a new debugging command is received, self-defining and writing a function of the debugging plug-in according to the new debugging command to generate a new debugging plug-in;

a new debug plug-in is referenced into the command mapping table.

Optionally, the step of writing a function of the debug plug-in according to the new debug command to generate a new debug plug-in by customization includes:

and according to the new debugging command, self-defining writing is carried out on the function according to the data format of the preset debugging plug-in, and the new debugging plug-in is generated.

Optionally, after the step of matching the command field with the command identification number of the debug plug-in, the method further includes:

and if the debugging command is not matched or the matched debugging plug-in cannot realize the debugging command, prompting to quote a new debugging plug-in.

Optionally, after the step of prompting to refer to a new debug plug-in, the method further includes:

opening the authority of quoting the debugging plug-in, and quoting a new debugging plug-in to a command mapping table, wherein the new debugging plug-in is a debugging plug-in which a command field is matched or the debugging command is realized.

Optionally, the step of loading, by the automatic call system interface, the target debug plug-in corresponding to the command identification number from the command mapping table includes:

and acquiring a target debugging plug-in corresponding to the command identification number, and transmitting the parameter field to a function of the target debugging plug-in so as to execute debugging operation.

Optionally, the step after passing parameters into the function of the corresponding debugging plug-in to perform the debugging operation includes:

if the execution is successful, recording the command field and the parameter field of the command line to a success list;

if the execution fails, the state of waiting for the input of the debugging command is returned.

Optionally, the step after the execution is successful further includes:

and directly converting the recorded success list into corresponding compiling language codes and debugging codes, and integrating the compiling language codes and the debugging codes into a driving debugging development system for secondary development based on debugging.

In addition, to achieve the above object, the present invention also provides a drive debug apparatus, including: the device comprises a memory, a processor and a driver debugging program which is stored on the memory and can run on the processor, wherein the driver debugging program realizes the steps of the driver debugging method when being executed by the processor.

In addition, to achieve the above object, the present invention further provides a computer readable storage medium, having a driver debugging program stored thereon, which, when being executed by a processor, implements the steps of the driver debugging method as described above.

The drive debugging method, the drive debugging device and the computer readable storage medium provided by the embodiment of the invention achieve the purpose of debugging the drive by realizing a universal drive debugging framework. All the driven debugging is realized by using a basic system interface, a set of universal debugging method is convenient to use, and the debugging can be realized by using a uniform plug-in for different equipment. The framework abstracts all command operations into a plug-in, and simultaneously creates a command mapping table for supporting corresponding command implementation. When the debugging is driven, the obtained command line input by the debugging personnel is analyzed to obtain a command field and a parameter field, the command field is used for matching a command identification number in a command mapping table, and the parameter field is transmitted to a debugging plug-in unit after the corresponding debugging plug-in unit is loaded so as to execute debugging operation, so that the debugging command is completed. Therefore, for debugging developers, the implementation of the functions focused on debugging drivers is only needed, and the implementation details of the driver debugging framework of different devices are not needed to be concerned. The invention also realizes the automatic interactive debugging command, dynamically generates the corresponding C language code and the test code, is used for being directly integrated into an actual development system, and is convenient for secondary development based on debugging. Therefore, repeated development is avoided, and the software development and debugging efficiency is improved.

Drawings

Fig. 1 is a schematic structural diagram of a drive debugging device of a hardware operating environment according to an embodiment of the present invention;

fig. 2 is a flowchart illustrating a first embodiment of a driving debugging method according to the present invention.

The implementation, functional features and advantages of the objects of the present invention will be further explained with reference to the accompanying drawings.

Detailed Description

It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

In order to better understand the technical solution, the technical solution will be described in detail with reference to the drawings and the specific embodiments.

As shown in fig. 1, fig. 1 is a schematic structural diagram of a driver debug device in a hardware operating environment according to an embodiment of the present invention, where the driver debug device may be a terminal.

The terminal of the embodiment of the invention can be a PC, and can also be a mobile terminal device with a display function, such as a smart phone, a tablet computer, an electronic book reader, an MP3(Moving Picture Experts Group Audio Layer III, dynamic video Experts compress standard Audio Layer 3) player, an MP4(Moving Picture Experts Group Audio Layer IV, dynamic video Experts compress standard Audio Layer 3) player, a portable computer, and the like.

As shown in fig. 1, the terminal may include: a processor 1001, such as a CPU, a network interface 1004, a user interface 1003, a memory 1005, a communication bus 1002. Wherein a communication bus 1002 is used to enable connective communication between these components. The user interface 1003 may include a Display screen (Display), an input unit such as a Keyboard (Keyboard), and the optional user interface 1003 may also include a standard wired interface, a wireless interface. The network interface 1004 may optionally include a standard wired interface, a wireless interface (e.g., WI-FI interface). The memory 1005 may be a high-speed RAM memory or a non-volatile memory (e.g., a magnetic disk memory). The memory 1005 may alternatively be a storage device separate from the processor 1001.

Optionally, the terminal may further include a camera, a Radio Frequency (RF) circuit, a sensor, an audio circuit, a WiFi module, and the like. Such as light sensors, motion sensors, and other sensors. Specifically, the light sensor may include an ambient light sensor that may adjust the brightness of the display screen according to the brightness of ambient light, and a proximity sensor that may turn off the display screen and/or the backlight when the mobile terminal is moved to the ear. As one of the motion sensors, the gravity acceleration sensor can detect the magnitude of acceleration in each direction (generally, three axes), detect the magnitude and direction of gravity when the mobile terminal is stationary, and can be used for applications (such as horizontal and vertical screen switching, related games, magnetometer attitude calibration), vibration recognition related functions (such as pedometer and tapping) and the like for recognizing the attitude of the mobile terminal; of course, the mobile terminal may also be configured with other sensors such as a gyroscope, a barometer, a hygrometer, a thermometer, and an infrared sensor, which are not described herein again.

Those skilled in the art will appreciate that the terminal structure shown in fig. 1 is not intended to be limiting and may include more or fewer components than those shown, or some components may be combined, or a different arrangement of components.

As shown in fig. 1, a memory 1005, which is a kind of computer storage medium, may include therein an operating system, a network communication module, a user interface module, and a driver debugging program.

In the terminal shown in fig. 1, the network interface 1004 is mainly used for connecting to a backend server and performing data communication with the backend server; the user interface 1003 is mainly used for connecting a client (user side) and performing data communication with the client; and the processor 1001 may be configured to call the driver debugger stored in the memory 1005 and perform the following operations:

Further, the processor 1001 may call a driver debugger stored in the memory 1005, and also perform the following operations:

a new debug plug-in is referenced into the command mapping table.

Referring to fig. 2, the present invention provides a driver debug method, and in a first embodiment of the driver debug method of the present invention, the driver debug method includes:

step S10, the debugging plug-in that has realized different debugging commands is referred to the command mapping table in advance.

In this embodiment, the purpose of debugging the driver is achieved by implementing a driver debugging framework, and all debugging commands are abstracted into a plug-in (existing in the form of a dynamic link library). Preferably, the debugging plug-in is implemented by a data structure of a structure body, and the data structure for implementing the debugging plug-in is not limited in this embodiment. The structure body for realizing the debugging plug-in comprises: the executed debugging command ID is the command identification number of the debugging plug-in; executing the function name mapped by the command; the size of the debugging parameter; parameters transmitted to the debugging function; the function that the command implements. The developer driving debugging can realize different debugging commands by rewriting the function, and complete different debugging functions. In addition, the present embodiment also creates a command mapping table to support the implementation of different completed debug commands. A debugging command corresponds to a structure body, namely corresponds to a debugging plug-in, and is quoted into the command mapping table. And each debugging command is realized by a debugging developer through rewriting a function in the structure, so that customized realization is realized.

In this embodiment, the debug commands are divided into two types, one type is a debug-driven command, and the other type is an auxiliary debug command. The drive debugging command maps all common drive debugging operations into standard operation commands to be processed uniformly, and the auxiliary command is used for assisting in debugging or expanding the drive debugging function. For the driving debugging command, the dynamic realization is realized by realizing the function in the debugging plug-in structure body, and only the interface which is interested by the user needs to be realized.

Wherein driving the debug command comprises:

command to open the device: the input command line parameter is O { file/path }, and an open system debugging interface is called;

command to shut down the device: the input command line parameter is C { id }, call close system debug interface;

read device num characters and execute the command of the action following: the input command line parameter is R num action, and a read system debugging interface is called;

a command to write num data to the device, the data supporting integer and floating point: the input command line parameter is W [ num ] [ i/f ] data, and a write system debugging interface is called;

and the command of IO control enables a cmd command to be transmitted into num parameter args, and the subsequent action is executed: the input command line parameter is Iocmd [ num ] [ args ] action, and an ioctls system debugging interface is called;

and modifying num data after mapping the command of memory mapping, and executing the following action: the input command line parameter is Mm length; md [ num ] [ data ] action, calling the mmap system debugging interface;

command to unmap: the input command line parameter is Um length, and a unmap system debugging interface is called;

monitoring equipment at intervals of timeout seconds by monitoring the command of the equipment, and executing do _ action if an event occurs; otherwise, do _ timeout is performed: the input command line parameter is PI [ timeout ]? do _ timeout; do _ action, calling an epoll system debugging interface;

command of action of event of monitoring file or folder: the input command line parameter is Ino [ path ] action, and an inotify system debugging interface is called;

monitoring hot plug events, and executing corresponding action commands: the input command line parameter is Ev [ action _ type ] action, and an events system debugging interface is called.

Wherein the auxiliary command comprises:

debugging and quitting commands: calling a quick system debugging interface when the input command line parameter is q;

and loading the command of the plug-in where the path is located: the input command line parameter is Load { path }, and a Load system debugging interface is called;

help information command: calling a help system debugging interface when the input command line parameter is h;

and directly executing the command of the action method: the input command line parameter is Map { action } { args }, and a Map system debugging interface is called;

and automatically generating a command corresponding to the c language code and the test code by executing the successful instruction: the input command line parameter is Demo { file/path }, and a Demo system debugging interface is called.

Step S20, after traversing all the existing debugging plug-ins, obtaining the input of the command line, and analyzing the command line to obtain the command field and the parameter field.

In this embodiment, the debug commands are divided into two types, and the input of the command line is exemplified by taking an open device command in the drive debug command as an example. After a debugging developer inputs a command line O { file/path }, the system automatically calls an open debugging interface to open the file device, and traverses all debugging plugins in the path by using a load _ plugins interface. Then, the debugging developer inputs' ID: 3,100 ", after parsing the command line, the ID: command field of 3 and parameter field of 100, by ID: the command of 3 matches the debugging plug-in with the command identification number of 3 in the command mapping table, and transmits the parameter 100 to the function of the debugging plug-in with the command identification number of 3 to execute the corresponding debugging function. Or in a command line input by a debugging developer, only if the command has no parameter, the function which is matched with the command and realizes no parameter is directly called. Or if the command line input by the debugging developer has a plurality of parameters, the functional function which is matched with the command and realizes the corresponding number of parameters is called.

Step S30, matching the command field with the command identification number of the debugging plug-in, if matching, automatically calling the system interface to load the target debugging plug-in corresponding to the command identification number from the command mapping table, and transmitting the parameter field to the target debugging plug-in to execute the debugging operation.

In the actual driver debugging process, step S20 parses the command line input by the debugging developer to obtain a command field and a parameter field, and when the command matches the executed debugging command I D, i.e., the command identification number of the debugging plug-in, the debugging command automatically calls the corresponding system call interface, and then transfers the parameter to the function implementing the command for execution, thereby completing the customized debugging. In this embodiment, the management of automatically calling the corresponding system call interface is implemented by the following method: loading a debugging plug-in according to the file name; or loading a command list defined by the plug-in through loading the path address; or loading a debugging plug-in under a specific path; or loading all debugging plug-ins under the path; or searching the structural body corresponding to the plug-in through a command.

To aid in understanding the execution of debug commands, an explanation is now provided by way of an example below.

For example, a debugging developer initially inputs a file path of a debugging object and a path of a debugging plug-in of a corresponding device in a command line. The debugging program opens a corresponding equipment file according to the transmitted file path of the debugging object, and if the equipment file is network equipment, the network equipment needs to be opened through a socket system debugging interface; if the device file is not a network device, the non-network device is opened using the basic open system debug interface. And then, according to the path of the debugging plug-in of the opened corresponding device, traversing and displaying all the debugging plug-ins in the path directory of the debugging developer by using an interface managed by the plug-in, for example, by using a system debugging interface load _ plugins loading all the plug-ins in the path, so that the debugging developer can select and use the debugging plug-ins. And if all the traversed debugging plug-ins can not realize the debugging function which is supposed to be completed by the debugging developer, allowing the debugging developer to write the function by self-defining to obtain a new debugging plug-in and reference the new debugging plug-in to the command mapping table. If the debugging developer does not transmit the two parameters of the file path of the debugging object and the path of the debugging plug-in for opening the corresponding equipment, the default debugging command is used for realizing the corresponding operation, the basic open system debugging interface is used for opening the non-network equipment, and the load _ plugins system debugging interface is used for loading all the debugging plug-ins under the existing debugging plug-in path. After all debugging plug-ins for realizing related debugging commands are updated in the command mapping table, the input of the command field and the parameter field of the command line of the debugging developer is waited.

In this embodiment, the development of the drivers of different devices is abstracted to the implementation of the function in the debug plug-in, and the pre-implemented debug plug-in is mapped to the command mapping table to implement uniform commands and parameters. Therefore, the first embodiment of the present invention provides a programming mode based on plug-in, which implements a general driver debugging method, reduces repeated development of a certain debugging program, and improves development efficiency of driver debugging. And moreover, a unified debugging instruction and a method are provided, so that the learning and using cost is reduced.

Optionally, the present invention provides a driver debugging method, and in a second embodiment of the driver debugging method of the present invention, the driver debugging method includes:

step A1, when a new debugging command is received, self-defining and writing a function of the debugging plug-in according to the new debugging command to generate a new debugging plug-in;

step A2, the new debug plug-in is referenced to the command mapping table.

When a new debugging command which does not exist in the existing command list is received, a debugging developer needs to self-define and write a function of the debugging plug-in according to the new debugging command so as to generate a new debugging plug-in, and the new debugging plug-in is introduced into the command mapping table.

Or when the command mapping table is empty, that is, when all the debugging plug-ins are not implemented, and at this time, under the condition that the function in the debugging plug-ins is not implemented, before receiving a new debugging command, a debugging developer needs to custom write the function of the debugging plug-ins according to the debugging command to generate a new debugging plug-in, and the new debugging plug-ins are introduced into the command mapping table.

Or when the function needs to be updated or adjusted on the premise that the existing debugging plug-in does not change the debugging command, and also when the received debugging command for realizing different debugging functions is received, the debugging developer re-writes the function of the debugging plug-in according to the debugging command to generate a new debugging plug-in, and the new debugging plug-in is introduced into the command mapping table, so that the updating or the adjustment of the same debugging command is completed.

Further, in the third embodiment of the present invention, the step of writing a function of the debug plug-in according to the new debug command to generate a new debug plug-in includes:

and step B, self-defining writing the function according to the new debugging command and the data format of the preset debugging plug-in, and generating the new debugging plug-in.

When the function of the debugging plug-in is realized, the function in the debugging plug-in needs to be customized according to a preset data format of the debugging plug-in, for example, according to a data format of a structure body for realizing the debugging plug-in (the structure body includes an executed debugging command ID, namely a command identification number of the debugging plug-in, a function name mapped by an execution command, a debugging parameter, a parameter transmitted to a debugging function, and a function realized by the command), that is, a debugging developer writes the function according to the preset data format of the debugging plug-in.

In this embodiment, for different debug commands, the method of completing the debug plug-in by implementing different function functions and referring different debug plug-ins to the command mapping table expands the application scenarios of the driver debug method and improves the usability and universality of the driver debug method.

In a fourth embodiment of the driver debug method of the present invention, after the step of matching the command field with the command identification number of the debug plug-in, the method further includes:

and C, prompting to quote a new debugging plug-in if the debugging plug-ins are not matched or the matched debugging plug-ins cannot realize the debugging command.

When the command obtained by analyzing the input command line is not matched with the command identifier of the existing debugging plug-in, or the matched debugging plug-in cannot realize the obtained debugging command because the number of the parameter fields is not met or the data types of the parameter fields are not met. In this embodiment, the reason why the matched debug plug-in cannot implement the obtained debug command is not limited. Then prompting debugging developers: the existing debugging plug-in has not realized the command line input by the debugging developer, that is, there is no command identifier matching with the command field in the data structure of the existing debugging plug-in, or there is no debugging plug-in which does not conform with the input parameter field in the existing debugging plug-in, or there is no debugging plug-in which conforms with both the input command field and the input parameter field in the existing debugging plug-in.

Further, after the step of prompting to refer to the new debugging plug-in, the method further comprises the following steps:

step D, opening the authority of the reference debugging plug-in, and referencing a new debugging plug-in to a command mapping table, wherein the new debugging plug-in is a matched command field or a debugging plug-in which the debugging command is realized.

After receiving the prompt of referring to the new debugging plug-in, the debugging developer opens the authority of referring to the debugging plug-in so that the debugging developer can further supplement the new debugging plug-in, update or adjust the existing debugging plug-in and refer to the command mapping table. If the debugging developer does not find the debugging plug-in capable of realizing the input debugging command in the existing debugging plug-ins, a new functional function can be rewritten to generate a new debugging plug-in; or updating or adjusting the existing plug-in to generate a new debugging plug-in; or be combined with existing debug plug-ins to implement the debug command. In this embodiment, the implementation method for obtaining the debugging plug-in conforming to the prompt is not limited.

In this embodiment, the permission to refer to the debugging plug-in is opened for the debugging situation that the command is not matched with the command identification number of the debugging plug-in and the matched debugging plug-in cannot realize the obtained debugging command, so that a debugging developer can further perfect a driving debugging frame by referring to a new debugging plug-in which meets the debugging situation again, and the driving debugging method has higher flexibility and higher universality.

In a fifth embodiment of the driver debugging method of the present invention, the step of automatically invoking a system interface to load a target debugging plug-in corresponding to the command identification number from the command mapping table includes:

and step E, acquiring the target debugging plug-in corresponding to the command identification number, and transmitting the parameter field to a function of the target debugging plug-in to execute debugging operation.

When the command obtained by analyzing the input command line is matched with the command identifier of the existing debugging plug-in, the debugging program automatically calls the system interface to traverse all the debugging plug-ins from the command mapping table, loads the debugging plug-ins corresponding to the command identification numbers, transmits the parameters obtained by analyzing the input command line into the function of the debugging plug-ins corresponding to the command identification numbers, and executes the corresponding debugging operation.

Or directly saving the command identifier and the function in the command mapping table, and directly omitting the traversal of the debugging plug-in. When the command obtained by analyzing the input command line is matched with the command identifier stored in the command mapping table, the debugging program automatically transmits the parameter obtained by analyzing the input command line into the functional function corresponding to the command identification number, and executes the corresponding debugging operation.

Further, the step after passing parameters into the function of the corresponding debugging plug-in to perform debugging operations comprises:

step F, if the execution is successful, recording the command field and the parameter field of the command line to a success list;

step G: if the execution fails, the state of waiting for the input of the debugging command is returned.

And establishing a success list in the background of the system, and recording a debugging command corresponding to the successfully executed debugging plug-in to the success list if the successfully executed debugging plug-in exists. Otherwise, returning to the state of waiting for the input of the debugging command, wherein the waiting debugging command is a debugging command corresponding to a new debugging plug-in after the debugging developer supplements, updates or adjusts the debugging plug-in which the execution fails.

Further, the step after the execution is successful further includes:

step F1: and directly converting the recorded success list into corresponding compiling language codes and debugging codes, and integrating the compiling language codes and the debugging codes into a driving debugging development system for secondary development based on debugging.

And automatically generating corresponding C language codes and test codes by using the recorded success list through a demo debugging interface, and integrating the C language codes and the test codes into a development system for driving debugging for secondary development, thereby improving the development efficiency of driving debugging.

In the embodiment, on the basis of realizing the general drive debugging method, the development efficiency of drive debugging is further improved by recording the successfully executed debugging plug-in and debugging command and converting the successfully executed debugging plug-in and debugging command into the code to be integrated into the development system.

In addition, an embodiment of the present invention further provides a driver debug apparatus, where the driver debug apparatus includes: the device comprises a memory, a processor and a driver debugging program which is stored on the memory and can run on the processor, wherein the driver debugging program realizes the steps of the embodiments of the driver debugging method when being executed by the processor.

In addition, an embodiment of the present invention further provides a computer-readable storage medium, where a driver debugger is stored on the computer-readable storage medium, and the driver debugger implements the steps of the embodiments of the driver debugging method when being executed by a processor.

The development content of the specific implementation of the driver debugging device and the computer readable storage medium of the present invention is substantially the same as that of the embodiments of the driver debugging method described above, and will not be described in detail here.

It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or system. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or system that comprises the element.

The above-mentioned serial numbers of the embodiments of the present invention are merely for description and do not represent the merits of the embodiments.

Through the above description of the embodiments, those skilled in the art will clearly understand that the method of the above embodiments can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but in many cases, the former is a better implementation manner. Based on such understanding, the technical solution of the present invention may be embodied in the form of a software product, which is stored in a storage medium (e.g., ROM/RAM, magnetic disk, optical disk) as described above and includes instructions for enabling a terminal device (e.g., a mobile phone, a computer, a server, an air conditioner, or a network device) to execute the method according to the embodiments of the present invention.

The above description is only a preferred embodiment of the present invention, and not intended to limit the scope of the present invention, and all modifications of equivalent structures and equivalent processes, which are made by using the contents of the present specification and the accompanying drawings, or directly or indirectly applied to other related technical fields, are included in the scope of the present invention.

Claims

1. A driving debugging method is characterized by comprising the following steps:

2. The driven debugging method of claim 1, comprising:

a new debug plug-in is referenced into the command mapping table.

3. The driven debugging method of claim 2 wherein the step of custom writing the functional functions of the debugging plug-in according to the new debugging commands to generate a new debugging plug-in comprises:

4. The driven debugging method of claim 1, wherein after the step of matching the command field with the command identification number of the debugging plug-in, further comprising:

5. The driven debugging method of claim 4 wherein, after the step of prompting for reference to a new debugging plug-in, further comprising:

6. The driven debugging method of claim 1, wherein the step of loading, by the auto-call system interface, the target debugging plug-in corresponding to the command identification number from the command mapping table comprises:

7. The driven debugging method of claim 6 wherein the step after passing parameters into the functional function of the target debugging plug-in to perform debugging operations comprises:

8. The driven debugging method of claim 7, wherein the step of performing successfully further comprises:

9. An actuated debugging device characterized in that it comprises: memory, a processor and a driver debugger stored on the memory and executable on the processor, the driver debugger when executed by the processor implementing the steps of the driver debugging method of any of claims 1 to 8.

10. A computer-readable storage medium, having a driver debugger stored thereon, the driver debugger when executed by a processor implementing the steps of the driver debugging method of any of claims 1-8.