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

Abstract

Disclosed in the present application are an inter-core communication method and apparatus, and a medium, an electronic device and a multi-core system. The method comprises: selecting a first target application from among local applications (S11); on the basis of the first target application, selecting a first data id from among a plurality of preset data ids, and on the basis of the first target application, selecting a second target CPU core from among one or more preset second CPU cores; on the basis of the first data id, generating first byte stream data, and sending the first byte stream data to the second target CPU core, such that the second target CPU core generates a second data id and feedback data on the basis of the first byte stream data (S13); and receiving the second data id fed back by the second target CPU core, on the basis of the second data id, receiving the feedback data fed back by the second target CPU core, and controlling the first target application to run on the basis of the feedback data (S14). The method can realize convenient inter-core communication.

Description

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

[0001] Cross-reference to Related Applications

[0002] This application claims priority to the Chinese patent application No. 202410992342.X, filed on July 23, 2024, and entitled "Inter-core communication method, device and medium, electronic device, and multi-core system", the entire content of which is incorporated herein by reference. TECHNICAL FIELD

[0003] The present application relates to the technical field of inter-core communication, and in particular to an inter-core communication method, device and medium, electronic device, and multi-core system. BACKGROUND

[0004] With the rapid development of intelligent technology for new energy vehicles, the chips carried on vehicles are becoming more and more rich. Different CPU (Central Processing Unit) cores can be located in the same chip or different chips. These CPU cores can be heterogeneous or homogeneous, and the operating systems carried between the CPU cores can also be different. In order to efficiently meet the diversified user needs and functions, it is necessary to provide a mechanism for data transmission and communication between different CPU cores for inter-core communication. SUMMARY

[0005] The present application aims to at least partly solve one of the problems in the related art. To this end, the first object of the present application is to provide an inter-core communication method to achieve convenient inter-core communication.

[0006] The second object of the present application is to provide a computer readable storage medium.

[0007] The third object of the present application is to provide an electronic device.

[0008] The fourth object of the present application is to provide an inter-core communication device.

[0009] The fifth object of the present application is to provide a multi-core system.

[0010] To achieve the above object, the first aspect of the present application provides a method for inter-core communication, the method is used for a first CPU core, and the method comprises the following steps: selecting 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; 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 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, 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.

[0011] The second aspect of the present application provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to realize the inter-core communication method.

[0012] The third aspect of the present application provides an electronic device, which comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, and the computer program is executed by the processor to realize the inter-core communication method.

[0013] The fourth aspect of the present application provides an inter-core communication device, which comprises: a selection module, configured to select a first target application from local applications, and 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 generation module, configured to generate first byte stream data according to the first data id; a sending module, configured to send the first byte stream data to the 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; a receiving module, configured to 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 a control module, configured to control the first target application to run based on the feedback data.

[0014] The fifth aspect of the present application provides a multi-core system, which comprises a plurality of CPU cores, and for any one of the plurality of CPU cores, the electronic device is comprised.

[0015] According to the inter-core communication method, device and medium, electronic device and multi-core system, the first target application is selected from the local application, the first data id is selected from the plurality of preset data ids according to the first target application, and the target second CPU core is selected from the one or more preset second CPU cores according to the first target application; the 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 the second data id and the feedback data based on the first byte stream data; the second data id fed back by the target second CPU core is received, the 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 used for communication and the second CPU core for communication both correspond to the local application, the first data id and the target second CPU core used in actual communication can be determined according to the first target application after the first target application is determined, and communication is performed through the first data id and the target second CPU core. Since the data id and the second CPU core are used for communication, the standardized processing of the communication information between the first CPU core and the second CPU core can be realized, so that the general API (Application Programming Interface, application programming interface) is supported, a unified inter-core communication interface is provided for the upper-layer user, that is, a set of API and SDK (Software Development Kit, software development kit), which greatly facilitates the use of the upper-layer development user and realizes convenient inter-core communication.

[0016] Additional aspects and advantages of the application will be set forth in part in the description which follows, and in part will become apparent to those skilled in the art upon examination of the following and / or can be learned by practice of the application. BRIEF DESCRIPTION OF DRAWINGS

[0017] FIG. 1 is a flowchart of an inter-core communication method according to an embodiment of the present application;

[0018] FIG. 2 is a schematic diagram of an inter-core communication system architecture according to an embodiment of the present application;

[0019] FIG. 3 is a schematic diagram of an inter-core communication system architecture according to an example of the present application;

[0020] FIG. 4 is a schematic diagram of an inter-core communication system architecture according to another example of the present application;

[0021] FIG. 5 is a schematic diagram of an inter-core communication method according to an example of the present application;

[0022] FIG. 6 is a structural block diagram of an electronic device according to an embodiment of the present application;

[0023] FIG. 7 is a structural block diagram of an inter-core communication device according to an embodiment of the present application;

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

[0025] In the field of vehicle-mounted, there are three mechanisms for realizing inter-core communication. The main difference is the link for transmitting data at the bottom layer. There are implementations based on SPI (Serial Peripheral Interface) physical bus, implementations based on PCie (Peripheral Component Interconnect Express) bus, and implementations based on shared memory.

[0026] Inter-core communication based on SPI physical bus adopts SPI bus technology, which is a synchronous serial communication protocol mainly used for communication between chips. SPI bus communication requires at least two devices, a master device and a slave device. In a multi-core processor system, each core can act as a master device or a slave device, so inter-core communication can be realized through the SPI bus.

[0027] Inter-core communication based on PCie adopts PCie bus for data transmission, which is a high-speed serial bus mainly used for connecting various devices inside a computer, including hard disks, graphics cards, network cards, etc. In a multi-core processor, each core can act as an endpoint of the PCie bus, so inter-core communication can be realized through the PCie bus.

[0028] Inter-core communication based on shared memory adopts shared memory for data transmission. Shared memory is a memory sharing mechanism provided by the linux operating system, which allows different processes or threads to access the same block of memory, thereby achieving data sharing and communication. In a multi-core processor system, each core can access shared memory, so inter-core communication can be realized through shared memory.

