Communication method, medium, chip, and vehicle

Abstract

The present disclosure relates to a communication method, medium, chip and vehicle, comprising: determining packet task information of a processor, wherein the processor comprises a plurality of cores, and the packet task information comprises packet tasks corresponding to different cores; and processing the packet tasks by the cores corresponding to the packet tasks, wherein the packet tasks comprise receiving and / or sending packets through a communication bus, thereby effectively reducing the load rate of the processor and improving the resource utilization rate of the communication bus, and further effectively improving the communication efficiency and stability based on the communication bus.

Description

Technical Field

[0001] This disclosure relates to the field of vehicle communication technology, specifically to a communication method, medium, chip, and vehicle. Background Technology

[0002] Currently, multi-core chips are widely used in electric vehicles, including chassis domain control systems, braking systems, and motor control systems. These chips often integrate multiple vehicle systems, so they need to be connected to multiple communication buses to achieve communication interaction.

[0003] In existing technologies, a single core in a chip is typically used to manage all messages on the communication bus. For example, a core may connect to two communication buses to manage messages. Since each communication bus needs to occupy the core when processing messages, one of the two communication buses will always be idle, which seriously affects communication efficiency. When there are a large number of messages to be processed, the chip's processor load rate is high, which can easily lead to communication failures such as message timeouts. Summary of the Invention

[0004] The purpose of this disclosure is to provide a communication method, medium, chip, and vehicle.

[0005] To achieve the above objectives, this disclosure provides a communication method, the method comprising:

[0006] Determine the message task information of the processor, wherein the processor includes multiple cores, and the message task information includes message tasks corresponding to different cores;

[0007] The message task is processed by the kernel corresponding to the message task, wherein the message task includes receiving and / or sending messages through the communication bus.

[0008] Optionally, the message task information further includes different communication buses corresponding to different kernels; the step of processing the message task through the kernel corresponding to the message task includes:

[0009] The message corresponding to the message task is received and / or sent through the target communication bus corresponding to the kernel.

[0010] Optionally, the message task includes a sending task, and the message task information further includes the task status corresponding to the sending task. Sending the message corresponding to the message task through the target communication bus corresponding to the kernel includes:

[0011] Based on the task status of the sending task, determine the task to be sent from the sending task;

[0012] The message corresponding to the task to be sent is loaded into the corresponding kernel's sending queue, so that the kernel can send the message in the sending queue through the corresponding target communication bus.

[0013] Optionally, the message task information further includes the task type corresponding to the message task, wherein the task type includes at least one of periodic tasks, event tasks, and periodic event tasks; wherein,

[0014] For the periodic tasks, the task status includes the task period, and the tasks to be sent include periodic tasks whose period counts satisfy the task period conditions.

[0015] For the event-type task, the task status includes an event flag bit, and the task to be sent includes event-type tasks with the event flag bit set to the target value;

[0016] For the periodic event-type task, the task status includes the task period and the event flag bit, and the task to be sent includes event-type tasks whose period count meets the task period condition and whose event flag bit is the target value.

[0017] Optionally, loading the message corresponding to the task to be sent into the corresponding kernel's transmission queue, so that the kernel sends the message in the transmission queue through the corresponding target communication bus, includes:

[0018] Each kernel loads the corresponding messages to be sent into its sending queue in ascending order of task cycle size;

[0019] Each kernel polls the packets in its transmission queue and sends each polled packet through the corresponding target communication bus. The kernel polls the packets in the transmission queue in the order they were loaded into the queue.

[0020] Optionally, the message task further includes a receiving task, which receives the message corresponding to the message task through a target communication bus corresponding to the kernel, including:

[0021] Acquire the message to be received transmitted by the target communication bus and add the message to be received to the message pool of the target communication bus;

[0022] Each kernel polls the message pool of the target communication bus corresponding to it to obtain the message transmitted by the target communication bus corresponding to that kernel from the message pool.

[0023] Optionally, the method further includes:

[0024] When the kernel polls the message pool and finds any message to be received, it verifies whether the message to be received belongs to the receiving task corresponding to the kernel.

[0025] If the message to be received belongs to the receiving task corresponding to the kernel, the message to be received is obtained, and the receiving task corresponding to the kernel is updated in the message task information.

[0026] Optionally, the method further includes:

[0027] The message task information records the timestamp and flag bits during the message task processing process;

[0028] The processing of the message task is diagnosed based on the timestamp and the flag bit.

[0029] Optionally, the message task information for determining the processor includes:

[0030] The message data structure of each communication bus connected to the processor is defined as a union data structure;

[0031] Based on the union data structure, the message task information of the processor is determined.

[0032] This disclosure also provides a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the methods provided in this disclosure.

[0033] This disclosure also provides a chip including a processor for performing the methods provided in this disclosure.

