Inter-core communication method and device, vehicle and computer readable storage medium

Abstract

The embodiment of the invention relates to the technical field of communication, and discloses an inter-core communication method and device, a vehicle and a computer readable storage medium, and the method comprises the steps: firstly storing a to-be-processed request to a first queue and a second queue through a first core, and enabling the real-time performance of the to-be-processed request stored in the first queue to be higher than that of the second queue; the queue priority of the first queue is higher than that of the second queue. And then, sequentially sending the to-be-processed requests stored in the first queue and the second queue to a shared memory through the first core according to a sequence of queue priorities from high to low. And finally, obtaining the to-be-processed request from the shared memory through the second core. By applying the technical scheme of the invention, the requests with high real-time requirements can be processed preferentially, and the stability of vehicle control is ensured.

Description

Technical Field

[0001] Embodiments of the present invention relate to the field of communication technology, and specifically to an inter-core communication method, device, vehicle and computer-readable storage medium. Background Art

[0002] At present, most vehicle systems use the basic architecture of application processors (A cores), real-time processors (R cores) and microcontrollers (M cores). Generally, the chips of smart gateways will use heterogeneous systems, that is, they have multiple high-computing A cores (system on chip (SoC)) to run the Linux complex operating system plus one or more M cores (microcontroller units (MCU)) to run the real-time operating system. Since the A core side and the M core side have different processing capabilities for requests, and in order to meet the requirements of high-performance computing and high-real-time requests at the same time, the requests within the two cores need to be forwarded to each other, so it is particularly important to ensure efficient and reliable communication between the two cores.

[0003] However, the inter-core communication method in the prior art is difficult to ensure timely processing of requests with high real-time requirements, resulting in unstable vehicle control. Summary of the invention

[0004] In view of the above problems, an embodiment of the present invention provides an inter-core communication method, device, vehicle and computer-readable storage medium, which are used to solve the problem in the prior art that it is difficult to ensure timely processing of requests with high real-time requirements, resulting in unstable vehicle control.

[0005] According to one aspect of an embodiment of the present invention, there is provided an inter-core communication method, the method comprising:

[0006] The first core stores the pending requests in a first queue and a second queue, wherein the pending requests stored in the first queue have a higher real-time performance than those in the second queue, and the queue priority of the first queue is higher than that of the second queue;

[0007] Sending the pending requests stored in the first queue and the second queue to the shared memory in sequence according to the queue priority from high to low through the first core;

[0008] The pending request is obtained from the shared memory through the second core.

[0009] According to another aspect of an embodiment of the present invention, there is provided an inter-core communication device, comprising:

[0010] A storage module, used for storing the pending requests into a first queue and a second queue through the first core, wherein the pending requests stored in the first queue have higher real-time performance than those stored in the second queue, and the queue priority of the first queue is higher than that of the second queue;

[0011] A sending module, configured to send the pending requests stored in the first queue and the second queue to the shared memory in sequence according to the queue priority from high to low through the first core;

[0012] An acquisition module is used to acquire the pending request from the shared memory through the second core.

[0013] According to another aspect of an embodiment of the present invention, there is provided a vehicle, comprising: a vehicle body and a vehicle controller;

[0014] Wherein, the vehicle controller includes a processor, a memory, a communication interface and a communication bus, and the processor, the memory and the communication interface communicate with each other through the communication bus;

[0015] The memory is used to store at least one executable instruction, and the executable instruction enables the processor to execute the operation of the above-mentioned inter-core communication method.

[0016] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is provided, wherein the storage medium stores at least one executable instruction, wherein the executable instruction enables an inter-core communication device / vehicle to perform the operation of the above-mentioned inter-core communication method.

[0017] The inter-core communication method, device, vehicle and computer-readable storage medium provided by the embodiment of the present invention, in which the pending requests are first stored in the first queue and the second queue by the first core, the real-time performance of the pending requests stored in the first queue is higher than that of the second queue, and the queue priority of the first queue is higher than that of the second queue. Then, the pending requests stored in the first queue and the second queue are sent to the shared memory in sequence by the first core in the order of queue priority from high to low. Finally, the pending requests are obtained from the shared memory by the second core. In this technical solution, the first queue is used to store the pending requests with high real-time requirements, and the second queue is used to store the remaining pending requests. When obtaining the pending requests that need to be sent from the first core to the second core, they are obtained from the first queue first, and after all the pending requests in the first queue are obtained, they are obtained from the second queue. In this way, it can be ensured that the pending requests with high real-time performance will be processed first, thereby improving the stability of vehicle control.

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

[0019] The accompanying drawings are only used to illustrate the embodiments and are not to be considered as limiting the present invention. In addition, the same reference symbols are used to represent the same components throughout the accompanying drawings. In the accompanying drawings:

[0020] Figure 1 A schematic structural diagram of a vehicle provided by an embodiment of the present invention is shown;

[0021] Figure 2 A schematic diagram of the structure of a shared memory provided by an embodiment of the present invention is shown;

[0022] Figure 3 The schematic diagram shows the process of the inter-core communication method provided by the embodiment of the present invention. Figure 1 ;

[0023] Figure 4 The schematic diagram shows the process of the inter-core communication method provided by the embodiment of the present invention. Figure 2 ;

[0024] Figure 5 A schematic diagram of a scenario of an inter-core communication method provided by an embodiment of the present invention is shown;

