Distributed code automatic generation system and method based on virtual simulation

Abstract

The invention relates to the technical field of virtual simulation, in particular to a distributed code automatic generation system and method based on virtual simulation, and the system comprises a development module, a virtual simulation module and a code automatic generation module. The development module is used for maintaining communication between devices, analyzing an RPC data frame and constructing the RPC data frame, and is also used for deserializing an RPC data calling function, serializing a result and then processing the result; the virtual simulation module is used for associating a remote function with virtual equipment; the code automatic generation module is used for automatically generating source codes of all devices. According to the method, data which is difficult to reproduce in practice is generated in a data simulation form through a virtual simulation technology, and a developer is helped to simplify a development process; and meanwhile, an automatic code generation technology is utilized to complete automatic generation of embedded system bottom layer codes and virtual simulation equipment codes, so that developers can perform development on the basis, and the transplantation and debugging time of the developers is greatly saved.

Description

Technical Field

[0001] The present invention relates to the technical field of virtual simulation, and in particular to a distributed code automatic generation system and method based on virtual simulation. Background Art

[0002] In this era of the Internet of Everything, various smart devices are not independent, and different devices often need to work in coordination with each other. To address this problem, the current commonly used approach is to develop each device independently, and then use communication methods to achieve data interaction between different devices, thereby achieving linkage between different devices. This development approach has an obvious problem, which is that it requires independent development for each device, and the human and material costs are often relatively high. In addition, there are some special situations in some device working scenarios that are difficult to reproduce, resulting in difficulties in device development and debugging.

[0003] In summary, the present invention proposes a distributed code automatic generation system and method based on virtual simulation. Based on virtual simulation technology, data that is difficult to reproduce in practice is generated in the form of simulated data, helping developers to simplify the development process; and using code automatic generation technology, the automatic generation of embedded system underlying code and virtual simulation device code is completed, which is convenient for developers to develop on this basis and greatly saves developers' time for transplantation and debugging. Summary of the invention

[0004] To solve the above problems, the present invention provides a distributed code automatic generation system and method based on virtual simulation. Through virtual simulation technology, data that is difficult to reproduce in practice is generated in the form of simulated data, helping developers to simplify the development process. At the same time, the code automatic generation technology is used to complete the automatic generation of embedded system underlying code and virtual simulation device code, which is convenient for developers to develop on this basis and greatly saves developers' time for transplantation and debugging.

[0005] In order to achieve the above-mentioned object, the technical solution of the present invention is as follows: a distributed automatic code generation system based on virtual simulation includes a development module, a virtual simulation module and an automatic code generation module;

[0006] The development modules include function management module, RPC management module and communication management module;

[0007] The function management module is used to manage the RPC function of the current device, that is, the function entity is in the current device, and other devices access the function of the current device through the RPC interface;

[0008] The RPC management module is used to manage the device RPC interface between different devices to implement remote function calls between different devices, including the local device remotely calling the interface of other devices and parsing the RPC data frame from the communication management module;

[0009] The communication management module is used to maintain the communication between different devices, including receiving data streams from other devices, storing the received data in the receiving buffer, decrypting and verifying the data in the receiving buffer, and passing the verified data to the RPC management module in the form of RPC data frames for further processing. At the same time, it also receives RPC data frames from the RPC management module and stores them in the sending buffer. After encrypting the data, the data is sent out through the specified communication method, and automatically resends when the sending data times out, and automatically filters out redundant information when the same message is received;

[0010] The code automatic generation module includes a peripheral library management unit, a visual parameter configuration unit, a code automatic generation unit and a peripheral library module;

[0011] The peripheral library module includes MCU project templates and peripheral modules;

[0012] The peripheral library management unit is used to add microcontroller project templates and peripheral modules to the peripheral library module; it is also used to generate hardware resource description files and source code generation scripts;

[0013] The visual parameter configuration unit is used to realize the parameter configuration of the peripheral modules and the single-chip microcomputer engineering;

[0014] The code automatic generation unit is used to adjust and modify the corresponding source code according to the configuration information of the single-chip microcomputer and the configuration information of the peripheral module;

[0015] The virtual simulation module includes a virtual single-chip computer module, a virtual device processing engine module, a single-chip computer development project description script module and a virtual peripheral UI description script module;

[0016] The virtual MCU module is used to simulate the MCU on the PC side to connect to the virtual device processing engine to achieve the purpose of simulation;

[0017] The virtual device processing engine module is used to load the MCU development project description script from the external storage device when the user opens the virtual simulation software, parse all peripheral modules from the script, and then load all corresponding virtual peripheral UI description scripts from the peripheral library module according to the MCU development project description script, and display them in the corresponding interface according to the parsed content;

[0018] The MCU development project description script module is used to record the configuration parameters of the generated MCU development project;

[0019] The virtual peripheral UI description script module is used to describe the appearance and internal components of the virtual device through QML, and at the same time implement all function interface processing capabilities of the peripheral in the script.

[0020] Furthermore, the hardware resource description file is used to record the hardware resources of the single-chip microcomputer, including at least the single-chip microcomputer model, the number of pins, and the functions and hardware resources of each pin.

[0021] Furthermore, the peripheral library management unit is also used to debug the virtual peripheral UI description script module.

[0022] Furthermore, the virtual peripheral UI description script module is used to process the RPC data frame from the RPC interface processing module, parse the received data to obtain the corresponding function and parameter values, and take corresponding actions according to the function and parameter values.

