A debugging system and application method for a distributed host-free control system

Abstract

The present invention discloses an application method and system of a debugging system for a distributed hostless control system, and relates to the field of communication technology. The invention comprises a debugging system for a distributed hostless control system, comprising a plurality of sites, an MCU core, and firmware run by the MCU core; each site is connected to a separate functional device; the MCU core is respectively connected to each of the sites through peripherals; each site comprises a kernel logic diagram and a kernel device driver connected to a corresponding functional device; the firmware comprises a parser of the kernel logic diagram and a driver code of the kernel device driver; the parser monitors all state data during the operation of the kernel logic diagram through a memory interface controlled by debugging, and simultaneously controls the instructions during the operation of the kernel logic diagram. The debugging system of the distributed hostless control system is realized in the form of a chip, which solves the problem that real-time logic diagram debugging cannot be performed, and the communication interaction between sites requires additional programs to control.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to a debugging system and an application method of a distributed host-free control system. Background Art

[0002] The debugging system of a distributed hostless control system faces the need to maintain reliability and stability while being small in size. However, the existing mature MCU (microcontroller) cores or other controllers on the market cannot meet these requirements because their peripherals and communication functions have been basically finalized and it is difficult to make major changes. In addition, the debugging system of a distributed hostless control system cannot perform real-time logic diagram debugging, and the communication interaction between sites requires additional programs to control. Therefore, using a single mature MCU core to implement a debugging system for a distributed hostless control system cannot solve these problems. At present, how to realize chip-based debugging systems for distributed hostless control systems is a difficult problem in the development of existing technologies. Summary of the invention

[0003] The technical problem to be solved by the present invention is to realize the chipization of the debugging system of the distributed host-free control system. The purpose is to provide a debugging system and application method of the distributed host-free control system, which solves the problem that real-time logic diagram debugging cannot be performed and the communication interaction between sites requires additional programs to control, thereby meeting the requirements of reliability and stability.

[0004] The present invention is achieved through the following technical solutions:

[0005] A debugging system for a distributed host-free control system comprises a plurality of sites, an MCU core and firmware run by the MCU core; each of the sites is connected to a separate functional device; the MCU core is connected to each of the sites via peripherals; each of the sites comprises a core logic diagram and a core device driver connected to the corresponding functional device; the firmware comprises a parser for the core logic diagram and driver code for the core device driver; the parser monitors all status data during the operation of the core logic diagram via a memory interface controlled by debugging, and simultaneously controls the instructions of the core logic diagram during operation.

[0006] The method in which the parser monitors all state data during the operation of the kernel logic diagram through a debug-controlled memory interface and controls the instructions of the kernel logic diagram during operation, includes:

[0007] A continuous memory area is used as debug memory to store breakpoint steps. When the real-time running steps are consistent with the above breakpoint steps, an infinite loop is entered. At the same time, the data of the above peripherals when the above kernel logic diagram is running is stored in the common memory, which is used to interact with the above peripherals and the above kernel device driver respectively; and the instruction data and chip mapping data are stored in the debug memory, which is used to map the instruction data controlling the operation of the above kernel logic diagram using the above chip mapping data, so as to debug the above MCU kernel and the communication of the above MCU kernel.

[0008] The method for debugging the MCU core includes: interrupting the operation of the MCU core; and implementing a breakpoint function for a single instruction of the MCU core;

[0009] The method for debugging the communication of the MCU core includes: the peripherals are connected to the above-mentioned sites via a bus; controlling the bidirectional access between the MCU core and the above-mentioned debug memory, controlling the bidirectional access between the above-mentioned bus and the above-mentioned debug memory, and the read and write operations on the above-mentioned common memory.

[0010] The above-mentioned method of controlling the bidirectional access between the above-mentioned MCU core and the above-mentioned debug memory, or the above-mentioned method of controlling the bidirectional access between the above-mentioned bus and the above-mentioned debug memory, includes: monitoring and modifying the data in the above-mentioned debug memory; providing an editable logic formula to monitor certain data in the above-mentioned debug memory, and when the data changes and satisfies the operation result of the above-mentioned logic formula, interrupting the operation of the above-mentioned MCU core.