[0025] Figure 6 A schematic diagram showing the structure of an inter-core communication device provided by an embodiment of the present invention is shown;

[0026] Figure 7 A schematic structural diagram of a vehicle controller provided by an embodiment of the present invention is shown. DETAILED DESCRIPTION

[0027] Exemplary embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the present invention are shown in the drawings, it should be understood that the present invention can be implemented in various forms and should not be limited to the embodiments set forth herein.

[0028] First, the scenario involved in the present invention is explained.

[0029] In modern vehicle system design, a heterogeneous processor architecture is commonly used, which combines A cores, R cores and M cores. Smart gateway chips with this architecture usually contain multiple high-performance A cores that run complex operating systems such as Linux to support advanced computing tasks; at the same time, they are also equipped with one or more M cores that run real-time operating systems to handle time-sensitive requests.

[0030] Given the differences in request processing capabilities between the A-core and the M-core, and the need for the system to simultaneously meet the requirements of high-performance computing and real-time requests, it is critical to achieve effective forwarding and processing of requests between the A-core and the M-core. In order to ensure the efficiency and reliability of the system, an efficient and reliable inter-core communication mechanism must be designed to seamlessly transfer information and tasks between different types of processors. The design and implementation of this communication mechanism has a decisive impact on the performance and stability of the entire vehicle system.

[0031] The existing inter-core communication method generally determines which request needs to be processed first through a scheduling algorithm. Since the scheduling algorithm is responsible for allocating limited CPU time slices to ensure that all requests have a chance to run and to prevent some requests from not being executed for a long time, this will result in requests that have not been executed for a long time being processed before requests with high real-time requirements. Requests with high real-time requirements are usually related to vehicle safety functions, such as anti-collision systems, braking systems, steering control, etc. If requests with high real-time requirements are not processed in a timely manner, it may cause the vehicle to react slowly, increase the risk of accidents, and reduce the stability of the vehicle and the driving experience.

[0032] Based on this, the technical concept of the present invention is as follows: Since requests with high real-time requirements are usually related to the safety functions of the vehicle, even if some requests have been waiting for a long time, requests with high real-time requirements should be processed before these requests. Considering that requests can be stored in queues, a separate queue can be used to store requests with high real-time requirements, and a queue priority higher than other queues can be set for this queue. In this way, when inter-core communication is performed subsequently, the requests stored in the queue with a high queue priority can be transmitted first in the order of queue priority from high to low, which can ensure that as long as there are requests with high real-time requirements, they will be processed first, thereby ensuring the safety and stability of vehicle driving.

[0033] Figure 1 FIG. 1 shows a schematic diagram of the structure of a vehicle provided by an embodiment of the present invention. Figure 1 As shown, the vehicle includes: a generic interrupt controller (GIC), a first core, a second core, a static random access memory (SRAM) and a double data rate dynamic random access memory (DDR) memory.

[0034] Among them, in a multi-core system, inter-processor communication (IPC) technology usually involves data exchange and task coordination between multiple cores. First, an area can be divided on the on-chip memory of the system chip or the external DDR memory. Then this memory area is subdivided according to the number of communicating clients and the maximum amount of data in one communication. Each client has its own exclusive memory area for storing sent and received data. A sending end and a receiving end are required for each client. Among them, the receiving end generally needs to notify the corresponding core to process the request through an interrupt. In this case, the interrupt is the key trigger mechanism. The GIC generates an interrupt signal by triggering the interrupt. The interrupt signal is transmitted to the target core through the GIC route, triggering the corresponding interrupt function. Finally, the interrupt function will throw the request into the local priority queue of the target core according to the priority, and process the request in sequence according to the priority.

[0035] In one implementation, the first core is first responsible for packaging the pending requests stored in the first queue and the second queue in descending order of queue priority to form a request packet and then sending it to the SRAM (also called a shared space or a target storage space); then, the GIC is responsible for sending an interrupt signal to the second core to notify the second core that a request packet is stored in the target storage space; finally, the second core is responsible for obtaining the request packet from the target storage space to perform the request processing operation. DDR memory can transmit data twice in each cycle, and can be used when there are a large number of pending requests, thereby effectively improving the data transmission rate, improving the overall performance of the vehicle and the reliability of data transmission.

[0036] By applying this inter-core communication method in the vehicle, it is ensured that the second core can process the request packets sent by the first core in a timely and accurate manner, thereby improving the efficiency of request processing, ensuring the stability of the vehicle, and having good scalability. More cores and queues can be added in the future according to actual needs to further enhance the vehicle's parallel processing capabilities and overall performance.

[0037] Figure 2 FIG. 4 shows a schematic diagram of a shared memory structure provided by an embodiment of the present invention. Figure 2 As shown, the shared memory includes multiple storage spaces for storing request packets containing requests to be processed sent by one core to another core, and the second core obtains the request packets through the target storage space.

[0038] It should be noted that the first core can be A core, M1 core, M2 core, etc.; correspondingly, the second core can be A core, M1 core, M2 core, etc. And the target storage spaces in the shared memory generally appear in pairs, and the size of each target storage space is determined according to the maximum data volume of the system business and the size of the shared memory. Through the design of multiple target storage spaces, after the first core sends a request packet, the second core can locate the corresponding target storage space more quickly and perform efficient interrupt response processing, thereby improving the real-time performance of the system.

[0039] Figure 3 The schematic diagram shows the process of the inter-core communication method provided by the embodiment of the present invention. Figure 1 .like Figure 3 As shown, the method comprises the following steps:

[0040] Step 301: Store pending requests into a first queue and a second queue through a first core.

[0041] Among them, the real-time nature of the pending requests in the first queue is higher than that of the second queue, and the queue priority of the first queue is higher than that of the second queue.

[0042] Optionally, the pending requests stored in the first queue are requests related to the driver layer, and the pending requests stored in the second queue are requests related to the application layer.

[0043] It should be understood that the first queue can be used to store requests related to the driver layer. The driver layer is usually the part that directly interacts with the hardware, so these requests usually require high real-time performance and need to be processed with priority to ensure the response speed and efficiency of the vehicle.

[0044] Optionally, the first core belongs to a SoC in a vehicle.

[0045] For example, assume that the vehicle is processing sensor data collection requests and user interface update requests at the same time. For these two requests, since sensor data collection requests are directly related to the vehicle's real-time response to the external environment (such as temperature sensors detecting fire conditions), they need to be processed in real time, so such requests will be stored in the first queue and processed first. For user interface update requests, which do not require high real-time performance, such as refreshing the screen display, they can be stored in the second queue and processed after the vehicle has processed the critical sensor data.

[0046] It can be understood that by storing pending requests into different queues according to their types, pending requests related to the drive layer are stored in the first queue, and other pending requests that have relatively low real-time requirements but also need to be processed are stored in the second queue, so that when resources are limited, the vehicle gives priority to requests in the first queue to ensure that requests that require quick responses can be completed in a timely manner, thereby improving overall performance and stability.

[0047] Exemplarily, the second queue may store requests related to the application layer.

[0048] Step 302: Send the pending requests stored in the first queue and the second queue to the shared memory in sequence according to the queue priority from high to low through the first core.

[0049] The shared memory is a memory area accessible to both the first core and the second core and is used to store pending requests.

[0050] Optionally, the second core belongs to an MCU in the vehicle.

[0051] It can be understood that since the priority of the first queue is higher than that of the second queue, as long as there are pending requests stored in the first queue, the pending requests in the first queue will be sent to the shared memory first; if there are no pending requests stored in the first queue, but there are pending requests stored in the second queue, the pending requests in the second queue can be sent to the shared memory to ensure that the vehicle's pending requests related to the drive layer are responded to and processed first, thereby improving the stability of the vehicle.

[0052] In one possible implementation, referring to Figure 2 , the shared memory includes multiple storage spaces. Therefore, the target storage space can be determined from the shared memory first, and then the pending request is sent to the target storage space. Among them, the target storage space is used to store the pending request sent by the first core to the second core.

[0053] It should be understood that the specific implementation process and principle of this step will be Figure 4 The detailed description is given in the illustrated embodiment and will not be repeated here.

[0054] Step 303: Obtain the pending request from the shared memory through the second core.

[0055] It can be understood that after the pending requests stored in the first queue and the second queue are sent to the shared memory in sequence through the first core, the pending requests are obtained from the shared memory and processed through the second core.

[0056] The inter-core communication method provided by the embodiment of the present invention first stores pending requests in the first queue and the second queue through the first core. The real-time performance of the pending requests stored in the first queue is higher than that of the second queue, and the queue priority of the first queue is higher than that of the second queue. Then, the pending requests stored in the first queue and the second queue are sent to the shared memory in sequence by the first core in the order of queue priority from high to low. Finally, the pending requests are obtained from the shared memory through the second core. In this technical solution, the first queue is used to store pending requests with high real-time requirements, and the second queue is used to store other remaining pending requests. When obtaining pending requests that need to be sent from the first core to the second core, they are obtained from the first queue first, and after all pending requests in the first queue are obtained, they are obtained from the second queue. In this way, it can be ensured that pending requests with high real-time performance will be processed first, thereby improving the stability of vehicle control.

[0057] Next, the implementation process of step 302 is described in detail.

[0058] Figure 4 The schematic diagram shows the process of the inter-core communication method provided by the embodiment of the present invention. Figure 2 .like Figure 4 As shown, step 302 can be implemented by the following steps:

[0059] Step 401: The first core sequentially packages the pending requests stored in the first queue and the second queue in the order of queue priority from high to low and request priority from high to low, and obtains a plurality of request packets.

[0060] The pending requests stored in each queue are pre-configured with a request priority.

[0061] In actual applications, although it has been determined that pending requests in the first queue are processed first, and then pending requests in the second queue, there are multiple pending requests stored in each queue, and it is necessary to determine which pending requests to process first based on the request priority.

[0062] It is understandable that after determining the priority of each queue and the priority order of the pending requests in each queue, the first core can group the pending requests stored in the first queue and the second queue in sequence, and finally generate multiple request packages. In this way, while ensuring that the vehicle gives priority to pending requests with high real-time requirements, it also gives priority to pending requests with high priorities, further improving the stability of the vehicle. In addition, grouping multiple pending requests can reduce the number of data transmissions, reduce communication costs and time, and significantly improve transmission efficiency.

[0063] Step 402: Send multiple request packets to the shared memory in sequence according to the order of packet assembly time from first to last through the first core.

[0064] The shared memory is pre-divided into a plurality of storage spaces, and the target storage space among the plurality of storage spaces is used to store the pending requests sent by the first core to the second core.

[0065] Therefore, in one implementation, the first core sends multiple request packets to the target storage space in sequence according to the order of packet assembly time from earliest to latest.

