Method for inter-core communication mode of multi-core processor

Abstract

The invention provides a method of an inter-core communication mode of a multi-core processor, which comprises the following steps of: S1, determining a processor module partition, performing inter-partition communication initialization, and configuring a corresponding virtual partition, a virtual port and a corresponding driving program; s2, calling an interface program for communication between corresponding partitions in each partition application needing communication; s3, providing a corresponding communication service by the partition application; and S4, when data messages are required to be continuously received in sequence, calling an interface for creating the queue ports, sending messages to a source port in the queue ports through the interface for sending the messages in the partition application, calling the interface in the partition application in the partition needing to receive the messages, and receiving the messages of a destination queue port in sequence. And finally, communication monitoring and maintenance are performed, ID and state information of queues and sampling ports are searched regularly or as required, communication conditions are judged according to results, and if the queues are jammed or no new messages exist in the sampling ports, strategies are adjusted in time, faults are eliminated in time, and stable and efficient communication is ensured.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of inter-core communication of multi-core processors, and in particular to a method for inter-core communication of multi-core processors. BACKGROUND

[0002] In today's era of rapid technological development, multi-core processor technology is increasingly widely used in various fields. With the continuous progress of domestic chip technology, domestic multi-core processors are gradually emerging and playing an important role in many key fields.

[0003] Traditional single-core processors often struggle when faced with complex industrial site services. For example, in the industrial Internet of Things scenario, intelligent devices need to handle multiple services such as external communication, human-computer interaction, device control, and data acquisition. These services not only have very high real-time requirements for device control, such as precise motion control of robots and precise process control of automated production lines, which must complete instruction transmission and response within a very short time to ensure the accuracy and safety of the production process; at the same time, services such as human-computer interaction and image display require devices to have high performance, such as fast graphics rendering and smooth operation interface response, to provide a good user experience. However, the computing power of single-core processors is limited, making it difficult to meet these concurrent strong real-time and high-performance requirements, resulting in limited overall system performance and inability to efficiently handle complex and variable workloads.

[0004] In contrast, multi-core processors can significantly improve computing power by integrating multiple processor cores, enabling parallel processing of services. However, inter-core communication of multi-core processors has become a key issue. In domestic multi-core processors, for example, different architecture cores such as Loongson CPU, ARM (such as products from Ingenic), and FPGA (such as products from Highgoss) work together. Each core has different functions, with Loongson CPU handling external communication, ARM mainly handling real-time control, and FPGA focusing on I / O expansion and fiber communication. The diversity of this architecture makes inter-core communication more complex. Differences in running speed, data processing methods, and communication protocols between different cores make it difficult to effectively solve inter-core communication problems, leading to data transmission delays, information loss or errors, and other issues that seriously affect the performance and stability of the entire system, preventing the full potential of multi-core processors from being realized. Therefore, researching inter-core communication methods for domestic multi-core processors is of great practical significance and is a key step in improving the application efficiency of domestic multi-core processors, which is crucial for promoting the development of related technologies and the upgrading of industries in China. SUMMARY

[0005] The main purpose of the present application is to provide a method for inter-core communication of a multi-core processor, which solves the differences in running speed, data processing method and communication protocol of different cores, and effectively solves the problem of inter-core communication, so as to avoid the problems of data transmission delay, information loss or error.

[0006] To solve the above technical problems, the technical solution adopted by the present application is: A method for inter-core communication of a multi-core processor, comprising: S1, determining processor module partitioning and initializing inter-partition communication, configuring corresponding virtual partition, virtual port and corresponding driver program; S2, calling the interface program of corresponding inter-partition communication in each partition application requiring communication; S3, providing corresponding communication services by the partition application; S4, when requiring data message to be consecutive and received in sequence, the interface for creating a queue port needs to be called, the message is sent to the source port in the queue port through the message sending interface in the partition application, and the interface in the partition application is called in the partition requiring to receive the message, and the message of the destination queue port is received in sequence.

[0007] In the preferred scheme, the specific steps in step S1 are: For the hardware platform, the power supply, HDMI, USB to serial port, network port and SD card module need to be initialized to ensure normal operation of the hardware; In a heterogeneous multi-core device, an MPU+MCU architecture is adopted, and a non-real-time operating system and a real-time operating system dual system should be installed, in a specific processor, the Cortex-A53 main core runs the non-real-time operating system, the Cortex-M7 slave core runs the real-time operating system, the system is started through the boot program U-boot, including initializing hardware resources, reading and running the kernel image file, and during the installation process, the non-real-time operating system and the real-time operating system should be correctly configured and debugged to ensure stable operation of the dual system.

[0008] In the preferred scheme, the specific steps in step S2 are: After determining the processor module partitioning, the inter-partition communication initialization is performed, and the port information is accurately configured in the xml file of the partition application, covering the port type, name, direction and message length, and for the queue port, the queue length and transmission protocol also need to be defined; The channel information is accurately configured in the module.xml file, including the channel ID, source port and destination port name and partition name; For inter-module communication, virtual partitions and virtual ports are configured independently for each module, and drivers are written. Port and channel memory resources are adjusted according to actual conditions. In heterogeneous multi-core devices using the RPMsg protocol, driver modules rpmsg_core.c, virtio_rpmsg_bus.c, and imx_rpmsg.c are added to the kernel of the non-real-time operating system to realize the construction of the RPMsg bus, the association between the device and the VirtIO component, and the hardware platform configuration. The real-time operating system achieves communication by adding the RPMsg-Lite component and configuring it.

