Development Method and System of CAN Communication Platform Based on Embedded Linux

Abstract

This specification provides a method and system for developing a CAN communication platform based on embedded Linux. The method is applied to a CAN communication platform development system, which includes a hardware abstraction layer, a service layer, and an application layer. The method includes: calling the CAN interface initialization function of the service layer to traverse the CAN interface configuration table and initializing the CAN interface based on the configuration information in the table; the service layer storing the user-uploaded interface registration information in the CAN interface registry and creating a receive processing thread and a transmit processing thread for each CAN interface; the receive processing thread reading CAN frames from the receive queue of the CAN interface and determining a callback function pointer based on the CAN interface registration information; the application layer calling the corresponding callback function based on the callback function pointer to process the CAN frame; and the transmit processing thread reading CAN frames from the transmit queue of the corresponding CAN interface, with the hardware abstraction layer sending the CAN frame to the CAN bus.

Description

Technical Field

[0001] The embodiments in this specification relate to the field of computer technology, and in particular to a development method for a CAN communication platform based on embedded Linux. Background Technology

[0002] In embedded system development, the CAN bus is widely used in automotive electronics, industrial control, robotics and other fields due to its high reliability, real-time performance and anti-interference capabilities.

[0003] Traditional Linux system CAN communication development suffers from several problems, including high development complexity, lack of a unified framework, difficulty in multi-channel management, inflexible callback mechanisms, and cumbersome initialization processes. Developers need to directly call the raw LinuxSocket CAN interfaces (socket, ioctl, bind, etc.), resulting in repetitive and error-prone code. Inconsistent CAN driver interfaces implemented by different projects and developers lead to poor code reusability. The lack of a unified multi-CAN channel management mechanism frequently causes thread safety and resource contention issues. Traditional methods struggle to support dynamic callback registration and event response based on CAN ID ranges. Furthermore, each startup requires manual configuration of the baud rate, startup interface, and socket creation, lacking an automated initialization process.

[0004] It is evident that while some open-source CAN libraries exist, most lack complete service layer encapsulation, dynamic registration mechanisms, and unified management frameworks, resulting in low development efficiency and high maintenance costs. Therefore, an effective method is urgently needed to address these issues. Summary of the Invention

[0005] In view of this, embodiments of this specification provide a development method for a CAN communication platform based on embedded Linux. One or more embodiments of this specification also relate to a development system for a CAN communication platform based on embedded Linux, a computing device, a computer-readable storage medium, and a computer program, to address the technical deficiencies existing in the prior art.

[0006] According to a first aspect of the embodiments of this specification, a method for developing a CAN communication platform based on embedded Linux is provided, applied to a CAN communication platform development system, the CAN communication platform development system including a hardware abstraction layer, a service layer, and an application layer, the method comprising: By calling the CAN interface initialization function of the service layer, the predefined CAN interface configuration table is traversed, and each CAN interface is initialized based on the configuration information contained in the CAN interface configuration table. Receive the interface registration information uploaded by the user, and store the interface registration information in the registry of the corresponding CAN interface through the service layer; By calling the CAN interface startup function of the service layer, an independent receive processing thread and transmit processing thread are created for each CAN interface; The receiving processing thread reads the first CAN frame from the receiving queue of the corresponding CAN interface and determines the corresponding callback function pointer based on the registration information contained in the registry of the corresponding CAN interface. The application layer processes the first CAN frame by calling the corresponding callback function based on the callback function pointer. The sending processing thread reads the second CAN frame from the sending queue of the corresponding CAN interface and sends the second CAN frame to the CAN bus through the hardware abstraction layer.

[0007] Optionally, the initialization process for each CAN interface based on the configuration information contained in the CAN interface configuration table includes: The CAN interface manager is initialized by calling the CAN interface manager initialization function of the hardware abstraction layer and based on the configuration information contained in the CAN interface configuration table. Configure the baud rate of each CAN interface by calling the local CAN interface configuration function, and start each CAN interface. Create Socket interfaces and bind them to CAN interfaces respectively. The number of Socket interfaces is the same as the number of CAN interfaces, and there is a one-to-one correspondence between Socket interfaces and CAN interfaces. Initialize the transmit and receive queues for each CAN interface, and start the asynchronous receive thread for each CAN interface.

[0008] Optionally, receiving the interface registration information uploaded by the user includes: Receive interface registration information uploaded by the user through calling the CAN registration function of the service layer.

[0009] Optionally, the interface registration information includes the CAN interface number, CAN ID start value, CAN ID end value, and callback function pointer.

[0010] Optionally, determining the corresponding callback function pointer based on the registration information contained in the registry of the corresponding CAN interface includes: Read at least two CAN ID ranges from the registration information contained in the registry of the corresponding CAN interface. Each CAN ID range consists of a different CAN ID start value and a CAN ID end value, and different CAN ID ranges correspond to different callback function pointers. The CAN ID contained in the first CAN frame is determined, and if the CAN ID falls into the target CAN ID range, the callback function pointer corresponding to the target CAN ID range is determined as the callback function pointer corresponding to the first CAN frame, wherein the target CAN ID range is one of the at least two CAN ID ranges.

