An automatic CAN communication code configuration method and device, a storage medium and equipment

Abstract

This invention relates to an automated CAN communication code configuration method, apparatus, storage medium, and device. The method includes: acquiring and parsing a CAN network description file to extract the transmit / receive message configuration information of each controller node in the CAN network; based on the transmit / receive message configuration information, assigning each controller node to a corresponding hardware CAN controller, and assigning the messages to be transmitted and received by each node to different mailboxes of the hardware CAN controller to form a hardware resource allocation scheme; and automatically generating CAN communication configuration files for the microcontroller abstraction layer, basic software layer, and application software layer according to the hardware resource allocation scheme.

Description

Technical Field

[0001] This invention relates to the field of automotive electronic controller software development technology, and in particular to an automated CAN communication code configuration method, apparatus, storage medium and device. Background Technology

[0002] CAN (Controller Area Network) is an ISO internationally standardized serial communication protocol. Since its inception, it has been widely used in various vehicle controllers to enable information exchange between controllers and actuator control.

[0003] When using CAN communication, the interaction of the entire CAN network needs to be configured through configuration information at different levels. Specifically, this includes: configuring the baud rate, mailbox, and channels in the MCAL (Micro Controller Abstraction Layer); configuring CAN message routing in the BSW (Basic Software Layer); and configuring CAN message parsing in the ASW (Application Software Layer). The configuration content at these three levels must be strictly matched to ensure the normal operation of the entire controller's CAN communication; otherwise, anomalies such as frame loss and mistransmissions will occur.

[0004] In existing technical solutions, the configuration of each of the above layers needs to be performed separately using different software tools. The MCAL layer configuration requires the use of EB Tresos or dedicated configuration tools provided by chip manufacturers; the BSW layer configuration requires the use of the AUTOSAR (Automotive Open System Architecture) toolchain or manual modification of the project code; and the ASW layer configuration requires Simulink or manual modification of the project code. Because existing vehicle controllers have numerous functions, a single CAN bus often needs to send and receive a large number of messages, resulting in extremely complex CAN network configuration code. Relying entirely on manual configuration is highly prone to errors. Summary of the Invention

[0005] This invention discloses an automated CAN communication code configuration method, apparatus, storage medium, and device, aiming to solve the technical problems existing in the prior art.

[0006] The present invention adopts the following technical solution: On one hand, embodiments of the present invention provide an automated CAN communication code configuration method, including: Obtain and parse the CAN network description file to extract the transmit and receive message configuration information of each controller node in the CAN network; Based on the message transmission and reception configuration information, each controller node is assigned to the corresponding hardware CAN controller, and the messages to be transmitted and received by each node are assigned to different mailboxes of the hardware CAN controller, thus forming a hardware resource allocation scheme. Based on the hardware resource allocation scheme, CAN communication configuration files for the microcontroller abstraction layer, basic software layer, and application software layer are automatically generated.

[0007] Secondly, embodiments of the present invention provide an automated CAN communication code configuration device, comprising: The parsing module is used to obtain and parse the CAN network description file and extract the transmit and receive message configuration information of each controller node in the CAN network. The allocation module is used to allocate each controller node to the corresponding hardware CAN controller based on the message transmission and reception configuration information, and to allocate the messages to be transmitted and received by each node to different mailboxes of the hardware CAN controller, thus forming a hardware resource allocation scheme. The generation module is used to automatically generate CAN communication configuration files for the microcontroller abstraction layer, basic software layer, and application software layer based on the hardware resource allocation scheme.

[0008] Thirdly, embodiments of the present invention provide a computer-readable storage medium storing at least one instruction, which is loaded and executed by a processor to implement the automated CAN communication code configuration method described above.

[0009] Fourthly, embodiments of the present invention provide an electronic device, the electronic device including a processor and a memory, the memory storing at least one instruction, the instruction being loaded and executed by the processor to implement the automated CAN communication code configuration method as described above.

[0010] The technical solution adopted in this invention can achieve the following beneficial effects: This invention provides an automated CAN communication code configuration method. This method uses the CAN network description file as the sole input source. By automatically parsing the complete communication matrix from the signal level to the message level and then to the node level in the DBC file, it directly extracts the message transmission and reception configuration information of each controller node. This frees engineers from the tedious repetitive work of manually looking up the communication matrix and entering configuration parameters one by one, significantly reducing the risk of configuration errors introduced by manual operation and improving the accuracy and consistency of the configuration process.

