A DDS deployment method, device, electronic device and storage medium based on MCU

Abstract

The present invention provides a DDS deployment method, device, electronic device and storage medium based on MCU. The method comprises: obtaining a DDS source file and information of an MCU to be deployed, replacing an interface in the DDS source file according to abstract interface information, and obtaining a DDS protocol interface; determining a compilation tool corresponding to the architecture of the MCU to be deployed according to the architecture information, integrating SDK based on the compilation tool, determining content to be compiled, compiling the content to be compiled, obtaining a compilation result, sending the compilation result to the MCU to be deployed via a DDS protocol interface, completing DDS deployment, and performing DDS communication of different functions; the present invention solves the problem of deploying DDS based on MCU in the absence of an operating system or a streamlined system, provides a wider range of DDS application scenarios for the field of intelligent driving, and is conducive to the promotion of DDS in the field of intelligent driving.

Description

Technical Field

[0001] The present application relates to the field of computer applications, and in particular to a DDS deployment method, device, electronic device and storage medium based on MCU. Background Art

[0002] SOA (Service-Oriented Architecture) Service-oriented architecture is a component model that connects different functional units of applications (called services) through well-defined interfaces and contracts between these services. As the concept of SOA is introduced into the design of in-vehicle software, it serves as the technical foundation platform for realizing software-defined cars. The realization of SOA architecture has a key step, that is, SOC (Service-Oriented Communication); and DDS (Data Distribution Service) is an important tool for realizing SOC. DDS can transmit and distribute data from many smart terminals in real time. Its characteristics are that it does not limit the number and capacity of reports in the network in a very short time, and realizes highly reliable data communication. At present, DDS has been widely used in the field of communications, including but not limited to various information transmission scenarios in industry, transportation, energy, medical care, and military. MCU is also widely used in the automotive field, for example: instrument data processing, motor control, air conditioning frequency conversion, door detection, temperature detection and other scenarios all have MCU.

[0003] For traditional cars, when the amount of data is not large, the car can use internal transmission methods, such as CAN bus, I2C, serial port and other communication methods for data transmission. However, when the amount of data is large and complex, data transmission becomes difficult. For intelligent driving, data transmission has high requirements for transmission rate, reliability and real-time transmission. At this time, traditional communication methods are no longer applicable. At present, the communication of existing MCUs is mainly completed through peripheral protocols, such as serial ports, SPI, CAN and other classic communication protocols. However, these protocols cannot meet the requirements of high real-time, high speed, low latency, reliable and stable, and DDS has these characteristics. Previously, DDS was more used for data transmission between PCs or servers, but with the rise of intelligent driving, DDS is now also applied to various control domains, among which communication between MCUs is particularly important.

[0004] However, there are still many problems in how to complete the deployment of the DDS protocol on MCU. One of the main characteristics of MCU is that it has few resources, which means that the compatibility of the DDS protocol stack needs to be adapted when it is running. The existing methods are basically focused on DDS deployment with complex operating systems, and there is no special DDS deployment for MCUs without operating systems or with streamlined operating systems, so the applicability is not strong. Summary of the invention

[0005] In view of the above-mentioned shortcomings of the prior art, the present invention provides a DDS deployment method, device, electronic device and storage medium based on MCU to solve the above-mentioned technical problems.

[0006] The MCU-based DDS deployment method provided in the present application includes: obtaining a DDS source file and information about an MCU to be deployed, wherein the information about the MCU to be deployed includes abstract interface information and architecture information; replacing the interface in the DDS source file according to the abstract interface information to obtain a DDS protocol interface; determining a compilation tool corresponding to the architecture of the MCU to be deployed according to the architecture information, integrating SDK based on the compilation tool, and determining content to be compiled; compiling the content to be compiled based on the compilation tool under a preset compilation environment to obtain a compilation result, wherein the compilation environment is built based on the architecture information and the architecture of the MCU to be deployed; sending the compilation result to the MCU to be deployed via the DDS protocol interface to complete the DDS deployment so as to perform DDS communication with different functions.

