Communication method, device, system and equipment between heterogeneous chips, and computer program product

Abstract

The invention discloses a communication method, device, system and equipment between heterogeneous chips and a computer program product, the heterogeneous chips comprise a first chip and a second chip, the method is executed by the first chip, and the method comprises the steps that after an operating system of the first chip is started, a DBus service is initialized; handshaking with the second chip and determining the version of a data transmission protocol between the chips, wherein the data transmission protocol is a data transmission protocol in a preset general format; and carrying out data transmission between heterogeneous chips based on the initialized DBus service and the data transmission protocol version. According to the method and the device, seamless communication between heterogeneous chips is realized through DBus service, a communication mechanism does not need to be modified or adapted greatly, and the universality and the flexibility of heterogeneous chip communication are improved. Besides, by defining communication protocols in a unified format, communication barriers generated due to different private protocols among heterogeneous chips are eliminated, the compatibility of the system is improved, and the development and maintenance cost caused by protocol mismatching is reduced.

Description

Technical Field

[0001] This application relates to the field of communication technologies, and in particular, to a communication method, device, system, equipment, and computer program product between heterogeneous chips. Background Art

[0002] With the rapid development of autonomous driving technology, as the core component for intelligent decision-making and execution in vehicles, the communication efficiency and reliability between internal components of the autonomous driving domain controller are directly related to the performance and safety of the entire system. In the architecture of the autonomous driving domain controller, the communication between the System on Chip (SOC) and the Microcontroller Unit (MCU) plays a crucial role. However, the traditional physical serial port (such as UART / RS-232) communication method has exposed a series of problems in this scenario and urgently needs to be improved and optimized.

[0003] The traditional physical serial port communication method mainly has the following defects:

[0004] 1) High hardware adaptation complexity

[0005] The traditional physical serial port communication method requires manual configuration of key parameters such as baud rate, data bits, and stop bits. These configurations are not only cumbersome but also extremely error-prone. In addition, the driver codes provided by different hardware manufacturers are often incompatible, resulting in a large amount of human and time costs being invested in the hardware adaptation process.

[0006] 2) Low development efficiency

[0007] When developers use traditional serial port communication, they need to repeatedly write UART drivers, protocol parsing, and exception handling logic. The process of parsing data frames is complex and involves underlying operations such as frame header recognition, length verification, and CRC verification. This not only increases the development difficulty but also reduces the development efficiency and increases the risk of errors.

[0008] 3) Poor cross-platform compatibility

[0009] In the architecture of the autonomous driving domain controller, the SOC usually runs on a non-real-time operating system (such as Ubuntu), while the MCU runs on a real-time operating system (RTOS). The traditional serial port communication method lacks a unified communication framework, resulting in developers needing to develop Linux driver layer codes and bare-metal protocol stacks separately on the SOC side and the MCU side. This not only increases the development workload but also reduces the code reusability.

[0010] 4) Difficult debugging

[0011] The physical serial port communication method is vulnerable to electromagnetic interference, resulting in unstable communication. At the same time, the traditional serial port communication method lacks a built-in log tracing mechanism, making it difficult to quickly locate problems during debugging.

[0012] 5) Difficult system maintenance

[0013] In the traditional serial port communication architecture, the coupling degree between the communication module and the business logic is high. Once the communication protocol needs to be modified, the code on the SOC side and the MCU side needs to be updated synchronously. In addition, the lack of a unified service management mechanism makes the hot upgrade and fault recovery of communication components extremely difficult. Summary of the Invention

[0014] To solve the above technical problems in at least one aspect, embodiments of the present application provide a heterogeneous chip intercommunication method, device, system, equipment, and computer program product to improve the flexibility and communication efficiency of heterogeneous chip intercommunication.

[0015] Embodiments of the present application adopt the following technical solutions:

[0016] In a first aspect, embodiments of the present application provide a heterogeneous chip intercommunication method. The heterogeneous chips include a first chip and a second chip. The heterogeneous chip intercommunication method is executed by the first chip, and the heterogeneous chip intercommunication method includes:

[0017] After the operating system of the first chip is started, initialize the DBus service;

[0018] Perform a handshake with the second chip and determine the version of the data transfer protocol between the first chip and the second chip. The data transfer protocol is a data transfer protocol in a preset general format;

[0019] Based on the initialized DBus service and the data transfer protocol version between the first chip and the second chip, perform data transfer between the first chip and the second chip.

[0020] Optionally, the initializing the DBus service after the operating system of the first chip is started includes:

[0021] After the operating system of the first chip is started, load the service process through the Systemd service manager;

[0022] After the service process is loaded, initialize the DBus connection and register the DBus service interface.

[0023] Optionally, the DBus service interface includes at least one of a configuration management interface, a data read / write interface, and a subscription interface;

[0024] The configuration management interface includes at least one of a network parameter configuration interface and a hardware information reading interface. The network parameter configuration interface is used to configure network transmission parameters between the first chip and the second chip, and the hardware information reading interface is used to read the hardware information of the second chip;

[0025] The data read / write interface includes at least one of a data writing interface and a data reading interface. The data writing interface is used to write data to the second chip, and the data reading interface is used to read sensor data;

[0026] The subscription interface includes at least one of an event subscription interface and an unsubscribe interface. The event subscription interface is used to subscribe to asynchronous events of the second chip, and the unsubscribe interface is used to cancel the subscription of asynchronous events.

[0027] Optionally, the heterogeneous chip communication method further includes:

[0028] Define a general format for the data transmission protocol;

[0029] Wherein, the general format includes a start field, a middle field, and a check field. The middle field includes protocol version information, instruction type, and payload data. The instruction type includes at least one of a configuration parameter instruction, a data reading instruction, and a data writing instruction.

[0030] Optionally, the heterogeneous chip communication method further includes:

[0031] Create a communication service program configuration file for the DBus service;