[0011] Optionally, the development method for the CAN communication platform based on embedded Linux further includes: The first received CAN frame is added to the receive queue via the receive thread of the hardware abstraction layer; and... The user calls the CAN interface sending function of the service layer through the asynchronous sending interface of the application layer to add the second CAN frame to the sending queue.

[0012] Optionally, the development method for the CAN communication platform based on embedded Linux further includes: The service layer's CAN interface is invoked to initialize the function, release all queue resources, close the Socket interface, and stop the thread.

[0013] According to a second aspect of the embodiments of this specification, a CAN communication platform development system based on embedded Linux is provided, including: a hardware abstraction layer, a service layer, and an application layer; The service layer is used to provide a CAN interface initialization function, which is used to traverse a predefined CAN interface configuration table and perform initialization processing on each CAN interface based on the configuration information contained in the CAN interface configuration table. The service layer is also used to store the received user-uploaded interface registration information into the registry of the corresponding CAN interface, and create an independent receiving processing thread and a sending processing thread for each CAN interface by calling the CAN interface startup function. The receiving processing thread reads the first CAN frame from the receiving queue of the corresponding CAN interface, and determines the corresponding callback function pointer according to the registration information contained in the registry of the corresponding CAN interface. The sending processing thread reads the second CAN frame from the sending queue of the corresponding CAN interface. The application layer is used to process the first CAN frame by calling the corresponding callback function based on the callback function pointer; The hardware abstraction layer is used to send the second CAN frame to the CAN bus.

[0014] According to a third aspect of the embodiments of this specification, a computing device is provided, comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement any of the steps of the CAN communication platform development method based on embedded Linux.

[0015] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores computer-executable instructions, which, when executed by a processor, implement the steps of any of the described methods for developing a CAN communication platform based on embedded Linux.

[0016] According to a fifth aspect of the embodiments of this specification, a computer program is provided, wherein when the computer program is executed in a computer, it causes the computer to perform the steps of the above-described CAN communication platform development method based on embedded Linux.

[0017] This embodiment of the specification initializes the CAN interface by calling the CAN interface initialization function of the service layer to traverse the CAN interface configuration table and perform initialization processing on the CAN interface based on the configuration information in the CAN interface configuration table. The service layer stores the interface registration information uploaded by the user in the CAN interface registry and creates a receive processing thread and a transmit processing thread for each CAN interface. The receive processing thread reads CAN frames from the receive queue of the CAN interface and determines the callback function pointer according to the registration information of the CAN interface. The application layer calls the corresponding callback function based on the callback function pointer to process the CAN frame. The transmit processing thread reads CAN frames from the transmit queue of the corresponding CAN interface, and the hardware abstraction layer sends the CAN frame to the CAN bus. Through the low-level driver development of this embodiment, the stability and compatibility of CAN communication in the Linux system can be significantly improved, and development time and cost can be reduced. At the same time, since the driver follows a unified framework and interface specification, the adaptation between different hardware platforms is simpler and more efficient. In addition, this embodiment supports concurrent processing of multiple CAN channels, and the queue buffering and thread isolation mechanism helps to improve system throughput and real-time performance. Furthermore, this embodiment provides a flexible ID range registration mechanism, which facilitates the implementation of complex event response logic and enhances system scalability. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating a development method for a CAN communication platform based on embedded Linux, provided in one embodiment of this specification. Figure 2This is a schematic diagram illustrating the initialization process during the development of a CAN communication platform based on embedded Linux, provided in one embodiment of this specification. Figure 3 This is a schematic diagram illustrating the registration process during the development of a CAN communication platform based on embedded Linux, provided in one embodiment of this specification. Figure 4 This is a schematic diagram of the data transmission and reception timing provided in one embodiment of this specification; Figure 5 This is a schematic diagram illustrating queue and thread management according to one embodiment of this specification; Figure 6 This is a schematic diagram of a CAN communication platform development system based on embedded Linux, provided in one embodiment of this specification; Figure 7 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0019] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0020] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0021] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0022] This specification provides a method for developing a CAN communication platform based on embedded Linux. This specification also relates to a CAN communication platform development system based on embedded Linux, a computing device, a computer-readable storage medium, and a computer program, which will be described in detail in the following embodiments.

[0023] Figure 1 A flowchart is shown of a development method for a CAN communication platform based on embedded Linux according to an embodiment of this specification. This development method is applied to a CAN communication platform development system, which includes a hardware abstraction layer, a service layer, and an application layer. The method specifically includes the following steps.

[0024] Step 102: By calling the CAN interface initialization function of the service layer, the predefined CAN interface configuration table is traversed, and each CAN interface is initialized based on the configuration information contained in the CAN interface configuration table.

[0025] In one optional implementation, the initialization process for each CAN interface based on the configuration information contained in the CAN interface configuration table includes: The CAN interface manager is initialized by calling the CAN interface manager initialization function of the hardware abstraction layer and based on the configuration information contained in the CAN interface configuration table. Configure the baud rate of each CAN interface by calling the local CAN interface configuration function, and start each CAN interface. Create Socket interfaces and bind them to CAN interfaces respectively. The number of Socket interfaces is the same as the number of CAN interfaces, and there is a one-to-one correspondence between Socket interfaces and CAN interfaces. Initialize the transmit and receive queues for each CAN interface, and start the asynchronous receive thread for each CAN interface.

