Device for transmitting data based on UART interface and CAN peripheral

Abstract

The application relates to the technical field of electronic equipment, and discloses a device for transmitting data based on a UART interface and a CAN peripheral. The device comprises a mainboard provided with a UART interface, the UART interface being used for connecting a CAN peripheral; a Linux system running on the mainboard, the Linux system comprising a CAN subsystem, a CAN driver, a tty subsystem and a UART driver, wherein the CAN driver is in communication connection with the CAN subsystem and the tty subsystem respectively, and the CAN driver is used for: receiving first data of a CAN protocol from the CAN subsystem, converting the first data into second data of a UART protocol, and transmitting the second data to the tty subsystem, so that the second data is transmitted to the CAN peripheral via the tty subsystem, the UART driver and the UART interface; and receiving third data of a UART protocol from the tty subsystem, converting the third data into fourth data of a CAN protocol, and transmitting the fourth data to an application program of the Linux system through the CAN subsystem. The application realizes the transmission of data between the UART interface and the CAN peripheral without adding a hardware module.

Description

Technical Field

[0001] This application relates to the field of electronic device technology, specifically to a device for transmitting data between a UART interface and a CAN peripheral. Background Technology

[0002] A Universal Asynchronous Receiver / Transmitter (UART) is a bidirectional, serial, asynchronous communication bus that enables full-duplex communication using only one data receive line and one data transmit line. A Controller Area Network (CAN) bus is a serial communication protocol bus used in real-time applications. The CAN protocol is characterized by high reliability, high speed, and multi-node capabilities, and is therefore widely used in modern automotive control systems.

[0003] With the rapid development of new energy vehicles, their electrification level and sensor technology are improving daily, leading to a significant increase in the requirements for data transmission bandwidth and real-time performance of the vehicle's network. Therefore, the traditional two-channel CAN bus is no longer sufficient, and modern vehicles generally require four or even five CAN buses to handle increasingly complex communication tasks. To address the insufficient CAN interfaces on traditional motherboards, UART buses can be used for expansion to achieve bidirectional CAN data communication. However, currently, communicating with CAN peripherals via the UART interface requires a UART-to-CAN module. The problem that needs to be solved is how to transmit data between the motherboard's UART interface and CAN peripherals without adding a hardware module (i.e., a UART-to-CAN module). Summary of the Invention

[0004] In view of the above problems, this application provides a device for transmitting data between a UART interface and a CAN peripheral, which solves the problem in the prior art that requires additional hardware modules to transmit data between the UART interface and the CAN peripheral on the motherboard.

[0005] According to one aspect of the embodiments of this application, a device for transmitting data between a UART interface and a CAN peripheral is provided. The device includes: a motherboard having a UART interface for connecting a CAN peripheral; and a Linux system running on the motherboard, the Linux system including a CAN subsystem, a CAN driver, a tty subsystem, and a UART driver, wherein the CAN driver is communicatively connected to both the CAN subsystem and the tty subsystem, and the CAN driver is configured to: receive first data in the CAN protocol from the CAN subsystem, convert the first data into second data in the UART protocol, and transmit the second data to the tty subsystem, so as to transmit the second data to the CAN peripheral via the UART interface through the tty subsystem and the UART driver; and receive third data in the UART protocol from the tty subsystem, convert the third data into fourth data in the CAN protocol, and transmit the fourth data to an application program of the Linux system through the CAN subsystem.

[0006] In one alternative approach, the CAN driver stores data conversion rules corresponding to the CAN peripheral; specifically, the CAN driver is used to convert the first data into the second data according to the data conversion rules, and to convert the third data into the fourth data according to the data conversion rules.

[0007] In one optional embodiment, the CAN peripheral is a first CAN peripheral or a second CAN peripheral; the UART interface is used to connect to the first CAN peripheral or the second CAN peripheral; the CAN driver stores a first data conversion rule corresponding to the first CAN peripheral and a second data conversion rule corresponding to the second CAN peripheral; the CAN driver is specifically used to: determine the current CAN peripheral currently connected to the UART interface, determine the current data conversion rule corresponding to the current CAN peripheral from the first data conversion rule and the second data conversion rule, convert the first data to the second data according to the current data conversion rule, and convert the third data to the fourth data.

[0008] In one alternative approach, the first CAN peripheral and the second CAN peripheral correspond to a first peripheral identifier and a second peripheral identifier, respectively, and the Linux system is configured to store only the current peripheral identifier corresponding to the current CAN peripheral; the CAN driver is specifically used to determine the current CAN peripheral through the current peripheral identifier.

[0009] In one alternative approach, the Linux system stores a data table that includes a driver identifier and initialization information corresponding to the CAN driver; the Linux system is used to scan the data table during startup, start the CAN driver corresponding to the driver identifier, and initialize the CAN driver according to the initialization information.

[0010] In one optional embodiment, the CAN driver is further configured to: determine whether the data structure of the first data is a valid structure; if the data structure of the first data is a valid structure, convert the first data into the second data and perform CRC calculation on the second data to generate a CRC checksum; determine whether the current state of the UART interface is a state where data transmission is possible; if the current state of the UART interface is a state where data transmission is possible, transmit the second data and the CRC checksum together to the CAN peripheral through the tty subsystem, the UART driver, and the UART interface.

