A heterogeneous dual-core lock-free shared memory communication method and system based on multi-dimensional attribute classification

CN122884884APending Publication Date: 2026-10-09SHANGHAI INESA ELECTRONICS (GRP) CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202611090283.2
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-07-22
Publication Date
2026-10-09

AI Technical Summary

Technical Problem

[0005]第一,通信策略单一,缺乏对数据多维属性的系统性识别与差异化处理

Benefits of technology

[0066]1.四层物理隔离实现通道间零串扰与故障域隔离

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122884884A_ABST
    Figure CN122884884A_ABST
Patent Text Reader

Abstract

The application discloses a heterogeneous dual-core lock-free shared memory communication method and system based on multi-dimensional attribute classification, and is applied to a heterogeneous dual-core system of an automobile instrument. The method comprises the following steps: performing attribute analysis of three dimensions of real-time performance, reliability and batch on inter-core communication data at a sending end, and dividing the inter-core communication data into at least three message categories; allocating independent buffer region areas isolated by physical addresses to each message category in a shared memory, and associating independent hardware notification types; configuring receiving processing tasks with different priorities for each message category at a receiving end, and corresponding the hardware interrupt priority and the task priority; and adopting ring multi-slot writing and notification carrying accurate addresses to realize lock-free synchronization. The application further discloses a corresponding communication system. The application realizes zero crosstalk between channels, delay determinacy, lock-free synchronization and fine management of cache consistency, and can support ISO 26262 functional safety authentication.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of automotive electronic embedded systems technology, and more specifically to a data communication method and system for heterogeneous multi-core processors. Background Technology

[0002] Modern high-end automotive instrument clusters generally employ a heterogeneous multi-core processor architecture. The first processor core (typically a microcontroller based on the ARM Cortex-M series architecture) focuses on real-time control and vehicle bus communication, handling data transmission and reception for the vehicle's communication bus (such as the CAN bus), acquisition of hard-wired sensor signals, and determination of vehicle alarm strategies. The second processor core (typically an application processor based on the ARM Cortex-A series architecture) focuses on graphics processing and user interaction, handling the rendering of the LCD instrument cluster's human-machine interface, multimedia information integration, and multi-theme switching management. Both processor cores access the same shared memory via an on-chip high-speed bus, using this shared memory as the physical medium for data exchange.

[0003] In automotive instrument systems, cross-core data transmissions exhibit fundamental differences in real-time requirements, reliability requirements, and transmission batches: vehicle operating parameter data is characterized by high real-time performance and high periodicity, with a maximum allowable latency typically ranging from a few milliseconds to tens of milliseconds, and an update frequency of tens to hundreds of times per second; firmware upgrade data has high reliability requirements with zero error tolerance and large-block transmission characteristics, with single transmissions reaching tens of KB to several MB, but it only occurs occasionally in upgrade scenarios; system log data, on the other hand, is characterized by low real-time performance, batch generation, and tolerance for relatively large processing delays.

[0004] Existing inter-nuclear communication technologies have the following main shortcomings:

[0005] First, the communication strategy is simplistic and lacks a systematic identification and differentiated processing of the multidimensional attributes of data. Existing technical solutions typically partition memory only according to data size or use a simple dichotomy of "real-time / non-real-time" for classification. They fail to establish a systematic analysis mechanism at the sending end that covers the three dimensions of real-time performance, reliability, and batch processing, resulting in mutual interference when different types of data are transmitted in the same communication channel.

[0006] Second, shared memory only implements logical partitioning and does not achieve physical isolation of communication channels. Although existing technical solutions divide the shared memory into different buffers, they still use a unified hardware interrupt notification mechanism and a unified receiving and processing task. Different types of data share the same processing context at the receiving end, and crosstalk between channels cannot be eliminated at the hardware level. After an interrupt is triggered, the data type still needs to be determined by software. High-bandwidth data occupies storage bus bandwidth, resulting in jitter in the access latency of high real-time data.

[0007] Third, the synchronization mechanism is singular and relies on locks or polling, which introduces deterministic issues. Existing technical solutions either uniformly use interrupt notifications, resulting in significant context switching overhead for high-frequency data, uniformly use polling, leading to uncontrollable delays in critical data, or uniformly use mutexes / spin locks, resulting in priority inversion and deadlock risks. They cannot match differentiated synchronization strategies for different data types.

[0008] Fourth, the cache coherence problem lacks a systematic and refined handling process. In heterogeneous dual-core shared memory architectures, each processor core has its own independent cache (such as L1 and L2 caches), and typically lacks support for inter-processor hardware cache coherence protocols. Existing technical solutions to this problem are mostly ad-hoc, either configuring the entire shared memory in non-cached mode (significantly sacrificing performance) or performing a full cache flush (high overhead and affecting other data areas), without forming a standardized and refined management process bound to specific slot addresses.

[0009] To address the above shortcomings, this invention provides a heterogeneous dual-core lock-free shared memory communication method and system based on multi-dimensional attribute classification. Summary of the Invention

[0010] The purpose of this invention is to provide a data communication method and system for heterogeneous multi-core processors to solve the problems existing in the prior art.

[0011] The above-mentioned technical objective of the present invention is achieved through the following technical solution:

[0012] A heterogeneous dual-core lock-free shared memory communication method based on multi-dimensional attribute classification is applied to a heterogeneous dual-core system containing a first processor core and a second processor core, wherein the first processor core and the second processor core exchange data through shared memory, and includes the following steps:

[0013] Data classification steps: At the sending end, perform multidimensional attribute analysis on the inter-core communication data to be transmitted. The multidimensional attributes include at least real-time dimension, reliability dimension, and batch dimension. Based on the analysis results, divide the inter-core communication data into at least three message categories.

[0014] Channel isolation steps: Allocate independent buffer areas with non-overlapping physical addresses for each type of message in the shared memory, and associate each type of message with an independent hardware notification type, forming an independent communication channel with dual physical isolation of address space and notification channel;

[0015] Differentiated scheduling steps: Create an independent receiving and processing task for each type of message at the receiving end. Different types of receiving and processing tasks are configured with different task priorities, and the task priorities are matched with the corresponding hardware notification interrupt priorities.

[0016] Lock-free synchronization steps: The sending end adopts a ring multi-slot writing strategy. After writing data to the current slot, it sends a hardware notification carrying the precise address information of the current slot to the receiving end. The receiving end passively reads the data of the corresponding slot according to the address information carried in the hardware notification. The sending end and the receiving end operate on different slots at the same time, without the need for mutex locks or spinlocks.

[0017] Furthermore, in the data classification step:

[0018] The real-time dimension is measured by the maximum allowable latency, the reliability dimension is measured by the allowable bit error rate or the required check strength, and the batch size dimension is measured by the typical transmission scale and generation frequency of the data.

