A simulation debugging system and method for a 51 single-chip microcomputer simulator with double threads

Abstract

The application provides a simulation debugging system and method of a 51 single-chip microcomputer simulator with double threads, which comprises a debugger for inputting a debugging command, sending the debugging command to the simulator through a communication port after analyzing the debugging command, a main control program of the simulator, a plurality of debugging functions for realizing the debugging command and a checking program for checking an interrupt signal arranged in the main control program, a main thread and a listening thread created, the main thread being used for loading and executing a 51 single-chip microcomputer program, the listening thread being used for information interaction with the debugger, analyzing the received debugging command, calling the corresponding debugging function to execute a debugging operation, and feeding back a debugging result to the debugger. The application establishes communication between the simulator and the debugger and creates double threads, so that the simulator can execute the main thread and realize various debugging operations on the 51 single-chip microcomputer program through the listening thread, thereby realizing the debugging function of the 51 single-chip microcomputer simulator and improving the development efficiency of the single-chip microcomputer.

Description

Technical Field

[0001] This invention relates to the field of simulation and debugging technology, and specifically to a simulation and debugging system and method for a 51 microcontroller emulator with dual threads. Background Technology

[0002] A single-chip microcomputer (MCU) is an integrated circuit chip that uses very large-scale integrated circuit (VLSI) technology to integrate a central processing unit (CPU) with data processing capabilities, memory, various I / O ports, interrupt systems, timers / counters, and other functions onto a single silicon chip, thus forming a small but complete microcomputer system. Among them, the 51 microcontroller is widely used in various fields due to its simple instruction set, small size, low power consumption, and abundant on-chip resources. In the industrial field, it can be used for PLCs, sensor interfaces, and data acquisition; in the home appliance field, it is commonly used for controlling household appliances such as washing machines, air conditioners, and microwave ovens; in the education field, it can be used as a teaching tool for computer science, electrical engineering, and other professional courses. Therefore, the 51 microcontroller has high development demand. Among them, the 51 microcontroller emulator is a tool that provides a simulation environment for the design of 51 microcontrollers and related circuits. It can perform virtual simulation of 51 microcontroller systems at the software level, including virtual simulation of 51 microcontroller central processing unit, various registers, memory and other components. It enables the running of 51 microcontroller programs on the emulator, so that the developed microcontroller programs can still be verified and tested without the 51 microcontroller hardware.

[0003] See Figure 1 To fully simulate the functionality of a 51 microcontroller, existing emulators must simulate the chip's central processing unit (CPU), including instruction fetching, instruction translation, instruction execution, memory access, and data write-back. However, because existing 51 microcontroller emulators lack debugging capabilities and do not support online debugging, it is difficult to directly obtain the values ​​of various registers, program variables, and the current code location during program execution. This makes it difficult for developers to promptly identify the causes of problems and pinpoint the problematic code, significantly slowing down the development process and reducing the efficiency of 51 microcontroller development.

[0004] Therefore, there is a need for a dual-threaded simulation and debugging system and method that can realize the debugging function of 51 microcontroller emulator and improve the development efficiency of microcontroller. Summary of the Invention

[0005] This invention provides a simulation and debugging system and method for a 51 microcontroller emulator with dual threads. It is mainly used to solve the problems of existing 51 microcontroller emulators lacking debugging functions, which leads to the inability to detect and correct errors in the program in a timely manner and low microcontroller development efficiency. This invention achieves the effect of realizing the debugging function of the 51 microcontroller emulator and improving the microcontroller development efficiency.

[0006] The present invention achieves the above objectives through the following technical solutions:

[0007] A simulation and debugging system for a 51 microcontroller emulator with dual threads, comprising:

[0008] A debugger and an emulator establish a data communication connection. The debugger is used to input debug commands, parse the debug commands, and send them to the emulator through a communication port. The main program of the emulator is the 51 microcontroller program to be simulated and tested. Its main control program also includes several debug functions for implementing the debug commands and a check program for checking interrupt signals. The emulator creates a main thread and a listening thread. The main thread is used to load and execute the 51 microcontroller program, and uses the check program to check whether the current instruction address of the 51 microcontroller program will trigger a breakpoint or whether there is a manually input interrupt signal. Based on the check results, it feeds back the current instruction address and breakpoint information to the debugger. The listening thread is used to interact with the debugger, parse the received debug commands, call the corresponding debug functions to perform debug operations, and feed back the debug results to the debugger.

[0009] A further approach is to establish a TCP communication connection between the emulator and the debugger through a TCP communication port, with the emulator continuously listening to its TCP communication port to wait for the debugging command.

[0010] A further approach is that the debugging commands are used to view and modify the program status in real time, including but not limited to: breakpoint commands, single-step execution commands, variable viewing commands, memory viewing commands, and register viewing commands.

[0011] A further approach is to use the breakpoint command as: break + instruction address.

[0012] The command to view memory is: readmemory + memory address.

[0013] The command to view the registers is: regvalues.

[0014] A further approach is that the debugging functions correspond one-to-one with the debugging commands, including but not limited to: breakpoint functions, single-step execution functions, variable viewing functions, memory viewing functions, and register viewing functions.

[0015] A further approach is that the simulator configures program counters PC and nPC values ​​during the "fetch instruction" phase of the 51 microcontroller program execution. These values ​​are used to indicate the address locations of the current instruction and the next instruction in the main memory, respectively. The checking program is used to check whether the address of the current instruction will trigger a breakpoint or whether there is a manually input interrupt signal.

[0016] A further approach is that when the checking program detects that the current instruction address will trigger a breakpoint or that there is a manually input interrupt signal, the main program pauses its execution, and the simulator feeds back the current instruction address and breakpoint information as the debugging result to the debugger.

[0017] A further approach is for the debugger to encapsulate and display the debugging results in a standard data format.

[0018] A simulation and debugging method for a dual-threaded 51 microcontroller emulator, applied to the aforementioned simulation and debugging system for a dual-threaded 51 microcontroller emulator, includes:

[0019] S1: The emulator's main program includes debugging functions and a checker program, and creates a main thread and a listener thread. The main thread loads and executes the 51 microcontroller program. The listener thread establishes a TCP communication connection with the debugger.

[0020] S2: The listening thread continuously listens to the TCP port, waiting for debugging commands from the debugger.

[0021] S3: Upon receiving the debugging command, the listening thread parses the debugging command and calls the corresponding debugging function to perform the debugging operation according to the parsed structure.

[0022] S4: The listening thread sends the debugging results to the debugger and repeats step S2.

[0023] A further solution is that, when the main thread executes the 51 microcontroller program in step S1, it also includes:

[0024] S11: The main thread checks whether the current instruction address will trigger a breakpoint or whether there is a manually input interrupt signal.

[0025] S12: If yes, the main program pauses execution and sends the current instruction address and breakpoint information as the debugging result to the debugger. If no, repeat step S11.

[0026] Therefore, the present invention has the following beneficial effects:

[0027] 1. This invention establishes a communication connection between the debugger and the emulator, and creates dual threads in the emulator to enable parallel processing capabilities. While the emulator executes the 51 microcontroller program in the main thread, it receives debugging commands and performs various debugging operations on the 51 microcontroller program through a listening thread. This allows developers to directly locate the problematic code in the 51 microcontroller program and greatly reduces the difficulty of finding the cause of the problem by viewing variables, registers, and other debugging operations. The dual-thread task processing improves the overall processing capability and response speed of the program, thereby improving the overall development efficiency of the 51 microcontroller.

