A method and system for processing CAN messages

Abstract

A CAN message processing method and system, comprising receiving message data on a CAN bus; determining a priority category corresponding to the message data according to a preset mapping relationship; if the priority category belongs to a first category with higher real-time requirement, instantaneously analyzing and outputting the message data in an interrupt service routine; if the priority category belongs to a second category with lower real-time requirement, storing the message data in a buffer in the interrupt service routine, and analyzing the message data by a non-interrupt context task when a preset trigger condition is met. The application uses the resource allocation of interrupts and task contexts based on the differentiated processing strategy of priority classification, ensures the high real-time response of safety critical messages, reduces CPU occupation, and solves the balance problem between real-time and stability of a low-computing-power platform under high bus load.

Description

Technical Field

[0001] This application relates to the field of automotive electronic control, specifically to a CAN message processing method and system. Background Technology

[0002] With the increasing level of automotive electronics, especially the evolution of new energy vehicle architectures, the number of in-vehicle electronic control units (ECUs) has increased significantly, leading to a growing load on CAN bus communication. In embedded applications such as automotive instrument clusters, due to hardware limitations, microcontrollers (MCUs) with limited computing power are typically used as the processing core. However, how to efficiently process high-frequency CAN messages with limited CPU resources while ensuring the smooth operation of other tasks such as interface rendering has become an urgent technical problem to be solved.

[0003] Currently, the most common CAN message processing strategies in the industry include interrupt-driven and periodic polling methods.

[0004] Interrupt-driven methods involve triggering an interrupt upon receiving a message by the CAN controller, and then directly completing message reading, signal parsing, and subsequent service responses within the interrupt service routine (ISR). The advantages of this approach are rapid response, short data flow paths, and no need for additional buffer space. However, when the bus load is high or the message frequency is high, the frequency of interrupt triggering increases dramatically, causing the CPU to remain in interrupt context for extended periods, making it unable to respond to other low-priority tasks in a timely manner, and in severe cases, even causing the watchdog timeout reset. Furthermore, placing complex business logic in interrupt context violates the principles of layered software design and increases the difficulty of system maintenance.

[0005] Another common periodic polling method decouples message reception and processing. The interrupt is only responsible for storing the message in the buffer, and a background timer task periodically reads the buffer and parses it. This method avoids the problem of excessive interrupt nesting and has better system stability. However, setting the polling period often faces a dilemma: if the polling period is shortened to improve real-time performance, the CPU will consume a lot of resources on idle queries with no data changes, resulting in wasted computing power; if the polling period is lengthened to reduce load, it will lead to increased response delays for critical signals, making it difficult to meet the real-time requirements of instrument display or safety control.

[0006] More importantly, the messages on the in-vehicle CAN bus exhibit significant heterogeneity: they include both safety-critical messages that are extremely sensitive to real-time performance (such as vehicle speed and fault alarms) and ordinary status messages that are not sensitive to latency (such as mileage and maintenance information). Conventional technical solutions often employ a uniform interrupt or polling strategy for all messages, failing to allocate computing resources reasonably according to the service attributes of the messages. This results in critical messages being unable to respond in a timely manner during peak bus load periods because the CPU is occupied by processing a large number of ordinary messages, or non-critical messages consuming too many interrupt resources, leading to unreasonable overall system resource scheduling.

[0007] Given the shortcomings of the existing technology, there is an urgent need for an improved CAN message processing method to achieve a balance between high real-time response of critical messages and low overall system load on low computing power platforms, thereby improving the operational stability and resource utilization of the vehicle instrument system. Summary of the Invention

[0008] This application provides a CAN message processing method and system, which can solve the technical problem in the prior art that low computing power platforms have difficulty balancing the real-time performance of critical messages and the system CPU utilization rate under high bus load.

[0009] In a first aspect, embodiments of this application provide a CAN message processing method, comprising: receiving message data on a CAN bus; determining a priority category corresponding to the message data according to a preset mapping relationship; the priority category includes at least a first category with high real-time requirements and a second category with low real-time requirements; if the priority category belongs to the first category, the message data is parsed and output in real time in an interrupt service routine; if the priority category belongs to the second category, the message data is stored in a buffer in the interrupt service routine and parsed by a non-interrupt context task when a preset trigger condition is met.

