Driving debugging method and upper computer, lower computer and driving debugging system based on driving debugging method

Abstract

The invention provides a drive debugging method and an upper computer, a lower computer and a drive debugging system based on the drive debugging method. When the method is applied to the lower computer, the method comprises the following steps: receiving a drive debugging instruction sent by the upper computer; the drive debugging instruction comprises identification information of a to-be-debugged drive interface; searching debugging information matched with the identification information of the to-be-debugged driving interface; under the condition that the debugging information matched with the identification information of the to-be-debugged driving interface is found, the to-be-debugged driving interface is debugged according to the debugging information. According to the method, the debugging efficiency of the driving interface can be effectively improved.

Description

Technical Field

[0001] The present application relates to the field of embedded technology, and in particular to a drive debugging method and a host computer, a slave computer, and a drive debugging system based thereon. Background Art

[0002] An embedded system is a special-purpose computer system that is mainly used to perform specific tasks or control specific devices. In an embedded system, it usually includes a host computer and a slave computer. The host computer usually refers to the main control unit responsible for processing high-level logic, user interaction and external communication, such as a computer or controller. The slave computer usually refers to a microcontroller, single-chip microcomputer, etc. that directly interacts with physical devices and performs real-time control tasks.

[0003] Embedded systems usually require debugging interfaces to provide the required monitoring, fault detection, or performance analysis functions during the development and maintenance of applications, so that the system can run normally or perform performance optimization.

[0004] In the related art, test cases are usually used to debug interfaces. Specifically, debuggers usually design test cases according to application requirements, and then compile the image files corresponding to the test cases and burn them into the lower computer for verification to debug the interface. In this way, if the application requirements change, the test cases need to be redesigned, and the compilation, burning and other operations need to be re-executed, resulting in low debugging efficiency. Summary of the invention

[0005] The purpose of the embodiments of the present application is to provide a driver debugging method and a host computer, a slave computer, and a driver debugging system based thereon, so as to improve the debugging efficiency of the driver interface.

[0006] In the first aspect, an embodiment of the present application provides a driver debugging method, which is applied to a lower computer in an embedded system, and the method includes: receiving a driver debugging instruction sent by a host computer; the driver debugging instruction includes identification information of a driver interface to be debugged; searching for debugging information that matches the identification information of the driver interface to be debugged; and debugging the driver interface to be debugged according to the debugging information when debugging information that matches the identification information of the driver interface to be debugged is found. In this way, the driver debugging instruction can be sent directly to the lower computer by the host computer, so that the lower computer can debug the driver interface to be debugged according to the debugging information that matches the identification information of the driver interface to be debugged. Subsequently, there is no need to use test cases, nor to perform operations such as compiling and burning related to the test cases, which improves the situation where test cases need to be repeatedly modified and operations such as compiling and burning need to be repeatedly performed when application requirements change, thereby effectively improving debugging efficiency.

[0007] Optionally, the lower computer is installed with a target embedded operating system, and the target embedded operating system is integratedly compiled to generate an application program and a driver. Even if the target embedded operating system is installed in the lower computer, it can improve the debugging efficiency of the driver interface to be debugged. Before receiving the driver debugging instruction sent by the upper computer, the method also includes: obtaining a configuration file and a mapping file; the configuration file records the identification information of multiple driver interfaces; the mapping file is generated based on the driver program, and records the calling functions of each driver interface and the address information of each calling function; the identification information of each driver interface, the calling function and the address information are stored in the driver debugging file in association. Before receiving the driver debugging instruction, the debugging environment can be pre-configured so that the matching debugging information can be more accurately found through the identification information of the driver interface to be debugged.

[0008] Optionally, the searching for debugging information matching the identification information of the driver interface to be debugged includes: searching the driver debugging file for the target calling function and target address information associated with the identification information of the driver interface to be debugged; and debugging the driver interface to be debugged according to the debugging information when debugging information matching the identification information of the driver interface to be debugged is found, including: debugging the driver interface to be debugged according to the target calling function and the target address information when the target calling function and the target address information associated with the identification information of the driver interface to be debugged are found. In this way, the driver interface to be debugged can be debugged through the target calling function, without the need to perform operations such as compilation and burning, thereby simplifying the operation process and improving debugging efficiency.

[0009] Optionally, debugging the driver interface to be debugged according to the target calling function and the target address information includes: calling the target calling function through a target pointer pointing to the target address information to debug the driver interface to be debugged. In this way, the lower computer can call the target calling function through the target pointer, thereby improving the access rate and improving the debugging efficiency to a certain extent.