[0011] In an alternative embodiment, the CAN driver is further configured to lock the data transmission channel for transmitting the second data using a data transmission lock before determining whether the data structure of the first data is a valid structure, and to release the data transmission lock after the second data transmission is completed.

[0012] In an optional embodiment, the CAN driver is further configured to: determine whether the current state of the UART interface is a state where data transmission is possible; if the current state of the UART interface is a state where data transmission is possible, receive the third data and the first CRC checksum through the UART driver and the tty subsystem; verify the integrity of the third data; if the third data is complete, perform CRC calculation on the third data to generate a second CRC checksum; if the second CRC checksum and the first CRC checksum are consistent, convert the third data into the fourth data, and transmit the fourth data to the application through the CAN subsystem.

[0013] In one alternative approach, the CAN driver is specifically used to parse the third data, determine the frame header data of the third data, and verify the integrity of the third data based on the frame header data.

[0014] In one alternative approach, the CAN driver is specifically used to parse the third data, determine the frame header data of the third data, and verify the integrity of the third data based on the frame header data.

[0015] In this embodiment, by setting up a CAN driver that communicates with both the CAN subsystem and the tty subsystem, the data received from the CAN subsystem is converted into UART protocol data. The converted data is then transmitted to the CAN peripheral via the tty subsystem, the UART driver, and the UART interface. Conversely, the data received from the tty subsystem is converted into CAN protocol data and transmitted to the Linux system application via the CAN subsystem. This allows the Linux system running on the motherboard to communicate directly with the CAN peripheral without relying on an external hardware conversion module, simplifying the system architecture and improving communication flexibility and device integration.

[0016] The above description is merely an overview of the technical solutions of the embodiments of this application. In order to better understand the technical means of the embodiments of this application and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of this application more obvious and understandable, specific implementation methods of this application are described below. Attached Figure Description

[0017] The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This diagram illustrates the data transmission process between the existing UART-to-CAN module and the main control system of the motherboard. Figure 2 This illustration shows a schematic diagram of a device for transmitting data between a UART interface and a CAN peripheral, as provided in an embodiment of this application. Figure 3 A flowchart illustrating the steps of CAN driver execution provided in an embodiment of this application is shown; Figure 4 A flowchart illustrating the steps of CAN driver execution provided in another embodiment of this application is shown.

[0018] The reference numerals in the detailed embodiments are as follows: 10. Devices that transmit data between UART interface and CAN peripheral; 100. Motherboard; 110. Linux system; 111. Application program; 112. CAN socket; 113. CAN subsystem; 114. CAN driver; 115. tty subsystem; 116. UART driver; 120. UART interface. Detailed Implementation

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

[0020] In project development, when the motherboard itself lacks a CAN interface, or its CAN interface version is incompatible (e.g., it does not support Controller Area Network with Flexible Data (CAN FD) or the baud rate is insufficient), other types of interfaces can be converted to a CAN interface to enable the motherboard to communicate with CAN peripherals. For example, this conversion can be achieved using modules such as USB-to-CAN, UART-to-CAN, or PCIe-to-CAN. However, USB-to-CAN and PCIe-to-CAN modules typically require proprietary drivers provided by the manufacturer to function correctly.

[0021] In contrast, UART-to-CAN modules are particularly suitable for small-scale projects due to their low cost and driverless nature. Their driverless advantage stems from the fact that most motherboards have a UART interface; data exchange with the CAN module can be achieved simply by using the RX and TX pins of the UART. Ultimately, the data is sent to the CAN bus via the CAN module, or the CAN module parses the data on the CAN bus and then forwards it to the main controller via UART.

[0022] Figure 1 This diagram illustrates the data transmission process between an existing UART-to-CAN module and the main control system of the motherboard. Figure 1 As shown, the motherboard's MCU connects to a UART-to-CAN module via its UART interface. This UART-to-CAN module then connects to CAN peripherals via the CAN bus. CAN peripherals refer to electronic devices connected to the CAN bus, such as other ECUs, sensors, or actuators. The motherboard's main control system is the brain of the entire system, responsible for application logic. The application program refers to the program used to implement specific functions, such as sending control commands to CAN peripherals, requesting sensor data from CAN peripherals, and processing messages received from CAN peripherals. The MCU UART peripheral is a dedicated hardware circuit within the MCU chip on the motherboard responsible for UART communication. It converts parallel data to be sent by the CPU into serial data, outputs it through the TX pin, and converts serial data received from the RX pin into parallel data for CPU processing.