[0026] Specifically, the CAN (Controller Area Network) communication platform development method based on embedded Linux provided in the embodiments of this specification is applied to the CAN communication platform development system, which includes a hardware abstraction layer, a service layer, and an application layer; The HAL layer (Hardware Abstraction Layer) is used to encapsulate the raw operations of Linux Socket CAN, providing standardized interfaces for initialization, sending, receiving, and deinitialization.

[0027] The SRV layer (service layer) is used to implement multi-channel management, queue buffering, thread scheduling, callback registration and distribution.

[0028] The APP layer (application layer) is used to respond to specific CAN frames by registering callback functions based on user-defined business logic. The specific CAN frame is essentially the trigger condition, and the callback function is the action to be executed.

[0029] In the embodiments of this specification, the development of a CAN communication platform first requires platform initialization. Specifically, this is achieved by calling the CAN interface initialization function SRV_CAN_Init() of the service layer, which iterates through the predefined CAN interface configuration table. This CAN interface configuration table contains the configuration information of each CAN interface (CAN channel), including but not limited to basic channel information, physical layer configuration, and communication rate. The basic channel information may include the CAN channel number (CAN1 / CAN2 / CAN3) and the channel name or purpose; the communication rate may include the baud rate.

[0030] Then, based on the configuration information contained in the CAN interface configuration table, initialization processing can be performed on each CAN interface, that is, for each CAN interface, the following steps are executed sequentially: 1) The CAN interface manager is initialized by calling the CAN interface manager initialization function HAL_CAN_ManagerInit() of the hardware abstraction layer and based on the configuration information contained in the CAN interface configuration table. 2) Set the baud rate of the CAN interface and start the CAN interface by calling the local CAN interface configuration function LOCAL_CanSetup(); 3) Create a socket and bind it to the CAN interface; 4) Initialize the transmit and receive queues of the CAN interface; 5) Start the asynchronous receive thread of the CAN interface.

[0031] Step 104: Receive the interface registration information uploaded by the user, and store the interface registration information in the registry of the corresponding CAN interface through the service layer.

[0032] In one optional implementation, receiving the interface registration information uploaded by the user includes: Receive interface registration information uploaded by the user through calling the CAN registration function of the service layer.

[0033] Furthermore, the interface registration information includes the CAN interface number, CAN ID start value, CAN ID end value, and callback function pointer.

[0034] Specifically, after the platform initialization is completed, it enters the callback registration phase. Specifically, the user first calls the CAN registration function SRV_CAN_Register() in the service layer to upload the interface number of the CAN interface, the start value of CAN ID, the end value of CAN ID and the callback function pointer to the service layer. Then the service layer stores this information in the registry of the corresponding CAN interface.

[0035] Step 106: By calling the CAN interface startup function of the service layer, create an independent receive processing thread and transmit processing thread for each CAN interface.

[0036] Specifically, after the callback registration phase is completed, the service startup phase begins. This involves calling the CAN interface startup function SRV_CAN_Start() in the service layer to create independent receive and transmit processing threads for each CAN interface.

[0037] Step 108: The receiving processing thread reads the first CAN frame from the receiving queue of the corresponding CAN interface and determines the corresponding callback function pointer based on the registration information contained in the registry of the corresponding CAN interface.

[0038] In one optional implementation, determining the corresponding callback function pointer based on the registration information contained in the registry of the corresponding CAN interface includes: Read at least two CAN ID ranges from the registration information contained in the registry of the corresponding CAN interface. Each CAN ID range consists of a different CAN ID start value and a CAN ID end value, and different CAN ID ranges correspond to different callback function pointers. The CAN ID contained in the first CAN frame is determined, and if the CAN ID falls into the target CAN ID range, the callback function pointer corresponding to the target CAN ID range is determined as the callback function pointer corresponding to the first CAN frame, wherein the target CAN ID range is one of the at least two CAN ID ranges.

[0039] In addition, the aforementioned method for developing a CAN communication platform based on embedded Linux also includes: The first received CAN frame is added to the receive queue via the receive thread of the hardware abstraction layer; and... The user calls the CAN interface sending function of the service layer through the asynchronous sending interface of the application layer to add the second CAN frame to the sending queue.

[0040] Specifically, during the data transmission and reception phase, the user calls the CAN interface transmission function SRV_CAN_Send() in the service layer through the asynchronous transmission interface of the application layer to add the second CAN frame to be sent to the transmission queue, which is then sent asynchronously by the transmission processing thread; and the first CAN frame received is added to the reception queue through the reception thread in the HAL layer, which is then matched and processed by the reception processing thread.