[0028] 2. This invention adds a checking program to the main program of the simulator. The checking program checks whether the current instruction address of the main program will trigger breakpoints and other operations. If a breakpoint is triggered, the main program pauses and feeds back the current instruction address, breakpoint information and other information as debugging results to the debugger. Developers can then obtain debugging information on the debugger. This invention enables the simulator to correctly identify breakpoint markers and correctly complete the corresponding debugging operations.

[0029] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments. Attached Figure Description

[0030] Figure 1 This is a schematic diagram of the instruction processing process of the existing 51 microcontroller emulator.

[0031] Figure 2 This is a schematic diagram of the simulation and debugging system according to an embodiment of the present invention.

[0032] Figure 3 This is a flowchart of the simulation debugging method according to an embodiment of the present invention. Detailed Implementation

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

[0034] An embodiment of a simulation and debugging system for a dual-threaded 51 microcontroller emulator.

[0035] See Figure 2 The present invention relates to a simulation and debugging system for a dual-threaded 51 microcontroller emulator, comprising:

[0036] A debugger 10 and an emulator 20 establish a data communication connection. The debugger 10 is used to input debug commands, parse the debug commands, and send them to the emulator 20 through the communication port. The main program of the emulator 20 is the 51 microcontroller program to be simulated and tested. Its main control program also includes several debug functions for implementing the debug commands and a check program for checking interrupt signals. The emulator 20 creates a main thread and a listening thread. The main thread is used to load and execute the 51 microcontroller program, and check whether the current instruction address of the 51 microcontroller program will trigger a breakpoint or whether there is a manually input interrupt signal through the check program. Based on the check results, the current instruction address and breakpoint information are fed back to the debugger 10. The listening thread is used to interact with the debugger 10, parse the received debug commands, call the corresponding debug functions to perform debug operations, and feed back the debug results to the debugger 10.

[0037] Specifically, in this embodiment, the debugger 10 can establish a communication connection with the 51 microcontroller system and has a main program for initializing various debugging functions, including interaction with the emulator 20, setting breakpoints, single-step execution, viewing register and memory information, etc. It controls and tracks the program execution process of the emulator 20 through system debugging instructions provided by the operating system. It can single-step execute code, set and trigger breakpoints, check the values ​​of variables and trace the stack, and modify memory contents and register values, thereby observing different execution paths and results of the program.

[0038] Specifically, in this embodiment, the debugger 10 can be configured and customized in the integrated development environment (IDE), and the customized debugger can be placed in a specified directory for corresponding configuration.

[0039] In this embodiment, the emulator 20 and the debugger 10 establish a TCP communication connection through a TCP communication port, and the emulator 20 continuously listens to its TCP communication port to wait for the debugging command.

[0040] Specifically, this embodiment uses the TCP transport layer communication protocol based on byte streams. Before sending debugging commands, a communication connection needs to be established between the emulator 20 and the debugger 10. This is achieved by initializing the communication connection through a three-way handshake and releasing the connection through a four-way handshake after data transmission is completed. Furthermore, TCP ensures reliable data transmission through mechanisms such as acknowledgment and timeout retransmission, guaranteeing data arrival at the receiving end even under changes in the communication link, thus achieving reliable data transmission.

[0041] In this embodiment, the debugging commands are used to view and modify the program status in real time, including but not limited to: breakpoint commands, single-step execution commands, variable viewing commands, memory viewing commands, and register viewing commands.

[0042] In this embodiment, the breakpoint command is: break + instruction address.

[0043] The command to view memory is: readmemory + memory address.

[0044] The command to view the registers is: regvalues.

[0045] In this embodiment, the debugging functions correspond one-to-one with the debugging commands, including but not limited to: breakpoint function: break_handler, single-step execution function: step_handler / next_handler, variable viewing function: read_var_handler, memory viewing function: read_memory_handler, and register viewing function: read_reg_handler.

[0046] Specifically, the debugging functions described in this embodiment also include: a continuous execution function: continue_handler, a pause execution function: stop_handler, a breakpoint viewing function: break_list_handler, a breakpoint deletion function: break_delete_handler, a register write function: write_reg_handler, a memory write function: write_memory_handler, and a variable write function: write_var_handler.