[0032] Wherein, the communication service program configuration file is used to configure at least one of status monitoring information, resource limit information, and log management information of the communication service program. The status monitoring information of the communication service program is used to monitor the status of the communication service program through a heartbeat mechanism. The resource limit information is used to control the resource occupancy of the communication service program. The log management information is used to store the running logs of the communication service program.

[0033] Optionally, the data transmission between the first chip and the second chip based on the initialized DBus service and the data transmission protocol version between the first chip and the second chip includes:

[0034] Receive a DBus service call request from the user;

[0035] Encapsulate a first data frame according to the DBus service call request and the data transmission protocol version;

[0036] Add the first data frame to the data sending queue, and asynchronously send the first data frame to the second chip through the data sending queue.

[0037] Optionally, the data transmission between the first chip and the second chip based on the initialized DBus service and the data transmission protocol version between the first chip and the second chip includes:

[0038] Receive a second data frame sent by the second chip;

[0039] Parse the second data frame to obtain the parsing result of the second data frame, where the parsing result includes the instruction type;

[0040] Generate a corresponding response frame according to the instruction type and return it to the second chip.

[0041] In a second aspect, an inter - heterogeneous - chip communication device is further provided in an embodiment of the present application. The heterogeneous chips include a first chip and a second chip. The inter - heterogeneous - chip communication device is applied to the first chip and includes:

[0042] An initialization unit, configured to initialize the DBus service after the operating system of the first chip is started;

[0043] A determination unit, configured to perform a handshake with the second chip and determine the version of the data transmission protocol between the first chip and the second chip, where the data transmission protocol is a data transmission protocol in a preset general format;

[0044] A transmission unit, configured to perform data transmission between the first chip and the second chip based on the initialized DBus service and the data transmission protocol version between the first chip and the second chip.

[0045] In a third aspect, an inter - heterogeneous - chip communication system is further provided in an embodiment of the present application. The inter - heterogeneous - chip communication system includes: a first chip and a second chip. The DBus service is deployed on the first chip, and data is transmitted between the first chip and the second chip through the DBus service. The first chip is configured to execute the inter - heterogeneous - chip communication method described in any one of the foregoing items.

[0046] In a fourth aspect, an embodiment of the present application further provides a device, including:

[0047] A processor; and a memory arranged to store computer - executable instructions, where the executable instructions, when executed, cause the processor to execute the inter - heterogeneous - chip communication method described in any one of the foregoing items.

[0048] Fifth aspect, an embodiment of the present application further provides a computer program product, including a computer program / instructions, and when the computer program / instructions are executed by a processor, the foregoing heterogeneous chip - to - chip communication method is implemented.

[0049] At least one of the above - mentioned technical solutions adopted in the embodiments of the present application can achieve the following beneficial effects: In the heterogeneous chip - to - chip communication method of the embodiments of the present application, the heterogeneous chips include a first chip and a second chip, and the heterogeneous chip - to - chip communication method is executed by the first chip. After the operating system of the first chip is started, the DBus service is initialized first; then a handshake is performed with the second chip to determine the version of the data transfer protocol between the first chip and the second chip, and the data transfer protocol is a data transfer protocol in a preset general format; finally, based on the initialized DBus service and the data transfer protocol version between the first chip and the second chip, data transfer between the first chip and the second chip is performed. The heterogeneous chip - to - chip communication method of the embodiments of the present application realizes seamless communication between heterogeneous chips through the DBus service, is applicable to different operating system platforms, does not require a large number of modifications or adaptations to the communication mechanism, and improves the generality and flexibility of heterogeneous chip communication. In addition, by defining a communication protocol with a unified format, the communication barriers caused by different private protocols between heterogeneous chips are eliminated, the compatibility of the system is improved, and the development and maintenance costs brought by protocol mismatch are reduced. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The schematic embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation of the present application. In the drawings:

[0051] Figure 1 It is a schematic flow chart of a heterogeneous chip - to - chip communication method in an embodiment of the present application;

[0052] Figure 2 It is a schematic flow chart of data sending based on the DBus service in an embodiment of the present application;

[0053] Figure 3 It is a schematic flow chart of data receiving based on the DBus service in an embodiment of the present application;

[0054] Figure 4 It is a schematic structural diagram of a heterogeneous chip - to - chip communication device in an embodiment of the present application;

[0055] Figure 5 It is a schematic structural diagram of a heterogeneous chip - to - chip communication system in an embodiment of the present application;

[0056] Figure 6 It is a schematic structural diagram of a device in an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0057] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments of this application and the corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, rather than all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without making creative efforts fall within the scope of protection of this application.

[0058] The following will, in conjunction with the drawings, elaborate on the technical solutions provided by each embodiment of this application.

[0059] A heterogeneous chip - to - chip communication method according to an embodiment of this application, as Figure 1 shown, provides a flowchart of a heterogeneous chip - to - chip communication method in an embodiment of this application. The heterogeneous chips include a first chip and a second chip. The heterogeneous chip - to - chip communication method is executed by the first chip, and the heterogeneous chip - to - chip communication method at least includes the following steps S110 to step S130:

[0060] Step S110, after the operating system of the first chip is started, initialize the DBus service.

[0061] For ease of distinction, the heterogeneous chips in the embodiments of this application are defined as "the first chip" and "the second chip". The first chip and the second chip can respectively refer to an SOC and an MCU. Of course, they can also refer to different models of SOCs or different models of MCUs, that is, as long as they are heterogeneous chips that rely on traditional physical serial ports for communication, they can be used as the "first chip" and "the second chip" of this application.

[0062] The heterogeneous chip - to - chip communication method of the embodiments of this application can be executed by one of the chips. Here, the first chip is taken as an example for illustration. When communicating between heterogeneous chips, it is necessary to first start the operating system of the first chip. After the system starts up, it is necessary to initialize the DBus service. DBus is a message bus system that allows applications to send, receive, and listen for messages. In the Linux system, DBus usually runs as a system service. The process of initializing the DBus service may involve operations such as loading the DBus daemon process and configuring the DBus bus (such as the system bus or the session bus). During the initialization process, it is also necessary to allocate necessary system resources (such as memory, CPU time, etc.) for the DBus service and perform corresponding configuration settings to ensure that the DBus service can efficiently handle message - passing tasks.