[0023] Taking sending control commands from an application to a CAN peripheral as an example, the control commands sent by the application are first encapsulated according to the serial port protocol customized by the UART-to-CAN module. The encapsulated data is then sent to the MCU's UART interface via the TX pin of the MCU's UART peripheral. This interface is used for communication with the main control system. Protocol parsing and data conversion are the core firmware programs of the MCU inside the UART-to-CAN module. Protocol parsing refers to parsing the CAN ID and data content according to the preset serial port protocol; data conversion refers to assembling the parsed data into CAN data frames conforming to the CAN 2.0A / B standard. The CAN controller is a hardware controller used to handle various details of the CAN protocol, such as bit timing, arbitration, error detection, and acknowledgment. After parsing and converting the data, it is transmitted to the CAN controller, and then to the CAN transceiver. The CAN transceiver connects the CAN controller and the physical bus, converting the digital signals (CAN_TX, CAN_RX) output by the CAN controller into differential signals (CAN_H, CAN_L) for transmission on the bus, and converting the differential signals on the bus into digital signals for transmission to the CAN controller. The CAN transceiver transmits data to the CAN bus network, which consists of two twisted pairs of wires (CAN_H and CAN_L). Ultimately, the data is transmitted to the ECUs / sensors / actuators of the CAN peripherals. These ECUs / sensors / actuators are the other CAN nodes on the bus, communicating with each other via the CAN protocol. The UART-to-CAN module enables the main control MCU to send and receive messages on the bus just like these other nodes.

[0024] As explained above, if the main control system is a Linux system, and a UART-to-CAN module is used under Linux, the UART interface cannot be used by other programs. However, this exclusivity requirement in Linux systems can usually only be adhered to through development conventions; the system itself cannot forcibly prevent other users or programs from accessing the serial port device file. Once another program uses the serial port, the CAN communication data will be affected.

[0025] On the Linux system platform, the interface encapsulation of the UART to CAN module can be implemented through middleware. In other words, the middleware performs protocol conversion between different modules and provides a unified Application Programming Interface (API) to the application. However, this method still provides a custom interface, which is not as universal as the native Linux interface and is not suitable for situations where multiple applications concurrently access the CAN bus.

