Software debugging method, device, equipment, storage medium and program product

Abstract

The application provides a software debugging method and device, equipment, storage medium and program product, and relates to the field of computers. The method comprises the following steps: the electronic equipment can determine whether the current time meets the debugging running condition. If yes, the electronic equipment can generate a running signal. The electronic equipment can wake up the first program module in response to the running signal. The first program module after being woken up will exit the standby running state and enter the running state. The electronic equipment can obtain the second program module when the first program module completes running. The second program module can be the subsequent program module of the first program module in the target program. The electronic equipment can set the state of the second program module as the standby running state. The method provided in the application improves the debugging flexibility of the program modules of the target program.

Description

Technical Field

[0001] This application relates to the field of machine vision, and more particularly to a software debugging method, apparatus, device, storage medium, and program product. Background Technology

[0002] As an important component of the field of computer vision, vision software is widely used in image processing, pattern recognition, and machine vision inspection. This software uses algorithms to analyze and process images to achieve automated detection, measurement, and classification functions.

[0003] Existing vision software typically employs a linear execution model in controlling the flow of operations. Once the process begins, all modules execute sequentially until completion. This is especially true when the Group loop feature is enabled, where the software executes multiple loops consecutively.

[0004] While this design ensures the continuity of the process, it has significant shortcomings in debugging and problem diagnosis, resulting in a lack of debugging flexibility in existing vision software. Summary of the Invention

[0005] This application provides a software debugging method, apparatus, device, storage medium, and program product to solve the problem of poor debugging flexibility in the execution of vision software in the prior art.

[0006] Firstly, this application provides a software debugging method, including:

[0007] If the debugging and operation conditions are met, a running signal is generated;

[0008] In response to the running signal, the first program module in the target program that is in a standby state is awakened, so that the first program module exits the standby state and runs;

[0009] When the first program module finishes running, the second program module that follows the first program module is determined according to the connection relationship of the multiple program modules in the target program.

[0010] Set the status of the second program module to the ready-to-run state.

[0011] Secondly, this application provides a software debugging apparatus, comprising:

[0012] The generation module is used to generate running signals when the debugging and running conditions are met;

[0013] The debugging module is used to respond to the running signal, wake up the first program module in the target program that is in a standby state, so that the first program module exits the standby state and runs; when the first program module finishes running, determine the second program module that succeeds the first program module according to the connection relationship of multiple program modules in the target program; and set the state of the second program module to a standby state.

[0014] Thirdly, this application provides an electronic device, including: a memory and a processor;

[0015] The memory is used to store computer programs; the processor is used to execute the first aspect and any possible design of the first aspect according to the computer programs stored in the memory.

[0016] Fourthly, this application provides a computer-readable storage medium storing a computer program, wherein when at least one processor of an electronic device executes the computer program, the electronic device performs the first aspect and any possible software debugging method in the design of the first aspect.

[0017] Fifthly, this application provides a computer program product comprising a computer program that, when executed by at least one processor of an electronic device, causes the electronic device to perform the first aspect and any possible design of the first aspect.

[0018] The software debugging method, apparatus, device, storage medium, and program product provided in this application determine whether the debugging operation conditions are met at the current moment; if they are met, a running signal is generated; in response to the running signal, a first program module can be woken up; after being woken up, the first program module will exit the waiting state and enter the running state; after the first program module finishes running, a second program module is obtained; the second program module can be a program module that succeeds the first program module in the target program; by setting the state of the second program module to the waiting state, the debugging flexibility of each program module in the target program is improved. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0020] Figure 1 A schematic diagram showing the connection of multiple program modules in a target program provided in an embodiment of this application;

[0021] Figure 2 A schematic diagram showing the connection of multiple program modules in a Group of a target program provided in an embodiment of this application;

[0022] Figure 3 Flowchart of a software debugging method provided in an embodiment of this application Figure 1 ;

[0023] Figure 4 A flowchart for starting debugging is provided as an embodiment of this application;

[0024] Figure 5 Flowchart of a software debugging method provided in an embodiment of this application Figure 2 ;

[0025] Figure 6 A flowchart of single-step debugging provided in one embodiment of this application;

[0026] Figure 7 Flowchart of a software debugging method provided in an embodiment of this application Figure 3 ;

[0027] Figure 8 This is a schematic diagram of a breakpoint generation interface provided in an embodiment of this application;

[0028] Figure 9 A schematic diagram of the interface for setting breakpoints according to an embodiment of this application;

[0029] Figure 10 A breakpoint debugging process provided for an embodiment of this application Figure 1 ;

[0030] Figure 11 Flowchart of a software debugging method provided in an embodiment of this application Figure 4 ;

[0031] Figure 12 A flowchart illustrating an abnormal interruption provided in an embodiment of this application;

[0032] Figure 13 Flowchart of a software debugging method provided in an embodiment of this application Figure 5 ;

[0033] Figure 14 A flowchart for stopping debugging is provided as an embodiment of this application;

[0034] Figure 15 This is a schematic diagram of the structure of a software debugging device provided in an embodiment of this application;

[0035] Figure 16 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application.

[0036] The accompanying drawings have illustrated specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to specific embodiments. Detailed Implementation

[0037] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0038] Terminology Explanation:

[0039] Vision Software: The vision software used in this application is specifically VisionMaster. VisionMaster, used in industrial machine vision, is a machine vision software platform independently developed by Hikvision Robotics. It is specifically designed for rapidly building vision applications and solving visual inspection challenges, providing a series of algorithmic tools to meet the needs of machine vision applications such as visual positioning, dimensional measurement, defect detection, and information recognition. The debugging function of this application is also implemented based on this vision software.

[0040] A process is a container in vision software. This container can contain all modules of the target program. Optionally, these modules can be program modules, groups, etc. A process controls the sequential execution of modules within the target program. A process container is one level higher than a group.

[0041] Loop: An execution strategy of the target program in vision software within its execution flow. Within one execution cycle, multiple program modules of the target program can be executed repeatedly.

[0042] Group: A module type within vision software. A group module is like a container. When multiple program modules are assembled together to form a black box, the multiple program modules included in this black box form a Group. In vision software, a Group can be displayed externally as a module identifier. When you double-click on a Group in the display interface, you can enter the Group and view the program modules within it. Currently, VisionMaster's Group has both grouping and looping functions. The looping function is disabled by default. When you need to use the looping function of a Group, you can manually enable it.

[0043] Breakpoint debugging: When a program module has a breakpoint set, the flow can be executed sequentially in the breakpoint debugging state until the program module with the breakpoint is interrupted.

[0044] Single-step debugging: When using single-step debugging, each click of the single-step debugging button will execute one program module in sequence within the process.