[0010] Optionally, after obtaining the configuration file and the mapping file, the method further includes: if the mapping file meets the legality verification requirements, verifying whether the configuration file meets the compliance requirements; the verification of whether the configuration file meets the compliance requirements includes: if there is no call function and address information corresponding to the identification information of each driver interface recorded in the configuration file in the mapping file, determining that the configuration file does not meet the compliance requirements. In this way, the mapping file and the configuration file can be verified to make the pre-configured debugging environment more complete.

[0011] Optionally, the verifying whether the configuration file meets the compliance requirements further includes: if the file type of the configuration file is not a preset file type, determining that the configuration file does not meet the compliance requirements; the preset file type is a file type that can be executed by the application. In this way, it is possible to determine whether the configuration file meets the compliance requirements by the file type of the configuration file, so that the subsequent verification operation can be stopped when the file type is not compliant, thereby improving the verification efficiency to a certain extent.

[0012] In the second aspect, the embodiment of the present application provides a driver debugging method, which is applied to a host computer in an embedded system, and the method includes: receiving identification information of a driver interface to be debugged; sending a driver debugging instruction to a lower computer according to the identification information of the driver interface to be debugged; the driver debugging instruction is used to instruct the lower computer to search for debugging information that matches the identification information of the driver interface to be debugged; when debugging information that matches the identification information of the driver interface to be debugged is found, debugging the driver interface to be debugged according to the debugging information. In this way, there is no need to use test cases, nor to perform operations such as compiling and burning related to test cases, which improves the situation where test cases need to be repeatedly modified and operations such as compiling and burning need to be repeatedly performed when application requirements change, thereby effectively improving debugging efficiency.

[0013] On the third aspect, the embodiment of the present application provides a lower computer in an embedded system, the lower computer comprising: an instruction receiving module for receiving a driver debugging instruction sent by a host computer; the driver debugging instruction includes identification information of a driver interface to be debugged; a search module for finding debugging information that matches the identification information of the driver interface to be debugged; and a debugging module for debugging the driver interface to be debugged according to the debugging information when debugging information that matches the identification information of the driver interface to be debugged is found. In this way, there is no need to use test cases, nor to perform operations such as compiling and burning related to the test cases, which improves the situation where test cases need to be repeatedly modified and operations such as compiling and burning need to be repeatedly performed when application requirements change, thereby effectively improving debugging efficiency.

[0014] In the fourth aspect, the embodiment of the present application provides a host computer in an embedded system, the host computer comprising: an information receiving module for receiving identification information of a driver interface to be debugged; an instruction sending module for sending a driver debugging instruction to a lower computer according to the identification information of the driver interface to be debugged; the driver debugging instruction is used to instruct the lower computer to search for debugging information that matches the identification information of the driver interface to be debugged; when debugging information that matches the identification information of the driver interface to be debugged is found, the driver interface to be debugged is debugged according to the debugging information. In this way, there is no need to use test cases, nor to perform operations such as compiling and burning related to test cases, which improves the situation where test cases need to be repeatedly modified and operations such as compiling and burning need to be repeatedly performed when application requirements change, thereby effectively improving debugging efficiency.

[0015] In a fifth aspect, an embodiment of the present application provides a driver debugging system, including: a host computer, for receiving identification information of a driver interface to be debugged; and sending a driver debugging instruction to a lower computer according to the identification information of the driver interface to be debugged; and a lower computer, for debugging the driver interface to be debugged according to the method described in the first aspect. In this way, there is no need to use test cases, nor to perform compiling, burning and other operations related to the test cases, which improves the situation where test cases need to be repeatedly modified and operations such as compiling and burning need to be repeatedly performed when application requirements change, thereby effectively improving debugging efficiency.

[0016] In a sixth aspect, an embodiment of the present application provides an electronic device, comprising a processor and a memory, wherein the memory stores computer-readable instructions, and when the computer-readable instructions are executed by the processor, the steps in the method provided in the first aspect or the second aspect are executed.

[0017] In a seventh aspect, an embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the steps of the method provided in the first aspect or the second aspect are performed.

[0018] Other features and advantages of the present application will be described in the following description, and partly become apparent from the description, or be understood by practicing the embodiments of the present application. The purpose and other advantages of the present application can be realized and obtained by the structures specifically pointed out in the written description, claims, and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments of the present application will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0020] Figure 1 A flowchart of a drive debugging method applied to a lower computer provided in an embodiment of the present application;