[0007] In one embodiment of the present application, the DDS source file is compiled based on the compilation tool to obtain a script file for describing the compilation and connection rules of the project, and the compilation is a cross-compilation based on generating executable code on one platform on another platform; the script file is parsed by a command tool to obtain a binary file and / or a library file, and the binary file and / or the library file is used as the compilation result.

[0008] In one embodiment of the present application, if the MCU to be deployed has an operation management system, the library file is linked and the library file is added to the environment variable to form a dynamic library, so that the MCU to be deployed calls the DDS protocol interface to complete the DDS deployment, and upgrades and maintains by replacing the library file; if the MCU to be deployed does not have an operation management system, the protocol stack content of the DDS source file is generated in the binary file in the form of firmware, so that the MCU to be deployed calls the DDS protocol interface according to the header file of the DDS source file to complete the DDS deployment.

[0009] In one embodiment of the present application, an application is written at the application layer for testing and function demonstration; the written application is supplied to the MCU to be deployed for application through the DDS protocol interface.

[0010] In one embodiment of the present application, DDS parameter data is stored in a string in json format, and the string is sent to the MCU to be deployed. The DDS parameter data includes domain participant information, DDS topic information, publisher information and data writing information, subscriber information and data reading information, or a combination of several of them.

[0011] In one embodiment of the present application, data transmission is performed through a socket protocol to obtain a DDS source file and information about the MCU to be deployed; if an operation management system exists for the MCU to be deployed, and resources are greater than or equal to a preset resource threshold, the TCP / IP protocol stack is determined to be the DDS data transmission protocol; if an operation management system does not exist for the MCU to be deployed, or resources are less than a preset resource threshold, the UDP protocol stack is determined to be the DDS data transmission protocol.

[0012] In one embodiment of the present application, if there is an operation management system for the MCU to be deployed, the interface in the DDS source file is replaced according to the abstract interface information to obtain the DDS protocol interface; if there is no operation management system for the MCU to be deployed, task polling is performed on the MCU to be deployed so that the MCU to be deployed is interface-adapted with the DDS source file.

[0013] The present application also provides a DDS deployment device based on MCU, including: an information acquisition module, used to obtain DDS source files and MCU information to be deployed, the MCU information to be deployed includes abstract interface information and architecture information; an interface module, used to replace the interface in the DDS source file according to the abstract interface information, and obtain a DDS protocol interface; a compilation module, used to determine a compilation tool corresponding to the architecture of the MCU to be deployed according to the architecture information, perform SDK integration based on the compilation tool, and determine the content to be compiled; under a preset compilation environment, compile the content to be compiled based on the compilation tool to obtain a compilation result, and the compilation environment is built based on the architecture information and the architecture of the MCU to be deployed; a deployment module, used to send the compilation result to the MCU to be deployed via the DDS protocol interface, complete the DDS deployment, and perform DDS communication with different functions.

[0014] According to one aspect of an embodiment of the present application, an electronic device is provided, comprising: one or more processors; a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the electronic device implements the MCU-based DDS deployment method as described above.

[0015] According to one aspect of an embodiment of the present application, a computer-readable storage medium is provided, on which computer-readable instructions are stored. When the computer-readable instructions are executed by a processor of a computer, the computer executes the MCU-based DDS deployment method as described above.

[0016] In the technical solutions provided in some embodiments of the present application, the MCU-based DDS deployment method, device, electronic device and storage medium in the present application solve the problem of deploying DDS on an MCU without an operating system or a streamlined operating system. Whether it is an MCU without an operating system or an MCU with a streamlined RTOS, the present application can overcome the lack of DDS-dependent components when system resources are low and realize the deployment of DDS on the MCU, greatly improving the adaptability of DDS deployment, solving the problem of deploying DDS based on MCU when there is no operating system or a streamlined system, providing a wider range of DDS application scenarios for the field of intelligent driving, and facilitating the promotion of DDS in the field of intelligent driving.

[0017] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The drawings herein are incorporated into the specification and constitute a part of the specification, showing embodiments consistent with the present application, and together with the specification, are used to explain the principles of the present application. Obviously, the drawings described below are only some embodiments of the present application, and for those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative work. In the drawings:

[0019] Figure 1 It is a flowchart of a DDS deployment method based on MCU shown in an exemplary embodiment of the present application;

