Embedded software testing method and device

Abstract

The invention discloses an embedded software testing method and device, and the method comprises the steps: determining a suspected fault point of an embedded software project in a whole code period, determining the address of the suspected fault point, judging whether the embedded software project has a communication interface, obtaining a judgment result, and carrying out the testing of the embedded software according to an issuing mode corresponding to the judgment result. The address is issued to the micro-control unit, so that the micro-control unit returns data corresponding to the address, the address, the name of the suspected fault point and the data have a corresponding relation, and the data corresponding to the address is returned to the client.

Description

Technical Field

[0001] The present application relates to the field of embedded software processing technology, and more specifically, to an embedded software testing method and device. Background Art

[0002] Usually in the field of embedded software, before the code development, debugging and testing phase, it is necessary to identify the problem point first, and then analyze the problem point. During the analysis process, the corresponding variables may need to be printed. At this time, the source code needs to be modified to reproduce or eliminate the fault. If the source code modification is effective, the problem point is located.

[0003] Since the above process requires changing the source code, the debugging process of the embedded software is complicated, resulting in low efficiency in debugging and testing of the embedded software.

[0004] Therefore, how to improve the efficiency of debugging and testing of embedded software is a problem that needs to be solved urgently in this application. Summary of the invention

[0005] In view of this, the present application discloses an embedded software testing method and device, aiming to improve the testing and debugging efficiency of embedded software.

[0006] In order to achieve the above purpose, the disclosed technical solution is as follows:

[0007] The first aspect of the present application discloses an embedded software testing method, the method comprising:

[0008] Determine suspected fault points of the embedded software project throughout the entire code cycle, and determine the addresses of the suspected fault points;

[0009] Determine whether the embedded software project has a communication interface and obtain a determination result;

[0010] According to the sending mode corresponding to the judgment result, the address is sent to the micro control unit, so that the micro control unit returns the data corresponding to the address; wherein there is a corresponding relationship between the address, the name of the suspected fault point and the data;

[0011] The data corresponding to the address is sent back to the client.

[0012] Preferably, determining the suspected fault point of the embedded software project in the entire code cycle and determining the address of the suspected fault point includes:

[0013] During the entire code cycle, when the actual data of the embedded software project is detected to be inconsistent with the preset expected data, the inconsistent data is located to obtain the suspected fault point of the embedded software project;

[0014] Obtain the name of the suspected fault point and determine the type of the suspected fault point;

[0015] By presetting the development environment, in the code-generated project, the address corresponding to the suspected fault point is determined according to the name of the suspected fault point and the type of the suspected fault point.

[0016] Preferably, sending the address to the micro control unit according to the sending mode corresponding to the judgment result so that the micro control unit returns the data corresponding to the address, includes:

[0017] If the embedded software project has a communication interface, the preset debugging command and the preset communication command are integrated into the communication interface, and the address is sent to the micro control unit through the communication interface, so that the micro control unit returns the data corresponding to the address;

[0018] Transmitting the data corresponding to the address back to the client through the preset communication interface;

[0019] If the embedded software project does not have a communication interface, the address is sent to the micro control unit through a dedicated debugging command and a dedicated test interface, so that the micro control unit returns the data corresponding to the address and transmits the data corresponding to the address back to the client.

[0020] Preferably, if the embedded software project has a communication interface, the preset debugging command and the preset communication command are integrated into the communication interface, and the address is sent to the micro control unit through the communication interface so that the micro control unit returns the data corresponding to the address, including:

[0021] Determine whether the embedded software project has a communication interface and the address type of the address; wherein the address type includes at least a variable address or a register address;

[0022] If the embedded software project has a communication interface, and the address type of the address is a variable address, integrating a preset debugging command and a preset communication command;

[0023] The variable address is sent to the micro control unit through the communication interface and the integrated command, so that the micro control unit obtains the data pointed to by the variable address through pointer reference;

[0024] If the embedded software project has a communication interface and the address type of the address is a register address, the register address is sent to the microcontroller unit through the communication interface and the integrated command, so that the microcontroller unit obtains the hexadecimal data and decimal data pointed to by the register address through pointer reference.

[0025] Preferably, if the embedded software project does not have a communication interface, the address is sent to the micro control unit through a dedicated debugging command and a dedicated test interface, so that the micro control unit returns the data corresponding to the address, and transmits the data corresponding to the address back to the client, including:

[0026] If the embedded software project does not have a communication interface, and the address type of the address is a variable address, the variable address is sent to the microcontroller unit through a dedicated debugging command and a dedicated test interface, so that the microcontroller unit obtains the variable name pointed to by the variable address through a pointer reference; wherein the debugging command is a command that has no effect on the project function during the communication process;

[0027] If the embedded software project does not have a communication interface and the address type of the address is a register address, the register address is sent to the microcontroller unit through a dedicated debugging command and a dedicated test interface, so that the microcontroller unit obtains the hexadecimal data and decimal data pointed to by the register address through a pointer reference.

[0028] Preferably, it also includes:

[0029] If it is detected that the connection between the micro control unit and the client is unsuccessful, the micro control unit and the client are connected via an intermediate forwarding device.

[0030] A second aspect of the present application discloses an embedded software testing device, the device comprising:

[0031] A determination unit, used to determine suspected fault points of the embedded software project in the entire code cycle, and determine the addresses of the suspected fault points;

[0032] A judgment unit, used to judge whether the embedded software project has a communication interface and obtain a judgment result;

[0033] A sending unit, used for sending the address to the micro control unit according to the sending mode corresponding to the judgment result, so that the micro control unit returns the data corresponding to the address; wherein there is a corresponding relationship between the address, the name of the suspected fault point and the data;

[0034] The return unit is used to return the data corresponding to the address to the client.

[0035] Preferably, the determining unit includes:

[0036] A positioning module is used to locate the inconsistent data during the entire code cycle when the actual data of the embedded software project is inconsistent with the preset expected data, so as to obtain the suspected fault point of the embedded software project;

[0037] A first acquisition module is used to obtain the name of the suspected fault point and determine the type of the suspected fault point;

[0038] The second acquisition module is used to determine the address corresponding to the suspected fault point according to the name of the suspected fault point and the type of the suspected fault point in the code-generated project through a preset development environment.

[0039] Preferably, the sending unit includes:

[0040] A first sending module is used for integrating a preset debugging command and a preset communication command into the communication interface if the embedded software project has a communication interface, and sending the address to the micro control unit through the communication interface, so that the micro control unit returns data corresponding to the address;

[0041] A return module, used to return the data corresponding to the address to the client through the preset communication interface;

[0042] The second sending module is used to send the address to the micro control unit through a dedicated debugging command and a dedicated test interface if there is no communication interface in the embedded software project, so that the micro control unit returns the data corresponding to the address and transmits the data corresponding to the address back to the client.

[0043] Preferably, the first sending module includes:

[0044] A judgment submodule, used to judge whether the embedded software project has a communication interface and the address type of the address; wherein the address type at least includes a variable address or a register address;

[0045] An integration submodule, used for integrating a preset debugging command and a preset communication command if the embedded software project has a communication interface and the address type of the address is a variable address;

[0046] A first sending submodule is used to send the variable address to the micro control unit through the communication interface and the integrated command, so that the micro control unit obtains the data pointed to by the variable address through pointer reference;

[0047] The second sending submodule is used to send the register address to the micro control unit through the communication interface and the integrated command if the embedded software project has a communication interface and the address type of the address is a register address, so that the micro control unit obtains the hexadecimal data and decimal data pointed to by the register address through a pointer reference.

[0048] Through the above technical scheme, it can be known that the present application discloses an embedded software testing method and device. In the entire code cycle, the suspected fault point of the embedded software project is determined, and the address of the suspected fault point is determined, and it is judged whether the embedded software project has a communication interface, and the judgment result is obtained. According to the corresponding issuing method of the judgment result, the address is issued to the micro control unit, so that the micro control unit returns the data corresponding to the address, wherein there is a corresponding relationship between the address, the name of the suspected fault point and the data, and the data corresponding to the address is transmitted back to the client. Through the above scheme, there is no need to print the corresponding variables during the analysis process to modify the source code to reproduce or eliminate the fault. It is only necessary to send the address of the suspected fault point obtained to the micro control unit, and locate the variable data or register data pointed to by the address of the suspected fault point, so as to test and debug the variable data or register data later. Since only the address is operated, the read content is not distinguished, so the space occupied is relatively small, thereby improving the testing and debugging efficiency of embedded software. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0050] Figure 1 A flowchart of an embedded software testing method disclosed in an embodiment of the present application;