[0066] Optionally, in step 401, the first core groups the requests to be processed in sequence according to the queue priority from high to low and the request priority from high to low, and when multiple request packets are formed, each request packet has a clear packet grouping moment, that is, the time point when it is generated.

[0067] Optionally, when the first core completes the package assembly processing of the first request packet, it can send the request packet to the target storage space. Correspondingly, when the package assembly processing of the second request packet is completed, the request packet is sent to the target storage space again, until the last request packet is packaged and sent to the target storage space.

[0068] It can be understood that the first core sends the request packets to the target storage space in the shared memory in the order of their packet assembly time from first to last. The purpose is to ensure that the request packets can enter the target storage space in an orderly manner according to the order in which they are generated, so that the subsequent second core can process the requests in the expected order, and further ensure that the pending requests with high real-time requirements can be processed with higher priority.

[0069] In one implementation, the specific implementation of step 303 may be achieved through the following steps:

[0070] An interrupt signal is sent to the second core, and the second core obtains the request packet from the target storage space according to the interrupt signal.

[0071] The interrupt signal is used to notify the second core that a request packet is stored in the target storage space.

[0072] In actual applications, GIC detects in real time whether each storage space in the shared memory contains a request packet. After detecting that there is a request in the target storage space, an interrupt signal is sent to the second core. After receiving the interrupt signal, the second core obtains the request packet stored in the target storage space from the target storage space.

[0073] It can be understood that this method ensures that the second core can efficiently and timely process multiple request packets from the first core through interrupt notification, thereby improving the real-time performance and processing efficiency of the vehicle.

[0074] The inter-core communication method provided by the embodiment of the present invention firstly performs packet grouping processing on the pending requests stored in the first queue and the second queue in sequence according to the queue priority from high to low and the request priority from high to low through the first core, and obtains multiple request packets; then, the first core sends the multiple request packets in sequence to the shared memory in sequence according to the packet grouping time from first to last. The method utilizes the priority sorting of pending requests and the time sequence of packet grouping to send them in sequence, optimizes the transmission process of request packets, ensures that key requests are processed first and transmitted in sequence, and improves the stability of the vehicle.

[0075] In one implementation, when the first core performs packet processing on the pending requests stored in the first queue and the second queue in sequence according to the queue priorities, the specific process is as follows:

[0076] First, the first core sequentially obtains the pending requests stored in the first queue in order of request priority from high to low, until the number of pending requests obtained reaches a preset number of requests, or all pending requests stored in the first queue are obtained; then, if all pending requests stored in the first queue are obtained, and the number of pending requests obtained does not reach the preset number of requests, the first core sequentially obtains the pending requests stored in the second queue in order of request priority from high to low, until the total number of pending requests obtained reaches the preset number of requests, or all pending requests stored in the second queue are obtained; finally, the first core performs package processing on the obtained pending requests to generate a request package.

[0077] For example, assuming that the preset request volume is 10 pending requests, in the first core, the number of pending requests in the first queue is 11, and the number of pending requests in the second queue is 10. After the first core obtains the first 10 pending requests in the first queue in descending order of priority, it directly performs package grouping; then, after obtaining the remaining 1 pending request in the first queue, it continues to obtain the first 9 pending requests from the second queue in descending order of priority and performs a second package grouping; accordingly, after obtaining all the remaining pending requests in the second queue, it performs package grouping again, and finally generates three request packages.

[0078] For example, assuming that the preset request amount is 10 pending requests, in the first core, the number of pending requests in the first queue is 5, and the number of pending requests in the second queue is 4. After the first core obtains 5 pending requests in the first queue in descending order of priority, it continues to obtain 4 pending requests from the second queue in descending order of priority and performs package processing to generate a request package.

[0079] It is understandable that, since the priority of the first queue is higher than that of the second queue, the pending requests stored in the first queue will be first obtained in order of priority from high to low when performing package processing. If the request amount of pending requests obtained from the first queue reaches the preset request amount, the step of obtaining the pending requests in the second queue is skipped, and the package processing operation is directly entered; if all pending requests in the first queue have been obtained, but the pending requests obtained at this time do not reach the preset request amount, then the first core continues to obtain the pending requests stored in the second queue in order of request priority from high to low, until the total amount of pending requests obtained from the first queue and the second queue reaches the preset request amount, or all pending requests stored in the second queue are also obtained, then the first core performs package processing on the pending requests that have been obtained to generate one or more request packages, so that they can be transmitted and executed more efficiently during subsequent processing. In this way, different vehicle load conditions can be flexibly adapted. When there are more requests with high real-time requirements, the vehicle can process these tasks quickly; when there are fewer requests with high real-time requirements, requests with low real-time requirements can also be scheduled and processed in a timely manner. At the same time, by packaging the requests, the cost of data transmission can be further reduced and the overall processing efficiency of the vehicle can be improved.

[0080] It should be noted that, according to the queue priority, the pending requests in the first queue will be packaged and processed first, and the second queue contains pending requests that are not real-time-sensitive but have a long waiting time. In order to ensure that all pending requests can get corresponding responses, it is necessary to further sort the pending requests in the second queue. The specific implementation process is as follows:

[0081] First, the first core sorts the pending requests stored in the second queue according to request priority and residence time to generate a pending request sequence; then, the first core obtains the pending requests in the pending request sequence according to the order of the pending request sequence from front to back.

[0082] Among them, a pending request with a higher request priority or a longer stay time has a higher position in the pending request sequence.