[0019] Based on the three-dimensional attribute analysis results, the inter-core communication data is divided into three categories: the first category of messages with high real-time performance and high periodicity, the second category of messages with high reliability and large-block transmission and occasional transmission, and the third category of messages with low real-time performance and batch transmission.

[0020] Furthermore, in the channel isolation step, the independent buffer area implements four layers of physical isolation:

[0021] Address space isolation ensures that the physical address ranges of buffers for different message types do not overlap in shared memory;

[0022] Interrupt channels are isolated, and different message categories are associated with different hardware notification types. Each notification type corresponds to an independent hardware interrupt line or hardware interrupt identifier.

[0023] Context isolation is implemented, with different message categories being handled independently by different receiving and processing tasks;

[0024] Cache operations are isolated; cache refresh and cache invalidation operations are performed only on the precise address range of the corresponding slot.

[0025] Furthermore, the sending end performs the following steps:

[0026] S1: Retrieve the data frame to be sent, check the priority queue of each channel, and retrieve the first frame to be sent from the queue.

[0027] S2: Perform multidimensional attribute analysis on the retrieved data frame to determine the message category to which the data frame belongs, and select the target data area corresponding to the message category;

[0028] S3: Encapsulate data frames according to the communication protocol format, and assemble the frame header, payload, and checksum;

[0029] S4: Obtain the current write slot index of the target data area's circular buffer, write the encapsulated data frame to the slot indicated by the current write slot index, and perform a cache refresh operation on the precise address range corresponding to the slot after writing is completed;

[0030] S5: Assemble a hardware notification message. The hardware notification message includes at least a data start address field, a data length field, and a channel type field. Assign the physical start address of the shared memory of the currently written slot to the data start address field, assign the byte length of the written data frame to the data length field, and send the hardware notification.

[0031] S6: Move the write slot index to the next slot and release the current slot;

[0032] The receiving end performs the following steps:

[0033] R1: Hardware notification interrupt triggered, the corresponding interrupt line wakes up the receiving and processing task of the corresponding priority.

[0034] R2: Parse the received hardware notification message structure and extract the data start address and data length;

[0035] R3: Perform a cache invalidation operation on the precise address range indicated by the data start address and the data length, invalidate the local cache, and force a reload from the shared memory;

[0036] R4: Starting from the data start address, passively read data frames from the shared memory according to the data length;

[0037] R5: Performs integrity verification on the read data frames, verifying the synchronization identifier and checksum;

[0038] R6: After successful verification, the data frame is delivered to the upper-layer application processing queue.

[0039] Furthermore, in step S4, after the sending end completes the writing of the data frame but before sending the hardware notification, it performs a cache refresh operation on the precise address range corresponding to the slot. The starting address and length of the refresh strictly match the slot address and data length written this time.

[0040] The hardware notification in step S5 is sent after the cache refresh is complete.

[0041] In step S6, the sending end increments the write slot index and takes the modulo of the total number of slots;

[0042] In step R3, after receiving the hardware notification and before reading data from the address specified in the notification, the receiving end performs a cache invalidation operation on the precise address range indicated by the data start address and the data length.

[0043] The total number of slots in the circular buffer satisfies the following condition: the ratio of the maximum time for the receiver to complete processing a single slot to the shortest time for the transmitter to fill all other slots except the current slot is greater than a safety threshold.

[0044] Furthermore, in the differentiated scheduling step:

[0045] Configure the highest hardware interrupt priority and the highest task priority for the second type of message, and bind the highest priority hardware interrupt line;

[0046] Configure the second-highest hardware interrupt priority and the second-highest task priority for the first type of message, and bind the second-highest priority hardware interrupt line;

[0047] Configure the lowest hardware interrupt priority and the lowest task priority for the third type of message, and bind the lowest priority hardware interrupt line;

[0048] High-priority hardware interrupts can preempt low-priority hardware interrupts at the hardware level, and high-priority tasks can preempt low-priority tasks.

[0049] Furthermore, the first type of message adopts the latest-first-time strategy, where newly arrived data overwrites the slot where old data is located or is written to the next free slot, and the receiving end only processes the latest arriving data;

[0050] The second type of message adopts a full-reliability timeliness strategy, where each frame of data must be successfully received and verified. When all slots are filled with unprocessed data, the sender is blocked and waits.

[0051] The third type of message adopts a "batch accumulation" timeliness strategy, where multiple data entries are accumulated at the sending end to reach a preset threshold or meet a preset time condition before being written in batches and triggering a notification.

[0052] Furthermore, it also includes channel adaptive configuration steps:

[0053] The configuration parameters of each independent communication channel are adapted and configured during system initialization based on the multidimensional attribute analysis results of the corresponding message category. The configuration parameters include the number of ring buffer slots, the capacity of a single slot, and the notification trigger threshold.

[0054] During system operation, the sending end continuously counts the backlog of data to be sent in each channel and the processing delay at the receiving end. When the backlog is detected to continuously exceed the first threshold or the processing delay exceeds the second threshold, the configuration parameters of the channel are automatically adjusted. The adjustment includes: increasing or decreasing the number of slots, switching the notification triggering strategy from frame-by-frame notification to accumulated notification or from accumulated notification to frame-by-frame notification.

[0055] Once the backlog returns to normal levels, the configuration parameters will revert to their default values.

[0056] Furthermore, it also includes independent health monitoring procedures for each channel:

[0057] The sending end maintains an independent health status record for each independent communication channel. The health status record includes at least one or more of the following monitoring indicators: notification transmission success rate, data frame verification failure rate, number of times the buffer is close to full, and average end-to-end latency.

[0058] When the health indicators of any channel exceed the preset range, a tiered response is triggered: Level 1 response is to suspend the transmission of new data by that channel and wait for the backlog of data to be processed; Level 2 response is to dynamically adjust the configuration parameters of that channel, including one or more of the following: number of slots, notification trigger frequency, and verification algorithm strength; Level 3 response is to report the abnormal status of that channel to the system monitoring module through another communication channel and record it in the log channel.

[0059] A heterogeneous dual-core lock-free shared memory communication system based on multi-dimensional attribute classification is applied to a heterogeneous dual-core system containing a first processor core and a second processor core. The first processor core and the second processor core exchange data through shared memory, including:

[0060] A data multidimensional attribute identification and classification unit is set at the sending end. It is used to perform multidimensional attribute analysis on the inter-core communication data to be transmitted, including at least real-time dimension, reliability dimension and batch dimension, and divide the inter-core communication data into at least three message categories according to the analysis results.

[0061] The shared memory multi-region physical isolation unit is used to allocate independent buffer areas with non-overlapping physical addresses for each type of message in the shared memory, and to configure independent data structures for each type of message;