[0063] Step S120, perform a handshake with the second chip and determine the version of the data transfer protocol between the first chip and the second chip. The data transfer protocol is a data transfer protocol in a preset general format.

[0064] Handshaking is a process in which both communicating parties establish a connection and confirm each other's identities. Between the first chip and the second chip, handshaking involves sending and receiving specific handshaking signals or messages to confirm that both parties are ready for communication.

[0065] During the handshaking process, the first chip and the second chip also need to negotiate a version of the data transfer protocol that they both support. Here, the data transfer protocol is a general and standard - format data transfer protocol defined in the embodiments of this application for data transfer between heterogeneous chips. The purpose is to eliminate communication barriers caused by different private protocols between heterogeneous chips, improve the compatibility of the system, and reduce the development and maintenance costs due to protocol mismatches.

[0066] Since the defined general - format data transfer protocol may also be continuously iterated and updated with the change of requirements, there will be multiple versions of the general - format data transfer protocol. The embodiments of this application support the co - existence of new and old versions. In the handshaking stage, the first chip and the second chip can automatically negotiate the protocol version, further improving the communication flexibility.

[0067] Step S130: Based on the initialized DBus service and the data transfer protocol version between the first chip and the second chip, perform data transfer between the first chip and the second chip.

[0068] After determining the data transfer protocol version, data can be sent and received through the initialized DBus service. The DBus service provides a message - passing mechanism that allows the first chip to encapsulate data packets into messages and send them to the second chip, and receive messages from the second chip and parse out the data packets.

[0069] During the data transfer process, both the first chip and the second chip need to strictly follow the negotiated data transfer protocol, which includes the data format, encoding method, checksum generation and verification, etc. At the same time, data packets need to be correctly encapsulated into message formats for transmission through the DBus service. Data transfer may involve the sending and receiving of multiple data packets or messages. After each data packet or message is sent, the first chip can wait for the confirmation message from the second chip to ensure that the data has been successfully received and processed. At the same time, the first chip also needs to handle possible transmission errors or data loss situations and take corresponding corrective measures.

[0070] The heterogeneous chip - to - chip communication method according to the embodiments of the present application realizes seamless communication between heterogeneous chips through the DBus service. It is applicable to different operating system platforms, without the need for a large number of modifications or adaptations to the communication mechanism, improving the generality and flexibility of heterogeneous chip communication. In addition, by defining a communication protocol with a unified format, the communication barriers caused by different private protocols between heterogeneous chips are eliminated, improving the system compatibility and reducing the development and maintenance costs due to protocol mismatch.

[0071] In some embodiments of the present application, after the operating system of the first chip is started, initializing the DBus service includes: after the operating system of the first chip is started, loading the service process through the Systemd service manager; in the case where the service process is loaded, initializing the DBus connection and registering the DBus service interface.

[0072] When the operating system (such as Linux) of the first chip starts up, the system begins to run various services and processes. During this process, a specific service process can be loaded through the Systemd service manager. Systemd is a system and service manager used by most modern Linux distributions, responsible for initializing the system, starting services, managing daemons, etc.

[0073] After the service process is loaded, initialize the DBus connection and register the system - level DBus service com.autodrive.mcu. Initializing the DBus connection means setting up and starting the DBus session or system bus, depending on whether the service is a user - facing session or a system - level service. After the DBus connection is initialized, the DBus service interface needs to be registered. The DBus service interface defines the operations that the service can perform and the data types it provides. By registering the interface, other applications or services can call these operations through DBus to achieve cross - application communication.

[0074] Through Systemd service management, the automatic start and stop of the communication module can be achieved without manual intervention. Systemd also provides a powerful status monitoring function. Administrators can monitor the running status of services in real - time, view logs, diagnose problems, etc., greatly improving the maintainability and stability of the system. In addition, Systemd can also manage the dependency relationships of services to ensure that services start and stop in the correct order, which is particularly important for complex systems because it can avoid conflicts and deadlocks between services.

[0075] In some embodiments of the present application, the DBus service interface includes at least one of a configuration management interface, a data read / write interface, and a subscription interface; the configuration management interface includes at least one of a network parameter configuration interface and a hardware information reading interface. The network parameter configuration interface is used to configure the network transmission parameters between the first chip and the second chip, and the hardware information reading interface is used to read the hardware information of the second chip; the data read / write interface includes at least one of a data writing interface and a data reading interface. The data writing interface is used to write data to the second chip, and the data reading interface is used to read sensor data; the subscription interface includes at least one of an event subscription interface and an unsubscribe interface. The event subscription interface is used to subscribe to asynchronous events of the second chip, and the unsubscribe interface is used to cancel the subscription of asynchronous events.

[0076] The DBus service interface in the embodiments of the present application is designed to include multiple functions to meet the communication requirements between different application programs, such as including but not limited to a configuration management interface, a data read / write interface, and a subscription interface.

[0077] (1) Configuration management interface: mainly used to provide methods for network parameter configuration and hardware information configuration. By calling the configuration management interface of the DBus service, the corresponding configuration can be achieved. The configuration management interface specifically implemented in the embodiments of the present application can include, for example:

[0078] 1) Network parameter configuration interface such as SetBaudRate(rate:uint32)→bool for baud rate configuration: used to dynamically modify the baud rate (supporting 115200bps to 3Mbps);

[0079] 2) Hardware information reading interface GetDeviceInfo()→dict: used to read metadata such as the MCU hardware version and firmware signature.

[0080] (2) Data read / write interface: mainly used to provide methods for data writing and reading. By calling the data read / write interface of the DBus service, the corresponding data writing or reading function can be achieved. The data read / write interface specifically implemented in the embodiments of the present application can include, for example:

[0081] 1) Data writing interface WriteRegister(addr:uint16,value:bytes)→bool: write raw data to the MCU register;