[0020] Figure 2 It is a specific flow chart of a DDS deployment method based on MCU shown in an exemplary embodiment of the present application;

[0021] Figure 3 It is a schematic diagram of a cross-compilation process in a DDS deployment method based on an MCU shown in an exemplary embodiment of the present application;

[0022] Figure 4 is a block diagram of an MCU-based DDS deployment device shown in an exemplary embodiment of the present application;

[0023] Figure 5 A schematic diagram of the structure of a computer system suitable for implementing an electronic device of an embodiment of the present application is shown. DETAILED DESCRIPTION

[0024] The following will describe the embodiments of the present invention with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the contents disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention, not for limiting the scope of protection of the present invention.

[0025] It should be noted that the illustrations provided in the following embodiments are only schematic illustrations of the basic concept of the present invention, and thus the drawings only show components related to the present invention rather than being drawn according to the number, shape and size of components in actual implementation. In actual implementation, the type, quantity and proportion of each component may be changed arbitrarily, and the component layout may also be more complicated.

[0026] In the following description, numerous details are discussed to provide a more thorough explanation of the embodiments of the present invention. However, it is obvious to those skilled in the art that the embodiments of the present invention can be implemented without these specific details. In other embodiments, well-known structures and devices are shown in the form of block diagrams rather than in detail to avoid making the embodiments of the present invention difficult to understand.

[0027] The term "multiple" as used in this application refers to two or more than two. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the related objects are in an "or" relationship.

[0028] First of all, it should be explained that the Microcontroller Unit (MCU), also known as a single chip microcomputer or a single chip microcomputer, is a chip-level computer that appropriately reduces the frequency and specifications of the central processing unit (CPU), and integrates memory, timer, USB, A / D conversion, UART, PLC, DMA and other peripheral interfaces, and even LCD driver circuits on a single chip to form a chip-level computer, which can perform different combination controls for different application scenarios. At present, it has been widely used in the field of smart cars.

[0029] Data Distribution Service (DDS) defines an efficient service for distributing data between participants in distributed applications. DDS is a data-centric middleware protocol and API standard published by the Object Management Group (OMG). DDS integrates various components in the system, providing low-latency data connections, high reliability, and highly scalable architecture to meet the needs of commercial-grade IoT applications.

[0030] The communication of existing MCUs is mainly completed through peripheral protocols, such as serial ports, SPI, CAN and other classic communication protocols. However, these protocols cannot meet the requirements of high real-time, high speed, low latency, reliability and stability, and DDS has these characteristics. Previously, DDS was more used for data transmission between PCs or servers, but with the rise of intelligent driving, DDS is now also applied to various control domains, among which communication between MCUs is particularly important. However, it is still worth studying how to complete the deployment of the DDS protocol on the MCU. A major feature of the MCU is that it has few resources, which leads to the need to adapt the compatibility of the DDS protocol stack when it is running. Most of the current patents focus on the deployment of DDS with complex operating systems, and there is no way to deploy MCUs without operating systems or with streamlined operating systems.

[0031] Figure 1 FIG. 1 is a flowchart of an MCU-based DDS deployment method according to an exemplary embodiment of the present application. The MCU-based DDS deployment method can be executed by the vehicle side. Figure 1 As shown, the MCU-based DDS deployment method includes at least steps S110 to S150, which are described in detail as follows:

[0032] In step S110, the DDS source file and the MCU information to be deployed are obtained, and the MCU information to be deployed includes abstract interface information and architecture information.

[0033] In one embodiment of the present application, since no matter it is an MCU without an operating system or an MCU with a streamlined RTOS, their common point is that the system resources are few, and they lack DDS dependent components, and need to be adapted. Therefore, by solving the deployment of DDS dependencies, it is possible to deploy DDS on the MCU. In this embodiment, first obtain the DDS source file and the MCU information to be deployed, and the MCU information to be deployed includes abstract interface information and architecture information. Take FreeRTOS (an open source real-time operating system) as an example, it does not have a shell, nor does it have the content that DDS may need, such as a file system and a network system, and its kernel can even be only 6kb in size. For some MCUs with fewer resources, it is very suitable to transplant FreeRTOS for multi-tasking systems. Therefore, to deploy DDS on FreeRTOS, it is only necessary to add the dependencies of DDS to the MCU. When deploying, first consider what components DDS needs, which can be judged by the obtained DDS source files and the MCU information to be deployed.