[0062] An independent hardware notification unit is used to associate an independent hardware notification type with each type of message. After the sending end completes the data writing, it sends a notification to the receiving end through the corresponding hardware notification type.

[0063] A two-level differentiated scheduling unit is set at the receiving end to create an independent receiving and processing task for each type of message. Different types of receiving and processing tasks are configured with different task priorities, and the task priorities are matched with the corresponding hardware notification interrupt priorities.

[0064] The lockless synchronization unit is used to control the sending end to send a hardware notification carrying the precise address information of the current slot after writing data to the current slot using a ring multi-slot writing strategy, and to control the receiving end to passively read the data of the corresponding slot according to the address information carried in the hardware notification, so that the sending end and the receiving end can operate on different slots at the same time.

[0065] In summary, the present invention has the following beneficial effects:

[0066] 1. Four-layer physical isolation achieves zero crosstalk between channels and fault domain isolation.

[0067] Existing technologies only perform logical partitioning and share a single hardware interrupt, leading to interference between different types of data in the same channel. This invention achieves end-to-end physical isolation from hardware to software through four levels: independent buffer areas with non-overlapping physical addresses, independent hardware interrupt lines, independent receiving and processing tasks, and cache maintenance operations that target only a precise address range for a single slot.

[0068] 2. Architectural lock-free design eliminates dependencies on synchronization primitives.

[0069] Existing technologies relying on mutexes, spinlocks, or flag polling inherently suffer from priority inversion, deadlocks, and nondeterministic delays. This invention addresses these issues through a triple lock-free protection mechanism: atomic pairing of writes and notifications (notification precedes index movement, ensuring data is fully visible before notifying the receiver), purely passive receiver processing (no scanning or polling, naturally avoiding read / write concurrency conflicts in terms of timing), and redundant guarantee of the total number of slots (a safety margin of at least twice, ensuring slots are released before the write index loopback). This completely eliminates read / write contention at the architectural level, rather than the software level, resulting in deterministic and predictable inter-core communication latency.

[0070] 3. Single-slot precise cache management balances consistency and high performance.

[0071] Existing technologies often handle cache coherency by configuring the entire shared memory in non-cached mode (significantly impacting performance) or performing a full cache refresh (high overhead and affecting other data areas), resulting in coarse-grained cache maintenance. This invention, through a three-stage cache management process, refines cache maintenance to a "single slot" level. It operates only on cache lines within the address range of the current data, and the refresh start address and length strictly match the slot address and data length being written, without affecting other slots or other data areas. This reduces cache operation overhead and does not rely on inter-processor hardware cache coherency protocols.

[0072] 4. Two-level priority scheduling of hardware interrupts and software tasks.

[0073] Existing technologies mostly employ single-software task priority scheduling, where high-priority tasks must wait for operating system scheduling, resulting in uncertain response delays. This invention utilizes a two-level linkage scheduling system combining hardware interrupt priority and software task priority. It binds high-security data (firmware upgrades) to the highest-priority hardware interrupt line and the highest-priority task, allowing high-priority interrupts to directly preempt the current execution context at the hardware level, rather than relying solely on operating system software scheduling. This end-to-end hardware-to-software approach ensures priority response for critical data, and the upper bound of critical data latency can be precisely quantified.

[0074] 5. Precise matching of data timeliness strategy and transmission characteristics

[0075] In existing technologies, three types of data share the same timeliness strategy, which may lead to the overwriting and loss of real-time data or unnecessary interruption overhead caused by non-real-time data. This invention configures differentiated timeliness strategies for the three types of messages: high real-time periodic business data adopts "latest priority" (new frames overwrite old frames or write to the next free slot, maintaining only the latest value, naturally avoiding queue overflow); high-reliability upgrade data adopts "full reliability" (blocking and waiting to ensure zero loss); and low real-time log data adopts "accumulation batch" (batch triggering after accumulation reaches a threshold, reducing interruption frequency). The processing method for each type of data is precisely matched with its real-time and reliability requirements, and resource investment is proportional to demand. Attached Figure Description

[0076] Figure 1 This is an architecture diagram of the heterogeneous dual-core lock-free shared memory communication system described in this invention.

[0077] Figure 2 This is a flowchart illustrating the interaction between the sending end and the receiving end as described in this invention.

[0078] Figure 3 This is a timeline comparison chart of the three types of data priority scheduling described in this invention. Detailed Implementation

[0079] To make the technical means, creative features, objectives and effects of this invention easier to understand, the invention will be further described below with reference to the figures and specific embodiments.

[0080] I. System Architecture and Hardware Configuration

[0081] This implementation method uses an automotive instrument system as an example for explanation. Figure 1 As shown, the system includes a first processor core (sender) and a second processor core (receiver). The two processor cores access the same shared memory (i.e., DDR memory) through an on-chip high-speed bus and use a hardware notification module (Mailbox) to notify cross-core events.

[0082] In this embodiment, the first processor core is a microcontroller based on the ARM Cortex-M series architecture (e.g., Cortex-M7), running a lightweight real-time operating system (RTOS), responsible for transmitting and receiving vehicle CAN bus data, acquiring hard-wired sensor signals, and determining vehicle alarm strategies. The second processor core is an application processor based on the ARM Cortex-A series architecture (e.g., Cortex-A53), running a real-time operating system or Linux system, responsible for graphics rendering of the human-machine interface, multimedia information integration, and user interaction.

[0083] The shared memory is Double Data Rate Synchronous Dynamic Random Access Memory (DDR memory), accessed by both processor cores via an on-chip high-speed bus. The hardware notification module is a Mailbox module, supporting multiple independent notification message types. Each notification type corresponds to an independent hardware interrupt line or hardware interrupt identifier, and its hardware interrupt priority can be configured independently. The Mailbox module supports at least three independent hardware interrupt lines.

[0084] In heterogeneous dual-core architectures, each processor core has its own independent data cache (L1 D-Cache), and they typically lack support for inter-processor hardware cache coherency protocols. Therefore, this invention ensures data consistency through a standardized cache management process.

[0085] II. System Initialization Phase

[0086] After the system is powered on, the initial configuration is executed first.

[0087] (I) Registration and Classification Configuration of Multidimensional Data Attributes

[0088] The multi-dimensional attribute identification and classification unit of the first processor core registers and analyzes all data sources in the system that need to be transmitted across cores.

[0089] Specifically, the first processor core iterates through all registered data source modules in the system (including the CAN communication module, sensor acquisition module, firmware upgrade management module, log recording module, etc.) to obtain the output data attribute information of each data source module. For each data source, at least three dimensions of attribute parameters are extracted:

[0090] In terms of real-time performance, the maximum allowable delay time for the data is read from the configuration information of the data source module. For example, the vehicle speed signal is registered with a maximum allowable delay of no more than 5 milliseconds, and the alarm indicator status signal is registered with a maximum allowable delay of no more than 15 milliseconds.