[0083] Optionally, in order to ensure that requests with a long stay time but a low priority can still be processed in a timely manner, the priority and waiting time of the request can be weighted and combined by setting weights to calculate a "comprehensive priority" value, and then the requests can be sorted according to this comprehensive priority.

[0084] For example, suppose there are three requests in the vehicle: Request A: priority P is 8, stay time T is 2 minutes; Request B: priority P is 5, stay time T is 10 minutes; Request C: priority P is 3, stay time T is 15 minutes. Among them, the weight of priority P is W p is 0.7, and the weight of the stay time T is W t is 0.3.

[0085] For each request, calculate its comprehensive priority value P c The calculation formula can be:

[0086] P c =W p *P+W t *T

[0087] Among them, P c is the comprehensive priority value of each request, P is the initial priority of each request, T is the stay time of each request, and W is the p is the priority weight, W t is the weight of the stay duration.

[0088] The corresponding comprehensive priorities of request A, request B, and request C are 6.2, 6.5, and 6.6, respectively, that is, the final sequence of pending requests is: request C> request B> request A. The specific priority weights, the weights of the dwell time, and the calculation formula of the comprehensive priority value can be determined according to the actual situation, and the embodiment of the present invention does not make any specific restrictions here.

[0089] It can be understood that by sorting the pending requests based on priority and dwell time, the vehicle can arrange the order of request processing more reasonably, ensuring that key requests are executed in a timely manner while taking into account those requests that have been waiting for a long time, thereby improving the overall fairness of the vehicle and the balance of request processing.

[0090] Figure 5 FIG. 1 is a schematic diagram showing a scenario of an inter-core communication method provided by an embodiment of the present invention. Figure 5 As shown, the scenario diagram includes: a first core and a second core.

[0091] Among them, the first core provides an interface to the application layer to realize the functions of sending requests and receiving data of the application layer (application (Application, APP) 1, APP2, APP3). The monitoring program monitors the application layer, and after monitoring the pending request of the application layer, writes the pending request to the inter-core communication driver in the kernel layer. At the same time, the display driver can send an add request instruction to the inter-core communication driver to add the pending request generated by the display driver to the inter-core communication driver. The inter-core communication driver divides the acquired pending requests according to the multi-queue and multi-priority method, and stores the first queue and the second queue through the channel transmission command prompt. That is, the pending request related to the driver layer is placed in the first queue, and the pending request related to the application layer is placed in the second queue (i.e., queue buffer operation). Further, the kernel process will periodically group the pending requests stored in the first queue and the second queue in the order of queue priority from high to low to form a request packet and send it to the shared memory, and finally trigger an interrupt signal to notify the second core that a request packet has been sent. Finally, after receiving the interrupt signal, the second core immediately reads the request packet data from the shared memory, and distributes the obtained pending request to the corresponding request processor or display driver for processing.

[0092] Correspondingly, when the second core sends the processing result to the first core, the request processor in the second core first calls the sending interface to write the processing result into the shared memory; then, the first core receives the interrupt signal and copies the processing result into the loop storage. Finally, the inter-core communication driver reads all the processing results in the loop storage at one time and distributes them to the corresponding display driver or application layer.

[0093] It should be understood that the process of the second core sending the pending request to the first core is consistent with the process of the second core sending the processing result to the first core. The process of the first core sending the processing result to the second core is consistent with the process of the first core sending the pending request to the second core.

[0094] The inter-core communication method provided by the embodiment of the present invention first stores the pending requests in the first queue and the second queue through the first core, the real-time performance of the pending requests stored in the first queue is higher than that of the second queue, and the queue priority of the first queue is higher than that of the second queue; then, the pending requests stored in the first queue and the second queue are sent to the shared memory in sequence according to the queue priority from high to low through the first core; finally, the pending requests are obtained from the shared memory through the second core, so that the vehicle can effectively manage and process requests with different real-time requirements, thereby ensuring the vehicle's response speed to high real-time tasks, while rationally utilizing resources, reducing the long waiting time of low-priority requests, and improving the stability of the vehicle.

[0095] Figure 6 FIG. 1 shows a schematic diagram of the structure of the inter-core communication device provided by an embodiment of the present invention. Figure 6 As shown, the inter-core communication device 60 includes: a storage module 601, a sending module 602 and an acquisition module 603.

[0096] The storage module 601 is used to store the pending requests into the first queue and the second queue through the first core, the pending requests stored in the first queue have higher real-time performance than those stored in the second queue, and the queue priority of the first queue is higher than that of the second queue;

[0097] The sending module 602 is used to send the pending requests stored in the first queue and the second queue to the shared memory in sequence according to the queue priority from high to low through the first core;

[0098] The acquisition module 603 is used to acquire the pending request from the shared memory through the second core.

[0099] In an optional manner, the storage module 601 is specifically configured to:

[0100] The first core sequentially packages the pending requests stored in the first queue and the second queue in the order of queue priority from high to low and request priority from high to low, to obtain multiple request packets;

[0101] The first core sends the multiple request packets to the shared memory in sequence according to the order of packet assembly time.

[0102] In an optional manner, the inter-core communication device 60 further includes a processing module, which is specifically configured to:

[0103] Obtaining the pending requests stored in the first queue in sequence according to the order of request priority from high to low through the first core until the number of pending requests obtained reaches a preset number of requests, or all pending requests stored in the first queue are obtained; wherein the pending requests stored in each queue are pre-configured with a request priority;