[0051] Figure 2 This is a schematic diagram of variable data disclosed in the embodiments of this application;

[0052] Figure 3 A schematic diagram of register data disclosed in an embodiment of the present application;

[0053] Figure 4 A schematic diagram of the structure of an embedded software testing device disclosed in an embodiment of the present application;

[0054] Figure 5 This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of the present application. DETAILED DESCRIPTION

[0055] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0056] In this application, the terms "comprises", "comprising" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprising a ..." does not exclude the presence of other identical elements in the process, method, article or device comprising the element.

[0057] As can be seen from the background technology, usually in the field of embedded software, before the code development, debugging and testing phase, it is necessary to first determine the problem point, and then analyze the problem point. In the analysis process, the corresponding variables may be printed, and the source code needs to be modified at this time to reproduce or eliminate the fault. If modifying the source code is effective, the problem point is located. Since the above process needs to change the source code, the debugging process of the embedded software is cumbersome, which leads to low efficiency in debugging and testing of the embedded software. Therefore, how to improve the efficiency of debugging and testing of embedded software is a problem that needs to be solved in this application.

[0058] In order to solve the above problems, the present application discloses an embedded software testing method. In the embedded software testing process, there is no need to print the corresponding variables during the analysis process to modify the source code to reproduce or eliminate the fault. It is only necessary to send the address of the suspected fault point obtained to the microcontroller unit, and locate the variable data or register data pointed to by the address of the suspected fault point, so as to test and debug the variable data or register data later. Since only the address is operated and the read content is not distinguished, the space occupied is relatively small, thereby improving the testing and debugging efficiency of the embedded software. The specific implementation method is specifically described by the following embodiments.

[0059] refer to Figure 1 As shown, an embedded software testing method disclosed in an embodiment of the present application is provided, and the embedded software testing method mainly includes the following steps:

[0060] S101: During the entire code cycle, a suspected fault point of the embedded software project is determined, and an address of the suspected fault point is determined.

[0061] The entire code cycle includes the entire life cycle of the code, including the code development phase, debugging phase, and testing phase.

[0062] In the software development process, code development, debugging and testing are key links, which together constitute an important part of the software life cycle, namely the program phase or coding phase. The main task of this phase is to implement the design content of the system design phase through coding, and finally form an executable software code.

[0063] Throughout the life cycle of the code, the method of this solution can be used to locate faults and assist in debugging, testing, etc. A suspected fault point refers to a suspected fault point in an embedded software project where the actual data of the embedded software project is inconsistent with the preset expected data.

[0064] The specific process of obtaining the address of the suspected fault point is shown in A1-A3.

[0065] A1: During the entire code cycle, when the actual data of the embedded software project is detected to be inconsistent with the preset expected data, the inconsistent data is located to obtain the suspected fault point of the embedded software project.

[0066] It should be noted that the preset expected data is pre-set standard data for comparison with actual data of the embedded software project.

[0067] A2: Obtain the name of the suspected fault point and determine the type of the suspected fault point.

[0068] The type of the suspected fault point can assist in determining the length of the read data, and the type of the suspected fault point includes but is not limited to single-byte, double-byte, or quad-byte.

[0069] A3: By presetting the development environment, in the code-generated project, the address corresponding to the suspected fault point is determined according to the name and type of the suspected fault point.

[0070] The preset development environment includes but is not limited to an integrated development environment (IDE) of a microcontroller unit (MCU).

[0071] The suspected fault points include fault points associated with variables and fault points associated with registers.

[0072] The address corresponding to the name of the suspected fault point is obtained, that is, the address of the variable or register that needs to be debugged and tested.

[0073] The address of the variable or register that needs to be debugged and tested can be obtained through the MCU IDE in the project file generated by the code, or it can be obtained by the software engineer through manual query in the IDE software after the code is compiled.

[0074] Get the variable data in the project file generated by the code, as follows Figure 2 As shown, Figure 2 A data schematic diagram of the variables is shown.

[0075] Figure 2 In the table, the left column is the address of the variable, such as 0x1000, 0x1002; the right column is the name of the variable, such as _st_RCON, _sys_error.