[0010] In conjunction with the first aspect, in one implementation, the priority categories include immediate processing level, important processing level, normal processing level, and delayed processing level; the immediate processing level corresponds to the first category, and the other levels correspond to the second category. In conjunction with the first aspect, in another implementation, for important processing level message data, satisfying the preset triggering condition includes: detecting whether the status information meets the status change event; if it does, parsing is triggered immediately; if not, a periodic check counter is incremented, and parsing is triggered when the counter reaches a preset threshold; wherein, the status change event includes a change in signal value, a change in signal value exceeding the preset threshold, or the first reception of a message after recovery from a timeout state. In conjunction with the first aspect, in another implementation, for normal processing level message data, satisfying the preset triggering condition includes: parsing important processing level messages together within the same task cycle when parsing is triggered, or synchronously triggering parsing when the periodic check counter reaches the preset threshold. In conjunction with the first aspect, in another implementation, for delayed processing level message data, satisfying the preset triggering condition includes: triggering parsing when receiving an interface switching request or data query request from an upper-layer application.

[0011] Secondly, embodiments of this application provide a CAN message processing system, including: a memory for storing a computer program; and a processor for executing the computer program to implement the CAN message processing method as described in the first aspect.

[0012] Thirdly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the CAN message processing method as described in the first aspect.

[0013] The beneficial effects of the technical solution provided in this application include: by adopting a differentiated processing strategy based on priority categories (i.e., the first category is parsed immediately in the interrupt service routine, and the second category is stored in the interrupt and parsed by a non-interrupt context task), the technical problems in related technologies, such as high CPU usage under high load due to uniform interrupt processing or delayed response of critical messages due to uniform polling processing, are solved. Specifically, for the first category of messages with high real-time requirements, the high priority characteristics of the interrupt service routine are used to ensure low-latency response of safety-critical signals; for the second category of messages with low real-time requirements, batch or triggered parsing is performed using a non-interrupt context task, avoiding the overhead caused by frequent interrupt context switching. At the same time, the dual triggering mechanism of change detection and counter eliminates the repeated parsing of invalid data, significantly reducing the overall CPU load of the system and achieving a balance between real-time performance and stability of bus communication on low-computing-power platforms. Attached Figure Description

[0014] Figure 1This is a flowchart illustrating an embodiment of the CAN message processing method of this application; Figure 2 This is a schematic diagram of the interrupt service routine processing flow provided in the embodiments of this application; Figure 3 This is a schematic diagram of the non-interrupted context task cycle triggering process provided in the embodiments of this application. Detailed Implementation

[0015] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0016] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0017] Firstly, embodiments of this application provide a CAN message processing method.

[0018] In one embodiment, reference is made to Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the CAN message processing method of this application. Figure 1 As shown, the CAN message processing method includes: Step S1: Receive message data from the CAN bus.

[0019] As an example, the automotive instrument cluster controller listens to the CAN bus via a CAN controller. When a message is transmitted on the CAN bus, the CAN controller receives the message and stores it in the hardware receive register. The message data includes a CAN identifier (CANID), a data length code (DLC), and a data segment (Payload), where the data segment is typically 8 bytes.

[0020] Step S2: Determine the priority category corresponding to the message data according to the preset mapping relationship. The priority categories include at least the first category with high real-time requirements and the second category with low real-time requirements.

[0021] As an example, the preset mapping relationship is stored in the MCU's Flash or RAM, and can be implemented using data structures such as configuration tables, arrays, or hash maps. Taking the configuration table as an example, this configuration table is loaded during the system initialization phase, indexed by the CAN identifier, and each index entry contains the corresponding priority category information.

[0022] Specifically, upon arrival of message data, the CAN identifier of the message is extracted, and a preset mapping relationship is queried to determine whether the message data belongs to the first category or the second category. The first category is for messages with higher real-time requirements, while the second category is for messages with lower real-time requirements.

[0023] Step S3: If the priority category belongs to the first category, the message data is parsed and output in real time in the interrupt service routine.

[0024] As an example, when it is determined that the message data belongs to the first category, the following operations are performed directly within the CAN Receive Interrupt Service Routine (ISR): First, read the message data by reading the raw message data from the CAN controller hardware register.

[0025] Secondly, signal parsing is performed. Based on predefined signal parsing rules (such as Intel / Motorola format, start bit, bit length, scaling factor, offset, etc.), the original message data is converted into physical signal values ​​(such as vehicle speed = original value × 0.1 + 0).