[0023] Furthermore, the single-chip microcomputer development project description script module is also used to obtain the names and path addresses of all peripherals by reading the peripheral configuration information when generating a virtual simulation interface, and load the virtual peripheral UI description script from the specified location according to the name and address.

[0024] Furthermore, the MCU development project description script module is used to obtain the MCU configuration information from the system variables, and then copy the project template from the peripheral library specified path to the user specified storage path, and at the same time copy all peripheral modules from the specified location to the user specified storage path, and then run the source code generation script.

[0025] Furthermore, the distributed code automatic generation method based on virtual simulation has the following steps:

[0026] S1 first uses the embedded system distributed development method to implement remote function calls between different devices through RPC technology;

[0027] S2 is based on RPC technology and uses virtual simulation technology to associate remote functions with virtual devices in the form of simulated function interfaces on the PC side;

[0028] S3 connects the virtual MCU module with the virtual device through RPC technology, and then develops the implementation logic of the actual project in the virtual MCU module to control the virtual device. When the data value of the sensor needs to be modified, it is modified directly through the virtual device;

[0029] S4 is completed by the developer or hardware manufacturer through the peripheral library management unit to design the peripheral library and add it to the peripheral library unit. When using the tool, the peripheral library management unit will automatically load the corresponding single-chip microcomputer and peripheral modules from the peripheral library unit for user selection, and complete the corresponding parameter configuration. After configuration, the single-chip microcomputer development project is automatically generated through the code automatic generation unit, and then the corresponding functions are implemented based on the development project; and when the virtual simulation function is selected, the visual parameter configuration unit automatically adds the virtual peripheral UI description script to the project, and then when the virtual simulation tool is started, a virtual simulation device is generated according to the single-chip microcomputer development project description script and the virtual peripheral UI description script.

[0030] Furthermore, the data processing process of the function management module in step S1 is as follows:

[0031] S1-1 defines the device RPC interface and initializes it;

[0032] S1-2 deserializes and parses the data frame passed by the RPC management module, calls the corresponding function according to the parsing result, and passes the serialized data frame returned by the function to the RPC management module for further processing.

[0033] Furthermore, the data processing process of the RPC management module also included in steps S1 and S2 is as follows:

[0034] S2-1 completes the device RPC interface definition of all device types according to the function management module, then completes the definition of all functions according to each peripheral module and interface variable, and initializes all device RPC interfaces to the defined functions;

[0035] S2-2 implements various peripheral modules and interface variables;

[0036] Remote call of S2-3 function. When the current device needs to remotely access other device function interfaces through the RPC interface, first specify the corresponding device number, and then access it through the rpc_api RPC interface;

[0037] The step S2-2 also includes the following implementation process of each peripheral module and interface variable:

[0038] S2-2-1 In each function, obtain all the input parameters and return parameters of the corresponding function, calculate the length of the input parameters and return parameters to be serialized, dynamically apply for memory matching the RPC data frame according to the length, and serialize according to the input parameters and return parameters, and then pass the serialized data to the communication management module;

[0039] S2-2-2 Wait for the communication management module to return the call result, and determine whether the parameter type is normal based on the RPC data frame in the return result. If normal, deserialize it based on the return parameter length, return parameter sequence, input parameter length and input parameter sequence to obtain the function return result, and pass the return result to the called function; if the parameter type is judged to be an abnormal value, directly use the parameter type as the return value of the function and end the function call.

[0040] Further, the steps S1, S2 and S3 also include the following communication processing process:

[0041] S3-1 initializes all network modules, resets the timestamps and frame sequence numbers of all device RPC interfaces, and then goes to S3-2;

[0042] S3-2 determines whether there is data to be sent in the sending buffer. If there is data, if encryption is required, the data is encrypted first, and then the data in the buffer is sent out through the specified data sending interface according to the storage order and the communication type in the RPC data frame. After all data is sent, go to S3-3;

[0043] S3-3 determines whether there is data in the receiving buffer. If there is data, if encryption is used, the data is first decrypted and the decrypted data is verified. If the verification fails, the data verification failure status is sent back to the source device, and then the process goes to S3-5.

[0044] S3-4 determines whether the RPC error code is 0. If not, go to S3-6. Otherwise, determine whether the frame number in the received RPC data frame is before the frame number of the device RPC interface and whether the timestamp is close to the local timestamp. If not, determine that the data is invalid, and send the data timeout status back to the source device. Otherwise, determine the function type. If it is an active function remote call function type, transmit the parsed RPC data frame to the RPC management module, and then go to S3-5. If it is a function remote call return result type, transmit the parsed RPC data frame to the RPC Management module, parses the returned result at the same time, notifies the called function that the remote function call process has been completed, releases the memory of the corresponding RPC data frame, and then goes to S3-5; if it is a callback function type, the parsed RPC data frame is transmitted to the RPC management module, and the corresponding function is called according to the set callback function, and then goes to S3-5; if it is an interrupt function, the parsed RPC data frame is transmitted to the RPC management module, and the corresponding function is called according to the set interrupt function, and then goes to S3-5; in addition, this function type will be added, deleted, and modified according to actual needs;

[0045] S3-5 checks whether the timestamps in all sent RPC data frames have timed out. If not, it goes to S3-2. If the return data has not been received after the specified time, it notifies the called function that the remote function call has timed out, releases the memory of the corresponding RPC data frame, and goes to S3-2.