[0045] Existing vision software, when controlling the execution of a workflow, executes all modules within the workflow once it begins, without interruption, which is inconvenient for debugging. Especially when a group loop is enabled, it is impossible to set breakpoints to debug and view the execution results of modules in each loop. After the group loop completes, all graphic results are displayed on the image, but it is difficult to determine which loop result corresponds to which graphic position. Existing software cannot meet the need to clearly know the execution status during each loop.

[0046] In the fields of industrial automation and intelligent manufacturing, machine vision plays a crucial role in improving production efficiency, ensuring product quality, and achieving process control. Vision software, as the core of a machine vision system, is responsible for processing image data, performing algorithmic analysis, and providing operational feedback.

[0047] Existing vision software has made some progress in controlling process execution, enabling automated process execution. However, these software programs have limitations in terms of process control flexibility and debugging convenience. In particular, once process execution begins, existing software does not support interruptions in the middle of the process, which is especially inconvenient during the development and debugging phases. Furthermore, when using group loop execution, existing software cannot set breakpoints during the loop, making it impossible to view and analyze the execution results of each loop in real time. After the loop ends, all graphical results are displayed overlay, making it difficult to identify which loop corresponds to which graphical position, posing challenges to accurate debugging and problem diagnosis.

[0048] To address the aforementioned technical problems, embodiments of this application provide a software debugging method applicable to vision software. This software debugging method may include three types of debugging: breakpoint debugging, single-step debugging, and exception debugging.

[0049] Optionally, Figure 1 The display interface of the software debugging method of this application in vision software is shown. For example... Figure 1 As shown, the top of the interface can include multiple tabs. The first three tabs can be fixed software tabs. Starting from the fourth tab, these can be process tabs. Users can create new process tabs by clicking the "+". Each process tab can correspond to a process container. For example, as shown... Figure 1As shown, this includes one process label. This process label can be named "Process 1". It can also include a run button and a rerun button.

[0050] Optionally, the path information of the currently running module can be set below the label. For example, such as... Figure 1 As shown, the currently running module is Linear Search 1, so the path information could be "Process 1 > Linear Search 1". For example, ... Figure 2 As shown, when the running module is Elliptic Search 1, the path information can be "Process 1 > Combined Module 1 > Elliptic Search 1".

[0051] Optionally, Figure 1 The displayed interface may also include debugging buttons. These buttons may include four sub-buttons: "Start Debugging," "Step-by-Step Debugging," "Breakpoint Debugging," and "Exception Debugging." Optionally, the labels for these four buttons can be customized by the user. For example, "Start Debugging" can be replaced with "Start Debugging Status," "Step-by-Step Debugging" with "Step-by-Step Execution," "Breakpoint Debugging" with "Execute to Next Breakpoint," and "Exception Debugging" with "NG Interruption." Optionally, when the user clicks the "Start Debugging" button, it will change to "Stop Debugging," and the "Step-by-Step Debugging," "Breakpoint Debugging," and "Exception Debugging" buttons will become clickable.

[0052] Optionally, Figure 1 The displayed interface may also include a target program. This target program may include multiple program modules linked sequentially. For example, Figure 1The target program shown may include five program modules: Image Source 1, Circle Search 1, Line Search 1, Contour Matching 1, and Line Circle Measurement 1. Optionally, the target program may also include a Group. This Group may be a combined module 1. Each module may correspond to a rectangle labeled with the module name. The right side of the rectangle may include an indicator area displaying the module's status. This indicator area may display an icon showing the module's execution status. For example, when the module is not being executed, the indicator area may be empty. When the module is being executed, the indicator area may display a third icon. Optionally, the third icon may be displayed in a color such as yellow. Alternatively, the third icon may also be a grid. When the module completes execution, the indicator area may display a first icon or a second icon. Optionally, when the module executes successfully, it may display a second icon. Optionally, the second icon may be displayed in a color such as green. Alternatively, the second icon may also be a diagonal line. Optionally, when the module encounters an error during execution, it may display a first icon. Optionally, the first icon may be displayed in a color such as red. Alternatively, the first diagram could also be the bottom diagonal.

[0053] Optionally, users can enter a group by clicking on its module. For example, such as Figure 1 As shown, module 1 can be a Group. For example... Figure 2 As shown, the combined module 1 can include three program modules: Circle Search 1, Blob Analysis, and Ellipse Search 1.

[0054] Using an electronic device as the execution subject, the software debugging method of the following embodiments is executed. Specifically, the execution subject can be a hardware device of the electronic device, a software application implementing the following embodiments in the electronic device, a computer-readable storage medium on which the software application implementing the following embodiments is installed, or code implementing the software application of the following embodiments.

[0055] The technical solutions of this application will be described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0056] Figure 3 The flowchart of a software debugging method provided in an embodiment of this application is shown. Figure 1 .exist Figure 1 and Figure 2 Based on the illustrated embodiments, as Figure 3 As shown, with an electronic device as the execution entity, the target program includes multiple program modules connected in sequence. The method in this embodiment may include the following steps:

[0057] S101. If the debugging and operation conditions are met, generate an operation signal.

[0058] In this embodiment, the electronic device can determine whether the debugging operation conditions are met at the current moment. If they are met, the electronic device can generate a running signal. The running signal can instruct the program module in the waiting state to run. Otherwise, if the conditions are not met, the electronic device will continue to wait until the debugging operation conditions are met.

[0059] In one example, the debugging condition can be either the debug button being triggered or the debug button not being exited. Optionally, the debug button can be any one of three buttons: single-step debugging, breakpoint debugging, or exception debugging. Optionally, when the debug button is triggered, a run signal can be generated. For example, when the single-step debugging button is triggered, single-step debugging mode can be entered, and a run signal can be generated. When the breakpoint debugging button is triggered, breakpoint debugging mode can be entered, and a run signal can be generated. When the exception debugging button is triggered, exception debugging mode can be entered, and a run signal can be generated. Optionally, when the debug button is not exited, the electronic device can continue to generate run signals. For example, single-step debugging mode can exit after the execution of the first program module is completed. Similarly, breakpoint debugging mode can exit when it is determined that the second program module includes a breakpoint. Before running to the program module where the breakpoint is located, the electronic device is in a running state where the debug button is not exited each time a program module finishes execution. At this time, the electronic device can directly generate a run signal so that it can continue to run according to the connection sequence of the program modules until it reaches the program module where the breakpoint is located. For example, the abnormal debugging state can exit when it is determined that the operation of the first program module has encountered an abnormality.

[0060] S102. In response to the run signal, wake up the first program module in the target program that is in the standby state, so that the first program module exits the standby state and runs.