[0034] In step S120, the interface in the DDS source file is replaced according to the abstract interface information to obtain a DDS protocol interface.

[0035] In one embodiment of the present application, FreeRTOS is also taken as an example. For MCUs with FreeRTOS, since FreeRTOS comes with common operation interfaces, such as threads, signals, mutexes, queues, etc., it is only necessary to replace the relevant APIs (programming interfaces) in the DDS source code. For MCUs without an operating system, in order to adapt to the DDS source code as much as possible, it is necessary to make some improvements to the protocol stack. For example, MCUs without an operating system usually execute application functions by polling tasks in a background cycle, and some blocking scenarios need to be considered for processing. For example, when receiving data, it is possible to consider receiving data in the form of polling callbacks to avoid background blocking when there is no data.

[0036] In step S130, a compilation tool corresponding to the architecture of the MCU to be deployed is determined according to the architecture information, SDK integration is performed based on the compilation tool, and content to be compiled is determined.

[0037] In one embodiment of the present application, first obtain the cross-compilation tool corresponding to the MCU architecture. For example, for aarch64, i.e., the ARM architecture 64-bit system, different versions of the tool rely on different library files. Therefore, all programs under the same MCU should be completed with only one compiler as much as possible. Then, merge the code, integrate the SDK, and write the makefile. This step is mainly the work before program compilation.

[0038] In step S140, the content to be compiled is compiled based on a compilation tool in a preset compilation environment to obtain a compilation result, and the compilation environment is built based on the architecture information and the architecture of the MCU to be deployed.

[0039] In one embodiment of the present application, the compilation environment must be built first. For example, when compiling a 64-bit program, a 64-bit system should be selected as much as possible, otherwise the dependency library may not match. During compilation, the usual step is to use cmake and then perform make to generate binary files or library files. Since windows does not support cross-compilation enough, cross-compilation is performed under the linux system in this embodiment. Finally, library file links or binary file burning are performed. For systems with file systems or memory management, the generated library files can be linked. First, the library files are added to the environment variables, and then the header files of DDS are included. All apis in DDS can be used, and since the generated library files are dynamic libraries, subsequent upgrades and maintenance only need to replace the library files. However, some MCUs do not have an operating system, and the protocol stack content of DDS is generated in a binary file in the form of firmware, so there is no operation of replacing the library. Similarly, the DDS protocol interface can be called after the api declaration of DDS in the header file, but subsequent upgrades and maintenance require compilation and burning of new firmware.

[0040] In step S150, the compilation result is sent to the MCU to be deployed via the DDS protocol interface to complete the DDS deployment so as to perform DDS communication of different functions.

[0041] In one embodiment of the present application, after completing the above steps S110-S140, DDS can be used normally. However, it should be noted that if the DDS protocol is not well understood, some functional deviations may occur. For MCU, since there is no complex operating system for human-computer interaction, engineers need to consider how to use it conveniently. In this embodiment, some of the content required by DDS is first saved in a string in json format and sent to the MCU for processing in the form of a serial port or file. The content referred to here includes but is not limited to domain participants (Domain Participant), DDS topics (Topic), publishers (Publisher) and data writers (Data Writer), subscribers (Subscriber) and data readers (Data Reader). These parameters will work together to generate a complete set of DDS data transmission system. In addition, DDS has an important parameter, Qos (quality of service), that is, quality of service. DDS has a variety of Qos, each of which involves different message strategies. The above parameters can be configured when data is published, so it can be handled flexibly.