[0034] This disclosure also provides a vehicle that includes the chip provided in this disclosure.

[0035] By using the above technical solution, multiple kernels can process the sending and receiving of messages on different communication buses in parallel, which can effectively reduce the processor load and improve the resource utilization of the communication bus, thereby effectively improving the communication efficiency and stability based on the communication bus.

[0036] Other features and advantages of this disclosure will be described in detail in the following detailed description section. Attached Figure Description

[0037] The accompanying drawings are provided to further illustrate the present disclosure and form part of the specification. They are used together with the following detailed description to explain the present disclosure, but do not constitute a limitation thereof. In the drawings:

[0038] Figure 1 This is a flowchart of a communication method proposed in an exemplary embodiment of this disclosure.

[0039] Figure 2 This is a schematic diagram illustrating a queue management method for sending tasks according to an exemplary embodiment of this disclosure.

[0040] Figure 3 This is a flowchart illustrating a message transmission method according to an exemplary embodiment of this disclosure.

[0041] Figure 4 This is a flowchart illustrating a method for receiving messages according to an exemplary embodiment of this disclosure.

[0042] Figure 5 This is a block diagram of a communication device proposed in an exemplary embodiment of the present disclosure. Detailed Implementation

[0043] The specific embodiments of this disclosure will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustration and explanation only and are not intended to limit this disclosure.

[0044] Before introducing the communication methods, media, chips, and vehicles provided in this disclosure, the application scenarios of this disclosure will be introduced first.

[0045] With the development of multi-core technology, microcontrollers have gradually evolved from single-core to multi-core chips. For example, a chip with the Tricore architecture designed for embedded operating systems integrates a multi-in-one powertrain system that includes a motor control system, a braking system, and a vehicle controller. This powertrain system communicates with multiple ECUs (Electronic Control Units) through multiple communication buses. The chip includes multiple processors. When any processor runs a program segment, it copies the program segment from the PFLx (Program Flash Interface) to the processor's local PCACHE (Program Cache) via the XBAR0 single bus. Temporary variables are dynamically allocated during runtime and stored in the processor's local DCACHE (Data Cache). Therefore, any modification made by each processor to a program segment or temporary variable will not affect other processors running the same program segment.

[0046] In view of this, the present disclosure provides a communication method that can be applied to a multi-core chip in a vehicle. The chip includes at least one processor and a message management module for centrally managing the messages to be processed by all processors. Each processor in the chip can run the same set of code that implements the method of the present disclosure, thereby improving code portability and reducing code duplication, memory usage and processor load when using multi-core chips.

[0047] Figure 1 This is a flowchart illustrating a communication method provided in an exemplary embodiment. For example... Figure 1As shown, the method may include the following steps:

[0048] Step S11: Determine the processor's message task information.

[0049] The processor includes multiple cores, and the message task information includes message tasks corresponding to different cores.

[0050] In one implementation, whenever there are pending messages on the communication bus within the chip, the message management module will aggregate these pending messages into message task information in the form of message tasks. Based on at least one of the following: the number of pending messages on the communication bus, the processor load rate, the core load rate, and the real-time requirements of the pending messages, the message tasks will be evenly distributed to at least one core of at least one processor within the chip, so that the processor can process the message corresponding to that processor through the message task information.

[0051] The message task information is a data structure used to manage or schedule message tasks. It can be represented as a list, i.e., a message task list. This list includes message information, kernel information, and diagnostic information. Based on different message processing methods, the message task list can be further divided into a sending task list and a receiving task list. The message information includes the message index, message count, message data, and message ID (Identity Document). The processor uses this information to determine the message task that needs to be processed. The kernel information includes the kernel index, the index of the communication bus driver allocated by the kernel, and the interrupt disable / enable interface. The processor uses this information to determine the kernel and communication bus corresponding to the message task to be processed. The diagnostic information includes timeout diagnostic information, packet anomaly diagnostic information, and verification diagnostic information. The processor uses this information to diagnose faults in the message task.

[0052] It is worth noting that the processor can be a CPU (Central Processing Unit) with multiple cores, each of which corresponds to a core ID, such as Core0, Core1, Core2, ..., CoreN. In the examples below, the core ID is used to represent different cores.

[0053] For example, each message task in the message task list corresponds to at least one core. The processor can determine the message task corresponding to each core by polling the message task list. For example, the first processor (CPU0) includes a first core (Core0), a second core (Core1), and a third core (Core2). When the first processor (CPU0) polls the message task list, each core in CPU0 will poll the message task list. If a message task that the processor does not need to process is polled, it will not be processed by default and will continue to poll the next message task. If a message task corresponding to a core is polled, the corresponding core will be used as the running core to process the message task. For example, if the core corresponding to message task 1 is Core0, then when message task 1 is polled, Core0 will be used as the running core to process message task 1.