[0029] These three methods use three different physical communication links, SPI, PCie, and shared memory, respectively, so they require different hardware support and driver support, as well as BSP (Board Support Package) engineers to provide HAL (Hardware Abstraction Layer) layer encapsulation of the respective bottom layer communication links to facilitate the use of these communication methods. These three methods have their own advantages and disadvantages, and the most suitable method needs to be selected according to the scene. The summary and comparison are as follows.

[0030] Advantages of SPI-based:

[0031] Good real-time performance: SPI communication is based on hardware interface implementation, fast speed, suitable for high real-time requirement communication scene. High security: SPI communication is based on hardware interface implementation, high communication security, not easy to be used by malicious programs or attackers for illegal operation. Stable and reliable: SPI communication is based on hardware interface implementation, high stability and reliability, not easy to appear deadlock and competition and other problems.

[0032] Disadvantages of SPI-based:

[0033] High hardware cost: SPI communication needs the support of hardware interface, so the hardware cost is high, not suitable for low-cost communication scene. Short transmission distance: SPI communication has a short transmission distance, not suitable for long-distance communication scenarios. Complex interface: The interface of SPI communication is complex, and it requires high technical level to develop and debug.

[0034] Advantages of PCIe-based:

[0035] Fast transmission speed: PCIe bus has fast speed and large transmission bandwidth, suitable for high-speed data transmission. High reliability: PCIe bus is stable and reliable, not easy to appear deadlock and competition and other problems. Support hot plug: PCIe bus supports hot plug, convenient for hardware addition and replacement.

[0036] Disadvantages of PCIe-based:

[0037] High hardware cost: PCIe bus needs special hardware support, so the hardware cost is high, not suitable for low-cost communication scene. Transmission distance limit: The transmission distance of PCIe bus is limited, not suitable for long-distance communication scenarios. Complex interface: The interface of PCIe bus is complex, and it requires high technical level to develop and debug.

[0038] Advantages of shared memory-based:

[0039] Fast speed: Shared memory is shared between different processes in the same physical memory, so the access speed is fast, suitable for large data communication scenarios. Simple and easy to use: The implementation of shared memory is relatively simple, and the communication interface is easy to write and debug. High reliability: Shared memory access is managed by the operating system, which can ensure the correctness and synchronization of data.

[0040] Disadvantages of shared memory-based:

[0041] Poor real-time performance: Since the access of shared memory is managed by the operating system, the real-time performance is poor, and it is not suitable for communication scenarios with high real-time requirements. Easy to compete: Since multiple processes can access shared memory at the same time, it is easy to cause competition and deadlock problems, and corresponding synchronization and mutual exclusion processing is required. Poor security: The access of shared memory is unrestricted, and it is easy to be used by malicious programs or attackers for illegal operations.

[0042] The above three physical communication links for inter-core communication have their own advantages and application scenarios. Application developers can choose the more suitable communication method according to their own needs, and access the API and SDK of this method. However, sometimes application developers need to use multiple inter-core communications at the same time to meet the diverse needs of users, or the underlying developers of inter-core communication functions need to provide different inter-core communications for different application developers. In this case, it is not efficient and convenient to implement and provide a set of API and SDK for each communication method. And if a new inter-core communication mechanism is added later, a new set of API and SDK must be implemented and maintained, which is not strong in maintainability and scalability.

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

[0044] The inter-core communication method, device and medium, electronic equipment and multi-core system of the embodiments of the present application are described below with reference to the accompanying drawings, wherein the same or similar reference signs represent the same or similar elements or elements with the same or similar functions throughout. The embodiments described with reference to the accompanying drawings are exemplary and should not be understood as limiting the present application.

[0045] FIG. 1 is a flowchart of an inter-core communication method according to an embodiment of the present application.

[0046] In the embodiments of the present application, the 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 can be heterogeneous or homogeneous, and the operating systems running on the CPU cores can also be different. The system with multiple CPU cores can include one chip or multiple chips. Moreover, at least one of the CPU cores in the system with multiple CPU cores, except the first CPU core, is a preset second CPU core.

[0047] As shown in FIG. 1, the inter-core communication method includes:

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

[0049] Specifically, a plurality of local applications are arranged on the first CPU core, and different local applications can need to communicate with different CPU cores in order to run. In order to realize communication between different CPU cores, the first CPU core needs to determine the second CPU core that can communicate in advance, and for each application, determine the second CPU core that needs to communicate in order to run the application, and then make an appointment with the second CPU core to determine the data id when the first CPU core communicates with the second CPU core when running the application. Through the appointment, the data id sent between the two CPU cores matches each other.

[0050] The above data id corresponds to a local application, and different local applications use different data ids to communicate with the corresponding second CPU core. One local application can correspond to one data id, and can also correspond to multiple data ids.

[0051] Since the data id is predetermined, the first CPU core can tell the target second CPU core the local application to be run currently through the data id, so that the target second CPU core can determine the function to be implemented based on the application to be run and provide feedback data, thereby ensuring the stability and accuracy of communication. Moreover, by appointing the data id, when the target second CPU core sends feedback data to the first CPU core, the data id can be sent first, so that the first CPU core can determine the sender of the received data based on the data id, and the security of the received data can be ensured.

[0052] The above data id will be described below in conjunction with a specific example.

[0053] In this example, the data id includes three parts, and the three parts are respectively recorded as Priority, GroupId and ElementId, wherein the size of Priority is 4 bits, the size of GroupId is 12 bits, and the size of ElementId is 16 bits. At this time, the data id is an uint32 integer.

[0054] 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 that a data id is 0x30010001, the Priority of the data id is 3, the GroupId is 1, and the ElementId is 1.

[0055] Among them, the first 4 bits of the data id are used as the priority to identify the data priority.