[0042] In one embodiment of the present application, the DDS source file can be compiled based on the compilation tool cmake to obtain a script file for describing the compilation and connection rules of the project. The compilation is based on the cross-compilation of the executable code on another platform generated on one platform. In this embodiment, the compilation tool is a cross-platform compilation tool, and the compilation process of all platforms can be described with simple statements. Various makefiles or project files can be output by the compilation tool. Then, the script file is parsed by the command tool make to obtain a binary file and / or a library file, and the binary file and / or the library file are used as the compilation result. The script file in this embodiment is a Makefile file, and the Makefile file describes the compilation, connection and other rules of the entire project. The command tool in this embodiment is a Make tool, and its most important and basic function is to describe the relationship between source programs and automatically maintain the compilation work through the makefile file.

[0043] In one embodiment of the present application, if there is an operation management system for the MCU to be deployed, the library file is linked, and the library file is added to the environment variable to form a dynamic library, so that the MCU to be deployed calls the DDS protocol interface, completes the DDS deployment, and upgrades and maintains by replacing the library file; if there is no operation management system for the MCU to be deployed, the protocol stack content of the DDS source file is generated in the binary file in the form of firmware, so that the MCU to be deployed calls the DDS protocol interface according to the header file of the DDS source file to complete the DDS deployment. Specifically, for a system with a file system or memory management, the generated library file can be linked, first the library file is added to the environment variable, and then the header file of DDS is included, so that all the apis in DDS can be used. Since the library file generated in this embodiment is a dynamic library, subsequent upgrades and maintenance only need to replace the library file. However, some MCUs have no operating system, and the protocol stack content of DDS is generated in the binary file in the form of firmware. Therefore, there is no operation of replacing the library. Similarly, the DDS protocol interface can be called after the DDS api declaration in the header file, but subsequent upgrades and maintenance require compilation and burning of new firmware.

[0044] In one embodiment of the present application, before cross-compilation, it is also necessary to adapt the OSAL of DDS. OSAL in this embodiment refers to the operating system abstract interface. DDS programs, especially some open source codes, inevitably use some operations related to the operating system. The DDS protocol stack source code is written in C / C++, so the adaptation of OSAL requires engineers to use the C / C++ programming language for adaptation. For MCUs with systems, it is only necessary to replace the relevant APIs (program programming interfaces) in the DDS source files. For MCUs without operating systems, in order to adapt to the DDS source code as much as possible, it is necessary to make some improvements to the protocol stack. For example, MCUs without operating systems usually execute application functions by task polling in a background cycle, and some blocking scenarios need to be considered for processing. Then, application programs are written at the application layer for testing and function demonstration; the written application programs are supplied to the MCU to be deployed for application through the DDS protocol interface. In this embodiment, from the perspective of the deployer, on the one hand, it is necessary to write demos for testing or function demonstration. On the other hand, the content in DDS is also provided to other applications of the MCU in the form of APIs. In this way, the MCU can directly call the data interface of DDS to transmit data, which greatly improves the work efficiency for MCUs with fewer resources. In this embodiment, regardless of whether there is an operating system, the application interface is consistent, so when deploying DDS on the MCU, whether there is an operating system or not does not affect the development of the application.

[0045] In one embodiment of the present application, when DDS transmits data, DDS has two main modes, one is to rely on socket (socket protocol), the bottom layer is TCP / IP protocol, and the other is to rely on shared memory. However, this method of shared memory is generally for operating systems with a complete memory management system, such as Linux and Windows systems, and is not applicable to MCU. In this embodiment, data transmission is performed through the socket protocol to obtain DDS source files and information about the MCU to be deployed; if the MCU to be deployed has an operation management system, and the resources are greater than or equal to the preset resource threshold, the TCP / IP protocol stack is determined to be the DDS data transmission protocol; if the MCU to be deployed does not have an operation management system, or the resources are less than the preset resource threshold, the UDP protocol stack is determined to be the DDS data transmission protocol. In this embodiment, DDS uses socket, and both TCP and UDP protocols can be selected, and RTCP (real-time transport protocol) can also be selected. In this embodiment, the transplantation of the TCP / IP protocol stack needs to be completed first. For example, on many MCUs with smaller resources, lwip is selected as the TCP / IP protocol stack, and some MCUs only consider transplanting the simplified UDP protocol because they have no operating system or very small resources.

[0046] Figure 2 It is a specific flow chart of a DDS deployment method based on MCU shown in an exemplary embodiment of the present application.