[0011] In the hardware resource allocation stage, the technical solution of this invention automatically establishes a mapping relationship between nodes and the hardware CAN controller based on the node identification information of each controller node. It then allocates sent and received messages to their corresponding send and receive mailboxes according to the transmission and reception direction of each message. Simultaneously, it automatically configures corresponding message filtering parameters for the receive mailbox based on the frame ID of each received message, forming a complete hardware resource allocation scheme that includes node mapping relationships, message mailbox mapping relationships, and message filtering parameters. This allocation process is fully automated, avoiding common problems such as mailbox resource conflicts and omissions in filter parameter configuration.

[0012] In the configuration file generation stage, the technical solution of this invention can simultaneously generate CAN communication configuration files at three levels: the microcontroller abstraction layer, the basic software layer, and the application software layer, based on the hardware resource allocation scheme. This achieves end-to-end connectivity from the channel parameters, sender and receiver mailbox configurations, and mailbox filtering configurations of the bottom-level driver, to the message routing configurations of the middle layer, and finally to the CAN message parsing configurations of the upper layer. The data reference relationships between the configuration files of each layer strictly correspond to the actual software architecture, ensuring the integrity and coordination of cross-layer configurations. This completely solves the problem of data inconsistency between layers that is prone to occur when manually maintaining multi-layer configuration files in the traditional development model. Attached Figure Description

[0013] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below, forming part of the present invention. The illustrative embodiments of the present invention and their descriptions explain the present invention and do not constitute an improper limitation of the present invention. In the accompanying drawings: Figure 1 This is a flowchart illustrating an automated CAN communication code configuration method provided in one embodiment of the present invention; Figure 2 This is a schematic diagram of the structure of an automated CAN communication code configuration device provided in one embodiment of the present invention. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. In the description of this invention, it should be noted that the term "or" is generally used to include the meaning of "and / or," unless otherwise expressly indicated.

[0015] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. Furthermore, in the description of this application, the terms "first," "second," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance.

[0016] Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0017] Existing vehicle controllers have numerous functions, and a single CAN bus often needs to send and receive many messages, resulting in a complex CAN network configuration code. Manual configuration of the entire system is extremely prone to errors. Even when using the complete AUTOSAR toolchain for CAN communication development, although code can be automatically generated in some stages, manual configuration is still required for the allocation of specific CAN controller mailboxes.

[0018] The allocation of CAN controller mailboxes directly affects the transmission and reception efficiency of the entire CAN communication network. On the receiving side, assigning messages with similar frame IDs to the same CAN mailbox effectively reduces the number of interrupts triggered by the CAN controller and lowers the time spent looking up addresses during CAN message routing. On the transmitting side, different CAN messages typically have different real-time requirements. Messages directly controlling actuators have higher priority and are assigned smaller CAN IDs, while messages sending controller status information have relatively lower priority and their CAN IDs are assigned within a wider range. If all messages are sent indiscriminately through the same CAN mailbox, it may cause a problem of transmission priority confusion within the software, where high-priority control messages are blocked because low-priority status messages have not yet been sent.

[0019] like Figure 1 To address the technical problems existing in the prior art, embodiments of the present invention provide an automated CAN communication code configuration method, comprising at least the following steps: Step S110: Obtain and parse the CAN network description file to extract the message transmission and reception configuration information of each controller node in the CAN network.

[0020] Step S120: Based on the message transmission and reception configuration information, each controller node is assigned to the corresponding hardware CAN controller, and the messages to be transmitted and received by each node are assigned to different mailboxes of the hardware CAN controller, thus forming a hardware resource allocation scheme.

[0021] Step S130: Based on the hardware resource allocation scheme, automatically generate CAN communication configuration files for the microcontroller abstraction layer, basic software layer, and application software layer.

[0022] In a preferred embodiment, the CAN network description file in step S110 is a DBC (DatabaseCAN) file. The DBC file is a standardized database file that describes the vehicle's CAN communication network. It defines the complete communication matrix of the vehicle's CAN network from the signal level to the message level and then to the node level in a structured manner.

[0023] Specifically, at the signal level, the DBC file records the name, data type, start bit, data length, byte order, scaling factor, offset, and value range of the physical signal carried by each CAN message; at the message level, the DBC file defines the frame ID, frame format (standard frame or extended frame), data length, and the relationship between each message and its associated signal for each CAN message; at the node level, the DBC file explicitly records the name identifier of each controller node in the vehicle CAN network, as well as the message sending and receiving relationships corresponding to each node, thus forming a complete transceiver matrix.