[0046] S3-6 determines whether the number of retransmissions of the current data frame reaches the specified number. If so, the called function is notified that the remote function call has failed, and then the process goes to S3-2. If not, the data is resent, and then the process goes to S3-2.

[0047] The technical principle of the above scheme is as follows: first, using the embedded system distributed development method, the remote function call between different devices is realized through RPC technology, and then based on this technology, the virtual simulation technology is used to associate the remote function with the virtual device (including various single-chip peripherals and sensor peripherals) through the form of simulated function interface on the PC side. In addition, by simulating a virtual single-chip computer and connecting with the virtual device through RPC technology, the developer then develops the implementation logic in the actual project in the virtual single-chip computer and controls the virtual device. When the data value of the sensor needs to be modified, it is modified directly through the virtual device. Using the code automatic generation module, the source code of all devices (including various single-chip peripherals and sensor peripherals) is automatically generated. Developers only need to care about the design of the logical function, and do not need to care about the underlying implementation process.

[0048] The above scheme has the following beneficial effects:

[0049] 1. Compared with the existing technology, which requires independent development of each device, and then uses communication means to realize data interaction between different devices, and then realizes linkage between different devices, this method has high manpower and material costs. In this solution, through virtual simulation technology, developers can develop products without real devices, avoiding the high manpower and material costs required for independent development of each device; at the same time, using code automatic generation technology, the generation of embedded system underlying code and virtual simulation device code can be automatically completed, which greatly saves developers' transplantation and debugging time. Developers only need to care about the design of logical functions, without paying attention to the underlying implementation process, so that they can focus more on the development of product functions.

[0050] In addition, through the virtual simulation system, developers can simulate and generate data that is difficult to reproduce in reality, helping to simplify the development process and reduce the difficulty of development. The virtual simulation system can also provide rich supporting materials for developers to use, further improving development efficiency.

[0051] 2. This solution uses the distributed development method of embedded systems and implements remote function calls between different devices through RPC technology, which enhances the linkage between devices. This allows different devices to work together more efficiently and improves the performance and stability of the entire system.

[0052] Additional aspects and advantages of the present invention will be given in part in the following description and in part will be obvious from the following description, or will be learned through practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] Figure 1 A schematic diagram of a development module of an embodiment of a distributed code automatic generation system and method based on virtual simulation of the present invention;

[0054] Figure 2 It is a schematic diagram of the device RPC interface definition of an embodiment of a distributed code automatic generation system and method based on virtual simulation of the present invention;

[0055] Figure 3 It is a schematic diagram of an example of RPC interface definition of a semd device according to an embodiment of a distributed code automatic generation system and method based on virtual simulation of the present invention;

[0056] Figure 4 The embodiment of the distributed code automatic generation system and method based on virtual simulation of the present invention is a schematic diagram of an example of initializing the RPC interface of the semd device;

[0057] Figure 5 It is a schematic diagram of RPC interface definition of an embodiment of a distributed code automatic generation system and method based on virtual simulation of the present invention;

[0058] Figure 6 It is a schematic diagram of an example of RPC interface definition of an embodiment of a distributed code automatic generation system and method based on virtual simulation of the present invention;

[0059] Figure 7 A schematic diagram of a virtual simulation module of an embodiment of a distributed code automatic generation system and method based on virtual simulation of the present invention;

[0060] Figure 8 A schematic diagram of a code automatic generation module of an embodiment of a distributed code automatic generation system and method based on virtual simulation of the present invention;

[0061] Fig. 9 The diagram is a schematic diagram of the WiFi source code directory structure of an embodiment of a distributed code automatic generation system and method based on virtual simulation of the present invention. DETAILED DESCRIPTION

[0062] The technical solution of the present invention will be described clearly and completely below in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0063] In the description of the present invention, it should be noted that the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer", etc., indicating the orientation or positional relationship, are based on the orientation or positional relationship shown in the drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as limiting the present invention. In addition, the terms "first", "second", and "third" are used for descriptive purposes only, and cannot be understood as indicating or implying relative importance.

[0064] In the description of the present invention, it should be noted that, unless otherwise clearly specified and limited, the terms "installed", "connected", and "connected" should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection, or it can be indirectly connected through an intermediate medium, or it can be the internal communication of two components. For ordinary technicians in this field, the specific meanings of the above terms in the present invention can be understood according to specific circumstances.

[0065] The following is further described in detail through specific implementation methods:

[0066] Embodiment 1:

[0067] like Figure 1 , Figure 2 , Figure 3 , Figure 4 , Figure 5 , Figure 6 , Figure 7 , Figure 8 and Fig. 9 As shown: A distributed code automatic generation system based on virtual simulation includes a development module, a virtual simulation module and a code automatic generation module.

[0068] The development modules include function management module, RPC management module and communication management module. At the same time, in order to realize the linkage between different modules and the linkage with virtual simulation devices, the remote procedure call (RPC) technology is used. And because the existing RPC components or frameworks have complex structures and cannot be directly applied to some resource-constrained embedded devices, a lightweight RPC interface is redesigned.

[0069] The function management module is used to manage the RPC function of the current device, that is, the function entity is in the current device, and other devices access the function of the current device through the RPC interface.

[0070] The RPC management module is used to manage the device RPC interface between different devices to implement remote function calls between different devices, which includes the local device remotely calling the interface of other devices and parsing the RPC data frame from the communication management module.