[0041] Based on this, the CAN interface's receive processing thread reads the first CAN frame from the receive queue and matches the CAN ID range according to the registry to call the corresponding callback function. Specifically, it first reads at least two corresponding CAN ID ranges from the registration information contained in the registry of the corresponding CAN interface. Each CAN ID range consists of a different CAN ID start value and a CAN ID end value, and different CAN ID ranges correspond to different callback function pointers. Then, it determines the CAN ID contained in the first CAN frame and matches this CAN ID with each CAN ID range, that is, it determines whether the CAN ID falls into a certain CAN ID range. If it is determined that the CAN ID falls into the target CAN ID range, the callback function pointer corresponding to the target CAN ID range is determined as the callback function pointer corresponding to the first CAN frame, where the target CAN ID range is one of at least two CAN ID ranges.

[0042] Step 110: The application layer processes the first CAN frame by calling the corresponding callback function based on the callback function pointer.

[0043] Specifically, once the callback function pointer corresponding to the first CAN frame is determined, the application layer can call the corresponding callback function based on the callback function pointer to process the first CAN frame.

[0044] Step 112: The second CAN frame is read from the transmission queue of the corresponding CAN interface through the transmission processing thread, and the second CAN frame is sent to the CAN bus through the hardware abstraction layer.

[0045] Specifically, as mentioned earlier, during the data transmission and reception phase, the user calls the CAN interface transmission function SRV_CAN_Send() in the service layer through the asynchronous transmission interface of the application layer to add the second CAN frame to be sent to the transmission queue, and the transmission processing thread performs asynchronous transmission.

[0046] Based on this, after creating an independent transmission processing thread for the CAN interface, the second CAN frame can be read from the transmission queue of the corresponding CAN interface through this transmission processing thread, and then sent to the CAN bus through the HAL layer.

[0047] Furthermore, the development method for the CAN communication platform based on embedded Linux also includes: The service layer's CAN interface is invoked to initialize the function, release all queue resources, close the Socket interface, and stop the thread.

[0048] Specifically, during the platform's initialization phase, the service layer's CAN interface can be called to initialize the function SRV_CAN_Deinit(), releasing all queue resources, closing the socket, and stopping the thread.

[0049] The CAN communication platform development method based on embedded Linux provided in this specification is applicable to embedded devices requiring multi-channel, high-concurrency, and scalable CAN communication. This specification aims to achieve efficient management of CAN devices in Linux systems through a three-tier architecture (hardware abstraction layer, service layer, application layer) CAN communication platform design, improving system stability, compatibility, and scalability while reducing development difficulty and cost. Specifically, it provides a standardized Linux CAN driver initialization method, simplifying the development process, enabling unified management and resource isolation of multiple CAN channels, providing a dynamic callback registration mechanism based on CAN ID ranges, supporting flexible event handling, designing thread-safe asynchronous transmit / receive queues to improve data throughput and stability, and constructing a three-tier architecture (HAL layer, SRV layer, APP layer) to improve code reusability and maintainability.

[0050] This embodiment of the specification initializes the CAN interface by calling the CAN interface initialization function of the service layer to traverse the CAN interface configuration table and perform initialization processing on the CAN interface based on the configuration information in the CAN interface configuration table. The service layer stores the interface registration information uploaded by the user in the CAN interface registry and creates a receive processing thread and a transmit processing thread for each CAN interface. The receive processing thread reads CAN frames from the receive queue of the CAN interface and determines the callback function pointer according to the registration information of the CAN interface. The application layer calls the corresponding callback function based on the callback function pointer to process the CAN frame. The transmit processing thread reads CAN frames from the transmit queue of the corresponding CAN interface, and the hardware abstraction layer sends the CAN frame to the CAN bus. By providing standardized interfaces, developers can focus on business logic without worrying about underlying socket operations, which improves development efficiency. Queue buffering, thread isolation, and resource management reduce resource contention and data loss, enhancing system stability. Support for dynamic addition and deletion of multiple CAN channels and a flexible callback registration mechanism facilitates feature expansion, improving scalability. The clear three-tier architecture, with reusable HAL and SRV layers, is suitable for different Linux platforms and CAN hardware, resulting in high code reusability. Furthermore, asynchronous thread processing and queuing mechanisms ensure timely response and transmission of critical CAN frames, guaranteeing high real-time communication performance.

[0051] The underlying driver development described in this specification can significantly improve the stability and compatibility of CAN communication in Linux systems, while reducing development time and costs. Furthermore, because the driver follows a unified framework and interface specification, adaptation between different hardware platforms is simpler and more efficient. Additionally, the embodiments in this specification support concurrent processing of multiple CAN channels, and through queue buffering and thread isolation mechanisms, they help improve system throughput and real-time performance. Moreover, the embodiments in this specification provide a flexible ID range registration mechanism, facilitating the implementation of complex event response logic and enhancing system scalability.

[0052] Figure 2 This diagram illustrates the initialization process during the development of a CAN communication platform based on embedded Linux, according to one embodiment of this specification. Figure 2 As shown, the first step in developing a CAN communication platform is to initialize the platform. Specifically, this involves calling the CAN interface initialization function SRV_CAN_Init() in the service layer to read the predefined CAN interface configuration table. This CAN interface configuration table contains the configuration information for each CAN interface (CAN channel), including but not limited to basic channel information, physical layer configuration, and communication rate. The basic channel information may include the CAN channel number (CAN1 / CAN2 / CAN3) and the channel name or purpose; the communication rate may include the baud rate.