[0056] The middle 12 bits are used as a GroupId, which is used to distinguish data ids of different applications. Different applications use different GroupIds to distinguish. That is, in this example, the data id corresponds to a local application, and the local application corresponds to the GroupId in the data id.

[0057] The last 16 bits are used as a unique id of the same group data. The 16 bits support a maximum of 65535 ElementIds for the same group of GroupIds. The same group data refers to data with the same GroupId.

[0058] After the agreement with each second CPU core is completed, the first CPU core can select a first target application from the local applications to work. As an example, the first CPU core can determine the current function to be implemented and determine the local application for implementing the current function to be implemented as the first target application.

[0059] S12, according to the first target application, selects a first data id from a plurality of preset data ids, and according to the first target application, selects a target second CPU core from one or more preset second CPU cores.

[0060] 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 the first data id corresponding to the first target application, and since different local applications use different data ids to communicate with the corresponding second CPU core, the first CPU core can also select the target second CPU core corresponding to the first target application.

[0061] S13, according to the first data id, generates a first byte stream data, and sends 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.

[0062] The following describes the sending of byte stream data between two CPU cores in conjunction with the specific embodiment shown in FIG. 2.

[0063] Specifically, the overall system architecture design used to send byte stream data shown in FIG. 2 is composed of two parts, including ZBUS Lib and ZBUS DAEMON.

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

[0065] ZBUSDAEMON is a daemon process that is mainly used to encapsulate various inter-core communication functions and provide services for ZBUS Lib. It is mainly a ZBUS MANAGER, which mainly contains an IPC component and a BUS WRAPPER class instance. The BUS WRAPPER class is an abstract parent class that defines a set of common interface definitions for SPI, PCie, shared memory, and other inter-core communication operations. The instance subclasses SPI_BUS_WRAPPER, PCIE_BUS_WRAPPER, and SHM_BUS_WRAPPER under it inherit the parent class BUS WRAPPER and implement their respective inter-core communication functions. These specific instance classes perform data transmission and communication with the respective underlying communication links through the HAL layer library provided by the BSP developer. The HAL layer provides related drivers for operating the underlying hardware communication link and provides respective interfaces for the upper WRAPPER layer, facilitating user use of the functions. The HAL layer includes SPI_HAL, SHM_IPCF_HAL, and PCIE_HAL, which correspond to the SPI, Shared Memory, and PCie physical communication links, respectively. ZBUSDAEMON provides which inter-core communication to the user is mainly specified by the configuration file. If the configuration file is set to Shared Memory, the process will provide an inter-core communication mechanism based on shared memory, and the user can configure it according to their own scenario.

[0066] When using the inter-core communication method of the present application, the inter-core communication method needs to be configured in the configuration file of ZBUSDAEMON, and the process needs to be deployed and started. Then, the user's application can be connected to ZBUS Lib to use the inter-core communication service provided by ZBUSDAEMON.

[0067] The key class diagram of ZBUS Lib can be seen from the example shown in FIG. 3. In FIG. 3, the key data and functions are listed, and the function parameters and types are omitted.

[0068] Specifically, ZBUS Lib is mainly composed of Zbus and ZbusIpc classes. The Init() functions in Zbus and ZbusIpc are used to initialize the IPC instance.

[0069] Create() is a function for creating zbus (i.e. the inter-core communication method of the present application) instance.

[0070] SetIdentify() is a function for setting data_group_id_ (i.e. the above-mentioned GroupId), and the GroupId of different types of APPs is different.

[0071] SetDataArrivedCallback() is a function for setting data_available_cb_ (i.e. the above-mentioned callback function).

[0072] GetData() and PostData() are functions for calling MethodCall() in ZbusIpc.

[0073] zbus_Ipc_ is an instance of the class ZbusIpc, and the two are in a composition relationship. It is an encapsulation of an IPC middleware, and its underlying layer is iceoryx, which provides the capability of in-domain communication between vehicle system boards. Iceoryx is a process intercommunication based on shared memory. This component can be replaced by other IPC components with similar functions.

[0074] The main role of this IPC instance is to provide the capability of in-domain communication with the ZBUSDaemon process. The ZBUSDaemon process also contains an IPC instance, which forms a pair of communication ends with the IPC instance of the ZBUS Lib. In the ZbusIpc class, five key functions are listed.

[0075] Publish() realizes message publishing, and is mainly used for ZBUSDaemon to notify ZBUS Lib that the data of the GroupId it subscribes has arrived.

[0076] MethodCall() is a function for calling the Getdata() function and the PostData() function in the opposite end ZBUSDaemon, and thus realizes the GetData (data extraction) and PostData (submit data) functions of the API.

[0077] Subscribe() realizes the function of message subscription, and is mainly used for ZBUS Lib to subscribe the data id of the GroupId corresponding to the APP in ZBUSDaemon. The main goal of the cooperation of Subscribe() and Publish() functions is to trigger the callback function data_available_cb_ set by SetDataArrivedCallback.

[0078] UnSubscribe() is used to cancel the subscription of APP corresponding to the data id of GroupId, which is automatically called by ZBUS Lib at the end of the whole program.

[0079] The design and implementation of ZBUSDaemon can be seen from the example shown in FIG. 4. Similarly, in FIG. 4, key data and functions are listed, and function parameters and types are omitted.

[0080] Specifically, ZBUSDaemon is mainly composed of three key class diagrams, including ZbusManager class (i.e. ZBUS_MANAGER in FIG. 2), ZbusIpc class (i.e. IPC in FIG. 2) and IBusWrapper class (i.e. BUS_WRAPPER in FIG. 2). IBusWrapper class is an abstract class, which uses the polymorphism and inheritance idea of c++, the parent class abstracts a set of public interfaces for data sending and receiving, and multiple child classes ShmBusWrapper (i.e. SHM_BUS_WRAPPER in FIG. 2), PCieBusWrapper (i.e. PCIE_BUS_WRAPPER in FIG. 2), SpiBusWrapper (i.e. SPI_BUS_WRAPPER in FIG. 2) implement their own inter-core communication according to their own mechanism. If new inter-core communication methods are needed in the future, the abstract class can be inherited and implemented, such as XxxxxxWrapper class in FIG. 4. Therefore, the inter-core communication method of the present application has good expansibility and maintainability.

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