[0024] By parsing the aforementioned DBC file, the message transmission and reception configuration information of each controller node in the CAN network can be systematically extracted. In a preferred embodiment, the message transmission and reception configuration information includes at least the following: node identification information of each controller node, frame ID and transmission / reception direction of the messages transmitted and received by each node, and signal attribute information of the signals carried by each message.

[0025] The node identification information is used to uniquely identify each controller node in the CAN network, serving as the basis for subsequently mapping each controller node to the corresponding hardware CAN controller. The frame ID of each node's transmitted and received messages uniquely identifies each message on the CAN bus and determines the priority of each message in bus arbitration according to the CAN protocol specification; the smaller the frame ID value, the higher the message priority. The transmission / reception direction indicates whether the message is a transmit or receive message for the current controller node, which is an important basis for subsequent mailbox resource allocation. The signal attribute information carried by each message is used at the application software layer to perform physical quantity parsing on the received raw message data, restoring the message byte stream to signal values ​​with practical engineering significance.

[0026] It should be noted that in actual vehicle development scenarios, a controller typically needs to participate in communication on multiple CAN buses simultaneously. Therefore, the DBC file often corresponds to multiple different nodes, each representing the controller's communication entity on different CAN buses. By fully parsing the DBC file, the controller's transmit and receive message configuration information on all CAN buses can be obtained at once. This provides a complete and accurate data foundation for the automatic allocation of hardware resources in the subsequent step S120, thus avoiding the tedious process of engineers having to consult communication matrix documents one by one and manually organize transmit and receive frame lists in traditional development methods. This effectively reduces the risk of information omissions or input errors caused by manual operation.

[0027] In a preferred embodiment, step S120, which involves assigning each controller node to a corresponding hardware CAN controller, specifically includes: establishing a mapping relationship between each controller node and each hardware CAN controller in the microcontroller based on the node identification information of each controller node; and assigning each controller node to a corresponding hardware CAN controller according to the node mapping relationship.

[0028] Specifically, most microcontrollers (MCUs) integrate a varying number of hardware CAN controller resources, and the number of mailboxes supported by different hardware CAN controllers typically varies. When establishing node mapping relationships, this embodiment of the invention, based on the message transmission and reception configuration information of each controller node extracted in step S110, calculates the total number of different frame ID messages that each node needs to transmit and receive, and sorts them according to the number of messages transmitted and received by each node from most to least. Simultaneously, it calculates the total number of mailboxes owned by each hardware CAN controller in the microcontroller and sorts them from most to least. Based on this, a mapping relationship between nodes and hardware CAN controllers is established according to the above sorting results. That is, the controller node that needs to transmit and receive the most different frame ID messages is preferentially assigned to the hardware CAN controller with the most mailbox resources, and the remaining nodes are assigned in the same order.

[0029] By employing the above matching strategy, the mailbox resources of each hardware CAN controller can be fully utilized to the maximum extent, avoiding the problem that some nodes' transmit and receive messages cannot be effectively allocated to a sufficient number of mailboxes due to incorrect matching between nodes and controllers, thereby reducing the overall efficiency of the CAN communication network.

[0030] In a preferred embodiment, step S120, which involves allocating the messages to be sent and received by each node to different mailboxes of the hardware CAN controller, specifically includes: allocating the sending messages to the sending mailbox of the hardware CAN controller and the receiving messages to the receiving mailbox of the hardware CAN controller according to the sending and receiving direction of each message.

[0031] Specifically, regarding the allocation of message mailboxes, the CAN messages to be sent by the vehicle controller are typically divided into different priority levels according to their functional type: control messages that directly control actuator actions have high real-time requirements, and according to the CAN protocol arbitration rules, these messages are usually assigned frame IDs with smaller values; while diagnostic or status messages used to report the controller's own status information have relatively lower real-time requirements, and their frame ID values ​​are usually allocated within a larger range. If all messages are uniformly allocated to the same mailbox without distinction, it may cause a problem of transmission priority disorder during software execution, that is, high-priority control messages may be blocked because low-priority status messages have not yet been sent, thus affecting the real-time response of control commands. Therefore, this embodiment of the invention allocates messages of different priorities to different mailboxes according to the frame ID value range and functional type of each message, to ensure that each message can be sent in a timely manner according to its proper priority order, thus ensuring the real-time performance and reliability of CAN communication.