[0026] Finally, external signals are sent. Specifically, the parsed signal values ​​are written to the global signal buffer or sent to the message queue for use by the instrument GUI rendering module or upper-level control logic.

[0027] In this step, first-category messages are not queued in the intermediate buffer and are parsed and output directly in the interrupt context, ensuring that the end-to-end delay from receiving the system response from the message is minimized.

[0028] Step S4: If the priority category belongs to the second category, the message data is stored in the buffer in the interrupt service routine and parsed by the non-interrupt context task when the preset trigger condition is met.

[0029] As an example, when the message data is determined to belong to the second category, an interrupt-decoupled processing method is adopted.

[0030] The interrupt storage, which is included in the CAN receive interrupt service routine, simply copies the original message data to a software buffer (such as a circular buffer or a structured array) and updates the timestamp and status flags of the message, without performing signal parsing.

[0031] Non-interrupt context task resolution involves an interrupt-independent background task (such as a periodic task or event-triggered task in an RTOS) reading message data from the buffer and performing signal resolution when preset trigger conditions are met.

[0032] Preset trigger conditions include, but are not limited to, changes in message data content, changes exceeding preset thresholds, expiration of periodic timers, or queries initiated by upper-layer applications.

[0033] In this embodiment, the buffer allocates an independent storage unit for each second category message. Each storage unit contains the following fields: CAN identifier, priority category, previous cycle signal value, current signal value, change trigger flag, cycle check counter, timeout counter, etc.

[0034] In summary, by employing a differentiated processing strategy based on priority categories (i.e., parsing the first category in real-time within the interrupt service routine, and storing the second category in the interrupt and triggering parsing by a background task), the technical problems of excessive CPU usage under high load due to uniform interrupt processing, or delayed response to critical messages due to uniform polling processing, in related technologies, are solved. Specifically, for the first category of messages with high real-time requirements, the high priority of the interrupt service routine ensures low-latency response to safety-critical signals. For the second category of messages with lower real-time requirements, batch or triggered parsing is performed using background tasks, avoiding the overhead of frequent interrupt context switching. Simultaneously, the dual triggering mechanism of change detection and counters eliminates the repeated parsing of invalid data, significantly reducing the overall CPU load of the system and achieving a balance between real-time performance and stability of bus communication on low-computing-power platforms. The change detection logic is not limited to numerical comparison but can also include variations such as checksum verification, signal validity bit detection, or determining invariance only after N consecutive frames are identical.

[0035] Reference Figure 2 , Figure 2 This is a schematic diagram of the Interrupt Service Routine (ISR) processing flow provided in the embodiments of this application.

[0036] like Figure 2 As shown, the interrupt service routine processing flow includes the following steps: Step S201: The device starts up and waits to receive data.

[0037] After system initialization is complete, it enters the main loop to wait and enables the CAN controller interrupt.

[0038] Step S202: The hardware receives the CAN message and triggers an interrupt.

[0039] When a message arrives on the CAN bus, the CAN controller hardware triggers a receive interrupt request.

[0040] Step S203: Determine whether the message data belongs to the first category (real-time processing level).

[0041] The system queries the priority category of the message based on the preset mapping relationship.

[0042] If it belongs to the first category, then proceed to step S204.

[0043] If it does not belong to the first category, proceed to step S205.

[0044] Step S204: Parse the message, send out signals, and end the interrupt.

[0045] For Category 1 messages, signal parsing is performed directly within the interrupt service routine, and the parsed signal value is sent to the global signal area or message queue before exiting the interrupt service routine.

[0046] Step S205: Update stored data.

[0047] For messages that are not in Category 1, the original message data is stored in the software buffer and the relevant timestamp is updated within the interrupt service routine.

[0048] Step S206: Determine whether the message data belongs to the important processing level.

[0049] If it belongs to the important processing level, then proceed to step S207.

[0050] If it does not belong to the critical processing level (i.e., the normal processing level or the delayed processing level), then proceed to step S209.

[0051] Step S207: Check if the status has been updated.

[0052] Within the interrupt service routine, change detection calculations are performed based on the original message data (e.g., comparing the original data or calculating simplified physical values), and compared with the previous cycle's state information stored in the buffer. If the change condition is met, the change trigger flag is set. This change detection calculation aims to quickly generate the flag; complete signal parsing is still performed in a background task.