[0082] ZbusManager class is the management class of the whole ZBUSDaemon. Its role is to communicate with ZBUS Lib and manage inter-core communication methods. It mainly contains two members zbus_ipc_ and bus_wrapper_. zbus_ipc_ is an instance of ZbusIpc class, which is similar to zbus_ipc_ in ZBUS Lib, and is an IPC instance for ZBUSDaemon to communicate with ZBUS Lib. In the ZBUSDaemon end, the Publish function of IPC communication is mainly used to notify the opposite ZBUS Lib that the data of a certain GroupId subscribed by it is available.

[0083] The member of bus_wrapper_ of ZbusManager is a pointer to the parent class IBusWrapper, and its actual instance is one of the child classes ShmBusWrapper, PCieWrapper, SpiBusWrapper, and the specific one is related to the inter-core communication mode specified in the configuration file. For example, if the inter-core communication mode is Shm, the inter-core communication communication mode based on shared memory is adopted, if the configuration is PCie, the inter-core communication mode based on PCie bus is adopted, and if the configuration is SPI, the inter-core communication mode based on SPI bus is adopted. This class mainly includes 5 functions, the Init() function is mainly used to initialize zbus when ZBUSDaemon starts, for example, calling the LoadZbusParamFromJson() function to load the configuration file to specify the specific child class for the bus_wrapper_ member to select the specific inter-core communication mode, and to initialize the IPC member zbus_Ipc_. GetData(), PostData() can refer to the corresponding functions in the above ZbusIpc class. OnDataAvailable() is used to execute the callback function.

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

[0085] The IBusWrapper class mainly abstracts three interfaces, which mainly define three main operations of inter-core communication. The first is the initialization of resources relied on by inter-core communication, represented by the BusInit() interface. The second is sending data to the target core, represented by the BusWrite() interface, and the third is receiving data from the target core, represented by the BusRead() interface. The IBusWrapper abstracts and unifies the interfaces of different inter-core communication mechanisms, and their subclasses implement these basic operation interfaces. Take one of the subclasses, ShmBusWrapper, as an example, which mainly includes a data_cache_ member and an on_data_available_cb_ member. The data_cache_ is a data cache module used to cache the data received by ShmBusWrapper from the opposite core through the SHM_IPCf_HAL layer. The other member on_data_available_cb_ is the OnDataAvailable member function of ZbusManager set when BusInit() is called by ZbusManager. In this way, when the SHM_IPCf_HAL layer receives data, it will update the cache data_cache_ and trigger the on_data_available_cb_ call. The BusRead() interface implementation of ShmBusWrapper is to directly read data from the data_cache_ cache. The BusWrite() interface implementation of ShmBusWrapper is to directly call the data sending implementation of SHM_IPCf_HAL to send data.

[0086] The difference between the PCieWrapper class and the SpiBusWrapper class and the ShmBusWrapper class is that they implement BusInit(), BusWrite(), and BusRead() interfaces in different HAL layers and call different HAL layers in different ways.

[0087] 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 according to a preset operation mode through a target inter-core communication mode, wherein the target inter-core communication mode is an inter-core communication mode selected from a plurality of preset inter-core communication modes, and the preset operation mode is an operation mode common to the plurality of preset inter-core communication modes.

[0088] If the above examples are described, the above multiple preset inter-core communication modes include the above SPI, PCie, shared memory and other inter-core communication modes, the target inter-core communication mode is the inter-core communication mode specified by the configuration file, and the preset operation mode includes operations of three interfaces of the parent class IBusWrapper abstraction: BusInit(), BusWrite(), and BusRead(). That is, no matter which inter-core communication mode is specified according to the configuration file, the first byte stream data can be sent to the target second CPU core through the target inter-core communication mode through the preset operation mode.

[0089] Therefore, in order to realize the sending of 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 the preset operation mode.

[0090] S14, 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.

[0091] 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 according to the second data id. According to the design, if the first CPU core receives multiple data ids, the second data id needs to be determined from the multiple data ids, the feedback data corresponding to the second data id is determined as the feedback data required by the first target application, and then the feedback data corresponding to the second data id is received.

[0092] Thus, the first target application is selected from the local applications, the first data id is selected from the plurality of preset data ids according to the first target application, and the target second CPU core is selected from the one or more preset second CPU cores according to the first target application; the 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 the second data id and the feedback data based on the first byte stream data; the second data id fed back by the target second CPU core is received, the 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 used for communication and the second CPU core for communication both correspond to the local application, the first data id and the target second CPU core used in actual communication can be determined according to the first target application after the first target application is determined, and communication is performed through the first data id and the target second CPU core. Since the data id and the second CPU core are used for communication, the standardized processing of the communication information between the first CPU core and the second CPU core can be realized, thereby supporting the general API, providing a unified inter-core communication interface for the upper-layer user, that is, a set of API and SDK, greatly facilitating the use of the upper-layer development user, thereby realizing convenient inter-core communication, and having high maintainability and expansibility.

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

[0094] The following is described with a specific example.

[0095] Specifically, in this example, one data id corresponds to one data structure of c language, and the data structure is used to carry data, as follows:

[0096] The above program means that the data id 0x30010001 corresponds to the data structure IntenalNodeOnline, and the data structure IntenalNodeOnline internally nests another data structure IntenalNodeEnum. When transmitting data through inter-core communication, the IntenalNodeOnline data is obtained and sent according to the data id 0x30010001 in the API for receiving and sending data. The data id is identified by the macro ZKOS_ZBUS_DID_NM_IntenalNodeOnline of c language, and the specific value of the macro is the hexadecimal number 0x30010001.