[0082] 2) Data reading interface ReadSensor(sensor_id:uint8)→dict: read sensor data (automatically converted to JSON).

[0083] (3) Subscription Interface: mainly used to provide methods for subscribing to and canceling events. By calling the subscription interface of the DBus service, the corresponding event subscription or cancellation function can be realized. For example, the subscription interfaces specifically implemented in the embodiments of this application may include:

[0084] 1) Event Subscription Interface Subscribe(signal: string): Subscribe to MCU asynchronous events (such as EmergencyAlert);

[0085] 2) Unsubscribe Interface Unsubscribe(signal: string): Cancel event subscription.

[0086] Of course, the above interfaces are only some of the DBus service interfaces listed in the embodiments of this application. Specifically, which functional interfaces are implemented can be flexibly set by those skilled in the art according to actual needs, and no specific limitation is made here.

[0087] By providing a variety of DBus service interfaces, it facilitates communication and transmission between heterogeneous chips, increases the flexibility and scalability of the system, and enables it to adapt to changing requirements and environments. The network parameter configuration interface allows for precise and dynamic configuration of communication parameters, thereby optimizing the efficiency and reliability of data transmission. Through the DBus service interface, the status and behavior of the system can be easily monitored and managed, which helps to simplify system management and maintenance work and reduce operating costs.

[0088] In some embodiments of this application, the method for communicating between heterogeneous chips further includes: defining a general format for the data transmission protocol; wherein, the general format includes a start field, a middle field, and a check field, and the middle field includes protocol version information, instruction type, and payload data, and the instruction type includes at least one of a configuration parameter instruction, a data read instruction, and a data write instruction.

[0089] The embodiments of this application define a general format for the data transmission protocol for communication and transmission between heterogeneous chips, and this general format is designed to include a start field, a middle field, and a check field.

[0090] The start field is used to identify the start of the data packet and can be a fixed byte sequence or a specific identifier, which is used to distinguish the data packet from other data at the receiving end.

[0091] The middle field is the core part of the data packet, containing protocol version information, instruction type, and payload data. The protocol version information indicates the version of the data transmission protocol used by the current data packet, which is crucial for ensuring that the sender and receiver can correctly parse the data packet. The instruction type indicates the type of instruction carried by the data packet. In the embodiments of the present application, the instruction type can include, for example, configuration parameter instructions, data read instructions, and data write instructions, etc. These instructions are used to configure chip parameters, read chip data, and write data to the chip respectively. According to the instruction type, the payload data can include specific configuration parameters, the address or identifier of the data to be read, the data to be written, etc.

[0092] The check field is used to verify the integrity and correctness of the data packet. It is usually generated by calculating the checksum or hash value of a certain part of the data packet (such as the middle field). At the receiving end, by recalculating the check value and comparing it with the received check field, it can be detected whether an error has occurred during the transmission of the data packet.

[0093] For the convenience of understanding the above embodiments, the protocol frame format of the general format data transmission protocol designed in the embodiments of the present application can be expressed in the following form:

[0094]

[0095] Of course, it should be noted that the above content is only an example structure of the general format data transmission protocol designed in the embodiments of the present application. Specifically, which fields are included and the configuration of the field information can be flexibly adjusted by those skilled in the art according to actual needs, and no specific limitation is made here.

[0096] By defining the general format of the data transmission protocol, the integrity, correctness, and efficiency of the data during transmission can be ensured. The introduction of the protocol version information enables the system to support different versions of the data transmission protocol. When it is necessary to update or expand the protocol, only the protocol version information needs to be modified, and the compatibility between the old and new versions is ensured, which helps to reduce the maintenance cost brought by protocol updates. The introduction of the instruction type enables the data transmission protocol to be compatible with different instruction types at the same time. Combining JSON and the DBus protocol greatly improves the data parsing efficiency compared with the traditional UART frame format.

[0097] In some embodiments of the present application, the heterogeneous chip - to - chip communication method further includes: creating a communication service program configuration file for the DBus service; wherein, the communication service program configuration file is used to configure at least one of the status monitoring information, resource limit information, and log management information of the communication service program. The status monitoring information of the communication service program is used to monitor the status of the communication service program through a heartbeat mechanism. The resource limit information is used to control the resource occupancy of the communication service program. The log management information is used to store the running logs of the communication service program.

[0098] The embodiments of the present application also create a communication service program configuration file for the communication service program of the DBus service. It is used to configure and manage the communication service program of the DBus service, including multiple key parts, to ensure the stable operation and efficient management of the communication service program.

[0099] 1) Status monitoring information:

[0100] The status monitoring information monitors the status of the communication service program through a heartbeat mechanism. The heartbeat mechanism is a commonly used status monitoring means. It regularly sends heartbeat signals (or called heartbeat packets) to confirm whether the communication service program is running normally. If the heartbeat signal is not received within a certain period of time, it may indicate that the communication service program has an anomaly or failure.

[0101] In the configuration file, parameters such as the sending interval of the heartbeat signal, the receiving timeout time, etc., and the handling measures after the loss of the heartbeat signal (such as restarting the communication service program, sending alarm information, etc.) can be flexibly set according to actual needs. For example, it can be configured that the communication service program needs to send a heartbeat signal every 25 seconds, and when it times out, it triggers a restart.

[0102] 2) Resource limit information:

[0103] The resource limit information is used to control the resource occupancy of the communication service program, which includes key resources such as CPU usage rate and memory occupancy. By configuring these limit information, it can prevent the communication service program from causing system crashes or performance degradation due to resource exhaustion.

[0104] In the configuration file, parameters such as the maximum CPU usage rate and the upper limit of memory occupancy of each communication service program can be specified, and the handling measures when the resource occupancy exceeds the limit (such as restricting resource usage, terminating the process, etc.) can be set. For example, it can be configured that when the CPU occupancy rate > 80%, it triggers a fuse, and the memory can be limited to 512MB.

[0105] 3) Log management information:

[0106] The log management information is used to store and manage the running logs of the communication service program. By integrating syslog, the log information of the communication service program is stored in slices according to levels. The running logs are an important tool for recording key information such as the running status, exception information, and user operations of the communication service program. Through the log management information, the running situation of the communication service program can be conveniently viewed and analyzed, and problems can be discovered and solved in a timely manner.

[0107] In the configuration file, the storage path of the log file, the file name format, and the log level (such as debug, info, warning, error) can be specified.

[0108] Through the configuration of the status monitoring information, the status of the communication service program can be monitored in real time, and abnormal situations can be discovered and processed in a timely manner, thereby improving the stability and reliability of the communication service program. Through the configuration of the resource limit information, the resource occupancy of the communication service program can be controlled, preventing the system from crashing or the performance from degrading due to resource exhaustion, which helps to optimize the use of system resources and improve the overall performance of the system. Through the configuration of the log management information, the running situation of the communication service program can be conveniently viewed and analyzed, problems can be discovered and solved in a timely manner, which helps to shorten the fault recovery time and improve the availability and maintenance efficiency of the system.

[0109] The design of the configuration file enables the system to be flexibly configured and adjusted according to actual needs. When it is necessary to modify the configuration of the existing communication service program, only the configuration file needs to be modified, without the need to make large-scale modifications or reconstructions to the system, which enhances the configurability and scalability of the system and reduces the system maintenance cost.

[0110] In some embodiments of the present application, the data transmission between the first chip and the second chip based on the initialized DBus service and the data transmission protocol version between the first chip and the second chip includes: receiving a DBus service call request from a user; encapsulating a first data frame according to the DBus service call request and the data transmission protocol version; adding the first data frame to a data sending queue, and asynchronously sending the first data frame to the second chip through the data sending queue.

[0111] As Figure 2 shown, a schematic diagram of a data sending process based on the DBus service in an embodiment of the present application is provided. In the data sending process of the first chip, the user can first call the method of the DBus service. In this link, the user only needs to call the DBus command and pass parameters for the DBus command. The parameters can include, for example, the session Bus, the system Bus, printing the return message, the Bus name, the target object path, the calling method, and the parameters passed to the method.

[0112] Then, it is necessary to perform a legality check on the transmitted parameters. For example, it can include checking the parameter type, range, whether it is required, etc., to ensure the reliability and legality of the data. After the parameters pass the legality check, the parameters are serialized into JSON data and compressed. The JSON format is easy to read and parse, while compression can reduce the data size and improve the transmission efficiency. Then, according to the version of the data transmission protocol in the common format negotiated by both parties, the compressed data is encapsulated into a data frame, which includes further operations such as adding a frame header and a CRC check field, etc., to respectively identify the start and end of the frame and ensure the integrity of the data.

[0113] The above - encapsulated protocol frame is added to the data sending queue and sorted according to the priority. The system can reasonably arrange the data sending order according to the priority level to ensure that high - priority data can be transmitted first. During the data transmission process, the first chip will wait for the confirmation frame from the second chip. This confirmation frame is sent back by the second chip after successfully receiving the data to confirm the integrity and correctness of the data. If the first chip does not receive the confirmation frame within a certain time, it will try to resend the data, and the maximum number of retries can be set here. The retry mechanism can ensure that there is a chance to re - establish the connection and successfully transmit the data in case of communication failure.

[0114] By using DBus for communication, fast data transmission and efficient processing between heterogeneous chips can be achieved. At the same time, data serialization and compression processing reduce the amount of data transmitted, further improving the communication efficiency. By encapsulating the protocol frame according to the data transmission protocol in the common format, the integrity and correctness of the data can be ensured, and the efficiency of the second chip for parsing the data frame in the future can also be improved. By adding the data frame to the data sending queue and setting the priority sorting of data sending, different priority data transmission requirements can be flexibly processed, improving the flexibility and response speed of the system.

[0115] In some embodiments of the present application, the data transmission between the first chip and the second chip based on the initialized DBus service and the data transmission protocol version between the first chip and the second chip includes: receiving a second data frame sent by the second chip; parsing the second data frame to obtain the parsing result of the second data frame, where the parsing result includes the instruction type; generating a corresponding response frame according to the instruction type and returning it to the second chip.

[0116] Such as Figure 3As shown in the figure, a schematic diagram of the data reception process based on the DBus service in the embodiments of the present application is provided. In the data reception process of the first chip, it is necessary to first perform a UART interruption. The UART (Universal Asynchronous Receiver-Transmitter) interruption is a common way to trigger data reception. When the second chip sends a data frame, the UART interface of the first chip will detect this data frame and generate an interruption signal to notify the CPU to receive data. Triggered by the UART interruption, the first chip starts to receive the data frame sent by the second chip.

[0117] To ensure the integrity and continuity of the data, the first chip will write the received data frame (or part of the data therein) into a circular buffer. This buffer can temporarily store the data until it is completely processed or forwarded.

[0118] Before processing the data frame, the first chip needs to search for and find a specific frame header flag (such as 0xAA). This frame header flag is used to identify the start and end of the data frame to ensure the correct parsing and processing of the data. To ensure the integrity of the data, the first chip will also verify whether the message length of the data frame matches the expected length. If the lengths do not match, it may indicate that an error or loss occurred during data transmission.

[0119] If the verification passes, the first chip will decompress the payload of the data frame and parse its content. The result of the parsing is a data in JSON format, which contains information such as the instruction type sent by the second chip. After that, the first chip will trigger a DBus signal broadcast and send the parsed JSON format data (or the key information therein) to the server or other components that need this data. If the parsed data frame is a control instruction (such as setting parameters, starting / stopping a certain operation, etc.), the first chip will perform corresponding operations according to the instruction type.

[0120] After successfully parsing and processing the data frame, the first chip will generate a corresponding response frame according to the instruction type and return it to the second chip. This response frame can contain processing results, status information, etc.

[0121] Through the above data reception process, the first chip can efficiently receive and process the data frames sent by the second chip, improving the data transmission efficiency and response speed of the system. By generating corresponding response frames according to the instruction type, the first chip can flexibly process various control instructions, improving the flexibility and scalability of the system.