[0009] In the preferred embodiment, the corresponding communication service step in step S3 is as follows: A non-preemptive priority scheduling strategy is adopted. In the message distribution unit, the message priority is set according to the message data volume or the application-specified priority. The message is distributed to high and low priority queues. The message is stored in a linked storage structure. When constructing a message node, the relevant members are assigned values ​​and inserted into the queue according to the rules. In the message scheduling unit, a kernel thread is created through the RPMsg driver. It first checks the readiness status of the high-priority queue and sends messages according to the rules. When the high-priority queue is empty, it checks the low-priority queue and uses a mutex lock to ensure data consistency. A priority scheduling strategy combining deficit round-robin is adopted. The message distribution unit distributes messages to the corresponding queues according to priority and queue number. Medium-priority messages are inserted into the queue according to specific rules. The message scheduling unit first judges the high-priority queue, then processes the medium-priority queue according to the deficit round-robin strategy, and finally judges the low-priority queue. The kernel thread initializes the credit value of the specified medium-priority queue and updates the deficit and sends messages according to the rules.

[0010] In the preferred scheme, regarding non-preemptive priority scheduling, the total number of messages is , No. One message ( The priority of ) is The amount of data is The priority calculation function is defined as follows: ; in For message data volume threshold, Indicates high priority. This indicates a low priority queue; meanwhile, a high priority queue is set up. and low priority queues The queue lengths are respectively and The message delivery rates were respectively and The service rates were respectively and According to the M / G / 1 model in queuing theory, the average waiting time of messages in a high-priority queue is... and average length of stay The calculation formula is as follows: ; ; in For the first The delivery rate of high-priority messages The second moment of its service time, For the first The delivery rate of low-priority messages The average number of frames encapsulated for low-priority messages. The average service time for a message frame; these formulas and functions are used to accurately determine message priority and calculate the message waiting and dwell time of high-priority queues through queuing theory models, providing a basis for evaluating and optimizing the performance of high-priority message transmission; In priority scheduling combined with deficit round-robin, inter-core messages are divided into three priorities: high, medium, and low. The set of high-priority messages is... The medium-priority message set is The low-priority message set is For the first message in the medium priority message set One message The credit score of its queue is The deficit is The data packet size is The priority message scheduling function is defined as follows: ; when At that time, send the message and update the deficit. ;when If the message is skipped, the system continues to check the next medium-priority message; assuming the system transmits a certain amount of data per unit time... For high-priority message groups, the arrival curve is as follows: The service curve is According to deterministic network calculus theory, the communication delay boundary of high-priority message groups The calculation formula is: ; These functions and formulas are used to achieve fair scheduling and bandwidth allocation for medium-priority messages, and to calculate the communication delay boundary of high-priority message groups through deterministic network calculus theory, ensuring that the system meets the communication requirements of messages of different priorities and improving the real-time performance and reliability of the system.

[0011] In the preferred embodiment, step S4 is as follows: The sender calls the corresponding inter-partition communication interface program in the partition application, and calls the interface to create queue ports or sampling ports as needed. The sender sends messages to the corresponding ports through the message sending interface in the partition application. During the sending process, the message scheduling strategy adopted must be followed, and the messages must be placed in the corresponding queue or processed according to the deficit polling rule.

[0012] By utilizing the provided interface service, the queue port ID and status can be obtained by the queue port name, and the sampling port ID and status can be obtained by the sampling port name. Based on the monitoring results, the communication status can be judged, and abnormal situations can be handled and optimized to ensure normal and stable communication. The receiving party calls the interface in the partition application in the partition that needs to receive messages, and receives messages according to the message sending mode. In queue mode, messages are sent from the message queue of the source port to the message queue of the destination port in first-in-first-out order, and the receiving party retrieves messages from the queue of the destination port. In sampling mode, new messages overwrite old messages, and the receiver receives the last updated message from the sending partition. Using the provided interface service, the queue port ID can be obtained by the queue port name, and then the status of the queue port can be obtained. The sampling port ID and the current status of the specified sampling port can be obtained by the sampling port name, so as to monitor and manage the communication process. By monitoring port status, problems in the communication process can be detected in a timely manner, such as whether the queue is congested or messages are lost, and corresponding measures can be taken to optimize the process.

[0013] In the preferred scheme, regarding message sending and receiving, let the sending success rate function of the sender's partition application be: ,in The factors influencing successful transmission are represented as a vector, such as network status parameters and port status parameters. A linear regression model is established through statistical analysis of historical transmission data.

[0014] in For regression coefficients, This is the error term; the sender uses this function to evaluate the success rate of this message transmission. When the success rate is lower than a set threshold, retransmission or adjustments to the transmission strategy are taken to ensure reliable message delivery. The receiver sets the message reception accuracy function as follows: ,in The vector represents the factors affecting reception accuracy, such as signal strength parameters and receiver queue status parameters; a logistic regression model is obtained through data fitting: ; The receiver uses this function to determine the accuracy of the received message, and verifies or requests a retransmission of potentially erroneous messages to ensure the correctness of the received message. In terms of communication status monitoring, let the congestion index of the queue port be... Defined as: ; in This is the current queue length. The maximum capacity of the queue; when When the congestion threshold is exceeded, the system takes congestion control measures, such as adjusting the message scheduling strategy and increasing the buffer, to ensure smooth communication; for the sampling port, the information update frequency is set to... The information timeliness function is , is represented as: ; in This refers to the last time the information was updated. This is the time-dependent attenuation coefficient; when When the timeliness threshold is lower than set, a message will be displayed indicating a possible communication problem or sender failure, so that timely troubleshooting and repair can be carried out to improve the reliability and real-time performance of the system.

[0015] In the preferred scheme, the algorithm steps in steps S1-S4 are as follows: A1. After the hardware platform is powered on, the processor performs a reset operation; To boot the Cortex-A53 kernel using the U-boot loader, follow these steps: Initialize memory, set the clock, and disable interrupt hardware resources; Read the system kernel image file from memory and determine whether it is a non-real-time operating system image file or a real-time operating system image file.