[0032] In a preferred embodiment, step S120 further includes: configuring corresponding message filtering parameters for the corresponding receiving mailbox based on the frame ID of each received message.

[0033] Specifically, in the design specifications of the vehicle CAN communication matrix, the frame IDs of messages sent from the same controller node are usually planned within a certain continuous or similar range, and the frame ID ranges of different controller nodes are distinguishable from each other. Based on the above pattern, in configuring message filtering parameters for each receiving mailbox, this embodiment of the invention determines the corresponding filtering mask and filtering reference value according to the distribution range of the frame IDs of the messages to be received by the mailbox. This ensures that each receiving mailbox only triggers a receiving interruption for messages belonging to a specific frame ID range, while other messages outside this range are filtered and blocked at the hardware level without the need for software processing.

[0034] The above configuration strategy allows for two main advantages: firstly, messages with similar frame IDs can be grouped into the same receiving mailbox for processing, effectively reducing the total number of interrupts triggered by the CAN controller to the main controller and lowering interrupt handling overhead; secondly, it avoids additional software routing lookup time incurred by the controller due to receiving irrelevant CAN messages that should not be processed, thus improving the overall receiving efficiency of the CAN communication network. If a controller node needs to receive messages from N different controller nodes, the filtering parameters of N receiving mailboxes can be configured accordingly to achieve targeted reception of messages from their respective sources by each receiving mailbox.

[0035] Preferably, the hardware resource allocation scheme formed through the above steps includes at least the following: the node mapping relationship between each controller node and the corresponding hardware CAN controller, the message mailbox mapping relationship between the messages to be sent and received by each controller node and the corresponding hardware CAN controller mailbox, and the message filtering parameters corresponding to each receiving mailbox.

[0036] The node mapping relationship records which hardware CAN controller each DBC node is assigned to, serving as the basic index for generating configuration files at subsequent levels. The message mailbox mapping relationship records the correspondence between each frame of transmitted and received messages from each controller node and its specific mailbox number, providing the direct basis for generating the microcontroller abstraction layer driver configuration and the basic software layer message routing configuration. The message filtering parameters record the filter mask and filter baseline value configuration for each receiving mailbox, ensuring the underlying hardware's ability to selectively filter messages on the receiving side. These three parts together constitute a complete hardware resource allocation scheme, providing a unified and complete data foundation for the synchronous generation of cross-level configuration files in the subsequent step S130.

[0037] In a preferred embodiment, step S130, the generation of the microcontroller abstraction layer driver configuration file, specifically includes: generating a microcontroller abstraction layer (MCAL) driver configuration file based on the message mailbox mapping relationship and the message filtering parameters corresponding to each receiving mailbox; the microcontroller abstraction layer driver configuration file records the channel configuration parameters, sender and receiver mailbox configuration information, and mailbox filtering configuration information of each hardware CAN controller.

[0038] In engineering practice, the configuration of microcontroller abstraction layer (AIL) drivers typically requires the use of the EB Tresos software tool. This software records the channel configuration parameters, sender / receiver mailbox configuration information, and mailbox filtering configuration information of each hardware CAN controller in .xdm file format. In traditional development methods, engineers must manually operate the EB Tresos software to enter these configuration parameters one by one to generate the corresponding .xdm configuration file, a tedious process prone to human error. This invention, through automated software, directly generates .xdm format configuration files conforming to the EB Tresos specification based on the message mailbox mapping relationship formed in step S120 and the message filtering parameters of each receiving mailbox. This eliminates the need for engineers to manually enter configuration parameters item by item, enabling automated CAN driver configuration and significantly reducing the manual operation cost and risk of configuration errors in microcontroller AIL configuration.

[0039] Specifically, the microcontroller abstraction layer driver configuration file is the configuration level in the entire AUTOSAR software architecture that directly corresponds to the underlying hardware resources. Its content must be strictly consistent with the physical characteristics and resource allocation results of the actual hardware CAN controller.

[0040] In a preferred embodiment, regarding channel configuration parameters, the configuration file generates corresponding timing configuration items for each CAN channel based on physical layer parameters such as baud rate settings, sampling point positions, and synchronization jump widths corresponding to each hardware CAN controller, ensuring that the communication bit timing between nodes on the CAN bus meets the requirements of relevant protocol specifications.