[0076] For example, if you want to read the data of the variable named _st_RCON, you send the address 0x1000 to the MCU. No matter what data is stored at the address, the MCU can return the data corresponding to the address to the client for display. When the MCU returns the data corresponding to the address to the client for display, if the preset expected data is inconsistent with the actual data, the location of the data that is inconsistent with the preset expected data and the actual data is located. Subsequently, the actual data that is inconsistent with the expectation can be modified to make it consistent with the corresponding preset expected data.

[0077] Get the register data in the project file generated by the code, as follows Figure 3 As shown, Figure 3 A data schematic diagram of a register is shown.

[0078] Figure 3 In the register, Address is the address of the register; Name is the name of the register; Hex is the hexadecimal data of the register; Decimal is the decimal data of the register.

[0079] The hexadecimal data and decimal data of the register are presented as multiple options to improve the convenience of users in viewing the register data.

[0080] S102: Determine whether the embedded software project has a communication interface and obtain a determination result.

[0081] The communication interface is the communication interface integrated in the MCU.

[0082] The judgment result includes a judgment result that the embedded software project has a communication interface or a judgment result that the embedded software project does not have a communication interface.

[0083] It should be noted that this solution does not limit the MCU communication interface used, including but not limited to: UART, IIC (I2C), SPI, RS485, CAN, Ethernet, WiFi, 4G card and other communication interfaces.

[0084] This solution does not limit the chips used in embedded software projects. The chips used in embedded software projects in this solution are preferably MCU. This solution only adds the functions of this solution to the MCU chip used in the project.

[0085] Since the address is sent and the data result is uploaded and printed to help locate the problem, a communication interface is required. The selection principles of the communication interface are as follows:

[0086] a) Determine whether the embedded software project has a communication interface. If the embedded software project does not have a communication interface, determine that the communication function is not used in the embedded software project (i.e., there is no communication function), and then select a dedicated communication interface in the MCU that is not used and does not affect the project function.

[0087] It should be noted that since this solution can be integrated into any of the above-mentioned communication interfaces and isolated through the communication protocol, it will not affect the normal project functions.

[0088] b) Determine whether the embedded software project has a communication interface. If the embedded software project has a communication interface and it is determined that the embedded software project already includes communication functions, the communication interface used in the embedded software project can be directly used.

[0089] S103: according to the sending mode corresponding to the judgment result, the address is sent to the micro control unit, so that the micro control unit returns the data corresponding to the address; wherein there is a corresponding relationship between the address, the name of the suspected fault point and the data.

[0090] There is a corresponding relationship between the specific address, the name of the suspected fault point and the data. Figure 2 and Figure 3 shown.

[0091] Since the address is sent and the data result is uploaded and printed, a set of dedicated debugging commands is required. The definition principles of debugging commands are as follows:

[0092] a) If the communication function is not used in the embedded software project (not included), add a dedicated debugging command;

[0093] b) If the embedded software project already includes communication functions, the debugging commands of the embedded software project including communication functions can be integrated with the communication commands of the embedded software project including communication functions, but the communication functions of the project cannot be affected.

[0094] The embedded software project already contains the communication function, that is, it has the corresponding communication interface. The existence of the corresponding communication interface only means that this function requires communication to be realized, but it does not limit or stipulate the chip or chip interface used.

[0095] It should be noted that this solution does not limit or specify the dedicated debugging commands used. The codes of the dedicated debugging commands are just different from other communication commands.

[0096] The above-mentioned "dedicated" only means that this command will not be coupled with other project functions; and will not affect the normal functions of the project; it is only used for data access when needed, and this function will not be started at other times.

[0097] According to the sending mode corresponding to the judgment result, the address is sent to the micro control unit so that the micro control unit returns the data corresponding to the address. The process is shown in B1-B3:

[0098] B1: If the embedded software project has a communication interface, integrate the preset debugging command and the preset communication command into the communication interface, and send the address to the microcontroller unit (MCU) through the communication interface so that the MCU returns the data corresponding to the address.

[0099] There is a one-to-one correspondence between addresses and data.

[0100] It should be noted that the preset debugging command is a debugging command for an embedded software project with a communication function. The preset communication command is a communication command for an embedded software project with a communication function.

[0101] Specifically, if the embedded software project has a communication interface, the preset debugging command and the preset communication command are integrated into the communication interface, and the address is sent to the MCU through the communication interface so that the MCU returns the data corresponding to the address. The process is as follows:

[0102] (1) Determine whether the embedded software project has a communication interface and the address type of the address; wherein the address type at least includes a variable address or a register address;

[0103] (2) If the embedded software project has a communication interface and the address type of the address is a variable address, the preset debugging command and the preset communication command are integrated;

[0104] It should be noted that the preset debugging command is the debugging command of the embedded software project including the communication function. The preset communication command is the communication command of the embedded software project including the communication function.

[0105] (3) sending the variable address to the microcontroller unit through the communication interface and the integrated command, so that the microcontroller unit obtains the data pointed to by the variable address through the pointer reference;

[0106] (4) If the embedded software project has a communication interface and the address type of the address is a register address, the register address is sent to the microcontroller unit through the communication interface and the integrated command, so that the microcontroller unit obtains the hexadecimal data and decimal data pointed to by the register address through pointer reference.

[0107] Among them, if there is a "project with a communication interface", the debugging and testing commands will be integrated into the communication and isolated from the normal communication by software.

[0108] B2: The data corresponding to the address is transmitted back to the client through the preset communication interface;

[0109] The preset communication interface refers to the communication interface in which the embedded software project has communication functions.

[0110] B3: If the embedded software project does not have a communication interface, the address is sent to the MCU through a dedicated debugging command and a dedicated test interface so that the MCU returns the data corresponding to the address and transmits the data corresponding to the address back to the client.

[0111] Among them, if "there is no project with a communication interface", a debugging and testing interface should be reserved during the design stage to implement the content of this patent.

[0112] It should be noted that for "projects without communication interfaces", communication interfaces are reserved for "debugging" and "testing" during project design, but they are not visible to the outside world and are only used for "debugging" and "testing" purposes.

[0113] In addition, for "projects without communication interfaces", data in "registers" can also be obtained in the same way as variables. Other operations are the same as those for "projects with communication interfaces".

[0114] Specifically, if the embedded software project does not have a communication interface, the address is sent to the microcontroller unit through a dedicated debugging command and a dedicated test interface so that the microcontroller unit returns the data corresponding to the address, and the process of transmitting the data corresponding to the address back to the client is as follows:

[0115] If the embedded software project does not have a communication interface, and the address type of the address is a variable address, the variable address is sent to the microcontroller unit through a dedicated debugging command and a dedicated test interface, so that the microcontroller unit obtains the variable name pointed to by the variable address through a pointer reference; wherein the debugging command is a command that has no effect on the project function during the communication process;

[0116] If the embedded software project does not have a communication interface and the address type of the address is a register address, the register address is sent to the microcontroller unit through a dedicated debugging command and a dedicated test interface, so that the microcontroller unit obtains the hexadecimal data and decimal data pointed to by the register address through a pointer reference.

[0117] It should be noted that if there is no project with a communication interface, a debugging and testing interface should be reserved during the design phase to implement the contents of this solution.

[0118] S104: Send the data corresponding to the address back to the client.

[0119] In S104, the data corresponding to the address is transmitted back to the client through the communication interface of the MCU.

[0120] To facilitate understanding of the entire process of transmitting the data corresponding to the address back to the client, the details are as follows:

[0121] First, check the address of the variable or register to be printed and uploaded;

[0122] Secondly, determine whether the embedded software project has a communication interface, and send the variable address or register address to the MCU through the corresponding sending method of the determination result;

[0123] Then, the MCU will obtain the corresponding address and obtain the data in the variable or register pointed to by the address through pointer reference;

[0124] Finally, the data corresponding to the address is transmitted back to the client through the MCU communication interface and dedicated debugging commands.

[0125] It should be noted that this solution does not limit or require the use of a dedicated application (Application, APP) for a personal computer (Personal Computer, PC), and third-party "debugging assistant" and other software can also be used. This solution is also not limited to having a dedicated APP for a PC.

[0126] This solution sends the address of the variable or register you want to view and returns the corresponding data results to facilitate viewing and help locate or solve the problem.

[0127] When the MCU sends the data corresponding to the address back to the client for display, when the preset expected data is inconsistent with the actual data, the position of the data that is inconsistent with the preset expected data and the actual data is located, and the actual data that is inconsistent with the expectation can be modified later to make it consistent with the corresponding preset expected data.