[0011] The method for monitoring and modifying the data in the debug memory comprises: the MCU core modifies the data in the debug memory through the bus; the bus is controlled by directly reading and writing data, and the communication method of the bus is invisible to the reading and writing users; the MCU core monitors the data in the debug memory through the debug communication circuit.

[0012] When the MCU core monitors the data in the debug memory through the debug communication circuit, the data in the debug memory is synchronized to the debug standby memory at the same time, and the data in the debug standby memory is provided to the user for viewing.

[0013] The method of controlling the bidirectional access between the MCU core and the debug memory, or the method of controlling the bidirectional access between the bus and the debug memory, comprises: a user monitors all data in the debug memory, and adds memory addresses or relays to be monitored.

[0014] The above peripherals include standard peripherals and custom peripherals; the above standard peripherals include any one or more of ordinary IO ports, partial serial port communications, SPI communications and timers; the above custom peripherals include logic diagram programming chips.

[0015] An application method of a debugging system for a distributed host-free control system includes: abstractly transplanting the parser of the kernel logic diagram and the driver code of the kernel device driver to a virtual operating environment, and performing simulation debugging with a programming tool of the kernel logic diagram.

[0016] The method of abstractly transplanting the parser of the kernel logic graph and the driver code of the kernel device driver to the virtual operating environment includes the following steps:

[0017] The first method is to classify the above-mentioned sites corresponding to the functional devices with high reliability into virtual sites, and classify the above-mentioned sites corresponding to the functional devices with low reliability into physical sites; the above-mentioned virtual sites are implemented in a virtual operating environment and combined with the above-mentioned physical sites;

[0018] The second type: each of the above-mentioned sites is set on the core board, and a standardized interface is provided to splice any number of the above-mentioned sites;

[0019] The third method: convert all the above sites into programs, each process in the program represents a site, and convert all hardware interfaces into abstract program interfaces.

[0020] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0021] The present invention realizes the method of chip-based debugging system of distributed host-free control system and running compiled firmware using MCU kernel, including parser firmware of kernel logic diagram and driver code of kernel device driver; MCU kernel is respectively connected to the kernel logic diagram of each site and the kernel device driver of functional device through peripherals; parser firmware can monitor all status data in the kernel logic diagram running process through the memory interface of debugging control, and control the instructions of the kernel logic diagram when running at the same time, so as to perform real-time logic diagram debugging, and the communication interaction between sites no longer needs additional program to control, thus meeting the requirements of reliability and stability. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the technical solutions of the exemplary embodiments of the present invention, the following briefly introduces the drawings required for use in the embodiments. It should be understood that the following drawings only illustrate certain embodiments of the present invention and should not be regarded as limiting the scope. For those of ordinary skill in the art, other relevant drawings can be obtained based on these drawings without creative work. In the drawings:

[0023] Figure 1 This is a schematic diagram of the principles of the debugging system of the distributed host-less control system according to Example 1 of the present application. DETAILED DESCRIPTION

[0024] In order to make the objectives, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with embodiments and drawings. The exemplary implementation modes of the present invention and their description are only used to explain the present invention and are not intended to limit the present invention.

[0025] Example 1

[0026] like Figure 1 As shown, an embodiment of the present application provides a debugging system for a distributed host-free control system, including multiple sites, an MCU core and firmware run by the above-mentioned MCU core; each of the above-mentioned sites is connected to a separate functional device; the above-mentioned MCU core is connected to each of the above-mentioned sites through peripherals; each of the above-mentioned sites includes a kernel logic diagram and a kernel device driver connected to the corresponding above-mentioned functional device; the above-mentioned firmware includes a parser of the above-mentioned kernel logic diagram and a driver code of the above-mentioned kernel device driver; the above-mentioned parser monitors all status data during the operation of the above-mentioned kernel logic diagram through a memory interface controlled by debugging, and at the same time controls the instructions of the above-mentioned kernel logic diagram during operation.