[0091] In terms of reliability, the required verification strength level is read from the configuration information of the data source module. For example, firmware upgrade data registration requires CRC32 end-to-end complete verification, while periodic business data registration requires CRC16 verification.

[0092] In terms of batch size, the typical frame length and update cycle of the data are read from the configuration information of the data source module. For example, periodic vehicle operation parameter data is registered as approximately 200 bytes per frame with an update cycle of 20 milliseconds; firmware upgrade fragment data is registered as up to 64KB per instance and occurs sporadically; system log data is registered as up to 32KB in batches and occurs at an unpredictable frequency.

[0093] Based on the above three-dimensional attribute analysis results, the first processor core maps each data source to its corresponding message category:

[0094] Periodic vehicle operating parameter data (vehicle speed, RPM, temperature, pressure, fluid level, mileage, time, gear status, driving mode, indicator light status, etc.) are mapped to the first type of message (business message);

[0095] The firmware upgrade data fragments (update data such as system firmware, graphics resources, and configuration parameters) are mapped to the second type of message (upgrade message);

[0096] System operation record data (operation status information, abnormal event records, debugging and diagnostic data, etc.) are mapped to a third type of message (log message).

[0097] (II) Shared Memory Multi-Sector Physical Isolation Configuration

[0098] Three independent buffer regions with non-overlapping physical addresses are established in the shared memory, with the following specific configuration:

[0099] The first data area (corresponding to the first type of message): configured as a circular buffer with 128 slots, each slot having a capacity of 256 bytes. This data area is associated with the first type of hardware notification (Mailbox first message type) and bound to the second highest priority hardware interrupt line. The physical address range of the first data area is predefined in the system linker script and does not overlap with the addresses of the second and third data areas.

[0100] The selection of 128 slots is based on the following calculations: the transmission period of a service data frame is 20 milliseconds, and the time for the receiving end to process a single frame of service data is approximately 2 to 3 milliseconds. The shortest time required for the sending end to fill 127 slots (total slots 128 minus 1) is 127 × 20 milliseconds = 2540 milliseconds, while the time for the receiving end to complete processing a single slot is only 2 to 3 milliseconds. The ratio between the two is far greater than the 2x safety margin requirement. Therefore, when the sending end's write index loop returns to slot K after one cycle, slot K has already been processed and released by the receiving end.

[0101] The second data area (corresponding to the second type of message): configured as a circular buffer with four large-capacity slots, each slot having a capacity of 66KB, sufficient to hold a complete firmware upgrade data fragment (maximum 64KB). This data area is associated with the second type of hardware notification (Mailbox second message type) and bound to the highest priority hardware interrupt line. The second data area is further subdivided into a first-direction sub-area and a second-direction sub-area—the first-direction sub-area is used for upgrade data transmission from the first processor core to the second processor core (such as forwarding the upgrade file from the MCU to the application processor), and the second-direction sub-area is used for upgrade data transmission from the second processor core to the first processor core (such as sending the upgrade confirmation status back from the application processor to the MCU). The physical addresses of the two sub-areas are independent of each other.

[0102] The selection of 4 slots is based on the following considerations: firmware upgrade data is generated sporadically, fragments arrive continuously during the upgrade, and the time for the receiver to process a single fragment (read, verify, and write to the eMMC spare partition) is approximately 50 to 100 milliseconds. 4 slots are sufficient to buffer the continuous arrival of upgrade fragments, while the smaller number of slots reduces memory usage.

[0103] The third data area (corresponding to the third type of message): configured as a batch write area, with a size of 64KB, used for the accumulation and batch transmission of log data. This data area is associated with the third type of hardware notification (Mailbox third message type) and bound to the lowest priority hardware interrupt line.

[0104] (III) Two-level differentiated scheduling configuration

[0105] At the receiving end (second processor core), three independent receiving and processing tasks are created, and a priority is configured for each task:

[0106] The second receiving task (processing second type of messages / upgrade data): configured with the highest priority among all application tasks in the system, and bound to the highest priority hardware interrupt line (IRQ priority configured to the highest). The task's message queue depth is 4 (matching the number of slots in the second data area), and it adopts a blocking wait mode.

[0107] The first receiving task (processing the first type of message / business data) is configured as the second highest priority—lower than the second receiving task but higher than other application tasks in the system (such as graphics rendering tasks, multimedia processing tasks, etc.), and is bound to the second highest priority hardware interrupt line. The task's message queue depth is 128 (matching the number of slots in the first data area), and it adopts a blocking wait mode.

[0108] The third receiving task (processing third-category messages / log data): configured with a priority close to the system idle priority, significantly lower than all other application tasks, and bound to the lowest priority hardware interrupt line. This task also uses a blocking wait mode, but the real-time operating system scheduler only selects this task for execution if no higher-priority task is ready in the system.

[0109] With the above configuration, hardware interrupt priorities correspond one-to-one with software task priorities: the highest priority hardware interrupt wakes up the highest priority task, the second highest priority hardware interrupt wakes up the second highest priority task, and the lowest priority hardware interrupt wakes up the lowest priority task. High-priority hardware interrupts can directly preempt the current execution context of low-priority interrupts at the hardware level.

[0110] like Figure 3 As shown, after completing the priority configuration and physical channel isolation for the three types of messages, the three data areas exhibit a parallel scheduling relationship on the timeline: the first data area (service messages) strictly follows a timed triggering periodic sending pattern in the sequence of frames 0 to 10; the second data area (upgrade messages) is triggered by event sending in the T2~T3 and T7~T8 intervals, horizontally blocking the current periodic frames of the first data area through high-priority preemption (frames 3 and 8 are preempted); the third data area (log messages) sends packets 0 to 4 accumulated at the underlying level in batches using the idle time slots (T4~T5 and T8~T9 intervals) generated during the execution of the first and second data areas. Each of the three channels occupies its own time slot on the timeline, with no channel overlap or bandwidth contention between them.

[0111] III. Normal System Operation Phase – Business Data Communication Process

[0112] During normal system operation, taking the transmission of periodic vehicle operating parameter data as an example, the complete communication process of the first type of message is explained (corresponding to...). Figure 2 The interaction process between S1 and S6 and between R1 and R6.

[0113] S1: Retrieve the data frame to be sent

[0114] The CAN communication module of the first processor core receives a frame of the latest vehicle operating parameter data (including signals such as vehicle speed, RPM, and temperature) from the CAN bus every 20 milliseconds. The interrupt service routine of the first processor core puts the received data frame into the priority queue of each channel at the transmitting end.