[0104] If all pending requests stored in the first queue are obtained, and the request amount of the pending requests obtained does not reach the preset request amount, the pending requests stored in the second queue are obtained in sequence by the first core in the order of request priority from high to low, until the total request amount of the pending requests obtained reaches the preset request amount, or all pending requests stored in the second queue are obtained;

[0105] The first core performs packet processing on the acquired requests to be processed to generate a request packet.

[0106] In an optional manner, the processing module is specifically configured to:

[0107] The first core sorts the pending requests stored in the second queue according to the request priority and the residence time to generate a pending request sequence; wherein the pending request with a higher request priority or a longer residence time has a higher position in the pending request sequence;

[0108] The first core obtains the pending requests in the pending request sequence according to the order of the pending request sequence from front to back.

[0109] In an optional manner, the shared memory is pre-divided into a plurality of storage spaces, and a target storage space among the plurality of storage spaces is used to store the pending request sent by the first core to the second core. The sending module 602 is specifically used to:

[0110] The first core sends the multiple request packets to the target storage space in sequence according to the order of packet assembly time.

[0111] In an optional manner, the acquisition module 603 is specifically configured to:

[0112] Sending an interrupt signal to the second core, where the interrupt signal is used to notify the second core that a request packet is stored in the target storage space;

[0113] The second core obtains the request packet from the target storage space according to the interrupt signal.

[0114] In an optional manner, the pending requests stored in the first queue are requests related to the driver layer, and the pending requests stored in the second queue are requests related to the application layer;

[0115] The first core belongs to the SoC in the vehicle, and the second core belongs to the MCU in the vehicle.

[0116] Exemplarily, the storage module 601, the sending module 602, the acquiring module 603 and the processing module may be implemented by a processor of a vehicle controller.

[0117] From the above, it can be seen that the inter-core communication device 60 provided in the embodiment of the present invention not only improves the accuracy of the second core in processing the pending request, but also ensures that the vehicle can respond to key requests in a timely manner. In addition, the inter-core communication device 60 provided in the embodiment of the present invention, on the basis of dividing the requests according to queues and priorities to ensure accurate processing of requests, also has good scalability, and can add more cores and queues according to actual needs, further improving the parallel processing capability and overall performance of the vehicle.

[0118] An embodiment of the present invention provides a vehicle, which includes: a vehicle body and a vehicle controller.

[0119] Figure 7FIG. 1 shows a schematic diagram of the structure of a vehicle controller provided by an embodiment of the present invention. Figure 7 As shown, the vehicle controller 70 may include: a processor (processor) 701, a memory 702, a communication interface (Communications Interface) 703, and a communication bus 704.

[0120] The processor 701, the communication interface 703, and the memory 702 communicate with each other through the communication bus 704. The communication interface 703 is used to communicate with other devices such as a client or other server network elements. The processor 701 is used to execute the program 705, which can specifically execute the relevant steps in the above-mentioned embodiment of the method for inter-core communication.

[0121] Specifically, the program 705 may include program code, which includes computer-executable instructions.

[0122] The processor 701 may be a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present invention. The one or more processors included in the vehicle controller 70 may be processors of the same type, such as one or more CPUs; or processors of different types, such as one or more CPUs and one or more ASICs.

[0123] The memory 702 is used to store the program 705. The memory 702 may include a high-speed RAM memory, and may also include a non-volatile memory (non-volatile memory), such as at least one disk memory.

[0124] Program 705 can be specifically called by processor 701 to enable the vehicle to perform the following operations:

[0125] The first core stores the pending requests in the first queue and the second queue, the pending requests stored in the first queue have higher real-time performance than the second queue, and the queue priority of the first queue is higher than that of the second queue;

[0126] Sending the pending requests stored in the first queue and the second queue to the shared memory in sequence according to the queue priority from high to low through the first core;

[0127] The second core retrieves pending requests from shared memory.

[0128] In an optional manner, the first core sequentially sends the pending requests stored in the first queue and the second queue to the shared memory in descending order of queue priority, including:

[0129] The first core sequentially performs packet processing on the pending requests stored in the first queue and the second queue in the order of queue priority from high to low and request priority from high to low, to obtain multiple request packets; wherein the pending requests stored in each queue are pre-configured with a request priority;

[0130] The first core sends the multiple request packets to the shared memory in sequence according to the order of packet assembly time.

[0131] In an optional manner, the first core sequentially performs packet processing on the pending requests stored in the first queue and the second queue in the order of queue priority from high to low and request priority from high to low, to obtain multiple request packets, including:

[0132] Obtaining, by the first core, the pending requests stored in the first queue in descending order of request priority, until the number of pending requests obtained reaches a preset number of requests, or all pending requests stored in the first queue are obtained;

[0133] If all pending requests stored in the first queue are obtained, and the request amount of the pending requests obtained does not reach the preset request amount, the pending requests stored in the second queue are obtained in sequence by the first core in the order of request priority from high to low, until the total request amount of the pending requests obtained reaches the preset request amount, or all pending requests stored in the second queue are obtained;

[0134] The first core performs packet processing on the acquired requests to be processed to generate a request packet.

[0135] In an optional manner, obtaining the pending requests stored in the second queue in order of request priority from high to low by the first core includes:

[0136] The first core sorts the pending requests stored in the second queue according to the request priority and the residence time to generate a pending request sequence; wherein the pending request with a higher request priority or a longer residence time has a higher position in the pending request sequence;