[0097] That is to say, after determining the first data id, the general 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.

[0098] The above general API will be described below in combination with a specific example.

[0099] Specifically, the ZBUS Lib provides six interface functions, i.e., function one, function two, function three, function four, function five and function six, which are respectively:

[0100] Function one: static std::shared_ptr <zbus>Zbus::Create().

[0101] Function two: bool Zbus::Init().

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

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

[0104] Function five: int Zbus::PostData(uint32_t data_id, void*buffer, uint32_t size).

[0105] Function six: using OnDataAvailable = std::function<void(uint32_t id)>.

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

[0107] Among them, function one is used to: construct a new zbus instance and return its pointer. That is, the user needs to use this interface to obtain a zbus instance before using the other five interface functions.

[0108] Function two is used to: load zbus related configuration and initialize zbus function, mainly load IPC configuration file, then initialize IPC component, used for cross process communication between IPC and ZBUSDAEMON.

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

[0110] Function four is used to read the byte stream data of the data structure corresponding to the data id from the ZBUS DAEMON into the preset buffer, and size is the space size of the preset buffer, which needs to be greater than or equal to the byte size of the data structure corresponding to the data id. The function returns 0 to indicate success, and a non-0 value indicates failure.

[0111] Function five is used to send the byte stream data of the data structure corresponding to the data id in the preset buffer with a size of size to the opposite CPU core through the ZBUS DAEMON. The size needs to be greater than or equal to the byte size of the data structure corresponding to the data id. The function returns 0 to indicate success, and a non-0 value indicates failure.

[0112] Function six is used to register the callback function of the opposite ZBUS DAEMON data arrival by the function, and when the opposite data is updated and available, the corresponding logic of the data id is processed in the callback function registered by the user. The user sets the function of the type OnDataAvailable named cb 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, and cb is a callback function of the type OnDataAvailable. SetDataArrivedCallback registers the cb function. The cb callback function is written by the user, and the user can write the corresponding logic of the data id, but needs to be registered through SetDataArrivedCallback.

[0113] It should be noted that for the above function four and function five, a data structure according to the data id also needs to be set, for example, through a preset setting, so that when the above data id 0x30010001 is received, the corresponding data structure IntenalNodeOnline is obtained and sent. The above function four and function five are general APIs.

[0114] In some embodiments of the present application, when the first CPU core receives the second byte stream data sent by the third CPU core, the method further comprises: selecting a second target application from the local applications according to the second byte stream data; generating transmission data according to the second target application, and selecting a fourth data id from the plurality of preset data ids according to the second target application, generating third byte stream data according to 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 comprises: sending the transmission data and the third byte stream data to the third CPU core through a target inter-core communication mode according to a preset operation mode, wherein the target inter-core communication mode is an inter-core communication mode selected from a plurality of preset inter-core communication modes, and the preset operation mode is an operation mode common to the plurality of preset inter-core communication modes.

[0115] Specifically, the first CPU core can also be a CPU core that other CPU cores communicate with after determining their own functions to be implemented, and the other CPU core that determines its own function to be implemented is recorded as the third CPU core. That is to say, after the third CPU core confirms its own function to be implemented, it determines the application for implementing the function to be implemented, and determines that it needs to communicate with the first CPU core in order to implement the function to be implemented, and then the third CPU core generates second byte stream data according to the data id corresponding to the application, and sends the second byte stream data to the first CPU core. At this time, after the first CPU core receives the second byte stream data sent by the third CPU core, it can obtain the corresponding data id according to the second byte stream data, and since the data id corresponds to the application, it can determine the second target application in the local application for responding to the third CPU core according to the second byte stream data, and then can control the second target application to run in a preset manner to obtain a running result, take the running result as feedback data for the third CPU core, generate a fourth data id according to the second target application, generate third byte stream data according to the fourth data id, and send the feedback data for the third CPU core and the third byte stream data 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.

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

[0117] Specifically, the first CPU core needs to check the shared memory, and 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 a third data id.

[0118] Moreover, since there can be multiple third data ids 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 the feedback data corresponding to the second data id. The method of 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 take the third data id that matches the first data id successfully as the second data id.

[0119] In some embodiments of the present application, 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, and 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.

[0120] 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.

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

[0122] That is to say, the first CPU core needs to check the shared memory, if there is shared data in the shared memory, it is judged 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 a 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, it is determined that the third data id is a valid data id.

[0123] The above embodiments are described below in combination with a specific example shown in FIG. 5. In FIG. 5, the ZbusWrapper class is the SHM_BUS_WRAPPER described above, the ipcfHAL library is the SHM_IPCF_HAL described above, and the operating system kernel can be a Linux kernel. In FIG. 5, the functions used are as follows:

[0124] Init(), which means initialization;

[0125] SetDataArrivedCallback(OnDataAvailable), which means setting a callback function;

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

[0127] BusInit(protocol, OnDataAvailable), which means initializing and passing in a callback function;

[0128] Return, which means returning an operation result;

[0129] ShmInit(OnMsgAvailableCb), which means shared memory initialization and passing in a callback function;

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

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

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

[0133] UpdateDataCache, which means updating a data cache data_cache_;

[0134] OnDataAvailable(msq_id), means to execute the callback function after the data cache is updated;

[0135] Ipc.Publish(topic_name, data), means to publish data id;

[0136] OnDataAvailable(msq_id), means to execute the callback function;

[0137] GetData(data_id, buffer, size), means to get data operation;

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

[0139] BusRead(data_id, buffer, size, mode), means to read data cache;

[0140] PostData(data_id, buffer, size), means to send data operation;

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

[0142] BusWrite(data_id, buffer, size, mode), means to write data;

[0143] ShmMqSend(msqid, msgp, msgsz, msgflg), means to send data in shared memory queue.

[0144] Flow 1 is the initialization, which shows the initialization process after the APP using ZBUS Lib and ZBUS Daemon are started. It mainly includes two end configuration loading, IPC initialization, setting GroupId, data subscription and registration of GroupId callback function. APP wants to use zbus function service, ZBUS Daemon needs to start before APP.

