Inter-core communication method and device, medium, electronic equipment and multi-core system

Abstract

The invention discloses an inter-core communication method and device, a medium, electronic equipment and a multi-core system. The method comprises the following steps: selecting a first target application from local applications; selecting first data id from a plurality of preset data id according to the first target application, and selecting a target second CPU core from one or more preset second CPU cores according to the first target application; generating first byte stream data according to the first data id, and sending the first byte stream data to a target second CPU core, so that the target second CPU core generates second data id and feedback data based on the first byte stream data; and receiving second data id fed back by the target second CPU core, receiving feedback data fed back by the target second CPU core according to the second data id, and controlling the first target application to run based on the feedback data. According to the method, convenient inter-core communication can be realized.

Description

Technical Field

[0001] The present invention relates to the field of inter-core communication technology, and in particular to an inter-core communication method, device and medium, electronic equipment, and multi-core system. Background Art

[0002] With the rapid development of intelligent technologies in new energy vehicles, the number of chips installed in vehicles is increasing. Different CPU (Central Processing Unit) cores may reside on the same chip or on different chips. These CPU cores may be heterogeneous or homogeneous, and the operating systems running on each CPU core may also differ. To efficiently meet diverse user needs and functions, a data transmission and communication mechanism is needed for inter-core communication between different CPU cores. Summary of the Invention

[0003] The present invention aims to solve one of the technical problems in the related art at least to a certain extent. To this end, a first object of the present invention is to propose an inter-core communication method to achieve convenient inter-core communication.

[0004] A second object of the present invention is to provide a computer-readable storage medium.

[0005] A third object of the present invention is to provide an electronic device.

[0006] A fourth objective of the present invention is to provide an inter-core communication device.

[0007] A fifth object of the present invention is to provide a multi-core system.

[0008] To achieve the above-mentioned purpose, an embodiment of the first aspect of the present invention proposes an inter-core communication method, which is used for a first CPU core, and the method includes: selecting a first target application from a local application; selecting a first data id from a plurality of preset data ids according to the first target application, and selecting a target second CPU core from one or more preset second CPU cores according to the first target application; generating first byte stream data according to the first data id, and sending the first byte stream data to the target second CPU core, so that the target second CPU core generates a second data id and feedback data based on the first byte stream data; receiving the second data id fed back by the target second CPU core, and receiving the feedback data fed back by the target second CPU core according to the second data id, and controlling the first target application to run based on the feedback data.

[0009] A second aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the above-mentioned inter-core communication method is implemented.

[0010] An embodiment of the third aspect of the present invention proposes an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the computer program is executed by the processor, the above-mentioned inter-core communication method is implemented.

[0011] The fourth object of the present invention is to propose an inter-core communication device, which includes: a selection module for selecting a first target application from a local application, and selecting a first data id from a plurality of preset data ids according to the first target application, and selecting a target second CPU core from one or more preset second CPU cores according to the first target application; a generation module for generating first byte stream data according to the first data id; a sending module for sending the first byte stream data to the target second CPU core, so that the target second CPU core generates a second data id and feedback data based on the first byte stream data; a receiving module for receiving the second data id fed back by the target second CPU core, and receiving feedback data fed back by the target second CPU core according to the second data id; and a control module for controlling the first target application to run based on the feedback data.

[0012] A fifth object of the present invention is to provide a multi-core system, wherein the system includes multiple CPU cores, and any one of the multiple CPU cores includes the above-mentioned electronic device.

[0013] According to the inter-core communication method, device and medium, electronic device, and multi-core system of the embodiments of the present invention, a first target application is selected from a local application; a first data id is selected from a plurality of preset data ids according to the first target application, and a target second CPU core is selected from one or more preset second CPU cores according to the first target application; first byte stream data is generated according to the first data id, and the first byte stream data is sent to the target second CPU core, so that the target second CPU core generates a second data id and feedback data based on the first byte stream data; a second data id fed back by the target second CPU core is received, and feedback data fed back by the target second CPU core is received according to the second data id, and the first target application is controlled to run based on the feedback data. Since the data id set for communication and the second CPU core for communication both correspond to local applications, after determining the first target application, the first data id and the target second CPU core of the application in actual communication can be determined according to the first target application, and communication is carried out with the target second CPU core through the first data id. Since the data id is used to communicate with the second CPU core, standardized processing of communication information between the first CPU core and the second CPU core can be achieved, thereby supporting the setting of a general API (Application Programming Interface) and providing upper-level users with a unified inter-core communication interface, namely a set of APIs and SDKs (Software Development Kits), which greatly facilitates the use of upper-level development users and realizes convenient inter-core communication.

[0014] Additional aspects and advantages of the present invention will be set forth in part in the description which follows and, in part, will be obvious from the description which follows, or may be learned through practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 is a flow chart of an inter-core communication method according to an embodiment of the present invention;

[0016] Figure 2 This is a schematic diagram of the inter-core communication system architecture according to one embodiment of the present invention;

[0017] Figure 3 is a schematic diagram of an inter-core communication system architecture of an example of the present invention;

[0018] Figure 4 is a schematic diagram of an inter-core communication system architecture according to another example of the present invention;

[0019] Figure 5 is a schematic diagram of an example inter-core communication method of the present invention;

[0020] Figure 6 is a structural block diagram of an electronic device according to an embodiment of the present invention;

[0021] Figure 7 is a structural block diagram of an inter-core communication device according to an embodiment of the present invention;

[0022] Figure 8 It is a structural block diagram of a multi-core system according to an embodiment of the present invention. DETAILED DESCRIPTION

[0023] In the automotive field, there are three mechanisms for implementing inter-core communication. These differ primarily in the underlying data transmission links. Some rely on the SPI (Serial Peripheral Interface) physical bus, others on the PCie (Peripheral Component Interconnect Express) bus, and some on shared memory.

[0024] Inter-core communication over the SPI physical bus uses SPI bus technology, a synchronous serial communication protocol primarily used for inter-chip communication. SPI bus communication requires at least two devices: a master and a slave. In a multi-core processor system, each core can function as either a master or a slave, enabling inter-core communication over the SPI bus.

[0025] PCIe-based inter-core communication uses the PCIe bus for data transmission. It is a high-speed serial bus primarily used to connect various devices within a computer, including hard drives, graphics cards, and network cards. In a multi-core processor, each core can serve as an endpoint on the PCIe bus, enabling inter-core communication.

[0026] Inter-core communication based on shared memory uses shared memory for data transfer. Shared memory is a memory sharing mechanism provided by the Linux operating system that allows different processes or threads to access the same memory block, thereby enabling data sharing and communication. In a multi-core processor system, each core can access shared memory, thus enabling inter-core communication through shared memory.