[0016] If it is a real-time operating system image file, copy it into the memory of the Cortex-M7 core and wake up the Cortex-M7 core to start the real-time operating system; if it is a non-real-time operating system image file, run the kernel file to start the non-real-time operating system. A2. When a message arrives, the message distribution unit performs the following operations: Retrieve message priority and queue number information; The message's queue type is determined by its priority and queue number, including high, medium, and low priority queues. For high-priority or low-priority messages, find the corresponding queue node and insert the message node into the queue using the tail insertion method; for medium-priority messages, first find the queue head node, then find the corresponding queue according to the queue number, and insert the message node into the queue using the tail insertion method. The message scheduling unit executes the following loop operation through kernel threads: Determine if the high-priority queue is ready, i.e., whether the message count of the queue head node is greater than 0. If it is, retrieve the message pointed to by the queue head node, send the message through the RPMsg channel, and then continue to check if there are any more messages in the high-priority queue. If the high-priority queue is empty, proceed to the next step. To determine if a medium-priority queue is ready, perform the following steps: Obtain the index of the current waiting service queue and find the corresponding queue node; Determine whether the queue deficit needs to be updated based on whether it is the first visit or a round of scheduling has been completed. If so, update the deficit of all queues by adding the queue credit value quantum to the deficit. Check if the queue is empty. If it is, clear the value of deficit to zero. If it is not empty, check if the value of deficit is greater than the length of the message to be transmitted. If it is, output the message and update the values ​​of deficit and cur_p. Otherwise, continue to check the next queue. Determine if the low-priority queue is ready. If it is, retrieve the message pointed to by the queue head node and send the message through the RPMsg channel; otherwise, wait for the queue to be ready. A3. Call the following operations periodically or as needed: Find the corresponding queue port ID by queue port name; Retrieve the status information of the queue port based on the queue port ID, including queue length, number of messages, and whether there are any messages waiting to be sent; Find the sampling port ID based on the sampling port name; Get the current status information of the specified sampling port based on the sampling port ID, such as whether there are new messages and the timestamp of the latest message; Make judgments and handle actions based on the acquired status information: If the queue length is too long or the message waiting time is too long, it may indicate that there is communication congestion, and it is necessary to adjust the message scheduling strategy or check whether the system resources are insufficient. If there is no new message at the sampling port for a long time, it may indicate a problem with the sender or a communication link interruption, and troubleshooting is required.

[0017] The present invention provides a method for inter-core communication of a multi-core processor. First, in terms of function implementation, by reasonably determining the processor module partitions and performing effective initialization of inter-partition communication, the advantages of different cores can be fully utilized. For example, Loongson CPUs focus on external communication processing and can efficiently interact with external devices or systems for data; ARM is responsible for real-time control and can accurately and quickly respond to control signals to ensure the real-time performance of the system; FPGAs perform I / O expansion and fiber optic communication, greatly expanding the input / output capabilities and communication bandwidth of the system. This division of labor and cooperation enables the entire system to operate more stably and efficiently in the face of complex tasks, such as multi-device linkage control in industrial automation production and data collection and signal processing in intelligent transportation systems, improving the overall performance of the system.

[0018] Secondly, in terms of communication reliability, accurately configuring the corresponding virtual partitions, virtual ports, and writing the corresponding driver programs constructs a stable infrastructure for inter-core communication. This helps to reduce interference and errors during communication and ensures that data can be transmitted accurately between different partitions. Whether in the scenario of file transfer with a large amount of data or in the process of transmitting control instructions with extremely high real-time requirements, the integrity and accuracy of information can be ensured, thereby enhancing the reliability and stability of the system and reducing the probability of system anomalies due to communication failures.

[0019] Furthermore, in terms of data processing flexibility, it supports two communication methods, queue ports and sampling ports, and provides rich interface services, such as obtaining the queue port ID and status through the queue port name, and obtaining the sampling port ID and status according to the sampling port name, etc. This enables the system to flexibly select the communication method according to different application requirements. When it is necessary to ensure that data messages are received coherently and in order, the interface for creating a queue port can be called for communication, which is suitable for scenarios such as video stream transmission and continuous sensor data collection; for some applications with high requirements for data timeliness, such as the transmission of status update information in a real-time monitoring system, the sampling port can be used for communication to ensure that the receiver can obtain the latest data in a timely manner, greatly improving the flexibility and adaptability of data processing and meeting the diverse application scenario requirements. Brief Description of the Drawings

[0020] The present invention will be further described below in conjunction with the drawings and embodiments: Figure 1 is the flowchart of the system construction and initialization steps of the present invention; Figure 2 is the flowchart of the communication resource configuration steps of the present invention; Figure 3 This is a flowchart of the message scheduling and transmission steps of the present invention; Figure 4 This is a flowchart of the communication execution and monitoring steps of the present invention; Detailed Implementation Example 1 like Figures 1-4 As shown, a method for inter-core communication in a multi-core processor includes: S1. Determine the processor module partition and perform inter-partition communication initialization, and configure the corresponding virtual partitions, virtual ports and corresponding drivers; S2. Call the corresponding inter-partition communication interface program in each partition application that needs to communicate. S3, The corresponding communication services are provided by the partition application; S4. When data messages are required to be received sequentially and in order, the interface for creating a queue port needs to be called. Messages are sent to the source port in the queue port through the message sending interface in the partition application. In the partition that needs to receive messages, the interface in the partition application is called to receive messages from the destination queue port in order.

[0021] In the preferred embodiment, the specific steps in step S1 are as follows: For the hardware platform, initialization operations need to be performed on the power supply, HDMI, USB to serial port, network port, and SD card module to ensure that the hardware is running normally; In heterogeneous multi-core devices using an MPU + MCU architecture, a dual-system setup should be installed, consisting of a non-real-time operating system (NRTOS) and a real-time operating system (RTOS).