[0053] Then, based on the configuration information contained in the CAN interface configuration table, all CAN channels can be traversed, and initialization processing can be performed on each CAN channel. That is, for each CAN interface (taking the CANx interface as an example), the following steps can be executed sequentially: 1) The CAN interface manager is initialized by calling the CAN interface manager initialization function HAL_CAN_ManagerInit() of the hardware abstraction layer and based on the configuration information contained in the CAN interface configuration table. 2) Set the baud rate of the CANx interface by calling the local CAN interface configuration function LOCAL_CanSetup(); 3) Disable the CANx interface; 4) Enable and activate the CANx interface; 5) Create a CAN Socket; 6) Bind the CAN Socket to the CANx interface; 7) Initialize the transmit queue of the CANx interface; 8) Initialize the receive queue of the CANx interface; 9) Set the callback function; 10) Start the asynchronous receive thread of the CANx interface.

[0054] After initializing each CAN interface, it is necessary to determine whether the current number of channels is less than the maximum number of channels. If so, return to the step of traversing all CAN channels; otherwise, set init_flag=true to end the initialization process.

[0055] Figure 3 This diagram illustrates the registration process during the development of a CAN communication platform based on embedded Linux, according to one embodiment of this specification. Figure 3 As shown, in the callback registration phase, the user first calls the CAN registration function SRV_CAN_Register() in the service layer to upload the interface number, CAN ID start value, CAN ID end value, and callback function pointer of the CAN interface to the service layer. Then, the service layer determines whether the number of registered interfaces is less than the maximum number of CAN interfaces. If not, it needs to call the CAN interface initialization function to initialize the new CAN interface. If so, it stores this information in the registry of the corresponding CAN interface, increments the value of the variable register_num by 1, and enters the service startup phase.

[0056] During the service startup phase, the CAN interface startup function SRV_CAN_Start() of the service layer is called. While waiting to confirm that init_flag=true, all CAN interfaces are traversed, and an independent receive processing thread and transmit processing thread are created for each CAN interface. Then, the CAN interface initialization function is called to determine if there are any more interfaces. If so, the step of traversing all interfaces is returned; otherwise, start_flag=true is set. At this point, the CAN communication platform is ready.

[0057] Figure 4 A schematic diagram illustrating the data transmission and reception timing provided in one embodiment of this specification is shown, demonstrating the timing process of a CAN frame from reception to callback processing. Figure 4 As shown, in the data reception process, the CAN frame first arrives at the HAL layer via the CAN bus, and then the HAL layer's receiving thread adds the received CAN frame to the receiving queue, where the receiving processing thread performs matching and callbacks. The receiving processing thread's loop process specifically involves: reading the CAN frame from the receiving queue and matching the CAN ID range according to the registry to call the corresponding callback function. Specifically, it first reads at least two corresponding CAN ID ranges from the registration information in the registry of the corresponding CAN interface. Each CAN ID range consists of a different CAN ID start value and a CAN ID end value, and different CAN ID ranges correspond to different callback function pointers. Then, it determines the CAN ID contained in the first CAN frame and matches this CAN ID with each CAN ID range, i.e., determines whether the CAN ID falls into a certain CAN ID range. If it is determined that the CAN ID falls into the target CAN ID range, the callback function pointer corresponding to the target CAN ID range is determined as the callback function pointer corresponding to the first CAN frame. Then, the application layer calls the corresponding callback function based on the callback function pointer to process the CAN frame.

[0058] For the data transmission process, the user calls the CAN interface transmission function SRV_CAN_Send() in the service layer through the asynchronous transmission interface of the application layer to add the CAN frame to be transmitted to the transmission queue. The transmission processing thread reads the CAN frame from the transmission queue and sends the CAN frame to the CAN bus through the HAL layer.

[0059] Figure 5 This document illustrates a schematic diagram of queue and thread management according to an embodiment of the present specification, showing the relationship between various channel queues, threads, and callback registry.

[0060] Taking the implementation of a dual-CAN channel communication platform as an example, assuming that an embedded device has two CAN interfaces (can0, can1), the specific development process is as follows: Step 1: Predefine the configuration table.

[0061] Step 2: Initialize the CAN interface.

[0062] By calling the CAN interface initialization function SRV_CAN_Init(), the predefined CAN interface configuration table is traversed. Based on the configuration information contained in the CAN interface configuration table, the initialization process is performed on each CAN interface in sequence. 1) The CAN interface manager is initialized by calling the CAN interface manager initialization function HAL_CAN_ManagerInit() of the hardware abstraction layer and based on the configuration information contained in the CAN interface configuration table. 2) Set the baud rate of the CAN interface and start the CAN interface by calling the local CAN interface configuration function LOCAL_CanSetup(); 3) The local CAN interface initialization function LOCAL_CanInit() creates a socket and binds it to can0 / can1; 4) Initialize the transmit and receive queues of the CAN interface (capacity 1024, supports overlay). 5) Start the asynchronous receive thread of the CAN interface.