[0061] In this embodiment, after the electronic device generates a running signal, it can respond to the signal and wake up the first program module. The woken-up first program module will exit the standby state and enter the running state. Here, the first program module is the program module currently in the standby state. Optionally, the number of the first program modules can be one or more. When the process runs on the main process, the number of the first program modules can be one. For example, as... Figure 1 As shown, when the process runs through Image Source 1, Circle Search 1, and Line Search 1, the first program can be Image Source 1, Circle Search 1, or Line Search 1. When the process reaches a branch process, the number of the first program modules can be determined based on the number of branches. For example, when there are two branches, the number of the first program modules can be two. For example, as shown... Figure 1 As shown, when the process runs to Line Circle Measurement 1 and Contour Matching 1, the corresponding two branches can include two first program modules: Line Circle Measurement 1 and Contour Matching 1.

[0062] In one example, the process of waking up the first program module with a run signal and causing the first program module to exit the standby state and enter the run state may specifically include:

[0063] Step 11: Count the number of first program modules that are in the waiting-to-run state.

[0064] In this step, the electronic device can count the number of first program modules in the waiting state to obtain a first number. Optionally, a first program module in the waiting state can perform a wait operation (P operation). At this time, the first program module can call a wait function. The electronic device can determine the first number by counting the number of wait function calls. Optionally, the semaphore value of the wait function can be 0. At this time, the first program module can remain in the waiting state.

[0065] Step 12: In response to the running signal, generate the first number of wake-up signals.

[0066] In this step, the electronic device can generate a wake-up signal in response to the operation signal. Optionally, the number of wake-up signals generated by the electronic device can be determined according to a first quantity. Optionally, each first program module can correspond to one wake-up signal. Optionally, the wake-up signal can be a semaphore.

[0067] Step 13: Use a wake-up signal to wake up the first program module so that the first program module exits the standby state.

[0068] In this step, the electronic device can acquire the semaphore through the wait function of the first program module. When the wait function acquires the semaphore, its value can become 1. When the value of the wait function becomes 1, the first program module is woken up. The woken-up first program module will begin running. Before starting to run, the wait function can be decremented by 1, returning its value to 0. After the value of the wait function returns to 0, the first program module will begin running.

[0069] Step 14: Run the first program module.

[0070] In this step, the electronic device can run the first program module.

[0071] S103. When the first program module finishes running, determine the second program module that succeeds the first program module based on the connection relationship between multiple program modules in the target program.

[0072] In this embodiment, the electronic device can acquire a second program module after the first program module has finished running. This second program module can be a successor program module to the first program module in the target program. For example, in... Figure 1 In the target program shown, the program module following image source 1 is circle search 1. The program module following circle search 1 is line search 1. The program modules following line search 1 are contour matching 1 and line circle measurement 1.

[0073] In one example, after the first program module completes its execution, the electronic device can also display the execution result of the first program module by adding an icon to the module's identification area. The electronic device can obtain the execution result of the first program module, which includes whether it runs normally or abnormally. Optionally, "running normally" means "OK," and "running abnormally" means "NG." When the execution result of the first program module is abnormal, the electronic device can use a first icon to label the first program module. When the execution result of the first program module is normal, the electronic device can use a second icon to label the first program module. Optionally, the first and second icons can be colors. For example, the first icon can be red, and the second icon can be green. Alternatively, the first and second icons can be patterns. For example, the first icon can be a bottom diagonal line, and the second icon can be a top diagonal line. Optionally, the color and pattern are merely examples to illustrate that the first and second icons are different icons. In actual implementation, the first and second icons can be set by technicians or users.

[0074] In another example, during the execution of the first program, the electronic device can also display the running module by adding an icon to the identification area of ​​the program module. Optionally, when the first program module is running, a third icon is used to label the first program module. Optionally, the third icon can be yellow. Alternatively, the third icon can also be a diamond pattern. Optionally, this color and pattern are merely examples to illustrate that the third icon is different from the first and second icons. In actual implementation, the third icon can be set by a technician or user.

[0075] S104. Set the status of the second program module to the ready-to-run state.

[0076] In this embodiment, after identifying the second program module, the electronic device can set the state of the second program module to a ready-to-run state. Optionally, during this setting process, the electronic device can call the wait function of the second program module to put the second program module into this waiting state. When the second program module enters the waiting state, the value of the wait function can be 0. The second program module will continue to wait to be woken up.

[0077] The software debugging method provided in this application allows an electronic device to determine whether the debugging operation conditions are met at the current moment. If met, the electronic device can generate a running signal. In response to this running signal, the electronic device can wake up a first program module. The woken-up first program module will exit the standby state and enter the running state. The electronic device can acquire a second program module after the first program module has finished running. This second program module can be a successor program module to the first program module in the target program. The electronic device can set the state of the second program module to the standby state. In this application, by setting debugging operation conditions, the sequential execution of program modules is achieved in various debugging processes, enabling flexible debugging of each program module in the target program.

[0078] Based on the above embodiments, the debug buttons may include three functions: single-step debugging, breakpoint debugging, and exception debugging. Before triggering these three debug buttons, the user typically needs to click [the appropriate button]. Figure 1 The "Start Debugging" button is shown. Clicking this button puts the process into debug mode. Once in debug mode, the "Step Debug," "Breakpoint Debug," and "Exception Debug" buttons become available. Furthermore, once in debug mode, the "Start Debugging" button changes to a "Stop Debugging" button. In other words, the "Stop Debugging" button appears after the "Start Debugging" button is triggered.

[0079] In one implementation, when the "Start Debugging" button is clicked, the electronic device can perform the following steps: Figure 4 As shown, it includes:

[0080] S201. Click the Start Debugging button to put the process into debug mode.

[0081] S202, The process scheduling task begins execution. This scheduling task is used to schedule the execution of target programs within the process. Optionally, a process may include one or more target programs. Optionally, the process scheduling task may generate a process for each target program. Optionally, a process may be used to execute a program module of that target program. For example, when the first program module completes execution, the process may switch to the second program module.

[0082] S203. Run to the starting module of the process. Since the process has just begun debugging in this embodiment, the scheduling task can be scheduled to the starting module of the target program of the process. This starting module is the first program module of the target program. For example, Figure 1 In the target program shown, the starting module is image source 1.

[0083] S204. Increase the number of debug signal waits. Optionally, this number of debug signal waits can be the number of program modules that have entered the waiting state. That is, the first number. In the initial state, this number of debug signal waits can be 0. When running to the starting module of the process, the electronic device can quickly realize the statistics of the number of wait function calls by increasing the number of debug signal waits.

[0084] S205. The starting module's state is set to the ready-to-run state. Optionally, when the starting module is set to the ready-to-run state, the starting module's wait function will be called.

[0085] S206. Wait for the continue operation signal. This continue operation signal is a semaphore. In this step, the continue operation signal is generated only when the debug button is triggered.

[0086] Figure 5 The flowchart of a software debugging method provided in an embodiment of this application is shown. Figure 2 .exist Figures 1 to 4 Based on the illustrated embodiment, when the debug button is a single-step debug button, such as Figure 5 As shown, with an electronic device as the execution subject, the method in this embodiment may include the following steps:

[0087] S301. If the single-step debugging button is triggered, a run signal is generated.