[0054] Step S12: Process the message task through the kernel corresponding to the message task.

[0055] The message task includes receiving and / or sending messages via a communication bus.

[0056] In one embodiment, the communication bus is a CAN (Controller Area Network) bus. The CAN bus communication also supports the CANFD (CAN with Flexible Data rate) protocol and the CANVT (Virtual CAN communication) protocol. In addition, the communication bus can also be a LIN (Local Interconnect Network) bus, a FlexRay bus, and a MOST (Media Oriented System Transport) bus.

[0057] In one implementation, the vehicle's chip, through a message management module, organizes and summarizes the message signals that need to be processed on the communication bus into a message task list based on the functional requirements of the vehicle's service layer software for multiple ECUs connected to the CAN bus. Each message task in the message task list includes the kernel ID, message task ID, task cycle, task signal, and the communication bus corresponding to the message task. Each kernel is pre-matched with at least one communication bus. Whenever there is a message task in the message task list, each kernel in each processor polls the receiving task list to determine the running kernel corresponding to each message task. Then, the running kernel processes the corresponding message task through the communication bus corresponding to the message task.

[0058] By using multiple kernels to process the sending and receiving of messages on different communication buses in parallel, the processor load can be effectively reduced, the resource utilization of the communication bus can be improved, and the communication efficiency and stability based on the communication bus can be effectively improved.

[0059] Optionally, the message task information further includes different communication buses corresponding to different kernels, and the step of processing the message task through the kernel corresponding to the message task includes:

[0060] The message corresponding to the message task is received and / or sent through the target communication bus corresponding to the kernel.

[0061] In one implementation, the kernel and the communication bus can be pre-matched. Once the kernel corresponding to the message task is determined, the kernel processes the message task through the target communication bus that matches it.

[0062] Taking the following receiving task list as an example, the second core (Core1) in CPU0 polls the sending task list. When the second core polls for message task 1, the core ID corresponding to message task 1 is Core0. In this case, the second core does not execute the message task by default and continues to execute the next message task. When the second core polls for message task 2, the core ID corresponding to message task 2 is Core1. Therefore, the second core is determined to be the running core of message task 2. Then, message task 2 is executed through the second core and the target communication bus CAN B corresponding to the second core, that is, the message corresponding to message task 2 is received.

[0063]

[0064] Optionally, the message task includes a sending task, and the message task information further includes the task status corresponding to the sending task. Sending the message corresponding to the message task through the target communication bus corresponding to the kernel includes:

[0065] First, based on the task status of the sending task, the task to be sent is determined from the sending tasks.

[0066] Then, the message corresponding to the task to be sent is loaded into the corresponding kernel's sending queue, so that the kernel can send the message in the sending queue through the corresponding target communication bus.

[0067] It is worth noting that the task status of the sending task can determine whether the sending task needs to be sent immediately. Tasks to be sent are message tasks that need to be sent immediately.

[0068] In one embodiment, the kernel polls the list of sending tasks. When it encounters a sending task that it is responsible for processing, it determines whether the sending task needs to be sent immediately based on the task status. If it does, it adds a queueable flag to the sending task; if it does not, it clears the queueable flag from the sending task. After the kernel has finished polling the list of sending tasks, it identifies the sending tasks with queueable flags corresponding to the kernel as tasks to be sent and loads the packets corresponding to the tasks to be sent into the kernel's sending queue.

[0069] Optionally, the message task information may also include the task type of the corresponding message task, wherein the task type includes at least one of periodic task, event task, and periodic event task.

[0070] For the periodic task, the task status includes the task period, and the task to be sent includes periodic tasks whose period count satisfies the task period condition.

[0071] Among them, periodic tasks are message tasks that need to perform sending operations according to a preset period. The period conditions include that the period value is not 0 and the count value of the period counter reaches the corresponding preset counting duration.

[0072] For the event-type task, the task status includes an event flag, and the task to be sent includes event-type tasks with the event flag set to a target value.

[0073] Among them, event-based tasks are message tasks that are triggered by preset triggering events or triggering conditions to send operations.

[0074] For the periodic event-type task, the task status includes the task period and the event flag bit, and the task to be sent includes event-type tasks whose period count meets the task period condition and whose event flag bit is the target value.

[0075] In one embodiment, see Figure 2 As shown, when the kernel polls the sending task queue and finds the corresponding sending task, it first needs to determine the task type of the sending task. If the task type is a periodic task, it checks whether the corresponding period value is 0. If the period value is 0, the message task is not a task to be sent, so the queueable flag in the message task is cleared. If the period value is not 0, it checks the count value of the period counter corresponding to the message task. The period counter is an internal timer used to track the time since the last sending of the message task. If the count value of the period counter reaches or exceeds the preset counting time corresponding to the message task, the queueable flag is added to the message task.