[0022] In certain processors, the Cortex-A53 main core runs a non-real-time operating system, while the Cortex-M7 slave core runs a real-time operating system. The system boots up through the U-boot bootloader, which includes initializing hardware resources and reading and running the kernel image file. During the installation process, the non-real-time operating system and the real-time operating system must be correctly configured and debugged to ensure the stable operation of the dual systems.

[0023] The hardware platform using the i.MX 8M Plus processor requires initialization of each hardware module. This includes converting the power module's input voltage to a stable DC voltage to power other hardware modules; configuring the HDMI module for high-definition image output; setting up the USB-to-serial and Ethernet modules to ensure data transfer with external devices (such as personal computers); and initializing the SD card module to enable normal file read and write operations.

[0024] Dual-system installation and configuration: For heterogeneous multi-core devices, such as those using an MPU + MCU architecture, a dual-system setup is required, consisting of a non-real-time (RTD) operating system and a real-time (RTD) operating system. In the i.MX 8M Plus processor, the Cortex-A53 acts as the master core running the RTD, while the Cortex-M7 acts as the slave core running the RTD. The installation process includes: first, running the bootloader U-boot on the Cortex-A53 core. In the first stage, U-boot initializes memory, sets the clock, and disables interrupts and other hardware resources. In the second stage, it reads the system kernel image file from memory and runs it to start the kernel. For the RTD, the Toradex Easy Installer tool can be used for installation. After installation, the hardware platform must be reset, and the system must be checked for normal startup. For the RTD, the relevant Software Development Kit (SDK) must be obtained. The RTD source files in the SDK are compiled using the cross-compiler arm-none-eabi-gcc. The generated executable file is copied to the SD card, and then the RTD is booted using the U-boot program.

[0025] After completing the dual-system installation, communication configuration between the systems is required. In non-real-time operating system systems, multiple driver modules need to be added to the kernel to enable RPMsg communication, while in real-time operating system systems, only the RPMsg-Lite component needs to be added to the source files and the corresponding configuration completed.

[0026] In the preferred embodiment, the specific steps in step S2 are as follows: After determining the processor module partitions, perform inter-partition communication initialization. Accurately configure port information in the XML file of the partition application, including port type, name, direction and message length. For queue ports, queue length and transmission protocol also need to be defined. Configure the channel information precisely in the module.xml file, including the channel ID, source port and destination port name, and the name of the partition where it is located; For inter-module communication, virtual partitions and virtual ports are configured independently for each module, and drivers are written. Port and channel memory resources are adjusted according to actual conditions. In heterogeneous multi-core devices using the RPMsg protocol, driver modules rpmsg_core.c, virtio_rpmsg_bus.c, and imx_rpmsg.c are added to the kernel of the non-real-time operating system to realize the construction of the RPMsg bus, the association between the device and the VirtIO component, and the hardware platform configuration. The real-time operating system achieves communication by adding the RPMsg-Lite component and configuring it.

[0027] Port and Channel Configuration: After determining the processor module partitions, perform inter-module communication initialization. Configure port information in detail in the partition application's XML file, including port type (e.g., queued port or sampling port), port name, port direction (source port or destination port), and message length. For queued ports, queue length and transmission protocol (e.g., receive blocking, discarding, and not applicable) also need to be defined. Configure channel information in the module.xml file, clarifying the connection relationships between ports, including defining channel ID, source port name and partition name, and destination port name and partition name. For inter-module communication, each module needs to be configured separately, including setting up virtual partitions, virtual ports, and writing corresponding drivers. The memory resources occupied by ports and channels should be adjusted based on actual port and channel usage.

[0028] Protocol and Driver Setup: The RPMsg protocol is used for inter-core communication in heterogeneous multi-core devices. In non-real-time operating systems, the RPMsg protocol source files are stored in the drivers / rpmsg directory. Related files, such as rpmsg_core.c, are used to build the RPMsg bus, managing device and driver lists by defining attributes such as bus name, device and driver matching rules, and completing device and driver matching through callback functions. The virtio_rpmsg_bus.c file associates RPMsg devices with VirtIO components, implementing shared memory management and other functions. During data exchange, message sending and receiving are achieved through the index information of the Available Ring and Used Ring storage buffers. The imx_rpmsg.c file completes the hardware platform-related configuration, including the specific implementation of inter-core interrupts, setting the shared memory start address and size, and establishing its association with virtio_rpmsg_bus.c. Applications communicate through the APIs provided by the driver files. Real-time operating systems achieve communication by adding and configuring the RPMsg-Lite component.

[0029] Example 2 Further explanation in conjunction with Example 1, such as Figures 1-4As shown, the corresponding communication service steps in step S3 are as follows: A non-preemptive priority scheduling strategy is adopted. In the message distribution unit, the message priority is set according to the message data volume or the application-specified priority. The message is distributed to high and low priority queues. The message is stored in a linked storage structure. When constructing a message node, the relevant members are assigned values ​​and inserted into the queue according to the rules. In the message scheduling unit, a kernel thread is created through the RPMsg driver. It first checks the readiness status of the high-priority queue and sends messages according to the rules. When the high-priority queue is empty, it checks the low-priority queue and uses a mutex lock to ensure data consistency. A priority scheduling strategy combining deficit round-robin is adopted. The message distribution unit distributes messages to the corresponding queues according to priority and queue number. Medium-priority messages are inserted into the queue according to specific rules. The message scheduling unit first judges the high-priority queue, then processes the medium-priority queue according to the deficit round-robin strategy, and finally judges the low-priority queue. The kernel thread initializes the credit value of the specified medium-priority queue and updates the deficit and sends messages according to the rules.