[0027] The method in which the parser monitors all state data during the operation of the kernel logic diagram through a debug-controlled memory interface and controls the instructions of the kernel logic diagram during operation, includes:

[0028] A continuous memory area is used as debug memory to store breakpoint steps. When the real-time running steps are consistent with the above breakpoint steps, an infinite loop is entered. At the same time, the data of the above peripherals when the above kernel logic diagram is running is stored in the common memory, which is used to interact with the above peripherals and the above kernel device driver respectively; and the instruction data and chip mapping data are stored in the debug memory, which is used to map the instruction data controlling the operation of the above kernel logic diagram using the above chip mapping data, so as to debug the above MCU kernel and the communication of the above MCU kernel.

[0029] The method for debugging the MCU core includes: interrupting the operation of the MCU core; and implementing a breakpoint function for a single instruction of the MCU core;

[0030] The method for debugging the communication of the MCU core includes: the peripherals are connected to the above-mentioned sites via a bus; controlling the bidirectional access between the MCU core and the above-mentioned debug memory, controlling the bidirectional access between the above-mentioned bus and the above-mentioned debug memory, and the read and write operations on the above-mentioned common memory.

[0031] The above-mentioned method of controlling the bidirectional access between the above-mentioned MCU core and the above-mentioned debug memory, or the above-mentioned method of controlling the bidirectional access between the above-mentioned bus and the above-mentioned debug memory, includes: monitoring and modifying the data in the above-mentioned debug memory; providing an editable logic formula to monitor certain data in the above-mentioned debug memory, and when the data changes and satisfies the operation result of the above-mentioned logic formula, interrupting the operation of the above-mentioned MCU core.

[0032] The method for monitoring and modifying the data in the debug memory comprises: the MCU core modifies the data in the debug memory through the bus; the bus is controlled by directly reading and writing data, and the communication method of the bus is invisible to the reading and writing users; the MCU core monitors the data in the debug memory through the debug communication circuit.

[0033] When the MCU core monitors the data in the debug memory through the debug communication circuit, the data in the debug memory is synchronized to the debug standby memory at the same time, and the data in the debug standby memory is provided to the user for viewing.

[0034] The method of controlling the bidirectional access between the MCU core and the debug memory, or the method of controlling the bidirectional access between the bus and the debug memory, comprises: a user monitors all data in the debug memory, and adds memory addresses or relays to be monitored.

[0035] The above peripherals include standard peripherals and custom peripherals; the above standard peripherals include any one or more of ordinary IO ports, partial serial port communications, SPI communications and timers; the above custom peripherals include logic diagram programming chips.

[0036] The method of implementing this application includes but is not limited to MCU core, standard peripherals, custom peripherals and interfaces, debugging and communication modules, bus communication modules and ordinary memory. The compiled firmware is run using a standard MCU core composition architecture, such as RISC-V or ARM architecture. The firmware includes two core parts: logic diagram parser firmware and peripheral device driver code, thereby providing a standard high-speed communication bus to the outside, the bus connects peripherals and communications, and requires direct reading and writing of data for bus control. The kernel logic diagram includes the logic diagram program corresponding to each functional device.

[0037] The debugging communication module mainly solves the connection and communication between the logic diagram programming development tool and the debugging system site of the distributed hostless control system. The debugging function is realized by monitoring all the status data in the process of running the logic diagram and controlling the instructions at the same time. The specific implementation method is to reserve a memory interface for debugging control during firmware implementation, such as using a continuous memory area as the debugging memory to store the breakpoint steps. When the real-time running steps are consistent with the debugging memory storage steps, it enters an infinite loop waiting. The data of the peripherals during the instruction running process is stored in the ordinary memory, while the instruction data and the remaining chip mapping data are stored in the debugging memory. The data stored in the ordinary memory is used to interact with the peripherals and drivers; the data stored in the debugging memory is used for data mapping and debugging communication. The communication consists of two parts, one is the communication interface for the program debugging process, and the other is the bus communication interface. Among them, the bus communication interface only defines the data link layer and above, provides a basic communication physical interface, but does not restrict the physical layer interface, but the bus communication method is invisible to the code programming user.

