Inter-core communication method and device, robot and storage medium

Abstract

The embodiment of the invention provides an inter-core communication method and device, a robot and a storage medium, and the method comprises the steps: responding to a registration request of a first processor of the robot for a to-be-published theme, and determining a data storage space of the to-be-published theme in a shared memory of the robot; the first processor writes target data corresponding to the to-be-published theme into the data storage space to generate a serial number of the to-be-published theme; and a second processor of the robot periodically queries the serial number of the subscribed theme, and obtains data in the subscribed theme under the condition that the serial number of the subscribed theme is updated.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of computer technology, and are related to, but not limited to, an inter-core communication method, device, robot, and storage medium. Background Art

[0002] In multi-core processor systems, multiple processing units work together to improve computing efficiency and response speed. In robotic systems, real-time performance and data synchronization are crucial for task execution. Inter-core communication, a key technology for enabling multi-core collaboration, directly impacts system performance and stability.

[0003] In related technologies, inter-core communication in heterogeneous multi-core processing systems typically relies on the Remote Processor Messaging (RPMsg) protocol as a communication mechanism, combined with the Open Asymmetric Multi-Processing (OpenAMP) framework to support remote processor lifecycle management, resource scheduling, and message transmission. However, in practice, Linux does not support multiple processes simultaneously opening RPMsg mapped devices, making distributed communication impossible and requiring a central process to forward reads and writes.

[0004] Therefore, when faced with high concurrency and low latency communication requirements, related technologies have the problem of low communication efficiency and are unable to meet the high standards of real-time communication required by complex robotic systems. Summary of the Invention

[0005] To solve the problems existing in the related technologies, the embodiments of the present application provide an inter-core communication method, device, robot and storage medium.

[0006] In a first aspect, the present application provides an inter-core communication method, which includes: in response to a registration request for a topic to be published by a first processor of a robot, determining a data storage space for the topic to be published in a shared memory of the robot; the first processor writes target data corresponding to the topic to be published into the data storage space, and generates a serial number for the topic to be published; the second processor of the robot periodically queries the serial number of the subscribed topic, and obtains the data in the subscribed topic when the serial number of the subscribed topic is updated.

[0007] In some embodiments, the shared memory includes a metadata area; the inter-core communication method further includes: the first processor obtains the spin lock of the shared memory and locks the shared memory; correspondingly, determining the data storage space of the to-be-published topic in the shared memory of the robot includes: the first processor traverses the topic information structure of the metadata area based on the topic name of the to-be-published topic to determine the historical registration information of the to-be-published topic; the first processor determines the data storage space in the shared memory based on the historical registration information; correspondingly, after determining the data storage space, the inter-core communication method further includes: the first processor releases the spin lock.

[0008] In some embodiments, the first processor determines the data storage space in the shared memory based on the historical registration information, including: in response to the historical registration message indicating that the to-be-published topic does not exist in the shared memory, the first processor registers the to-be-published topic based on the number of topics in the shared memory, and determines the topic index of the to-be-published topic and the data storage space; the data storage space is an unused area in the shared memory; in response to the historical registration message indicating that the to-be-published topic exists in the shared memory, the first processor determines the data area corresponding to the to-be-published topic in the shared memory as the data storage space.

[0009] In some embodiments, after the topic to be published is registered, the inter-core communication method further includes: the first processor updates the field information of the topic to be published in the topic information structure, and the field information includes at least the topic valid identifier, topic name, topic name length and topic name string; the first processor updates the storage area information of the data storage space corresponding to the topic to be published; the storage area information includes at least the starting offset of the data storage space in the shared memory, the number of data blocks and the size of each data block.

[0010] In some embodiments, the shared memory also includes a storage area; the first processor writes the target data corresponding to the topic to be published into the data storage space to generate a serial number of the topic to be published, including: the first processor performs an atomic self-increment operation on the storage index of the data storage space to obtain an update index of the data storage space; the first processor obtains the data block corresponding to the update index in the storage area and the read-write lock corresponding to the data block based on the update index of the data storage space; the first processor writes the target data corresponding to the topic to be published into the data block corresponding to the update index in a byte-aligned manner to generate a serial number of the topic to be published.

[0011] In some embodiments, the shared memory also includes an event notification area; before generating the serial number of the topic to be published, the inter-core communication method also includes: the first processor updates the valid length and data identifier of the data block corresponding to the update index, and releases the read-write lock corresponding to the data block; the first processor records the topic name and data version of the topic to be published in the event notification area.

[0012] In some embodiments, the inter-core communication method also includes: the second processor obtains the spin lock of the shared memory and locks the shared memory; in response to the fact that the second processor's to-be-registered topic does not exist in the metadata area of ​​the shared memory, the second processor registers the to-be-registered topic in the topic information structure of the metadata area, obtains the subscribed topic of the second processor, and updates the field information of the subscribed topic; the second processor allocates a subscription storage area for the subscribed topic, and records the subscribed topic in the event notification area in the memory area; the second processor releases the spin lock.

[0013] In some embodiments, when the serial number of the subscribed topic is updated, obtaining the data in the subscribed topic includes: the second processor reads the notification information of the subscribed topic in the subscription storage area, and determines the data version of the data block corresponding to the subscribed topic whose writing is completed; the second processor obtains the read-write lock of the data block whose writing is completed in a read manner, and determines the data identifier in the data block whose writing is completed; the second processor compares the data version with the data identifier to obtain a comparison result; in response to the comparison result indicating that the data version is consistent with the data identifier, the second processor obtains the data in the data block whose writing is completed.

[0014] In the second aspect, an embodiment of the present application provides an inter-core communication device, which includes: a determination module, which is used to determine the data storage space of the topic to be published in the shared memory of the robot in response to the registration request of the first processor of the robot for the topic to be published; a generation module, which is used for the first processor to write the target data corresponding to the topic to be published into the data storage space, and generate the serial number of the topic to be published; and an acquisition module, which is used for the second processor of the robot to periodically query the serial number of the subscribed topic, and obtain the data in the subscribed topic when the serial number of the subscribed topic is updated.

[0015] In a third aspect, an embodiment of the present application provides a robot comprising: a memory for storing executable instructions; and a processor comprising at least a first processor and a second processor for implementing the above-mentioned inter-core communication method when executing the executable instructions stored in the memory.

[0016] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium storing executable instructions for causing a processor to execute the executable instructions to implement the above-mentioned inter-core communication method.

[0017] In a fifth aspect, an embodiment of the present application provides a computer program product, which includes executable instructions, and the executable instructions are stored in a computer-readable storage medium; when the robot's processor reads the executable instructions from the computer-readable storage medium and executes the executable instructions, the above-mentioned inter-core communication method is implemented.

[0018] The embodiment of the present application allocates independent data storage space in shared memory for each topic to be published, and the first processor is responsible for writing the target data and generating a serial number, and the second processor determines whether there is new data available for reading by periodically querying the serial number. This makes the inter-core communication method provided by the embodiment of the present application unnecessary to rely on the interrupt mechanism for cross-core notification, reducing the system scheduling overhead. The reader directly reads and writes through subscription polling and shared memory, realizing zero-copy reading, without the need for a network or intermediate agent, reducing end-to-end latency, and improving communication efficiency. It also adopts a distributed design concept, dynamically allocating a corresponding shared memory area for each topic to be published, allocating shared memory on demand, and reducing resource waste. At the same time, there is no master-slave distinction between multiple processors, reducing the strong dependence on the master-slave relationship in related technologies, and improving the flexibility and real-time performance of inter-core communication.

[0019] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 This is an optional process diagram of the inter-core communication method provided in the embodiment of the present application. Figure 1 ;

[0021] Figure 2 This is an optional process diagram of the inter-core communication method provided in the embodiment of the present application. Figure 2 ;

[0022] Figure 3 This is an optional process diagram of the inter-core communication method provided in the embodiment of the present application. Figure 3 ;

[0023] Figure 4 This is a schematic diagram of the structural division of the shared memory provided in an embodiment of the present application;

[0024] Figure 5 This is a schematic diagram of the PUB communication process provided by an embodiment of the present application;

[0025] Figure 6 This is a schematic diagram of the SUB communication process provided by an embodiment of the present application;

[0026] Figure 7 is a schematic structural diagram of an inter-core communication device provided in an embodiment of the present application;

[0027] Figure 8 This is a schematic diagram of the hardware entity of a robot provided in an embodiment of the present application. DETAILED DESCRIPTION