[0047] like Figure 2 As shown, in this embodiment, the DDS source file can be obtained, and the network protocol stack can be transplanted into the SDK of DDS; then, OSAL is adapted according to different platforms, and the DDS protocol stack is adapted to OSAL; then the application code is written, and the SDK of DDS is merged; a LINUX cross-compilation environment is built, cross-compilation is performed, and binary files or library files are generated; finally, the API of DDS is called in other applications, and parameters are configured for DDS communication with different functions. Through the above steps, the deployment of DDS on MCU can be completed. In this embodiment, the biggest difference between having an operating system and not having one is the adaptation of OSAL, and the subsequent work is basically considered based on the situation where the MCU has fewer resources. The method in this embodiment solves the problem of deploying DDS based on MCU without an operating system. Providing a wider range of DDS application scenarios for the field of intelligent driving is conducive to the promotion of DDS in the field of intelligent driving.

[0048] Figure 3 It is a schematic diagram of the cross-compilation process in the MCU-based DDS deployment method shown in an exemplary embodiment of the present application.

[0049] like Figure 3 As shown, in this embodiment, the specific steps include S310-S340.

[0050] S310. First, obtain the cross-compilation tool corresponding to the MCU architecture. Different versions of the tool depend on different library files. All programs under the same MCU should be completed with only one compiler as much as possible.

[0051] S320, merge code, integrate SDK, and write makefile. This step is mainly the work before program compilation. For MCUs on certain platforms, the default make method may be through cmake, and engineers need to consider how to write it. On the one hand, it is necessary to configure what needs to be compiled. For example, the DDS completion protocol stack contains many examples and tools, and a full compilation will take up additional memory space. On the other hand, it is necessary to set the link method, such as generating a dynamic library or a static library. Usually, considering the resource size and maintenance compilation, choose to generate a dynamic library.

[0052] S330, cross-compile under Linux system. Set up the compilation environment. For example, when compiling a 64-bit program, choose a 64-bit system as much as possible, otherwise there may be a problem of mismatching dependent libraries. When compiling, the usual steps are to use cmake and then make to generate binary files or library files.

[0053] S340, library file link or binary file burning. For systems with file systems or memory management, you can link the generated library file, first add the library file to the environment variable, and then include the DDS header file to use all the APIs in DDS.

[0054] The following describes an embodiment of the device of the present application, which can be used to execute the self-learning method in the above embodiment of the present application. For details not disclosed in the embodiment of the device of the present application, please refer to the embodiment of the self-learning method in the above embodiment of the present application.

[0055] Figure 4 It is a block diagram of an MCU-based DDS deployment device shown in an exemplary embodiment of the present application.

[0056] The MCU-based DDS deployment device in this embodiment includes:

[0057] The information collection module is used to obtain the DDS source file and the MCU information to be deployed, and the MCU information to be deployed includes abstract interface information and architecture information.

[0058] The interface module is used to replace the interface in the DDS source file according to the abstract interface information to obtain the DDS protocol interface.

[0059] The compilation module is used to determine the compilation tool corresponding to the architecture of the MCU to be deployed according to the architecture information, integrate the SDK based on the compilation tool, and determine the content to be compiled; under a preset compilation environment, compile the content to be compiled based on the compilation tool to obtain the compilation result. The compilation environment is built based on the architecture information and the architecture of the MCU to be deployed.

[0060] The deployment module is used to send the compilation result to the MCU to be deployed via the DDS protocol interface to complete the DDS deployment so as to perform DDS communication of different functions.

[0061] The MCU-based DDS deployment device in this embodiment is a device corresponding to the above method, and the above method can be used to perform DDS deployment. It should be noted that the device provided in the above embodiment and the method provided in the above embodiment belong to the same concept, and the specific manner in which each module and unit performs the operation has been described in detail in the method embodiment, which will not be repeated here. In actual applications, the device provided in the above embodiment can distribute the above functions to different functional modules as needed, that is, divide the internal structure of the device into different functional modules to complete all or part of the functions described above, and this is not limited here.

[0062] An embodiment of the present application also provides an electronic device, comprising: one or more processors; a storage device for storing one or more programs, when the one or more programs are executed by the one or more processors, the electronic device implements the image processing method provided in the above-mentioned embodiments.