[0115] The scheduler at the sending end checks the priority queues of each channel and retrieves the data frame to be sent from the head of the non-empty queue. In a typical scenario, service data frames arrive continuously at a period of 20 milliseconds, and the scheduler continuously retrieves service data frames for transmission according to the period.

[0116] S2: Determine the data category and select the target data area

[0117] The sending end performs multi-dimensional attribute analysis on the data frame to be transmitted. The data frame comes from the CAN communication module, and its registration information indicates that: the maximum allowable delay is 5 milliseconds (real-time dimension: high real-time), the check strength is CRC16 (reliability dimension: low error tolerance), the typical frame length is 200 bytes, and the update cycle is 20 milliseconds (batch dimension: small data, high frequency).

[0118] Based on the above three-dimensional attribute analysis results, the sending end determines the data frame as a first type of message (business message) and selects the first data area as the target data area.

[0119] S3: Encapsulated according to communication protocol format

[0120] The sending end encapsulates the data frame according to a predefined communication protocol format: first, a frame header synchronization identifier is added (e.g., a fixed value of 0xAA55), then the vehicle operating parameter data is filled into the payload area according to the bit field encoding compression method (e.g., 2 bits are used to represent 4 display effects and 3 bits are used to represent 8 driving modes), and finally the CRC16 check code is calculated and appended to the frame tail to form a complete data frame to be sent.

[0121] S4: Retrieve the write index and write it to the slot.

[0122] The sending end obtains the current write slot index of the first data area's circular buffer (assuming the current write slot index is N). The encapsulated data frame is then written to the Nth slot.

[0123] After the write operation is complete, the sending end performs a cache refresh operation on the precise address range corresponding to the slot. Specifically, the sending end uses the cache maintenance operation (D-Cache Clean) of the ARM CP15 coprocessor to write the dirty data in the cache within the address range of the Nth slot back to the physical medium of the shared memory. The refresh starts at the physical address of the Nth slot, and the length is the length of the data frame written this time, without involving cache operations on other slots or other data areas.

[0124] S5: Assemble notification and send

[0125] After the sender confirms that the cache refresh is complete, it assembles the hardware notification message structure. This structure contains three fields:

[0126] Data start address field: assigned the value of the physical start address of the shared memory in slot N;

[0127] The data length field is assigned the length of the data frame written in bytes.

[0128] Channel type field: Assigned the first notification type identifier.

[0129] The sending end calls the Mailbox hardware notification sending interface, specifies the first notification type identifier, and the hardware completes the notification transmission from the first processor core to the second processor core. The notification signal is transmitted through the Mailbox's dedicated interrupt line, without consuming storage data bus bandwidth.

[0130] S6: Move the write index forward to release the slot.

[0131] The sending end moves the write slot index to the next slot—increments the current index N and takes the modulo of the total number of slots 128, i.e., N=(N+1) / 128, and releases the Nth slot for subsequent data frames to be written.

[0132] It's important to note that the write slot index forwarding occurs after the hardware notification has been sent. This means that the sender will not reuse the slot before notifying the receiver, ensuring that the slot's content is complete and available when the receiver receives the notification. Furthermore, due to the redundancy of the 128 slots, when the write index cycles back to slot K, slot K has already been processed and released by the receiver, preventing data overwriting.

[0133] R1: Hardware notification interrupt triggered

[0134] The Mailbox module of the second processor core detects the arrival of a hardware notification of the first notification type, and the corresponding second-highest priority hardware interrupt line is triggered. The hardware interrupt controller, based on the interrupt priority configuration, responds immediately to this interrupt and wakes up the first receiving task if there is no higher priority interrupt (i.e., the interrupt of the second notification type) currently being processed.

[0135] R2: Parse the notification message structure

[0136] After the first receiving task is awakened, it reads the notification message structure in the Mailbox module, extracts the data start address field (the physical start address of the Nth slot), the data length field (the byte length of this data frame), and the channel type field (the first notification type).

[0137] R3: Perform cache invalidation operation

[0138] The first receiving task performs a cache invalidation operation on the precise address range indicated by the data's starting address and length. Specifically, through the ARM CP15 coprocessor's cache maintenance operation (D-Cache Invalidate), the cache lines in the second processor core's local cache corresponding to the address range are invalidated. In this way, even if the second processor core's cache happens to contain old data in the same address range (e.g., an old value cached when reading the Nth slot previously), it will be discarded due to invalidation.

[0139] R4: Read a data frame from the specified address

[0140] The first receive task starts from the data header address and passively reads data frames from shared memory according to their length. Since step R3 invalidates the local cache, this read forces a reload of data from the shared memory physical medium, ensuring that the data read is the most recently written content from the first processor core.

[0141] R5: Verify frame integrity

[0142] The first receiving task performs integrity verification on the read data frames: First, it checks whether the frame header synchronization identifier is 0xAA55, then it recalculates the CRC16 checksum and compares it with the checksum at the end of the frame. If the verification passes, it proceeds to step R6; if the verification fails, the frame is discarded and an error log can be logged.

[0143] R6: Deliver to upper-layer application

[0144] After the verification is successful, the first receiving task decapsulates the data frame, extracts vehicle operating parameters such as vehicle speed, RPM, temperature, and indicator light status, updates the data model in the graphical interface, and drives the instrument display to refresh.

[0145] At this point, the process of transmitting a complete business data frame from the first processor core to the second processor core is complete. Since the first data area has 128 slots and the data frame transmission period is 20 milliseconds, the receiving end takes about 2 to 3 milliseconds to process one frame, and the entire communication process does not require any mutex locks or spinlocks.

[0146] IV. Firmware Upgrade Scenario – Upgrade Data Communication Process

[0147] When the system needs to perform a firmware upgrade (e.g., by initiating a UDS diagnostic session through an external diagnostic device), the transmission of the second type of message (upgrade message) will be used as an example for explanation.

[0148] The first processor core receives fragmented data (approximately 4KB to 64KB per fragment) of the firmware upgrade file via the CAN bus. The data multidimensional attribute identification and classification unit identifies the attributes of the data: reliability requirement is CRC32 zero error tolerance (reliability dimension: high reliability), single transmission volume can reach 64KB, and it is generated intermittently (batch dimension: large-block intermittent), thus classifying it as a second type of message.

[0149] The sender writes the upgrade data fragment to the current slot in the second data area. The second data area is a large-capacity circular buffer with four slots, each with a capacity of 66KB, sufficient to hold a complete upgrade fragment. After writing, the sender flushes the cache for that slot, then assembles the second type of hardware notification and sends it.

[0150] The second receiving task of the second processor core is directly preempted and woken up by the highest priority hardware interrupt. Even if the first receiving task is processing business data at this time, the hardware interrupt controller will immediately respond to the highest priority interrupt according to the priority, and the scheduler will switch to the second receiving task for execution.