[0076] For event-based tasks, the processor's operating system monitors the triggering events or triggering conditions corresponding to each event-based task in the task list in real time. When the triggering event or triggering condition corresponding to the message task occurs, its corresponding event flag will be enabled, i.e., the event flag will be set to the target value. When the kernel polls for its corresponding event-based task, if the event flag of the message task is enabled, the kernel will add an enqueue flag to the event-based task. If it is not enabled, the enqueue flag in the event-based task will be cleared.

[0077] For periodic event tasks, it is first necessary to determine whether the event flag of the message task is enabled. If it is not enabled, the queueable flag in the message task is cleared. If it is enabled, the period counter corresponding to the message task is started. When the period value is not 0 and the count value of the period counter reaches or exceeds the preset count duration corresponding to the message task, the queueable flag is added to the message task, which is then determined to be a task to be sent.

[0078] Optionally, loading the message corresponding to the task to be sent into the corresponding kernel's transmission queue, so that the kernel sends the message in the transmission queue through the corresponding target communication bus, includes:

[0079] First, each kernel loads the corresponding messages to be sent into its sending queue in ascending order of task cycle size.

[0080] The period of a message task is used to characterize the processing priority of the message task; the smaller the period, the higher the priority.

[0081] Then, each kernel polls the packets in its transmission queue and sends each polled packet through the corresponding target communication bus. The kernel polls the packets in the transmission queue from first to last according to the order in which the packets were loaded into the transmission queue.

[0082] In one implementation, the kernel polls the task list to determine the tasks it is responsible for handling and that need to be sent immediately, and loads these tasks into the kernel's message sending queue in ascending order of task cycle size. Each kernel sends messages through its corresponding target communication bus in the order they are loaded into the message sending queue.

[0083] For example, see the schematic diagram of the transmission queues shown below, where the first transmission queue is the transmission queue of the first core (Core0), and the second transmission queue is the transmission queue of the third core (Core2). After the first core polls the message transmission list, it determines that message task 1 (TXTASK1) and message task 4 (TXTASK4) are messages to be processed by the first core and need to be sent immediately. Since the period of message task 1 is longer than that of message task 4, it means that the task priority of message task 4 is higher than that of message task 1. Therefore, the first core first loads message task 4, which has a higher task priority, into its corresponding first transmission queue, and then loads message task 1, which has a lower task priority, into the first transmission queue. Further, the first core polls the first transmission queue and sends the messages corresponding to the message tasks sequentially through the target communication bus CAN A corresponding to the first core according to the first-in-first-out principle. Similarly, after the third kernel polls the message sending list, it determines that message task 5 (TXTASK5) and message task 6 (TXTASK6) are messages to be sent that the third kernel is responsible for processing and that need to be sent immediately. Since the period of message task 6 is longer than that of message task 5, it means that the task priority of message task 5 is higher than that of message task 6. Therefore, the third kernel first loads message task 5, which has a higher task priority, into its corresponding second sending queue, and then loads message task 6, which has a lower task priority, into the second sending queue. Furthermore, the third kernel polls the second sending queue and sends the messages corresponding to the message tasks in sequence through the target communication bus CANFD C corresponding to the third kernel according to the first-in-first-out principle.

[0084]

[0085] In one embodiment, see Figure 3 As shown, for each core in the processor, the message to be sent can be processed in the following ways.

[0086] S301, Poll the task list.

[0087] S302. Determine the sending task corresponding to the kernel in the sending task list.

[0088] For example, each core in the processor polls the list of sending tasks and compares it with the kernel ID pre-bound to each sending task in the list to determine the sending task that the kernel needs to process. If the kernel does not find a matching sending task after polling the list of sending tasks, then step S305 is executed.

[0089] S303. Based on the task status of the sending task, add / remove the queueable flag for the sending task.

[0090] For example, when the kernel polls for a corresponding sending task, it adds or removes the queueable flag for that sending task based on the task status corresponding to the task type. After adding / removing the queueable flag, it continues to poll for the next sending task until the sending task list has been polled. The method for determining the task status of a sending task based on different task types has been explained above and will not be repeated here.

[0091] S304. Confirm whether the task list has been polled completely.

[0092] If polling is complete, execute S305; otherwise, return to execute S301.

[0093] S305. Determine whether there are any pending tasks with the queue flag enabled in the target communication bus corresponding to the running kernel.

[0094] If it exists, execute S306; if it does not exist, execute S309.

[0095] It is worth noting that the kernel corresponding to the sending task in the sending task list is the running kernel for these sending tasks. In other words, the running kernel is responsible for sending and managing these sending tasks.