[0038] The connection and communication between the logic diagram programming development tool and the debug system site of the distributed hostless control system uses wireless connection to send debug data. The debug data includes instruction data during chip operation and mapping data between chips. Specifically, the connection bus between the debug memory and the kernel is taken over by the debug communication module, and all kernel access to the debug memory must go through the debug communication module. In this way, it can be ensured that all data generated during the kernel running the logic diagram is sent through the debug bus, and the debug communication module can use special instructions to control the stop and start of each step of the logic diagram instruction.

[0039] The bus communication module is used to solve the communication between sites. The bus communication module realizes the interaction between sites through the interaction between chips. The communication is invisible to the user. The communication configuration method is automatically determined when the logic diagram is generated. When the logic diagram is generated, the configuration items that need to be mapped will be automatically generated. This configuration item is temporarily invisible to the user.

[0040] Ordinary memory is used to store the intermediate data of ordinary peripherals and the FICS kernel code and logic diagram. Ordinary memory consists of two parts, namely, memory that does not lose data when power is off (flash, etc.) and memory that loses data when power is off (SRAM, etc.). Flash is used to store peripheral driver code and FICS kernel code.

[0041] The site provides standardized peripherals for driving peripheral devices and communicating with peripheral devices. Standard peripherals include controlling common IO ports, some serial port communications, SPI communications, timers and other series of standard peripherals.

[0042] When standardized peripherals cannot realize their functions, customized peripherals can be flexibly used to realize them. Among them, FPGA or other logic diagram programming chips are used to connect to the bus to build custom peripheral tools and interfaces.

[0043] The debug communication module can be implemented using a series of logic circuits, which mainly coordinate the access to debug memory from the kernel, as well as the bidirectional access between communication and debug memory. It also has read and write operations on ordinary memory. Ordinary memory can only be read and written once when powered on. Ordinary memory cannot be controlled during operation. The debug communication circuit has a pause control on the kernel operation. The debug communication module includes: instruction breakpoints,

[0044] Memory monitoring, memory data modification and conditional breakpoint functions.

[0045] Instruction breakpoint: that is, to implement the breakpoint function for a single instruction of the kernel, which can be implemented by software combined with hardware, such as controlling the connection or disconnection by controlling the relay switch. Optionally, each instruction judges 5 breakpoint memories, which are stored in the debug memory. As long as the number of instruction steps in the breakpoint memory is consistent with the number of running steps, a pause will occur. It is tentatively only included in the instruction running pause, and the peripherals and communication modules independent of the kernel will not be paused.

[0046] Memory monitoring: monitor all data in the debug memory, and you can view the memory addresses or relays that need to be monitored added by the user. However, when adding monitoring items, the kernel must be suspended, that is, the interrupt interface provided by the kernel is used to make the kernel pause in the interrupt.

[0047] Memory data modification: that is, modifying the data in the debug memory, but the modification operation must make the kernel operation temporarily suspended.

[0048] Conditional breakpoint: users can use logical operations (AND, OR, NOT) and other logic to monitor data in a debug memory. If the data changes and meets the logical operation results, an interrupt operation that stops the kernel occurs.

[0049] Debug memory access control: that is, the core is directly connected to the debug memory through the bus at ordinary times, and the debug communication circuit only monitors the read and write operations initiated by the debugger to the debug memory, and synchronizes the debug memory data to the debug backup memory, so that it can be completed by only maintaining the consistency of the data in the backup memory and the debug memory. The instruction memory data that the user can see comes from the backup memory.

[0050] The above specific implementation methods further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above are only specific implementation methods of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

[0051] Example 2

[0052] An embodiment of the present application provides an application method of a distributed host-free control system debugging system, including: abstractly transplanting the parser of the above-mentioned kernel logic diagram and the driver code of the above-mentioned kernel device driver to a virtual operating environment, and performing simulation debugging with the programming tool of the above-mentioned kernel logic diagram.

[0053] The method of abstractly transplanting the parser of the kernel logic graph and the driver code of the kernel device driver to the virtual operating environment includes the following steps:

[0054] The first method is to classify the above-mentioned sites corresponding to the functional devices with high reliability into virtual sites, and classify the above-mentioned sites corresponding to the functional devices with low reliability into physical sites; the above-mentioned virtual sites are implemented in a virtual operating environment and combined with the above-mentioned physical sites;

[0055] The second type: each of the above-mentioned sites is set on the core board, and a standardized interface is provided to splice any number of the above-mentioned sites;

[0056] The third method: convert all the above sites into programs, each process in the program represents a site, and convert all hardware interfaces into abstract program interfaces.

[0057] In order to solve the challenges of real-time logic diagram debugging and inter-site communication interaction, the firmware and peripheral drivers are abstracted and transplanted to virtualize an operating environment in a computer or device with an operating system. This virtual operating environment imitates the operation of physical devices, thereby realizing the simulation of the debugging system of distributed hostless control systems at a low cost at the application level. Through this virtualization method, the resources of the computer can be used to realize virtual debugging and simulation of the program without physical FICS hardware. This not only reduces the cost of development and testing, but also improves development efficiency. At the same time, this method allows simulation debugging in conjunction with logic diagram programming tools, further optimizing the development process.

[0058] The establishment of this virtualized simulation environment enables developers to test and verify the behavior of the system in a controlled environment to ensure the stability and reliability of the system. In addition, it also provides a platform for communication interaction between sites, allowing developers to simulate and test the communication protocols and programs between different sites without relying on physical hardware. In summary, by porting the distributed host communication firmware and peripheral driver abstraction to a virtual environment, we can achieve low-cost and efficient simulation and debugging of the debugging system of distributed hostless control systems, while solving the problems of real-time logic diagram debugging and communication interaction between sites. This method provides new possibilities for the development and testing of the debugging system of distributed hostless control systems and promotes the development of distributed host communication technology. For the virtualization implementation of the debugging system of distributed hostless control systems, three different virtualization methods are proposed to adapt to different scenarios and requirements.

[0059] Partial virtualization: In this method, the implementation of some sites is concentrated in PCs or other operating environments, combined with physical sites. For equipment with extremely high reliability requirements, physical sites are used to ensure their stability and performance. For those sites with relatively low reliability requirements or those that are not necessary in the overall system design, virtualization technology can be used to reduce costs and improve flexibility. This method balances the use of physical sites and virtual sites, selects according to actual needs, and realizes the virtualization of some functions.

[0060] Flexible virtual method: By disassembling the top plate of the site and retaining the core part. The core part provides standardized interfaces to the outside to achieve flexible splicing of the top plate. The functions of some sites are concentrated in the same core board, which improves the integration and flexibility of the system. This method allows more flexible combination and configuration of sites, making the system more modular and scalable.

[0061] Full virtualization: All sites are fully virtualized, and all hardware interfaces are converted into abstract program interfaces. All sites become processes in the program, and each process represents a site. This method realizes the full virtualization of the system, so that the debugging system of the entire distributed host-free control system can be simulated and tested at the software level.

[0062] The fully virtualized approach provides extremely high flexibility and scalability, allowing development and testing without physical hardware limitations.

[0063] These three virtualization methods provide multiple options for the implementation of the debugging system of distributed hostless control systems. You can choose the appropriate method according to specific needs and scenarios. Whether it is partial virtualization, flexible virtualization or full virtualization, it can bring more convenience and possibilities to the development, testing and deployment of the debugging system of distributed hostless control systems.

[0064] In summary, the embodiments of the present application provide a debugging system and application method for a distributed hostless control system: a method of chipizing the debugging system of a distributed hostless control system, and utilizing an MCU core to run compiled firmware, including a parser firmware of a kernel logic diagram and a driver code of a kernel device driver; the MCU core is connected to the kernel logic diagram of each site and the kernel device driver of a functional device through peripherals; the parser firmware can monitor all status data during the operation of the kernel logic diagram through a memory interface controlled by a debugger, and simultaneously control the instructions of the kernel logic diagram during operation, thereby performing real-time logic diagram debugging, and the communication interaction between sites no longer requires additional programs to control, thereby meeting the requirements of reliability and stability.