[0151] The second receiving task parses the address and length in the notification, invalidates the cache for the corresponding address range, reads the upgrade data fragment from the shared memory, performs CRC32 integrity verification, and writes the fragment to the eMMC spare partition after the verification passes.

[0152] After the upgrade data transmission is complete, the second receiving task releases the processor, and the first receiving task resumes execution. The maximum latency of the service data is only increased by a determinable upper bound in the upgrade fragmentation processing time (approximately 50 to 100 milliseconds), and the latency is completely predictable.

[0153] V. Log Data Communication Process

[0154] Log data (such as running status records, abnormal event records, debugging and diagnostic information, etc.) is continuously generated during the operation of each module.

[0155] The logging module of the first processor core continuously writes log entries to the local buffer. When the accumulated amount reaches a preset threshold (e.g., 32KB), the data multidimensional attribute identification and classification unit classifies it as a third type of message (log message).

[0156] The sending end packages multiple accumulated log entries into the third data area at a fixed offset, and then sends the third type of hardware notification.

[0157] The third receive task of the second processor core is awakened by the lowest priority hardware interrupt. However, since the third receive task is configured with a near-idle priority, if the first or second receive task is ready at this time, the real-time operating system scheduler will prioritize scheduling the higher priority task, and the third receive task will automatically delay execution.

[0158] The third receiving task is scheduled to execute only when the processor is completely idle (i.e., no first or second receiving task is ready). It reads log data in batches from the third data area, formats it into a file, and writes it to external storage. Log processing does not consume processing time slices for business data and upgrade data.

[0159] VI. The Complete Process of Fine-grained Cache Consistency Management

[0160] In the communication process of the above-mentioned message types, cache consistency management follows a standardized three-stage process:

[0161] The first segment (precise refresh after sender write): Taking step S4 of the first type of message as an example, after the sender completes the data frame writing to slot N and before sending the notification, it uses the D-CacheClean operation of the ARMCP15 coprocessor to write the dirty data within the precise address range of slot N back to shared memory. The refresh start address is strictly equal to the physical starting address of slot N, and the length is strictly equal to the length of the data frame written this time, executed on a cache line basis. This operation does not involve cache lines in other slots or other data areas.

[0162] In implementations based on ARM Cortex-M processors, cache flushing can be accomplished by using the SCB_CleanDCache_by_Addr function, passing in the starting address and data length, allowing the hardware to automatically write back the cache lines within the specified address range. In implementations based on ARM Cortex-A processors, this can be achieved through the DCCIMVAC (DataCache Clean and Invalidate by MVA) operation of the CP15 coprocessor.

[0163] The second segment (notification delivery): The sending end confirms that the cache refresh is complete before sending a hardware notification to the receiving end. Because the notification is sent after the cache refresh, the receiving end can ensure that the latest data is already in the physical medium of the shared memory when it receives the notification, thus guaranteeing data visibility in terms of timing.

[0164] The third stage (precise invalidation before data is read by the receiver): Taking step R3 of the first type of message as an example, after receiving the notification but before reading the data from the address specified in the notification, the receiver invalidates the local cache lines within the precise address range indicated by the data start address and data length through the D-Cache Invalidate operation of the ARM CP15 coprocessor. The invalidated address range strictly matches the data address and length in the notification and does not affect other cached data.

[0165] In implementations based on ARM Cortex-M processors, cache line invalidation for a specified address range can be performed via functions. In implementations based on ARM Cortex-A processors, this can be accomplished through the DCIMVAC (DataCache Invalidate by MVA) operation of the CP15 coprocessor.

[0166] Through the above three-stage process, the mechanism ensures that the receiving end always reads the latest written data, without relying on the inter-processor hardware cache coherency protocol.

[0167] VII. Implementation Guarantee of Lock-Free Synchronization Mechanism

[0168] In all the communication processes described above, lock-free synchronization is achieved through a triple guarantee mechanism:

[0169] (i) Atomic pairing of slot writes and notifications

[0170] Taking the first type of message as an example, the sending end strictly follows the following sequence of operations: write the data frame to slot N → perform a cache refresh of the exact address range of slot N → send a first-type hardware notification carrying the exact address of slot N → move the write slot index from N to (N+1) / 128. This sequence of operations constitutes a logical atomic unit—the sending end will not move the write index out of slot N before notifying the receiving end, and therefore will not reuse that slot; when the receiving end receives the notification, the content of that slot has been completely written and the cache has been refreshed, and the data is fully visible.

[0171] (II) Purely passive processing at the receiving end

[0172] The receiver only accesses the precise slot address specified in the hardware notification after receiving it. Taking the first receive task as an example, this task does not actively scan, poll, or probe the status of any slots in the first data area. Therefore, the receiver will never concurrently access a slot while the sender is writing to it—each access by the receiver is triggered by a notification from the sender, and the notification is only sent after the write is complete and the cache is refreshed, naturally avoiding read-write concurrency conflicts in terms of access timing.

[0173] (III) Redundancy guarantee in the total number of slots

[0174] The first data area is configured with 128 slots, satisfying the following condition: the maximum time for the receiver to complete processing a single slot (approximately 3 milliseconds) is much less than the shortest time for the sender to fill 127 slots (total slot count 128 minus 1) (127 × 20 milliseconds = 2540 milliseconds). The ratio between the two is approximately 847 times, far exceeding a safety margin of 2 times. Therefore, when the sender's write index completes one cycle and returns to slot K, slot K has already been processed and released by the receiver.

[0175] The second data area is configured with 4 slots. The transmission interval of upgrade fragments is limited by the CAN bus rate (typically in the tens of milliseconds range), and the time for the receiver to process a single fragment is approximately 50 to 100 milliseconds. Four slots are sufficient to buffer subsequent arriving fragments before the receiver finishes processing one fragment, and the safety margin, as tested, meets the requirement of not less than 2 times.

[0176] The combined effect of the triple protection is that the sending end and the receiving end operate on different slots at the same time (the sending end writes to slot N, the receiving end processes slot M, and N≠M), naturally eliminating address contention and completely eliminating the dependence on synchronization primitives such as mutexes and spinlocks.

[0177] VIII. Implementation of Channel Adaptive Configuration

[0178] During the system initialization phase, the parameters of each data area are adapted and configured based on the multidimensional attribute analysis results of the corresponding message categories:

[0179] First data area (business messages): Due to the high data update frequency (20 millisecond cycle) and small single frame data volume (about 200 bytes), it is configured with 128 slots, each slot with a capacity of 256 bytes, and the notification trigger threshold is frame-by-frame notification (a notification is triggered once for each frame written).

[0180] Second data area (upgrade message): Due to the large single data transmission volume (maximum 64KB) but occasional occurrence, it is configured with 4 slots, each with a capacity of 66KB, and the notification trigger threshold is frame-by-frame notification.