[0071] The communication management module is used to maintain communication between different devices, including receiving data streams from other devices, storing the received data in the receiving buffer, decrypting the data in the receiving buffer (if the encryption function is enabled) and verifying the data, and passing the verified data to the RPC management module in the form of RPC data frames for further processing. It also receives RPC data frames from the RPC management module and stores them in the sending buffer. After encrypting the data (if the encryption function is enabled), the data is sent out through the specified communication method, and automatically resends when the sending data times out, and automatically filters out redundant information when the same message is received.

[0072] The code automatic generation module includes a peripheral library management unit, a visualization parameter configuration unit, a code automatic generation unit and a peripheral library module.

[0073] The peripheral library module includes MCU project templates and peripheral modules. MCU project templates include project templates for different MCU models. Each MCU project template consists of a development project template, a hardware resource description file, a source code generation script, and a virtual peripheral UI description script. By completing the entry of these parameters in the peripheral library management module, it is convenient to load and display them according to the parameter type in the visual parameter configuration interface for developers to select; the source code generation script is used to modify and adjust the source code according to the configuration parameters; the virtual peripheral UI description script is used to generate a virtual device interface and realize the interaction between the virtual device and the MCU.

[0074] The peripheral module includes various microcontroller internal peripherals and sensor peripherals, which are composed of peripheral source code, peripheral parameter scripts, sample codes, data documents, source code generation scripts, and virtual peripheral UI description scripts; the peripheral source code is the source code provided by the developer or hardware manufacturer, and is developed using the POSIX (Portable Operating System Interface) standard; the sample code is the demonstration code used to test the function of the peripheral module, and the user can view it by clicking the corresponding button in the visual parameter configuration interface; the data document is the instruction manual, hardware design manual, hardware parameters, supporting software and other information of the peripheral module.

[0075] The peripheral library management unit is used to add microcontroller project templates and peripheral modules to the peripheral library module; it is also used to generate hardware resource description files and source code generation scripts, as well as virtual peripheral UI description script module debugging. The hardware resource description file is used to record the hardware resources of the microcontroller, including the microcontroller model, the number of pins and the function of each pin, hardware resources (RAM and ROM size and address range), and all internal peripheral information (including but not limited to serial ports, external interrupts, timers, PWM, SPI, IIC, FSMC, USB, etc., which are specific to the chip model). These parameters are entered in the peripheral library management module so that they can be loaded and displayed according to the parameter type in the visual parameter configuration interface for developers to choose. For example, when the WiFi module configures the communication serial port, its parameter type is the serial port type. According to the microcontroller type selected by the developer, the serial port parameters are read from the hardware resource description file (for example, STM32F103C8T6 has 3 serial ports, namely UART1, UART2, and UART3, which are displayed in the corresponding communication serial port. If it is a microcontroller of other models, the number of serial ports and the position of the pins are not completely consistent), and displayed in the interface. Peripheral UI description script module debugging, when the developer develops a peripheral library or a MCU project template, the script function is tested. That is, when the developer completes the script writing, the script is run to check whether it is consistent with the implemented function.

[0076] The visual parameter configuration unit is used to implement the parameter configuration of the MCU project peripheral modules and MCU projects. When the software is opened, all the MCU project template information is first loaded from the peripheral library and displayed in the interface. The user selects the corresponding MCU model and configures the project storage address, project name, debugging serial port information, operating system information and other parameters. After completing the MCU selection, the hardware resources of the selected MCU are loaded into the system, and it will automatically jump to the peripheral module parameter configuration interface to load all peripheral modules and display them in the interface. When the user clicks on different peripheral modules, the peripheral parameter configuration script will be loaded from the specified peripheral module, and the corresponding configuration parameters will be displayed in the interface for the user to configure. After completing all peripheral parameter configurations, when you click Create Project, all configuration parameters will be saved to the system variables, and then jump to the code automatic generation unit.

[0077] The code automatic generation unit is used to obtain the MCU configuration information from the system variables, and then copy the project template from the specified path of the peripheral library to the storage path specified by the user, and at the same time copy all peripheral modules from the specified location to the storage path specified by the user, and then run the source code generation script, that is, adjust and modify the corresponding source code according to the MCU configuration information and peripheral module configuration information. For example, taking the WiFi module as an example, it includes AP mode and STA mode (the two modes are composed of different source codes, assuming that their directory structure is as follows Fig. 9 As shown, the AP mode consists of wifi.h, wifi_ap.h, and wifi_ap.c, and the STA mode consists of wifi.h, wifi_sta.h, and wifi_sta.c). In STA mode, the current device is connected to the router to access the Internet. In the source code copying stage, the entire directory (wifi.h, wifi_ap.h, wifi_ap.c, wifi_sta.h, and wifi_sta.c) will be copied to the specified path, and then the sta mode will be configured according to the configuration parameters, and the wifi_ap.h and wifi_ap.c files will be deleted. At the same time, the configuration parameters (including the router hotspot name, the router hotspot connection password, the reset pin, and the communication serial port) will be written into the corresponding source code, such as into wifi_ap.c. This method has more flexible parameter configuration, and its parameter configuration and source code generation depend on the content of the script. It can even directly build the source code according to the configuration parameters through the source code generation script, while ignoring the source code copying process. The specific implementation method is selected by the developer.

[0078] The virtual simulation module includes a virtual single-chip computer module, a virtual device processing engine module, a single-chip computer development project description script module and a virtual peripheral UI description script module.

[0079] The virtual MCU module is used to simulate the MCU on the PC side to connect to the virtual device processing engine to achieve the purpose of simulation.