[0021] Figure 2 A flowchart of a drive debugging method applied to a host computer provided in an embodiment of the present application;

[0022] Figure 3 A structural block diagram of a lower computer provided in an embodiment of the present application;

[0023] Figure 4 A structural block diagram of a host computer provided in an embodiment of the present application;

[0024] Figure 5 A structural block diagram of a drive debugging system provided in an embodiment of the present application;

[0025] Figure 6 A schematic diagram of the structure of an electronic device for executing a drive debugging method provided in an embodiment of the present application. DETAILED DESCRIPTION

[0026] The technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all of the embodiments. The components of the embodiments of the present application described and shown in the drawings here can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the application claimed for protection, but merely represents the selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without making creative work belong to the scope of protection of the present application.

[0027] It should be noted that similar reference numerals and letters represent similar items in the following drawings, so once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings. At the same time, in the description of this application, the terms "first", "second", etc. are only used to distinguish the description and cannot be understood as indicating or implying relative importance.

[0028] It should be noted that the embodiments in this application or the technical features in the embodiments may be combined if there is no conflict.

[0029] In the related art, there is a problem of low debugging efficiency when debugging a driver interface in an embedded system; in order to solve this problem, the present application provides a driver debugging method and a host computer, a slave computer, and a driver debugging system based thereon; further, the host computer sends a driver debugging instruction to the slave computer to instruct the slave computer to debug the driver interface to be debugged using pre-configured debugging information according to the driver debugging instruction. In this way, there is no need to use test cases, nor to perform operations such as compiling and burning related to the test cases, thereby effectively improving the debugging efficiency.

[0030] The defects existing in the solutions in the above-mentioned related technologies are the results obtained by the inventor after practice and careful research. Therefore, the discovery process of the above-mentioned problems and the solutions proposed in the embodiments of the present invention below for the above-mentioned problems should all be the contributions made by the inventor to the present invention during the process of the present invention.

[0031] In some application scenarios, the above driver debugging method can be applied to a lower computer in an embedded system. The above lower computer can include, for example, smart home devices, industrial automation equipment, etc.

[0032] Please refer to Figure 1 , which shows a flow chart of a driver debugging method provided by an embodiment of the present application. Figure 1 As shown, the drive debugging method includes the following steps 101 to 103.

[0033] Step 101, the lower computer receives a driver debugging instruction sent by the upper computer; the driver debugging instruction includes identification information of the driver interface to be debugged;

[0034] The host computer may include, for example, a desktop computer, a laptop computer, or other device that can substantially exchange information with the slave computer. In some application scenarios, the host computer may be connected to the slave computer via a serial port, for example, to achieve information exchange.

[0035] The above-mentioned driver interface to be debugged is also an interface to be debugged and used to realize the driver function.

[0036] The above-mentioned driver debugging instruction is also an instruction for instructing the lower computer to debug the driver interface to be debugged. It may include the identification information of the driver interface to be debugged and related instruction information. Among them, the identification information of the driver interface to be debugged is used to identify the driver interface to be debugged, which may include, for example, the name and number of the driver interface to be debugged. The above-mentioned related instruction information is used to indicate how to debug the driver interface to be debugged, which may include, for example, parameters representing the debugging content, parameters representing the debugging requirements, etc. The above-mentioned parameters representing the debugging content may be, for example, "write ABC", and the parameters representing the debugging requirements may be, for example, that 2 parameters need to be input, and both parameters are integers, etc.

[0037] In some application scenarios, the host computer can receive the identification information of the driver interface to be debugged and the related instruction information input by the operator, thereby automatically or according to the instructions generated by the operator to generate the above-mentioned driver debugging instructions. In other application scenarios, the host computer can also actively obtain the driver interface information corresponding to the application when the application is installed, so as to obtain the identification information of the driver interface to be debugged from the driver interface information and generate the corresponding driver debugging instructions.

[0038] Then, the upper computer can send the drive debugging instruction to the lower computer. In some application scenarios, the lower computer can also verify the relevant information in the drive debugging instruction. Specifically, the lower computer can, for example, parse the number of input parameters from the drive debugging instruction, and then determine whether the number of input parameters is the same as the preset number of parameters. If not, it can be regarded as the drive debugging instruction is abnormal, or the lower computer can also parse whether the parameter type is an integer. If not, it can also be regarded as the drive debugging instruction is abnormal, so that a prompt message can be output to remind the operator to adjust the drive debugging instruction in time.