[0027] These three methods use different physical communication links: SPI, PCIe, and shared memory. Therefore, they require different hardware and driver support, as well as HAL (Hardware Abstraction Layer) encapsulation of the underlying communication links provided by BSP (Board Support Package) engineers to facilitate their use. Each method has its own advantages and disadvantages, and the most appropriate method should be selected based on the scenario. A summary and comparison are provided below.

[0028] Advantages of SPI:

[0029] Good real-time performance: SPI communication is implemented based on a hardware interface, offering high speed and suitable for communication scenarios with high real-time requirements. High security: SPI communication is implemented based on a hardware interface, offering high communication security and making it less susceptible to exploitation by malicious programs or attackers. Stable and reliable: SPI communication is implemented based on a hardware interface, offering high stability and reliability, making it less prone to deadlock and contention issues.

[0030] Disadvantages of SPI-based:

[0031] High hardware cost: SPI communication requires hardware interface support, resulting in high hardware costs and unsuitable for low-cost communication scenarios. Short transmission distance: SPI communication has a short transmission distance and is not suitable for long-distance communication scenarios. Complex interface: SPI communication interfaces are relatively complex and require a high level of technical expertise to develop and debug.

[0032] Advantages of PCIe:

[0033] Fast transmission speed: The PCIe bus has a high transmission bandwidth and is suitable for high-speed data transmission. High reliability: The PCIe bus is stable and reliable, and is not prone to problems such as deadlock and contention. Hot-swappable support: The PCIe bus supports hot-swappable, making it easy to add and replace hardware.

[0034] Disadvantages of PCIe-based:

[0035] High hardware cost: The PCIe bus requires specialized hardware support, resulting in high hardware costs and unsuitable for low-cost communication scenarios. Transmission distance limitation: The transmission distance of the PCIe bus is limited, making it unsuitable for long-distance communication scenarios. Complex interface: The PCIe bus interface is relatively complex, requiring a high level of technical expertise to develop and debug.

[0036] Advantages of shared memory:

[0037] Fast: Shared memory is shared between different processes within the same physical memory, resulting in fast access speeds and suitable for communication scenarios with large data volumes. Easy to use: Shared memory is simple to implement, and the communication interface is easy to write and debug. High reliability: Access to shared memory is managed by the operating system, ensuring data accuracy and synchronization.

[0038] Disadvantages of shared memory:

[0039] Poor real-time performance: Because shared memory access is managed by the operating system, real-time performance is poor and unsuitable for communication scenarios requiring high real-time performance. Prone to contention: Because multiple processes can access shared memory simultaneously, contention and deadlock are prone to occur, requiring appropriate synchronization and mutual exclusion. Poor security: Unrestricted access to shared memory makes it easy for malicious programs or attackers to exploit this to perform illegal operations.

[0040] The three physical communication links described above for inter-core communication each have their own advantages and applicable scenarios. Application developers can choose the communication method that best suits their needs and access the corresponding APIs and SDKs. However, to meet diverse user needs, application developers may need to use multiple inter-core communication methods simultaneously, or the underlying developers of inter-core communication functionality may need to provide different inter-core communication options for different application developers. Implementing and providing a separate set of APIs and SDKs for each communication method is inefficient and inconvenient. Furthermore, adding new inter-core communication mechanisms later requires implementing and maintaining a new set of APIs and SDKs, which limits maintainability and scalability.

[0041] Therefore, the present invention proposes an inter-core communication method, device and medium, electronic equipment, and multi-core system.

[0042] The following describes, with reference to the accompanying drawings, inter-core communication methods, devices, and media, electronic devices, and multi-core systems according to embodiments of the present invention. Throughout, identical or similar reference numerals represent identical or similar elements or elements having identical or similar functions. The embodiments described with reference to the accompanying drawings are illustrative only and are not to be construed as limiting the present invention.

[0043] Figure 1 This is a flow chart of an inter-core communication method according to an embodiment of the present invention.

[0044] In an embodiment of the present invention, an inter-core communication method is used for a first CPU core. The first CPU core can be any CPU core in a system with multiple CPU cores. The CPU cores in the system with multiple CPU cores may be heterogeneous or homogeneous, and the operating systems installed on the CPU cores may be different. The system with multiple CPU cores may include a single chip or multiple chips. Furthermore, at least one CPU core other than the first CPU core in the system with multiple CPU cores is set as a preset second CPU core.

[0045] like Figure 1 As shown, the inter-core communication method includes:

[0046] S11, selecting a first target application from local applications.

[0047] Specifically, a first CPU core is configured with multiple local applications. Different local applications may need to communicate with different CPU cores in order to run. To achieve communication with different CPU cores, the first CPU core needs to pre-determine a second CPU core with which it can communicate. For each application, the first CPU core determines the second CPU core with which the application needs to communicate in order to run. The first CPU core then enters into an agreement with the second CPU core to determine the data IDs used when the first and second CPU cores communicate when running the application. This agreement ensures that the data IDs sent between the two CPU cores match.

[0048] The above data id corresponds to the local application. Different local applications use different data ids to communicate with the corresponding second CPU core. A local application can correspond to one data id or multiple data ids.

[0049] Because the data ID is pre-agreed, the first CPU core can use it to inform the target second CPU core of the local application it is currently running. This allows the target second CPU core to determine the functions to be implemented based on the application being run and provide feedback data, thereby ensuring the stability and accuracy of communication. Furthermore, by agreeing on the data ID, the target second CPU core can first send the data ID when sending feedback data to the first CPU core, allowing the first CPU core to determine the sender of the received data based on the data ID, thus ensuring the security of the received data.

[0050] The above data ID is explained below with reference to a specific example.

[0051] In this example, the data id consists of three parts, which are respectively recorded as Priority, GroupId, and ElementId. The size of Priority is 4 bits, the size of GroupId is 12 bits, and the size of ElementId is 16 bits. In this case, the data id is a uint32 integer.

[0052] Priority is the first 4 bits of the data ID, GroupId is the middle 12 bits of the data ID, and ElementId is the last 16 bits of the data ID. Assuming a data ID is 0x30010001, the data ID's Priority is 3, GroupId is 1, and ElementId is 1.

[0053] The first 4 bits of the data ID are used as the priority to identify the data priority.

[0054] The middle 12 bits are used as GroupId to distinguish the data IDs of different applications. Different applications use different GroupIds for differentiation. That is to say, in this example, the above data ID corresponds to the local application, which means that the local application corresponds one-to-one with the GroupId in the data ID.

[0055] The last 16 bits serve as the unique ID for the same group of data. 16 bits support a maximum of 65,535 ElementIds for the same GroupId. The same group of data refers to data with the same GroupId.

[0056] After completing the agreement with each second CPU core, the first CPU core can select the first target application from the local applications to perform the work. As an example, the first CPU core can determine the current function to be implemented and determine the local application used to implement the current function to be implemented as the first target application.

[0057] S12 , selecting a first data ID from a plurality of preset data IDs according to a first target application, and selecting a target second CPU core from one or more preset second CPU cores according to the first target application.