Claims

1. A distributed hostless control system debugging system, characterized in that: It comprises a plurality of sites, an MCU core and a firmware run by the MCU core; each of the sites is connected to a separate functional device; the MCU core is connected to each of the sites through a peripheral; each of the sites comprises a core logic diagram and a core device driver connected to the corresponding functional device; the firmware comprises a parser of the core logic diagram and a driver code of the core device driver; The parser monitors all state data during the operation of the kernel logic diagram through a memory interface controlled by debugging, and controls the instructions during the operation of the kernel logic diagram, including: using a continuous memory area as a debugging memory to store the breakpoint step number, and when the real-time operation step number is consistent with the breakpoint step number, entering an infinite loop waiting, and storing the data of the peripherals during the operation of the kernel logic diagram in a common memory, so as to interact with the peripherals and the kernel device driver respectively; The instruction data and chip mapping data are stored in the debugging memory, and the chip mapping data is used to perform data mapping on the instruction data that controls the operation of the core logic diagram, so as to debug the MCU core and the communication of the MCU core.

2. A distributed host-free control system debugging system according to claim 1, characterized in that: The method for debugging the MCU kernel comprises: interrupting the operation of the MCU kernel; and implementing a breakpoint function for a single instruction of the MCU kernel; The method for debugging the communication of the MCU core includes: the peripheral device connects each of the sites via a bus; controls the bidirectional access between the MCU core and the debug memory, controls the bidirectional access between the bus and the debug memory, and controls the read and write operations on the common memory.

3. A distributed host-free control system debugging system according to claim 2, characterized in that: The method for controlling the bidirectional access between the MCU core and the debug memory, or the method for controlling the bidirectional access between the bus and the debug memory, comprises: monitoring and modifying the data in the debug memory; providing an editable logic formula to monitor certain data in the debug memory, and interrupting the operation of the MCU core when the data changes and satisfies the operation result of the logic formula.

4. A distributed host-free control system debugging system according to claim 3, characterized in that: The method for monitoring and modifying the data in the debug memory comprises: the MCU core modifies the data in the debug memory through the bus; the bus is controlled by directly reading and writing data, and the communication mode of the bus is invisible to the reading and writing users; the MCU core monitors the data in the debug memory through the debug communication circuit.

5. A distributed host-free control system debugging system according to claim 4, characterized in that: When the MCU core monitors the data in the debug memory through the debug communication circuit, the data in the debug memory is synchronized to the debug standby memory at the same time, and the data in the debug standby memory is provided to the user for viewing.

6. A distributed host-free control system debugging system according to claim 3, characterized in that: The method of controlling the bidirectional access between the MCU core and the debug memory, or the method of controlling the bidirectional access between the bus and the debug memory, comprises: a user monitors all data in the debug memory, and adds memory addresses or relays to be monitored.

7. A distributed host-free control system debugging system according to claim 1, characterized in that: The peripherals include standard peripherals and custom peripherals; the standard peripherals include any one or more of ordinary IO ports, partial serial port communications, SPI communications and timers; the custom peripherals include logic diagram programming chips.

8. An application method for a debugging system of a distributed host-less control system as claimed in claim 1, characterized in that: include: The parser of the kernel logic diagram and the driver code of the kernel device driver are abstractly transplanted to the virtual operating environment, and simulation debugging is performed with the programming tool of the kernel logic diagram.

9. The application method of a distributed host-free control system debugging system according to claim 8, characterized in that: The method of abstractly transplanting the parser of the kernel logic graph and the driver code of the kernel device driver to the virtual operating environment includes the following steps: The first method: the corresponding site is divided into a virtual site according to the functional device with high reliability, and the corresponding site is divided into a physical site according to the functional device with low reliability; the virtual site is implemented in a virtual operating environment and combined with the physical site; The second type: each of the sites is provided on a core board, and a standardized interface is provided to splice any number of the sites; The third method is to convert all the above mentioned sites into programs, where each process represents one site, and convert all hardware interfaces into abstract program interfaces.

Images