[0026] To address the aforementioned issues, this application proposes a device for transmitting data between a UART interface and a CAN peripheral. This is achieved by configuring a CAN driver within the Linux system running on the device. This CAN driver serves as a core component of the Linux system, connecting to both the CAN subsystem and the teletypewriter (tty) subsystem within the Linux system. When the CAN driver receives first data in the CAN protocol from the CAN subsystem, it converts this data into second data in the UART protocol and transmits it to the CAN peripheral via the UART interface through the tty subsystem and the UART driver. Similarly, when the CAN driver receives third data in the UART protocol from the tty subsystem, it converts this data into fourth data in the CAN protocol and transmits it to the upper-layer application through the CAN subsystem. This approach allows the Linux system on the motherboard to communicate directly with the CAN peripheral without relying on external hardware conversion modules, simplifying the system architecture and improving communication flexibility and device integration. Furthermore, since Linux provides numerous readily available tools, CAN peripheral debugging can be easily performed within the Linux system. Moreover, the ability to directly manipulate the CAN driver using the Qt programming framework reduces application development costs. Qt is a cross-platform C++ application development framework whose core goal is to enable developers to build high-performance, graphical applications that run on multiple operating systems and devices using a single codebase. Qt is not only a graphical user interface (GUI) framework, but also includes a rich set of underlying libraries for network communication, database operations, file I / O, multithreading, signals and slots (Qt's core mechanism), supporting development across all scenarios from embedded devices to desktops, mobile devices, and IoT devices.

[0027] The following section will describe in detail the device provided in this application that transmits data based on a UART interface and a CAN peripheral, with reference to the accompanying drawings. Figure 2 A schematic diagram of a device for transmitting data between a UART interface and a CAN peripheral, as provided in an embodiment of this application, is shown. Figure 2As shown, the device 10, which transmits data between a UART interface and a CAN peripheral, includes a motherboard 100 and a Linux system 110 running on the motherboard 100. The motherboard 100 also has a UART interface 120 for connecting to the CAN peripheral. In this embodiment, a CAN driver 114 is added to the existing Linux system. The CAN driver 114 is communicatively connected to the CAN subsystem 113 and the tty subsystem 115. The CAN driver 114 is used to convert UART protocol data into CAN protocol data and vice versa. The specific implementation of the CAN driver 114 will be described in other embodiments below.

[0028] When the Linux system 110 starts, in order for the newly added CAN driver 114 to be correctly loaded and started, the CAN driver 114 must first be declared. Specifically, the Linux system 110 stores a data table that records the identifiers corresponding to the drivers to be loaded and started. By writing the driver identifier and initialization information corresponding to the CAN driver 114 into this data table, when the device 10, which transmits data with the CAN peripheral via the UART interface, is connected to the power supply, the Linux system 110 scans this data table, obtains the driver identifier corresponding to the CAN driver 114 from the data table, and then starts the CAN driver 114 corresponding to that driver identifier, and initializes the CAN driver 114 according to the initialization information in the data table. The specific type of this data table depends on the architecture of the device 10 that transmits data via UART interface and CAN peripheral. If the device 10 that transmits data via UART interface and CAN peripheral is an x86-based device (such as a personal computer), then the data table is an Advanced Configuration and Power Interface (ACPI) table; if the device 10 that transmits data via UART interface and CAN peripheral is an embedded system, then the data table is a Device Tree Source (DTS) table.

[0029] When declaring CAN driver 114, it must be declared in the ACPI or DTS table, and this declaration must be performed under the corresponding UART controller to ensure that the UART interface operated by CAN driver 114 matches the physical interface on the hardware. Furthermore, the ACPI hardware identifier (HID) or DTS compatible attribute used in the declaration must be completely consistent with the identifier set in the CAN driver 114 source code. Only when the two match will the Linux kernel recognize and call the CAN driver 114. Here, "compatible" is equivalent to the driver's name. The Linux system 110 compares the compatible attribute of a driver with the compatible attribute in the DTS table. If the compatible attribute of a driver matches the compatible attribute in the DTS table, it means that the driver needs to be started.

[0030] Furthermore, when a Linux system boots up and loads a driver, it typically executes a hardware detection function first. This function checks if the target hardware exists before driver initialization. If the hardware exists, the driver continues with the subsequent initialization process; if the hardware does not exist, the driver immediately stops loading. The core purpose of this mechanism is to prevent the driver from performing invalid operations and to prevent system exceptions or errors caused by continuing to run in the absence of hardware.

[0031] It should be noted that for the driver, the hardware binding is first achieved through driver registration and device matching mechanisms. After successful matching, the probe function is responsible for initializing underlying resources such as network devices, CAN devices, GPIO, and work queues. When the application layer requests to enable the device, the open function completes the device configuration and opens the serial port to prepare for data communication. During the data transmission phase, the xmit function is responsible for sending CAN frames through the UART interface, while the receive function reads data from the UART interface and parses it into CAN frames. In addition, the driver also provides a system call interface (sysfs) for user space to configure parameters and read status. Finally, the device check thread continuously verifies the device's existence and reads relevant configurations to ensure the stable operation of the driver.

[0032] The core functionality of the driver is implemented through five logical stages. First, in the driver registration stage, the system registers a serial device (serdev) driver using the `module_serdev_device_driver` macro and uses driver matching tables (covering `of_match_table` for device tree matching and `acpi_match_table` for ACPI matching) to automatically bind the driver to the underlying hardware. After a successful match, the system enters the probe stage, which is responsible for initializing core resources: allocating network devices (`alloc_candev`) and private data structures (`evoc400b_priv`); binding the network device operation set (`netdev_ops`) and the CAN device mode setting interface (`can_do_set_mode`); initializing basic mechanisms such as locks, work queues, and timers; and obtaining GPIO pins for reset and configuration based on device tree or ACPI information. In addition, the probe function adds the current device to the shared management structure (evoc400b_shareds) to maintain the shared state of the dual UART interfaces. For UART, it also creates sysfs interfaces for channel and registers for configuration and status reading, and starts a dedicated device check thread (thread_check_evoc400b) to verify the existence of the device and read the register configuration, and finally completes the registration of the CAN device (register_candev).

[0033] When a device is enabled, the `open` function is called. This function sets the communication bit rate and writes the configuration information to the registers. It then opens the serial device (`serdev_device_open`) and sets the communication baud rate, finally waking up the network device's transmit queue (`netif_wake_queue`) to prepare for data communication. During data transmission, the `xmit` function encapsulates the CAN frame according to a specific protocol format and calculates the CRC checksum. It then places the data into the transmit buffer and initiates serial port transmission via the work queue (or by directly calling the transmit interface). Correspondingly, the `receive` function reads the data stream from the serial device, parses it back into a CAN frame, and finally submits it to the network protocol stack. In addition, the driver includes two auxiliary mechanisms: the system call interface (`sysfs`) provides read / write access to channels and registers to user space for dynamic device configuration and status acquisition; the device check thread periodically sends query commands to verify device responses to confirm the device is online and reads the device's register configuration information in real time.

[0034] This section will detail the implementation of the CAN driver 114. For example... Figure 2As shown, when the application 111 of the Linux system 110 needs to send data to the CAN peripheral (e.g., control commands, commands requesting the CAN peripheral to send data from its sensors), the application 111 transmits the data to the socket CAN 112. Socket CAN is a CAN communication framework natively integrated into the Linux kernel. It abstracts the CAN bus into a Linux network socket interface, allowing developers to read and write CAN data using the familiar Berkeley Software Distribution (BSD) Socket API (in the same way as TCP / IP network programming). It is compatible with various CAN hardware, whether it's a native CAN controller or a USB-to-CAN or UART-to-CAN device; as long as the driver is registered as a network device, the application layer can access it using the same Socket API. Socket CAN is a standardized adapter for CAN communication under Linux, allowing the application layer to use the CAN bus simply, efficiently, and across hardware, just like operating a network interface.

[0035] Next, the Socket CAN transmits data to the CAN subsystem 113, and the CAN subsystem 113 transmits the first data of the CAN protocol to the CAN driver 114. The CAN subsystem 113 is an existing subsystem in the Linux system. Since the CAN peripheral is connected to the UART interface 120 of the motherboard 100, in order to transmit the data sent by the application 111 to the CAN peripheral, in this embodiment, the CAN driver 114 converts the first data into second data of the UART protocol, and transmits the second data to the CAN peripheral via the UART interface 120 through the tty subsystem 115 and the UART driver 116. Because the CAN peripheral is connected to the motherboard 100 through the UART interface, and the second data sent by the motherboard 100 to the CAN peripheral is UART protocol data, conforming to the communication specifications of the UART interface, it can be correctly received and parsed by the CAN peripheral, thus realizing the transmission of data to the CAN peripheral through the UART interface.

[0036] Similarly, in order for the application 111 to receive data sent by the CAN peripheral, when the CAN peripheral sends data to the application 111 through the UART interface 120, the CAN peripheral sends the third data of the UART protocol through the UART driver 116 and the tty subsystem 115. After receiving the third data from the tty subsystem 115, the CAN driver 114 converts the third data into the fourth data of the CAN protocol and transmits the fourth data to the application 111 through the CAN subsystem 113 and Socket CAN.

[0037] In this embodiment, by setting a CAN driver 114 that is communicatively connected to the CAN subsystem 113 and the tty subsystem 115 respectively, the CAN driver 114 converts the CAN protocol data received from the CAN subsystem 113 into UART protocol data. The converted data is then transmitted to the CAN peripheral through the tty subsystem 115, the UART driver 116, and the UART interface 120. Additionally, the UART protocol data received from the tty subsystem 115 is converted into CAN protocol data, and the converted data is transmitted to the application 111 of the Linux system 110 through the CAN subsystem 113. This allows the Linux system 110 running on the motherboard 100 to communicate directly with the CAN peripheral without relying on an external hardware conversion module, simplifying the system architecture and improving the flexibility of communication and the integration of the device.

[0038] Different CAN peripheral manufacturers may use different CAN protocols. Therefore, in order for the CAN driver 114 to convert CAN protocol data to UART protocol data and vice versa, in this embodiment, the CAN driver 114 stores data conversion rules corresponding to the CAN peripheral. These data conversion rules can be the CAN protocol defined by the CAN peripheral manufacturer, which specifies details such as the data frame format, the meaning of identifiers (IDs), the parsing method of data fields, and error handling mechanisms.

[0039] In this embodiment of the application, by storing the data conversion rules corresponding to the CAN peripheral in the CAN driver 114, the CAN driver 114 can parse the first data of the CAN protocol according to the data conversion rules, and then accurately convert the first data of the CAN protocol into the second data of the UART protocol, and accurately convert the third data of the UART protocol into the fourth data in a format that conforms to the requirements of the CAN protocol.

[0040] In some embodiments, if the local storage space of the motherboard 100 is limited, the data conversion rules can also be stored on a server or in the cloud. When the CAN driver 114 needs to convert data, it retrieves the stored data conversion rules from the server or cloud and performs data conversion according to the data conversion rules.

[0041] for Figure 1The most critical aspect of the existing data transmission method using the UART interface with CAN peripherals for the main control system is the implementation of protocol and data encapsulation. Since different manufacturers' UART-to-CAN modules typically use their own proprietary communication protocols, if the CAN peripheral is replaced with a different protocol, application developers must rewrite or modify the serial port protocol parsing and encapsulation code in the application to adapt to the new module's format requirements, which is detrimental to product updates and iterations.

[0042] In other words, under different circumstances, the device 10, which transmits data to CAN peripherals based on the UART interface, may communicate with CAN peripherals manufactured by different manufacturers through the UART interface 120. However, the CAN protocols defined by different CAN peripheral manufacturers may be different. Therefore, when the UART interface 120 is connected to different CAN peripherals, in order to enable the CAN driver 114 to accurately convert data and avoid frequent changes to the upper-layer application due to differences in the underlying protocol, in some embodiments, the data conversion rules corresponding to different CAN peripherals (i.e., all CAN peripherals that may be connected to the UART interface 120) can be stored in the CAN driver 114. The CAN driver 114 determines the CAN peripheral currently connected to the UART interface 120, and then performs data conversion according to the data conversion rules corresponding to that CAN peripheral. This ensures that the CAN driver 114 can accurately convert data, thereby achieving seamless compatible communication between the device 10 that transmits data based on the UART interface and CAN peripherals and CAN peripherals from different manufacturers. Moreover, there is no need to modify the protocol of the upper-layer application to adapt to different CAN peripherals. This achieves complete decoupling between the application and the underlying CAN peripherals, reduces the maintenance cost of the application, and facilitates product updates and iterations.

[0043] Specifically, the UART interface 120 is used to connect to either the first or second CAN peripheral, and the first data conversion rule corresponding to the first CAN peripheral and the second data conversion rule corresponding to the second CAN peripheral are pre-stored in the CAN driver 114. The CAN driver 114 determines the current CAN peripheral currently connected to the UART interface 120, selects the first and second data conversion rules to determine the current data conversion rule corresponding to the current CAN peripheral, and converts the first data to the second data and the third data to the fourth data according to the current data conversion rule, thereby achieving accurate data conversion.

[0044] In order for the CAN driver 114 to identify the current CAN peripheral connected to the UART interface 120, a first peripheral identifier and a second peripheral identifier are pre-established for the first CAN peripheral and the second CAN peripheral, respectively. The first correspondence between the first CAN peripheral and the first data conversion rule, and the second correspondence between the second CAN peripheral and the second data conversion rule are stored in the CAN driver 114. Furthermore, after the user determines the current CAN peripheral connected to the UART interface 120, the current peripheral identifier corresponding to the current CAN peripheral is written into the Linux system 110. The CAN driver can then determine the current CAN peripheral corresponding to the current peripheral identifier by reading the current peripheral identifier written into the Linux system 110, and determine the current data conversion rule corresponding to the current CAN peripheral from the first and second correspondences stored in the CAN driver 114. Therefore, the data can be converted according to the current data conversion rule.

[0045] In this embodiment, by pre-storing the data conversion rules corresponding to all CAN peripherals that may be connected to the UART interface 120 in the CAN driver 114, when the CAN peripherals connected to the UART interface 120 change, there is no need to modify the driver code, recompile the kernel, or update the firmware. The CAN driver 114 only needs to dynamically match and call the corresponding conversion rules according to the identification information of the currently connected CAN peripherals, thereby achieving seamless compatibility and hot-swappable support for CAN peripherals of different models and protocols, and improving the scalability and maintenance convenience of the device.

[0046] The steps executed by CAN driver 114 will be further described below with reference to the accompanying drawings. Figure 3 A flowchart illustrating the steps of CAN driver execution provided in an embodiment of this application is shown. Figure 3 As shown, when application 111 sends data to the CAN peripheral, CAN driver 114 executes the following steps 210 to 260.

[0047] Step 210: Determine whether the data structure of the first data is a valid structure. If yes, proceed to step 230; otherwise, proceed to step 220.

[0048] The first data is the data to be sent from application 111. Since the data constructed by the application may have format errors or missing fields, the CAN driver 114 must first verify whether the data structure conforms to the definition specifications of the standard CAN frame in the kernel before performing any actual protocol conversion and transmission operations. If it is determined to be a valid structure, the data is allowed to proceed to the next step for protocol conversion; if it is determined to be an invalid structure, the data is discarded directly and an error message is returned to the application, thereby preventing invalid or illegal data from entering the subsequent processing flow and preventing invalid occupation of the UART interface 120 or causing underlying communication anomalies.

[0049] Step 220: Discard the first data.

[0050] If the first data structure is not a valid structure, the CAN driver 114 will refuse to process the data and discard it directly. At the same time, it will return an error status message to the application 111 (such as indicating that the data format is invalid or the parameters are incorrect) to notify the application 111 that the transmission has failed, thereby preventing invalid or illegal data from entering the subsequent protocol conversion and UART transmission process.

[0051] Step 230: Convert the first data into the second data, and perform CRC calculation on the second data to generate a CRC checksum.

[0052] If the data structure of the first data is valid, the first data of the CAN protocol is converted into the second data of the UART protocol. The second data is then calculated according to the Cyclic Redundancy Check (CRC) algorithm to generate the corresponding CRC check code. The CRC check code is then appended to the end of the data frame of the second data so that the CAN peripheral can determine the integrity and accuracy of the second data based on the CRC check code.

[0053] Step 240: Determine whether the current state of UART interface 120 is a state where data transmission is possible. If yes, proceed to step 260; otherwise, proceed to step 250.

[0054] Before transmitting the second data to the CAN peripheral, the CAN driver 114 needs to check whether the UART interface 120 is properly enabled and initialized (e.g., baud rate), and whether its transmit buffer has enough remaining space to accommodate the second data to be transmitted. If the UART interface 120 is disabled, suspended, or the transmit buffer is full, it is determined to be in a state where transmission is not possible; if the UART interface 120 is enabled and the transmit buffer is not full, it is determined to be in a state where data transmission is possible.

[0055] Step 250: Wake up the network queue.

[0056] If the UART interface 120 is currently in a non-transferable state (e.g., the transmit buffer is full or the device is not ready), the CAN driver 114 wakes up the network queue by performing this step so that subsequent applications can send data to the CAN peripheral.

[0057] Step 260: Transmit the second data and CRC check code together to the CAN peripheral through the tty subsystem 115, UART driver 116 and UART interface 120.

[0058] If the current state of the UART interface 120 is a state where data transmission is possible, the CAN driver 114 submits the combined data frame (including the second data after protocol conversion and the generated CRC checksum) to the tty subsystem 115. The tty subsystem 115 is responsible for the serial data scheduling and relay at the kernel level and transmits it to the UART driver 116. Finally, the UART driver 116 writes the data into the physical transmit buffer of the UART interface 120, converts it into a serial bit stream and sends it out through the physical line, thereby completing the final transmission of data to the CAN peripheral.

[0059] In some embodiments, if multi-threaded parallel data transmission is involved, to ensure that the second data can be transmitted to the CAN peripheral, preferably, during initialization, the CAN driver creates a data transmission lock for the device transmitting data between the UART interface and the CAN peripheral. This data transmission lock is a software synchronization mechanism defined and managed internally by the CAN driver, belonging to the driver software layer. It is used to perform exclusive access control of the UART interface in a multi-threaded concurrent environment to prevent data conflicts. Before executing step 210, the CAN driver 11 acquires the data transmission lock, first using the data transmission lock to lock the data transmission channel used for transmitting the second data, so as to write the second data into the UART buffer under exclusive access rights, and releases the data transmission lock after the second data transmission is completed. If the current data transmission lock is held by another thread, the thread requesting transmission enters a blocked state or spins and waits until the data transmission lock is released. Through the above settings, problems such as data interleaving, protocol frame corruption, or read / write conflicts of the underlying UART buffer caused by multi-threaded concurrent access can be effectively avoided, ensuring that each CAN data frame and its checksum can be transmitted atomically as a complete whole, thereby ensuring the reliability and consistency of data transmission.

[0060] Figure 4 A flowchart illustrating the steps of CAN driver execution according to another embodiment of this application is shown. Figure 4 As shown, when the CAN peripheral sends data to the application program 111, the CAN driver 114 executes the following steps 310 to 380.

[0061] Step 310: Determine whether the current state of UART interface 120 is a state where data transmission is possible. If yes, proceed to step 330; otherwise, proceed to step 320.

[0062] This step is the same as step 240. Therefore, the principle and specific implementation method of this step can be referred to step 240, and will not be repeated here.

[0063] Step 320: Cache configuration data.

[0064] If the current state of UART interface 120 is one where data transmission is not possible, configuration data is buffered. This configuration data refers to the initialization commands, operating mode settings (such as entering configuration mode or normal mode), baud rate parameters, filter settings, and other control parameters issued by the CAN driver 114 to the CAN peripheral before normal communication. It can also refer to query commands periodically sent by the device check thread. Since these configuration commands are usually initiated by the driver, if the UART interface is busy or not ready at this time, the configuration data needs to be temporarily stored in the transmit buffer queue. It will be retrieved and transmitted preferentially when the serial port status recovers, ensuring that the CAN peripheral can complete initialization or correctly respond to status queries in a timely manner, thus preparing for a stable CAN data reception process.

[0065] Step 330: Receive the third data and the first CRC checksum through the UART driver 116 and the tty subsystem 115.

[0066] The third data and the first CRC checksum are sent by the CAN peripheral.

[0067] Step 340: Verify if the third data is complete. If yes, proceed to step 360; otherwise, proceed to step 350.

[0068] The CAN driver 114 verifies the integrity of the third data according to the CAN protocol corresponding to the CAN peripheral. Specifically, the CAN driver 114 parses the third data to determine the frame header data and verifies its integrity based on the frame header data. The frame header data typically contains the length information or frame type identifier of the data frame. The CAN driver 114 extracts this length information, calculates the theoretical total length (or payload length) that the current protocol frame should have, and compares it with the actual length of the received third data. If they match, the received data frame is preliminarily determined to be structurally complete and untrunculated; if the actual length is less than the theoretical length, the data frame is determined to be incomplete. Only after the frame header data verification is passed (i.e., the frame length is complete) will the CAN driver 114 further perform a CRC operation comparison on the third data and the first CRC checksum. Through this method, both the accuracy and integrity of the third data can be determined.

[0069] Step 350: Discard the data.

[0070] If the third data is incomplete, it means that the third data is invalid. In this case, proceed to this step to discard or delete the third data.

[0071] Step 360: Perform CRC calculation on the third data to generate a second CRC checksum.

[0072] If the third data is complete, then the third data is calculated according to the CRC algorithm to generate the corresponding second CRC check code.

[0073] Step 370: Determine whether the second CRC checksum and the first CRC checksum are consistent. If yes, proceed to step 380; otherwise, proceed to step 350.

[0074] Specifically, by determining whether the second CRC checksum and the first CRC checksum are consistent, it is possible to determine whether a bit error or data loss occurred during the transmission of the third data to the CAN driver via the UART interface. If they are consistent, it indicates that the received serial data frame is intact and can proceed to step 380 for subsequent protocol parsing and reporting. If they are inconsistent, it indicates that the data has been interfered with or truncated on the physical transmission link, and the data has been corrupted. In this case, it proceeds to step 350 to process it as invalid data, thereby preventing erroneous or incomplete instructions from being misread by the upper-layer application.

[0075] Step 380: Convert the third data into fourth data and transmit the fourth data to the application program 111 via the CAN subsystem 113.

[0076] The third data is a serial data frame format conforming to the CAN peripheral's private communication protocol, and the fourth data is the CAN frame structure of the Linux kernel standard. The CAN driver 114 reverse-parses and remaps the identifier, frame type, and data payload fields in the third data according to the data conversion rules corresponding to the current CAN peripheral, encapsulates them into the fourth data of the CAN protocol, and calls the standard interface provided by the CAN subsystem 113 to inject the socket buffer (skb) carrying the fourth data into the Linux network protocol stack. Finally, the fourth data is transmitted to the application program 111 in the form of a CAN socket (Socket CAN), thus completing the complete data reception process from the CAN peripheral to the application program.

[0077] In some embodiments, if multi-threaded parallel data transmission is involved, to ensure that the fourth data can be transmitted to the application, preferably, during initialization, the CAN driver creates a data receive lock, which is similar to the data transmit lock mentioned above. Before executing step 310, the CAN driver 114 first uses the data receive lock to lock the data transmission channel used for transmitting the fourth data, and releases the data receive lock after the application 111 receives the fourth data. Through the above settings, the problems of interleaving, overwriting, or protocol parsing errors caused by multiple receiving threads or interrupt handlers concurrently accessing the underlying UART interface and shared receive buffer can be avoided. At the same time, during the process of assembling the fourth data into a standard CAN frame and submitting it to the CAN subsystem 113, the locking operation ensures the atomicity of core data structures such as the socket buffer (skb), preventing concurrent enqueueing from causing kernel state chaos, thereby ensuring the stability and reliability of the entire data link from serial port reading and protocol parsing to application layer reception.

[0078] In the several embodiments provided in this application, any function, if implemented as a software functional module / unit and sold or used as an independent product, can be stored in a computer-readable storage medium. Based on this understanding, all or part of the technical solution of this application can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or other electronic device) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing computer program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0079] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system, or other device. Various general-purpose systems can also be used in conjunction with the teachings herein. The required structure for constructing such systems is apparent from the above description. Furthermore, the embodiments of this application are not directed to any particular programming language. It should be understood that the content of this application described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing the best mode of implementation of this application.