[0063] Figure 5 The structure diagram of the computer system suitable for implementing the electronic device of the embodiment of the present application is shown. It should be noted that: Figure 5 The computer system 1200 of the electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0064] like Figure 5 As shown, the computer system 1200 includes a central processing unit (CPU) 1201, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 1202 or the program loaded from the storage part 1208 to the random access memory (RAM) 1203, such as executing the method described in the above embodiment. In the RAM 1203, various programs and data required for system operation are also stored. The CPU 1201, the ROM 1202 and the RAM 1203 are connected to each other through the bus 1204. The input / output (I / O) interface 1205 is also connected to the bus 1204.

[0065] The following components are connected to the I / O interface 1205: an input section 1206 including a keyboard, a mouse, etc.; an output section 1207 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1208 including a hard disk, etc.; and a communication section 1209 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication section 1209 performs communication processing via a network such as the Internet. A drive 1210 is also connected to the I / O interface 1205 as needed. A removable medium 1211, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 1210 as needed so that a computer program read therefrom is installed into the storage section 1208 as needed.

[0066] In particular, according to an embodiment of the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a computer program for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication section 1209, and / or installed from a removable medium 1211. When the computer program is executed by a central processing unit (CPU) 1201, various functions defined in the system of the present application are executed.

[0067] It should be noted that the computer-readable medium shown in the embodiment of the present application can be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media can include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, wherein a computer-readable computer program is carried. This propagated data signal can take a variety of forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination of the above. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. A computer program contained on a computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above.

[0068] The flowchart and block diagram in the accompanying drawings illustrate the possible architecture, functions and operations of the system, method and computer program product according to various embodiments of the present application. Wherein, each box in the flowchart or block diagram can represent a module, a program segment, or a part of the code, and the above-mentioned module, program segment, or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of boxes in the block diagram or flowchart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0069] The units involved in the embodiments described in this application may be implemented by software or hardware, and the units described may also be set in a processor. The names of these units do not, in some cases, constitute limitations on the units themselves.

[0070] Another aspect of the present application also provides a computer-readable storage medium on which a computer program is stored, and when the computer program is executed by a processor, the road condition refreshing method as described above is implemented. The computer-readable storage medium may be included in the electronic device described in the above embodiment, or may exist independently without being assembled into the electronic device.

[0071] Another aspect of the present application also provides a computer program product or a computer program, which includes a computer instruction stored in a computer-readable storage medium. A processor of a computer device reads the computer instruction from the computer-readable storage medium, and the processor executes the computer instruction, so that the computer device executes the road condition refreshing method provided in each of the above embodiments.

[0072] The above embodiments are merely illustrative of the principles and effects of the present invention, and are not intended to limit the present invention. Anyone familiar with the technology may modify or change the above embodiments without violating the spirit and scope of the present invention. Therefore, all equivalent modifications or changes made by a person of ordinary skill in the art without departing from the spirit and technical ideas disclosed by the present invention shall still be covered by the claims of the present invention.

Claims

1. A DDS deployment method based on MCU, characterized in that: include: Obtaining DDS source files and information about the MCU to be deployed, wherein the information about the MCU to be deployed includes abstract interface information and architecture information; According to the abstract interface information, the interface in the DDS source file is replaced to obtain a DDS protocol interface; Determine a compilation tool corresponding to the architecture of the MCU to be deployed according to the architecture information, perform SDK integration based on the compilation tool, and determine the content to be compiled; Under a preset compilation environment, compile the content to be compiled based on the compilation tool, including compiling the DDS source file based on the compilation tool to obtain a script file for describing the compilation and connection rules of the project, and perform command parsing on the script file through a command tool to obtain a binary file and / or a library file to obtain a compilation result, wherein the compilation environment is built based on the architecture information and the architecture of the MCU to be deployed; Sending the compilation result to the MCU to be deployed via the DDS protocol interface to complete the DDS deployment so as to perform DDS communication with different functions; If the MCU to be deployed has an operation management system, the library file is linked and added to the environment variable to form a dynamic library, so that the MCU to be deployed calls the DDS protocol interface to complete the DDS deployment, and upgrades and maintains by replacing the library file; If the MCU to be deployed does not have an operation management system, the protocol stack content of the DDS source file is generated in the binary file in the form of firmware, so that the MCU to be deployed calls the DDS protocol interface according to the header file of the DDS source file to complete the DDS deployment.