[0039] Step 102, the lower computer searches for debugging information that matches the identification information of the drive interface to be debugged;

[0040] The above debugging information is also the relevant information for debugging the driver interface to be debugged, which may include, for example, the calling function of the driver interface to be debugged, the precautions for using the calling function, the calling path of the calling function, the calling timing, the debugging log and other information.

[0041] In some application scenarios, after receiving the driver debugging instruction, the lower computer can search locally for debugging information that matches the identification information of the driver interface to be debugged. In these application scenarios, the lower computer can obtain the identification information of multiple driver interfaces and the debugging information corresponding to each driver interface in advance, so that after receiving the driver debugging instruction, it can search for the corresponding debugging information according to the identification information of the driver interface to be debugged. Among them, the lower computer can obtain the identification information of each driver interface and the corresponding debugging information from the upper computer to improve the adaptability of the information in the upper computer and the lower computer.

[0042] Step 103 : when the lower computer finds debugging information matching the identification information of the drive interface to be debugged, the lower computer debugs the drive interface to be debugged according to the debugging information.

[0043] In some application scenarios, after the lower computer obtains the identification information of multiple drive interfaces and the debugging information corresponding to each drive interface, it can associate and store the association relationship between the identification information and the corresponding debugging information. In this way, if the lower computer finds the debugging information associated with the identification information of the drive interface to be debugged, it can be regarded as a match between the two. Alternatively, if the lower computer finds the identification information of the drive interface to be debugged, it can be regarded as the debugging information associated with the identification information of the drive interface to be debugged exists locally, and then the two can also be regarded as a match.

[0044] In these application scenarios, the lower computer can debug the driver interface to be debugged according to the debug information found. Specifically, it can judge whether the driver interface to be debugged can work normally after the driver interface to be debugged performs the same operation as the historical debug operation through the historical debug operation recorded in the debug log and the state of the debug interface under the historical debug operation.

[0045] In this implementation, the upper computer can directly send a driver debugging instruction to the lower computer, so that the lower computer can debug the driver interface to be debugged according to the debugging information that matches the identification information of the driver interface to be debugged. In this way, there is no need to use test cases, nor to perform compiling, burning and other operations related to the test cases, which improves the situation where the test cases need to be repeatedly modified and the compiling, burning and other operations need to be repeatedly performed when the application requirements change, thereby effectively improving the debugging efficiency.

[0046] In some application scenarios, after the lower computer debugs the drive interface to be debugged, the debugging result can also be fed back to the upper computer so that the upper computer or the operator can know the debugging situation.

[0047] In some optional implementations, a target embedded operating system is installed in the lower computer, and the target embedded operating system is compiled to generate an application program and a driver program in an integrated manner.

[0048] In some application scenarios, in order to improve the response rate of the lower computer, the lower computer can install a target embedded operating system with a small storage capacity (such as 1 megabyte, 2 megabytes, etc.), and can bundle and store various information through the target embedded operating system. Such information may include, for example, relevant information of the application program, relevant information of the driver program, etc., so that it can be compiled and generated as a whole application program and the driver program. Among them, the lower computer can use, for example, a macro kernel to store various information.

[0049] That is, the above-mentioned target embedded operating system can be regarded as an embedded operating system with small storage capacity and information bundled storage, which can include RT-Thread (real-time thread operating system), ucos (a real-time operating system based on microprocessor), FreeRTOS (embedded real-time operating system), etc.

[0050] In the related art, since the target embedded operating system has a small storage capacity and it stores a variety of information in a bundled manner, it relies more on the operator to debug the driver interface through test cases, resulting in low debugging efficiency. For example, the original process of the application is write, read, write, read; then, the process now needs to be modified to a one-time write followed by a unified read. The operator needs to modify the read and write process in the test case, and then recompile and burn it into the lower computer before debugging the relevant driver interface. Alternatively, if the application needs to change the original parameter A to parameter B, the operator also needs to modify the parameters in the test case, and then recompile and burn it into the lower computer before debugging the relevant driver interface. This will result in low debugging efficiency.

[0051] In this implementation, since the lower computer does not need to use test cases or perform compilation, burning and other operations related to the test cases, even if the target embedded operating system is installed in the lower computer, it can debug the debug driver interface through steps 101 to 103 as described above, thereby improving debugging efficiency.