[0128] This solution receives the address of the variable to be viewed and references the address. If the address is a variable address, the variable address is given to the MCU. The MCU takes out the variable address corresponding to the variable and sends it back to the client. Since only the address is operated, the space occupied is relatively small. You only need to get the address to read the data of the address, which can cover most application scenarios.

[0129] If it is detected that the connection between the micro control unit and the client is unsuccessful, the MCU and the client are connected through an intermediate forwarding device.

[0130] Since there are many possible problems during the product debugging and testing phase, and the chip space is limited, it is impossible to define all possible variables that may have problems in advance through communication commands, so that they can be printed and uploaded when problems occur. If there are no variables that can be printed and uploaded when a problem occurs, it is necessary to re-burn the code and print and upload the variable. This process will cause the code for finding the problem to be inconsistent with the code delivered to the customer, increasing the code management cost. Therefore, based on the above problems, this solution can achieve almost the same debugging and testing effects as "online debugging" without using the "online debugging" of the chip development environment; it can also avoid the problems described above, while reducing costs and increasing the speed of problem solving. Even if problems occur during on-site use by customers, the methods of this solution can be used to quickly locate and solve the problem, so as to improve efficiency, reduce costs, and maintain the company's image.

[0131] This solution improves debugging efficiency and does not worry about code legacy issues. Because the code is always retained in the source code, you only need to send the variable address you want to view to the MCU, and the MCU returns the value of the corresponding variable according to the received address. It is simple, intuitive, and efficient.

[0132] In the embodiment of the present application, during the embedded software testing process, there is no need to print the corresponding variables to modify the source code to reproduce or eliminate the fault. It is only necessary to send the acquired address of the suspected fault point to the microcontroller unit, and only the variable data or register data pointed to by the address of the suspected fault point is needed to locate the variable data or register data so as to test and debug the variable data or register data later. Since only the address is operated without distinguishing the read content, the space occupied is relatively small, thereby improving the testing and debugging efficiency of the embedded software.

[0133] Based on the above embodiments Figure 1 The disclosed embedded software testing method, the embodiment of the present application also discloses an embedded software testing device, such as Figure 4 As shown, the embedded software testing device comprises:

[0134] The determination unit 401 is used to determine the suspected fault point of the embedded software project in the entire code cycle, and determine the address of the suspected fault point;

[0135] A determination unit 402 is used to determine whether the embedded software project has a communication interface and obtain a determination result;

[0136] The sending unit 403 is used to send the address to the micro control unit according to the sending mode corresponding to the judgment result, so that the micro control unit returns the data corresponding to the address; wherein there is a corresponding relationship between the address, the name of the suspected fault point and the data;

[0137] The return unit 404 is used to return the data corresponding to the address to the client.

[0138] Further, the determining unit 401 includes:

[0139] A positioning module is used to locate the inconsistent data during the entire code cycle when the actual data of the embedded software project is inconsistent with the preset expected data, so as to obtain the suspected fault point of the embedded software project;

[0140] A first acquisition module is used to obtain the name of the suspected fault point and determine the type of the suspected fault point;

[0141] The second acquisition module is used to determine the address corresponding to the suspected fault point according to the name of the suspected fault point and the type of the suspected fault point in the code-generated project through a preset development environment.

[0142] Furthermore, the issuing unit 403 includes:

[0143] The first sending module is used to integrate the preset debugging command and the preset communication command into the communication interface if the embedded software project has a communication interface, and send the address to the micro control unit through the communication interface so that the micro control unit returns data corresponding to the address;

[0144] The return module is used to return the data corresponding to the address to the client through a preset communication interface;

[0145] The second sending module is used to send the address to the micro control unit through a dedicated debugging command and a dedicated test interface if there is no communication interface in the embedded software project, so that the micro control unit returns the data corresponding to the address and transmits the data corresponding to the address back to the client.

[0146] Furthermore, the first issuing module includes:

[0147] A judgment submodule is used to judge whether the embedded software project has a communication interface and the address type of the address; wherein the address type at least includes a variable address or a register address;

[0148] The integration submodule is used to integrate the preset debugging command and the preset communication command if the embedded software project has a communication interface and the address type of the address is a variable address;

[0149] The first sending submodule is used to send the variable address to the micro control unit through the communication interface and the integrated command, so that the micro control unit obtains the data pointed to by the variable address through the pointer reference;