2. The MCU-based DDS deployment method according to claim 1, characterized in that: The compilation is based on cross-compilation to generate executable code on one platform on another platform; The binary file and / or library file is taken as a compilation result.

3. The MCU-based DDS deployment method according to claim 1, characterized in that: Before compiling the content to be compiled based on the compilation tool, the method further includes: Write applications at the application layer for testing and functional demonstration; The written application program is supplied to the MCU to be deployed for application through the DDS protocol interface.

4. The MCU-based DDS deployment method according to any one of claims 1 to 3, characterized in that: Sending the compilation result to the MCU to be deployed via the DDS protocol interface also includes: The DDS parameter data is stored in a string in json format and sent to the MCU to be deployed. The DDS parameter data includes one or a combination of domain participant information, DDS topic information, publisher information and data writing information, subscriber information and data reading information.

5. The MCU-based DDS deployment method according to any one of claims 1 to 3, characterized in that: Before obtaining the DDS source file and the MCU information to be deployed, the following steps are also required: Data is transmitted through the socket protocol to obtain the DDS source file and the MCU information to be deployed; If the MCU to be deployed has an operation management system and the resources are greater than or equal to the preset resource threshold, the TCP / IP protocol stack is determined to be the DDS data transmission protocol; If the MCU to be deployed does not have an operation management system, or the resources are less than a preset resource threshold, the UDP protocol stack is determined to be the DDS data transmission protocol.

6. The MCU-based DDS deployment method according to any one of claims 1 to 3, characterized in that: Before compiling the content to be compiled based on the compilation tool, the method further includes: If the MCU to be deployed has an operation management system, the interface in the DDS source file is replaced according to the abstract interface information to obtain a DDS protocol interface; If the MCU to be deployed does not have an operation management system, task polling is performed on the MCU to be deployed, so that the MCU to be deployed performs interface adaptation with the DDS source file.

7. A DDS deployment device based on MCU, characterized in that: include: An information collection module is used to obtain DDS source files and information about the MCU to be deployed, where the information about the MCU to be deployed includes abstract interface information and architecture information; An interface module, used to replace the interface in the DDS source file according to the abstract interface information to obtain a DDS protocol interface; A compilation module, used to determine a compilation tool corresponding to the architecture of the MCU to be deployed according to the architecture information, perform SDK integration based on the compilation tool, and determine the content to be compiled; Under a preset compilation environment, compile the content to be compiled based on the compilation tool, including compiling the DDS source file based on the compilation tool to obtain a script file for describing the compilation and connection rules of the project, and perform command parsing on the script file through a command tool to obtain a binary file and / or a library file to obtain a compilation result, wherein the compilation environment is built based on the architecture information and the architecture of the MCU to be deployed; A deployment module, used to send the compilation result to the MCU to be deployed via the DDS protocol interface, complete the DDS deployment, and perform DDS communication of different functions; If the MCU to be deployed has an operation management system, the library file is linked and added to the environment variable to form a dynamic library, so that the MCU to be deployed calls the DDS protocol interface to complete the DDS deployment, and upgrades and maintains by replacing the library file; If the MCU to be deployed does not have an operation management system, the protocol stack content of the DDS source file is generated in the binary file in the form of firmware, so that the MCU to be deployed calls the DDS protocol interface according to the header file of the DDS source file to complete the DDS deployment.

8. An electronic device, characterized in that: include: one or more processors; A storage device for storing one or more programs, when the one or more programs are executed by the one or more processors, enables the electronic device to implement the MCU-based DDS deployment method as described in any one of claims 1 to 5.

9. A computer-readable storage medium, characterized in that: Computer-readable instructions are stored thereon, and when the computer-readable instructions are executed by a processor of a computer, the computer is caused to execute the MCU-based DDS deployment method described in any one of claims 1 to 5.

Images