[0096] S306. Based on the period size of the task to be sent, load the message corresponding to the task to be sent into the transmission queue of the target communication bus corresponding to the running kernel.

[0097] S307, Message Task Information Processing.

[0098] It is worth noting that after the message is sent, the running kernel will process the message task information corresponding to the sent message, such as updating the message status and releasing memory resources.

[0099] S308 polls the send queue of the target communication bus corresponding to the running kernel and sends the messages corresponding to the tasks to be sent in the order they are loaded into the send queue.

[0100] S309, Message Fault Management.

[0101] For example, after the message is sent, based on the flag bits and timestamps recorded during the message transmission process, real-time feedback is provided on message diagnostic information such as timeout detection, verification detection, and life frame detection.

[0102] Optionally, the message task further includes a receiving task, which receives the message corresponding to the message task through a target communication bus corresponding to the kernel, including:

[0103] Acquire the message to be received transmitted by the target communication bus and add the message to be received to the message pool of the target communication bus.

[0104] Each kernel polls the message pool of the target communication bus corresponding to it to obtain the message transmitted by the target communication bus corresponding to that kernel from the message pool.

[0105] It is worth noting that whenever there is a message to be received on the communication bus, the CPU triggers the ISR (Interrupt Service Routine) and polls and compares all message tasks in the receiving task list. This includes a large number of comparisons of receiving tasks not on the current communication bus. Therefore, when there are many messages to be received on the communication bus, each communication bus will frequently trigger the ISR. The program performs tasks such as task polling and comparison, ID verification, data parsing, data verification, and time recording. The CPU has a large computational load and the running time is too long, which can easily affect the running cycle of other tasks. Furthermore, when the CPU load is high, basic diagnostic functions such as send / receive timeout diagnosis, data verification diagnosis, and message life frame verification cannot be used normally.

[0106] In view of this, for receiving tasks, the messages to be received in the communication bus can be stored in the message pool (FIFO pool) based on the FIFO (First In First Out) data structure, but no receiving processing is performed on the messages. Then, in the system's regular tasks or main loop, the kernel polls the message pool of the target communication bus corresponding to the kernel at a fixed period (e.g., 10ms) and performs receiving processing on the messages to be received in the message pool, so as to quickly release the interrupt service routine and avoid long interrupt processing hard-wired real-time performance.

[0107] Each receiving task corresponds to a different kernel, each kernel corresponds to a different target communication bus, and each target communication bus corresponds to a different message pool.

[0108] For example, taking the CAN bus as the communication bus, the following steps can be used to process the messages to be received on the communication bus.

[0109] The first step is for the processor to check the status register of the CAN controller to determine whether there is an interrupt flag in each CAN bus. If there is, it means that the interrupt service routine has been triggered on that CAN bus. If there is no interrupt flag, it means that the interrupt service routine has not been triggered on that CAN bus. The check continues.

[0110] The second step is to clear the interrupt flag corresponding to the CAN bus that triggered the interrupt in the interrupt service routine when a receive interrupt is detected, in order to avoid processing the same interrupt repeatedly.

[0111] The third step is to read the message from the CAN bus in the receive buffer of the CAN controller. The message read includes the message ID, message data field and other message information. At the same time as the message is obtained, the current system time is obtained as a timestamp to provide a basis for subsequent management and data diagnosis of the message.

[0112] The fourth step is to package the acquired message and system time into the tail of the FIFO pool corresponding to the CAN bus. The FIFO pool is used to temporarily store the received messages until the processor's main program or task scheduler processes them.

[0113] It is worth noting that, due to the characteristics of the FIFO data structure, the first message received will be retrieved and processed first.

[0114] The above method can quickly release interrupts and avoid the impact of prolonged interrupt handling on the real-time performance of the system.

[0115] In one embodiment, participants Figure 4 As shown, the packets in the packet pool can be processed through the following steps.

[0116] S401. Poll the list of receiving tasks to determine the running kernel corresponding to each receiving task.

[0117] It is worth noting that whenever there is a message to be received on the communication bus, the message management module will summarize and organize the receiving tasks corresponding to the messages to be received into a receiving task list.

[0118] For example, each core of the processor polls the list of receiving tasks. Taking the first core (Core0) as an example, if there is a receiving task corresponding to Core0 in the receiving task list, then Core0 becomes the core that runs these receiving tasks. Subsequently, these receiving tasks are processed by Core0. After Core0 finishes polling the receiving task list, it generates a receiving queue for Core0 based on the receiving priority of all receiving tasks handled by Core0. The receiving priority of a receiving task is determined by the period size of the receiving task; the smaller the period, the higher the priority.

[0119] S402. By running the kernel, poll the message pool of the target communication bus corresponding to its receive queue. If a new message is stored in the message pool, retrieve the message header from the message pool.