[0041] In a preferred embodiment, regarding the configuration information of the sending and receiving mailboxes, the configuration file records the attribute information such as the sending message frame ID and frame type (standard frame or extended frame) carried by each sending mailbox according to the message mailbox mapping relationship formed in step S120, and records the basic attributes such as the corresponding mailbox number and mailbox type for each receiving mailbox, thereby establishing a complete correspondence between frame ID and physical mailbox resources at the driver level.

[0042] In a preferred embodiment, regarding the mailbox filtering configuration information, the configuration file writes the message filtering parameters calculated for each receiving mailbox in step S120, namely the filter mask and the filter reference value, into the filtering configuration item of the corresponding receiving mailbox. This enables the hardware CAN controller to automatically block message frames that do not belong to the receiving range of this mailbox on the receiving side according to the filtering rules, and complete the pre-screening of messages without occupying software processing resources.

[0043] By generating the complete three parts mentioned above, the microcontroller abstraction layer driver configuration file can comprehensively describe the resource usage status of each hardware CAN controller, providing correct and reliable underlying hardware driver support for the operation of upper-layer modules in the AUTOSAR communication stack.

[0044] In a preferred embodiment, step S130, regarding the generation of the basic software layer message routing configuration file, specifically includes: generating a basic software layer (BSW) message routing configuration file based on the message mailbox mapping relationship; the message routing configuration file contains routing configuration information required to find the corresponding application layer message cache address based on the frame ID of the received message after the hardware CAN controller mailbox interrupt is triggered.

[0045] In traditional development methods, routing configuration information is typically recorded manually using C language code. Engineers must fill in the mapping relationship between the frame ID of each received message and the corresponding application layer cache address frame by frame. This is not only labor-intensive but also prone to communication anomalies due to incorrect frame IDs or missing cache addresses. This invention, through automated software, directly generates a C language source file containing complete routing configuration information based on the message mailbox mapping relationship formed in step S120. This automates the configuration of the basic software layer in CAN communication, completely replacing the tedious process of manually writing C code.

[0046] Specifically, in the AUTOSAR communication architecture, when a receiving mailbox receives a CAN message that meets the filtering conditions, the hardware CAN controller triggers a corresponding receive interrupt, notifying the communication management module of the basic software layer to read and distribute the message. At this time, the communication management module needs to quickly locate the application layer message data buffer address corresponding to the frame ID in the routing configuration table based on the frame ID of the received message, and write the message data into the buffer for subsequent reading by the message parsing module of the application software layer. If the routing configuration information is missing or incorrect, the communication management module will not be able to correctly identify the ownership of the received message, resulting in the message data not being written to the correct buffer address in time, thus causing abnormal execution of the application layer logic. To this end, this embodiment of the invention, based on the message mailbox mapping relationship formed in step S120, writes the mapping relationship between the frame ID of each received message and its corresponding application layer message buffer address into the message routing configuration file one by one, constructing a complete frame ID routing index table.

[0047] Furthermore, considering that the same frame message in the vehicle's CAN communication matrix may need to be read by multiple application modules simultaneously, the routing configuration file also supports configuring multiple target cache addresses for the same frame ID to meet the multicast distribution requirements of message data between different application modules. By automatically generating the above routing configuration file, communication anomalies caused by incorrect frame ID entries or omissions in cache address correspondences during manual configuration can be effectively avoided, ensuring the correctness and integrity of the basic software layer message routing function.

[0048] In a preferred embodiment, step S130, regarding the generation of the application software layer CAN message parsing configuration file, specifically includes: generating the application software layer CAN message parsing configuration file based on the transmit and receive frame information of each controller node; the CAN message parsing configuration file includes the data cache definition of each CAN message, and the parsing configuration information for parsing the messages in the data cache into corresponding signals based on the CAN network description file.

[0049] Specifically, in the AUTOSAR application software layer, the use of CAN communication data ultimately uses signals as the basic unit. The raw data frames of each CAN message are stored in the message data buffer as byte arrays. When the application software layer reads the value of a specific signal, it needs to extract the corresponding raw bit data from the raw byte array according to the parsing rules such as the starting bit position of the signal in the message data frame, the signal bit length, the byte order (big-endian or little-endian), and the quantization conversion coefficients (scaling factor and offset), and perform physical value conversion before obtaining the final engineering quantity value.