[0181] The third data area (log messages): configured in batch mode, with an accumulation threshold of 32KB and a time threshold of 500 milliseconds—that is, a notification is triggered when the accumulated amount reaches 32KB or when more than 500 milliseconds have passed since the last send.

[0182] During system operation, the first processor core continuously monitors the backlog of data to be sent in each data area and the processing latency at the receiving end. When it is detected that the backlog of a certain data area continuously exceeds the first threshold or the processing latency exceeds the second threshold, the configuration parameters of that data area are automatically adjusted.

[0183] For example, during a vehicle diagnostic session, a surge in firmware upgrade data may occur, and the four slots in the second data area may not be sufficient to buffer the continuously arriving upgrade fragments. When the channel adaptive configuration unit detects that the backlog in the second data area continues to exceed a threshold, it automatically increases the number of slots in the second data area temporarily from 4 to 8 to absorb the sudden traffic surge. Once the upgrade session ends and the backlog returns to normal, the number of slots reverts to 4.

[0184] For example, when business data traffic increases abnormally (e.g., a large number of sudden messages appear on the CAN bus), the frame-by-frame notification strategy of the first data area may lead to excessively high interrupt frequency. After detecting this situation, the channel adaptive configuration unit switches the notification triggering strategy from frame-by-frame notification to cumulative notification—triggers a notification after accumulating 5 frames of business data, thereby reducing interrupt frequency and CPU overhead. When the traffic returns to normal, the strategy reverts to frame-by-frame notification.

[0185] IX. Implementation of Independent Health Monitoring for Each Channel

[0186] The first processor core maintains an independent health status record for each data area.

[0187] For the first data area (business messages), maintain the following monitoring metrics: notification sending success rate (the ratio of the number of successfully sent notifications to the total number of attempted sending), data frame verification failure rate (obtained from the receiver through the reverse notification channel), count of the number of times the buffer is close to full (counted when the difference between the write index and the read index exceeds 100), and average end-to-end latency (the time from when the data frame is put into the sending queue to when the receiver confirms receipt).

[0188] For the second data area (upgrade messages), maintain similar monitoring metrics, focusing on the number of times the buffer is close to full (count when the difference between the write index and the read index exceeds 3 times).

[0189] For the third data area (log messages), maintain the success rate of notification sending and the statistics of the number of times the buffer is close to full (count when the difference between the write pointer and the read pointer exceeds the threshold).

[0190] When the health indicators of any data area exceed the preset range, the system triggers a tiered response:

[0191] Level 1 response: Suspend the transmission of new data through this channel and wait for the backlog of data to be processed. For example, when the log data area is nearing full capacity due to an abnormally large number of log bursts, suspend the writing of new logs to the third data area and wait for the third receiving task to finish reading the backlog of log data before resuming.

[0192] The second-level response dynamically adjusts the configuration parameters of the channel. For example, when the buffer of the service data area frequently approaches full capacity, the number of slots in the first data area can be temporarily increased (from 128 to 256), or the notification triggering strategy can be switched from frame-by-frame notification to cumulative notification.

[0193] A level 3 response involves reporting the abnormal status of this channel to the system monitoring module via another channel and logging it to the log channel for later analysis. For example, when the verification failure rate in the upgrade data area continuously exceeds the threshold, an alarm notification is sent to the system monitoring module through the business message channel of the first data area, and the abnormal event is simultaneously logged to the log channel.

[0194] Importantly, because the three data zones are completely isolated in terms of physical address and notification type, anomaly monitoring and response operations in one channel will not interfere with the normal operation of other channels. When the log channel triggers a Level 1 response due to an abnormally large outbreak of logs, communication between the business message channel and the upgrade message channel remains completely unaffected.

[0195] In this document, the terms "upper," "lower," "front," "back," "left," "right," "top," "bottom," "inner," "outer," "vertical," and "horizontal," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only used for the clarity of expressing the technical solution and for the convenience of description, and therefore should not be construed as limiting the present invention.

[0196] In this document, the terms “comprising,” “including,” or any other variations thereof are intended to cover non-exclusive inclusion, which includes not only the elements listed but also other elements not expressly listed.

[0197] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of this invention is defined by the appended claims and their equivalents.

Claims

1. A heterogeneous dual-core lock-free shared memory communication method based on multi-dimensional attribute classification, applied to a heterogeneous dual-core system including a first processor core and a second processor core, wherein the first processor core and the second processor core exchange data through shared memory, characterized in that, Includes the following steps: Data classification steps: At the sending end, perform multidimensional attribute analysis on the inter-core communication data to be transmitted. The multidimensional attributes include at least real-time dimension, reliability dimension, and batch dimension. Based on the analysis results, divide the inter-core communication data into at least three message categories. Channel isolation steps: Allocate independent buffer areas with non-overlapping physical addresses for each type of message in the shared memory, and associate each type of message with an independent hardware notification type, forming an independent communication channel with dual physical isolation of address space and notification channel; Differentiated scheduling steps: Create an independent receiving and processing task for each type of message at the receiving end. Different types of receiving and processing tasks are configured with different task priorities, and the task priorities are matched with the corresponding hardware notification interrupt priorities. Lock-free synchronization steps: The sending end adopts a ring multi-slot writing strategy. After writing data to the current slot, it sends a hardware notification carrying the precise address information of the current slot to the receiving end. The receiving end passively reads the data of the corresponding slot according to the address information carried in the hardware notification. The sending end and the receiving end operate on different slots at the same time, without the need for mutex locks or spinlocks.

2. The heterogeneous dual-core lock-free shared memory communication method based on multi-dimensional attribute classification according to claim 1, characterized in that, In the data classification step: The real-time dimension is measured by the maximum allowable latency, the reliability dimension is measured by the allowable bit error rate or the required check strength, and the batch size dimension is measured by the typical transmission scale and generation frequency of the data. Based on the three-dimensional attribute analysis results, the inter-core communication data is divided into three categories: the first category of messages with high real-time performance and high periodicity, the second category of messages with high reliability and large-block transmission and occasional transmission, and the third category of messages with low real-time performance and batch transmission.

3. The heterogeneous dual-core lock-free shared memory communication method based on multi-dimensional attribute classification according to claim 1, characterized in that, In the channel isolation step, the independent buffer area achieves four layers of physical isolation: Address space isolation ensures that the physical address ranges of buffers for different message types do not overlap in shared memory; Interrupt channels are isolated, and different message categories are associated with different hardware notification types. Each notification type corresponds to an independent hardware interrupt line or hardware interrupt identifier. Context isolation is implemented, with different message categories being handled independently by different receiving and processing tasks; Cache operations are isolated; cache refresh and cache invalidation operations are performed only on the precise address range of the corresponding slot.