[0030] Priority scheduling strategy (taking non-preemptive priority scheduling as an example) Message Distribution: In the message distribution unit, message priorities are determined according to pre-defined rules. For example, based on message data size, if the message data size is less than the maximum data length of one RPMsg message frame, it is set to high priority; otherwise, it is set to low priority; or the priority is set according to the application-specified priority. Then, the messages are distributed to the corresponding priority queues (high and low priority queues), and a linked storage structure is used to store the messages. When constructing a message node, members such as message length, content, and priority are assigned values, and the corresponding queue head node is found according to the priority. The message node is then inserted into the queue using tail insertion.

[0031] Message scheduling: Message scheduling is implemented by creating a kernel thread in the RPMsg driver. First, it checks if the high-priority queue is ready. If the message count at the queue head node is not zero, the message pointed to by the queue head node is retrieved and sent through the RPMsg channel. Then, it checks if the high-priority queue still has messages. If the high-priority queue is empty, it checks if the low-priority queue is ready, again based on the message count at the queue head node. If ready, the message is retrieved and sent; otherwise, it waits for the queue to become ready. Mutex locks are used to protect the queues when messages enter or leave them to ensure data consistency.

[0032] Combining the priority scheduling strategy of deficit round-robin: Message distribution: The message distribution unit distributes messages to the corresponding queues based on priority (high, medium, low) and queue number. For high and low priority messages, after finding the corresponding queue node, the message node is directly added to the queue using tail insertion. For medium priority messages, the queue head node is found first, then the corresponding queue is located based on the queue number, and the message node is added to the queue using tail insertion. When constructing a message node, in addition to assigning values ​​to members such as message length and content, values ​​also need to be assigned to members specific to medium priority messages, such as the starting transmission position.

[0033] Message scheduling: The message scheduling unit first checks if the high-priority queue is ready. If it is, the message is sent; otherwise, the medium-priority queue is checked. For medium-priority queues, the kernel thread needs to specify the credit value (quantum) for each medium-priority queue during initialization. During scheduling, the sequence number of the queue waiting for service is first obtained, the corresponding queue node is found, and it is determined whether the queue deficit needs to be updated. If so, the deficit of all queues is updated (plus the queue credit value). Then, it is checked if the queue is empty. If empty, the deficit value is cleared to zero. If not empty, it is checked if the deficit value is greater than the length of the message to be transmitted. If so, the message is output and the deficit and starting transmission position values ​​are updated; otherwise, the next queue is checked. Finally, the low-priority queue is checked. If it is ready, the message is sent; otherwise, the queue is waited for to become ready.

[0034] In the preferred scheme, regarding non-preemptive priority scheduling, the total number of messages is , No. One message ( The priority of ) is The amount of data is The priority calculation function is defined as follows: ; in For message data volume threshold, Indicates high priority. This indicates a low priority queue; meanwhile, a high priority queue is set up. and low priority queues The queue lengths are respectively and The message delivery rates were respectively and The service rates were respectively and According to the M / G / 1 model in queuing theory, the average waiting time of messages in a high-priority queue is... and average length of stay The calculation formula is as follows: ; ; in For the first The delivery rate of high-priority messages The second moment of its service time, For the first The delivery rate of low-priority messages The average number of frames encapsulated for low-priority messages. The average service time for a message frame; these formulas and functions are used to accurately determine message priority and calculate the message waiting and dwell time of high-priority queues through queuing theory models, providing a basis for evaluating and optimizing the performance of high-priority message transmission; In priority scheduling combined with deficit round-robin, inter-core messages are divided into three priorities: high, medium, and low. The set of high-priority messages is... The medium-priority message set is The low-priority message set is For the first message in the medium priority message set One message The credit score of its queue is The deficit is The data packet size is The priority message scheduling function is defined as follows: ; when At that time, send the message and update the deficit. ;when If the message is skipped, the system continues to check the next medium-priority message; assuming the system transmits a certain amount of data per unit time... For high-priority message groups, the arrival curve is as follows: The service curve is According to deterministic network calculus theory, the communication delay boundary of high-priority message groups The calculation formula is: ; These functions and formulas are used to achieve fair scheduling and bandwidth allocation for medium-priority messages, and to calculate the communication delay boundary of high-priority message groups through deterministic network calculus theory, ensuring that the system meets the communication requirements of messages of different priorities and improving the real-time performance and reliability of the system.

[0035] In the preferred embodiment, step S4 is as follows: The sender calls the corresponding inter-partition communication interface program in the partition application, and calls the interface to create queue ports or sampling ports as needed. The sender sends messages to the corresponding ports through the message sending interface in the partition application. During the sending process, the message scheduling strategy adopted must be followed, and the messages must be placed in the corresponding queue or processed according to the deficit polling rule.

[0036] By utilizing the provided interface service, the queue port ID and status can be obtained by the queue port name, and the sampling port ID and status can be obtained by the sampling port name. Based on the monitoring results, the communication status can be judged, and abnormal situations can be handled and optimized to ensure normal and stable communication. The receiving party calls the interface in the partition application in the partition that needs to receive messages, and receives messages according to the message sending mode. In queue mode, messages are sent from the message queue of the source port to the message queue of the destination port in first-in-first-out order, and the receiving party retrieves messages from the queue of the destination port. In sampling mode, new messages overwrite old messages, and the receiver receives the last updated message from the sending partition. Using the provided interface service, the queue port ID can be obtained by the queue port name, and then the status of the queue port can be obtained. The sampling port ID and the current status of the specified sampling port can be obtained by the sampling port name, so as to monitor and manage the communication process. By monitoring port status, problems in the communication process can be detected in a timely manner, such as whether the queue is congested or messages are lost, and corresponding measures can be taken to optimize the process.

[0037] In the preferred scheme, regarding message sending and receiving, let the sending success rate function of the sender's partition application be: ,in The factors influencing successful transmission are represented as a vector, such as network status parameters and port status parameters. A linear regression model is established through statistical analysis of historical transmission data.