[0063] Step 3: Callback registration.

[0064] First, the user calls the CAN registration function SRV_CAN_Register() in the service layer to upload the interface number of the CAN interface, the start value of the CAN ID, the end value of the CAN ID, and the callback function pointer to the service layer. Then, the service layer stores this information in the registry of the corresponding CAN interface, specifically in the server->member_register[] array.

[0065] Step 4: Start the service.

[0066] The CAN interface startup service SRV_CAN_Start() creates a CAN interface receive processing thread LOCAL_CanServerRecvProcess and a CAN interface send processing thread LOCAL_CanServerSendProcess for each channel.

[0067] The receiving processing thread retrieves CAN frames from the receive queue, iterates through the registry to match IDs, and calls the callback function.

[0068] The transmission processing thread retrieves CAN frames from the transmission queue and sends them to the CAN bus via HAL_CAN_Manager.

[0069] Corresponding to the above method embodiments, this specification also provides an embodiment of a CAN communication platform development system based on embedded Linux. Figure 6 This specification illustrates a schematic diagram of the structure of a CAN communication platform development system based on embedded Linux, according to one embodiment of this specification. Figure 6 As shown, the system includes: a hardware abstraction layer, a service layer, and an application layer; The service layer is used to provide a CAN interface initialization function, which is used to traverse a predefined CAN interface configuration table and perform initialization processing on each CAN interface based on the configuration information contained in the CAN interface configuration table. The service layer is also used to store the received user-uploaded interface registration information into the registry of the corresponding CAN interface, and create an independent receiving processing thread and a sending processing thread for each CAN interface by calling the CAN interface startup function. The receiving processing thread reads the first CAN frame from the receiving queue of the corresponding CAN interface, and determines the corresponding callback function pointer according to the registration information contained in the registry of the corresponding CAN interface. The sending processing thread reads the second CAN frame from the sending queue of the corresponding CAN interface. The application layer is used to process the first CAN frame by calling the corresponding callback function based on the callback function pointer; The hardware abstraction layer is used to send the second CAN frame to the CAN bus.

[0070] Optionally, the CAN interface initialization function is further used for: The CAN interface manager is initialized by calling the CAN interface manager initialization function of the hardware abstraction layer and based on the configuration information contained in the CAN interface configuration table. Configure the baud rate of each CAN interface by calling the local CAN interface configuration function, and start each CAN interface. Create Socket interfaces and bind them to CAN interfaces respectively. The number of Socket interfaces is the same as the number of CAN interfaces, and there is a one-to-one correspondence between Socket interfaces and CAN interfaces. Initialize the transmit and receive queues for each CAN interface, and start the asynchronous receive thread for each CAN interface.

[0071] Optionally, the service layer is further configured to: Receive interface registration information uploaded by the user through calling the CAN registration function of the service layer.

[0072] Optionally, the interface registration information includes the CAN interface number, CAN ID start value, CAN ID end value, and callback function pointer.

[0073] Optionally, the service layer is further configured to: Read at least two CAN ID ranges from the registration information contained in the registry of the corresponding CAN interface. Each CAN ID range consists of a different CAN ID start value and a CAN ID end value, and different CAN ID ranges correspond to different callback function pointers. The CAN ID contained in the first CAN frame is determined, and if the CAN ID falls into the target CAN ID range, the callback function pointer corresponding to the target CAN ID range is determined as the callback function pointer corresponding to the first CAN frame, wherein the target CAN ID range is one of the at least two CAN ID ranges.

[0074] Optionally, the hardware abstraction layer is further configured to: add the received first CAN frame to the receive queue via a receiving thread; The application layer is also used to: call the CAN interface transmission function of the service layer through the asynchronous transmission interface to add the second CAN frame to the transmission queue.

[0075] Optionally, the service layer is further configured to: The initialization function is accessed via the CAN interface, releasing all queue resources, closing the Socket interface, and stopping the thread.

[0076] Specifically, the HAL layer (Hardware Abstraction Layer) is used to encapsulate the raw operations of Linux Socket CAN, providing standardized interfaces for initialization, sending, receiving, and deinitialization.

[0077] The SRV layer (service layer) is used to implement multi-channel management, queue buffering, thread scheduling, callback registration and distribution.

[0078] The APP layer (application layer) is used to respond to specific CAN frames by registering callback functions based on user-defined business logic. The specific CAN frame is essentially the trigger condition, and the callback function is the action to be executed.

[0079] In the embodiments described in this specification, the development of a CAN communication platform first requires platform initialization. Specifically, this involves calling the CAN interface initialization function SRV_CAN_Init() in the service layer to traverse the predefined CAN interface configuration table, which contains the configuration information for each CAN interface (CAN channel). Then, based on the configuration information contained in the CAN interface configuration table, initialization processing can be performed on each CAN interface, that is, for each CAN interface, the following steps are executed sequentially: 1) The CAN interface manager is initialized by calling the CAN interface manager initialization function HAL_CAN_ManagerInit() of the hardware abstraction layer and based on the configuration information contained in the CAN interface configuration table. 2) Set the baud rate of the CAN interface and start the CAN interface by calling the local CAN interface configuration function LOCAL_CanSetup(); 3) Create a socket and bind it to the CAN interface; 4) Initialize the transmit and receive queues of the CAN interface; 5) Start the asynchronous receive thread of the CAN interface.