[0053] If the status is not updated (i.e. the value has not changed and has not exceeded the threshold), then proceed to step S209.

[0054] If the status is updated, proceed to step S208.

[0055] Step S208: Set the change trigger flag and end the interrupt.

[0056] If a status update is detected (including numerical changes, changes exceeding a threshold, or timeout recovery), the change trigger flag corresponding to the message is set, and then the interrupt service routine is exited.

[0057] Step S209: Interruption ends.

[0058] For messages processed at the normal or delayed processing level, or important processing level messages whose status has not been updated, the interrupt service routine will exit immediately after data storage is completed. Subsequent parsing and processing will be handled by a background task.

[0059] In this embodiment, the above-described interrupt handling process enables immediate response to high-priority messages during interruption and rapid storage and status marking of low-priority messages during interruption, thereby minimizing interruption time.

[0060] Furthermore, in one embodiment, priority categories are used to characterize the urgency of message processing. In this embodiment, priority categories include immediate processing level, important processing level, normal processing level, and delayed processing level. The immediate processing level corresponds to the first category mentioned above, while the important processing level, normal processing level, and delayed processing level correspond to the second category mentioned above. Priority categories can be stored using configuration tables, array indexes, or hash mappings, etc.

[0061] In this embodiment, the real-time processing level is typically used to carry messages directly related to driving safety, such as forward collision warnings, AEB status, or serious fault alarms. These messages have the highest security level and the most stringent real-time requirements. The critical processing level is typically used to carry messages that are refreshed frequently and directly affect the main interface display, such as vehicle speed and engine speed. The general processing level is used to carry routine information display messages, such as fuel level and coolant temperature. The delayed processing level is used to carry messages that are only displayed on specific sub-interfaces, such as tire temperature and maintenance reminders.

[0062] This four-level classification method allows the system to allocate processing resources more precisely. For example, the highest-security, real-time processing messages can be configured to have exclusive interrupt resources, while other levels of messages can share background task resources, thereby achieving optimal system performance with limited resources.

[0063] Furthermore, in one embodiment, for critical processing-level messages, the system checks whether the state information maintained in the buffer meets the requirements of a state change event during the interrupt service routine. The state information includes at least a change trigger flag and a periodic check counter.

[0064] If a state change event is detected, the system immediately triggers the parsing process and resets the periodic check counter. State change events include, but are not limited to: a change in the signal value corresponding to the message data, a signal value change exceeding a preset threshold, or the first reception of a message after recovering from a timeout state. For example, for vehicle speed signals, only changes exceeding 1 km / h are considered valid, thus avoiding frequent parsing due to signal jitter.

[0065] If no state change event is detected, the system increments the periodic check counter. When the periodic check counter reaches a preset threshold, the parsing process is triggered, and the periodic check counter is reset. This is a fallback mechanism to ensure that even if the signal remains unchanged for a long time, the system can still refresh the data periodically to prevent the display from freezing.

[0066] Through this dual mechanism of change-triggered and periodic fallback, this embodiment ensures both rapid response to dynamic signals and avoids invalid calculations of static signals, significantly reducing the load on background tasks.

[0067] Reference Figure 3 , Figure 3 This is a schematic diagram of the background task periodic triggering process provided in the embodiments of this application.

[0068] like Figure 3 As shown, the processing flow of background tasks (which can be periodically triggered by system timers) includes the following steps: Step S301: Background task starts, waiting to be triggered.

[0069] After system initialization, background tasks enter a waiting state and are woken up by a hardware timer or operating system scheduler at fixed intervals.

[0070] Step S302: Timer is triggered, and the task cycle begins.

[0071] When the preset task cycle is reached, the background task is activated and begins to execute the inspection process.

[0072] Step S303: Determine whether there is a change trigger flag for important processing level messages.

[0073] The task iterates through important processing-level messages in the buffer, checking if their change trigger flags are set. The background task only queries the status of the change trigger flags; it does not need to repeatedly compare and calculate the signal values. If the flag is set, parsing is performed. If it is not set, parsing is skipped. If a change trigger flag is set, proceed to step S304.

[0074] If it does not exist, proceed to step S305.

[0075] Step S304: Clear the change trigger flag and proceed to the parsing process.