[0088] In this embodiment, the electronic device can obtain the trigger signal of the single-step debug button when the user triggers it. The electronic device can change its debug state to single-step debug state in response to the trigger signal. The electronic device can generate a run signal in response to the single-step debug state. Optionally, the single-step debug button is used to instruct the target program to run a program module. Alternatively, when the target program includes multiple branches, the single-step debug button can also be used to instruct multiple branches of the target program to run a program module. That is, the single-step debug button can be used to control the flow to run the first program model currently in the pending run state. Optionally, the run signal triggered by the single-step debug button may include a semaphore. The wait function of the first program model in the pending run state can acquire the semaphore.

[0089] S302. In response to the run signal, wake up the first program module in the target program that is in the standby state, so that the first program module exits the standby state and runs.

[0090] S303. When the first program module finishes running, determine the second program module that succeeds the first program module based on the connection relationship between multiple program modules in the target program.

[0091] S304. Set the status of the second program module to the ready-to-run state.

[0092] Among them, the implementation of steps S302 to S304 is... Figure 2 The implementation of steps S102 to S104 in the embodiment is similar, and will not be repeated here.

[0093] S305. The single-step debugging state entered when the Exit Single-Step Debugging button is triggered.

[0094] In this embodiment, during the single-step debugging process, each triggering of the single-step debugging button controls the electronic device to enter the single-step debugging state. This single-step debugging state is only used to execute the first program module, which is currently in the waiting-to-run state. After the first program module has finished running, the electronic device can exit the single-step debugging state after setting the second program module to enter the waiting-to-run state.

[0095] For example, the target program can be like Figure 1 As shown. When the first program module is Circle Search 1, the electronic device can, after completing Circle Search 1, use Line Search 1 as the second program module. The electronic device can, after setting the state of Line Search 1 to the ready-to-run state, exit the single-step debugging state corresponding to this single-step debugging.

[0096] When the electronic device receives the trigger information of the single-step debugging button again, it can complete the line search 1 operation and then set line circle measurement 1 and contour matching 1 as the second program module. The electronic device can exit the single-step debugging state corresponding to this single-step debugging after setting the state of line circle measurement 1 and contour matching 1 to the ready-to-run state.

[0097] When the electronic device receives the single-step debugging trigger information again, it can complete line circle measurement 1 and contour matching 1. If a program module is included after line circle measurement 1, that program module will be used as the second program module. Because... Figure 1 In the process, the program module is not included after Line Circle Measurement 1. Therefore, the operation of this branch line ends. Furthermore, the combined module 1 following Contour Matching 1 will be used as the second program module. This combined module 1 is a grouped module, obtained by combining multiple program modules.

[0098] The electronic device can exit the single-step debugging state corresponding to the current single-step debugging after setting the status of the second program module to the ready-to-run state. Optionally, when the combined module 1 is identified as the second program module, the page will automatically jump to, for example,... Figure 2 The interface shown. In this combined module 1, the first program module, Circle Lookup 1, is redefined as the second program module.

[0099] In subsequent step-by-step debugging, the electronic device will run sequentially according to the step-by-step debugging instructions. Figure 2 The diagram shows multiple program modules. Optionally, during subsequent step-by-step debugging, the number of loops for the multiple program modules in this combined module 1 will be determined based on the setting information of this combined module 1.

[0100] Therefore, during single-step debugging, the actual execution is as follows: Figure 2 The circle shown is searchable as 1. Figure 2 The three program modules shown are the specific components of combined module 1. During single-step debugging, each time the single-step debugging button is clicked, one program module in combined module 1 will be run.

[0101] For example, when module 1 does not have a loop, it will complete execution when all three program modules have finished executing. Optionally, when module 1 completes execution, the page can return to the previous page. Figure 1 The process shown is Flow 1. This process will continue to execute the other modules following Flow 1.

[0102] The software debugging method provided in this application allows the electronic device to receive the trigger of the single-step debugging button when the user does so. The electronic device can then generate a run signal in response to this trigger information. Responding to the run signal, the electronic device can wake up the first program module in the target program that is in a standby state, causing the first program module to exit the standby state and begin execution. Once the first program module has finished running, the electronic device can determine the subsequent second program module based on the connection relationships among multiple program modules in the target program. The electronic device can then set the state of the second program module to a standby state. After setting the standby state of the second program module, the electronic device can exit the single-step debugging state. This application, by using single-step debugging, achieves sequential execution of program modules in the target program, improving the control flexibility during model execution.

[0103] In one implementation, when the single-step debugging button is clicked, the steps performed by the electronic device can be as follows: Figure 6 As shown, it includes:

[0104] S401, Click the single-step debugging button.

[0105] S402. Obtain the number of debug wait signals. The number of debug wait signals is the first number of the first program modules that have entered the standby state.

[0106] S403. Generate wake-up signals according to quantity. These wake-up signals can be named debug wait signals. Each wake-up signal can wake up a first program module that is in a standby state.

[0107] S404, The first program module in the standby state is awakened.

[0108] S405, the first program module is running.

[0109] S406. If the first program module runs normally, the module status is set to "Running OK"; otherwise, the module status is set to "Running NG". The module status setting can be implemented by displaying the corresponding diagram in the identifier area.

[0110] S407. Based on the connection relationship of multiple program modules in the target program, determine the second program module that succeeds the first program module.

[0111] S408. Increase the number of debug signal waiting items. Specifically, the electronic device can subtract the number of the first program modules from the number of debug signal waiting items and add the number of the second program modules to obtain a new number of debug signal waiting items. That is, obtain a new first number.

[0112] S409. Set the status of the second program module to "ready to run".

[0113] S410, Waiting for the continue operation signal. This continue operation signal is a semaphore. In this step, the continue operation signal will be generated when the single-step debug button is triggered again.

[0114] Figure 7 The flowchart of a software debugging method provided in an embodiment of this application is shown. Figure 3 .exist Figures 1 to 6 Based on the illustrated embodiment, when the debug button is a breakpoint debug button, as shown... Figure 7 As shown, with an electronic device as the execution subject, the method in this embodiment may include the following steps:

[0115] S501. If the breakpoint debugging button is triggered, or if the breakpoint debugging state triggered by the breakpoint debugging button is not exited, a run signal is generated. The breakpoint debugging state is entered when the breakpoint debugging button is triggered.

[0116] The steps shown in this embodiment describe the execution process of a program module during breakpoint debugging. During this process, the electronic device can determine whether the first program module, currently in a waiting-to-run state, can run based on the two scenarios described above. One scenario is that when the electronic device determines that the breakpoint debugging button has been triggered, it can generate a run signal. Optionally, when the breakpoint debugging button is triggered, the electronic device can enter the breakpoint debugging state in response to the trigger information of the breakpoint debugging button. The other scenario is that when the electronic device determines that it has not exited the breakpoint debugging state, it can generate a run signal. Since the breakpoint debugging state exits when a breakpoint exists in the second program module, not exiting the breakpoint debugging state indicates that the first program module does not contain a breakpoint. That is, the electronic device can determine that the current breakpoint debugging has not yet reached a breakpoint. Optionally, the run signal is used to instruct the first program module, currently in a waiting-to-run state, to run.