[0137] The first core obtains the pending requests in the pending request sequence according to the order of the pending request sequence from front to back.

[0138] In an optional manner, the shared memory is pre-divided into a plurality of storage spaces, and a target storage space among the plurality of storage spaces is used to store the pending requests sent by the first core to the second core, and the first core sequentially sends the plurality of request packets to the shared memory in a first-to-last order of packet assembly time, including:

[0139] The first core sends the multiple request packets to the target storage space in sequence according to the order of packet assembly time.

[0140] In an optional manner, obtaining the pending request from the shared memory by the second core includes:

[0141] Sending an interrupt signal to the second core, where the interrupt signal is used to notify the second core that a request packet is stored in the target storage space;

[0142] The second core obtains the request packet from the target storage space according to the interrupt signal.

[0143] In an optional manner, the pending requests stored in the first queue are requests related to the driver layer, and the pending requests stored in the second queue are requests related to the application layer;

[0144] The first core belongs to the SoC in the vehicle, and the second core belongs to the MCU in the vehicle.

[0145] Therefore, the vehicle provided by the embodiment of the present invention, with the help of the superiority of inter-core communication technology, takes into account that different pending requests have different types and requirements, and sets up two queues in the first core according to the real-time requirements of the pending requests, so that pending requests with high real-time requirements can be processed first, avoiding backlog and congestion of pending requests in a single queue, and ensuring that the system can respond to critical requests in a timely manner.

[0146] An embodiment of the present invention provides a computer-readable storage medium, which stores at least one executable instruction. When the executable instruction is executed on the inter-core communication device 60 / vehicle, the inter-core communication device 60 / vehicle executes the inter-core communication method in any of the above method embodiments.

[0147] The executable instructions may be specifically used to enable the inter-core communication device 60 / vehicle to perform the following operations:

[0148] The first core stores the pending requests in the first queue and the second queue, the pending requests stored in the first queue have higher real-time performance than the second queue, and the queue priority of the first queue is higher than that of the second queue;

[0149] Sending the pending requests stored in the first queue and the second queue to the shared memory in sequence according to the queue priority from high to low through the first core;

[0150] The second core retrieves pending requests from shared memory.

[0151] In an optional manner, the first core sequentially sends the pending requests stored in the first queue and the second queue to the shared memory in descending order of queue priority, including:

[0152] The first core sequentially performs packet processing on the pending requests stored in the first queue and the second queue in the order of queue priority from high to low and request priority from high to low, to obtain multiple request packets; wherein the pending requests stored in each queue are pre-configured with a request priority;

[0153] The first core sends the multiple request packets to the shared memory in sequence according to the order of packet assembly time.

[0154] In an optional manner, the first core sequentially performs packet processing on the pending requests stored in the first queue and the second queue in the order of queue priority from high to low and request priority from high to low, to obtain multiple request packets, including:

[0155] Obtaining, by the first core, the pending requests stored in the first queue in descending order of request priority, until the number of pending requests obtained reaches a preset number of requests, or all pending requests stored in the first queue are obtained;

[0156] If all pending requests stored in the first queue are obtained, and the request amount of the pending requests obtained does not reach the preset request amount, the pending requests stored in the second queue are obtained in sequence by the first core in the order of request priority from high to low, until the total request amount of the pending requests obtained reaches the preset request amount, or all pending requests stored in the second queue are obtained;

[0157] The first core performs packet processing on the acquired requests to be processed to generate a request packet.

[0158] In an optional manner, obtaining the pending requests stored in the second queue in order of request priority from high to low by the first core includes:

[0159] The first core sorts the pending requests stored in the second queue according to the request priority and the residence time to generate a pending request sequence; wherein the pending request with a higher request priority or a longer residence time has a higher position in the pending request sequence;

[0160] The first core obtains the pending requests in the pending request sequence according to the order of the pending request sequence from front to back.

[0161] In an optional manner, the shared memory is pre-divided into a plurality of storage spaces, and a target storage space among the plurality of storage spaces is used to store the pending requests sent by the first core to the second core, and the first core sequentially sends the plurality of request packets to the shared memory in a first-to-last order of packet assembly time, including:

[0162] The first core sends the multiple request packets to the target storage space in sequence according to the order of packet assembly time.

[0163] In an optional manner, obtaining the pending request from the shared memory by the second core includes:

[0164] Sending an interrupt signal to the second core, where the interrupt signal is used to notify the second core that a request packet is stored in the target storage space;

[0165] The second core obtains the request packet from the target storage space according to the interrupt signal.

[0166] In an optional manner, the pending requests stored in the first queue are requests related to the driver layer, and the pending requests stored in the second queue are requests related to the application layer;

[0167] The first core belongs to the SoC in the vehicle, and the second core belongs to the MCU in the vehicle.

[0168] Therefore, in an embodiment of the present invention, with the help of the superiority of inter-core communication technology, taking into account that different pending requests have different types and requirements, two queues are set up in the first core according to the real-time requirements of the pending requests, so that pending requests with high real-time requirements can be processed first, avoiding backlog and congestion of pending requests in a single queue, and ensuring that the system can respond to critical requests in a timely manner.

[0169] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system or other device. In addition, the embodiments of the present invention are not directed to any particular programming language.