[0076] For messages that detect a change trigger flag being set, clear the flag to prevent duplicate processing, and then proceed to step S306.

[0077] Step S305: Accumulate the period check counter and determine whether the threshold has been reached.

[0078] For messages for which no change trigger flag is detected, the periodic check counter is incremented. This counter serves as a fallback trigger mechanism, independent of the change status of critical messages, ensuring that the system can periodically enter the parsing process even without signal changes.

[0079] Determine whether the periodic check counter has reached the preset threshold.

[0080] If the threshold is reached, proceed to step S306.

[0081] If the threshold is not reached, proceed to step S307 and wait for the next timer to be triggered.

[0082] Step S306: Parse the non-delayed processing level message data, send out signals, and reset the counter.

[0083] A unified parsing process is executed to parse the message data that needs to be processed. Specifically, the parsing objects include important processing level messages and ordinary processing level messages (i.e., non-delayed processing level messages).

[0084] After parsing is completed, the parsed signal is sent to the display module or upper-layer application, and the period check counter is reset to the initial value (e.g., zero), and then step S307 is executed.

[0085] Step S307: Wait for the next timer to trigger.

[0086] Once this task cycle ends, the background task enters a dormant or waiting state until the next timer is triggered.

[0087] In this embodiment, the aforementioned background task processing flow enables immediate response to changes in critical processing-level messages and periodic fallback refresh of ordinary processing-level messages. Simultaneously, by parsing critical and ordinary messages within the same task cycle, the number of task wake-ups is reduced, further lowering system computing power consumption.

[0088] Furthermore, in one embodiment, the parsing triggering condition for ordinary processing-level messages reuses the triggering mechanism for important processing-level messages. Specifically, when important processing-level message data triggers the parsing process, the system will parse ordinary processing-level message data simultaneously within the same task cycle of the background task. Alternatively, when the periodic check counter reaches a preset threshold, the parsing of ordinary processing-level message data will be triggered synchronously.

[0089] This batch processing method reduces the number of times background tasks need to be woken up. The system does not need to maintain a complex triggering logic for ordinary messages, but instead processes them in sync with the pace of important messages, thereby simplifying the software architecture and improving cache hit rate.

[0090] Furthermore, in one embodiment, for delayed-processing level messages, the system only triggers parsing upon receiving an interface switching request or data query request from the upper-layer application. For example, when a user clicks the vehicle status button on the instrument panel to switch to the interface displaying tire temperature, the upper-layer application sends a query request. In response to this request, the system triggers the parsing and display of the delayed-processing level message all at once.

[0091] While these messages are received and stored when the user is not viewing the relevant interface, no parsing is performed. This on-demand processing strategy further conserves CPU resources, allowing the system to focus its limited computing power on more critical tasks.

[0092] Furthermore, in one embodiment, to support the aforementioned differentiated processing strategy, the system maintains independent receive buffers for each type of message. The state information maintained in memory for each message entry includes multiple fields, as shown in the table below: Table 1. Description of Buffer Status Information Fields

[0093] In this embodiment, by maintaining the aforementioned state information, the system can efficiently transfer data state between interrupt service routines and background tasks. For example, the interrupt service routine only needs to update the current signal value and change trigger flag, without executing complete parsing logic. The background task, on the other hand, determines whether to perform parsing by reading the change trigger flag and the periodic check counter.

[0094] The change trigger flag is set in the interrupt service routine based on the comparison between the current signal value and the signal value of the previous cycle. If the two are inconsistent, or the change exceeds a preset threshold, the flag is set.

[0095] The timeout counter is reset to the timeout threshold each time a valid packet is received, and it decrements over time in a background task. If it decrements to zero, the timeout protection process is triggered.

[0096] The parsing request flag is used to respond to on-demand parsing requests for delayed-processing level messages. When an upper-layer application (such as a GUI module) initiates a UI switch or data query, this flag is set to notify the background task to perform parsing.

[0097] This embodiment provides a reliable data foundation for differentiated processing strategies through a comprehensive status information data structure, ensuring data consistency between interrupts and tasks and the correctness of processing logic.

[0098] Furthermore, in one embodiment, the system checks a timeout counter in a background task. If the timeout counter reaches zero, it determines that the message data communication has timed out and generates a timeout alarm signal output. For example, the instrument panel can display a communication failure icon to remind the driver.