[0120] It is worth noting that each communication bus corresponds to a message pool in advance, and each kernel corresponds to at least one communication bus.

[0121] For example, during the polling of the message pool, the kernel checks whether there are any pending messages in the message pool. If the message pool is not empty, the message header is retrieved. For example, if the target communication bus corresponding to Core0 is CAN A, Core0 polls the first message pool corresponding to CAN A. If there are newly added messages in the first message pool, the header of these newly added messages is retrieved.

[0122] S403. Perform data verification on the retrieved message and process the retrieved message based on the data verification result.

[0123] Among them, the message to be received is the message whose data verification process has passed.

[0124] S404. Determine whether all newly added packets in the packet pool have been rounded up.

[0125] If the rounding process is complete, execute S405; otherwise, execute S406.

[0126] S405. Determine whether the receiving tasks in the receiving task list have been processed.

[0127] If the processing is complete, proceed to step S406; otherwise, return to step S401.

[0128] S406. Determine the fault diagnosis result of the receiving task based on the flag bits and timestamps recorded during the receiving task's processing.

[0129] The above methods can ensure that messages on the communication bus are effectively managed and processed, avoid the impact of frequent interrupts triggered by the receiving task on the running cycle of other tasks of the processor, effectively reduce the processor load, and ensure the stability of fault diagnosis of message tasks.

[0130] Optionally, the method further includes:

[0131] When the kernel polls the message pool and finds any message to be received, it verifies whether the message to be received belongs to the receiving task corresponding to the kernel.

[0132] If the message to be received belongs to the receiving task corresponding to the kernel, the message to be received is obtained, and the receiving task corresponding to the kernel is updated in the message task information.

[0133] For example, for packets being retrieved from the packet pool in a round-robin fashion, step S403 above can be implemented through the following sub-steps.

[0134] The first step is to poll the receive queue of the communication bus corresponding to the message pool and compare the message ID of the retrieved message with the receive task in the receive queue one by one.

[0135] The following diagram illustrates the receiving queue. The first receiving queue is the receiving queue of the first core (Core0). The target communication bus corresponding to Core0 is CAN B. When a message is retrieved from the message pool corresponding to CAN B, Core0 compares and verifies the retrieved message with the message tasks in the first receiving queue one by one. That is, it determines whether there is a message task in the task signal shown in the diagram that matches the message ID of the message, so as to determine whether the retrieved message is correct.

[0136] If the comparison passes, proceed to the next step; if the comparison fails, put the message back into the message pool and proceed to the fourth step.

[0137]

[0138] The second step is to verify the data of the message task information of the received task and determine the verification result.

[0139] The data verification of the message can be done using CRC (Cyclic Redundancy Check) to ensure the integrity and correctness of the message.

[0140] If the verification result passes, then the third and fourth steps are executed sequentially. If the verification result fails, then the message will be processed according to the processing policy corresponding to the verification result and the fourth step will be executed. The processing policy corresponding to the verification result includes at least one of the following: putting the message back into the message pool, discarding the message, recording the error, or sending an error report.

[0141] The third step is to update the message task information corresponding to the message task and record the update time of the message task information.

[0142] The fourth step is to determine whether the transmission queue of the communication bus corresponding to the message pool has been polled.

[0143] If the polling is complete, the data verification process ends, and messages that pass the data verification process are identified as messages to be received. If the polling is not complete, the process returns to the first step.

[0144] Optionally, the method further includes:

[0145] The message task information records the timestamp and flag bit during the message task processing.

[0146] The processing of the message task is diagnosed based on the timestamp and the flag bit.

[0147] In one implementation, based on the flag bits recorded during the message task processing, it can be determined whether there is data abnormality or error. Based on the timestamps recorded during the message task processing, it can be determined whether the message task is completed within the preset processing time, i.e. whether a communication timeout fault has occurred. If the fault diagnosis result indicates a transmission fault, a fault report is generated based on the relevant system information of the fault type, fault time, and fault impact, and the generated fault report is sent to the fault processing module of the processor.

[0148] Optionally, the message task information for determining the processor includes:

[0149] The message data structure of each communication bus connected to the processor is defined as a union data structure.

[0150] Based on the union data structure, the message task information of the processor is determined.

[0151] It's worth noting that the union data structure contains a char data type variable 'a', an int data type array variable 'i', and a double data type variable 'b'. During memory address allocation in the chip, the union structure members 'a', 'i', and 'b' share a memory space. The size of this memory space is equal to the longest of the members. When the union is allocated to a specific member, that member's value is stored in the shared memory space, and the values ​​of the other members are overwritten. In other words, the union data structure can only store the value of one member at a time.