[0028] In order to make the purpose, technical solutions and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limiting this application. All other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0029] In the following description, reference is made to "some embodiments," which describe a subset of all possible embodiments. However, it will be understood that "some embodiments" may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict. Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by those skilled in the art to which the embodiments of this application pertain. The terms used in the embodiments of this application are for the purpose of describing the embodiments of this application only and are not intended to limit this application.

[0030] In some embodiments, in a multi-core heterogeneous system (e.g., a combination of Cortex-A, Cortex-R, or Cortex-M cores), efficient and reliable data communication and coordinated control between different cores are required. This is typically achieved by using an RPMsg+OpenAMP architecture that supports remote processor lifecycle management, resource scheduling, and message transmission.

[0031] RPMsg is a lightweight inter-core communication protocol designed for heterogeneous multi-core systems. It is used for message-level communication between the master and slave cores in Linux. OpenAMP is a higher-level software framework based on RPMsg, providing a complete set of middleware that supports inter-core communication, resource management, and remote core lifecycle control in heterogeneous systems.

[0032] Although the RPMsg + OpenAMP architecture is relatively mature and widely used, it still has many technical limitations and shortcomings in practical use. These include: Due to its reliance on multiple subsystems, such as the virtio device model and libmetal for platform abstraction, and the need to adapt to low-level interrupt and memory resources, RPMsg and OpenAMP are complex to integrate and port within lightweight real-time operating systems (RTOS) or bare-metal environments. Interrupts are frequent, limiting scheduling efficiency. Each domain is separated by an independent channel, resulting in multi-domain communication isolation. Linux does not support simultaneous opening of RPMsg-mapped devices by multiple processes, making distributed communication impossible. A central process is required for read and write forwarding, resulting in low communication efficiency. The strong dependency between cores imposes strict constraints on startup logic, resulting in complex bind / unbind logic and difficulty in implementing dynamic registration, limiting application startup flexibility and performance. The single-packet data size is limited to 512 bytes, making it particularly unsuitable for applications with large packets. Furthermore, even small packets are padded with zeros to transmit 512 bytes, increasing system resource consumption and latency, and reducing communication efficiency.

[0033] Based on this, an embodiment of the present application can provide an inter-core communication method, which, in response to a registration request for a topic to be published by the first processor of the robot, determines the data storage space of the topic to be published in the shared memory of the robot; the first processor writes the target data corresponding to the topic to be published into the data storage space, and generates a serial number of the topic to be published; the second processor of the robot periodically queries the serial number of the subscribed topic, and obtains the data in the subscribed topic when the serial number of the subscribed topic is updated.

[0034] In this way, by allocating independent data storage space in shared memory for each topic to be published, and the first processor is responsible for writing the target data and generating a serial number, the second processor determines whether there is new data available for reading by periodically querying the serial number. The inter-core communication method provided in the embodiment of the present application does not need to rely on the interrupt mechanism for cross-core notification, which reduces the system scheduling overhead. The reader directly reads and writes through subscription polling and shared memory, realizing zero-copy reading, without the need for a network or intermediate agent, reducing end-to-end latency and improving communication efficiency. It also adopts a distributed design concept to dynamically allocate a corresponding shared memory area for each topic to be published, allocate shared memory on demand, and reduce resource waste. At the same time, there is no master-slave distinction between multiple processors, reducing the strong dependence on the master-slave relationship in related technologies and improving the flexibility and real-time performance of inter-core communication.

[0035] In the embodiments of the present application, the inter-core communication method provided can be applied to fields such as autonomous driving and industrial robots that require processing high-frequency sensor data and real-time control instructions, which have extremely high timeliness requirements.

[0036] The technical solution of this application will be described in detail below with reference to the accompanying drawings.

[0037] Figure 1 This is an optional process diagram of the inter-core communication method provided in the embodiment of the present application. Figure 1 The executors of the inter-core communication method provided in the embodiment of the present application are the first processor and the second processor of the robot. The first processor can be a data publisher, such as the sensor data processing unit (such as a LiDAR point cloud processing module) or a real-time control instruction generation module of the robot, and the second processor can be a data reader, such as a motion control module (such as a motor drive).

[0038] In some embodiments, the first processor and the second processor may also be one of a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), a field programmable gate array (FPGA), or an application specific integrated circuit (ASIC).

[0039] like Figure 1 As shown, the inter-core communication method provided in the embodiment of the present application can be implemented through steps S101 to S103:

[0040] S101 : In response to a registration request for a topic to be published by a first processor of a robot, determine a data storage space for the topic to be published in a shared memory of the robot.

[0041] In an embodiment of the present application, the first processor may be a main processing unit (MPU) in the robot, where the MPU is a processing unit used to generate or collect data, such as a sensor data processing module or a control instruction generation module.

[0042] The topic to be published may refer to data that the first processor needs to publish, such as lidar data or motor control instructions, etc., which are used to organize and classify communication content.

[0043] The registration request may indicate that the first processor wishes to add the topic to the distributed communication system so that subsequent published data can be shared with other processors.

[0044] Shared memory can be a memory area pre-allocated in the robot's storage for inter-core communication and accessible to multiple processors or processes. The shared memory structure can be divided into three parts: the metadata area (Header), the event notification area (Notify), and the storage area (Segment). The Header area is used to manage global metadata, such as the number of currently registered topics and the next available segment offset address; Notify is used for event notification and contains the topic name (topic_id) and corresponding sequence number of each subscriber; the Segment area is used for actual data storage. Each topic corresponds to one or more segments, and each segment contains several data block buffers. Each data block buffer has an independent read-write lock to ensure the security of concurrent access.

[0045] In an embodiment of the present application, the first processor may register the topic to be published in the shared memory, and declare the data type and format of the topic during registration. The shared memory will dynamically allocate data storage space for the topic to be published.

[0046] In some embodiments, the process of determining the data storage space can be implemented through the following steps: first, obtain the spinlock of the shared memory header to ensure thread safety; then traverse the topic_struct array in the Header to determine whether the topic has been registered; if not, create a new Topic_struct based on the current topic_num_index and allocate the corresponding segment area.

[0047] Here, the shared memory area is automatically allocated through the dynamic registration mechanism, which enables flexible configuration of cross-core communication, improves the scalability and adaptability of the system, and reduces the workload of manual configuration.

[0048] S102: The first processor writes the target data corresponding to the to-be-published topic into the data storage space, and generates a serial number for the to-be-published topic.

[0049] In the embodiments of the present application, target data may refer to specific data content to be published, such as sensor data or control instructions. Writing the target data to the data storage area may refer to copying the data to an unused data block in pre-allocated data storage space in the shared memory. The sequence number may be used to mark the version of the data block, making it easier for subscribers to determine whether new data is available for reading.

[0050] In some embodiments, the writing can be implemented in the following manner: first, find the corresponding data storage space (segment) according to the topic to be published; then perform an atomic operation self-increment on the seq_ (which can refer to the sequence number / index of the data storage space, used to identify the version of the data block) of the segment to generate a new sequence number; an attempt can be made to acquire the read-write lock of the Segment_block (data block) corresponding to the new sequence number in a write manner; subsequently, the target data is copied into the unused data block of the data storage space in a byte-aligned manner.

[0051] Here, using the sequence number and the atomic operation, the data overwrite problem can be effectively avoided, ensuring data consistency in the multi-writer / multi-reader scenario, thereby improving the stability and reliability of communication.

[0052] S103, the second processor of the robot periodically queries the sequence number of the subscribed topic, and acquires data in the subscribed topic in a case where the sequence number of the subscribed topic is updated.

[0053] In the embodiments of the present application, the second processor can be a secure co-processor (SCP) or other processor in the robot, and can be used to perform real-time tasks or low-power consumption calculations.

[0054] Periodic query can refer to checking the state of the subscribed topic at a certain time interval or event triggering frequency, the sequence number of the subscribed topic refers to the latest data version of the subscribed topic concerned by the second processor, and sequence number update means that new data is published. Acquiring data in the subscribed topic refers to reading the latest data content and processing it.

[0055] In the embodiments of the present application, the second processor can sequentially read the event notification area (notify), and judge whether there is data that has completed writing; for each data block that meets the condition, an attempt is made to acquire the read-write lock in the data block in a read manner, and the data index in the data block is compared to prevent data from being overwritten, then the data block and data information are read, and finally the read-write lock is released, completing a data acquisition operation.

[0056] The periodic query and sequence number comparison mechanism in the embodiments of the present application can achieve efficient inter-core asynchronous communication without relying on interrupts, reduce the interrupt overhead and delay of the system, and improve the overall communication efficiency and real-time performance.