[0099] If data is received again after the timeout determination, it is determined to be a timeout recovery, and the change trigger flag is set. This will immediately trigger the parsing process to ensure that the data displayed after the timeout recovery is up-to-date, avoiding misleading results caused by displaying expired data.

[0100] Furthermore, in one embodiment, before receiving message data on the CAN bus, the system performs initialization steps. These include loading a configuration file, establishing a mapping between CAN identifiers and priority categories, allocating an independent buffer for each message, and initializing the processing parameters for each message, including setting the timeout counter to an initial threshold and resetting the periodic check counter.

[0101] By adopting a unified initialization process, the consistency of the state of each module when the system starts is ensured, and occasional failures caused by uninitialized variables are avoided.

[0102] The following section will further illustrate the processing method of the present invention using a specific application scenario of an automotive instrument controller.

[0103] In one embodiment, the automotive instrument cluster controller communicates with the vehicle controller, powertrain controller, battery management system, ADAS controller, and body controller via a CAN bus. During system initialization, received CAN messages are pre-classified into four categories based on their functional attributes: immediate processing level, important processing level, normal processing level, and delayed processing level, and a mapping table between CAN identifiers and priority categories is established.

[0104] Specifically, examples of message classification at each level are as follows: Real-time processing level: Messages directly related to driving safety, such as forward collision warning, AEB status, and serious fault alarms. These messages have the highest real-time requirements and cannot tolerate significant delays or loss.

[0105] Critical processing level: Messages that are frequently refreshed and directly affect the main interface display, such as vehicle speed, engine speed, turn signal status, braking status, and general fault indicators. These messages have high real-time requirements, and usually only the latest status needs to be monitored.

[0106] Standard processing level: Regular information display messages, such as fuel level, coolant temperature, and remaining driving range. These messages generally do not have real-time requirements, and the data update cycle is relatively long.

[0107] Delayed processing level: Messages displayed only in specific sub-interfaces, such as tire temperature, rear axle load, maintenance reminders, historical statistics, etc. These messages have the lowest real-time requirements, with slow data updates and relatively low importance.

[0108] During operation, the processing flow for messages at each level is as follows: When a real-time processing message arrives, the CAN receive interrupt service routine directly receives, parses, and transmits the message to ensure that alarms and critical status information can be displayed on the instrument in a timely manner or trigger subsequent linkage actions. During this process, the message data is processed directly in the interrupt context without additional buffering.

[0109] When a critical processing-level message arrives, the interrupt service routine first compares the current signal value with the signal value of the previous valid cycle. If a change in value is detected, the change exceeds a preset threshold, or the message is in the first frame state after timeout recovery, the change trigger flag is immediately set, and subsequent parsing and business logic are completed by a background task after the interrupt exits. If the content of the critical processing-level message has not changed substantially, only the cache and timeout count information are updated, and the parsing process is not repeated.

[0110] For ordinary processing-level messages, the interrupt service routine is only responsible for caching the raw data. The system schedules parsing tasks uniformly according to a fixed period to perform batch parsing and status updates for this type of message. Specifically, ordinary processing-level messages reuse the triggering mechanism of important processing-level messages. When an important processing-level message triggers parsing, or when the period counter reaches a threshold, parsing is performed together.

[0111] For delayed processing messages, the interrupt service routine is only responsible for caching the raw data. The cached data is only parsed and displayed when the user switches to the corresponding display interface, or when the upper-layer application explicitly initiates a read request. While the user is not viewing the relevant interface, such messages do not consume additional parsing computational power.

[0112] In this embodiment, the following technical effects are achieved through the above-described hierarchical processing method: The response latency for safety-related messages (real-time processing level) is controlled at the millisecond or even microsecond level to ensure driving safety; Significantly reduces the interrupt handling time occupied by low-priority messages, and significantly reduces interrupt load; On low-computing-power platforms (such as MCUs with a main frequency of 150-300MHz), a better balance between real-time performance and CPU resource consumption can be achieved. Improve the operational stability of automotive instrument systems under high bus load conditions and avoid system lag or reset caused by CAN message storms.

[0113] Compared with traditional solutions that parse everything during interruptions or use fixed-period polling, this embodiment can maximize system resource utilization while ensuring the real-time performance of critical services.