[0122] In the embodiments of the present application, a heterogeneous chip communication device 400 is also provided, as Figure 4As shown, a schematic structural diagram of an inter - heterogeneous - chip communication device in an embodiment of the present application is provided. The heterogeneous chips include a first chip and a second chip. The inter - heterogeneous - chip communication device is applied to the first chip. The inter - heterogeneous - chip communication device 400 includes: an initialization unit 410, a determination unit 420, and a transmission unit 430, where:

[0123] The initialization unit 410 is configured to initialize the DBus service after the operating system of the first chip is started.

[0124] The determination unit 420 is configured to perform a handshake with the second chip and determine the version of the data transmission protocol between the first chip and the second chip. The data transmission protocol is a data transmission protocol in a preset general format.

[0125] The transmission unit 430 is configured to perform data transmission between the first chip and the second chip based on the initialized DBus service and the version of the data transmission protocol between the first chip and the second chip.

[0126] In some embodiments of the present application, the initialization unit 410 is specifically configured to: after the operating system of the first chip is started, load a service process through the Systemd service manager; and after loading the service process, initialize a DBus connection and register a DBus service interface.

[0127] In some embodiments of the present application, the DBus service interface includes at least one of a configuration management interface, a data read - write interface, and a subscription interface; the configuration management interface includes at least one of a network parameter configuration interface and a hardware information reading interface. The network parameter configuration interface is used to configure network transmission parameters between the first chip and the second chip, and the hardware information reading interface is used to read the hardware information of the second chip; the data read - write interface includes at least one of a data writing interface and a data reading interface. The data writing interface is used to write data to the second chip, and the data reading interface is used to read sensor data; the subscription interface includes at least one of an event subscription interface and an unsubscribe interface. The event subscription interface is used to subscribe to asynchronous events of the second chip, and the unsubscribe interface is used to cancel the subscription of asynchronous events.

[0128] In some embodiments of the present application, the inter - heterogeneous - chip communication device 400 further includes: a definition unit, configured to define a general format of the data transmission protocol; where the general format includes a start field, a middle field, and a check field. The middle field includes protocol version information, an instruction type, and payload data. The instruction type includes at least one of a configuration parameter instruction, a data reading instruction, and a data writing instruction.

[0129] In some embodiments of the present application, the heterogeneous chip - to - chip communication device 400 further includes: a creation unit configured to create a communication service program configuration file for the DBus service; wherein, the communication service program configuration file is used to configure at least one of status monitoring information, resource limit information, and log management information of the communication service program. The status monitoring information of the communication service program is used to monitor the status of the communication service program through a heartbeat mechanism, the resource limit information is used to control the resource occupancy of the communication service program, and the log management information is used to store the running logs of the communication service program.

[0130] In some embodiments of the present application, the transmission unit 430 is specifically configured to: receive a DBus service call request from a user; encapsulate a first data frame according to the DBus service call request and the data transmission protocol version; add the first data frame to a data sending queue, and asynchronously send the first data frame to the second chip through the data sending queue.

[0131] In some embodiments of the present application, the transmission unit 430 is specifically configured to: receive a second data frame sent by the second chip; parse the second data frame to obtain a parsing result of the second data frame, where the parsing result includes an instruction type; generate a corresponding response frame according to the instruction type and return it to the second chip.

[0132] It can be understood that the above - mentioned heterogeneous chip - to - chip communication device can implement each step of the heterogeneous chip - to - chip communication method provided in the foregoing embodiments. The relevant explanations regarding the heterogeneous chip - to - chip communication method are applicable to the heterogeneous chip - to - chip communication device, and will not be elaborated herein.

[0133] The embodiments of the present application further provide a heterogeneous chip - to - chip communication system, which includes: a first chip and a second chip. A DBus service is deployed on the first chip, and data is transmitted between the first chip and the second chip through the DBus service. The first chip is configured to execute the heterogeneous chip - to - chip communication method described in any one of the foregoing items.

[0134] As Figure 5 shown, a schematic structural diagram of a heterogeneous chip - to - chip communication system in an embodiment of the present application is provided. The heterogeneous chip - to - chip communication system in the embodiment of the present application can include the following several levels according to function implementation:

[0135] (1) Hardware layer

[0136] SOC side: Chipset, integrating a UART controller and a level conversion circuit;

[0137] MCU side: Chipset, connecting vehicle actuators (motor, steering module) and sensors (radar, camera);

[0138] Physical link: RS-485 serial bus with electrical isolation (anti-interference voltage > 1500V).

[0139] (2) Driver layer

[0140] SOC side: Linux UART driver (kernel module), supporting DMA transfer;

[0141] MCU side: Bare-metal interrupt driver, implementing zero-copy circular buffer.

[0142] (3) Middleware layer

[0143] DBus service bus:

[0144] Service interface: com.autodrive.mcu, including methods such as configuration management, data reading and writing, and event subscription;

[0145] Protocol engine: Implementing payload compression (zlib), priority scheduling, and dynamic baud rate switching functions.

[0146] (4) Application layer

[0147] SOC side: Autopilot perception algorithm, diagnostic monitoring tool;

[0148] MCU side: Real-time control tasks (period ≤ 10ms), sensor algorithm programs, etc.

[0149] Based on the above, the key points and technical effects of this application mainly include:

[0150] 1) Protocol standardization: Defining a unified JSON-RPC 2.0 communication protocol, eliminating private protocol barriers. Combining JSON and DBus protocols, compared with traditional UART frame formats, greatly improves data parsing efficiency; supporting the hot update mechanism, and new communication protocol versions can be dynamically loaded without restarting the system;

[0151] 2) Hardware-independent design: Encapsulating the underlying UART driver and providing a plug-and-play DBus service interface to the upper layer; uniformly encapsulating hardware register operations through ioctl. When replacing the MCU chip (such as upgrading from TC397 to S32G), only the driver configuration file needs to be modified, with strong scalability and no need for secondary development; supporting dynamic binding of multiple serial ports (UART0 - UART3), and the single-channel bandwidth reaches 2Mbps;