[0038] in For regression coefficients, This is the error term; the sender uses this function to evaluate the success rate of this message transmission. When the success rate is lower than a set threshold, retransmission or adjustments to the transmission strategy are taken to ensure reliable message delivery. The receiver sets the message reception accuracy function as follows: ,in The vector represents the factors affecting reception accuracy, such as signal strength parameters and receiver queue status parameters; a logistic regression model is obtained through data fitting: ; The receiver uses this function to determine the accuracy of the received message, and verifies or requests a retransmission of potentially erroneous messages to ensure the correctness of the received message. In terms of communication status monitoring, let the congestion index of the queue port be... Defined as: ; in This is the current queue length. The maximum capacity of the queue; when When the congestion threshold is exceeded, the system takes congestion control measures, such as adjusting the message scheduling strategy and increasing the buffer, to ensure smooth communication; for the sampling port, the information update frequency is set to... The information timeliness function is , is represented as: ; in This refers to the last time the information was updated. This is the time-dependent attenuation coefficient; when When the timeliness threshold is lower than set, a message will be displayed indicating a possible communication problem or sender failure, so that timely troubleshooting and repair can be carried out to improve the reliability and real-time performance of the system.

[0039] Example 3 Further explanation in conjunction with Example 1, such as Figures 1-4 As shown, the algorithm steps in steps S1-S4 are as follows: A1. After the hardware platform is powered on, the processor performs a reset operation; To boot the Cortex-A53 kernel using the U-boot loader, follow these steps: Initialize memory, set the clock, and disable interrupt hardware resources; Read the system kernel image file from memory and determine whether it is a non-real-time operating system image file or a real-time operating system image file.

[0040] If it is a real-time operating system image file, copy it into the memory of the Cortex-M7 core and wake up the Cortex-M7 core to start the real-time operating system; if it is a non-real-time operating system image file, run the kernel file to start the non-real-time operating system. A2. When a message arrives, the message distribution unit performs the following operations: Retrieve message priority and queue number information; The message's queue type is determined by its priority and queue number, including high, medium, and low priority queues. For high-priority or low-priority messages, find the corresponding queue node and insert the message node into the queue using the tail insertion method; for medium-priority messages, first find the queue head node, then find the corresponding queue according to the queue number, and insert the message node into the queue using the tail insertion method. The message scheduling unit executes the following loop operation through kernel threads: Determine if the high-priority queue is ready, i.e., whether the message count of the queue head node is greater than 0. If it is, retrieve the message pointed to by the queue head node, send the message through the RPMsg channel, and then continue to check if there are any more messages in the high-priority queue. If the high-priority queue is empty, proceed to the next step. To determine if a medium-priority queue is ready, perform the following steps: Obtain the index of the current waiting service queue and find the corresponding queue node; Determine whether the queue deficit needs to be updated based on whether it is the first visit or a round of scheduling has been completed. If so, update the deficit of all queues by adding the queue credit value quantum to the deficit. Check if the queue is empty. If it is, clear the value of deficit to zero. If it is not empty, check if the value of deficit is greater than the length of the message to be transmitted. If it is, output the message and update the values ​​of deficit and cur_p. Otherwise, continue to check the next queue. Determine if the low-priority queue is ready. If it is, retrieve the message pointed to by the queue head node and send the message through the RPMsg channel; otherwise, wait for the queue to be ready. A3. Call the following operations periodically or as needed: Find the corresponding queue port ID by queue port name; Retrieve the status information of the queue port based on the queue port ID, including queue length, number of messages, and whether there are any messages waiting to be sent; Find the sampling port ID based on the sampling port name; Get the current status information of the specified sampling port based on the sampling port ID, such as whether there are new messages and the timestamp of the latest message; Make judgments and handle actions based on the acquired status information: If the queue length is too long or the message waiting time is too long, it may indicate that there is communication congestion, and it is necessary to adjust the message scheduling strategy or check whether the system resources are insufficient. If the sampling port does not receive any new messages for an extended period, it may indicate a problem with the sender or a communication link interruption, requiring troubleshooting.

[0041] System startup and initialization correspond to the following steps in algorithm A1: hardware platform power-on reset, Cortex-A53 core bootloader U-boot initialization of hardware resources such as memory, clock, and interrupts, and reading and judging the system kernel image file. These steps correspond to the system setup and initialization steps in multi-core processor inter-core communication methods. Their significance lies in establishing a stable operating foundation for the entire inter-core communication system, ensuring the hardware is in normal working condition and that both systems can boot correctly. Like laying a solid foundation for a building, this is a prerequisite for successful subsequent communication. Without this step, the system cannot operate normally, and inter-core communication is impossible.

[0042] Message scheduling and transmission correspondence: Algorithm step A2 details the distribution and scheduling process after message arrival, which completely corresponds to the message scheduling and transmission part of the inter-core communication method in multi-core processors. By obtaining the message priority and queue number and accurately inserting the message into the corresponding queue, and scheduling messages according to the order of high, medium, and low priority queues, it ensures that messages can be transmitted in an orderly manner according to the set rules, meeting the transmission requirements of messages with different priorities. For example, in industrial control scenarios, critical messages such as control signals can be set to high priority and transmitted first to ensure the real-time performance of the system; while ordinary data is processed according to medium and low priorities to avoid blocking critical messages, thereby improving the communication efficiency and reliability of the entire system and enabling the system to operate efficiently and in a coordinated manner.

[0043] Communication monitoring and maintenance correspond to the periodic or on-demand queue port and sampling port information query and status judgment operations in algorithm step A3, which correspond to the communication execution and monitoring stage in the inter-core communication method of multi-core processors. Its significance lies in its ability to monitor the communication status in real time and promptly identify potential problems. When abnormal situations such as queue congestion or no new messages at the sampling port occur, corresponding measures can be taken quickly, such as adjusting the message scheduling strategy or troubleshooting, ensuring the continuity and stability of communication. It's like equipping the communication system with an "intelligent guardian," constantly protecting the normal operation of communication and effectively improving system availability and performance.