[0117] In one example, during breakpoint debugging, the specific steps an electronic device takes to determine whether to enter and exit breakpoint debugging state may include:

[0118] Step 31: When the breakpoint debugging button is triggered, determine whether there are any program modules with breakpoints set in the subsequent program modules of the first program module, based on the connection relationship of multiple program modules in the target program.

[0119] In this step, the target program in the process container is retrieved, and it is traversed sequentially starting from the next program module after the first program module. The electronic device will end the traversal when a program module with a breakpoint is set. Simultaneously, the electronic device can return the traversal result with breakpoints. If the electronic device completes the traversal without encountering a program module with a breakpoint, it can return the traversal result without breakpoints.

[0120] The first program module is the program module that is in a standby state when the breakpoint debugging button is triggered. When a breakpoint exists in this first program module, the breakpoint debugging program will not be able to run. Therefore, the electronic device will not check the breakpoints in this first program module when searching for breakpoints.

[0121] It should be noted that when the first program module has a breakpoint and is in a loop, if the electronic device traverses to the first program module according to the target program, the breakpoint in the first program module will be captured.

[0122] Step 32: If it is determined that a breakpoint exists in the traversal result, then enter the breakpoint debugging state. Otherwise, if it is determined that no breakpoint exists in the traversal result, then do not enter the breakpoint debugging state.

[0123] Optionally, this process only associates the program module that is closest to the first module and has a breakpoint.

[0124] S502. In response to the run signal, wake up the first program module in the target program that is in the standby state, so that the first program module exits the standby state and runs.

[0125] S503. When the first program module finishes running, determine the second program module that succeeds the first program module based on the connection relationship between multiple program modules in the target program.

[0126] S504. Set the status of the second program module to the ready-to-run state.

[0127] Among them, the implementation of steps S502 to S504 is... Figure 2 The implementation of steps S102 to S104 in the embodiment is similar, and will not be repeated here.

[0128] S505. If the second program module contains breakpoints, exit the breakpoint debugging state.

[0129] In this embodiment, after setting the running state of the second program module, the electronic device can determine whether the second program module includes breakpoints. If breakpoints are included, it means that the breakpoint debugging has reached the breakpoint, and the breakpoint debugging ends. Therefore, the electronic device can exit the breakpoint debugging state when it determines that the second program module includes breakpoints.

[0130] Optionally, the electronic device may return to step S501 if the second program module does not contain breakpoints. Upon returning to step S501, the second program module becomes the first program module. The electronic device will no longer generate a run signal if it has determined that it has exited the breakpoint debugging state. Optionally, if the second program module does not contain breakpoints, the electronic device will not exit the breakpoint debugging state. The electronic device may generate a run signal and continue executing program modules sequentially after returning to step S501 without exiting the breakpoint debugging state.

[0131] The software debugging method provided in this application allows the electronic device to generate a run signal when the breakpoint debugging button is triggered. Alternatively, the electronic device can generate a run signal when it determines that the breakpoint debugging state generated when the breakpoint debugging button is not triggered has not been exited. In response to the run signal, the electronic device can wake up a first program module in the target program that is in a standby state, causing the first program module to exit the standby state and run. After the first program module finishes running, the electronic device can determine the subsequent second program module based on the connection relationship of multiple program modules in the target program. The electronic device can set the state of the second program module to a standby state. After setting the standby state of the second program module, the electronic device can determine whether the second program module contains breakpoints. If it contains breakpoints, the electronic device can exit the breakpoint debugging state. In this application, by using breakpoint debugging, a debugging method that stops the target program at breakpoints is achieved, improving the control flexibility during the execution of the target program.

[0132] Based on the above embodiments, before the breakpoint debugging button is triggered, the electronic device needs to set a breakpoint on at least one program module of the target program. The process of setting this breakpoint can be as follows: Figure 8 As shown, users can right-click on the program module where breakpoints need to be set to trigger a menu. This menu includes at least the option to add a breakpoint. When the user clicks the option to add a breakpoint, the electronic device can respond to the user's operation and set a breakpoint on the program module. Optionally, the menu may also include an option to delete a breakpoint. This breakpoint deletion option can delete the breakpoints set on the program module. Optionally, the menu may also include an option to delete all breakpoints. This option to delete all breakpoints can delete all breakpoints on the target program.

[0133] Optionally, when completed as follows Figure 8 After setting breakpoints on the program module shown, the electronic device can pause program execution and display the current processing result when it reaches the breakpoint. This processing result can be displayed as follows: Figure 9 As shown in the image, this interface may include a display window. This display window may show the setting parameters of the combined modules, as well as the output image and output results.

[0134] In one implementation, when the breakpoint debugging button is clicked, the execution steps of the electronic device can be as follows: Figure 10 As shown, it includes:

[0135] S601, Click the breakpoint debugging button.

[0136] S602. Enter breakpoint debugging mode. Optionally, the electronic device may have a breakpoint debugging mode flag set. When the breakpoint debugging mode flag is true, it indicates that the electronic device has entered breakpoint debugging mode.

[0137] S603. Obtain the number of debug wait signals. The number of debug wait signals is the first number of the first program modules that have entered the standby state.

[0138] S604. Generate wake-up signals according to quantity. These wake-up signals can be named debug wait signals. Each wake-up signal can wake up a first program module that is in a standby state.

[0139] S605, The first program module in the standby state is awakened.

[0140] S606, the first program module runs.

[0141] S607. If the first program module runs normally, the module status is set to "Running OK"; otherwise, the module status is set to "Running NG".

[0142] S608. Based on the connection relationship of multiple program modules in the target program, determine the second program module that succeeds the first program module.

[0143] S609. Determine if the second program module has a breakpoint. If yes, execute S610. If no, treat the second program module as the new first program module and return to S606.

[0144] S610. Exit breakpoint debugging state. Optionally, when the breakpoint debugging state is marked as false, it indicates that the electronic device is exiting the breakpoint debugging state. Therefore, the electronic device can exit the breakpoint debugging state by changing the breakpoint debugging flag to false.

[0145] S611. Increase the number of debug signal waiting items. Specifically, the electronic device can subtract the number of the first program modules from the number of debug signal waiting items and add the number of the second program modules to obtain a new number of debug signal waiting items. That is, obtain a new first number.

[0146] S612. Set the status of the second program module to "ready to run".

[0147] S613. Wait for the continue running signal. This continue running signal is a semaphore. In this step, the continue running signal will be generated when the breakpoint debugging button is triggered again.