[0052] Furthermore, before the lower computer receives the drive debugging instruction sent by the upper computer, the method further includes:

[0053] Step 1, the lower computer obtains a configuration file and a mapping file; the configuration file records identification information of multiple drive interfaces; the mapping file is generated based on the driver program and records the calling functions of each drive interface and the address information of each calling function;

[0054] The above configuration file can be configured by an operator according to application requirements, and in addition to recording the identification information of the drive interface, it can also record interface parameters used to transmit data or instructions and the index, type and value of each interface parameter.

[0055] The mapping file is generated by the driver, and contains the call functions corresponding to each driver interface and the address information corresponding to each call function. In this way, since the mapping file is directly generated by the driver, the adaptability between the driver interface, the call function and the location information is improved to a certain extent.

[0056] In some application scenarios, the lower computer may actively obtain the above configuration files and mapping files from the upper computer; or the upper computer may actively send them to the lower computer, which is not limited here.

[0057] Step 2: The lower computer stores the identification information of each drive interface, the calling function and the address information in a drive debugging file in an associated manner.

[0058] In some application scenarios, the lower computer may associate and store the identification information of each driver interface, the calling function of the driver interface, and the location information of the calling function in the driver debugging file, so that the other two can be found through one of them later.

[0059] In this implementation, before receiving the driver debugging instruction, the debugging environment can be pre-configured (ie, the information in the configuration file and the mapping file are stored in association), so that matching debugging information can be more accurately found through the identification information of the driver interface to be debugged.

[0060] In some optional implementations, the step of searching for debugging information matching the identification information of the driver interface to be debugged in step 102 includes: the lower computer searching the driver debugging file for target calling function and target address information associated with the identification information of the driver interface to be debugged;

[0061] In some application scenarios, after the host computer obtains the driver debugging file, it can find the target calling function and target address information associated with the driver interface to be debugged based on the association between the driver interface identification information, the calling function and the address information of the calling function. The debugging information here refers to the target calling function and target address information.

[0062] In this way, when the lower computer described in the above step 103 finds the debugging information that matches the identification information of the driver interface to be debugged, it debugs the driver interface to be debugged according to the debugging information, including: when the lower computer finds the target calling function and target address information associated with the identification information of the driver interface to be debugged, it debugs the driver interface to be debugged according to the target calling function and the target address information.

[0063] That is to say, after finding the target calling function and the target address information, the lower computer can call the target calling function from the location indicated by the target address information, so as to debug the driver interface to be debugged.

[0064] In this implementation, the driver interface to be debugged can be debugged by calling the target function, thereby eliminating the need to perform operations such as compilation and burning, thereby simplifying the operation process and improving debugging efficiency.

[0065] In some optional implementations, the lower computer debugs the driver interface to be debugged according to the target calling function and the target address information, including: the lower computer calls the target calling function through a target pointer pointing to the target address information to debug the driver interface to be debugged.

[0066] In some application scenarios, after finding the target address information, the lower computer can convert it into a function pointer, which is also the above-mentioned target pointer. In this way, the lower computer can call the above-mentioned target calling function through the target pointer.

[0067] In other application scenarios, the lower computer may also convert each address information in the driver debugging file into a corresponding function pointer, and then store each address information and its corresponding function pointer in association. In this way, after finding the target address information, the lower computer may determine the function pointer corresponding to the target address information as the above target pointer.

[0068] In this implementation, the lower computer can call the target calling function through the target pointer, thereby improving the access rate and improving the debugging efficiency to a certain extent.

[0069] In some optional implementations, after the lower computer in step 1 acquires the configuration file and the mapping file, the method further includes: the lower computer verifies whether the configuration file meets the compliance requirement if the mapping file meets the legality verification requirement;

[0070] In some application scenarios, after obtaining the configuration file and the mapping file, the lower computer can perform a validity check on both. In these application scenarios, since the mapping file is directly generated by the driver, its accuracy is relatively high, so only conventional validity check operations such as file name check, file size check, and file content check can be performed on it. Then, the above-mentioned validity check requirements can include, for example, that the file name is named in a preset format, the file size is within a preset range, and there are no abnormal characters in the file content.

[0071] Then, if the mapping file meets the legality verification requirements, the lower computer can continue to verify whether the configuration file meets the compliance requirements. The above compliance requirements may include, for example, whether the interface parameters in the configuration file are preset integers, whether the interface names are named in a preset format, etc.