[0057] The embodiment of the present application allocates independent data storage space in shared memory for each topic to be published, and the first processor is responsible for writing the target data and generating a serial number, and the second processor determines whether there is new data available for reading by periodically querying the serial number. This makes the inter-core communication method provided by the embodiment of the present application unnecessary to rely on the interrupt mechanism for cross-core notification, reducing the system scheduling overhead. The reader directly reads and writes through subscription polling and shared memory, realizing zero-copy reading, without the need for a network or intermediate agent, reducing end-to-end latency, and improving communication efficiency. It also adopts a distributed design concept, dynamically allocating a corresponding shared memory area for each topic to be published, allocating shared memory on demand, and reducing resource waste. At the same time, there is no master-slave distinction between multiple processors, reducing the strong dependence on the master-slave relationship in related technologies, and improving the flexibility and real-time performance of inter-core communication.

[0058] In some embodiments, the shared memory may include a header area for storing system-level metadata and control information, such as a topic registry, segment allocation pointers, etc., and for managing the overall shared memory state and topic configuration. The header area includes the next valid data block offset (next_valid_segment_offset_) for allocating a new storage area (segment), the number of topics (topic_num_) representing the number of currently registered topics, a lock for accessing the topic registry (topic_lock_), and a topic information structure (topic_struct). The topic_struct can support multiple topics, each of which contains information such as topic_id, length, string name, starting segment offset, number of data blocks (blocks), and size of each storage block (buffer).

[0059] By centrally managing registered topics in a metadata area, this embodiment of the application allows each core in a multi-core environment to access the metadata area to obtain the latest status of the topic, thus avoiding duplicate calculations or conflicts. This improves the efficiency of shared memory usage and the consistency of data access, thereby reducing system complexity and improving communication performance, thereby supporting high-concurrency, low-latency inter-core communication requirements.

[0060] The inter-core communication method provided in the embodiment of the present application further includes step S1:

[0061] S1. The first processor obtains a spin lock of the shared memory and locks the shared memory.

[0062] In the embodiments of the present application, the spin lock is a kind of light-weight synchronization mechanism, which can be used for mutual exclusion access of resources in a multi-thread or multi-core environment. When a processor attempts to acquire a spin lock, if the lock has been occupied, it will enter a busy waiting state, and continue to poll until the lock is available. Compared with the blocking lock, the spin lock has lower context switching overhead in the case of short lock holding time, and is suitable for high-performance scenarios.

[0063] In the embodiments of the present application, the spin lock can be used to protect the key data structure in the shared memory, such as the topic registration table and the segment allocation pointer in the Header area. When the first processor is preparing to register a new topic or access the information of an existing topic, it first needs to acquire the spin lock to ensure that there is no data race or inconsistency problem during the operation. For example, when updating topic_num_ or modifying the starting offset address (segment_offset_) of a certain topic in the shared memory, if no lock is added, multiple processors may simultaneously modify the same field, thereby causing data errors or deadlocks.

[0064] In this way, locking the shared memory through the spin lock can prevent multiple processors from simultaneously modifying the key data structure of the shared memory, thereby ensuring the consistency and integrity of the data, and further improving the stability and reliability of the system.

[0065] Correspondingly, the step of determining the data storage space of the to-be-published topic in the shared memory of the robot in step S101 includes steps S1011 and S1012:

[0066] S1011, the first processor traverses the topic information structure body of the meta information area based on the topic name of the to-be-published topic, and determines the historical registration information of the to-be-published topic.

[0067] In the embodiments of the present application, the topic name can be topic_id, which is a user-defined string identifier, or a string identifier generated based on user information or topic-related information, etc., and is used to uniquely identify a communication topic. In the distributed inter-core communication provided in the embodiments of the present application, the topic name can be used as an index to find whether the to-be-published topic has been published in the topic information structure body of the shared memory.

[0068] Here, the topic information structure body can be a predefined data structure in the shared memory, which can include fields such as topic_id, length, string name, starting segment offset, data block quantity, and size of each data block. By traversing the topic information structure body array, it can be checked whether the to-be-published topic has been registered, and if it has been registered, its historical registration information, such as the allocated segment offset address, can be obtained.

[0069] In an embodiment of the present application, when a new topic registration request is received, the existing topic information structures in the meta-information area are first compared item by item based on the provided topic name. If a matching topic information structure is found, it means that the topic has been registered and the detailed information of the topic can be directly returned; otherwise, it means that the topic has not been registered and a new segment area needs to be allocated to it and a corresponding topic information structure needs to be created. The created topic information structure records the registered topic and the segment area allocated to it.

[0070] In this way, it is possible to efficiently determine whether the target topic already exists, thereby avoiding duplicate registration and waste of resources, and thus improving the flexibility and scalability of the system.

[0071] S1012: The first processor determines the data storage space in the shared memory based on the historical registration information.

[0072] In embodiments of the present application, data storage space may refer to the actual data buffer allocated in shared memory for a specific topic. Each topic may correspond to one or more data storage spaces, and each data storage space may be composed of several data blocks, each of which may contain independent read-write locks and data buffers. Here, the number of data blocks corresponding to the data storage space for each topic may be determined based on the number of data to be published to the data storage space. If a single data block cannot meet the storage requirements, multiple data blocks may be allocated to ensure sufficient space to store the data to be published.

[0073] Through the data storage space offset address in the historical registration information, the specific location of the topic in the shared memory can be calculated, and its available data block list can be further determined.

[0074] In this embodiment of the present application, after confirming the offset address of the data storage space for the topic to be published, the system will locate the corresponding data storage space based on the offset address and select an available data block for data storage. To ensure data security and consistency, the selection and use of data blocks must strictly follow atomic operation rules and incorporate a read-write lock mechanism to coordinate access between multiple processors. In addition, flexible management of memory resources can be achieved by dynamically allocating and recycling data blocks.

[0075] In this way, shared memory resources can be efficiently utilized, thereby improving the efficiency and stability of data transmission, and thus meeting the communication needs in different application scenarios.

[0076] Correspondingly, the inter-core communication method further includes step S2:

[0077] S2. The first processor releases the spin lock.

[0078] In an embodiment of the present application, after completing the operation on the shared memory, the first processor needs to promptly release the previously acquired spin lock so that other processors can continue to access the relevant data in the shared memory. The process of releasing the spin lock can be completed by calling a dedicated application programming interface (API) or instruction.

[0079] Here, releasing the spin lock not only means releasing the lock itself, but also involves updating related state variables, such as resetting flags or notifying other processors that the lock has been released.

[0080] In this way, releasing the spin lock can ensure that other processors can access key data structures in shared memory in a timely manner, thereby improving the system's concurrency and response speed, and further enhancing the performance and stability of the entire inter-core communication system.

[0081] In an embodiment of the present application, by dividing the metadata area in the shared memory and using a spin lock mechanism to ensure the consistency of data access, it is possible to effectively prevent multiple processors from modifying the key data structure in the shared memory at the same time, thereby ensuring the consistency and integrity of the data, and thus improving the stability and reliability of the system.

[0082] In some embodiments, step S1012 may be implemented by steps S3 and S4:

[0083] S3. In response to the historical registration message indicating that the to-be-published topic does not exist in the shared memory, the first processor registers the to-be-published topic based on the number of topics in the shared memory, and determines the topic index of the to-be-published topic and the data storage space; the data storage space is an unused area in the shared memory.

[0084] In some embodiments, the topic index topic_num_ can refer to a location number or offset address used to identify a specific topic in shared memory. This index value can uniquely point to the data structure and storage area corresponding to a topic. Through this index, the relevant data of the topic can be quickly found and accessed in the shared memory. For example, a topic_struct array is maintained in the Header area. After each topic is registered, a unique index value topic_num_ is assigned to it, which is used to locate and operate the topic in the subsequent communication process.

[0085] The unused area refers to the shared memory space that is currently not occupied by any registered topic and can be located in the part of the shared memory that has not been initialized. These areas can be dynamically allocated to newly registered topics as their exclusive data storage areas. The selection of the unused area needs to consider the memory fragmentation problem, and the space that is continuous and large enough is preferred to improve the memory utilization. For example, the next_valid_segment_offset_ field is maintained in the Header, which records the starting position of the next available segment, ensuring that a suitable unused area can be found each time it is allocated.

[0086] S4, in response to the historical registration message representing that the to-be-published topic exists in the shared memory, the first processor determines the data area corresponding to the to-be-published topic in the shared memory as the data storage space.