[0080] The virtual device processing engine module is used to load the MCU development project description script from the external storage device when the user opens the virtual simulation software, parse all peripheral modules from the script, and then load all corresponding virtual peripheral UI description scripts from the peripheral library module according to the MCU development project description script, and display them in the corresponding interface according to the parsed content;

[0081] The MCU development project description script module is used to record the configuration parameters of the generated MCU development project. When generating the virtual simulation interface, the names and path addresses of all peripherals are obtained by reading the peripheral configuration information, and the virtual peripheral UI description script is loaded from the specified location according to the name and address. The configuration parameters include script version, operating system type, development mode (i.e. whether to enable the bootloader project), generated project storage path, debug serial port information, MCU hardware resource allocation information, project name, peripheral configuration information (including the names of all selected peripherals, peripheral configuration parameters, and peripheral source code paths), and other data.

[0082] The virtual peripheral UI description script module is used to describe the appearance and internal components of the virtual device through QML, and at the same time implement all the function interface processing capabilities of the peripheral in the script, that is, to process the RPC data frame from the RPC interface processing module, parse the received data into the corresponding function and parameter values, and make corresponding actions according to the function and parameter values. For example, for the LED peripheral module, when the RPC data frame received from the RPC interface processing module contains the LED control function led_set() function, and controls LED1 to be on, the ability to parse the RPC data frame is implemented in the script, and the led_set() function can be parsed from the RPC data frame, the LED number is LED1, and the state is on, and then the virtual device rendering module is used to control the LED state in the interface to be displayed as on, and then the processed result is returned to the RPC interface processing module. Other peripheral modules are also implemented in this way.

[0083] Embodiment 2:

[0084] The difference from Example 1 is that the distributed code automatic generation method based on virtual simulation has the following steps:

[0085] S1 first uses the distributed development method of embedded systems to implement remote function calls between different devices through RPC technology.

[0086] S2 is based on RPC technology and uses virtual simulation technology to associate remote functions with virtual devices in the form of simulated function interfaces on the PC side.

[0087] S3 connects the virtual MCU module to the virtual device through RPC technology, and then develops the implementation logic of the actual project in the virtual MCU module to control the virtual device. When the data value of the sensor needs to be modified, it is modified directly through the virtual device.

[0088] S4 is completed by the developer or hardware manufacturer through the peripheral library management unit to design the peripheral library and add it to the peripheral library unit. When using the tool, the peripheral library management unit will automatically load the corresponding single-chip microcomputer and peripheral modules from the peripheral library unit for user selection, and complete the corresponding parameter configuration. After configuration, the single-chip microcomputer development project is automatically generated through the code automatic generation unit, and then the corresponding project is implemented based on the development project; and when the virtual simulation function is selected, the visual parameter configuration unit automatically adds the virtual peripheral UI description script to the project, and then when the virtual simulation tool is started, a virtual simulation device is generated according to the single-chip microcomputer development project description script and the virtual peripheral UI description script.

[0089] The data processing process of the function management module in step S1 is as follows:

[0090] S1-1 defines the device RPC interface and initializes it. Taking a certain implementation process as an example, first define a device RPC interface for the current device. This interface is used to manage all module function interface classes of the current device. Then, each interface class defines module interface variables and interface functions. Its structure is as follows: Figure 2 As shown, during initialization, the corresponding interface is associated with the corresponding function and variable, that is, each member in the device RPC interface points to the corresponding function or variable. The specific implementation process refers to the initialization assignment of the structure pointer. Assuming an electrical parameter monitoring device (smart electricity monitordev, semd), its semd device RPC interface definition is as follows Figure 3 As shown, the initialization of the semd device RPC interface is as follows Figure 4 shown.

[0091] S1-2 deserializes and parses the data frame passed by the RPC management module, calls the corresponding function according to the parsing result, and passes the serialized data frame returned by the function to the RPC management module for further processing. That is, the conversion between RPC data frame and function is realized for each peripheral module respectively. This process includes two triggering methods. The first is that other devices call the function in the local device, which is called passive triggering; the second is that the local device actively sends data to other devices. For example, when the device generates an interrupt and needs to send data to other devices, this triggering method is called active triggering.

[0092] The implementation process of the passive trigger method is as follows:

[0093] Step 1: Get the function / variable number from the RPC data frame, for example Figure 4 For the WiFi peripheral module, the serial number of the wifi_read() function is 6 (starting from the wifi_config_value variable being 0), go to step 2;

[0094] Step 2, deserialize the function parameters from the entry parameter length and entry parameter sequence in the RPC data frame, obtain the entry parameters of different data types of the function, and calculate whether the parameter parameters are consistent with the parameter length in the RPC data frame. If they are consistent, go to step 3, otherwise go to step 4. For example, for the wifi_read() function, its parameters are char*buff, uint16_tlen, uint16_t timeout, and its length is the sum of the length of *buff, the length of len and the length of timeout, which is len+2+2=len+4 bytes. Assuming that the length of 10 data is read, the total length is 14 bytes, and the deserialized entry parameters are saved in a temporary variable, such as char*rec_buff[MAX_BUFF_LEN], uint16_trec_len, and uint16_t rec_timeout, respectively, where MAX_BUFF_LEN is the maximum length defined by the developer in the program in advance.