[0072] In some application scenarios, the lower computer may determine that the configuration file does not meet the compliance requirements when the mapping file does not contain the calling function and address information corresponding to the identification information of each driver interface recorded in the configuration file.

[0073] In some application scenarios, since the mapping file is generated by the driver program and contains debugging information for multiple driver interfaces, for each driver interface identification information in the configuration file, if the mapping file does not contain a calling function or address information that matches the identification information, then it can be considered that the driver interface cannot be debugged, and the configuration file can be considered to not meet compliance requirements.

[0074] In some application scenarios, when the lower computer determines that the mapping file does not meet the legality verification requirements or the configuration file does not meet the compliance requirements, the abnormal situation can be fed back to the upper computer so that the upper computer can handle the abnormal situation in time.

[0075] In some application scenarios, the lower computer can also parse the mapping file and the configuration file. For example, the lower computer can obtain the calling function from the mapping file and determine whether the parameters corresponding to the calling function are correct; and obtain the name of the driver interface from the configuration file and determine whether the name is spelled correctly. If the lower computer determines that the parsed content of the mapping file and / or configuration file is incorrect, it can also provide feedback to the upper computer.

[0076] In this implementation, the mapping file and the configuration file may be verified to make the pre-configured debugging environment more complete.

[0077] In some optional implementations, the lower computer verifies whether the configuration file meets the compliance requirements, and also includes: the lower computer determines that the configuration file does not meet the compliance requirements when the file type of the configuration file is not a preset file type; the preset file type is a file type that the application can execute.

[0078] The above-mentioned preset file types are file types that meet the compliance requirements, and may include XML file types, json file types, etc.

[0079] In some application scenarios, if the file type that can be executed by the application in the lower computer is an XML file, then if the file type of the configuration file is a json file, it can be considered that it does not meet the compliance requirements.

[0080] In this implementation, whether the file type of the configuration file meets the compliance requirements can be determined, so that subsequent verification operations can be stopped when the file type is not compliant, thereby improving the verification efficiency to a certain extent.

[0081] Please refer to Figure 2 , which shows a flow chart of a driver debugging method provided by an embodiment of the present application, and the driver debugging method is applied to a host computer in an embedded system. Figure 2 As shown, the drive debugging method includes the following steps 201 to 202.

[0082] Step 201, receiving identification information of a driver interface to be debugged;

[0083] Step 202: Send a drive debugging instruction to the lower computer according to the identification information of the drive interface to be debugged; the drive debugging instruction is used to instruct the lower computer to search for debugging information that matches the identification information of the drive interface to be debugged; when debugging information that matches the identification information of the drive interface to be debugged is found, debug the drive interface to be debugged according to the debugging information.

[0084] It should be noted that the implementation process of the above steps 201 to 202 and the technical effects achieved can be Figure 1 The steps in the illustrated embodiments are the same or similar and will not be described in detail here.

[0085] Those skilled in the art will appreciate that, in the above method of a specific embodiment, the order in which the steps are written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of the steps should be determined by their functions and possible internal logic.

[0086] Please refer to Figure 3, which shows a structural block diagram of a lower computer in an embedded system provided by an embodiment of the present application. Each functional module of the lower computer in the embedded system can execute Figure 1 The method embodiment involves various steps.

[0087] Optionally, the lower computer in the above embedded system includes an instruction receiving module 301, a search module 302 and a debugging module 303. The instruction receiving module 301 is used to receive a driver debugging instruction sent by the upper computer; the driver debugging instruction includes identification information of the driver interface to be debugged; the search module 302 is used to search for debugging information matching the identification information of the driver interface to be debugged; the debugging module 303 is used to debug the driver interface to be debugged according to the debugging information when debugging information matching the identification information of the driver interface to be debugged is found.

[0088] Optionally, the lower computer is installed with a target embedded operating system, and the target embedded operating system is integrated and compiled to generate an application program and a driver. The lower computer also includes a debugging preparation module, which is used to: obtain a configuration file and a mapping file before receiving a driver debugging instruction sent by the upper computer; the configuration file records the identification information of multiple driver interfaces; the mapping file is generated based on the driver program, and records the calling functions of each driver interface and the address information of each calling function; the identification information of each driver interface, the calling function and the address information are stored in the driver debugging file in association.