[0087] In the embodiments of the present application, the historical registration message refers to the information record generated by the registration request issued by other processes or modules before, which contains the state of whether the topic is registered, the registration time, the identity of the registrant, and other metadata. By analyzing the historical registration message, the system can judge whether the to-be-published topic has been registered, and decide whether to perform a new registration process or directly reuse the existing data area. The historical registration message can be saved in the topic_struct in the Header area, and the existence of the to-be-published topic can be quickly judged by traversing the array.

[0088] The data storage space refers to the shared memory space that has been allocated to the to-be-published topic and can contain several data blocks, each of which can be used to store the data of one publication. Since the to-be-published topic has been registered, its existing starting offset (segment_offset) address in the shared memory can be directly referenced without the need to allocate memory again. This way not only saves memory resources, but also reduces the performance loss caused by frequent memory allocation / deallocation. For example, if multiple publishers want to publish data to the same topic, they can share the same data storage space and only need to distinguish different batches of data through different data blocks.

[0089] Here, when it is detected that the to-be-published topic has been registered in the shared memory, the system will directly return the data storage space offset address and data block configuration parameters corresponding to the to-be-published topic, skipping the registration process. This can avoid repeated initialization of the topic structure and memory allocation, reducing system overhead. At the same time, by reusing the existing data storage space, the stability and consistency of the system can also be improved, avoiding potential conflicts and errors caused by multiple registrations.

[0090] In the embodiments of this application, an efficient inter-core communication mechanism is implemented by dynamically registering topics to be published in shared memory and allocating unused areas, or reusing existing topic data storage space. This reduces the frequency of memory allocation and deallocation, thereby lowering system overhead and improving memory utilization. Furthermore, it supports a high-concurrency, multi-reader / multi-writer distributed pub / sub model, meeting the stringent real-time and high-performance requirements of the robotics field.

[0091] In some embodiments, after the topic to be published is registered, the inter-core communication method further includes steps S5 and S6:

[0092] S5. The first processor updates the field information of the topic to be published in the topic information structure, where the field information at least includes a topic valid identifier, a topic name, a topic name length, and a topic name character string.

[0093] Here, when it detects that there are no topics to be published registered in shared memory, the system acquires the spin lock of the shared memory header and enters mutual exclusion protection mode. Then, based on the topic_num_ of the current topic to be published, it finds the first unused entry in the topic_struct, creates a new topic_struct, and updates its fields, including basic information such as the topic validity identifier topic_vaild_, the topic name topic_id, the topic name length topic_len, and the topic name string topic_str.

[0094] The topic validity flag can be a Boolean field that indicates whether the topic is active. When valid, the topic is available for publish and subscribe operations. When invalid, the system ignores all read and write requests for the topic. This mechanism allows for dynamic control over the activation and deactivation of communication channels, preventing invalid data transmission.

[0095] A topic name can be a unique integer number that uniquely identifies a topic within the communication system. This identifier can be automatically generated and assigned by the system to ensure that there are no conflicts between different topics. By using numeric identifiers, the system can achieve rapid lookup and matching at the underlying communication layer, improving processing efficiency.

[0096] The Topic Name Length and Topic Name String fields record the human-readable name of the topic. The Topic Name Length field can be used to determine the actual length of the string, while the Topic Name String field provides a more developer- and debugging tool-friendly identification method. These two fields allow the system to support multiple programming interfaces and accommodate debugging requirements in different language environments.

[0097] By updating these field information in the topic information structure body, the system can dynamically adjust the state and attributes of the topic, such as enabling / disabling specific communication channels, modifying the topic name to adapt to new functional requirements, etc. In this way, communication resources can be flexibly managed to avoid resource waste, thereby efficiently organizing communication among multiple cores, and thus improving the overall operation efficiency and response speed of the system.

[0098] S6, the first processor updates the storage area information of the data storage space corresponding to the to-be-published topic; the storage area information at least includes a starting offset of the data storage space in the shared memory, a data block quantity, and a size of each data block.

[0099] Here, the starting offset of the data storage space in the shared memory, the data block quantity, and the size of each data block in the Header can also be updated.

[0100] The data storage space can be a buffer for storing actual communication data. In the embodiments of the present application, each topic has a corresponding storage area, which is pre-allocated in the shared memory to ensure the zero-copy feature of data transmission. By updating the storage information of the area, the system can dynamically adjust its configuration to meet different communication needs.

[0101] Here, the starting offset can refer to the absolute address position of the data storage space in the shared memory. The starting offset is crucial for the system to correctly address and access data. The data block quantity can represent how many independent data blocks are contained in the storage area, and each data block can be independently read and written to support concurrent access. The size of each data block determines the maximum capacity of a single data unit, which can be configured according to specific application scenarios, such as small packet high frequency communication or large data low frequency communication.

[0102] By updating these storage area information, the system can dynamically expand or reduce the communication bandwidth, such as increasing the data block quantity to meet the high frequency data transmission demand, or increasing the size of each data block to optimize the large packet transmission efficiency. In this way, the communication needs in different scenarios can be flexibly adapted, so that the hardware resources can be fully utilized, and thus the communication efficiency and system performance can be improved.

[0103] The embodiments of the present application dynamically adjust the configuration parameters without the need to recompile or restart the entire robot system, so as to realize the optimization of communication strategy at runtime. This makes the system have stronger flexibility and scalability, and adapt to complex and variable application scenarios.

[0104] In some embodiments, the shared memory further includes a storage area, which can be composed of multiple data blocks, each data block having an independent read-write lock for data safety control in concurrent access. The design of the storage area supports dynamic allocation, i.e., dynamically dividing the storage space according to different topics, thereby improving the flexibility and efficiency of communication and reducing resource waste. Data of different topics can be stored in isolation to prevent data conflict or overwrite.

[0105] Figure 2 is an optional flowchart of the inter-core communication method provided by the embodiments of the present application Figure 2 The step S102 of the inter-core communication method provided by the embodiments of the present application can also be implemented by steps S201 to S203.

[0106] In step S201, the first processor performs an atomic self-increment operation on the storage index of the data storage space to obtain an updated index of the data storage space.

[0107] In the embodiments of the present application, the storage index can be seq_ of the current segment, which is a pointer or counter for identifying the current available data block position. Through the atomic self-increment operation, the updated index of the data storage space is obtained.

[0108] The atomic self-increment operation is a thread-safe operation mode, which ensures that multiple processors do not modify the same index value at the same time in a concurrent environment, avoiding data conflict. For example, in a multi-core heterogeneous system, multiple cores may attempt to write data to the shared memory at the same time, and the atomic self-increment operation is used to ensure the uniqueness and order of the index.

[0109] By using the atomic self-increment operation to manage the storage index, the system can ensure the order and consistency of data writing in a high-concurrency environment, avoiding data anomalies caused by race conditions.

[0110] In step S202, the first processor obtains the data block corresponding to the updated index in the storage area and the read-write lock corresponding to the data block based on the updated index of the data storage space.

[0111] In the embodiments of the present application, after obtaining the updated index, the data block corresponding to the index can be located, and the read-write lock of the data block can be obtained. Here, the read-write lock can be obtained in a write manner. The read-write lock is used to control the access permission of the data, ensuring that only one write operation is performed at the same time, while multiple read operations can be performed simultaneously to improve the throughput of the system.

[0112] In step S203, the first processor writes the target data corresponding to the to-be-published topic into the data block corresponding to the updated index in a byte-aligned manner to generate a sequence number of the to-be-published topic.

[0113] In this embodiment of the present application, the target data can be written to the data block in a byte-aligned manner, ensuring that the data layout in memory meets the requirements of the hardware architecture, thereby optimizing access efficiency. Finally, the system generates a sequence number (Notify_seq) for the topic to be published for this write operation. This serves as an identifier for the data, allowing subscribers to detect data updates and facilitate subsequent reading and management.

[0114] In an embodiment of the present application, by introducing a storage area in a shared memory, using an atomic auto-increment operation to manage the storage index, and writing data through a read-write lock and byte alignment method, the security and efficiency of communication between multiple cores can be effectively improved, thereby ensuring the consistency and integrity of data in high-concurrency scenarios, and thus significantly reducing communication delays and improving the overall performance of the system.

[0115] In some embodiments, the shared memory further includes an event notification area Notify, which is used for event notification and includes the topic_id and corresponding sequence number of each subscriber. Before generating the sequence number of the topic to be published, the inter-core communication method provided in the embodiment of the present application may further include steps S11 and S12:

[0116] S11. The first processor updates the valid length and data identifier of the data block corresponding to the update index, and releases the read-write lock corresponding to the data block.

[0117] In the embodiments of the present application, a data block is the basic unit for storing published topic data in shared memory. Each data block can contain a data buffer and a metadata header. The size of the data block can be determined by the system configuration, for example, it can be set to 512 bytes, 1024 bytes, etc. to adapt to different application requirements.

[0118] The data block data valid length (data_len_) can refer to the number of valid data bytes actually stored in the current data block. This field is used to indicate the actual size of the data so that subscribers can correctly parse the data content when reading. For example, if a data block has a maximum capacity of 1024 bytes but only 512 bytes are used to store data, the data block data valid length should be set to 512.

[0119] The data identifier (Segment_block in seq_) is a unique identifier associated with the data block, used to identify whether the data block has been published or overwritten. The identifier can be a sequence number, timestamp, or hash value, etc., to ensure that there is no conflict or misjudgment between different data blocks. For example, an atomic incrementing integer can be used as the data identifier, which is incremented by one each time new data is published, thereby avoiding data duplication or omission.

[0120] Here, each data block is equipped with an independent read-write lock to prevent data inconsistency caused by concurrent access. When the publisher writes data, it will try to acquire a write lock; when the subscriber reads data, it will try to acquire a read lock. The write lock is exclusive, i.e., only one write operation can be performed at the same time; while the read lock allows multiple read operations to be performed simultaneously.

[0121] Releasing the read-write lock means actively releasing the occupied lock resource after completing the operation on the data block, so that other threads or processes can continue to use the data block. This can improve the concurrent performance and resource utilization of the system. For example, after the publisher completes data writing, the write lock is immediately released, allowing the subscriber to read data in a timely manner; similarly, after the subscriber completes data reading, the read lock should also be released in a timely manner to avoid blocking subsequent operations.

[0122] In a robot control system, multiple processor cores may need to access the same data block in shared memory simultaneously. By updating the data effective length and data identifier of the data block, and releasing the read-write lock after the operation is completed, concurrent access can be effectively managed, ensuring data consistency and integrity, while reducing unnecessary waiting time and improving overall communication efficiency.

[0123] S12, the first processor records the topic name and data version of the to-be-published topic in the event notification area.

[0124] In the embodiments of the present application, the event notification area is a key part of the shared memory used to coordinate communication between the publisher and the subscriber. It maintains the state information of all published topics and their latest data, allowing the subscriber to learn whether there is new data to read in a timely manner. The event notification area can include a series of notification entries, each corresponding to a topic and recording the latest data version and other related information of the topic.

[0125] The topic name is a string or integer value used to uniquely identify a published topic. It can be a predefined constant or a dynamically generated variable, used to distinguish different data streams. For example, in a robot control system, joint_position can be used as the topic name for joint position data, and sensor_data can be used as the topic name for sensor data.

[0126] The data version segment_seq_ can be a numerical value used to represent the number of updates or change status of data under a certain topic. Each time the publisher sends new data to a certain topic, the data version of the topic is incremented by one. In this way, the subscriber can determine whether there is new data available by comparing the locally cached data version with the data version in the event notification area. For example, if the data version of a topic in the event notification area is 5, and the data version cached locally by the subscriber is 3, it means that there are two new data that have not been read.

[0127] In a multi-core heterogeneous robot control system, the master unit (MPU) and the coprocessor unit (SCP) can be responsible for different task modules, such as perception, decision-making, and execution. By recording the latest data version and topic name of each topic in the event notification area, each module can synchronize the latest data status in real time, thereby achieving efficient collaboration. In addition, this approach can also reduce unnecessary polling operations, reduce system overhead, and improve response speed.

[0128] In the embodiments of the present application, by updating the data valid length and data identifier of the data block before publishing new data and releasing the read-write lock, and recording the topic name and data version in the event notification area, the data access in the shared memory can be effectively managed, the communication efficiency and data consistency of the multi-core system can be improved, and the running performance and stability of the entire robot can be improved.

[0129] In some embodiments, the inter-core communication method provided by the embodiments of the present application can further include steps S21 and S24:

[0130] S21, the second processor acquires the spin lock of the shared memory, and locks the shared memory.

[0131] The second processor acquires the spin lock of the shared memory to ensure that its operation on the shared memory is exclusive. This can prevent other processors from simultaneously modifying the key data structure in the shared memory, thereby avoiding data inconsistency problems. For example, before registering a new topic (topic), it must be ensured that no other processor is currently performing read-write operations on the topic structure.

[0132] In the embodiments of the present application, by acquiring the spin lock before the second processor accesses the shared memory, the data race problem caused by multiple processors simultaneously modifying the shared memory can be effectively avoided, thereby ensuring the stability and data consistency of the system, and further improving the security and reliability of inter-core communication.

[0133] S22, in response to the second processor's to-be-registered topic not existing in the meta-information region of the shared memory, the second processor registers the to-be-registered topic and the corresponding topic information structure body in the meta-information region, obtains the second processor's subscribed topic, and updates the field information of the subscribed topic.

[0134] The to-be-registered topic can refer to a new topic that needs to be subscribed and registered in the shared memory. In this step, the second processor can first check whether the topic_struct in the meta-information region already exists the to-be-registered topic. If not, it is registered in the topic_struct, and the related field information is updated, such as topic_valid_(validity flag), segment_offset_(segment offset address corresponding to the topic), block_num_(number of data blocks allocated for each topic), block_buffer_size_(buffer size of each data block), and the like.

[0135] The registration process not only includes adding a new topic to the topic_struct, but also includes allocating corresponding segment and notify storage space for the topic in the shared memory, ensuring that the subsequent publishing and subscribing operations can correctly find the corresponding data storage location.

[0136] S23, the second processor allocates a subscription storage region for the subscribed topic, and records the subscribed topic in the event notification region in the memory region.

[0137] The subscription storage region refers to the memory space allocated for the subscribed topic, used to store the data block of the subscribed topic. The second processor can allocate and initialize the subscription storage region for the subscribed topic in the shared memory, and record the related information of the topic in the event notification region, so that the subsequent publisher can correctly notify the subscriber when sending data.

[0138] The event notification region is used to transmit the notification information of data updates between the publisher and the subscriber. In the embodiment of the present application, the event notification region includes Notify_state (global sequence number), Notify_info[k] (records each subscribed topic_id and the corresponding segment sequence), and Notify_seq[k] (the current sequence number of each topic), which are used to help the subscriber judge whether there is new data available for reading.

[0139] In the embodiments of the present application, by assigning a subscription storage area to the subscribed topic and recording relevant information in the event notification area, efficient event-driven communication can be achieved. In this way, it can be ensured that the subscriber can receive timely notification when the data is available, thereby improving the communication efficiency and real-time performance, and thus reducing system delay and enhancing overall performance.

[0140] S24, the second processor releases the spin lock.

[0141] After completing the operation on the shared memory, the second processor needs to release the spin lock acquired previously to allow other processors to continue accessing the shared memory. Releasing the spin lock is an important step to ensure system concurrency performance, which helps to improve the efficiency of cooperation between multiple processors.

[0142] In the embodiments of the present application, the shared memory mechanism and spin lock control are introduced in the inter-core communication process, which can realize efficient and safe data exchange. In this way, the high delay problem caused by traditional message queues or remote calls can be avoided, thereby improving the communication efficiency, and thus meeting the needs of high-performance application scenarios such as robots.

[0143] Figure 3 is an optional flowchart of the inter-core communication method provided by the embodiments of the present application Figure 3 The step S103 in the inter-core communication method provided by the embodiments of the present application can also be implemented by steps S301 to S304:

[0144] S301, the second processor reads the notification information of the subscribed topic in the subscription storage area, and determines the data version of the data block corresponding to the write completion of the subscribed topic.

[0145] The subscription storage area refers to the storage space reserved in the shared memory for each subscribed topic, which is used to save the meta information and state information related to the topic. The notification information is a set of metadata generated by the publisher after writing data, which is used to inform the subscriber whether there is new data available for reading under the topic. The notification information notify info can include fields such as data version number segment_seq_, topic_id, etc., to determine whether the data has changed.

[0146] The data version is a numerical value representing the write state of a certain data block. Each time data is written, the value will increase. By comparing the data version, it can be determined whether the data has been updated, thereby avoiding reading outdated or incomplete write data.

[0147] When the second processor detects that the sequence number of the subscribed topic has changed, it will first access the subscription storage area, read the notification information corresponding to the topic from it, and extract the current data version of the topic. This operation ensures that subsequent read operations can be based on the latest data version, improving data consistency and communication efficiency.