[0148] Figure 11 The flowchart of a software debugging method provided in an embodiment of this application is shown. Figure 4 .exist Figures 1 to 10 Based on the illustrated embodiment, when the debug button is the exception debug button, such as Figure 11As shown, with an electronic device as the execution subject, the method in this embodiment may include the following steps:

[0149] S701. If the abnormal debugging button is triggered, or if the abnormal debugging state triggered by the abnormal debugging button is not exited, a run signal is generated; wherein, the abnormal debugging state is entered when the abnormal debugging button is triggered.

[0150] The steps shown in this embodiment describe the execution process of a program module during abnormal debugging. During this process, the electronic device can determine whether the first program module, currently in a standby state, can run based on the two scenarios described above. In one scenario, when the abnormal debugging button is triggered, the electronic device generates a run signal. In the other scenario, when the abnormal debugging state entered upon triggering the button has not yet ended, the electronic device can determine that the current abnormal debugging has not encountered any abnormalities during operation and generate a run signal. This run signal is used to instruct the first program module, currently in a standby state, to run.

[0151] S702. In response to the run signal, wake up the first program module in the target program that is in the standby state, so that the first program module exits the standby state and runs.

[0152] S703. When the first program module finishes running, determine the second program module that succeeds the first program module based on the connection relationship between multiple program modules in the target program.

[0153] S704. Set the status of the second program module to the ready-to-run state.

[0154] Among them, the implementation of steps S702 to S704 is... Figure 2 The implementation of steps S102 to S104 in the embodiment is similar, and will not be repeated here.

[0155] S705. If the running result of the first program module is an abnormal operation, then exit the abnormal debugging state.

[0156] In this embodiment, after setting the running state of the second program module, the electronic device can determine whether the running result of the first program module is abnormal. If it is abnormal, it means that a program module with an abnormality has been found during the abnormal debugging process, and the abnormal debugging ends. Therefore, the electronic device can exit the abnormal debugging state when it determines that the running result of the first program module is abnormal.

[0157] Optionally, the electronic device can return to step S701 when the first program module's operation result is normal. After returning to step S701, the second program module will become the first program module. The electronic device will generate a running signal and continue running the target program with the first program module operating normally.

[0158] The software debugging method provided in this application allows an electronic device to generate a run signal when an abnormal debugging button is triggered. Alternatively, the electronic device can generate a run signal even before the abnormal interrupt signal triggered by the abnormal debugging button has exited. In response to the run signal, the electronic device can wake up a first program module in the target program that is in a standby state, causing the first program module to exit the standby state and run. After the first program module finishes running, the electronic device can determine the subsequent second program module based on the connection relationship between multiple program modules in the target program. The electronic device can set the state of the second program module to a standby state. After setting the standby state of the second program module, the electronic device can determine whether the running result of the first program module is an abnormal operation. If it is an abnormal operation, the abnormal debugging result is determined. This application, by using abnormal debugging, achieves a debugging method where the target program stops running at an abnormal point, improving the control flexibility during the execution of the target program.

[0159] In one implementation, when the exception debugging button is clicked, the electronic device can execute the following steps: Figure 12 As shown, it includes:

[0160] S801. Click the NG debug button. Optionally, the NG debug button can be an exception debug button. Optionally, NG can be used to refer to an exception during program execution.

[0161] S802. Entering abnormal debugging state. Optionally, the electronic device may have an abnormal debugging state flag set. When the abnormal debugging state flag is true, it indicates that the electronic device has entered the abnormal debugging state. When the abnormal debugging state flag is false, it indicates that the electronic device has exited the abnormal debugging state.

[0162] S803. Obtain the number of debug wait signals. The number of debug wait signals is the first number of the first program modules entering the standby state.

[0163] S804. Generate wake-up signals according to quantity. These wake-up signals can be named debug wait signals. Each wake-up signal can wake up a first program module that is in a standby state.

[0164] S805, the first program module in the standby state is awakened.

[0165] S806, First Program Module Running

[0166] S807. Determine whether the execution result of the first program module is a runtime exception. If yes, proceed to step 808. If no, proceed to step S813.

[0167] S808. Set the status of the first program module to Running NG. Running NG means running exception.

[0168] S809. Exit abnormal debugging state. Optionally, when the abnormal debugging state is marked as false, it indicates that the electronic device has exited the abnormal debugging state. The electronic device can modify the abnormal debugging state mark to false when it is determined that the first program module is running NG, thereby exiting the abnormal debugging state. Optionally, the exit of the abnormal debugging state can precede the operation of setting the second program module to the ready-to-run state.

[0169] S810, Increase the number of debug signal waiting items. Specifically, the electronic device can subtract the number of the first program modules from the number of debug signal waiting items and add the number of the second program modules to obtain a new number of debug signal waiting items. That is, obtain a new first number.

[0170] S811. Set the status of the second program module, which is the successor to the first program module, to be ready to run.

[0171] S812, Wait for the continue running signal. This continue running signal is a semaphore. In this step, the continue running signal will be generated when the breakpoint debugging button is triggered again.

[0172] S813. Set the status of the first program module to Running OK. Running OK means that it is running normally.

[0173] S814. Based on the connection relationship of multiple program modules in the target program, determine the second program module that succeeds the first program module.

[0174] Figure 13 The flowchart of a software debugging method provided in an embodiment of this application is shown. Figure 5 .exist Figures 1 to 12 Based on the illustrated embodiment, when the debug button is the stop debug button, as follows: Figure 13 As shown, with an electronic device as the execution subject, the method in this embodiment may include the following steps:

[0175] S901. If there is a first program module in a pending state, then generate a run signal.

[0176] In this embodiment, when the stop debugging button is triggered, the electronic device can obtain the trigger information of the stop debugging button. The electronic device can exit the debugging state based on this trigger information. After the electronic device exits the debugging state, the single-step debugging, breakpoint debugging, and exception debugging buttons will no longer be able to be triggered. When the electronic device determines that a first program module exists in a pending execution state, it will generate a run signal to allow the first program module to continue running.

[0177] Optionally, the Stop Debugging button will appear after the Start Debugging button is triggered.

[0178] In one example, after the stop debugging button is triggered, the electronic device also needs to perform the following operations:

[0179] Step 41: If you are in single-step debugging mode, exit single-step debugging mode.

[0180] Step 42: If you are in breakpoint debugging mode, exit breakpoint debugging mode.

[0181] In this step, the electronic device can set the breakpoint debugging state flag to false to exit the breakpoint debugging state.

[0182] Step 43: If in an abnormal debugging state, exit the abnormal debugging state.

[0183] In this step, the electronic device can set the abnormal debugging state flag to false to exit the abnormal debugging state. After exiting the abnormal debugging state, the target program will no longer be interrupted when an NG (Not Executable) error occurs.

[0184] Step 43: Exit debug mode.