4. The heterogeneous dual-core lock-free shared memory communication method based on multi-dimensional attribute classification according to claim 1, characterized in that, The sending end performs the following steps: S1: Retrieve the data frame to be sent, check the priority queue of each channel, and retrieve the first frame to be sent from the queue. S2: Perform multidimensional attribute analysis on the retrieved data frame to determine the message category to which the data frame belongs, and select the target data area corresponding to the message category; S3: Encapsulate data frames according to the communication protocol format, and assemble the frame header, payload, and checksum; S4: Obtain the current write slot index of the target data area's circular buffer, write the encapsulated data frame to the slot indicated by the current write slot index, and perform a cache refresh operation on the precise address range corresponding to the slot after writing is completed; S5: Assemble a hardware notification message. The hardware notification message includes at least a data start address field, a data length field, and a channel type field. Assign the physical start address of the shared memory of the currently written slot to the data start address field, assign the byte length of the written data frame to the data length field, and send the hardware notification. S6: Move the write slot index to the next slot and release the current slot; The receiving end performs the following steps: R1: Hardware notification interrupt triggered, the corresponding interrupt line wakes up the receiving and processing task of the corresponding priority. R2: Parse the received hardware notification message structure and extract the data start address and data length; R3: Perform a cache invalidation operation on the precise address range indicated by the data start address and the data length, invalidate the local cache, and force a reload from the shared memory; R4: Starting from the data start address, passively read data frames from the shared memory according to the data length; R5: Performs integrity verification on the read data frames, verifying the synchronization identifier and checksum; R6: After successful verification, the data frame is delivered to the upper-layer application processing queue.

5. The heterogeneous dual-core lock-free shared memory communication method based on multi-dimensional attribute classification according to claim 4, characterized in that, In step S4, after the sending end completes the data frame writing and before sending the hardware notification, it performs a cache refresh operation on the precise address range corresponding to the slot. The starting address and length of the refresh strictly match the slot address and data length written this time. The hardware notification in step S5 is sent after the cache refresh is complete. In step S6, the sending end increments the write slot index and takes the modulo of the total number of slots; In step R3, after receiving the hardware notification and before reading data from the address specified in the notification, the receiving end performs a cache invalidation operation on the precise address range indicated by the data start address and the data length. The total number of slots in the circular buffer satisfies the following condition: the ratio of the maximum time for the receiver to complete processing a single slot to the shortest time for the transmitter to fill all other slots except the current slot is greater than a safety threshold.

6. The heterogeneous dual-core lock-free shared memory communication method based on multi-dimensional attribute classification according to claim 2, characterized in that, In the differentiated scheduling step: Configure the highest hardware interrupt priority and the highest task priority for the second type of message, and bind the highest priority hardware interrupt line; Configure the second-highest hardware interrupt priority and the second-highest task priority for the first type of message, and bind the second-highest priority hardware interrupt line; Configure the lowest hardware interrupt priority and the lowest task priority for the third type of message, and bind the lowest priority hardware interrupt line; High-priority hardware interrupts can preempt low-priority hardware interrupts at the hardware level, and high-priority tasks can preempt low-priority tasks.

7. The heterogeneous dual-core lock-free shared memory communication method based on multi-dimensional attribute classification according to claim 2, characterized in that, The first type of message adopts the latest-first-time strategy. Newly arrived data overwrites the slot where the old data is located or is written to the next free slot. The receiving end only processes the latest data. The second type of message adopts a full-reliability timeliness strategy, where each frame of data must be successfully received and verified. When all slots are filled with unprocessed data, the sender is blocked and waits. The third type of message adopts a "batch accumulation" timeliness strategy, where multiple data entries are accumulated at the sending end to reach a preset threshold or meet a preset time condition before being written in batches and triggering a notification.

8. The heterogeneous dual-core lock-free shared memory communication method based on multi-dimensional attribute classification according to claim 1, characterized in that, It also includes the channel adaptive configuration step: The configuration parameters of each independent communication channel are adapted and configured during system initialization based on the multidimensional attribute analysis results of the corresponding message category. The configuration parameters include the number of ring buffer slots, the capacity of a single slot, and the notification trigger threshold. During system operation, the sending end continuously counts the backlog of data to be sent in each channel and the processing delay at the receiving end. When the backlog is detected to continuously exceed the first threshold or the processing delay exceeds the second threshold, the configuration parameters of the channel are automatically adjusted. The adjustment includes: increasing or decreasing the number of slots, switching the notification triggering strategy from frame-by-frame notification to accumulated notification or from accumulated notification to frame-by-frame notification. Once the backlog returns to normal levels, the configuration parameters will revert to their default values.

9. The heterogeneous dual-core lock-free shared memory communication method based on multi-dimensional attribute classification according to claim 1, characterized in that, It also includes independent health monitoring steps for each channel: The sending end maintains an independent health status record for each independent communication channel. The health status record includes at least one or more of the following monitoring indicators: notification transmission success rate, data frame verification failure rate, number of times the buffer is close to full, and average end-to-end latency. When the health indicators of any channel exceed the preset range, a tiered response is triggered: the first-level response is to suspend the transmission of new data by that channel and wait for the backlog of data to be processed. The second-level response involves dynamically adjusting the configuration parameters of the channel, including one or more of the following: number of slots, notification trigger frequency, and verification algorithm strength. The third-level response involves reporting the abnormal status of the channel to the system monitoring module through another communication channel and recording it in the log channel.

10. A heterogeneous dual-core lock-free shared memory communication system based on multi-dimensional attribute classification, applied to a heterogeneous dual-core system including a first processor core and a second processor core, wherein the first processor core and the second processor core exchange data through shared memory, characterized in that, include: A data multidimensional attribute identification and classification unit is set at the sending end. It is used to perform multidimensional attribute analysis on the inter-core communication data to be transmitted, including at least real-time dimension, reliability dimension and batch dimension, and divide the inter-core communication data into at least three message categories according to the analysis results. The shared memory multi-region physical isolation unit is used to allocate independent buffer areas with non-overlapping physical addresses for each type of message in the shared memory, and to configure independent data structures for each type of message; An independent hardware notification unit is used to associate an independent hardware notification type with each type of message. After the sending end completes the data writing, it sends a notification to the receiving end through the corresponding hardware notification type. A two-level differentiated scheduling unit is set at the receiving end to create an independent receiving and processing task for each type of message. Different types of receiving and processing tasks are configured with different task priorities, and the task priorities are matched with the corresponding hardware notification interrupt priorities. The lockless synchronization unit is used to control the sending end to send a hardware notification carrying the precise address information of the current slot after writing data to the current slot using a ring multi-slot writing strategy, and to control the receiving end to passively read the data of the corresponding slot according to the address information carried in the hardware notification, so that the sending end and the receiving end can operate on different slots at the same time.