[0080] After the platform initialization is completed, it enters the callback registration phase. Specifically, the user first calls the CAN registration function SRV_CAN_Register() in the service layer to upload the interface number of the CAN interface, the start value of the CAN ID, the end value of the CAN ID, and the callback function pointer to the service layer. Then, the service layer stores this information in the registry of the corresponding CAN interface.

[0081] After the callback registration phase is completed, the service startup phase begins. Specifically, this involves calling the CAN interface startup function SRV_CAN_Start() in the service layer to create independent receive processing threads and transmit processing threads for each CAN interface.

[0082] During the data transmission and reception phase, the user adds the CAN frame to be sent to the transmission queue by calling the CAN interface transmission function SRV_CAN_Send() of the service layer through the asynchronous transmission interface of the application layer, and the transmission processing thread performs asynchronous transmission; and the received CAN frame is added to the receive queue through the receiving thread of the HAL layer, and the receiving processing thread performs matching and callback.

[0083] Based on this, for business application 1 and business application 2, the CAN interface receive processing thread is used to read CAN frames from the receive queue, and determine the corresponding callback function pointer according to the ID range of the CAN ID matched in the registry, so as to call the corresponding callback function.

[0084] Once the callback function pointer corresponding to the CAN frame is determined, the application layer can call the corresponding callback function based on the callback function pointer to process the CAN frame.

[0085] For business application 3, the CAN interface's transmission processing thread reads the CAN frame from the corresponding CAN interface's transmission queue and sends the CAN frame to the HAL layer through the HAL transmission interface, so that the HAL layer can send the CAN frame to the CAN bus through the encapsulated CAN physical interface.

[0086] In addition, the HAL layer is also used for the execution of system commands. The CAN interface initialization function SRV_CAN_Init() calls the CAN interface manager initialization function HAL_CAN_ManagerInit() for each channel. The latter executes commands such as ip link set canX down / up through the local CAN interface configuration function LOCAL_CanSetup() to configure the interface.

[0087] In the embodiments described in this specification, when the queue is full and overwriting is enabled, the oldest data is automatically overwritten to prevent memory exhaustion; the receiving thread and the sending thread are separated to avoid mutual blocking; the receiving thread uses select() to implement timeout to avoid permanent blocking; and, upon exiting, the queue is destroyed, the socket is closed, and memory is released in sequence.

[0088] This specification's embodiments predefine the parameters of each CAN channel (interface name, baud rate, timeout, etc.) through a structure array, supporting flexible expansion; allow users to register an ID range, and all CAN frames falling within that range trigger the same callback; each channel is equipped with an independent send queue and receive queue, decoupling production and consumption and improving concurrency; provide a CAN receive function with a timeout to avoid permanent thread blocking; and expose internal functions through macro control for easy unit testing and module verification.

[0089] The above is an illustrative scheme of a CAN communication platform development system based on embedded Linux according to this embodiment. It should be noted that the technical solution of this CAN communication platform development system based on embedded Linux and the technical solution of the aforementioned CAN communication platform development method based on embedded Linux belong to the same concept. Details not described in detail in the technical solution of the CAN communication platform development system based on embedded Linux can be found in the description of the technical solution of the aforementioned CAN communication platform development method based on embedded Linux.

[0090] Figure 7A structural block diagram of a computing device 700 according to one embodiment of this specification is shown. The components of the computing device 700 include, but are not limited to, a memory 710 and a processor 720. The processor 720 is connected to the memory 710 via a bus 730, and a database 750 is used to store data.

[0091] The computing device 700 also includes an access device 740, which enables the computing device 700 to communicate via one or more networks 760. Examples of these networks include a Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the Internet. The access device 740 may include one or more of any type of wired or wireless network interface (e.g., a Network Interface Card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) interface, a Wi-MAX interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC) interface, and so on.

[0092] In one embodiment of this specification, the above-described components of the computing device 700 and Figure 7 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 7 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0093] The computing device 700 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or PCs. The computing device 700 can also be a mobile or stationary server.

[0094] The processor 720 is used to execute the following computer-executable instructions, which, when executed by the processor, implement the steps of the above-described development method for the CAN communication platform based on embedded Linux.

[0095] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device belongs to the same concept as the technical solution of the above-described CAN communication platform development method based on embedded Linux. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the above-described CAN communication platform development method based on embedded Linux.

[0096] An embodiment of this specification also provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the above-described development method for a CAN communication platform based on embedded Linux.

[0097] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium belongs to the same concept as the technical solution of the above-described CAN communication platform development method based on embedded Linux. Details not described in detail in the technical solution of the storage medium can be found in the description of the technical solution of the above-described CAN communication platform development method based on embedded Linux.