[0148] S302, the second processor acquires the read-write lock of the data block in the write completion mode, and determines the data identifier in the data block in the write completion.

[0149] In the embodiments of the present application, read-write locks are used to manage access permissions to data blocks, ensuring that data modification does not occur during reading, thereby ensuring data security and integrity.

[0150] The data identifier (seq_ in Segment_block) is a number used to uniquely identify a data block, which can be an integer or a string. Through the data identifier, the specific data block can be quickly located, improving the efficiency of data searching and accessing.

[0151] In actual applications, when the second processor acquires the data version, it will try to acquire the read-write lock of the data block in read-only mode. If successful, it means that the data block is in a readable state. At this time, the processor can continue to read the data identifier in the data block to further confirm the integrity and availability of the data.

[0152] S303, the second processor compares the data version and the data identifier to obtain a comparison result.

[0153] The comparison between the data version (segment_seq_) and the data identifier (seq_ in Segment_block) is to verify the consistency and validity of the data. If they match, it means that the content of the data block is complete and has been correctly written; if they do not match, it may indicate that the data block has not been written or has been overwritten, and reading the data block should be avoided at this time to avoid data errors or program exceptions.

[0154] The second processor will compare the data version and the data identifier, and only when they are consistent, the data block is considered valid and the next operation can be performed. This process helps to prevent data conflicts and data loss, improving the stability and reliability of the system.

[0155] S304, in response to the comparison result indicating that the data version and the data identifier are consistent, the second processor acquires the data in the data block in the write completion.

[0156] In some embodiments, when the data version is consistent with the data identifier, it indicates that the content of the data block is up to date and complete. At this point, the second processor can safely read the required data from the data block and pass it to the upper layer application for processing.

[0157] After confirming that the data version and data identifier are consistent, the second processor releases the read-write lock and copies the contents of the data block to the local cache for use by the application. This process ensures efficient data transmission and real-time response, meeting the low latency and high reliability requirements of the robotic system.

[0158] In the embodiments of this application, by introducing mechanisms such as subscription storage areas, notification information, data versioning, read-write locks, and data identification, inter-core communication performance in a multi-core heterogeneous system is optimized. This effectively avoids data conflicts and inconsistencies, thereby improving the reliability and efficiency of data transmission and supporting more complex distributed application scenarios.

[0159] Next, we provide an application of the inter-core communication method in a practical scenario.

[0160] In order to solve the problems existing in the related technologies, the embodiments of the present application provide a universal and efficient distributed inter-core communication solution based on the shared memory area between heterogeneous cores. Adopting a distributed design concept, pub / sub nodes are dynamically created based on the topic as the index, and shared memory areas corresponding to different topics are dynamically allocated. It also supports multi-core data sharing and flexible configuration of the number and size of buffers. It supports multiple readers / multiple writers. It designs a relatively complete data asynchronous security mechanism. It supports the pub / sub communication model. It supports zero copy of data. The notification mechanism supports the polling mechanism and can be flexibly configured.

[0161] Figure 4 This is a schematic diagram of the structure division of the shared memory provided in the embodiment of the present application, such as Figure 4 As shown, the shared memory structure is divided into three parts: Header area 401, Notify area 402 and Segment area 403 (there may be multiple, such as Segment 403-1 to Segment 403-n).

[0162] The Header area 401 (i.e., meta information area) is used to manage the overall shared memory state and topic configuration. It contains: next_valid_segment_offset_: for allocating a new segment; topic_num_: the number of currently registered topics; topic_lock_: a lock for accessing the topic table; topic_struct

[100] : supporting a maximum of 100 topics, each topic containing: topic_id, length, string name; start segment offset, block number, and per-block buffer size information. uint64_t in the figure is used to represent an unsigned 64-bit integer data type, which can store large values, such as memory addresses; Spin_lock topic_lock_ is a spin lock mechanism in the Header; struct topic_struct

[100] indicates that a structure array named topic_struct is defined in the Header, with a size of 100; topic_struct includes topic_valid_ (validity flag), topic_id_, topic_len_ (length of the topic name or other related string data), topic_str_ (stores the topic name or other descriptive string information), segment_offset_ (segment offset address corresponding to the topic), block_num_ (number of data blocks allocated for each topic), and block_buffer_size_ (buffer size of each data block).

[0163] The Notify area 402 (i.e., event notification area) is used to support data synchronization between publishers and subscribers. It contains: Notify_state: records the global sequence number; Notify_info[k]: records the topic_id of each subscribed topic and the corresponding segment sequence; Notify_seq[k]: the current sequence number of each topic, which is used by the subscriber to compare and determine whether there is new data. The padding_ in Notify_state is used for byte alignment or data padding to ensure that the memory layout of the structure meets certain requirements.

[0164] Segment area 403 (i.e. storage area), each segment manages a data block of a topic, and the structure is as follows: Segment_state: global sequence number of the current segment; Segment_block[m]: header information of each data block, including lock, data length, sequence number, etc.; Segment_block_buf[m]: actual data buffer, block_buffer_size_: buffer size of each data block.

[0165] Embodiments of the present application can adopt a three-level computing architecture, including a main processing unit (MPU, Memory Protection Unit), a shared memory management unit (SMMU, System Memory Management Unit) and a plurality of secure co-processors (SCP, Secure Co-Processors). The MPU can be used as a central control unit, and the SCP can be used as a dedicated computing unit, and cross-domain communication can be achieved through the SMMU. A hierarchical memory management model can be used, and the core data structure includes: a control header (Header): a global state management area, including a topic registration table, a spin lock, and a segment allocation pointer; a notification queue (Notify): an event-driven mechanism, maintaining seq sequence and callback information; a data segment (Segment): a dynamic storage unit, each segment containing a plurality of block buffers with independent locks.

[0166] Figure 5 is a PUB communication process schematic diagram provided by the embodiments of the present application, as shown in Figure 5 , the pub communication includes an initialization stage, a PUB topic registration stage and a PUB Publish stage.

[0167] Among them, the initialization stage is carried out through the secure core, and the secure core is a trusted execution environment, such as a hardware security module or a software security module, which initializes the shared memory.

[0168] The PUB topic registration stage is implemented through steps S501 to S509:

[0169] S501, get SHM Header spin lock.

[0170] Here, Core1 can refer to an application processor 1 (Application Processor 1) in a multi-core heterogeneous system, which can be an independent processor core or processing unit, such as the first processor in the foregoing embodiments. Here, Core1 and the secure core are different cores.

[0171] S502, register the topic.

[0172] S503, loop read the topic_struct in Header, judge whether the topic is registered.

[0173] Here, if registered, execute step S504; if not registered, execute step S505.

[0174] S504, if the topic is registered, return the Topic_struct.

[0175] S505, if the topic is not registered, create a new Topic_struct in the topic_num_ index position of topic_struct (that is, the first unused area) according to the current topic_num_.

[0176] S506, update the field information in the newly created Topic_struct, including topic_vaild_, topic_id_, topic_len_, topic_str_, and update the current segment_offset_, representing the actual offset address of the current topic in the SHM segment.

[0177] S507, update the next_valid_segment_offset_ and topic_num_ in the Header.

[0178] Here, the next_valid_segment_offset_ field records the next available valid segment offset address. The purpose of updating is to correctly find the next free memory location when creating a new topic or other data structure subsequently, avoiding data overlap and other problems.

[0179] At the same time, update the topic_num_ field, add 1 to the topic number, reflect that there is now a new topic in the shared memory, so that other processes can accurately understand the total number of registered topics when reading the shared memory header information subsequently, and then perform corresponding operations, such as traversing all topics.

[0180] S508, allocate segment area and notify area, and initialize.

[0181] S509, return the SHM Header spin lock.

[0182] In some embodiments, the PUB Publish stage can be implemented through steps S510 to S516:

[0183] S510, according to topic, index segment, and atomically increment seq_ of the current segment.

[0184] S511, index the seq_ to obtain the corresponding Segment_block. Try to obtain the read-write lock in the block in write mode.

[0185] Here, the read-write lock of the data block can be tried to be obtained in write mode, and if the read-write lock is available, the acquisition is successful; otherwise, it is returned immediately.

[0186] S512, copy the data to the Segment_block_buf corresponding to seq_ in byte alignment mode.

[0187] S513, update data_len_ and seq_ in the Segment_block corresponding to seq_, which is used to determine whether the data is valid and whether it is overwritten.