[0150] The second sending submodule is used to send the register address to the microcontroller unit through the communication interface and the integrated command if the embedded software project has a communication interface and the address type of the address is a register address, so that the microcontroller unit obtains the hexadecimal data and decimal data pointed to by the register address through a pointer reference.

[0151] Furthermore, the second issuing module includes:

[0152] The third sending submodule is used for sending the variable address to the microcontroller unit through a dedicated debugging command and a dedicated test interface if the embedded software project does not have a communication interface and the address type of the address is a variable address, so that the microcontroller unit obtains the variable name pointed to by the variable address through a pointer reference; wherein the debugging command is a command that has no effect on the project function during the communication process;

[0153] The fourth sending submodule is used to send the register address to the microcontroller unit through a dedicated debugging command and a dedicated test interface if the embedded software project does not have a communication interface and the address type of the address is a register address, so that the microcontroller unit obtains the hexadecimal data and decimal data pointed to by the register address through a pointer reference.

[0154] Furthermore, the embedded software testing device also includes:

[0155] The monitoring connection unit is used to connect the micro control unit and the client through an intermediate forwarding device if it is detected that the connection between the micro control unit and the client is unsuccessful.

[0156] In the embodiment of the present application, during the embedded software testing process, it is not necessary to print the corresponding variables during the analysis process to modify the source code to reproduce or eliminate the fault. It is only necessary to send the address of the suspected fault point obtained to the microcontroller unit, and locate the variable data or register data pointed to by the address of the suspected fault point, so as to test and debug the variable data or register data later. Since only the address is operated and the read content is not distinguished, the space occupied is relatively small, thereby improving the testing and debugging efficiency of the embedded software.

[0157] An embodiment of the present application further provides a storage medium, which includes stored instructions, wherein when the instructions are executed, the device where the storage medium is located is controlled to execute the above-mentioned embedded software testing method.

[0158] The present application also provides an electronic device, whose structural diagram is as follows: Figure 5 As shown, it specifically includes a memory 501 and one or more instructions 502, wherein the one or more instructions 502 are stored in the memory 501 and are configured to be executed by one or more processors 503 to execute the one or more instructions 502 to perform the above-mentioned embedded software testing method.

[0159] For the aforementioned method embodiments, for the sake of simplicity, they are all described as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the order of the actions described, because according to the present application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present application.

[0160] It should be noted that each embodiment in this specification is described in a progressive manner, and each embodiment focuses on the differences from other embodiments, and the same or similar parts between the embodiments can be referred to each other. For system embodiments, since they are basically similar to method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0161] The steps in the methods of the embodiments of the present application can be adjusted in order, combined, and deleted according to actual needs.

[0162] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are merely used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations.

[0163] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

[0164] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. An embedded software testing method, characterized in that: The method comprises: Determine suspected fault points of the embedded software project throughout the entire code cycle, and determine the addresses of the suspected fault points; Determine whether the embedded software project has a communication interface and obtain a determination result; According to the sending mode corresponding to the judgment result, the address is sent to the micro control unit, so that the micro control unit returns the data corresponding to the address; wherein there is a corresponding relationship between the address, the name of the suspected fault point and the data; The data corresponding to the address is sent back to the client.

2. The method according to claim 1, characterized in that: Determining the suspected fault point of the embedded software project in the entire code cycle and determining the address of the suspected fault point includes: During the entire code cycle, when the actual data of the embedded software project is detected to be inconsistent with the preset expected data, the inconsistent data is located to obtain the suspected fault point of the embedded software project; Obtain the name of the suspected fault point and determine the type of the suspected fault point; By presetting the development environment, in the code-generated project, the address corresponding to the suspected fault point is determined according to the name of the suspected fault point and the type of the suspected fault point.

3. The method according to claim 1, characterized in that: The sending of the address to the micro control unit according to the sending mode corresponding to the judgment result, so that the micro control unit returns the data corresponding to the address, includes: If the embedded software project has a communication interface, the preset debugging command and the preset communication command are integrated into the communication interface, and the address is sent to the micro control unit through the communication interface, so that the micro control unit returns the data corresponding to the address; Transmitting the data corresponding to the address back to the client through the preset communication interface; If the embedded software project does not have a communication interface, the address is sent to the micro control unit through a dedicated debugging command and a dedicated test interface, so that the micro control unit returns the data corresponding to the address and transmits the data corresponding to the address back to the client.

