Socket CAN communication system based on miniPCIe interface and control method
The SocketCAN communication system based on the miniPCIe interface achieves seamless integration between the miniPCIe-USB interface CAN hardware module and SocketCAN, solving the problems of unstable hardware adaptation and multi-node communication in embedded devices, and providing a plug-and-play, stable and reliable CAN communication solution.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-01-09
- Publication Date
- 2026-03-24
AI Technical Summary
Existing technologies cannot achieve seamless integration between the miniPCIe interface and the Linux native SocketCAN protocol stack in embedded devices, resulting in high development and deployment costs for users, unstable hardware adaptation, and inability to meet the needs of miniaturization and multi-node communication.
Design a SocketCAN communication system based on the miniPCIe interface, including a miniPCIe-USB interface CAN hardware module, a SocketCAN driver module, and a SocketCAN protocol stack interaction module. Through the collaborative work of these modules, real-time conversion of USB format CAN data and seamless connection with the standard SocketCAN network interface can be achieved.
It achieves seamless automatic docking between miniPCIe-USB interface CAN hardware modules and SocketCAN, providing a plug-and-play, stable, reliable, and highly expandable CAN communication solution to meet the "integrated, miniaturized, and multi-node communication" requirements of embedded devices.
Smart Images
Figure CN121722705A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of bus communication technology, specifically relating to a SocketCAN communication system and control method based on the miniPCIe interface. Background Technology
[0002] With the increasing demand for "real-time and highly reliable data transmission" in fields such as industrial automation and intelligent vehicles, CAN bus has become the core communication bus technology for such scenarios due to its characteristics such as multi-node communication, strong error detection capability, and excellent anti-interference ability.
[0003] In embedded Linux devices (such as industrial control hosts, vehicle controllers, and edge computing gateways), to expand CAN communication functions, the miniPCIe interface, with its advantages of "only 1 / 4 the size of standard PCIe, supporting onboard integration, and low power consumption", is gradually replacing traditional PCIe or USB external interfaces and becoming the mainstream hardware form for expanding CAN modules in embedded devices.
[0004] Existing technologies for extending CAN functionality in embedded Linux devices can be mainly divided into three categories: (1) Traditional miniPCIe CAN device solution This solution is currently the mainstream choice. The hardware adopts a miniPCIe physical interface and integrates a CAN controller (such as SJA1000, MCP2515) and a CAN transceiver (such as TJA1050). The communication protocol and driver adaptation are divided into two paths: Path 1: Based on a custom USB protocol. To reduce costs, most manufacturers multiplex the communication signals of the miniPCIe interface into a USB 2.0 bus (not native PCIe signals), but use a manufacturer-defined USB-CAN data interaction protocol (such as proprietary frame formats and instruction sets). This requires the manufacturer's proprietary SDK, and users need to write drivers or application code based on the SDK to implement CAN data transmission and reception; it cannot directly interface with the Linux native SocketCAN protocol stack.
[0005] Path 2: Partial support for SocketCAN, but manual configuration is required. A few high-end devices claim to support SocketCAN, but users need to manually set parameters such as the USB port number (e.g., / dev / ttyUSBx), CAN controller model, baud rate (e.g., 500kbps), and frame format (standard frame / extended frame) via command line or configuration file. The configuration process requires familiarity with Linux kernel driver logic, and it is difficult for non-professional users to deploy quickly.
[0006] (2) Standard PCIe CAN card solution For non-embedded scenarios such as industrial servers, existing standard PCIe interface CAN expansion cards integrate multi-channel CAN controllers, support direct interface with the Linux native SocketCAN protocol stack, and are compatible with common tools such as can-utils. However, this solution has significant limitations: large hardware size (standard PCIe card size is approximately 100mm × 60mm), making it unsuitable for miniaturized embedded device enclosures; and high power consumption (typically 5-10W), failing to meet the "low power consumption" requirements of embedded devices and making it difficult to apply to scenarios such as automotive and portable industrial control.
[0007] (3) External USB to CAN device solution External CAN converters that connect to embedded Linux devices via a USB-A interface have a simple hardware structure (including a CAN controller and a USB chip), and some products support SocketCAN. However, they have significant drawbacks: they require an additional USB port and rely on a USB cable connection, which can easily lead to poor contact and communication interruptions in the vibrating environments of vehicles or industrial settings; they lack hardware isolation design, making it easy for electromagnetic interference (EMI) from the CAN bus to be conducted to the host via the USB cable, causing Linux system crashes or data frame drops; and they cannot be integrated into embedded devices, requiring additional installation space, which does not meet the requirements of "integrated design".
[0008] Therefore, existing technical solutions have the technical problem of not being able to directly and automatically connect to the Linux native SocketCAN protocol stack to achieve CAN data transmission and reception while meeting the requirements of miniaturization and high reliability of embedded devices.
[0009] It should be noted that the information disclosed in this background section is only for understanding the background technology of this application concept, and therefore, the above description is not considered to constitute information related to the technology. Summary of the Invention
[0010] The purpose of this invention is to provide a SocketCAN communication system and control method based on the miniPCIe interface.
[0011] To address the aforementioned technical problems, this invention provides a SocketCAN communication system based on a miniPCIe interface, comprising: The miniPCIe-USB interface CAN hardware module is configured to establish communication with the Linux host after being connected to the Linux host via the USB bus. The SocketCAN driver module is configured to run at the kernel layer of the Linux host and drive the miniPCIe-USB interface CAN hardware module to output USB format CAN data according to control instructions from the external environment, and convert the USB format CAN data into a data structure conforming to the SocketCAN protocol stack in real time. The SocketCAN protocol stack interaction module is configured to send USB-formatted CAN data, which conforms to the SocketCAN protocol stack data structure and is output by the SocketCAN driver module, to the SocketCAN protocol stack of the Linux host, so that the miniPCIe-USB interface CAN hardware module can transmit and receive CAN data using the standard SocketCAN network interface.
[0012] In another aspect, the present invention also provides a control method based on the SocketCAN communication system as described above, comprising: After the miniPCIe-USB interface CAN hardware module is inserted into the miniPCIe slot of the Linux host, the SocketCAN driver module reads the PID / VID identifier of the miniPCIe-USB interface CAN hardware module, automatically identifies and loads the driver configuration and hardware parameter initialization for the miniPCIe-USB interface CAN hardware module. The SocketCAN driver module drives the miniPCIe-USB interface CAN hardware module to output USB format CAN data according to control commands from the external environment, and converts the USB format CAN data into a data structure that conforms to the SocketCAN protocol stack in real time. The SocketCAN protocol stack interaction module sends the USB format CAN data output by the SocketCAN driver module, which conforms to the SocketCAN protocol stack data structure, to the SocketCAN protocol stack of the Linux host, enabling the miniPCIe-USB interface CAN hardware module to transmit and receive CAN data using the standard SocketCAN network interface.
[0013] Thirdly, the present invention also provides a Linux host, comprising: The SocketCAN driver module is configured to run at the kernel layer of the Linux host, drive a CAN device to output USB-formatted CAN data according to control instructions from the external environment, and convert the USB-formatted CAN data into a data structure conforming to the SocketCAN protocol stack in real time. The SocketCAN protocol stack interaction module is configured to send the data converted by the SocketCAN driver module to the SocketCAN protocol stack of the Linux host, so that the CAN device can transmit and receive CAN data using the standard SocketCAN network interface.
[0014] Fourthly, the present invention also provides a CAN communication device, which is connected to the Linux host as described above, and includes: CAN controller; The miniPCIe physical interface is configured to be electrically connected to the CAN controller; The USB 2.0 bus interface is configured to be electrically connected to the CAN controller and to establish a USB communication connection with the Linux host. An electrical isolation unit is configured to connect to the CAN controller to isolate CAN bus interference; and A CAN bus transceiver is configured to connect to the electrical isolation unit and is used for transmitting and receiving CAN data.
[0015] The beneficial effects of this invention are that the SocketCAN communication system based on the miniPCIe interface works collaboratively through the miniPCIe-USB interface CAN hardware module, the SocketCAN driver module, and the SocketCAN protocol stack interaction module. The SocketCAN driver module converts the USB-format CAN data output by the miniPCIe-USB interface CAN hardware module into a data structure conforming to the SocketCAN protocol stack, achieving seamless automatic interfacing between the miniPCIe-USB interface and SocketCAN. This enables the miniPCIe-USB interface CAN hardware module to transmit and receive CAN data using the standard SocketCAN network interface. This provides a "plug-and-play, stable, reliable, and highly expandable" CAN communication solution for embedded Linux devices in industrial automation and intelligent vehicle applications, meeting the "integrated, miniaturized, and multi-node communication" requirements of embedded devices.
[0016] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained through the structures particularly pointed out in the description and the drawings.
[0017] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description
[0018] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.
[0019] Figure 1 A block diagram illustrating the principle of a SocketCAN communication system based on a miniPCIe interface, as shown in some embodiments, is presented. Figure 2 The diagram illustrates the steps of a control method for a SocketCAN communication system according to some embodiments; Figure 3 A block diagram illustrating the principles of a Linux host in some embodiments is shown; Figure 4 A schematic block diagram of a CAN communication device involved in some embodiments is shown. Detailed Implementation
[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0021] Definitions of abbreviations and key terms involved in this embodiment: SocketCAN: The Linux built-in CAN bus driver framework, which abstracts CAN communication through a network interface, supports the standard Socket API and can-utils tools, and is the core foundation of CAN "network-like" communication; CAN MAC: CAN controller, responsible for core data link layer processing (frame assembly / parsing, arbitration, error detection, filter configuration), connecting the CAN protocol stack and the physical layer; CAN PHY: CAN transceiver, which realizes physical layer signal conversion (digital signal ↔ CAN differential signal); miniPCIe-USB interface: An expansion interface based on the miniPCIe physical form, which reuses USB bus signals; PID / VID: Unique identifier for USB devices (product identification code / manufacturer identification code).
[0022] In embedded Linux devices (such as industrial control hosts, vehicle controllers, and edge computing gateways), to expand CAN communication functions, the miniPCIe interface, with its advantages of "only 1 / 4 the size of standard PCIe, supporting onboard integration, and low power consumption", is gradually replacing traditional PCIe or USB external interfaces and becoming the mainstream hardware form for expanding CAN modules in embedded devices.
[0023] However, the existing technical solutions have the following problems: Poor SocketCAN compatibility: Traditional miniPCIe CAN devices rely on custom protocols or manual configuration, which cannot achieve "seamless integration" with the Linux native SocketCAN protocol stack, increasing user development and deployment costs; Lack of support for common tools: Most solutions are incompatible with industry-standard tools such as can-utils (e.g., cansend, candump) and CANoe lightweight version, requiring the development of dedicated test programs and extending the project debugging cycle; Insufficient hardware feature adaptation: Existing SocketCAN technology (such as the can-usb driver in the Linux kernel) is only designed for standard PCIe or general USB devices and does not take into account the unique hardware features of the miniPCIe USB interface (such as pin definitions, USB bus communication timing, and onboard power supply specifications), resulting in unstable driver loading and high data transmission latency (≥5ms). Weak scalability and integration: Traditional solutions are either too bulky or rely on external cables, failing to meet the needs of embedded devices for "miniaturization, integration, and multi-channel expansion" (such as simultaneous communication of 4 CAN channels).
[0024] The defects in the above solutions and the reasons for their occurrence are the results of the inventors' practice and careful research. Therefore, the discovery process of the above problems and the solutions proposed in this disclosure should be considered as the inventors' contributions to this disclosure.
[0025] Therefore, at least one embodiment provides a SocketCAN communication system based on a miniPCIe interface, comprising: a miniPCIe-USB interface CAN hardware module configured to establish communication with a Linux host after being connected to a Linux host via a USB bus; a SocketCAN driver module configured to run at the kernel layer of the Linux host, for driving the miniPCIe-USB interface CAN hardware module to output USB-format CAN data according to control instructions from an external environment, and converting the USB-format CAN data into a data structure conforming to the SocketCAN protocol stack in real time; and a SocketCAN protocol stack interaction module configured to send the USB-format CAN data output by the SocketCAN driver module conforming to the SocketCAN protocol stack data structure to the SocketCAN protocol stack of the Linux host, enabling the miniPCIe-USB interface CAN hardware module to transmit and receive CAN data using a standard SocketCAN network interface.
[0026] This embodiment of the SocketCAN communication system based on the miniPCIe interface works collaboratively through a miniPCIe-USB interface CAN hardware module, a SocketCAN driver module, and a SocketCAN protocol stack interaction module. The SocketCAN driver module converts the USB-format CAN data output by the miniPCIe-USB interface CAN hardware module into a data structure conforming to the SocketCAN protocol stack, achieving seamless automatic interfacing between the miniPCIe-USB interface and SocketCAN. This enables the miniPCIe-USB interface CAN hardware module to transmit and receive CAN data using the standard SocketCAN network interface. This provides a "plug-and-play, stable, reliable, and highly expandable" CAN communication solution for embedded Linux devices in industrial automation and intelligent vehicle applications, meeting the "integrated, miniaturized, and multi-node communication" requirements of embedded devices.
[0027] The various non-limiting embodiments of the present disclosure will now be described in detail with reference to the accompanying drawings.
[0028] like Figure 1 As shown, this embodiment provides a SocketCAN communication system based on the miniPCIe interface, including: The miniPCIe-USB interface CAN hardware module is configured to establish communication with the Linux host after being connected to the Linux host via the USB bus. The SocketCAN driver module is configured to run at the kernel layer of the Linux host and drive the miniPCIe-USB interface CAN hardware module to output USB format CAN data according to control instructions from the external environment, and convert the USB format CAN data into a data structure conforming to the SocketCAN protocol stack in real time. The SocketCAN protocol stack interaction module is configured to send USB-formatted CAN data, which conforms to the SocketCAN protocol stack data structure and is output by the SocketCAN driver module, to the SocketCAN protocol stack of the Linux host, so that the miniPCIe-USB interface CAN hardware module can transmit and receive CAN data using the standard SocketCAN network interface.
[0029] In some embodiments, the miniPCIe-USB interface CAN hardware module includes: a CAN controller; a miniPCIe physical interface configured to be electrically connected to the CAN controller; a USB 2.0 bus interface configured to be electrically connected to the CAN controller and to establish a USB communication connection with the Linux host; an electrical isolation unit configured to be connected to the CAN controller to isolate CAN bus interference; and a CAN bus transceiver configured to be connected to the electrical isolation unit and used for transmitting and receiving CAN data.
[0030] Specifically, the CAN controller supports CAN 2.0A / B and CAN FD protocols. The miniPCIe physical interface uses a standard 52-pin Mini PCI Express physical connector (51mm x 30mm), and multiplexes the USB data pins (DP / DM) in the interface as a USB 2.0 bus. This design allows it to be compatible with miniPCIe slots in a wide range of embedded devices while communicating via the USB protocol.
[0031] An electrical isolation unit is installed between the CAN controller and the CAN bus transceiver to achieve complete isolation between signals and power. Its isolation withstand voltage is ≥2500Vrms, effectively blocking common-mode interference, surges, and ground potential differences from the CAN bus in harsh environments such as industrial and automotive settings, thus protecting the Linux host system.
[0032] CAN bus transceiver: Connected after the isolation unit, it is used to adapt to the physical level of the CAN bus (ISO11898-2 standard) and provide differential transmission and reception capabilities for the bus.
[0033] Specifically, the miniPCIe-USB interface CAN hardware module has a unique USB vendor identifier (VID) and product identifier (PID) embedded in its firmware, which are used by the host-side SocketCAN driver module for accurate identification.
[0034] Specifically, the miniPCIe-USB interface CAN hardware module supports baud rate adaptation from 125kbps to 8Mbps, and the SocketCAN driver module can automatically adjust the baud rate of the miniPCIe-USB interface CAN hardware module according to the baud rate instructions of the SocketCAN protocol stack.
[0035] In some embodiments, the control commands from the external environment include: control commands invoked by the standard SocketCAN API or control commands sent by a general SocketCAN tool; the SocketCAN protocol stack interaction module is adapted to pass the control commands invoked by the standard SocketCAN API to the SocketCAN driver module; and the SocketCAN driver module is adapted to parse and adapt the control commands sent by the general SocketCAN tool.
[0036] In some embodiments, the SocketCAN driver module includes: a hardware identification submodule configured to scan the USB bus, automatically identify and load driver configuration for the miniPCIe-USB interface CAN hardware module by matching the PID / VID identifier embedded in the miniPCIe-USB interface CAN hardware module; a protocol mapping submodule configured to convert the USB format CAN data output by the miniPCIe-USB interface CAN hardware module into a data structure conforming to the SocketCAN protocol stack in real time; and a tool adaptation submodule configured to parse and adapt control commands sent by a general SocketCAN tool.
[0037] In some embodiments, the hardware identification submodule has a built-in PID / VID identifier whitelist. When the hardware identification submodule detects that the PID / VID identifier fixed by the miniPCIe-USB interface CAN hardware module is not in the built-in PID / VID identifier whitelist, it stops loading the driver configuration for the miniPCIe-USB interface CAN hardware module, so that the Linux host only matches the customized miniPCIe-USB interface CAN hardware module and avoids conflicts with other USB device drivers.
[0038] Specifically, the protocol mapping submodule converts the USB-formatted CAN data output by the miniPCIe-USB interface CAN hardware module into a "can_frame" data structure conforming to the SocketCAN protocol stack in real time.
[0039] Specifically, the tool adapter submodule supports instruction parsing for general SocketCAN tools (such as can-utils and CANoe lightweight version), ensuring that the tool can directly control the miniPCIe-USB interface CAN hardware module. The SocketCAN driver module supports hot-swapping; after the miniPCIe-USB interface CAN hardware module is plugged in or out, it automatically re-identifies and restores the SocketCAN interface without requiring a Linux host restart.
[0040] In some embodiments, the control instructions parsed and adapted by the tool adaptation submodule include one or more of the following: message sending, message receiving, bus load testing, and error frame detection instructions.
[0041] In some embodiments, the standard SocketCAN network interface includes a standard network interface of type can0 or can1.
[0042] like Figure 2 As shown, some embodiments also provide a control method for a SocketCAN communication system, including: Step S101: After the miniPCIe-USB interface CAN hardware module is inserted into the miniPCIe slot of the Linux host, the SocketCAN driver module reads the PID / VID identifier of the miniPCIe-USB interface CAN hardware module, automatically identifies and loads the driver configuration and hardware parameter initialization for the miniPCIe-USB interface CAN hardware module. Step S102: The SocketCAN driver module drives the miniPCIe-USB interface CAN hardware module to output USB format CAN data according to the control instructions from the external environment, and converts the USB format CAN data into a data structure that conforms to the SocketCAN protocol stack in real time. Step S103: The USB format CAN data output by the SocketCAN driver module, conforming to the SocketCAN protocol stack data structure, is sent to the SocketCAN protocol stack of the Linux host through the SocketCAN protocol stack interaction module, so that the miniPCIe-USB interface CAN hardware module can transmit and receive CAN data using the standard SocketCAN network interface.
[0043] In some embodiments, the hardware parameter initialization includes at least the initialization of baud rate, frame format, and signal isolation level.
[0044] In some embodiments, the control method further includes: The SocketCAN driver module monitors the working status of the miniPCIe-USB interface CAN hardware module in real time and performs verification and error detection on the transmitted and received CAN data frames.
[0045] In some embodiments, the operating state includes at least the USB connection state and the CAN bus load rate.
[0046] Specifically, the miniPCIe USB interface CAN hardware module is inserted into the miniPCIe slot of the Linux host, and the system automatically detects the USB bus device; the user installs a customized SocketCAN driver module, which reads the PID / VID of the miniPCIe USB interface CAN hardware module through the hardware identification submodule, and automatically completes the loading of the driver kernel and the initialization of hardware parameters (such as baud rate, frame format, signal isolation level).
[0047] After the SocketCAN driver module is installed, a standard SocketCAN network interface (such as "can0") is automatically created on the Linux host. Users can activate the created standard SocketCAN network interface by using the command "ip link set can0 up type can bitrate 500000", without having to manually configure USB communication parameters or CAN controller registers.
[0048] Users can control the miniPCIe USB interface CAN hardware module to transmit and receive CAN data in two ways: Method 1: Write an application by calling the standard SocketCAN API (such as socket(), bind(), sendto(), recvfrom()). The standard SocketCAN API commands are passed to the SocketCAN driver module through the SocketCAN protocol stack interaction module to drive and control the miniPCIe USB interface CAN hardware module to complete the transmission and reception of CAN data.
[0049] Method 2: Directly use a general SocketCAN tool (such as can-utils) to send CAN messages via the command "cansend can00x123#11223344" and receive CAN data via the command "candump can0". The tool commands are parsed by the driver tool adapter submodule and then executed by the miniPCIe USB interface CAN hardware module.
[0050] The SocketCAN driver module monitors the working status of the miniPCIe USB interface CAN hardware module in real time (such as USB connection status and CAN bus load rate), performs CRC check and bit error detection on the transmitted and received CAN data frames, and feeds back the check results to the user through the "ip -s link show can0" command.
[0051] The general SocketCAN tool commands include, but are not limited to, message sending (cansend), message receiving (candump), bus load testing (canbusload), and error frame detection (canecho). The tool operation response latency is ≤1ms, and it is compatible with tools that use the native SocketCAN hardware interface.
[0052] For details regarding the specific implementation functions of the miniPCIe USB interface CAN hardware module, SocketCAN driver module, and SocketCAN protocol stack interaction module, please refer to the aforementioned content on the SocketCAN communication system based on the miniPCIe interface, which will not be repeated here.
[0053] like Figure 3 Some embodiments also provide a Linux host, including: a SocketCAN driver module configured to run at the kernel layer of the Linux host, for driving a CAN device to output USB-formatted CAN data according to control instructions from an external environment, and converting the USB-formatted CAN data into a data structure conforming to the SocketCAN protocol stack in real time; and a SocketCAN protocol stack interaction module configured to send the data converted by the SocketCAN driver module to the SocketCAN protocol stack of the Linux host, enabling the CAN device to transmit and receive CAN data using a standard SocketCAN network interface.
[0054] like Figure 4As shown, some embodiments also provide a CAN communication device connected to the Linux host as described above, and including: a CAN controller; a miniPCIe physical interface configured to be electrically connected to the CAN controller; a USB 2.0 bus interface configured to be electrically connected to the CAN controller and to establish a USB communication connection with the Linux host; an electrical isolation unit configured to be connected to the CAN controller to isolate CAN bus interference; and a CAN bus transceiver configured to be connected to the electrical isolation unit and used for transmitting and receiving CAN data.
[0055] For details on the structure, function, or working principle of each part in the CAN communication device, please refer to the aforementioned content on the miniPCIe-USB interface CAN hardware module, which will not be repeated here.
[0056] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative; for example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.
[0057] In addition, the functional modules in the various embodiments of the present invention can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.
[0058] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a part of the technical solution, 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, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.
[0059] Based on the above-described preferred embodiments of the present invention, and through the foregoing description, those skilled in the art can make various changes and modifications without departing from the inventive concept. The technical scope of this invention is not limited to the contents of the specification, but must be determined according to the scope of the claims.
Claims
1. A SocketCAN communication system based on a miniPCIe interface, characterized in that, include: The miniPCIe-USB interface CAN hardware module is configured to establish communication with the Linux host after being connected to the Linux host via the USB bus. The SocketCAN driver module is configured to run at the kernel layer of the Linux host and drive the miniPCIe-USB interface CAN hardware module to output USB format CAN data according to control instructions from the external environment, and convert the USB format CAN data into a data structure conforming to the SocketCAN protocol stack in real time. The SocketCAN protocol stack interaction module is configured to send USB-formatted CAN data, which conforms to the SocketCAN protocol stack data structure and is output by the SocketCAN driver module, to the SocketCAN protocol stack of the Linux host, so that the miniPCIe-USB interface CAN hardware module can transmit and receive CAN data using the standard SocketCAN network interface.
2. The SocketCAN communication system according to claim 1, characterized in that, The control commands from the external environment include: control commands invoked by the standard SocketCAN API or control commands sent by general SocketCAN tools; The SocketCAN protocol stack interaction module is adapted to transmit control commands for calling the standard SocketCAN API to the SocketCAN driver module; and The SocketCAN driver module is adapted to parse and adapt control commands sent by general SocketCAN tools.
3. The SocketCAN communication system according to claim 1, characterized in that, The SocketCAN driver module includes: The hardware identification submodule is configured to scan the USB bus and automatically identify and load the driver configuration for the miniPCIe-USB interface CAN hardware module by matching the PID / VID identifier embedded in the miniPCIe-USB interface CAN hardware module. The protocol mapping submodule is configured to convert the USB format CAN data output by the miniPCIe-USB interface CAN hardware module into a data structure conforming to the SocketCAN protocol stack in real time. The tool adaptation submodule is configured to parse and adapt control commands sent by the general SocketCAN tool.
4. The SocketCAN communication system according to claim 3, characterized in that, The hardware identification submodule has a built-in PID / VID identifier whitelist; When the hardware identification submodule detects that the PID / VID identifier embedded in the miniPCIe-USB interface CAN hardware module is not in the built-in PID / VID identifier whitelist, it stops loading the driver configuration for the miniPCIe-USB interface CAN hardware module.
5. The SocketCAN communication system according to claim 3, characterized in that, The control commands parsed and adapted by the tool adaptation submodule include one or more of the following: message sending, message receiving, bus load testing, and error frame detection commands.
6. The SocketCAN communication system according to claim 1, characterized in that, The standard SocketCAN network interface includes a standard network interface of type can0 or can1.
7. A control method based on the SocketCAN communication system according to any one of claims 1-6, characterized in that, include: After the miniPCIe-USB interface CAN hardware module is inserted into the miniPCIe slot of the Linux host, the SocketCAN driver module reads the PID / VID identifier of the miniPCIe-USB interface CAN hardware module, automatically identifies and loads the driver configuration and hardware parameter initialization for the miniPCIe-USB interface CAN hardware module. The SocketCAN driver module drives the miniPCIe-USB interface CAN hardware module to output USB format CAN data according to control commands from the external environment, and converts the USB format CAN data into a data structure that conforms to the SocketCAN protocol stack in real time. The SocketCAN protocol stack interaction module sends the USB format CAN data output by the SocketCAN driver module, which conforms to the SocketCAN protocol stack data structure, to the SocketCAN protocol stack of the Linux host, enabling the miniPCIe-USB interface CAN hardware module to transmit and receive CAN data using the standard SocketCAN network interface.
8. The control method according to claim 7, characterized in that, The hardware parameter initialization includes at least the initialization of baud rate, frame format, and signal isolation level.
9. The control method according to claim 7, characterized in that, Also includes: The SocketCAN driver module monitors the working status of the miniPCIe-USB interface CAN hardware module in real time and performs verification and error detection on the transmitted and received CAN data frames.
10. The control method according to claim 9, characterized in that, The operating status includes at least the USB connection status and the CAN bus load rate.
11. A Linux host, characterized in that, include: The SocketCAN driver module is configured to run at the kernel layer of the Linux host, drive a CAN device to output USB-formatted CAN data according to control instructions from the external environment, and convert the USB-formatted CAN data into a data structure conforming to the SocketCAN protocol stack in real time. The SocketCAN protocol stack interaction module is configured to send the data converted by the SocketCAN driver module to the SocketCAN protocol stack of the Linux host, so that the CAN device can transmit and receive CAN data using the standard SocketCAN network interface.
12. A CAN communication device, characterized in that, The CAN communication device is connected to the Linux host as described in claim 11, and includes: CAN controller; The miniPCIe physical interface is configured to be electrically connected to the CAN controller; The USB 2.0 bus interface is configured to be electrically connected to the CAN controller and to establish a USB communication connection with the Linux host. An electrical isolation unit is configured to connect to the CAN controller to isolate CAN bus interference; and A CAN bus transceiver is configured to connect to the electrical isolation unit and is used for transmitting and receiving CAN data.