[0050] All the above parsing rules are derived from the signal definition information in the CAN network description file (DBC file) obtained in step S110. Based on the complete transmit and receive frame information of each controller node, this embodiment of the invention first generates a corresponding data buffer definition for each CAN message frame at the application software layer, specifying the data type, byte length, and storage location of the buffer area. Furthermore, based on the signal definitions contained in each message in the DBC file, a corresponding parsing configuration item is generated for each signal. This parsing configuration item completely records all parsing parameters such as the signal's start bit, signal bit length, byte order type, scaling factor, offset, and valid numerical range.

[0051] The message parsing module at the application software layer can directly read the aforementioned configuration file. During runtime, no hardcoding of any message frame format or signal parsing rules is required, thus effectively decoupling the message parsing logic from the specific communication matrix definition. When the communication matrix version changes or signal definitions are adjusted, simply re-importing the updated DBC file and triggering the configuration file regeneration process automatically updates the application software layer's parsing configuration. No modifications to the application software code itself are necessary, significantly reducing the software maintenance workload and the risk of introducing errors caused by CAN communication matrix version iterations.

[0052] In a preferred embodiment, the specific implementation of the aforementioned CAN message parsing configuration file can be flexibly selected according to actual engineering needs. On the one hand, a C language source file can be generated, recording the data buffer definition of each message and the parsing configuration parameters of each signal through structure arrays or macro definitions, for direct calling by the embedded software code at runtime; on the other hand, a Simulink model file can also be generated, describing the parsing logic of each signal in a model-based manner, suitable for controller software engineering using Model Driven Development (MDD) approach, realizing the automated construction of the CAN message parsing model of the application software layer in the Simulink environment.

[0053] This invention, through automated software, directly generates corresponding C language source files or Simulink models based on the DBC file information parsed in step S110 and the hardware resource allocation results in step S120. This achieves automated configuration of the application software layer in CAN communication, completely replacing the repetitive work of manually writing C code or manually building Simulink parsing models in traditional development.

[0054] Furthermore, this embodiment of the invention also provides an automated CAN communication code configuration device, such as... Figure 2 The system includes a parsing module 210, an allocation module 220, and a generation module 230. The parsing module 210 is used to obtain and parse the CAN network description file and extract the message transmission and reception configuration information of each controller node in the CAN network. The allocation module 220 is used to allocate each controller node to the corresponding hardware CAN controller based on the message transmission and reception configuration information, and allocate the messages to be transmitted and received by each node to different mailboxes of the hardware CAN controller to form a hardware resource allocation scheme. The generation module 230 is used to automatically generate CAN communication configuration files for the microcontroller abstraction layer, the basic software layer, and the application software layer according to the hardware resource allocation scheme.

[0055] It should be noted that the automated CAN communication code configuration device provided in this embodiment and the automated CAN communication code configuration method provided in the above method embodiment are based on the same inventive concept, and they correspond to each other in terms of technical principles and implementation logic. Specifically, the function implemented by the parsing module 210 corresponds to the function implemented by step S110 in the above method embodiment, the function implemented by the allocation module 220 corresponds to the function implemented by step S120, and the function implemented by the generation module 230 corresponds to the function implemented by step S130. Since the device provided in this embodiment is consistent with the technical principles, implementation steps, and beneficial effects involved in the above method embodiment, to avoid repetition, the specific implementation methods of each module will not be repeated here. For relevant technical details, please refer to the corresponding descriptions in the above method embodiments.

[0056] Furthermore, in one embodiment of the present invention, a computer-readable storage medium is provided, wherein at least one instruction is stored in the storage medium, the at least one instruction being loaded and executed by a processor to implement the automated CAN communication code configuration method as described above.

[0057] In one embodiment, this application also provides an electronic device including a processor and a memory, wherein the memory stores at least one instruction, which is loaded and executed by the processor to implement the automated CAN communication code configuration method as described above.

[0058] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0059] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of the present invention without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of the present invention.

Claims

1. An automated CAN communication code configuration method, characterized in that, include: Obtain and parse the CAN network description file to extract the transmit and receive message configuration information of each controller node in the CAN network; Based on the message transmission and reception configuration information, each controller node is assigned to the corresponding hardware CAN controller, and the messages to be transmitted and received by each node are assigned to different mailboxes of the hardware CAN controller, thus forming a hardware resource allocation scheme. Based on the hardware resource allocation scheme, CAN communication configuration files for the microcontroller abstraction layer, basic software layer, and application software layer are automatically generated.