[0058] Specifically, after the first CPU core selects the first target application from the local applications, since the data id corresponds to the local application, the first CPU core can select and obtain the first data id corresponding to the first target application. Moreover, since different local applications use different data ids to communicate with the corresponding second CPU core, the first CPU core can also select and obtain the target second CPU core corresponding to the first target application.

[0059] S13 , generating first byte stream data according to the first data id, and sending the first byte stream data to the target second CPU core, so that the target second CPU core generates a second data id and feedback data based on the first byte stream data.

[0060] The following combination Figure 2 The specific embodiment shown illustrates sending byte stream data between two CPU cores.

[0061] Specifically, Figure 2 The overall system architecture design used to send byte stream data is composed of two parts, including ZBUS Lib and ZBUSDAEMON.

[0062] ZBUS Lib is the interface library for users to use this method. The API provided by ZBUS Lib is a function call based on data ID. Through this interface, users can easily use the CPU inter-core communication mechanism to send and receive data. ZBUS Lib also contains an IPC (Inter-Process Communication) component for communicating with the ZBUSDAEMON service that truly implements inter-core communication.

[0063] ZBUSDAEMON is a daemon process that encapsulates various inter-core communication functions and provides services for ZBUSLib. It primarily functions as a ZBUS manager, primarily including IPC components and BUSWRAPPER class instances. The BUSWRAPPER class is an abstract parent class that defines a common interface for inter-core communication operations such as SPI, PCIE, and shared memory. Its subclasses, SPI_BUS_WRAPPER, PCIE_BUS_WRAPPER, and SHM_BUS_WRAPPER, inherit from the parent BUSWRAPPER class and implement their own inter-core communication functions. These specific subclasses communicate and transfer data with their respective underlying communication links through the HAL layer library provided by the BSP developer. The HAL layer provides drivers for operating the underlying hardware communication links and exposes interfaces to the upper WRAPPER layer for user-friendly functionality. The HAL layer includes the SPI_HAL, SHM_IPCF_HAL, and PCIE_HAL, corresponding to the physical communication links SPI, shared memory, and PCIE, respectively. The specific type of inter-core communication that ZBUSDAEMON provides to users is mainly specified by the configuration file. If the configuration file is set to Shared Memory, then the process will provide an inter-core communication mechanism based on shared memory, which users can configure according to their own scenarios.

[0064] When using the inter-core communication method of the present invention, you need to configure the inter-core communication mode in the ZBUSDAEMON configuration file and deploy and start the process. Then, you can connect your own application to ZBUS Lib to use the inter-core communication service provided by ZBUSDAEMON.

[0065] The key class diagrams of ZBUS Lib can be found in Figure 3 The example shown. Figure 3 In the example, key data and functions are listed, while function parameters and types are omitted.

[0066] Specifically, ZBUS Lib mainly consists of the Zbus class and the ZbusIpc class. The Init() function in both Zbus and ZbusIpc is used to initialize the IPC instance.

[0067] Create() is a function for creating a zbus (ie, the inter-core communication method of the present invention) instance.

[0068] SetIdentify() is a function that sets data_group_id_ (that is, the GroupId mentioned above). The GroupId of different types of apps is different.

[0069] SetDataArrivedCallback() is the function that sets data_available_cb_ (that is, the above callback function).

[0070] GetData() and PostData() are functions used to call MethodCall() in ZbusIpc.

[0071] zbus_Ipc_ is an instance of the ZbusIpc class. It's a composite IPC middleware wrapper. Its underlying layer is iceoryx, which provides intra-domain communication between vehicle system boards. Iceoryx is an inter-process communication component based on shared memory. This component can be replaced by other IPC components with similar functionality.

[0072] The primary function of this IPC instance is to provide intra-domain communication with the ZBUSDaemon process. The ZBUSDaemon process also contains an IPC instance, forming a communication pair with the ZBUS Lib IPC instance. The ZbusIpc class lists five key functions.

[0073] Publish() implements message publishing, which is mainly used by ZBUSDaemon to notify ZBUS Lib of the arrival of data of the GroupId it subscribes to.

[0074] MethodCall() is a function used to call the Getdata() function and the PostData() function in the IPC peer ZBUSDaemon, thereby realizing the GetData (data extraction) and PostData (data submission) functions of the API.

[0075] Subscribe() implements the message subscription function, which is mainly used by ZBUS Lib to subscribe the data ID of the GroupId corresponding to the APP to ZBUSDaemon. The Subscribe() and Publish() functions are used in conjunction with each other, and their main goal is to trigger the callback function data_available_cb_ set by the SetDataArrivedCallback function.

[0076] UnSubscribe() is used to unsubscribe the data id of the GroupId corresponding to the APP. It is automatically called by ZBUS Lib at the end of the entire program.

[0077] The design and implementation of ZBUSDaemon can be found in Figure 4 Similarly, in Figure 4 In the example, key data and functions are listed, while function parameters and types are omitted.