[0044] The above embodiments are merely preferred technical solutions of the present invention and should not be considered as limitations on the present invention. The scope of protection of the present invention should be limited to the technical solutions described in the claims, including equivalent substitutions of the technical features described in the claims. That is, equivalent substitutions and improvements within this scope are also within the scope of protection of the present invention.

Claims

1. A method for inter-core communication in a multi-core processor, characterized by: The method includes: S1. Determine the processor module partition and perform inter-partition communication initialization, and configure the corresponding virtual partitions, virtual ports and corresponding drivers; S2. Call the corresponding inter-partition communication interface program in each partition application that needs to communicate. S3, The corresponding communication services are provided by the partition application; S4. When data messages are required to be received sequentially and in order, the interface for creating a queue port needs to be called. Messages are sent to the source port in the queue port through the message sending interface in the partition application. In the partition that needs to receive messages, the interface in the partition application is called to receive messages from the destination queue port in order.

2. The method for inter-core communication in a multi-core processor according to claim 1, characterized in that: The specific steps in step S1 are as follows: For the hardware platform, initialization operations need to be performed on the power supply, HDMI, USB to serial port, network port, and SD card module to ensure that the hardware is running normally; In heterogeneous multi-core devices using an MPU + MCU architecture, a dual-system setup of a non-real-time operating system and a real-time operating system should be installed. The non-real-time operating system runs on the main core of a specific processor, while the real-time operating system runs on the slave core. The system boot process is completed through a bootloader, which includes initializing hardware resources and reading and running the kernel image file. During the installation process, the non-real-time operating system and the real-time operating system must be correctly configured and debugged to ensure the stable operation of the dual systems.

3. The method for inter-core communication in a multi-core processor according to claim 1, characterized in that: The specific steps in step S2 are as follows: After determining the processor module partitions, perform inter-partition communication initialization. Accurately configure port information in the XML file of the partition application, including port type, name, direction and message length. For queue ports, queue length and transmission protocol also need to be defined. Configure the channel information precisely in the module.xml file, including the channel ID, source port and destination port name, and the name of the partition where it is located; For inter-module communication, virtual partitions and virtual ports are configured independently for each module, and drivers are written. Port and channel memory resources are adjusted according to actual conditions. In heterogeneous multi-core devices using the RPMsg protocol, driver modules rpmsg_core.c, virtio_rpmsg_bus.c, and imx_rpmsg.c are added to the kernel of the non-real-time operating system to realize the construction of the RPMsg bus, the association between the device and the VirtIO component, and the hardware platform configuration. The real-time operating system achieves communication by adding the RPMsg-Lite component and configuring it.

4. The method for inter-core communication in a multi-core processor according to claim 1, characterized in that: The corresponding communication service steps in step S3 are as follows: A non-preemptive priority scheduling strategy is adopted. In the message distribution unit, the message priority is set according to the message data volume or the application-specified priority. The message is distributed to high and low priority queues. The message is stored in a linked storage structure. When constructing a message node, the relevant members are assigned values ​​and inserted into the queue according to the rules. In the message scheduling unit, a kernel thread is created through the RPMsg driver. It first checks the readiness status of the high-priority queue and sends messages according to the rules. If the high-priority queue is empty, it then checks the low-priority queue and uses a mutex lock to ensure data consistency.

5. The method for inter-core communication in a multi-core processor according to claim 4, characterized in that: A priority scheduling strategy combining deficit round-robin is adopted. The message distribution unit distributes messages to the corresponding queues according to priority and queue number. Medium-priority messages are inserted into the queue according to specific rules. The message scheduling unit first judges the high-priority queue, then processes the medium-priority queue according to the deficit round-robin strategy, and finally judges the low-priority queue. The kernel thread initializes the credit value of the specified medium-priority queue and updates the deficit and sends messages according to the rules.

6. The method for inter-core communication in a multi-core processor according to claim 5, characterized in that: In terms of non-preemptive priority scheduling, the total number of messages is... , No. One message ( The priority of ) is The amount of data is The priority calculation function is defined as follows: ； in For message data volume threshold, Indicates high priority. This indicates a low priority queue; meanwhile, a high priority queue is set up. and low priority queues The queue lengths are respectively and The message delivery rates were respectively and The service rates were respectively and According to the M / G / 1 model in queuing theory, the average waiting time of messages in a high-priority queue is... and average length of stay The calculation formula is as follows: ； ； in For the first The delivery rate of high-priority messages The second moment of its service time, For the first The delivery rate of low-priority messages The average number of frames encapsulated for low-priority messages. The average service time for one message frame; These formulas and functions are used to accurately determine message priorities and calculate the message waiting and dwell time of high-priority queues through queuing theory models, providing a basis for evaluating and optimizing the performance of high-priority message transmission; In priority scheduling combined with deficit round-robin, inter-core messages are divided into three priorities: high, medium, and low. The set of high-priority messages is... The medium-priority message set is The low-priority message set is For the first message in the medium priority message set One message The credit score of its queue is The deficit is The data packet size is The priority message scheduling function is defined as follows: ； when At that time, send the message and update the deficit. ;when If the message is skipped, the system continues to check the next medium-priority message; assuming the system transmits a certain amount of data per unit time... For high-priority message groups, the arrival curve is as follows: The service curve is According to deterministic network calculus theory, the communication delay boundary of high-priority message groups The calculation formula is: ； These functions and formulas are used to achieve fair scheduling and bandwidth allocation for medium-priority messages, and to calculate the communication delay boundary of high-priority message groups through deterministic network calculus theory, ensuring that the system meets the communication requirements of messages of different priorities and improving the real-time performance and reliability of the system.