[0145] Specifically, the APP first performs function control for initialization, and sets a callback function, and the ZBUS Lib sends a subscription data id, which is the first data id described above. After the ZbusManager class receives the subscription data id, it controls for initialization and passes in the callback function. After the ZbusWrapper class receives the callback function, it performs shared memory initialization and passes in the callback function to SHM_IPCF_HAL. Moreover, the ZbusWrapper class also needs to obtain shared memory, determine whether shared data exists in the shared memory, and return the acquisition result to the ZbusManager class.

[0146] Flow 2 is a data available notification, which shows that when the core data of the opposite end is available, the Linux Kernel triggers an interrupt, the ZBUS Daemon obtains data from the shared memory of the SHM_IPCF_HAL layer to the ZBUS Daemon of the local core, and updates the data to the data_cache_ cache, and publishes the arrival notification of the data to the APP through the IPC. Only the APP with the same GroupId as the GroupId of the data will receive it, thereby triggering the callback function of the data available registered by the APP.

[0147] Specifically, if the ZbusWrapper class determines that data exists in the shared memory, it executes the callback function, receives the data in the shared memory, and caches the received data to data_cache_. At this time, the ZbusManager class executes the callback function to obtain the published data id, which is the second data id described above. Since multiple data ids may exist in the shared memory, it is necessary to compare the GroupId in the data id in the shared memory with the GroupId of the first data id. If the GroupId of a certain data id is consistent with the GroupId of the first data id, it is determined that the data id is valid.

[0148] Flow 3 is data acquisition, which shows the process of the APP acquiring data. By calling function four in the above general API, the user data is obtained from the cache of the ZBUS Daemon through the IPC of the ZBUS Lib.

[0149] Specifically, the APP calls function four in the above general API to perform data acquisition operation. According to the operation, the ZBUS Lib obtains user data from data_cache_ through the ZbusManager class. The user data is the feedback data described above.

[0150] Flow 4 is data sending, which shows the flow of APP sending data, by calling function five in the above general API, with the help of ZBUS Lib IPC to transmit data to ZBUS Daemon, and ZBUS Daemon finally calls ShmMqSend of SHM_IPCF_HAL to send to shared memory and notify the opposite end core.

[0151] Specifically, APP calls function five in the above general API to execute the data sending operation, and ZBUS Lib sends data to the ZbusManager class according to the operation. After receiving the data, the ZbusManager class writes the data into the shared memory through the ZbusWrapper class.

[0152] Among them, the HAL layer SHM_IPCf_HAL of ShmBusWrapper provides a shared memory data link, and four key interface functions exist in the data operation interface provided by the shared memory data link, which are function seven, function eight, function nine and function ten.

[0153] Function seven: bool ShmInit(ShmOnDataAvailable callback).

[0154] Function eight: int ShmMqGet(uint8_t key, uint32_t size, int msgflg).

[0155] Function nine: int ShmMqRecv(int msqid, void*msgp, uint32_t msgsz, enum ShmFlag msgflg).

[0156] Function ten: int ShmMqSend(int msqid, const void*msgp, uint32_t msgsz, enum ShmFlag msgflg).

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

[0158] Function eight is used to: get a queue of shared memory with a node size of size bytes, which is used to receive and send data. The return value is the queue id, and the specific value of the queue id is msqid.

[0159] Function nine is used to: get the head node data of the queue from the shared memory with queue id msqid.

[0160] The function ten is used to insert node data to the tail of the shared memory with the queue id msqid.

[0161] In summary, the inter-core communication method of the embodiment of the application sets the first target application from the local application; selects the first data id from the plurality of preset data ids according to the first target application, and selects the target second CPU core from the one or more preset second CPU cores according to the first target application; generates the first byte stream data according to the first data id, and sends the first byte stream data to the target second CPU core, so that the target second CPU core generates the second data id and the feedback data based on the first byte stream data; receives the second data id fed back by the target second CPU core, and receives the feedback data fed back by the target second CPU core according to the second data id, and controls the first target application to run based on the feedback data. Since the data id used for communication and the second CPU core for communication both correspond to the local application, the first data id and the target second CPU core used in actual communication can be determined according to the first target application after the first target application is determined, and communication is performed through the first data id and the target second CPU core. Since the data id and the second CPU core are used for communication, the standardized processing of the communication information between the first CPU core and the second CPU core can be realized, thereby supporting the setting of a general API and providing a unified inter-core communication interface for the upper-layer user, that is, a set of API and SDK, which greatly facilitates the use of the upper-layer development user. Moreover, different underlying transmission communication links and mechanisms (such as shared memory, SPI physical bus, etc.) are adapted, the user can select different communication links according to different scenes, and the newly added inter-core communication mechanism can be supported in subsequent expansion, and the usage mode remains unchanged, which has strong expansibility and maintainability. The underlying link resources and operating system resources relied on by the data transmission and reception are uniformly managed, which is transparent to the user, guarantees the safety and orderliness of the system, improves the robustness of the entire system, avoids the user directly illegally operating the underlying resources, and guarantees the safety and stability of the system.

[0162] Based on the inter-core communication method of the above embodiment, the application provides a computer readable storage medium.

[0163] In the embodiment of the application, the computer readable storage medium has a computer program stored thereon, and the computer program is executed by a processor to implement the inter-core communication method.

[0164] The computer readable storage medium of the embodiment of the application, by implementing the inter-core communication method of the above embodiment, sets the data id for communication and the second CPU core for communication, both of which correspond to the local application, so that after determining the first target application, the first data id of the actual communication application and the target second CPU core are determined according to the first target application, and communication is performed through the first data id and the target second CPU core. Since the data id and the second CPU core are used for communication, the standardized processing of the communication information between the first CPU core and the second CPU core can be realized, thereby supporting the setting of a general API and providing a unified inter-core communication interface for the upper layer user, that is, a set of API and SDK, which greatly facilitates the use of the upper layer development user.