[0047] In this embodiment, the emulator 20 configures the program counter PC and nPC values ​​during the "fetch instruction" stage of the 51 microcontroller program execution. These values ​​are used to indicate the address locations of the current instruction and the next instruction in the main memory, respectively. The checking program is used to check whether the address of the current instruction will trigger a breakpoint or whether there is a manually input interrupt signal.

[0048] In this embodiment, when the checking program detects that the current instruction address will trigger a breakpoint or that there is a manually input interrupt signal, the main program pauses its operation, and the simulator 20 feeds back the current instruction address and breakpoint information as the debugging result to the debugger 10.

[0049] Specifically, in this embodiment, when the simulator 20 receives a breakpoint command, it sets a breakpoint marker at the line or function entry point specified by the breakpoint command. The checker will trigger the breakpoint when it detects the current instruction address.

[0050] Meanwhile, when the main program in the simulator 20 attempts to retrieve the instruction at that address during execution, a breakpoint is triggered and execution is paused. The current instruction address and breakpoint information are then fed back to the debugger 10 as the debugging result.

[0051] Specifically, in this embodiment, the debugger 10 can integrate all the functions used for debugging into an executable program through software, and start the program on the PC for debugging. Debugging commands can be output to the emulator 20 by manually inputting debugging signals, such as sending an interrupt signal by pressing Ctrl+C.

[0052] In this embodiment, the debugger 10 encapsulates and displays the debugging results in a standard data format.

[0053] Specifically, this embodiment can improve the readability, maintainability and reusability of data code by encapsulating the debugging results. It can also hide the data inside the class and only provide the necessary access interface to the outside, thereby protecting the security of the data and facilitating program development.

[0054] An embodiment of a simulation and debugging method for a dual-threaded 51 microcontroller emulator 20

[0055] See Figure 3 The present invention relates to a simulation and debugging method for a dual-threaded 51 microcontroller emulator 20, which is applied to the simulation and debugging system of the dual-threaded 51 microcontroller emulator 20, and includes:

[0056] S1: The main program of the emulator 20 sets up debugging functions and inspection programs, and creates a main thread and a listening thread. The main thread loads and executes the 51 microcontroller program. The listening thread establishes a TCP communication connection with the debugger 10.

[0057] S2: The listening thread continuously listens to the TCP port, waiting for debugging commands from debugger 10.

[0058] S3: Upon receiving the debugging command, the listening thread parses the debugging command and calls the corresponding debugging function to perform the debugging operation according to the parsed structure.

[0059] S4: The listening thread sends the debugging results to debugger 10 and repeats step S2.

[0060] In this embodiment, when the main thread executes the 51 microcontroller program in step S1, it further includes:

[0061] S11: The main thread checks whether the current instruction address will trigger a breakpoint or whether there is a manually input interrupt signal.

[0062] S12: If yes, the main program pauses execution and sends the current instruction address and breakpoint information as the debugging result to debugger 10. If no, repeat step S11.

[0063] Specifically, the simulation debugging method in this embodiment also includes the following on the debugger 10 end:

[0064] a. The debugger 10 loads and parses the CDB (directory database) file in its main program, and establishes a TCP communication connection with the emulator 20 through the TCP port.

[0065] Specifically, in this embodiment, a program written in TCP can be used to send, receive, or listen for data.

[0066] b. Debugger 10 is waiting for the input of a debug command.

[0067] c. After receiving the input debugging command, debugger 10 parses the debugging command and sends the parsed debugging command to emulator 20 through the TCP port.

[0068] d. The main program of debugger 10 receives the debugging results returned by emulator 20 after executing the debugging command, encapsulates the debugging results in a standard data format, and returns them to the user.

[0069] e. Repeat step b until the main program in simulator 20 finishes execution.