[0098] An embodiment of this specification also provides a computer program, wherein when the computer program is executed in a computer, it causes the computer to perform the steps of the above-described CAN communication platform development method based on embedded Linux.

[0099] The above is an illustrative scheme of a computer program according to this embodiment. It should be noted that the technical solution of this computer program belongs to the same concept as the technical solution of the above-described CAN communication platform development method based on embedded Linux. For details not described in detail in the technical solution of the computer program, please refer to the description of the technical solution of the above-described CAN communication platform development method based on embedded Linux.

[0100] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0101] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or certain intermediate forms. The computer-readable medium may include any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added to or subtracted according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0102] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0103] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0104] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described herein. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A development method for a CAN communication platform based on embedded Linux, applied to a CAN communication platform development system, the CAN communication platform development system comprising a hardware abstraction layer, a service layer, and an application layer, the method comprising: By calling the CAN interface initialization function of the service layer, the predefined CAN interface configuration table is traversed, and each CAN interface is initialized based on the configuration information contained in the CAN interface configuration table. Receive the interface registration information uploaded by the user, and store the interface registration information in the registry of the corresponding CAN interface through the service layer; By calling the CAN interface startup function of the service layer, an independent receive processing thread and transmit processing thread are created for each CAN interface; The receiving processing thread reads the first CAN frame from the receiving queue of the corresponding CAN interface and determines the corresponding callback function pointer based on the registration information contained in the registry of the corresponding CAN interface. The application layer processes the first CAN frame by calling the corresponding callback function based on the callback function pointer. The sending processing thread reads the second CAN frame from the sending queue of the corresponding CAN interface and sends the second CAN frame to the CAN bus through the hardware abstraction layer.

2. The CAN communication platform development method based on embedded Linux according to claim 1, wherein the initialization process for each CAN interface based on the configuration information contained in the CAN interface configuration table includes: The CAN interface manager is initialized by calling the CAN interface manager initialization function of the hardware abstraction layer and based on the configuration information contained in the CAN interface configuration table. Configure the baud rate of each CAN interface by calling the local CAN interface configuration function, and start each CAN interface. Create Socket interfaces and bind them to CAN interfaces respectively. The number of Socket interfaces is the same as the number of CAN interfaces, and there is a one-to-one correspondence between Socket interfaces and CAN interfaces. Initialize the transmit and receive queues for each CAN interface, and start the asynchronous receive thread for each CAN interface.

3. The method for developing a CAN communication platform based on embedded Linux according to claim 1, wherein receiving the interface registration information uploaded by the user includes: Receive interface registration information uploaded by the user through calling the CAN registration function of the service layer.

4. The method for developing a CAN communication platform based on embedded Linux according to claim 1, wherein the interface registration information includes the CAN interface number, CAN ID start value, CAN ID end value, and callback function pointer.

5. The development method for a CAN communication platform based on embedded Linux according to claim 4, wherein determining the corresponding callback function pointer based on the registration information contained in the registry of the corresponding CAN interface includes: Read at least two CAN ID ranges from the registration information contained in the registry of the corresponding CAN interface. Each CAN ID range consists of a different CAN ID start value and a CAN ID end value, and different CAN ID ranges correspond to different callback function pointers. The CAN ID contained in the first CAN frame is determined, and if the CAN ID falls into the target CAN ID range, the callback function pointer corresponding to the target CAN ID range is determined as the callback function pointer corresponding to the first CAN frame, wherein the target CAN ID range is one of the at least two CAN ID ranges.

6. The method for developing a CAN communication platform based on embedded Linux according to claim 2 further includes: The first received CAN frame is added to the receive queue by the receiving thread of the hardware abstraction layer. as well as, The user calls the CAN interface sending function of the service layer through the asynchronous sending interface of the application layer to add the second CAN frame to the sending queue.

7. The method for developing a CAN communication platform based on embedded Linux according to claim 2 further includes: The service layer's CAN interface is invoked to initialize the function, release all queue resources, close the Socket interface, and stop the thread.

8. A CAN communication platform development system based on embedded Linux, comprising: Hardware abstraction layer, service layer, and application layer; The service layer is used to provide a CAN interface initialization function, which is used to traverse a predefined CAN interface configuration table and perform initialization processing on each CAN interface based on the configuration information contained in the CAN interface configuration table. The service layer is also used to store the received user-uploaded interface registration information into the registry of the corresponding CAN interface, and create an independent receiving processing thread and a sending processing thread for each CAN interface by calling the CAN interface startup function. The receiving processing thread reads the first CAN frame from the receiving queue of the corresponding CAN interface, and determines the corresponding callback function pointer according to the registration information contained in the registry of the corresponding CAN interface. The sending processing thread reads the second CAN frame from the sending queue of the corresponding CAN interface. The application layer is used to process the first CAN frame by calling the corresponding callback function based on the callback function pointer; The hardware abstraction layer is used to send the second CAN frame to the CAN bus.

9. A computing device, comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions. When the computer-executable instructions are executed by the processor, they implement the steps of the CAN communication platform development method based on embedded Linux as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the development method for the CAN communication platform based on embedded Linux as described in any one of claims 1 to 7.

Images