[0165] Based on the inter-core communication method of the above embodiment, the application further provides an electronic device.

[0166] FIG. 6 is a structural block diagram of an electronic device according to an embodiment of the application.

[0167] As shown in FIG. 6, the electronic device 500 includes a processor 501 and a memory 503. The processor 501 and the memory 503 are connected, for example, through a bus 502. Optionally, the electronic device 500 can further include a transceiver 504. It should be noted that in actual applications, the transceiver 504 is not limited to one, and the structure of the electronic device 500 does not constitute a limitation on the embodiments of the application.

[0168] The processor 501 can be a CPU (Central Processing Unit, central processor), a general-purpose processor, a DSP (Digital Signal Processor, digital signal processor), an ASIC (Application Specific Integrated Circuit, application specific integrated circuit), an FPGA (Field Programmable Gate Array, field programmable gate array) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. It can implement or execute various exemplary logical blocks, modules and circuits described in combination with the disclosure of the application. The processor 501 can also be a combination of computing functions, such as one or more microprocessor combinations, combinations of DSP and microprocessor, etc.

[0169] The bus 502 can include a path for transmitting information between the above-mentioned components. The bus 502 can be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. The bus 502 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one thick line is shown in FIG. 5, but it does not mean that there is only one bus or only one type of bus.

[0170] The memory 503 is configured to store a computer program corresponding to the inter-core communication method of the embodiments of the present application, and the processor 501 is configured to execute the computer program stored in the memory 503 to implement the contents shown in the foregoing method embodiments.

[0171] The electronic device 500 shown in FIG. 6 is only an example, and should not bring any limitation to the functions and use range of the embodiments of the present application.

[0172] The electronic device of the embodiments of the present application, by implementing the inter-core communication method of the above-mentioned embodiments, sets the data id for communication and the second CPU core for communication to correspond to the local application, so that after determining the first target application, the first data id and the target second CPU core of the application in actual communication are determined according to the first target application, and communication is performed through the first data id and the target second CPU core. Since the data id and the second CPU core are used for communication, the standardized processing of the communication information between the first CPU core and the second CPU core can be realized, thereby supporting the setting of a general API and providing a unified inter-core communication interface for the upper-layer user, that is, a set of API and SDK, which greatly facilitates the use of the upper-layer development user.

[0173] The present application also provides an inter-core communication device.

[0174] FIG. 7 is a structural block diagram of the inter-core communication device of the embodiments of the present application.

[0175] As shown in FIG. 7, the inter-core communication apparatus 700 includes: a selecting module 701 configured to select a first target application from local applications, and 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 702 configured to generate first byte stream data according to the first data id; a sending module 703 configured 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 configured to 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 a controlling module 705 configured to control the first target application to run based on the feedback data.

[0176] In some embodiments of the present application, the first target application is selected from the local applications, including: determining a current function to be implemented, and determining a local application for implementing the current function to be implemented as the first target application.

[0177] In some embodiments of the present application, the first byte stream data is generated according to the first data id, including: obtaining a data structure corresponding to the first data id according to a preset correspondence relationship, and generating the first byte stream data according to the data structure, wherein the preset correspondence relationship includes a correspondence relationship between a plurality of data ids and a plurality of data structures.

[0178] In some embodiments of the present application, the communication mode between the first CPU core and the target second CPU core is a shared memory-based communication mode, and the second data id fed back by the target second CPU core is received, including: checking whether a third data id exists in the shared memory; if the third data id exists in the shared memory, determining the second data id according to the third data id; and receiving the second data id.

[0179] In some embodiments of the present application, the first data id and the third data id both include a group id, and the second data id is determined according to the third data id, including: comparing the group id of the third data id with the group id of the first data id, and if the group id of the third data id is consistent with the group id of the first data id, determining that the third data id is the second data id.

[0180] In some embodiments of the present application, when the first CPU core receives the second byte stream data sent by the third CPU core, the method further comprises: selecting a second target application from the local applications according to the second byte stream data; generating transmission data according to the second target application, selecting a fourth data id from the plurality of preset data ids according to the second target application, generating third byte stream data according to 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 comprises: 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 the plurality of preset inter-core communication modes, and the preset operation mode is an operation mode common to the plurality of preset inter-core communication modes.

[0181] It should be noted that other specific implementations of the inter-core communication device of the embodiments of the present application can refer to the inter-core communication method of the above-mentioned embodiments.

[0182] The inter-core communication device of the embodiments of the present application sets the data id for communication and the second CPU core for communication to correspond to the local application, so that after determining the first target application, the first data id and the target second CPU core used in actual communication can be determined according to the first target application, and communication is performed through the first data id and the target second CPU core. Since the data id and the second CPU core are used for communication, standardized processing of communication information between the first CPU core and the second CPU core can be realized, thereby supporting the setting of a general API and providing a unified inter-core communication interface for the upper-layer user, i.e., a set of API and SDK, which greatly facilitates the use of the upper-layer development user.

[0183] The present application also proposes a multi-core system.

[0184] FIG. 8 is a structural block diagram of a multi-core system according to an embodiment of the present application.

[0185] As shown in FIG. 8, the multi-core system 800 includes a plurality of CPU cores 801, and for any one of the plurality of CPU cores 801, the electronic device 500 of the above-mentioned embodiments is included.

[0186] The multi-core system of the embodiment of the present application sets the data id for communication and the second CPU core for communication to correspond to the local application, so that after the first target application is determined, the first data id of the application in actual communication and the target second CPU core are determined according to the first target application, and communication is performed through the first data id and the target second CPU core. Since the data id and the second CPU core are used for communication, the standardized processing of the communication information between the first CPU core and the second CPU core can be realized, thereby supporting the setting of a general API and providing a unified inter-core communication interface for the upper-layer user, that is, a set of API and SDK, which greatly facilitates the use of the upper-layer development user.