[0152] 3) User-friendliness: Invoking communication services through standardized D-Bus interfaces without the need to pay attention to the details of the underlying protocol;

[0153] 4) Cross-platform support: Seamless communication between Ubuntu and RTOS is achieved through the DBus bus;

[0154] 5) Enhanced security: Integrate permission control and data verification mechanisms to ensure the reliability of critical instruction transmission;

[0155] 6) Resource efficiency: Reduce CPU polling overhead and adopt an event-driven mechanism to improve real-time performance;

[0156] 7) System maintainability: Automatically start, stop, and monitor the status of the communication module through Systemd service management;

[0157] 8) Improved development efficiency: Provide the mcu_shell debugging tool and use Systemd system service management to support the direct sending instruction verification function of Dbus send.

[0158] 9) Support for intelligent protocol adaptation: Support the coexistence of old and new versions of MCU firmware, and automatically negotiate the protocol version during the handshake phase; The frame parsing rules (described by JSON Schema) can be dynamically loaded through the ProtocolAdapter module.

[0159] 10) Self-healing communication link: Periodically send heartbeat frames (1Hz) to detect the link status. After disconnection, automatically degrade to the low-speed mode (115200bps) and attempt to reconnect. Seamlessly switch back to the high-speed mode after recovery.

[0160] Figure 6 It is a schematic structural diagram of a device in an embodiment of the present application. As Figure 6 shown, the device includes one or more processors (or processing units), and may also include one or more memories coupled to the processors, and may also include a communication module coupled to the processors.

[0161] The communication module can be used to communicate with other devices or apparatuses, such as sending or receiving data and / or signals. The communication module can have at least one communication module for communication. The communication module can include any interface necessary for communicating with other devices. Exemplarily, the communication module can be a transceiver, a circuit, a bus, a module, or other types of communication modules.

[0162] The processor can include, but is not limited to, at least one of the following: a general-purpose computer, a dedicated computer, a microcontroller, a digital signal controller (Digital Signal Processor, DSP), or one or more in a multi-core controller architecture based on a controller. The device can have multiple processors, such as an application-specific integrated circuit chip, which is subordinate to a clock synchronized with the main processor in time.

[0163] The memory may include one or more non-volatile memories and one or more volatile memories. Examples of non-volatile memories include, but are not limited to, at least one of the following: Read-Only-Memory (ROM), Electrically Programmable Read-Only-Memory (EPROM), flash memory, hard disk, Compact Disc (CD), Digital Video Disk (DVD), or other magnetic storage and / or optical storage. Examples of volatile memories include, but are not limited to, at least one of the following: Random Access Memory (RAM), or other volatile memories that do not persist during a power-off duration.

[0164] The computer program includes computer-executable instructions executed by an associated processor. The program may be stored in the ROM. The processor may execute any suitable actions and processes by loading the program into the RAM.

[0165] Possible implementations of the present application may be implemented by means of a program such that the communication device can execute any process discussed in the foregoing embodiments. Possible implementations of the present application may also be implemented by hardware or by a combination of software and hardware.

[0166] In some embodiments, the program may be tangibly embodied in a computer-readable storage medium, which may be included in the device (such as in the memory) or other storage devices accessible by the device. The program may be loaded from the computer-readable storage medium into the RAM for execution. The computer-readable storage medium may include any type of tangible non-volatile memory, such as ROM, EPROM, flash memory, hard disk, CD, DVD, etc.

[0167] The embodiments of the present application also provide a computer-readable storage medium, on which computer instructions or program codes are stored. When the processor runs the instructions or the program codes, the processor is caused to execute the methods and functions involved in any of the above embodiments. The computer-readable medium can be any tangible medium that contains or stores a program for or related to an instruction execution system, apparatus, or device. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. The computer-readable medium can include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any suitable combination thereof. The computer-readable storage medium can be any available medium that the computer can access or a data storage device such as a server or a data center that incorporates one or more available media. More detailed examples of the computer-readable storage medium include electrical connections with one or more wires, magnetic media (such as disks, floppy disks, hard disks, magnetic tapes, magnetic storage devices), optical media (such as optical storage devices, DVDs), semiconductor media (such as solid-state drives), random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), or any suitable combination thereof, etc.

[0168] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The embodiments of the present application also provide at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product includes one or more computer-executable instructions, such as instructions included in program modules, which are executed in a device on a target real or virtual processor to execute the processes, methods, and functions involved in any of the above embodiments. When the computer program instructions are loaded and executed on a computer, the processes or functions according to the embodiments of the present application are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by wire (such as coaxial cable, fiber optic, digital subscriber line) or wirelessly (such as infrared, wireless, microwave, etc.).

[0169] Embodiments of the present application also propose a computer program product, including a computer program or instructions. When the computer program or instructions run on a computer, the computer is enabled to execute the processes, methods, and functions in the above embodiments. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that execute specific tasks or implement specific abstract data types. In various embodiments, the functions of program modules can be combined or divided as needed. Machine-executable instructions for program modules can be executed within local or distributed devices. In a distributed device, program modules can be located in local and remote storage media.

[0170] Generally, various embodiments of the present application can be implemented in hardware or dedicated circuits, software, logic, or any combination thereof. Some aspects can be implemented in hardware, while other aspects can be implemented in firmware or software, which can be executed by a controller, a microprocessor, or other computing devices. Although various aspects of the embodiments of the present disclosure are shown and described as block diagrams, flowcharts, or using some other graphical representation, it should be understood that the blocks, devices, systems, technologies, or methods described herein can be implemented as, by way of non-limiting example, hardware, software, firmware, dedicated circuits or logic, general-purpose hardware or a controller or other computing devices, or some combination thereof.