[0188] S514, release the read-write lock of the block.

[0189] S515, operate notify and atomically increment next_seq_ in notify_state.

[0190] S516, index notify_info with next_seq_, fill in the topic_id and segment_seq_ corresponding to the segment being operated, and update notify_seq. The operation ensures the overwrite check.

[0191] Figure 6 is a SUB communication flow diagram provided by the embodiments of the present application, as shown in Figure 6 the PUB communication includes an initialization stage, a SUB topic registration stage, and a SUB Publish stage.

[0192] Among them, the SUB topic registration stage is implemented through steps S601 to S609:

[0193] S601, obtain the SHM Header spin lock.

[0194] Here, Core 2 can refer to an Application Processor 2 in a multi-core heterogeneous system, and can be a separate processor core or processing unit, such as the second processor in the foregoing embodiments. Here, Core 1, Core 2, and the secure core are different cores.

[0195] S602, register the topic.

[0196] S603, loop to read the topic_struct in the Header, and determine whether the topic is registered.

[0197] Here, if the topic is registered, perform step S604; if not, perform step S605.

[0198] S604, if the topic is registered, return the Topic_struct.

[0199] S605, if the topic is not registered, create a new Topic_struct at the topic_num_ index position (i.e., the first unused area) of the topic_struct according to the current topic_num_.

[0200] S606, update the field information in the newly created Topic_struct, including topic_vaild_, topic_id_, topic_len_, and topic_str_. Update the current segment_offset_, which represents the actual offset address of the current topic in the SHM. Update block_num_ and block_buffer_size_, which are set by the qos.

[0201] S607, update next_valid_segment_offset_ and topic_num_ in the Header.

[0202] S608, allocate the segment area and the notify area, and initialize them.

[0203] S609, return the SHM Header spin lock.

[0204] In some embodiments, the SUB Publish stage can be implemented through steps S610 to S614:

[0205] S610, operate the notify, and atomically obtain next_seq_ in notify_state.

[0206] S611 reads the notify info in sequence. The segments in the notify info are all already written. This design effectively supports multiple writers writing to a single topic. Compare this to notify_seq to prevent overwrites.

[0207] S612: Read the segment seq_ index corresponding to the notify info and attempt to acquire the read-write lock on the block using read mode. Compare the seq_ in the segment_block to prevent overwriting.

[0208] S613. Use seq_ as the index to read the block and data information.

[0209] S614: Release the read-write lock of BLCOK.

[0210] The inter-core communication method provided in the embodiments of the present application has relatively simple system portability requirements. A shared memory that can be mapped by both parties is sufficient, enabling efficient structural layout: pre-allocated memory and a compact structure suitable for robot embedded systems; multiple cores share a shared memory, supporting multi-core data sharing and removing the RPMsg end-to-end channel restrictions; innovative inter-core communication in the robot supports a distributed pub / sub model, dynamically creating pub / sub nodes based on topic indexes. Dynamically allocates shared memory areas corresponding to different topics. This greatly facilitates the application layer's requirements for a distributed publish-subscribe model for data communication; supports flexible configuration of the number and size of buffers. It can adapt to the different data reading and writing requirements of different applications, such as large data volumes and high-frequency data; supports multiple readers / writers, improving communication bandwidth. A relatively comprehensive data asynchronous security mechanism is designed, with multiple atomic operation mechanisms to ensure data security when concurrently reading and writing the same topic; abstracts a more user-friendly application layer interface and supports dynamic attribute configuration based on QoS; all cores have equal rights, without master-slave role definitions, greatly facilitating application development and increasing development flexibility; and cross-core communication has low latency. It supports zero-copy data, and the reader can operate on shared memory to improve communication efficiency; the notification mechanism supports a polling mechanism that can be flexibly configured.

[0211] Based on the above embodiments, the present invention further provides an inter-core communication device. Figure 7 This is a schematic diagram of the structure of the inter-core communication device provided in the embodiment of the present application. Figure 7As shown, the inter-core communication apparatus 700 includes a determining module 701, a generating module 702, and an obtaining module 703. The determining module 701 is configured to, in response to a first processor of a robot receiving a registration request for a to-be-published topic, determine a data storage space of the to-be-published topic in a shared memory of the robot. The generating module 702 is configured to write target data corresponding to the to-be-published topic into the data storage space by the first processor, and generate a sequence number of the to-be-published topic. The obtaining module 703 is configured to periodically query, by a second processor of the robot, a sequence number of a subscribed topic, and obtain data in the subscribed topic in a case where the sequence number of the subscribed topic is updated.

[0212] In some embodiments, the shared memory includes a meta-information region. The inter-core communication apparatus further includes a locking module configured to acquire, by the first processor, a spin lock of the shared memory, and lock the shared memory. The determining module 701 is further configured to traverse, based on a topic name of the to-be-published topic, a topic information structure body of the meta-information region, and determine historical registration information of the to-be-published topic. Based on the historical registration information, the data storage space is determined in the shared memory. Correspondingly, after the data storage space is determined, the inter-core communication apparatus further includes an unlocking module configured to, by the first processor, unlock the spin lock.

[0213] In some embodiments, the determining module 701 is further configured to, in response to the historical registration message representing that the to-be-published topic does not exist in the shared memory, perform registration of the to-be-published topic based on a number of topics in the shared memory, determine a topic index of the to-be-published topic and the data storage space. The data storage space is an unused region in the shared memory. In response to the historical registration message representing that the to-be-published topic exists in the shared memory, a data region corresponding to the to-be-published topic in the shared memory is determined as the data storage space.

[0214] In some embodiments, after the to-be-published topic is registered, the inter-core communication apparatus further includes an updating module configured to update field information of the to-be-published topic in the topic information structure body. The field information at least includes a topic valid identifier, a topic name, a topic name length, and a topic name string. Storage region information of the data storage space corresponding to the to-be-published topic is updated. The storage region information at least includes a starting offset of the data storage space in the shared memory, a number of data blocks, and a size of each data block.

[0215] In some embodiments, the shared memory further comprises a storage area; the generating module 702 is further configured to perform an atomic self-increment operation on a storage index of the data storage space by the first processor to obtain an updated index of the data storage space; based on the updated index of the data storage space, acquire a data block corresponding to the updated index in the storage area and a read-write lock corresponding to the data block; write the target data corresponding to the to-be-posted topic into the data block corresponding to the updated index in a byte alignment manner to generate a serial number of the to-be-posted topic.

[0216] In some embodiments, the shared memory further comprises an event notification area; before generating the serial number of the to-be-posted topic, the inter-core communication device further comprises: an updating module configured to update data effective length and data identification of the data block corresponding to the updated index and release the read-write lock corresponding to the data block; and a recording module configured to record a topic name and a data version of the to-be-posted topic in the event notification area.

[0217] In some embodiments, the inter-core communication device further comprises: a locking module configured to acquire a spin lock of the shared memory by the second processor and lock the shared memory; a registration module configured to, in response to the absence of a to-be-registered topic of the second processor in a meta-information area of the shared memory, register the to-be-registered topic in a topic information structure body of the meta-information area to obtain the subscribed topic of the second processor and update field information of the subscribed topic; an allocation module configured to allocate a subscription storage area for the subscribed topic and record the subscribed topic in an event notification area in the memory area; and a releasing module configured to release the spin lock by the second processor.

[0218] In some embodiments, the acquiring module 703 is further configured to read notification information of the subscribed topic in the subscription storage area, determine a data version of a written data block corresponding to the subscribed topic, acquire a read-write lock of the written data block in a read mode, determine data identification in the written data block, compare the data version and the data identification to obtain a comparison result, and acquire data in the written data block in response to the comparison result representing that the data version is consistent with the data identification.

[0219] The description of the inter-core communication device in the embodiments of the present application is similar to the description of the inter-core communication method described above, has similar beneficial effects as the inter-core communication method, and thus is not described herein. For technical details not disclosed in the embodiments, please refer to the description of the inter-core communication method of the present application for understanding.

[0220] Figure 8 is a hardware entity schematic diagram of a robot provided in an embodiment of the present application, as Figure 8 As shown, the hardware entity of the electronic device 80 includes: a processor 801, a communication interface 802 and a memory 803, wherein:

[0221] The processor 801 generally controls the overall operation of the electronic device 80. Here, the processor may include at least a first processor and a second processor, and the processor is not limited to only include the first processor and the second processor.

[0222] The communication interface 802 enables the electronic device to communicate with other terminals or servers through a network.