[0187] It is noted that the logic and / or steps represented in the flowcharts or otherwise described herein can be considered as a list of executable instructions for implementing logic functions, which can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor- based system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions, or in conjunction with such an instruction execution system, apparatus, or device. For the purposes of this specification, a "computer-readable medium" can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device or in conjunction with such an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of the computer-readable medium include the following: an electrical connection having one or more wires (electrical apparatus), a portable computer diskette (magnetic apparatus), a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber (optical apparatus), and a portable compact disc read-only memory (CDROM). In addition, the computer-readable medium can even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, for example, by optically scanning the paper or other suitable medium, then electronically converted into a form that is suitable for use by or in connection with the instruction execution system, apparatus, or device, and stored in the computer memory.

[0188] It should be understood that portions of the present application can be realized with hardware, software, firmware or a combination thereof. In the above-described embodiments, a plurality of steps or methods can be realized with software or firmware stored in a memory and executed by a suitable instruction execution system. If realized with hardware, and as in another embodiment, any one or a combination of the following technologies known in the art can be used: discrete logic circuit having logic gates for implementing logic functions on data signals, application specific integrated circuit having suitable combination logic gates, programmable gate array (PGA), field programmable gate array (FPGA), etc.

[0189] In the description of the specification, the description of the terms "one embodiment", "some embodiments", "an example", "a specific example", or "some examples" etc. means that the specific features, structures, materials or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present application. In the description of the specification, the illustrative description of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner.

[0190] In the description of the specification, the orientation or positional relationship indicated by the terms "center", "longitudinal", "transverse", "length", "width", "thickness", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", "clockwise", "counterclockwise", "axial", "radial", "circumferential" and the like is based on the orientation or positional relationship shown in the drawings, and does not indicate or imply that the device or element referred to must have a particular orientation, be constructed and operated in a particular orientation, and cannot be understood as a limitation of the present application.

[0191] In addition, the terms "first", "second" are only for descriptive purposes and cannot be understood as indicating or implying relative importance or implicitly indicating the number of the technical features indicated. Therefore, the features defined as "first", "second" can explicitly or implicitly include at least one of the features. In the description of the present application, the meaning of "a plurality of" is at least two, for example, two, three, etc., unless otherwise specifically limited.

[0192] In the description of the specification, unless otherwise specified, the terms "mounting", "connecting", "connecting", "fixing" and the like should be broadly understood, for example, it can be fixedly connected, or it can be detachably connected, or it can be integrated; it can be mechanically connected, or it can be electrically connected; it can be directly connected, or it can be indirectly connected through an intermediate medium; it can be the internal communication of two elements or the interaction relationship between two elements, unless otherwise explicitly limited. For those skilled in the art, the specific meaning of the above terms in the present application can be understood according to the specific circumstances.

[0193] In the present application, unless otherwise specifically specified and limited, the first feature is "on" or "under" the second feature can be that the first and second features are in direct contact, or the first and second features are in indirect contact through an intermediate medium. Moreover, the first feature "above", "over" and "on" the second feature can be that the first feature is directly above or obliquely above the second feature, or only indicates that the horizontal height of the first feature is higher than that of the second feature. The first feature "below", "under" and "under" the second feature can be that the first feature is directly below or obliquely below the second feature, or only indicates that the horizontal height of the first feature is less than that of the second feature.

[0194] Although the embodiments of the present application have been shown and described above, it is understood that the above-described embodiments are exemplary and are not to be construed as limiting the present application, and that changes, modifications, substitutions and variations can be made by those skilled in the art without departing from the scope of the present application.< / zbus>

Claims

1. A method for inter-core communication, characterized in that, The method is used for a first CPU core, and the method includes: Select the first target application from local applications; The 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 based on 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; The system receives a second data ID from the target second CPU core, receives feedback data from the target second CPU core based on the second data ID, and controls the first target application to run based on the feedback data.

2. The inter-nuclear communication method according to claim 1, characterized in that, The step of selecting the first target application from local applications includes: Identify 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.

3. The inter-nuclear communication method according to claim 1, characterized in that, The step of generating the first byte stream data based on the first data ID includes: A data structure corresponding to the first data ID is obtained according to a preset correspondence relationship, wherein the preset correspondence relationship includes the correspondence relationship between multiple data IDs and multiple data structures; The first byte stream data is generated according to the data structure.

4. The inter-nuclear communication method according to claim 1, characterized in that, The communication method between the first CPU core and the target second CPU core is a shared memory-based communication method. Receiving the second data ID fed back by the target second CPU core includes: Check if a third data ID exists 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-nuclear communication method according to claim 4, characterized in that, Both the first data ID and the third data ID include a group ID. 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 the same as the group ID of the first data ID, then it is determined that the third data ID and the first data ID are successfully matched.

6. The inter-nuclear 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: Select a second target application from the local application based on the second byte stream data; The transmission data is generated according to the second target application, and a fourth data ID is selected from a plurality of preset data IDs according to the second target application. A third byte stream data is generated according to the fourth data ID, and the transmission data and the third byte stream data are sent to the third CPU core. The step of sending the transmitted 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 the target inter-core communication method according to the preset operation mode. The target inter-core communication method is an inter-core communication method selected from multiple preset inter-core communication methods, and the preset operation mode is a common operation mode of multiple 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 the processor, it implements the inter-core communication method as described in any one of claims 1-6.

8. An electronic device, characterized in that, It includes 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, it implements the inter-core communication method as described in any one of claims 1-6.

9. An inter-nuclear communication device, characterized in that, The device includes: The selection module is used to select a first target application from local applications, select a first data ID from a plurality of 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; The generation module is used to generate the first byte stream data based on the first data id; A sending module 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; The receiving module is used to receive the second data ID fed back by the target second CPU core, and to receive the 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 for any one of the multiple CPU cores, the electronic device as described in claim 8 is included.

Images