[0080] It should be noted that the above embodiments are illustrative of this application and not restrictive, and those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. This application can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In claims enumerating several means, several units or modules of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be construed as limiting the order of execution.

[0081] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A device for transmitting data between a UART interface and a CAN peripheral, characterized in that, The device includes: The motherboard is equipped with a UART interface, which is used to connect CAN peripherals. The Linux system running on the motherboard includes a CAN subsystem, a CAN driver, a tty subsystem, and a UART driver. The CAN driver is communicatively connected to both the CAN subsystem and the tty subsystem, and is used for: The system receives first data in the CAN protocol from the CAN subsystem, converts the first data into second data in the UART protocol, and transmits the second data to the tty subsystem, so that the second data can be transmitted to the CAN peripheral via the UART interface through the tty subsystem and the UART driver; and The system receives third data from the UART protocol from the tty subsystem, converts the third data into fourth data from the CAN protocol, and transmits the fourth data to the application program of the Linux system through the CAN subsystem.

2. The device according to claim 1, characterized in that, The CAN driver stores data conversion rules corresponding to the CAN peripheral. The CAN driver is specifically used to convert the first data into the second data according to the data conversion rule, and to convert the third data into the fourth data according to the data conversion rule.

3. The device according to claim 1, characterized in that, The CAN peripheral is either a first CAN peripheral or a second CAN peripheral; the UART interface is used to connect to the first CAN peripheral or the second CAN peripheral; the CAN driver stores a first data conversion rule corresponding to the first CAN peripheral and a second data conversion rule corresponding to the second CAN peripheral. The CAN driver is specifically used to: determine the current CAN peripheral currently connected to the UART interface, determine the current data conversion rule corresponding to the current CAN peripheral from the first data conversion rule and the second data conversion rule, convert the first data into the second data according to the current data conversion rule, and convert the third data into the fourth data.