[0114] Secondly, embodiments of this application also provide a CAN message processing system, the system including a memory and a processor, the memory for storing a computer program, and the processor for executing the computer program to implement the CAN message processing method.

[0115] The functions of each module in the CAN message processing device correspond to the steps in the CAN message processing method embodiment, and their functions and implementation processes will not be described in detail here.

[0116] Thirdly, embodiments of this application also provide a computer-readable storage medium.

[0117] The present application has a computer-readable storage medium storing a CAN message processing program, wherein when the CAN message processing program is executed by a processor, it implements the steps of the CAN message processing method described above.

[0118] The method implemented when the CAN message processing program is executed can be referred to in various embodiments of the CAN message processing method of this application, and will not be repeated here.

[0119] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0120] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0121] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0122] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0123] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0124] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0125] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A CAN message processing method, characterized in that, The method includes: Receive message data from the CAN bus; The priority category corresponding to the message data is determined according to the preset mapping relationship; The priority categories include at least a first category with high real-time requirements and a second category with low real-time requirements; For the first category, the message data is parsed and processed in real time within the interrupt service routine; For the second category, the message data is stored in a buffer in the interrupt service routine and parsed by a non-interrupt context task when a preset trigger condition is met.

2. The CAN message processing method as described in claim 1, characterized in that, The priority categories include immediate processing, important processing, normal processing, and delayed processing. The instant processing level corresponds to the first category; The critical processing level, the normal processing level, and the delayed processing level correspond to the second category; The security level of the message data corresponding to the instant processing level is higher than the security level of the message data corresponding to other priority categories in the second category.

3. The CAN message processing method as described in claim 2, characterized in that, For critical processing level message data belonging to the second category, the preset triggering conditions include: Detect whether the state information maintained in the buffer satisfies a state change event; The status information includes at least a change trigger flag and the periodic check counter; If the state change event is detected, the parsing process is immediately triggered, and the periodic check counter is reset; If no state change event is detected, the periodic check counter is incremented. When the periodic check counter reaches a preset threshold, the parsing process is triggered and the periodic check counter is reset. The state change event includes at least one of the following: the signal value corresponding to the message data changes, the amount of change in the signal value corresponding to the message data exceeds a preset threshold, or the message data is received for the first time after recovering from the timeout state.

4. The CAN message processing method as described in claim 3, characterized in that, For ordinary processing-level message data belonging to the second category, the preset triggering conditions include: When the message data of the critical processing level triggers the parsing process, the message data of the ordinary processing level is parsed together within the same task cycle of the non-interruptible context task; or, When the periodic check counter reaches the preset threshold, the parsing of message data at the normal processing level is triggered synchronously.

5. The CAN message processing method as described in claim 2, characterized in that, For delayed processing level message data belonging to the second category, the preset triggering conditions include: Receives a UI switching request or data query request from the upper-layer application; In response to the request, message data parsing at the delayed processing level is triggered.

6. The CAN message processing method as described in claim 3, characterized in that, The status information also includes: CAN identifier, priority category, previous cycle signal value, current signal value, timeout counter, timeout determination threshold, cycle check trigger threshold, and parsing request flag; The change trigger flag is set in the interrupt service routine based on the comparison result between the current signal value and the signal value of the previous cycle; The timeout counter is reset each time the message data is received, and is decremented in the non-interrupt context task; The parsing request flag is used to respond to parsing requests initiated by upper-layer applications.

7. The CAN message processing method as described in claim 6, characterized in that, It also includes a timeout protection step: Check the timeout counter in the non-interrupt context task; If the timeout counter reaches zero, the message data communication is determined to have timed out, and a timeout alarm signal is generated and output. If the message data is received again after the timeout determination, it is determined to be a timeout recovery, and the change trigger flag is set.

8. The CAN message processing method as described in claim 1, characterized in that, Before receiving message data on the CAN bus, an initialization step is also included: Load the preset mapping relationship and establish the mapping relationship between CAN identifiers and priority categories; Allocate independent buffers for each type of message data; Initialize the processing parameters for each of the aforementioned message data, including the timeout counter and the periodic check counter.

9. A CAN message processing system, characterized in that, The system includes: Memory, used to store computer programs; A processor for executing the computer program to implement the CAN message processing method as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the CAN message processing method as described in any one of claims 1 to 8.

Images