[0095] Step 3, call the function of the corresponding serial number, obtain the return result, serialize the return result into the corresponding return parameter sequence, and then return the serialized RPC data frame to the RPC management module to end the process. For example, the input parameter buff and the length of the returned read data frame are both return parameters, that is, the return data length in the RPC data frame is set to the length value of the read data, and the read data buff is filled into the return data sequence in the RPC data frame. The function type is set to a normal function, and the remaining parameters keep the original values. Finally, the processed RPC data frame is returned to the RPC management module to end the process.

[0096] Step 4: Set the parameter type bit of the RPC data frame to a parameter length mismatch error value, and set the input parameter length, input parameter sequence, return parameter length and return parameter sequence to zero. Set the function type to a normal function, and keep the remaining parameters at their original values. Return the processed RPC data frame to the RPC management module to end the process.

[0097] The implementation process of the active trigger method is as follows:

[0098] The active triggering method requires other devices to first complete the initialization of relevant parameters through the passive triggering method, and record the device address and device type in the device list of the active triggering function. When the function is triggered by the device, all devices are traversed, and then the function execution results are serialized into the corresponding parameter sequence, and then the serialized RPC data frame is returned to the RPC management module to end the process.

[0099] The data processing process of the RPC management module also included in steps S1 and S2 is as follows:

[0100] S2-1 completes the device RPC interface definition of all device types according to the function management module, then completes the definition of all functions according to each peripheral module and interface variable, and initializes all device RPC interfaces to the defined functions. The definition and initialization process is as follows: Figures 2 to 4 As shown, the device RPC interfaces of all device types are then encapsulated into the RPC interface. The encapsulated interface is as follows Figure 5 As shown in the figure, devn_name_api_t represents the RPC interface of the device type n. Assume that there are three types of devices, and their RPC interfaces are as follows: Figure 6 As shown in the figure, there are three types of equipment, electrical parameter monitoring equipment (i.e. Figure 3 and 4 The RPC interface defined is rpc_api_t rpc_api. When different devices of the same device type need to be operated, the function needs to be specified by the device type and device number. The corresponding device type and device number will be specified. This process will apply for a piece of memory space with the maximum data cache size set by the user to store the data in the RPC data frame, and fill the corresponding device type and device number into the specified position in the RPC data frame. At the same time, the frame number in the RPC data frame is automatically increased by 1, and the current system timestamp is written into the timestamp bit in the RPC data frame. The memory is released by the communication management module when the function receives the function return value or times out.

[0101] S2-2 implements various peripheral modules and interface variables.

[0102] The step S2-2 also includes the following implementation process of each peripheral module and interface variable:

[0103] S2-2-1 In each function, obtain all the entry parameters and return parameters of the corresponding function, calculate the length of the entry parameters and return parameters to be serialized, dynamically apply for memory matching the RPC data frame according to the length, and serialize according to the entry parameters and return parameters, and then pass the serialized data to the communication management module.

[0104] For example, the current device wants to read the value of a temperature and humidity sensor of a certain device from other devices. Assuming that its interface is booldht11_read_data(uint16_t*temp,uint16_t*humit), the input parameter length is 2+2=4 bytes. Since the data is read in the form of a pointer here, it is not necessary to pass the input parameter. Therefore, the input parameter length of the RPC data frame is set to 4 and the input parameter sequence is set to zero, the return parameter length is set to 1, the return parameter sequence is all set to zero, the parameter type is set to normal parameters, the function serial number is filled according to the actual position of dht11_read_data in the device RPC interface, the module serial number is filled according to the position of the device RPC interface in the RPC interface, the function type is the active function remote call function type, and then the serialized data is passed to the communication management module, and then transferred to S2-2-2.

[0105] S2-2-2 Wait for the communication management module to return the call result, and judge whether the parameter type is normal according to the return result RPC data frame. If normal, deserialize according to the return parameter length, return parameter sequence, input parameter length and input parameter sequence to obtain the function return result, and pass the return result to the called function. For example, for bool dht11_read_data(uint16_t*temp,uint16_t*humit) in S2-2-1, when the correct result is returned, the temperature and humidity values ​​in the input parameter sequence are assigned to temp and humit respectively, and then the return parameter is used as the return value of the dht11_read_data() function, and the function call ends. If the parameter type is judged to be an abnormal value, the parameter type is directly used as the return value of the dht11_read_data() function, and the function call ends.

[0106] If the called interface is a peripheral module interface variable, the function type is configured as a variable type (for example, 0xFF), and then the variable is serialized according to the entry parameters of the function, and the same process as the function is executed.

[0107] Remote call of S2-3 function, when the current device needs to remotely access other device function interfaces through the RPC interface, first specify the corresponding device number, and then access it through the rpc_api RPC interface.

[0108] Take bool dht11_read_data(uint16_t*temp,uint16_t*humit) as an example to illustrate, assuming that the device type is semd (i.e. Figure 4The device type defined in ), numbered 123 (this interface uses the last 16 bits of the chip UID as the device number by default. The developer can customize the numbering format. The serial number is assumed to be 1 [starting from 0]). The calling method is to first specify the device number rpc_set_devid(123), and then call the function rpc_api.semd->dht11->read_data(&temp,&humit); the dht11_read_data() function call in the semd device numbered 123 is completed.

[0109] The steps S1, S2 and S3 also include the following communication processing process:

[0110] S3-1 initializes all network modules, resets the timestamps and frame sequence numbers of all device RPC interfaces, and then goes to S3-2;

[0111] S3-2 determines whether there is data to be sent in the sending buffer. If there is data, if encryption is required, the data is encrypted first, and then the data in the buffer is sent out through the specified data sending interface according to the storage order and the communication type in the RPC data frame. After all data is sent, go to S3-3;

[0112] S3-3 determines whether there is data in the receiving buffer. If there is data, if encryption is used, the data is first decrypted and the decrypted data is verified. If the verification fails, the data verification failure status is sent back to the source device, and then the process goes to S3-5.

[0113] S3-4 determines whether the RPC error code is 0. If not, go to S3-6. Otherwise, determine whether the frame number in the received RPC data frame is before the frame number of the device RPC interface and whether the timestamp is close to the local timestamp. If not, determine that the data is invalid, and send the data timeout status back to the source device. Otherwise, determine the function type. If it is an active function remote call function type, transmit the parsed RPC data frame to the RPC management module, and then go to S3-5. If it is a function remote call return result type, transmit the parsed RPC data frame to the RPC Management module, parses the returned result at the same time, notifies the called function that the remote function call process has been completed, releases the memory of the corresponding RPC data frame, and then goes to S3-5; if it is a callback function type, the parsed RPC data frame is transmitted to the RPC management module, and the corresponding function is called according to the set callback function, and then goes to S3-5; if it is an interrupt function, the parsed RPC data frame is transmitted to the RPC management module, and the corresponding function is called according to the set interrupt function, and then goes to S3-5; in addition, this function type will be added, deleted, and modified according to actual needs;

[0114] S3-5 checks whether the timestamps in all sent RPC data frames have timed out. If not, it goes to S3-2. If the return data has not been received after the specified time, it notifies the called function that the remote function call has timed out, releases the memory of the corresponding RPC data frame, and goes to S3-2.

[0115] S3-6 determines whether the number of retransmissions of the current data frame reaches the specified number. If so, the called function is notified that the remote function call has failed, and then the process goes to S3-2. If not, the data is resent, and then the process goes to S3-2.

[0116] Obviously, the above embodiments are merely examples for the purpose of clear explanation, and are not intended to limit the implementation methods. For those skilled in the art, other different forms of changes or modifications can be made based on the above description. It is not necessary and impossible to list all the implementation methods here. The obvious changes or modifications derived therefrom are still within the scope of protection of the invention.

Claims

1. A distributed code automatic generation system based on virtual simulation, characterized in that: Including development module, virtual simulation module and automatic code generation module; The development modules include function management module, RPC management module and communication management module; The function management module is used to manage the RPC function of the current device, that is, the function entity is in the current device, and other devices access the function of the current device through the RPC interface; The RPC management module is used to manage the device RPC interface between different devices to implement remote function calls between different devices, including the local device remotely calling the interface of other devices and parsing the RPC data frame from the communication management module; The communication management module is used to maintain the communication between different devices, including receiving data streams from other devices, storing the received data in the receiving buffer, decrypting and verifying the data in the receiving buffer, and passing the verified data to the RPC management module in the form of RPC data frames for further processing. At the same time, it also receives RPC data frames from the RPC management module and stores them in the sending buffer. After encrypting the data, the data is sent out through the specified communication method, and automatically resends when the sending data times out, and automatically filters out redundant information when the same message is received; The code automatic generation module includes a peripheral library management unit, a visual parameter configuration unit, a code automatic generation unit and a peripheral library module; The peripheral library module includes MCU project templates and peripheral modules; The peripheral library management unit is used to add microcontroller project templates and peripheral modules to the peripheral library module; it is also used to generate hardware resource description files and source code generation scripts; The visual parameter configuration unit is used to realize the parameter configuration of the MCU project peripheral modules and MCU projects; The code automatic generation unit is used to adjust and modify the corresponding source code according to the configuration information of the single-chip microcomputer and the configuration information of the peripheral module; The virtual simulation module includes a virtual single-chip computer module, a virtual device processing engine module, a single-chip computer development project description script module and a virtual peripheral UI description script module; The virtual MCU module is used to simulate the MCU on the PC side to connect to the virtual device processing engine to achieve the purpose of simulation; The virtual device processing engine module is used to load the MCU development project description script from the external storage device when the user opens the virtual simulation software, parse all peripheral modules from the script, and then load all corresponding virtual peripheral UI description scripts from the peripheral library module according to the MCU development project description script, and display them in the corresponding interface according to the parsed content; The MCU development project description script module is used to record the configuration parameters of the generated MCU development project; The virtual peripheral UI description script module is used to describe the appearance and internal components of the virtual device through QML, and at the same time implement all function interface processing capabilities of the peripheral in the script.

2. The distributed code automatic generation system based on virtual simulation according to claim 1 is characterized in that: The hardware resource description file is used to record the microcontroller hardware resources, including at least the microcontroller model, the number of pins, and the functions and hardware resources of each pin.

3. The distributed code automatic generation system based on virtual simulation according to claim 2 is characterized in that: The peripheral library management unit is also used to debug the virtual peripheral UI description script module.

4. The distributed code automatic generation system based on virtual simulation according to claim 3 is characterized in that: The virtual peripheral UI description script module is used to process the RPC data frame from the RPC interface processing module, parse the received data into the corresponding function and parameter values, and take corresponding actions according to the function and parameter values.

5. The distributed code automatic generation system based on virtual simulation according to claim 4 is characterized in that: The single-chip microcomputer development project description script module is also used to obtain the names and path addresses of all peripherals by reading the peripheral configuration information when generating a virtual simulation interface, and load the virtual peripheral UI description script from the specified location according to the name and address.

6. The distributed code automatic generation system based on virtual simulation according to claim 5 is characterized in that: The MCU development project description script module is used to obtain the MCU configuration information from the system variables, and then copy the project template from the specified path of the peripheral library to the user-specified storage path, and at the same time copy all peripheral modules from the specified location to the user-specified storage path, and then run the source code generation script.

7. A distributed code automatic generation method based on virtual simulation, according to any one of claims 1-6, characterized in that: Here are the steps: S1 first uses the embedded system distributed development method to implement remote function calls between different devices through RPC technology; S2 is based on RPC technology and uses virtual simulation technology to associate remote functions with virtual devices in the form of simulated function interfaces on the PC side; S3 connects the virtual MCU module with the virtual device through RPC technology, and then develops the implementation logic of the actual project in the virtual MCU module to control the virtual device. When the data value of the sensor needs to be modified, it is modified directly through the virtual device; S4 is completed by the developer or hardware manufacturer through the peripheral library management unit to design the peripheral library and add it to the peripheral library unit. When using the tool, the peripheral library management unit will automatically load the corresponding single-chip microcomputer and peripheral modules from the peripheral library unit for user selection, and complete the corresponding parameter configuration. After configuration, the single-chip microcomputer development project is automatically generated through the code automatic generation unit, and then the corresponding functions are implemented based on the development project; and when the virtual simulation function is selected, the visual parameter configuration unit automatically adds the virtual peripheral UI description script to the project, and then when the virtual simulation tool is started, a virtual simulation device is generated according to the single-chip microcomputer development project description script and the virtual peripheral UI description script.

8. The method of the distributed code automatic generation system based on virtual simulation according to claim 7 is characterized in that: The data processing process of the function management module in step S1 is as follows: S1-1 defines the device RPC interface and initializes it; S1-2 deserializes and parses the data frame passed by the RPC management module, calls the corresponding function according to the parsing result, and passes the serialized data frame returned by the function to the RPC management module for further processing.

9. The method of the distributed code automatic generation system based on virtual simulation according to claim 8, characterized in that: The data processing process of the RPC management module also included in steps S1 and S2 is as follows: S2-1 completes the device RPC interface definition of all device types according to the function management module, then completes the definition of all functions according to each peripheral module and interface variable, and initializes all device RPC interfaces to the defined functions; S2-2 implements various peripheral modules and interface variables; Remote call of S2-3 function. When the current device needs to remotely access other device function interfaces through the RPC interface, first specify the corresponding device number, and then access it through the rpc_api RPC interface; The step S2-2 also includes the following implementation process of each peripheral module and interface variable: S2-2-1 In each function, obtain all the input parameters and return parameters of the corresponding function, calculate the length of the input parameters and return parameters to be serialized, dynamically apply for memory matching the RPC data frame according to the length, and serialize according to the input parameters and return parameters, and then pass the serialized data to the communication management module; S2-2-2 Wait for the communication management module to return the call result, and determine whether the parameter type is normal based on the RPC data frame in the return result. If normal, deserialize it based on the return parameter length, return parameter sequence, input parameter length and input parameter sequence to obtain the function return result, and pass the return result to the called function; if the parameter type is judged to be an abnormal value, directly use the parameter type as the return value of the function and end the function call.

10. The method of the distributed code automatic generation system based on virtual simulation according to claim 9, characterized in that: The steps S1, S2 and S3 also include the following communication processing process: S3-1 initializes all network modules, resets the timestamps and frame sequence numbers of all device RPC interfaces, and then goes to S3-2; S3-2 determines whether there is data to be sent in the sending buffer. If there is data, if encryption is required, the data is encrypted first, and then the data in the buffer is sent out through the specified data sending interface according to the storage order and the communication type in the RPC data frame. After all data is sent, go to S3-3; S3-3 determines whether there is data in the receiving buffer. If there is data, if encryption is used, the data is first decrypted and the decrypted data is verified. If the verification fails, the data verification failure status is sent back to the source device, and then the process goes to S3-5. S3-4 determines whether the RPC error code is 0. If not, go to S3-6. Otherwise, determine whether the frame number in the received RPC data frame is before the frame number of the device RPC interface and whether the timestamp is close to the local timestamp. If not, determine that the data is invalid, and send the data timeout status back to the source device. Otherwise, determine the function type. If it is an active function remote call function type, transmit the parsed RPC data frame to the RPC management module, and then go to S3-5. If it is a function remote call return result type, the parsed RPC data frame is transmitted to the RPC management module, and the returned result is parsed to notify the called function that the remote function call process has been completed, and the memory of the corresponding RPC data frame is released, and then it goes to S3-5; if it is a callback function type, the parsed RPC data frame is transmitted to the RPC management module, and the corresponding function is called according to the set callback function, and then it goes to S3-5; if it is an interrupt function, the parsed RPC data frame is transmitted to the RPC management module, and the corresponding function is called according to the set interrupt function, and then it goes to S3-5; in addition, this function type will be added, deleted, and modified according to actual needs; S3-5 checks whether the timestamps in all sent RPC data frames have timed out. If not, it goes to S3-2. If the return data has not been received after the specified time, it notifies the called function that the remote function call has timed out, releases the memory of the corresponding RPC data frame, and goes to S3-2. S3-6 determines whether the number of retransmissions of the current data frame reaches the specified number. If so, the called function is notified that the remote function call has failed, and then the process goes to S3-2. If not, the data is resent, and then the process goes to S3-2.

Images