[0171] It should be noted that although the embodiments of the present application are described above in conjunction with the accompanying drawings respectively, the above embodiments are not independent of each other, and they can also be combined to obtain other embodiments. The manners, situations, categories, and divisions of the embodiments in the present application are only for the convenience of description and should not constitute a special limitation. The features in various manners, categories, situations, and embodiments can be combined with each other under logical circumstances. The various embodiments of the present application can be combined arbitrarily to achieve different technical effects. The embodiments of the present application will no longer list various combinations.

[0172] In addition, although the operations of the methods of the present disclosure are described in a specific order in the drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. On the contrary, the steps depicted in the flowchart can change the execution order. Additionally or alternatively, some steps can be omitted, multiple steps can be combined into one step for execution, and / or one step can be decomposed into multiple steps for execution. It should also be noted that the features and functions of two or more devices according to the present disclosure can be embodied in one device. Conversely, the features and functions of one device described above can be further divided and embodied by multiple devices.

[0173] It should also be noted that the term "including", "comprising" or any other variant thereof is intended to cover non-exclusive inclusion, such that a process, method, article or apparatus including a series of elements not only includes those elements but also includes other elements not expressly listed, or further includes elements inherent to such process, method, article or apparatus. Without further limitation, an element defined by the phrase "including an..." does not exclude the presence of additional identical elements in the process, method, article or apparatus including said element.

[0174] The above are only embodiments of the present application and are not intended to limit the present application. For those skilled in the art, various modifications and changes can be made to the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included within the scope of the claims of the present application.

Claims

1. A method for inter - heterogeneous chip communication, characterized in that, The heterogeneous chip includes a first chip and a second chip. The method for inter-chip communication of the heterogeneous chip is executed by the first chip, and the method for inter-chip communication of the heterogeneous chip includes: After the operating system of the first chip is started, initialize the DBus service; Perform a handshake with the second chip and determine the version of the data transmission protocol between the first chip and the second chip. The data transmission protocol is a data transmission protocol in a preset general format; Based on the initialized DBus service and the version of the data transmission protocol between the first chip and the second chip, perform data transmission between the first chip and the second chip.

2. The heterogeneous chip - to - chip communication method according to claim 1, wherein, The step of initializing the DBus service after the operating system of the first chip is started includes: After the operating system of the first chip is started, load the service process through the Systemd service manager; After loading the service process, initialize the DBus connection and register the DBus service interface.

3. The heterogeneous chip - to - chip communication method according to claim 2, wherein, The DBus service interface includes at least one of a configuration management interface, a data read / write interface, and a subscription interface; The configuration management interface includes at least one of a network parameter configuration interface and a hardware information reading interface. The network parameter configuration interface is used to configure the network transmission parameters between the first chip and the second chip, and the hardware information reading interface is used to read the hardware information of the second chip; The data read / write interface includes at least one of a data writing interface and a data reading interface. The data writing interface is used to write data to the second chip, and the data reading interface is used to read sensor data; The subscription interface includes at least one of an event subscription interface and an unsubscribe interface. The event subscription interface is used to subscribe to asynchronous events of the second chip, and the unsubscribe interface is used to cancel the subscription of asynchronous events.

4. The heterogeneous chip - to - chip communication method according to claim 1, wherein The method for inter-chip communication of the heterogeneous chip further includes: Define the general format of the data transmission protocol; Wherein, the general format includes a start field, a middle field, and a check field. The middle field includes protocol version information, instruction type, and payload data. The instruction type includes at least one of a configuration parameter instruction, a data reading instruction, and a data writing instruction.

5. The heterogeneous chip - to - chip communication method according to claim 1, wherein, The method for inter-chip communication of the heterogeneous chip further includes: Create a communication service program configuration file for the DBus service; Wherein, the communication service program configuration file is used to configure at least one of the status monitoring information, resource limit information, and log management information of the communication service program. The status monitoring information of the communication service program is used to monitor the status of the communication service program through a heartbeat mechanism. The resource limit information is used to control the resource occupancy of the communication service program. The log management information is used to store the running logs of the communication service program.

6. The heterogeneous chip - to - chip communication method according to claim 1, wherein, The step of performing data transmission between the first chip and the second chip based on the initialized DBus service and the version of the data transmission protocol between the first chip and the second chip includes: Receive a DBus service call request from the user; Encapsulate a first data frame according to the DBus service call request and the data transmission protocol version; Add the first data frame to the data sending queue, and asynchronously send the first data frame to the second chip through the data sending queue.

7. The heterogeneous chip - to - chip communication method according to claim 1, wherein The data transmission between the first chip and the second chip based on the initialized DBus service and the data transmission protocol version between the first chip and the second chip includes: Receive a second data frame sent by the second chip; Parse the second data frame to obtain the parsing result of the second data frame, where the parsing result includes the instruction type; Generate a corresponding response frame according to the instruction type and return it to the second chip.

8. An inter - heterogeneous - chip communication device, characterized in that, The heterogeneous chip includes a first chip and a second chip. The inter-heterogeneous-chip communication device is applied to the first chip, and the inter-heterogeneous-chip communication device includes: An initialization unit, configured to initialize the DBus service after the operating system of the first chip is started; A determination unit, configured to perform a handshake with the second chip and determine the version of the data transmission protocol between the first chip and the second chip, where the data transmission protocol is a data transmission protocol in a preset general format; A transmission unit, configured to perform data transmission between the first chip and the second chip based on the initialized DBus service and the data transmission protocol version between the first chip and the second chip.

9. A heterogeneous chip - to - chip communication system, characterized in that, The inter-heterogeneous-chip communication system includes: a first chip and a second chip. The DBus service is deployed on the first chip. Data is transmitted between the first chip and the second chip through the DBus service. The first chip is configured to execute the inter-heterogeneous-chip communication method according to any one of claims 1 to 7.

10. An apparatus, comprising: A processor; And a memory arranged to store computer-executable instructions, where the executable instructions, when executed, cause the processor to execute the inter-heterogeneous-chip communication method according to any one of claims 1 to 7.

11. A computer program product, comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, the inter-heterogeneous-chip communication method according to any one of claims 1 to 7 is implemented.

Images