4. The method according to claim 3, characterized in that If the embedded software project has a communication interface, integrating the preset debugging command and the preset communication command into the communication interface, and sending the address to the micro control unit through the communication interface so that the micro control unit returns data corresponding to the address, including: Determine whether the embedded software project has a communication interface and the address type of the address; wherein the address type includes at least a variable address or a register address; If the embedded software project has a communication interface, and the address type of the address is a variable address, integrating a preset debugging command and a preset communication command; The variable address is sent to the micro control unit through the communication interface and the integrated command, so that the micro control unit obtains the data pointed to by the variable address through pointer reference; If the embedded software project has a communication interface and the address type of the address is a register address, the register address is sent to the microcontroller unit through the communication interface and the integrated command, so that the microcontroller unit obtains the hexadecimal data and decimal data pointed to by the register address through pointer reference.

5. The method according to claim 3, characterized in that: If the embedded software project does not have a communication interface, the address is sent to the micro control unit through a dedicated debugging command and a dedicated test interface, so that the micro control unit returns the data corresponding to the address, and transmits the data corresponding to the address back to the client, including: If the embedded software project does not have a communication interface, and the address type of the address is a variable address, the variable address is sent to the microcontroller unit through a dedicated debugging command and a dedicated test interface, so that the microcontroller unit obtains the variable name pointed to by the variable address through a pointer reference; wherein the debugging command is a command that has no effect on the project function during the communication process; If the embedded software project does not have a communication interface and the address type of the address is a register address, the register address is sent to the microcontroller unit through a dedicated debugging command and a dedicated test interface, so that the microcontroller unit obtains the hexadecimal data and decimal data pointed to by the register address through a pointer reference.

6. The method according to claim 1, characterized in that Also includes: If it is detected that the connection between the micro control unit and the client is unsuccessful, the micro control unit and the client are connected via an intermediate forwarding device.

7. An embedded software testing device, characterized in that: The device comprises: A determination unit, used to determine suspected fault points of the embedded software project in the entire code cycle, and determine the addresses of the suspected fault points; A judgment unit, used to judge whether the embedded software project has a communication interface and obtain a judgment result; A sending unit, used for sending the address to the micro control unit according to the sending mode corresponding to the judgment result, so that the micro control unit returns the data corresponding to the address; wherein there is a corresponding relationship between the address, the name of the suspected fault point and the data; The return unit is used to return the data corresponding to the address to the client.

8. The device according to claim 7, characterized in that The determining unit comprises: A positioning module is used to locate the inconsistent data during the entire code cycle when the actual data of the embedded software project is inconsistent with the preset expected data, so as to obtain the suspected fault point of the embedded software project; A first acquisition module is used to obtain the name of the suspected fault point and determine the type of the suspected fault point; The second acquisition module is used to determine the address corresponding to the suspected fault point according to the name of the suspected fault point and the type of the suspected fault point in the code-generated project through a preset development environment.

9. The device according to claim 7, characterized in that The sending unit includes: A first sending module is used for integrating a preset debugging command and a preset communication command into the communication interface if the embedded software project has a communication interface, and sending the address to the micro control unit through the communication interface, so that the micro control unit returns data corresponding to the address; A return module, used to return the data corresponding to the address to the client through the preset communication interface; The second sending module is used to send the address to the micro control unit through a dedicated debugging command and a dedicated test interface if there is no communication interface in the embedded software project, so that the micro control unit returns the data corresponding to the address and transmits the data corresponding to the address back to the client.

10. The device according to claim 9, characterized in that The first sending module includes: A judgment submodule, used to judge whether the embedded software project has a communication interface and the address type of the address; wherein the address type at least includes a variable address or a register address; An integration submodule, used for integrating a preset debugging command and a preset communication command if the embedded software project has a communication interface and the address type of the address is a variable address; A first sending submodule is used to send the variable address to the micro control unit through the communication interface and the integrated command, so that the micro control unit obtains the data pointed to by the variable address through pointer reference; The second sending submodule is used to send the register address to the micro control unit through the communication interface and the integrated command if the embedded software project has a communication interface and the address type of the address is a register address, so that the micro control unit obtains the hexadecimal data and decimal data pointed to by the register address through a pointer reference.

Images