[0170] In the description provided herein, a large number of specific details are described. However, it is understood that embodiments of the present invention can be practiced without these specific details. Similarly, in order to simplify the present invention and help understand one or more of the various inventive aspects, in the above description of exemplary embodiments of the present invention, the various features of the embodiments of the present invention are sometimes grouped together into a single embodiment, figure, or description thereof. Wherein, the claims that follow the specific embodiment are hereby expressly incorporated into the specific embodiment, wherein each claim itself is a separate embodiment of the present invention.

[0171] Those skilled in the art will appreciate that the modules in the devices in the embodiments may be adaptively changed and arranged in one or more devices different from the embodiments. The modules or units or components in the embodiments may be combined into one module or unit or component, and further may be divided into a plurality of submodules or subunits or subcomponents. Except that at least some of such features and / or processes or units are mutually exclusive.

[0172] It should be noted that the above embodiments illustrate the present invention rather than limit it, and that those skilled in the art may devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference symbol between brackets shall not be construed as a limitation on the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "one" or "an" preceding an element does not exclude the presence of a plurality of such elements. The present invention may be implemented by means of hardware comprising a number of different elements and by means of a suitably programmed computer. In a unit claim enumerating a number of devices, several of these devices may be embodied by the same hardware item. The use of the words first, second, and third, etc. does not indicate any order. These words may be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be understood as limitations on the order of execution.

Claims

1. A method for inter-core communication, characterized in that: The method comprises: The first core stores the pending requests in a first queue and a second queue, wherein the pending requests stored in the first queue have a higher real-time performance than those in the second queue, and the queue priority of the first queue is higher than that of the second queue; Sending the pending requests stored in the first queue and the second queue to the shared memory in sequence according to the queue priority from high to low through the first core; The pending request is obtained from the shared memory through the second core.

2. The method according to claim 1, characterized in that The sending, by the first core, the pending requests stored in the first queue and the second queue to the shared memory in order of queue priority from high to low, includes: The first core sequentially performs packet grouping processing on the pending requests stored in the first queue and the second queue in the order of queue priority from high to low and request priority from high to low, to obtain a plurality of request packets; wherein the pending requests stored in each queue are pre-configured with a request priority; The first core sends the multiple request packets to the shared memory in sequence according to the order of packet assembly time from first to last.

3. The method according to claim 2, characterized in that The first core sequentially performs packet processing on the pending requests stored in the first queue and the second queue in the order of queue priority from high to low and request priority from high to low to obtain multiple request packets, including: The first core sequentially obtains the pending requests stored in the first queue in descending order of request priority, until the number of pending requests obtained reaches a preset number of requests, or all pending requests stored in the first queue are obtained; If all pending requests stored in the first queue are obtained, and the request amount of the pending requests obtained does not reach the preset request amount, the pending requests stored in the second queue are obtained in sequence by the first core in order of request priority from high to low, until the total request amount of the pending requests obtained reaches the preset request amount, or all pending requests stored in the second queue are obtained; The first core performs packet processing on the acquired requests to be processed to generate a request packet.

4. The method according to claim 3, characterized in that: The obtaining, by the first core, the pending requests stored in the second queue in descending order of request priority, includes: The first core sorts the pending requests stored in the second queue according to the request priority and the residence time to generate a pending request sequence; wherein the pending request with a higher request priority or a longer residence time is located at an earlier position in the pending request sequence; Obtaining, through the first core, pending requests in the pending request sequence according to the order of the pending request sequence from front to back.

5. The method according to any one of claims 2 to 4, characterized in that: The shared memory is pre-divided into a plurality of storage spaces, a target storage space among the plurality of storage spaces is used to store the pending requests sent by the first core to the second core, and the first core sequentially sends the plurality of request packets to the shared memory in a sequence of packet assembly times from first to last, including: The first core sends the multiple request packets to the target storage space in sequence according to the order of packet assembly time from earliest to latest.

6. The method according to claim 5, characterized in that The obtaining the pending request from the shared memory through the second core includes: Sending an interrupt signal to the second core, wherein the interrupt signal is used to notify the second core that a request packet is stored in the target storage space; The request packet is obtained from the target storage space through the second core according to the interrupt signal.

7. The method according to any one of claims 1 to 4, characterized in that: The pending requests stored in the first queue are requests related to the driver layer, and the pending requests stored in the second queue are requests related to the application layer; The first core belongs to a system-on-chip (SoC) in a vehicle, and the second core belongs to a microcontroller unit (MCU) in the vehicle.

8. An inter-core communication device, characterized in that: The device comprises: A storage module, used for storing the pending requests into a first queue and a second queue through the first core, wherein the pending requests stored in the first queue have higher real-time performance than those stored in the second queue, and the queue priority of the first queue is higher than that of the second queue; A sending module, configured to send the pending requests stored in the first queue and the second queue to the shared memory in sequence according to the queue priority from high to low through the first core; An acquisition module is used to acquire the pending request from the shared memory through the second core.

9. A vehicle, characterized in that: include: A vehicle body and a vehicle controller; Wherein, the vehicle controller includes a processor, a memory, a communication interface and a communication bus, and the processor, the memory and the communication interface communicate with each other through the communication bus; The memory is used to store at least one executable instruction, and the executable instruction enables the processor to perform the operation of the inter-core communication method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that: The storage medium stores at least one executable instruction, and when the executable instruction is executed on the inter-core communication device / vehicle, the inter-core communication device / vehicle executes the operation of the inter-core communication method as described in any one of claims 1-7.

Images