[0089] Optionally, the search module 302 is further used to: search for a target calling function and a target address information associated with the identification information of the driver interface to be debugged in the driver debugging file; and the debugging module 303 is further used to: when the target calling function and the target address information associated with the identification information of the driver interface to be debugged are found, debug the driver interface to be debugged according to the target calling function and the target address information.

[0090] Optionally, the debugging module 303 is further used to: call the target calling function through a target pointer pointing to the target address information to debug the driver interface to be debugged.

[0091] Optionally, the lower computer also includes a verification module, which is used to: after obtaining the configuration file and the mapping file, if the mapping file meets the legality verification requirements, verify whether the configuration file meets the compliance requirements; the verification of whether the configuration file meets the compliance requirements includes: if there is no calling function and address information corresponding to the identification information of each driver interface recorded in the configuration file in the mapping file, determining that the configuration file does not meet the compliance requirements.

[0092] Optionally, the verification module is further used to: determine that the configuration file does not meet the compliance requirement when the file type of the configuration file is not a preset file type; the preset file type is a file type that can be executed by the application.

[0093] It should be noted that those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the lower computer described above can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0094] Please refer to Figure 4 , which shows a structural block diagram of a host computer in an embedded system provided by an embodiment of the present application. Each functional module of the host computer in the embedded system can execute Figure 2 The method embodiment involves various steps.

[0095] Optionally, the host computer includes an information receiving module 401 and an instruction sending module 402. The information receiving module 401 is used to receive identification information of the drive interface to be debugged; the instruction sending module 402 is used to send a drive debugging instruction to the lower computer according to the identification information of the drive interface to be debugged; the drive debugging instruction is used to instruct the lower computer to search for debugging information matching the identification information of the drive interface to be debugged; when debugging information matching the identification information of the drive interface to be debugged is found, the drive interface to be debugged is debugged according to the debugging information.

[0096] It should be noted that those skilled in the art can clearly understand that for the convenience and brevity of description, the specific working process of the host computer described above can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0097] Please refer to Figure 5 , which shows a structural block diagram of a driver debugging system provided by an embodiment of the present application, and the driver debugging system may include an upper computer 501 and a lower computer 502. The upper computer 501 is used to receive identification information of the driver interface to be debugged; and send a driver debugging instruction to the lower computer according to the identification information of the driver interface to be debugged; the lower computer 502 is used to Figure 1Each step in the method embodiment debugs the drive interface to be debugged.

[0098] It should be noted that those skilled in the art can clearly understand that for the convenience and brevity of description, the specific working process of the drive debugging system described above can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0099] Please refer to Figure 6 , Figure 6 A structural diagram of an electronic device for executing a drive debugging method provided in an embodiment of the present application, the electronic device may include: at least one processor 601, such as a CPU, at least one communication interface 602, at least one memory 603 and at least one communication bus 604. Among them, the communication bus 604 is used to realize direct connection and communication between these components. Among them, the communication interface 602 of the device in the embodiment of the present application is used to communicate signaling or data with other node devices. The memory 603 can be a high-speed RAM memory or a non-volatile memory (non-volatile memory), such as at least one disk storage. The memory 603 can optionally also be at least one storage device located away from the aforementioned processor. Computer-readable instructions are stored in the memory 603. When the computer-readable instructions are executed by the processor 601, the electronic device can execute the above-mentioned Figure 1 The method process is shown.

[0100] Understandably, Figure 6 The structure shown is for illustration only, and the electronic device may also include Figure 6 More or fewer components as shown, or with Figure 6 Different configurations shown. Figure 6 Each component shown in the figure can be implemented by hardware, software or a combination thereof.

[0101] The present application embodiment provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the following can be performed: Figure 1 The method process in the method embodiment shown is executed by the electronic device.

[0102] An embodiment of the present application provides a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium, and the computer program includes program instructions. When the program instructions are executed by a computer, the computer can execute the methods provided by the above-mentioned method embodiments. For example, the method may include: receiving a driver debugging instruction sent by a host computer; the driver debugging instruction includes identification information of a driver interface to be debugged; searching for debugging information that matches the identification information of the driver interface to be debugged; and when debugging information that matches the identification information of the driver interface to be debugged is found, debugging the driver interface to be debugged according to the debugging information.

[0103] In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some communication interfaces, and the indirect coupling or communication connection of the devices or units can be electrical, mechanical or other forms.

[0104] In addition, the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0105] Furthermore, the functional modules in the various embodiments of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.