7. The method for inter-core communication in a multi-core processor according to claim 1, characterized in that: The steps in step S4 are as follows: The sender calls the corresponding inter-partition communication interface program in the partition application, calls the interface to create queue ports or sampling ports as needed, and sends messages to the corresponding ports through the message sending interface in the partition application. During the sending process, the message scheduling strategy adopted must be followed, and the messages should be placed in the corresponding queue or processed according to the deficit polling rule. By utilizing the provided interface service, the queue port ID and status can be obtained by the queue port name, and the sampling port ID and status can be obtained by the sampling port name. Based on the monitoring results, the communication status can be judged, and abnormal situations can be handled and optimized to ensure normal and stable communication. The receiving party calls the interface in the partition application in the partition that needs to receive messages, and receives messages according to the message sending mode. In queue mode, messages are sent from the message queue of the source port to the message queue of the destination port in first-in-first-out order, and the receiving party retrieves messages from the queue of the destination port.

8. The method for inter-core communication in a multi-core processor according to claim 7, characterized in that: In sampling mode, new messages overwrite old messages, and the receiver receives the last updated message from the sending partition. Using the provided interface service, the queue port ID can be obtained by the queue port name, and then the status of the queue port can be obtained. The sampling port ID and the current status of the specified sampling port can be obtained by the sampling port name, so as to monitor and manage the communication process. By monitoring port status, problems in the communication process can be detected in a timely manner, such as whether the queue is congested or messages are lost, and corresponding measures can be taken to optimize the process.

9. A method for inter-core communication in a multi-core processor according to claim 8, characterized in that: in Regarding message sending and receiving, the success rate function for the sender's partition application is: ,in The factors influencing successful transmission are represented as a vector, such as network status parameters and port status parameters. A linear regression model is established through statistical analysis of historical transmission data. ； in For regression coefficients, This is the error term; the sender uses this function to evaluate the success rate of this message transmission. When the success rate is lower than a set threshold, retransmission or adjustments to the transmission strategy are taken to ensure reliable message delivery. The receiver sets the message reception accuracy function as follows: ,in The vector represents the factors affecting reception accuracy, such as signal strength parameters and receiver queue status parameters; a logistic regression model is obtained through data fitting: ； The receiver uses this function to determine the accuracy of the received message, and verifies or requests a retransmission of potentially erroneous messages to ensure the correctness of the received message. In terms of communication status monitoring, let the congestion index of the queue port be... Defined as: ； in This is the current queue length. The maximum capacity of the queue; when When the congestion threshold is exceeded, the system takes congestion control measures, such as adjusting the message scheduling strategy and increasing the buffer, to ensure smooth communication; for the sampling port, the information update frequency is set to... The information timeliness function is , is represented as: ； in This refers to the last time the information was updated. This is the time-dependent attenuation coefficient; when When the timeliness threshold is lower than set, a message will be displayed indicating a possible communication problem or sender failure, so that timely troubleshooting and repair can be carried out to improve the reliability and real-time performance of the system.

10. The method for inter-core communication in a multi-core processor according to claim 1, characterized in that: The algorithm steps in steps S1-S4 are as follows: A1. After the hardware platform is powered on, the processor performs a reset operation; To boot the Cortex-A53 kernel using the U-boot loader, follow these steps: Initialize memory, set the clock, and disable interrupt hardware resources; Read the system kernel image file from memory and determine whether it is a non-real-time operating system image file or a real-time operating system image file; If it is a real-time operating system image file, copy it into the memory of the Cortex-M7 core and wake up the Cortex-M7 core to start the real-time operating system; if it is a non-real-time operating system image file, run the kernel file to start the non-real-time operating system. A2. When a message arrives, the message distribution unit performs the following operations: Retrieve message priority and queue number information; The message's queue type is determined by its priority and queue number, including high, medium, and low priority queues. If it is a high-priority or low-priority message, find the corresponding queue node and insert the message node into the queue using the tail insertion method; If it is a medium priority message, first find the head node of the queue, then find the corresponding queue according to the queue number, and use the tail insertion method to insert the message node into the queue; The message scheduling unit executes the following loop operation through kernel threads: Determine if the high-priority queue is ready, i.e., whether the message count of the queue head node is greater than 0. If it is, retrieve the message pointed to by the queue head node, send the message through the RPMsg channel, and then continue to check if there are any more messages in the high-priority queue. If the high-priority queue is empty, proceed to the next step. To determine if a medium-priority queue is ready, perform the following steps: Obtain the index of the current waiting service queue and find the corresponding queue node; Determine whether the queue deficit needs to be updated based on whether it is the first visit or a round of scheduling has been completed. If so, update the deficit of all queues by adding the queue credit value quantum to the deficit. Check if the queue is empty. If it is, clear the value of deficit to zero. If it is not empty, check if the value of deficit is greater than the length of the message to be transmitted. If it is, output the message and update the values ​​of deficit and cur_p. Otherwise, continue to check the next queue. Determine if the low-priority queue is ready. If it is, retrieve the message pointed to by the queue head node and send it through the RPMsg channel; otherwise, wait for the queue to become ready. A3. Call the following operations periodically or as needed: Find the corresponding queue port ID by queue port name; Retrieve the status information of the queue port based on the queue port ID, including queue length, number of messages, and whether there are any messages waiting to be sent; Find the sampling port ID based on the sampling port name; Get the current status information of the specified sampling port based on the sampling port ID, such as whether there are new messages and the timestamp of the latest message; Make judgments and handle actions based on the acquired status information: If the queue length is too long or the message waiting time is too long, it may indicate that there is communication congestion, and it is necessary to adjust the message scheduling strategy or check whether the system resources are insufficient. If the sampling port does not receive any new messages for an extended period, it may indicate a problem with the sender or a communication link interruption, requiring troubleshooting.

Images