[0152] By defining the message data structure of each communication bus using the union data structure, it is easy and intuitive to configure the data fields of each signal, such as the size and name of the bit field. This reduces the risk of data parsing errors or data address allocation errors caused by human operation. It can also improve the efficiency of separating high and low bytes, bitwise operations, bitwise OR operations, and shift operations in data processing, and can significantly reduce the amount of data computation on the CPU. At the same time, it can also avoid data anomalies caused by manual data manipulation.

[0153] In one embodiment, the message task list is a data structure for storing message task information. The message task list includes a union defined based on a union data structure and message-related metadata, such as message type, message priority, and timestamp. Whenever there is message data to be processed in the target communication bus corresponding to the processor, this message data is parsed and stored in the union. Then, based on the message data and metadata in the union, the task type, kernel, communication bus, and task cycle of each message to be processed are determined. The determined message task information is added to the message task list to generate corresponding send task lists and receive task lists, so that the processor can process the messages to be processed by polling the send task lists or receive task lists.

[0154] For example, the "CAN Service Protocol Stack Generation Tool" can quickly and efficiently generate all message data fields for multiple CAN buses in batches. It can also verify the memory size of the generated data fields to avoid issues such as the total data field size of standard CAN messages exceeding 8 bytes or the total data field size of CANFD messages exceeding 64 bytes. After generating the data structures defining the signals related to the CAN bus's receive and transmit messages, a message task list is generated according to information such as message type, period, message ID, bus to which the message belongs, and message signal data.

[0155] In addition, after generating the message task list, the message task list needs to be initialized in a series of steps as shown below.

[0156] For the sending task list, initialize the list data and flag bits of the sending task list, the period value and counter value of the message to be sent, the sending priority of the message to be sent, the kernel corresponding to the message to be sent, the communication bus, and the sending queue of the communication bus in sequence.

[0157] For the receiving task list, the list data of the receiving task list, the message signal of the message to be received, the priority of the message to be received, the kernel corresponding to the message to be received, and the communication bus are initialized in sequence. Based on the priority of the message to be received and the communication bus to which it belongs, the receiving queue and message pool corresponding to each communication bus are initialized.

[0158] See Figure 5 As shown, this disclosure also provides a communication device 500, which includes:

[0159] The determination module 510 is configured to determine the message task information of the processor, wherein the processor includes multiple cores and the message task information includes message tasks corresponding to different cores.

[0160] The processing module 520 is configured to process the message task through a kernel corresponding to the message task, wherein the message task includes receiving and / or sending messages through a communication bus.

[0161] Optionally, the message task information further includes different communication buses corresponding to different kernels, and the processing module 520 is configured as follows:

[0162] The message corresponding to the message task is received and / or sent through the target communication bus corresponding to the kernel.

[0163] Optionally, the message task includes a sending task, and the message task information further includes the task status corresponding to the sending task. The processing module 520 is configured to:

[0164] Based on the task status of the sending task, determine the task to be sent from the sending tasks.

[0165] The message corresponding to the task to be sent is loaded into the corresponding kernel's sending queue, so that the kernel can send the message in the sending queue through the corresponding target communication bus.

[0166] Optionally, the message task information may also include the task type of the corresponding message task, wherein the task type includes at least one of periodic task, event task, and periodic event task.

[0167] For the periodic task, the task status includes the task period, and the task to be sent includes periodic tasks whose period count satisfies the task period condition.

[0168] For the event-type task, the task status includes an event flag, and the task to be sent includes event-type tasks with the event flag set to a target value.

[0169] For the periodic event-type task, the task status includes the task period and the event flag bit, and the task to be sent includes event-type tasks whose period count meets the task period condition and whose event flag bit is the target value.

[0170] Optionally, the processing module 520 is configured to:

[0171] Each kernel loads the corresponding messages to be sent into its sending queue in ascending order of task cycle size.

[0172] Each kernel polls the packets in its transmission queue and sends each polled packet through the corresponding target communication bus. The kernel polls the packets in the transmission queue in the order they were loaded into the queue.

[0173] Optionally, the message task further includes a receiving task, and the processing module 520 is configured to:

[0174] Acquire the message to be received transmitted by the target communication bus and add the message to be received to the message pool of the target communication bus.

[0175] Each kernel polls the message pool of the target communication bus corresponding to it to obtain the message transmitted by the target communication bus corresponding to that kernel from the message pool.

[0176] Optionally, the processing module 520 is configured to:

[0177] When the kernel polls the message pool and finds any message to be received, it verifies whether the message to be received belongs to the receiving task corresponding to the kernel.

[0178] If the message to be received belongs to the receiving task corresponding to the kernel, the message to be received is obtained, and the receiving task corresponding to the kernel is updated in the message task information.

[0179] Optionally, the processing module 520 is configured to:

[0180] The message task information records the timestamp and flag bit during the message task processing.

[0181] The processing of the message task is diagnosed based on the timestamp and the flag bit.

[0182] Optionally, the determining module 510 is configured to:

[0183] The message data structure of each communication bus connected to the processor is defined as a union data structure.

[0184] Based on the union data structure, the message task information of the processor is determined.

[0185] This disclosure also provides a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the methods provided in this disclosure.

[0186] This disclosure also provides a chip including a processor for performing the methods provided in this disclosure.

[0187] This disclosure also provides a vehicle that includes the chip provided in this disclosure.

[0188] The preferred embodiments of this disclosure have been described in detail above with reference to the accompanying drawings. However, this disclosure is not limited to the specific details of the above embodiments. Within the scope of the technical concept of this disclosure, various simple modifications can be made to the technical solutions of this disclosure, and these simple modifications all fall within the protection scope of this disclosure.

[0189] It should also be noted that the various specific technical features described in the above specific embodiments can be combined in any suitable manner without contradiction. In order to avoid unnecessary repetition, this disclosure will not describe the various possible combinations separately.

[0190] Furthermore, various different embodiments of this disclosure can be combined in any way, as long as they do not violate the spirit of this disclosure, they should also be regarded as the content disclosed in this disclosure.

Claims

1. A communication method characterized by comprising: include: The message task information of the processor is determined, wherein the processor includes multiple cores, each core is identical, and each core is pre-matched with at least one communication bus; the message task information includes message tasks corresponding to different cores and different communication buses corresponding to different cores; The message task is processed by the kernel corresponding to the message task, wherein the message task includes receiving and / or sending messages through a communication bus, and the processing of the message task by the kernel corresponding to the message task includes receiving and / or sending messages corresponding to the message task through a target communication bus corresponding to the kernel; wherein the correspondence between the message task and the kernel is determined based on the number of messages to be processed in the communication bus, the processor load rate, the kernel load rate, and the real-time requirements of the messages to be processed; The message task includes a sending task, and the message task information also includes the task status corresponding to the sending task. Sending the message corresponding to the message task through the target communication bus corresponding to the kernel includes: the kernel determining the task to be sent from the sending tasks based on the task status of the sending task; loading the message corresponding to the task to be sent into the sending queue of the corresponding kernel, so that the kernel sends the message in the sending queue through the corresponding target communication bus. The message task also includes a receiving task, which receives the message corresponding to the message task through the target communication bus corresponding to the kernel, including: obtaining the message to be received transmitted by the target communication bus and adding the message to be received to the message pool of the target communication bus; each kernel polls the message pool of the target communication bus corresponding to it to obtain the message transmitted by the target communication bus corresponding to the kernel from the message pool.

2. The method according to claim 1, characterized in that, The message task information also includes the task type corresponding to the message task, and the task type includes at least one of periodic tasks, event tasks, and periodic event tasks; wherein... For the periodic tasks, the task status includes the task period, and the tasks to be sent include periodic tasks whose period counts satisfy the task period conditions. For the event-type task, the task status includes an event flag bit, and the task to be sent includes event-type tasks with the event flag bit set to the target value; For the periodic event-type task, the task status includes the task period and the event flag bit, and the task to be sent includes event-type tasks whose period count meets the task period condition and whose event flag bit is the target value.

3. The method according to claim 1, characterized in that, The step of loading the message corresponding to the task to be sent into the corresponding kernel's sending queue, so that the kernel can send the message in the sending queue through the corresponding target communication bus, includes: Each kernel loads the corresponding messages to be sent into its sending queue in ascending order of task cycle size; Each kernel polls the packets in its transmission queue and sends each polled packet through the corresponding target communication bus. The kernel polls the packets in the transmission queue in the order they were loaded into the queue.

4. The method according to claim 1, characterized in that, The method further includes: When the kernel polls the message pool and finds any message to be received, it verifies whether the message to be received belongs to the receiving task corresponding to the kernel. If the message to be received belongs to the receiving task corresponding to the kernel, the message to be received is obtained, and the receiving task corresponding to the kernel is updated in the message task information.

5. The method according to claim 1, characterized in that, The method further includes: The message task information records the timestamp and flag bits during the message task processing process; The processing of the message task is diagnosed based on the timestamp and the flag bit.

6. The method according to claim 1, characterized in that, The message task information for determining the processor includes: The message data structure of each communication bus connected to the processor is defined as a union data structure; Based on the union data structure, the message task information of the processor is determined.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the program implements the steps of the method described in any one of claims 1-6.

8. A chip, characterized in that, The chip includes a processor for performing the method according to any one of claims 1-6.

9. A vehicle, characterized in that, Includes the chip described in claim 8.

Images