[0223] The memory 803 is configured to store instructions and applications executable by the processor 801, and can also cache data to be processed or processed by the processor 801 and various modules in the electronic device 80 (for example, image data, audio data, voice communication data, and video communication data). This can be implemented using flash memory (FLASH) or random access memory (RAM). Data can be transmitted between the processor 801, the communication interface 802, and the memory 803 via a bus 804.

[0224] It should be noted that the description of the above storage medium and device embodiments is similar to the description of the above method embodiments and has similar beneficial effects as the method embodiments. For technical details not disclosed in the storage medium and device embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0225] The embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon, which implements the above-mentioned inter-core communication method when executed by a processor. The computer-readable storage medium can be transient or non-transient.

[0226] An embodiment of the present application provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program, and when the computer program is read and executed by a computer, implements some or all of the steps in the above method. The computer program product can be implemented specifically by hardware, software, or a combination thereof. In an optional embodiment, the computer program product is embodied as a computer storage medium. In another optional embodiment, the computer program product is embodied as a software product, such as a software development kit (SDK), etc.

[0227] In some embodiments, the storage medium can be a computer-readable storage medium, such as a ferromagnetic random access memory (FRAM), a read only memory (ROM), a programmable read only memory (PROM), an erasable programmable read only memory (EPROM), an electrically erasable programmable read only memory (EEPROM), a flash memory, a magnetic surface storage, an optical disk, or a compact disk-read only memory (CD-ROM), and the like. It can also be various devices including one or any combination of the above memories.

[0228] In some embodiments, the executable instructions can take the form of a program, software, software modules, scripts, or code, written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages; and they can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0229] As an example, the executable instructions can or can not correspond to a file in a file system, can be stored in a part of a file that holds other programs or data, such as one or more scripts stored in a hypertext markup language (HTML) document, in a single file dedicated to the program in question, or in multiple coordinated files, such as files that store one or more modules, sub programs, or portions of code. The executable instructions may, for example, be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

[0230] The above description is only some embodiments of the present application, and is not intended to limit the protection scope of the present application. Any modification, equivalent replacement, and improvement within the spirit and scope of the present application shall be included in the protection scope of the present application.

[0231] It should be understood that the term "one embodiment" or "an embodiment" as used herein means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the application. The appearances of the phrase "in one embodiment" or "in an embodiment" in various places in the specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that the sequence of steps in the above-described embodiments can not necessarily be the only sequence of steps, and that the embodiments can be carried out in other sequences than the one described. The above-described embodiments are merely exemplary and do not limit the scope of the application.

[0232] It should be noted that, as used in this document, the terms "includes," "including," "has," "having" or the like are intended to be open-ended: thus, a process, method, article, composition or apparatus that includes, has or comprises a list of elements is not limited to processes, methods, articles, compositions or apparatuses that consist only of those elements but can include other elements not expressly listed or inherent to such process, method, article, composition or apparatus. In other words, it is contemplated that the process, method, article, composition or apparatus that "includes", "has" or "comprises" one or more features, favors also including other features, unless the context clearly indicates otherwise. In the several embodiments provided in the application, it should be understood that the disclosed apparatus and methods might be implemented in other ways. The above-described apparatus embodiments are merely illustrative, for example, the division of the units is only a logical function division, and actual implementation can have another division manner, for example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed.

[0233] The above describes only the embodiments of the application, but the protection scope of the application is not limited thereto. Any skilled person in the art can easily think of changes or replacements within the technical range disclosed in the application, which should be covered in the protection scope of the application. Therefore, the protection scope of the application should be subject to the protection scope of the claims.

Claims

1. A method for inter-core communication, characterized in that: The inter-core communication method includes: In response to a registration request for a topic to be published by a first processor of the robot, determining a data storage space for the topic to be published in a shared memory of the robot; The first processor writes the target data corresponding to the to-be-published topic into the data storage space, and generates a serial number of the to-be-published topic; The second processor of the robot periodically queries the serial number of the subscribed topic, and obtains the data in the subscribed topic when the serial number of the subscribed topic is updated.

2. The inter-core communication method according to claim 1, wherein: The shared memory includes a meta-information area; and the inter-core communication method further includes: The first processor acquires the spin lock of the shared memory and locks the shared memory; Correspondingly, determining the data storage space of the to-be-published topic in the shared memory of the robot includes: The first processor traverses the topic information structure of the meta information area based on the topic name of the topic to be published, and determines the historical registration information of the topic to be published; The first processor determines the data storage space in the shared memory based on the historical registration information; Correspondingly, after determining the data storage space, the inter-core communication method further includes: The first processor releases the spin lock.

3. The inter-core communication method according to claim 2, wherein: The first processor determines the data storage space in the shared memory based on the historical registration information, including: In response to the historical registration message indicating that the to-be-published topic does not exist in the shared memory, the first processor registers the to-be-published topic based on the number of topics in the shared memory, and determines a topic index of the to-be-published topic and the data storage space; the data storage space is an unused area in the shared memory; In response to the historical registration message indicating that the to-be-published topic exists in the shared memory, the first processor determines a data area corresponding to the to-be-published topic in the shared memory as the data storage space.

4. The inter-core communication method according to any one of claims 1 to 3, characterized in that: After the to-be-published topic is registered, the inter-core communication method further includes: The first processor updates the field information of the to-be-published topic in the topic information structure, wherein the field information includes at least a topic valid identifier, a topic name, a topic name length, and a topic name character string; The first processor updates the storage area information of the data storage space corresponding to the to-be-published topic; the storage area information at least includes the starting offset of the data storage space in the shared memory, the number of data blocks and the size of each data block.

5. The inter-core communication method according to any one of claims 1 to 4, characterized in that: The shared memory further includes a storage area; the first processor writes the target data corresponding to the to-be-published topic into the data storage space, and generates a serial number of the to-be-published topic, including: The first processor performs an atomic self-increment operation on the storage index of the data storage space to obtain an updated index of the data storage space; The first processor acquires, based on the update index of the data storage space, a data block corresponding to the update index in the storage area and a read-write lock corresponding to the data block; The first processor writes the target data corresponding to the to-be-published topic into the data block corresponding to the update index in a byte-aligned manner, and generates a serial number of the to-be-published topic.

6. The inter-core communication method according to claim 5, characterized in that: The shared memory further includes an event notification area; before generating the serial number of the to-be-published topic, the inter-core communication method further includes: The first processor updates the valid length and data identifier of the data block corresponding to the update index, and releases the read-write lock corresponding to the data block; The first processor records the topic name and data version of the to-be-published topic in the event notification area.

7. The inter-core communication method according to any one of claims 1 to 6, characterized in that: The inter-core communication method further includes: The second processor acquires the spin lock of the shared memory and locks the shared memory; In response to the fact that the subject to be registered of the second processor does not exist in the meta information area of ​​the shared memory, the second processor registers the subject to be registered and its corresponding subject in the subject information structure of the meta information area, obtains the subscribed subject of the second processor, and updates the field information of the subscribed subject; The second processor allocates a subscription storage area for the subscribed topic, and records the subscribed topic in an event notification area in the memory area; The second processor releases the spin lock; and / or, When the sequence number of the subscribed topic is updated, obtaining the data in the subscribed topic includes: The second processor reads the notification information of the subscribed topic in the subscription storage area, and determines the data version of the written data block corresponding to the subscribed topic; The second processor obtains the read-write lock of the data block in a read mode, and determines the data identifier in the data block; The second processor compares the data version with the data identifier to obtain a comparison result; In response to the comparison result indicating that the data version is consistent with the data identifier, the second processor obtains the data in the written data block.

8. An inter-core communication device, characterized in that: The inter-core communication device includes: a determination module, configured to determine, in response to a registration request for a topic to be published by a first processor of the robot, a data storage space for the topic to be published in a shared memory of the robot; A generating module, configured for the first processor to write the target data corresponding to the to-be-published topic into the data storage space, and to generate a serial number of the to-be-published topic; An acquisition module is used for the second processor of the robot to periodically query the serial number of the subscribed topic, and when the serial number of the subscribed topic is updated, obtain the data in the subscribed topic.

9. A robot, characterized in that: The robot comprises: A memory for storing executable instructions; a processor, comprising at least a first processor and a second processor, for implementing the inter-core communication method according to any one of claims 1 to 7 when executing the executable instructions stored in the memory.

10. A computer-readable storage medium, characterized in that Executable instructions are stored, which are used to cause a processor to execute the executable instructions to implement the inter-core communication method according to any one of claims 1 to 7.

Images