[0106] In this document, relational terms such as first and second, etc. are used merely to distinguish one entity or operation from another entity or operation, but do not necessarily require or imply any such actual relationship or order between these entities or operations.

[0107] The above description is only an embodiment of the present application and is not intended to limit the protection scope of the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A drive debugging method, characterized in that: Applied to a lower computer in an embedded system, the method comprises: Receiving a drive debugging instruction sent by a host computer; the drive debugging instruction includes identification information of the drive interface to be debugged; Searching for debugging information that matches the identification information of the driver interface to be debugged; When debugging information matching the identification information of the drive interface to be debugged is found, the drive interface to be debugged is debugged according to the debugging information.

2. The method according to claim 1, characterized in that The lower computer is installed with a target embedded operating system, and the target embedded operating system is compiled to generate an application program and a driver program in an integrated manner; as well as Before receiving the drive debugging instruction sent by the host computer, the method further includes: Obtaining a configuration file and a mapping file; the configuration file records identification information of multiple driver interfaces; the mapping file is generated based on the driver program and records the calling functions of each driver interface and the address information of each calling function; The identification information of each driver interface, the calling function and the address information are stored in a driver debugging file in association with each other.

3. The method according to claim 2, characterized in that The searching for debugging information matching the identification information of the driver interface to be debugged includes: Searching the driver debugging file for target calling functions and target address information associated with the identification information of the driver interface to be debugged; and The step of debugging the driver interface to be debugged according to the debugging information when the debugging information matching the identification information of the driver interface to be debugged is as follows: When the target calling function and the target address information associated with the identification information of the driver interface to be debugged are found, the driver interface to be debugged is debugged according to the target calling function and the target address information.

4. The method according to claim 3, characterized in that The debugging of the driver interface to be debugged according to the target calling function and the target address information includes: The target calling function is called through a target pointer pointing to the target address information to debug the driver interface to be debugged.

5. The method according to claim 2, characterized in that: After obtaining the configuration file and the mapping file, the method further includes: If the mapping file meets the legality verification requirements, verify whether the configuration file meets the compliance requirements; Wherein, verifying whether the configuration file meets the compliance requirements includes: When the mapping file does not contain the calling function and address information corresponding to the identification information of each driver interface recorded in the configuration file, it is determined that the configuration file does not meet the compliance requirement.

6. The method according to claim 5, characterized in that The verifying whether the configuration file meets the compliance requirements further includes: In a case where the file type of the configuration file is not a preset file type, it is determined that the configuration file does not meet the compliance requirement; the preset file type is a file type that can be executed by the application.

7. A driver debugging method, characterized in that: Applied to a host computer in an embedded system, the method comprises: Receive identification information of the driver interface to be debugged; A drive debugging instruction is sent to a lower computer according to the identification information of the drive interface to be debugged; the drive debugging instruction is used to instruct the lower computer to search for debugging information that matches the identification information of the drive interface to be debugged; when debugging information that matches the identification information of the drive interface to be debugged is found, the drive interface to be debugged is debugged according to the debugging information.

8. A lower computer in an embedded system, characterized in that: The lower computer comprises: The instruction receiving module is used to receive the drive debugging instruction sent by the host computer; the drive debugging instruction includes the identification information of the drive interface to be debugged; A search module, used to search for debugging information matching the identification information of the driver interface to be debugged; The debugging module is used to debug the driver interface to be debugged according to the debugging information when debugging information matching the identification information of the driver interface to be debugged is found.

9. A host computer in an embedded system, characterized in that: The host computer comprises: An information receiving module, used for receiving identification information of the driver interface to be debugged; An instruction sending module is used to send a drive debugging instruction to a lower computer according to the identification information of the drive interface to be debugged; the drive debugging instruction is used to instruct the lower computer to search for debugging information that matches the identification information of the drive interface to be debugged; when debugging information that matches the identification information of the drive interface to be debugged is found, debug the drive interface to be debugged according to the debugging information.

10. A drive debugging system, characterized in that: include: The host computer is used to receive the identification information of the drive interface to be debugged; and sending a drive debugging instruction to a lower computer according to the identification information of the drive interface to be debugged; A lower computer is used to debug the drive interface to be debugged according to the method described in any one of claims 1 to 6.

11. An electronic device, characterized in that: The method comprises a processor and a memory, wherein the memory stores computer-readable instructions. When the computer-readable instructions are executed by the processor, the method according to any one of claims 1 to 6 or 7 is executed.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 6 or 7 is performed.

Images