[0078] Specifically, ZBUSDaemon is mainly composed of three key class diagrams, including the ZbusManager class (that is, Figure 2 ZBUS_MANAGER in ZbusIpc class (that is, Figure 2 IPC in) and IBusWrapper class (that is, Figure 2 BUS_WRAPPER in IBusWrapper). IBusWrapper class is an abstract class that uses the polymorphism and inheritance ideas of C++. The parent class abstracts a set of public interfaces for data transmission and reception, allowing multiple subclasses ShmBusWrapper (i.e. Figure 2 SHM_BUS_WRAPPER in), PCieBusWrapper (that is, Figure 2 PCIE_BUS_WRAPPER in), SpiBusWrapper (that is, Figure 2 SPI_BUS_WRAPPER in the SPI_BUS_WRAPPER class implements inter-core communication according to its own mechanism. If you need to support new inter-core communication methods later, you can inherit and implement this abstract class, for example Figure 4 Therefore, the inter-core communication method of the present invention has good scalability and maintainability.

[0079] The specific functions of these key classes are introduced below.

[0080] The ZbusManager class is the management class for the entire ZBUSDaemon. Its function is to communicate with the ZBUS Lib and manage inter-core communication. It primarily contains two members: zbus_ipc_ and bus_wrapper_. zbus_ipc_ is an instance of the ZbusIpc class. Similar to zbus_ipc_ in the ZBUS Lib, it is the IPC instance used by the ZBUSDaemon to communicate with the ZBUS Lib. The ZBUSDaemon primarily utilizes the Publish function of IPC communication to notify the peer ZBUS Lib of the availability of data for a subscribed GroupId.

[0081] The bus_wrapper_ member of the ZbusManager is a pointer to the parent IBusWrapper class. Its actual instance is one of the subclasses ShmBusWrapper, PCieWrapper, or SpiBusWrapper, depending on the inter-core communication method specified in the configuration file. For example, if Shm is configured as the inter-core communication method, ShmBusWrapper uses shared memory; if PCie is configured, PCieWrapper uses the PCie bus; and if SPI is configured, SpiBusWrapper uses the SPI bus. This class contains five main functions. The Init() function is primarily used to initialize the Zbus when the ZBUSDaemon starts. For example, it calls the LoadZbusParamFromJson() function to load the configuration file, specifying the subclass for the bus_wrapper_ member to select the inter-core communication method, and initializes the IPC member zbus_Ipc_. For GetData() and PostData(), refer to the corresponding functions in the ZbusIpc class. OnDataAvailable() is used to execute callback functions.

[0082] The key data and functions of the ZbusIpc class in ZBUSDaemon are consistent with those in ZBUS Lib.

[0083] The IBusWrapper class primarily abstracts three interfaces, defining the three primary operations for inter-core communication. The first is initializing the resources required for inter-core communication, represented by the BusInit() interface. The second is sending data to the target core, represented by the BusWrite() interface. The third is receiving data from the target core, represented by the BusRead() interface. IBusWrapper abstracts and unifies the interfaces of different inter-core communication mechanisms, and its subclasses implement these basic operation interfaces. For example, one of its subclasses, ShmBusWrapper, primarily includes the data_cache_ member and the on_data_available_cb_ member. data_cache_ is a data cache module used by ShmBusWrapper to cache data received from the peer core via the HAL layer, SHM_IPCf_HAL. The on_data_available_cb_ member sets the ZbusManager member function OnDataAvailable to on_data_available_cb_ when the ZbusManager calls BusInit() for initialization. When the SHM_IPCf_HAL layer receives data, it updates the cache data_cache_ and triggers the call to on_data_available_cb_. The ShmBusWrapper implementation of the BusRead() interface directly reads data from the data_cache_ cache. The ShmBusWrapper implementation of the BusWrite() interface directly calls the SHM_IPCf_HAL implementation of sending data.

[0084] The difference between the PCieWrapper class, the SpiBusWrapper class, and the ShmBusWrapper class lies in the different ways of implementing BusInit(), BusWrite(), and BusRead() to access different HAL layers and call different HAL layers.

[0085] It should be noted that when communicating between different CPU cores, the CPU core sending data can send the data to be sent to the CPU core receiving data through the target inter-core communication method according to the preset operation method, wherein the target inter-core communication method is an inter-core communication method selected from multiple preset inter-core communication methods, and the preset operation method is the common operation method of multiple preset inter-core communication methods.

[0086] If the above example is used for explanation, the above-mentioned multiple preset inter-core communication methods include the above-mentioned SPI, PCie, shared memory and other inter-core communication methods, the above-mentioned target inter-core communication method is the above-mentioned inter-core communication method specified by the configuration file, and the above-mentioned preset operation method includes operating the three abstract interfaces of the above-mentioned parent class IBusWrapper: BusInit(), BusWrite(), and BusRead(), that is, no matter which inter-core communication method is formulated according to the configuration file, the preset operation method can be used to implement the target inter-core communication method to send the first byte stream data to the target second CPU core.

[0087] Therefore, in order to send the first byte stream data to the target second CPU core, the first byte stream data can be sent to the target second CPU core through the target inter-core communication mode according to a preset operation mode.

[0088] S14 , receiving a second data ID fed back by the target second CPU core, receiving feedback data fed back by the target second CPU core according to the second data ID, and controlling the first target application to run based on the feedback data.

[0089] Specifically, the target second CPU core feeds back the second data id and the feedback data together, that is, the feedback data required by the first target application can be identified based on the second data id. Relying on this design, if the first CPU core receives multiple data ids, it is necessary to determine the second data id from the multiple data ids, and determine the feedback data corresponding to the second data id as the feedback data required by the first target application, and then receive the feedback data corresponding to the second data id.

[0090] Therefore, it is set to select a first target application from the local application; select a first data id from multiple preset data ids according to the first target application, and select a target second CPU core from one or more preset second CPU cores according to the first target application; generate first byte stream data according to the first data id, and send the first byte stream data to the target second CPU core, so that the target second CPU core generates a second data id and feedback data based on the first byte stream data; receive the second data id fed back by the target second CPU core, and receive the feedback data fed back by the target second CPU core according to the second data id, and control the first target application to run based on the feedback data. Since the data id set for communication and the second CPU core for communication both correspond to local applications, after determining the first target application, the first data id and the target second CPU core of the application in actual communication can be determined according to the first target application, and communication is performed with the target second CPU core through the first data id. Since the data id is used to communicate with the second CPU core, standardized processing of communication information between the first CPU core and the second CPU core can be achieved, thereby supporting the setting of a general API and providing upper-level users with a unified inter-core communication interface, that is, a set of APIs and SDKs, which greatly facilitates the use of upper-level development users, thereby achieving convenient inter-core communication and having high maintainability and scalability.

[0091] In some embodiments of the present invention, generating first byte stream data based on a first data id includes: obtaining a data structure corresponding to the first data id based on a preset correspondence relationship, the preset correspondence relationship including a correspondence between multiple data ids and multiple data structures; generating first byte stream data based on the data structure.

[0092] The following is an explanation using a specific example.

[0093] Specifically, in this example, a data ID is set to correspond to a C language data structure, which is used to carry data. The example is as follows:

[0094]

[0095] The above program indicates that data ID 0x30010001 corresponds to the data structure InternalNodeOnline, which contains another data structure called InternalNodeEnum. When transmitting data via inter-core communication, the receiving and sending APIs specify that the data ID 0x30010001 should be used to retrieve and send the InternalNodeOnline data. The data ID is identified by the C language macro ZKOS_ZBUS_DID_NM_InternalNodeOnline, whose value is the hexadecimal number 0x30010001.

[0096] That is to say, after determining the first data id, the universal API needs to find the corresponding data structure according to the first data id, generate the first byte stream data according to the data structure, and send the first byte stream data to the target second CPU core.

[0097] The following describes the general API using a specific example.

[0098] Specifically, ZBUS Lib provides 6 interface functions: Function 1, Function 2, Function 3, Function 4, Function 5, and Function 6, which are:

[0099] Function 1: static std::shared_ptr <zbus>Zbus::Create().

[0100] Function 2: bool Zbus::Init().

[0101] Function three: bool Zbus::SetIdentify(uin32_t GroupId).

[0102] Function 4: int Zbus::GetData(uint32_t data_id,void*buffer,uint32_t size).

[0103] Function 5: int Zbus::PostData(uint32_t data_id,void*buffer,uint32_tsize).

[0104] Function 6: using OnDataAvailable = std::function<void(uint32_t id)> ;

[0105] void Zbus::SetDataArrivedCallback(OnDataAvailable cb=nullptr).

[0106] Function 1 is used to construct a new zbus instance and return its pointer. In other words, users need to use this interface to obtain a zbus instance before using the other five interface functions.

[0107] Function 2 is used to load zbus related configuration and initialize zbus functions, mainly loading IPC configuration files and then initializing IPC components for cross-process communication between IPC and ZBUSDAEMON.

[0108] Function three is used to set the APP identity id, which is the GroupId in the above data id. Each different APP application has a different GroupId, so its data id is also different. Only when the GroupId corresponding to the APP that calls the API is set, the callback function of OnDataAvailable of the data arrival notification set by calling the SetDataArrivedCallback function of the above function six can take effect. In other words, before using the above void Zbus::SetDataArrivedCallback (OnDataAvailable cb = nullptr) interface function, you must first use the boolZbus::SetIdentify (uin32_t GroupId) interface, otherwise the program will not trigger the call.

[0109] Function 4 reads the byte stream data of the data structure corresponding to data id from ZBUSDAEMON into a preset buffer. Size specifies the size of the preset buffer and must be equal to or greater than the number of bytes in the data structure corresponding to data id. This function returns 0 for success and non-zero for failure.

[0110] Function 5 sends the byte stream of the data structure corresponding to data id in the preset buffer of size size to the peer CPU core via ZBUSDAEMON. size must be greater than or equal to the byte size of the data structure corresponding to data id. This function returns 0 for success and non-zero for failure.

[0111] Function six is ​​used to: Through this function, the user APP registers a callback function for the arrival of ZBUSDAEMON data on the other end, and when the data update on the other end is available, processes the corresponding logic of the data id in the callback function registered by itself. The user sets the function named cb of the OnDataAvailable type passed in through the SetDataArrivedCallback function. void Zbus::SetDataArrivedCallback(OnDataAvailable cb=nullptr) is used to process the corresponding logic of the data id in the registered callback function. cb is a callback function of type OnDataAvailable. SetDataArrivedCallback registers this cb function. The cb callback function is written by the user. The user can write the corresponding logic for processing the data id by themselves, but it needs to be registered through SetDataArrivedCallback.

[0112] It should be noted that for the above functions 4 and 5, it is also necessary to set up the data structure to be obtained according to the data ID. For example, through the preset setting, when the above data ID 0x30010001 is received, the corresponding data structure InternalNodeOnline is obtained and sent. The above functions 4 and 5 are general APIs.

[0113] In some embodiments of the present invention, after the first CPU core receives the second byte stream data sent by the third CPU core, the method also includes: selecting a second target application from the local application based on the second byte stream data; generating transmission data based on the second target application, and selecting a fourth data id from multiple preset data ids based on the second target application, generating third byte stream data based on the fourth data id, and sending the transmission data and the third byte stream data to the third CPU core; wherein, sending the transmission data and the third byte stream data to the third CPU core includes: sending the transmission data and the third byte stream data to the third CPU core through the target inter-core communication mode according to the preset operation mode, wherein the target inter-core communication mode is an inter-core communication mode selected from multiple preset inter-core communication modes, and the preset operation mode is an operation mode common to multiple preset inter-core communication modes.

[0114] Specifically, the first CPU core can also serve as the CPU core with which other CPU cores communicate after determining their own to-be-implemented functions, and the other CPU cores that have determined their own to-be-implemented functions are referred to as third CPU cores. In other words, after the third CPU core has determined its own to-be-implemented functions, it determines the application used to implement the to-be-implemented functions, and after determining that communication with the first CPU core is necessary to implement the to-be-implemented functions, the third CPU core generates second byte stream data based on the data ID corresponding to the application and sends the second byte stream data to the first CPU core. At this time, after receiving the second byte stream data sent by the third CPU core, the first CPU core can obtain the corresponding data id based on the second byte stream data. Since the data id corresponds to the application, the second target application in the local application for responding to the third CPU core can be determined based on the second byte stream data, and then the second target application can be controlled to run in a preset manner to obtain the running result, and the running result is used as feedback data fed back to the third CPU core by itself, and a fourth data id is generated based on the second target application, and third byte stream data is generated based on the fourth data id. The feedback data fed back to the third CPU core and the third byte stream data are sent to the third CPU core, so that the application in the third CPU core can run according to the feedback data fed back by the first CPU core.

[0115] In some embodiments of the present invention, the communication method between the first CPU core and the target second CPU core is a shared memory-based communication method, and receiving the second data id fed back by the target second CPU core includes: checking whether there is a third data id in the shared memory; if the third data id exists in the shared memory, matching the third data id with the first data id, and using the third data id that successfully matches the first data id as the second data id; receiving the second data id.

[0116] Specifically, the first CPU core needs to check the status of the shared memory. If there is shared data in the shared memory, it means that the second CPU core has sent data. At this time, the first CPU core needs to determine whether there is a data id in the shared data. If there is a data id in the shared data, the data id in the shared data is recorded as the third data id.

[0117] Furthermore, because multiple third data IDs may exist in the shared memory, the first CPU core needs to determine the second data ID from the multiple third data IDs in the shared memory and then receive feedback data corresponding to the second data ID. Specifically, the method for determining the second data ID from the third data ID is to match the third data ID in the shared memory with the first data ID and use the third data ID that successfully matches as the second data ID.

[0118] In some embodiments of the present invention, the first data ID and the third data ID both include a group ID, and matching the third data ID with the first data ID includes: comparing the group ID of the third data ID with the group ID of the first data ID; if the group ID in the third data ID is consistent with the group ID of the first data ID, it is determined that the third data ID matches the first data ID successfully.

[0119] Specifically, the above-mentioned group id is the above-mentioned GroupId, that is, if there is a third data id in the shared data, the GroupId of the third data id is obtained, and the obtained GroupId of the third data id is compared with the GroupId of the first data id. If the GroupId of a certain third data id is consistent with the GroupId of the first data id, it is determined that the third data id matches successfully and is the second data id.

[0120] Of course, if the GroupIds of all third data ids in the shared memory are inconsistent with the GroupId of the first data id, it can be determined that the target second CPU core has not sent feedback data.

[0121] That is to say, the first CPU core needs to check the status of the shared memory. If there is shared data in the shared memory, it determines whether there is a data id in the shared data. If there is a data id in the shared data, the data id in the shared data is recorded as the third data id, and the GroupId of the third data id is compared with the GroupId of the first data id. If the GroupId of a third data id is consistent with the GroupId of the first data id, the third data id is determined to be a valid data id.

[0122] The following combination Figure 5 The specific examples shown are used to illustrate the above embodiments. Figure 5 In the example, the ZbusWrapper class is the above-mentioned SHM_BUS_WRAPPER, the ipcfHAL library is the above-mentioned SHM_IPCF_HAL, and the operating system kernel can be the Linux kernel. Figure 5 The functions used in the code have the following meanings:

[0123] Init(), which means initialization;

[0124] SetDataArrivedCallback(OnDataAvailable), which means setting the callback function;

[0125] Ipc.Subscribe(zbus_daemon,topic_name), which means subscribing to data id;

[0126] BusInit(protocol, OnDataAvailable), which means initialization and passing in the callback function;

[0127] Return, which means returning the result of the operation;

[0128] ShmInit(OnMsgAvailableCb), which means shared memory is initialized and passed into the callback function;

[0129] ShmMqGet(key, size, msgflg), which means getting the shared memory queue;

[0130] OnMsgAvailableCb(msq_id), which means executing the callback function when there is data in the shared memory queue;

[0131] ShmMqRecv(msqid, msgp, msgsz, msgflg), means receiving data in the shared memory queue;

[0132] UpdateDataCache, which means updating the data cache data_cache_;

[0133] OnDataAvailable(msq_id), which means executing the callback function after the data cache is updated;

[0134] Ipc.Publish(topic_name, data), which means publishing data id;

[0135] OnDataAvailable(msq_id), which means executing the callback function;

[0136] GetData(data_id, buffer, size), which means getting data operation;

[0137] Ipc.MethodCall(zbus_daemon, "GetData", reqData, resData, 1s), which means remote method call to read data;

[0138] BusRead(data_id, buffer, size, mode), which means reading the data cache;

[0139] PostData(data_id, buffer, size), means sending data operation;

[0140] Ipc.MethodCall(zbus_daemon, "PostData", reqData, resData, 1s), which means remote method call, sending data;

[0141] BusWrite(data_id, buffer, size, mode), means writing data;

[0142] ShmMqSend(msqid, msgp, msgsz, msgflg) means sending data in the shared memory queue.

[0143] Process 1, "Initialization," illustrates the initialization process after starting an app and ZBUSDaemon using the ZBUS Lib. This process primarily includes loading configuration on both ends, initializing IPC, setting the GroupId, subscribing to GroupId data, and registering callback functions. For an app to use ZBUS services, ZBUSDaemon must be started before the app.

[0144] Specifically, the app first executes function control to initialize and set a callback function. ZBUS Lib sends the subscription data ID, which is the first data ID mentioned above. After receiving the subscription data ID, the ZbusManager class controls initialization and passes the callback function. After receiving the callback function, the ZbusWrapper class initializes shared memory and passes the callback function to SHM_IPCF_HAL. Furthermore, the ZbusWrapper class needs to obtain shared memory, determine whether shared data exists in the shared memory, and return the acquisition result to the ZbusManager class.

[0145] Process 2 is the data availability notification. It shows that when the core data of the peer end is available, the Linux Kernel triggers an interrupt, and the ZBUS Daemon obtains the data from the shared memory of the SHM_IPCF_HAL layer to the local core ZBUSDaemon, updates the data to the data_cache_ cache, and publishes the data arrival notification to the app through IPC. Only the app's GroupId and the GroupId to which the data belongs are consistent will receive the notification, thereby triggering the data availability callback function registered by the app.

[0146] Specifically, if the ZbusWrapper class determines that data exists in shared memory, it executes the callback function, receives the data from shared memory, and caches the received data in data_cache_. At this point, the ZbusManager class executes the callback function to obtain the published data ID, which is the second data ID mentioned above. Because there may be multiple data IDs in shared memory, the GroupId of the data ID in shared memory needs to be compared with the GroupId of the first data ID. If the GroupId of a data ID matches the GroupId of the first data ID, the data ID is determined to be valid.

[0147] Process 3 is data acquisition, which shows the process of APP obtaining data. By calling function 4 in the above general API, user data is obtained from the cache of ZBUSDaemon with the help of ZBUS Lib's IPC.

[0148] Specifically, the APP calls function 4 in the general API to perform the data acquisition operation. Based on this operation, the ZBUS Lib obtains user data from the data_cache_ through the ZbusManager class. This user data is the feedback data mentioned above.

[0149] Process 4 is data sending, which shows the process of APP sending data. By calling function 5 in the above-mentioned general API, the data is transmitted to ZBUSDaemon with the help of ZBUS Lib's IPC. ZBUSDaemon finally calls ShmMqSend of SHM_IPCF_HAL through various layers to send the data to the shared memory and then notifies the peer core.

[0150] Specifically, the app calls function five in the general API to send data, and ZBUS Lib sends data to the ZbusManager class based on this operation. After receiving the data, the ZbusManager class writes the data to the shared memory through the ZbusWrapper class.

[0151] Among them, the HAL layer SHM_IPCf_HAL of ShmBusWrapper provides a shared memory data link. There are four key interface functions in the data operation interface provided by the shared memory data link, namely the following function seven, function eight, function nine, and function ten, a total of four interface functions:

[0152] Function 7: bool ShmInit(ShmOnDataAvailable callback).

[0153] Function 8: int ShmMqGet(uint8_t key,uint32_t size,int msgflg).

[0154] Function nine: int ShmMqRecv(int msqid,void*msgp,uint32_t msgsz,enum ShmFlagmsgflg).

[0155] Function 10: int ShmMqSend(int msqid,const void*msgp,uint32_t msgsz,enumShmFlag msgflg).

[0156] Among them, function seven is used to: construct and initialize shared memory, and set the callback function ShmOnDataAvailable that is triggered when shared data is available to notify the upper layer that data can be read.

[0157] Function 8 obtains a shared memory queue with a node size of size bytes for receiving and sending data. The return value is the queue id, which is msqid.

[0158] Function nine is used to obtain the queue head node data from the shared memory whose queue id is msqid.

[0159] Function 10 is used to insert node data into the tail of the shared memory whose queue id is msqid.

[0160] In summary, the inter-core communication method of the embodiment of the present invention is configured to select a first target application from a local application; select a first data ID from multiple preset data IDs based on the first target application, and select a target second CPU core from one or more preset second CPU cores based on the first target application; generate first byte stream data based on the first data ID, and send the first byte stream data to the target second CPU core so that the target second CPU core generates a second data ID and feedback data based on the first byte stream data; receive a second data ID fed back by the target second CPU core, and receive feedback data fed back by the target second CPU core based on the second data ID, and control the first target application to run based on the feedback data. Since the data ID set for communication and the second CPU core for communication both correspond to local applications, after determining the first target application, the first data ID and the target second CPU core of the application in actual communication can be determined based on the first target application, and communication can be performed with the target second CPU core using the first data ID. Since the data ID is used to communicate with the second CPU core, standardized processing of communication information between the first CPU core and the second CPU core can be achieved, thereby supporting the setting of a universal API and providing a unified inter-core communication interface, i.e., a set of APIs and SDKs, for upper-level users, greatly facilitating the use of upper-level development users. Furthermore, by adapting to different underlying transmission communication links and mechanisms (such as shared memory and the SPI physical bus), users can select different communication links for different scenarios. This can be expanded to support new inter-core communication mechanisms without changing the usage method, ensuring strong scalability and maintainability. Centralized management of the underlying link resources and operating system resources that data transmission and reception rely on is seamless to users, ensuring system security and orderliness, improving overall system robustness, and preventing users from directly and illegally manipulating underlying resources, thus ensuring system security and stability.

[0161] Based on the inter-core communication method of the above embodiment, the present invention proposes a computer-readable storage medium.

[0162] In an embodiment of the present invention, a computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the above-mentioned inter-core communication method is implemented.

[0163] The computer-readable storage medium of an embodiment of the present invention, by implementing the inter-core communication method of the above-mentioned embodiment, sets the data id used for communication and the second CPU core for communication to correspond to the local application. Therefore, after determining the first target application, the first data id and the target second CPU core of the application in actual communication can be determined according to the first target application, and communication is performed with the target second CPU core through the first data id. Since the data id is used to communicate with the second CPU core, standardized processing of communication information between the first CPU core and the second CPU core can be achieved, thereby supporting the setting of a general API and providing upper-level users with a unified inter-core communication interface, that is, a set of APIs and SDKs, which greatly facilitates the use of upper-level development users.

[0164] Based on the inter-core communication method of the above embodiment, the present invention also provides an electronic device.

[0165] Figure 6 It is a structural block diagram of an electronic device according to an embodiment of the present invention.

[0166] like Figure 6 As shown, electronic device 500 includes: a processor 501 and a memory 503. Processor 501 and memory 503 are connected, for example, via a bus 502. Optionally, electronic device 500 may further include a transceiver 504. It should be noted that in actual applications, the number of transceivers 504 is not limited to one, and the structure of electronic device 500 does not constitute a limitation on the embodiments of the present invention.

[0167] The processor 501 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the present disclosure. The processor 501 may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, and the like.

[0168] The bus 502 may include a path for transmitting information between the above components. The bus 502 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus. The bus 502 may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 5 Only one thick line is used in the diagram, but this does not mean that there is only one bus or one type of bus.

[0169] The memory 503 is used to store a computer program corresponding to the inter-core communication method of the above embodiment of the present invention, and the computer program is controlled and executed by the processor 501. The processor 501 is used to execute the computer program stored in the memory 503 to implement the content shown in the above method embodiment.

[0170] in, Figure 6 The electronic device 500 shown is merely an example and should not limit the functions and scope of use of the embodiments of the present invention.

[0171] The electronic device of an embodiment of the present invention, by implementing the inter-core communication method of the above-mentioned embodiment, sets the data id used for communication and the second CPU core for communication to correspond to the local application. Therefore, after determining the first target application, the first data id of the application in actual communication and the target second CPU core can be determined according to the first target application, and communication is performed with the target second CPU core through the first data id. Since the data id is used to communicate with the second CPU core, standardized processing of communication information between the first CPU core and the second CPU core can be achieved, thereby supporting the setting of a general API and providing upper-level users with a unified inter-core communication interface, that is, a set of APIs and SDKs, which greatly facilitates the use of upper-level development users.

[0172] The present invention also provides an inter-core communication device.

[0173] Figure 7 It is a structural block diagram of the inter-core communication device according to an embodiment of the present invention.

[0174] like Figure 7 As shown, the inter-core communication device 700 includes: a selection module 701, which is used to select a first target application from local applications, and select a first data id from multiple preset data ids according to the first target application, and select a target second CPU core from one or more preset second CPU cores according to the first target application; a generation module 702, which is used to generate first byte stream data according to the first data id; a sending module 703, which is used to send the first byte stream data to the target second CPU core, so that the target second CPU core generates a second data id and feedback data based on the first byte stream data; a receiving module 704, which is used to receive the second data id fed back by the target second CPU core, and receive feedback data fed back by the target second CPU core according to the second data id; a control module 705, which is used to control the first target application to run based on the feedback data.

[0175] In some embodiments of the present invention, selecting the first target application from the local applications includes: determining a current function to be implemented, and determining the local application for implementing the current function to be implemented as the first target application.

[0176] In some embodiments of the present invention, generating first byte stream data according to a first data id includes: obtaining a data structure corresponding to the first data id according to a preset correspondence relationship, the preset correspondence relationship including a correspondence between multiple data ids and multiple data structures; generating first byte stream data according to the data structure.

[0177] In some embodiments of the present invention, the communication method between the first CPU core and the target second CPU core is a shared memory-based communication method, and receiving the second data id fed back by the target second CPU core includes: checking whether there is a third data id in the shared memory; if there is a third data id in the shared memory, determining the second data id based on the third data id; and receiving the second data id.

[0178] In some embodiments of the present invention, the first data ID and the third data ID both include a group ID, and determining the second data ID based on the third data ID includes: comparing the group ID of the third data ID with the group ID of the first data ID; if the group ID of the third data ID is consistent with the group ID of the first data ID, determining the third data ID as the second data ID.

[0179] In some embodiments of the present invention, after the first CPU core receives the second byte stream data sent by the third CPU core, the method also includes: selecting a second target application from the local application based on the second byte stream data; generating transmission data based on the second target application, and selecting a fourth data id from multiple preset data ids based on the second target application, generating third byte stream data based on the fourth data id, and sending the transmission data and the third byte stream data to the third CPU core; wherein, sending the transmission data and the third byte stream data to the third CPU core includes: sending the transmission data and the third byte stream data to the third CPU core through the target inter-core communication mode according to the preset operation mode, wherein the target inter-core communication mode is an inter-core communication mode selected from multiple preset inter-core communication modes, and the preset operation mode is an operation mode common to multiple preset inter-core communication modes.

[0180] It should be noted that for other specific implementations of the inter-core communication device of the embodiment of the present invention, reference can be made to the inter-core communication method of the above embodiment.

[0181] The inter-core communication device of an embodiment of the present invention sets the data id used for communication and the second CPU core for communication to correspond to the local application. Therefore, after determining the first target application, the first data id of the application in actual communication and the target second CPU core can be determined according to the first target application, and communication is performed with the target second CPU core through the first data id. Since the data id is used to communicate with the second CPU core, standardized processing of communication information between the first CPU core and the second CPU core can be achieved, thereby supporting the setting of a general API and providing upper-level users with a unified inter-core communication interface, that is, a set of APIs and SDKs, which greatly facilitates the use of upper-level development users.

[0182] The present invention also provides a multi-core system.

[0183] Figure 8 It is a structural block diagram of a multi-core system according to an embodiment of the present invention.

[0184] like Figure 8 As shown, the multi-core system 800 includes multiple CPU cores 801 , and any one of the multiple CPU cores 801 includes the electronic device 500 of the above embodiment.

[0185] In the multi-core system of an embodiment of the present invention, the data id used for communication and the second CPU core for communication are both set to correspond to local applications. Therefore, after determining the first target application, the first data id of the application in actual communication and the target second CPU core can be determined according to the first target application, and communication is performed with the target second CPU core through the first data id. Since the data id is used to communicate with the second CPU core, standardized processing of communication information between the first CPU core and the second CPU core can be achieved, thereby supporting the setting of a general API and providing upper-level users with a unified inter-core communication interface, that is, a set of APIs and SDKs, which greatly facilitates the use of upper-level development users.

[0186] It should be noted that the logic and / or steps represented in the flowcharts or otherwise described herein can be considered as a sequenced list of executable instructions for implementing the logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (e.g., a computer-based system, a system including a processor, or other system that can fetch and execute instructions from an instruction execution system, apparatus, or device). For purposes of this specification, a "computer-readable medium" can be any device that can contain, store, communicate, propagate, or transmit a program for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (non-exhaustive list) of computer-readable media include the following: an electrical connection with one or more wires (electronic device), a portable computer disk cartridge (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), fiber optic devices, and portable compact disc read-only memory (CDROM). Furthermore, the computer-readable medium may even be paper or other suitable medium on which the program is printed, since the program may be obtained electronically, for example, by optically scanning the paper or other medium and then editing, interpreting or processing it in another suitable manner if necessary, and then storing it in a computer memory.

[0187] It should be understood that various parts of the present invention can be implemented using hardware, software, firmware, or a combination thereof. In the above-described embodiments, multiple steps or methods can be implemented using software or firmware stored in a memory and executed by a suitable instruction execution system. If implemented using hardware, as in another embodiment, any one of the following technologies known in the art or a combination thereof can be used: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, an application-specific integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0188] Throughout this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples" indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, schematic representations of these terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

[0189] In the description of this specification, the terms "center", "longitudinal", "lateral", "length", "width", "thickness", "up", "down", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inside", "outside", "clockwise", "counterclockwise", "axial", "radial", "circumferential", etc., indicating the orientation or position relationship, are based on the orientation or position relationship shown in the accompanying drawings, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operate in a specific orientation, and should not be understood as a limitation on the present invention.

[0190] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features being referred to. Thus, a feature identified as "first" or "second" may explicitly or implicitly include at least one such feature. In the description of the present invention, "plurality" means at least two, for example, two, three, etc., unless otherwise specifically defined.

[0191] Throughout this specification, unless otherwise specified, terms such as "mounted," "connected," "connect," and "fixed" should be interpreted broadly. For example, these terms may refer to fixed, removable, or integrated connections; mechanical or electrical connections; direct or indirect connections through an intermediary; and internal communication between two components or interaction between two components, unless otherwise specified. Those skilled in the art will understand the specific meanings of these terms in the present invention based on specific circumstances.

[0192] In the present invention, unless otherwise expressly specified or limited, a first feature being "above" or "below" a second feature may mean that the first and second features are in direct contact, or that the first and second features are in indirect contact through an intermediary. Furthermore, a first feature being "above," "above," or "above" a second feature may mean that the first feature is directly above or diagonally above the second feature, or simply means that the first feature is at a higher level than the second feature. A first feature being "below," "below," or "below" a second feature may mean that the first feature is directly below or diagonally below the second feature, or simply means that the first feature is at a lower level than the second feature.

[0193] Although the embodiments of the present invention have been shown and described above, it will be understood that the above embodiments are illustrative and are not to be construed as limitations on the present invention. A person skilled in the art may change, modify, replace and modify the above embodiments within the scope of the present invention.< / zbus>

Claims

1. A method for inter-core communication, characterized in that: The method is used for a first CPU core, and the method comprises: Select a first target application from local applications; Selecting a first data id from a plurality of preset data ids according to the first target application, and selecting a target second CPU core from one or more preset second CPU cores according to the first target application; Generate first byte stream data according to the first data id, and send the first byte stream data to the target second CPU core so that the target second CPU core generates a second data id and feedback data based on the first byte stream data; Receive a second data id fed back by the target second CPU core, receive feedback data fed back by the target second CPU core according to the second data id, and control the first target application to run based on the feedback data.

2. The inter-core communication method according to claim 1, characterized in that: The selecting a first target application from local applications includes: A current function to be implemented is determined, and a local application used to implement the current function to be implemented is determined as the first target application.

3. The inter-core communication method according to claim 1, characterized in that: The generating first byte stream data according to the first data id includes: Obtaining a data structure corresponding to the first data id according to a preset corresponding relationship, wherein the preset corresponding relationship includes a corresponding relationship between multiple data ids and multiple data structures; The first byte stream data is generated according to the data structure.

4. The inter-core communication method according to claim 1, characterized in that: The communication mode between the first CPU core and the target second CPU core is a communication mode based on a shared memory, and the receiving of the second data id fed back by the target second CPU core includes: Check whether there is a third data id in the shared memory; If a third data id exists in the shared memory, the third data id is matched with the first data id, and the third data id that successfully matches the first data id is used as the second data id; Receive the second data id.

5. The inter-core communication method according to claim 4, characterized in that: The first data id and the third data id both include a group id, and matching the third data id with the first data id includes: The group id of the third data id is compared with the group id of the first data id. If the group id of the third data id is consistent with the group id of the first data id, it is determined that the third data id matches the first data id successfully.

6. The inter-core communication method according to claim 1, characterized in that: After the first CPU core receives the second byte stream data sent by the third CPU core, the method further includes: Selecting a second target application from local applications according to the second byte stream data; Generate transmission data according to the second target application, select a fourth data id from the plurality of preset data ids according to the second target application, generate third byte stream data according to the fourth data id, and send the transmission data and the third byte stream data to the third CPU core; Wherein, sending the transmission data and the third byte stream data to the third CPU core includes: The transmission data and the third byte stream data are sent to the third CPU core through a target inter-core communication method according to a preset operation method, wherein the target inter-core communication method is an inter-core communication method selected from a plurality of preset inter-core communication methods, and the preset operation method is a common operation method of the plurality of preset inter-core communication methods.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the inter-core communication method as described in any one of claims 1 to 6 is implemented.

8. An electronic device, characterized in that: The invention comprises a memory, a processor and a computer program stored in the memory and executable on the processor, wherein when the computer program is executed by the processor, the inter-core communication method as claimed in any one of claims 1 to 6 is implemented.

9. An inter-core communication device, characterized in that: The device comprises: A selection module, configured to select a first target application from local applications, select a first data id from a plurality of preset data ids according to the first target application, and select a target second CPU core from one or more preset second CPU cores according to the first target application; A generating module, used for generating first byte stream data according to the first data ID; A sending module, used for sending the first byte stream data to the target second CPU core, so that the target second CPU core generates a second data id and feedback data based on the first byte stream data; a receiving module, configured to receive a second data id fed back by the target second CPU core, and receive feedback data fed back by the target second CPU core according to the second data id; A control module is used to control the first target application to run based on the feedback data.

10. A multi-core system, characterized in that: The system includes multiple CPU cores, and any one of the multiple CPU cores includes the electronic device as claimed in claim 8.

Images