4. The device according to claim 3, characterized in that, The first CAN peripheral and the second CAN peripheral correspond to the first peripheral identifier and the second peripheral identifier, respectively. The Linux system is configured to store only the current peripheral identifier corresponding to the current CAN peripheral. The CAN driver is specifically used to determine the current CAN peripheral through the current peripheral identifier.

5. The device according to claim 1, characterized in that, The Linux system stores a data table, which includes the driver identifier and initialization information corresponding to the CAN driver. The Linux system is used to scan the data table at startup, start the CAN driver corresponding to the driver identifier, and initialize the CAN driver according to the initialization information.

6. The device according to claim 1, characterized in that, The CAN driver is also used for: Determine whether the data structure of the first data is a valid structure; If the data structure of the first data is a valid structure, then the first data is converted into the second data, and CRC calculation is performed on the second data to generate a CRC checksum. Determine whether the current state of the UART interface is a state where data transmission is possible; If the current state of the UART interface is one in which data transmission is possible, then the second data and the CRC checksum are transmitted together to the CAN peripheral through the tty subsystem, the UART driver, and the UART interface.

7. The device according to claim 6, characterized in that, The CAN driver is also used to lock the data transmission channel for transmitting the second data using a data transmission lock before determining whether the data structure of the first data is a valid structure, and to release the data transmission lock after the second data transmission is completed.

8. The device according to claim 1, characterized in that, The CAN driver is also used for: Determine whether the current state of the UART interface is a state where data transmission is possible; If the current state of the UART interface is a state where data transmission is possible, then the third data and the first CRC checksum are received through the UART driver and the tty subsystem. Verify the integrity of the third data; If the third data is complete, then a CRC calculation is performed on the third data to generate a second CRC checksum; If the second CRC checksum matches the first CRC checksum, the third data is converted into the fourth data, and the fourth data is transmitted to the application through the CAN subsystem.

9. The device according to claim 8, characterized in that, The CAN driver is specifically used to parse the third data, determine the frame header data of the third data, and verify the integrity of the third data based on the frame header data.

10. The device according to claim 8, characterized in that, The CAN driver is also used to lock the data transmission channel for transmitting the fourth data using a data receive lock before determining whether the current state of the UART interface is a state where data transmission is possible, and to release the data receive lock after the application receives the fourth data.

Images