[0070] The above embodiments are merely preferred embodiments of the present invention and should not be construed as limiting the scope of protection of the present invention. Any non-substantial changes and substitutions made by those skilled in the art based on the present invention shall fall within the scope of protection claimed by the present invention.

Claims

1. A simulation and debugging system for a 51 microcontroller emulator with dual threads, characterized in that, include: A debugger and an emulator establish a data communication connection. The debugger is used to input debug commands, parse the debug commands, and send them to the emulator through a communication port. The main program of the emulator is the 51 microcontroller program to be simulated and tested. Its main control program also includes several debug functions for implementing the debug commands and a check program for checking interrupt signals. The emulator creates a main thread and a listening thread. The main thread is used to load and execute the 51 microcontroller program, and uses the check program to check whether the current instruction address of the 51 microcontroller program will trigger a breakpoint or whether there is a manually input interrupt signal. Based on the check results, it feeds back the current instruction address and breakpoint information to the debugger. The listening thread is used to interact with the debugger, parse the received debug commands, call the corresponding debug functions to perform debug operations, and feed back the debug results to the debugger. The simulator configures program counters PC and nPC values ​​during the "fetch instruction" phase of the 51 microcontroller program. These values ​​indicate the address locations of the current instruction and the next instruction in the main memory, respectively. The checking program checks whether the address of the current instruction will trigger a breakpoint or whether there is a manually input interrupt signal. If so, the main program pauses execution, and the simulator feeds back the current instruction address and breakpoint information as debugging results to the debugger.

2. The simulation and debugging system for a 51 microcontroller emulator with dual threads according to claim 1, characterized in that: The emulator and debugger establish a TCP communication connection through a TCP communication port, and the emulator continuously listens to its TCP communication port to wait for the debugging command.

3. The simulation and debugging system for a 51 microcontroller emulator with dual threads according to claim 1, characterized in that: The debugging commands are used to view and modify the program status in real time, including but not limited to: breakpoint commands, single-step execution commands, variable viewing commands, memory viewing commands, and register viewing commands.

4. The simulation and debugging system for a 51 microcontroller emulator with dual threads according to claim 3, characterized in that: The breakpoint command is: break + instruction address; The command to view memory is: readmemory + memory address; The command to view the registers is: regvalues.

5. The simulation and debugging system for a 51 microcontroller emulator with dual threads according to claim 3, characterized in that: The debugging functions correspond one-to-one with the debugging commands, including but not limited to: breakpoint functions, single-step execution functions, variable viewing functions, memory viewing functions, and register viewing functions.

6. The simulation and debugging system for a 51 microcontroller emulator with dual threads according to claim 1, characterized in that: The debugger encapsulates and displays the debugging results in a standard data format.

7. A simulation and debugging method for a 51 microcontroller emulator with dual threads, characterized in that, A simulation and debugging system for a dual-threaded 51 microcontroller emulator as described in any one of claims 1-6, comprising: S1: The emulator's main program sets up debugging functions and checking programs, and creates a main thread and a listening thread. The main thread loads and executes the 51 microcontroller program; the listening thread establishes a TCP communication connection with the debugger. S2: The listening thread continuously listens to the TCP port, waiting for debugging commands from the debugger; S3: Upon receiving the debugging command, the listening thread parses the debugging command and calls the corresponding debugging function to perform the debugging operation according to the parsed structure; S4: The listening thread sends the debugging results to the debugger and repeats step S2.

8. The simulation and debugging method for a dual-threaded 51 microcontroller emulator according to claim 7, characterized in that, When the main thread executes the 51 microcontroller program in step S1, it also includes: S11: The main thread checks whether the current instruction address will trigger a breakpoint or whether there is a manually input interrupt signal; S12: If yes, the main program will pause running and send the current instruction address and breakpoint information as the debugging result to the debugger; if no, repeat step S11.

Images