[0185] In this step, once the electronic device exits debug mode, the buttons for single-step debugging, breakpoint debugging, and exception debugging will no longer be accessible. Furthermore, the stop debugging button will revert to the start debugging button.

[0186] S902. In response to the run signal, wake up the first program module in the target program that is in the standby state, so that the first program module exits the standby state and runs.

[0187] S903. When the first program module finishes running, determine the second program module that succeeds the first program module based on the connection relationship between multiple program modules in the target program.

[0188] S904. Set the status of the second program module to the ready-to-run state.

[0189] Among them, the implementation of steps S902 to S904 is... Figure 2The implementation of steps S102 to S104 in the embodiment is similar, and will not be repeated here. Optionally, after the state setting of the second program module is completed, the electronic device can return to step S901.

[0190] The software debugging method provided in this application allows the electronic device to exit the debugging state when the stop debugging button is triggered. If a first program module exists in a pending execution state, a execution signal is generated. The electronic device can respond to the execution signal to wake up the first program module in the target program that is in a pending execution state, causing the first program module to exit the pending execution state and run. After the first program module finishes running, the electronic device can determine the successor second program module based on the connection relationship among multiple program modules in the target program. The electronic device can then set the state of the second program module to a pending execution state. In this application, the debugging process can be terminated at any time by using the stop debugging method.

[0191] In one implementation, when the stop debugging button is clicked, the electronic device can execute the following steps: Figure 14 As shown, it includes:

[0192] S911. Click the Stop Debugging button. Optionally, the Stop Debugging button can be changed to the Stop Debugging button after the Start Debugging button is triggered.

[0193] S912. Exit debug mode, exit breakpoint debug mode, exit exception debug mode.

[0194] S913. Generate wake-up signals according to the number of program modules in the waiting state. These wake-up signals can be named debug wait signals. Each wake-up signal can wake up one of the first program modules in the waiting state.

[0195] S914. The first program module in the standby state is awakened and runs. S917. The first program module runs.

[0196] S915. Based on the connection relationship, determine whether a second program module exists. If yes, execute S916. If no, terminate the execution of the target program.

[0197] S916. Set the running status of the second program module to the standby state and return to S915.

[0198] Figure 15 This application provides a schematic diagram of the structure of a software debugging device according to an embodiment of the present application. Figure 15 As shown, the software debugging device 10 of this embodiment is used to implement the operation corresponding to the electronic device in any of the above method embodiments, wherein the target program includes a plurality of program modules connected in sequence, and the method, the software debugging device 10 of this embodiment includes:

[0199] The generation module 11 is used to generate a running signal when the debugging and running conditions are met;

[0200] The debugging module 12 is used to respond to the running signal, wake up the first program module in the target program that is in the standby state, so that the first program module exits the standby state and runs; when the first program module finishes running, it determines the second program module that succeeds the first program module according to the connection relationship of multiple program modules in the target program; and sets the state of the second program module to the standby state.

[0201] Optionally, the debug module 12 is used for:

[0202] Count the number of the first program modules that are in the pending execution state;

[0203] In response to the running signal, generate a first number of wake-up signals;

[0204] Use a wake-up signal to wake up the first program module, so that the first program module exits the standby state;

[0205] Run the first program module.

[0206] Optionally, the debugging operating conditions include:

[0207] The debug button has been triggered, or the debug button has not been triggered.

[0208] Optionally, when the debug button is a single-step debug button, module 11 is generated for:

[0209] If the single-step debugging button is triggered, a run signal is generated.

[0210] Optionally, after setting the state of the second program module to the ready-to-run state, the debug module 12 is used for:

[0211] The single-step debugging state is entered when the Exit Single-Step Debugging button is triggered.

[0212] Optionally, when the debug button is a breakpoint debug button, module 11 is generated for:

[0213] If the breakpoint debugging button is triggered, or if the breakpoint debugging state triggered by the breakpoint debugging button is not exited, a run signal is generated.

[0214] The breakpoint debugging mode is entered when the breakpoint debugging button is triggered.

[0215] Optionally, after setting the state of the second program module to the ready-to-run state, the debug module 12 is used for:

[0216] If the second program module contains breakpoints, exit the breakpoint debugging state.

[0217] Optionally, before the breakpoint debugging button is triggered, debugging module 12 is used for:

[0218] Set breakpoints on at least one program module of the target program.

[0219] Optionally, when the debug button is the exception debug button, module 11 is generated for:

[0220] If the abnormal debugging button is triggered, or if the abnormal debugging state triggered by the abnormal debugging button is not exited, a run signal is generated;

[0221] The abnormal debugging state is entered when the abnormal debugging button is triggered.

[0222] Optionally, after setting the state of the second program module to the ready-to-run state, the debug module 12 is used for:

[0223] If the first program module results in an error, then exit the error interruption state.

[0224] Optionally, when the stop debugging button is triggered, module 11 is generated for:

[0225] If there is a first program module in a pending state, a run signal is generated.

[0226] Optionally, debug module 12:

[0227] If you are in single-step debugging mode, exit single-step debugging mode;

[0228] If you are in breakpoint debugging mode, exit breakpoint debugging mode;

[0229] If in an abnormal debugging state, exit the abnormal debugging state;

[0230] Exit debug mode.

[0231] Optionally, the Stop Debugging button is displayed after the Start Debugging button is triggered.

[0232] Optionally, the debug module 12 is used for:

[0233] If the Start Debugging button is triggered, the system enters debug mode.

[0234] Optionally, the debug module 12 is used for:

[0235] Obtain the running result of the first program module, including whether the running is normal or abnormal;

[0236] When the first program module results in an error, the first program module is marked with the first diagram; when the first program module results in a normal operation, the first program module is marked with the second diagram.

[0237] Optionally, the debug module 12 is used for:

[0238] When the first program module is running, the first program module is labeled using the third diagram.

[0239] The software debugging device 10 provided in this application embodiment can execute the above method embodiment. Its specific implementation principle and technical effect can be found in the above method embodiment, and will not be repeated here.

[0240] Figure 16 A schematic diagram of the hardware structure of an electronic device according to an embodiment of this application is shown. Figure 16 As shown, the electronic device 20 is used to implement the operation corresponding to the electronic device in any of the above method embodiments. The electronic device 20 in this embodiment may include: a memory 21, a processor 22, and a display 24.

[0241] The memory 21 is used to store computer programs. The memory 21 may include high-speed random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device, and may also be a USB flash drive, external hard drive, read-only memory, disk or optical disc, etc.

[0242] Processor 22 is used to execute computer programs stored in memory to implement the software debugging method in the above embodiments. For details, please refer to the relevant descriptions in the foregoing method embodiments. The processor 22 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly manifested as execution by a hardware processor, or execution by a combination of hardware and software modules within the processor.

[0243] Alternatively, the memory 21 can be either standalone or integrated with the processor 22.