2. The automated CAN communication code configuration method according to claim 1, characterized in that, The CAN network description file includes a DBC file, which defines the complete communication matrix in the vehicle's CAN network from the signal level to the message level and then to the node level.

3. The automated CAN communication code configuration method according to claim 1, characterized in that, The message transmission and reception configuration information includes at least: the node identification information of each controller node, the frame ID and transmission / reception direction of the messages transmitted and received by each node, and the signal attribute information of the signals carried by each message.

4. The automated CAN communication code configuration method according to claim 3, characterized in that, The step of assigning each controller node to the corresponding hardware CAN controller includes: Based on the node identification information of each controller node, a mapping relationship is established between each controller node and each hardware CAN controller in the microcontroller. Based on the node mapping relationship, each controller node is assigned to the corresponding hardware CAN controller.

5. The automated CAN communication code configuration method according to claim 3, characterized in that, The step of allocating the messages to be sent and received by each node to different mailboxes of the hardware CAN controller includes: Based on the sending and receiving directions of each message, the sent messages are assigned to the send mailbox of the hardware CAN controller, and the received messages are assigned to the receive mailbox of the hardware CAN controller.

6. The automated CAN communication code configuration method according to claim 3, characterized in that, The step of allocating the messages to be sent and received by each node to different mailboxes of the hardware CAN controller includes: Configure corresponding message filtering parameters for the corresponding receiving mailbox based on the frame ID of each received message.

7. The automated CAN communication code configuration method according to claim 1, characterized in that, The hardware resource allocation scheme includes at least: the node mapping relationship between each controller node and the corresponding hardware CAN controller, the message mailbox mapping relationship between the messages to be sent and received by each controller node and the corresponding hardware CAN controller mailbox, and the message filtering parameters corresponding to each receiving mailbox.

8. The automated CAN communication code configuration method according to claim 7, characterized in that, The step of automatically generating CAN communication configuration files for the microcontroller abstraction layer, basic software layer, and application software layer based on the hardware resource allocation scheme includes: Based on the message mailbox mapping relationship and the message filtering parameters corresponding to each receiving mailbox, a microcontroller abstraction layer driver configuration file is generated; The microcontroller abstraction layer driver configuration file records the channel configuration parameters, send / receive mailbox configuration information, and mailbox filtering configuration information of each hardware CAN controller.

9. The automated CAN communication code configuration method according to claim 7, characterized in that, The step of automatically generating CAN communication configuration files for the microcontroller abstraction layer, basic software layer, and application software layer based on the hardware resource allocation scheme includes: Based on the aforementioned message mailbox mapping relationship, a message routing configuration file for the basic software layer is generated; The message routing configuration file contains the routing configuration information required to find the corresponding application layer message cache address based on the frame ID of the received message after the hardware CAN controller mailbox interrupt is triggered.

10. The automated CAN communication code configuration method according to claim 7, characterized in that, The step of automatically generating CAN communication configuration files for the microcontroller abstraction layer, basic software layer, and application software layer based on the hardware resource allocation scheme includes: Based on the transmit and receive frame information of each controller node, a CAN message parsing configuration file for the application software layer is generated; The CAN message parsing configuration file contains the data cache definition for each CAN message, as well as parsing configuration information for parsing the messages in the data cache into corresponding signals based on the CAN network description file.

11. An automated CAN communication code configuration device, characterized in that, include: The parsing module is used to obtain and parse the CAN network description file and extract the transmit and receive message configuration information of each controller node in the CAN network. The allocation module is used to allocate each controller node to the corresponding hardware CAN controller based on the message transmission and reception configuration information, and to allocate the messages to be transmitted and received by each node to different mailboxes of the hardware CAN controller, thus forming a hardware resource allocation scheme. The generation module is used to automatically generate CAN communication configuration files for the microcontroller abstraction layer, basic software layer, and application software layer based on the hardware resource allocation scheme.

12. A computer-readable storage medium, characterized in that, The storage medium stores at least one instruction, which is loaded and executed by a processor to implement the automated CAN communication code configuration method as described in any one of claims 1-10.

13. An electronic device, characterized in that, The electronic device includes a processor and a memory, the memory storing at least one instruction, which is loaded and executed by the processor to implement the automated CAN communication code configuration method as described in any one of claims 1-10.

Images