[0244] When the memory 21 is a device independent of the processor 22, the electronic device 20 may also include a bus 23. This bus 23 is used to connect the memory 21 and the processor 22. The bus 23 may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0245] The display 24 can be connected to the processor 21 via the bus 23. The processor 22 can display the target software and debugging buttons on the display 24, and the processor 22 can also acquire trigger information generated when the user operates the display 24.

[0246] The electronic device provided in this embodiment can be used to execute the above-described software debugging method. Its implementation method and technical effect are similar, and will not be described again in this embodiment.

[0247] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, is used to implement the methods provided in the various embodiments described above.

[0248] The computer-readable storage medium can be a computer storage medium or a communication medium. A communication medium includes any medium that facilitates the transfer of a computer program from one location to another. A computer storage medium can be any available medium accessible to a general-purpose or special-purpose computer. For example, a computer-readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the computer-readable storage medium. Of course, the computer-readable storage medium can also be a component of the processor. The processor and the computer-readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the ASIC can reside in a user equipment. Of course, the processor and the computer-readable storage medium can also exist as discrete components in a communication device.

[0249] Specifically, the computer-readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The storage medium can be any available medium accessible to general-purpose or special-purpose computers.

[0250] This application also provides a computer program product comprising a computer program stored in a computer-readable storage medium. At least one processor of the device can read the computer program from the computer-readable storage medium, and the at least one processor executes the computer program to cause the device to implement the methods provided in the various embodiments described above.

[0251] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0252] The modules can be physically separate, for example, installed in different locations within a single device, installed on different devices, distributed across multiple network units, or distributed across multiple processors. Alternatively, the modules can be integrated, for example, installed in the same device, or integrated into a single codebase. The modules can exist in hardware form, software form, or a combination of both. This application can select some or all of the modules to achieve the objectives of this embodiment based on actual needs.

[0253] When the various modules are implemented as integrated software functional modules, they can be stored in a computer-readable storage medium. The aforementioned software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods of the various embodiments of this application.

[0254] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some of the steps in the figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0255] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A software debugging method, characterized in that, A method for debugging a target program built on vision software, wherein the target program includes a grouping module, the grouping module being composed of multiple sequentially connected program modules, the program modules being used to perform machine vision tasks, the method comprising: If the debugging and operation conditions are met, a running signal is generated; The first number of first program modules in the waiting state is determined by counting the number of waiting functions called; the first number is: 1 when the first program module is in the main flow; when the first program module is in the branch flow, the first number is determined according to the number of branches in the current branch flow. In response to the running signal, the first number of wake-up signals are generated; In response to receiving the wake-up signal, the waiting function corresponding to the first program module ends, and each of the first program modules exits the standby state and starts running; When any of the first program modules completes execution, the second program module that follows the first program module is determined according to the connection relationship of the multiple program modules in the target program. The waiting function corresponding to the second program module is called to put the second program module into a standby state.

2. The method according to claim 1, characterized in that, The debugging conditions include: the debugging button is triggered, or the state of not exiting the state triggered by the debugging button is not exited.

3. The method according to claim 1 or 2, characterized in that, When the debug button is a single-step debug button, a run signal is generated if the debug run conditions are met, including: If the single-step debugging button is triggered, the running signal is generated.

4. The method according to claim 3, characterized in that, After setting the state of the second program module to the ready-to-run state, the method further includes: Exit the single-step debugging state entered when the single-step debugging button is triggered.

5. The method according to claim 1 or 2, characterized in that, When the debug button is the breakpoint debug button, a run signal is generated if the debug run conditions are met, including: If the breakpoint debugging button is triggered, or if the breakpoint debugging state triggered by the breakpoint debugging button is not exited, then the run signal is generated; The breakpoint debugging state is entered when the breakpoint debugging button is triggered.

6. The method according to claim 5, characterized in that, After setting the state of the second program module to the ready-to-run state, the method further includes: If the second program module contains breakpoints, exit the breakpoint debugging state.

7. The method according to claim 5, characterized in that, Before the breakpoint debugging button is triggered, the method further includes: Set breakpoints on at least one program module of the target program.

8. The method according to claim 1 or 2, characterized in that, When the debug button is the abnormal debug button, a run signal is generated if the debug run conditions are met, including: If the abnormal debugging button is triggered, or if the abnormal debugging state triggered by the abnormal debugging button is not exited, then the running signal is generated; The abnormal debugging state is entered when the abnormal debugging button is triggered.

9. The method according to claim 8, characterized in that, After setting the state of the second program module to the ready-to-run state, the method further includes: If the first program module results in an error, then exit the error interruption state.

10. The method according to claim 1 or 2, characterized in that, When the stop debugging button is triggered, the method includes: If there is a first program module in a pending state, a run signal is generated.

11. The method according to claim 10, characterized in that, The method further includes: If you are in single-step debugging mode, exit single-step debugging mode; If you are in breakpoint debugging mode, exit breakpoint debugging mode; If in an abnormal debugging state, exit the abnormal debugging state; Exit debug mode.

12. The method according to claim 10, characterized in that, The Stop Debugging button is displayed after the Start Debugging button is triggered.

13. The method according to claim 1 or 2, characterized in that, The method further includes: If the Start Debugging button is triggered, the system enters debug mode.

14. The method according to claim 1 or 2, characterized in that, When the first program module completes execution, the method further includes: Obtain the running result of the first program module, wherein the running result includes running normally or running abnormally; When the first program module results in an error, the first program module is marked with a first diagram; when the first program module results in a normal operation, the first program module is marked with a second diagram.

15. The method according to claim 1 or 2, characterized in that, The method further includes: When the first program module is running, the first program module is labeled using a third diagram.

16. A software debugging device, characterized in that, An apparatus for debugging a target program built on vision software, wherein the target program includes a grouping module, the grouping module comprising multiple sequentially connected program modules, the program modules being used to perform machine vision tasks, the apparatus comprising: The generation module is used to generate a running signal when the debugging and running conditions are met. The debugging module is used to determine the first number of first program modules in the standby state by counting the number of called wait functions; the first number is: 1 when the first program module is on the main flow; when the first program module is on a branch flow, the first number is determined according to the number of branches in the current branch flow; in response to a run signal, the first number of wake-up signals are generated; in response to receiving the wake-up signals, the waiting function corresponding to the first program module ends, and each first program module exits the standby state and runs; when any first program module finishes running, the successor second program module is determined according to the connection relationship of multiple program modules in the target program; the wait function corresponding to the second program module is called to make the second program module enter the standby state.

17. An electronic device, characterized in that, The electronic device includes: a memory and a processor; The memory is used to store a computer program; the processor is used to implement the method as described in any one of claims 1 to 15 according to the computer program stored in the memory.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, is used to implement the method as described in any one of claims 1 to 15.

19. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method according to any one of claims 1 to 15.

Images