Controller Area Network (CAN) was first developed by Bosch in Germany and became an international standard (ISO 11898). Due to its advantages such as flexibility, reliability, real-time performance, good openness, and strong error correction capabilities, the CAN bus has become one of the most promising fieldbuses. However, everything has two sides, and the CAN bus also has its shortcomings. Its limited transceiver drive capability restricts the maximum number of nodes that can be connected on the bus and the maximum direct transmission distance, making remote control impossible. This imposes certain constraints on system networking. In contrast, Ethernet, with its low cost, ease of networking, support from numerous application hardware and software, and continuous improvement based on actual network needs, has gradually developed into standard Ethernet (10 Mbit/s), Fast Ethernet (100 Mbit/s), Gigabit Ethernet, and 10 Gigabit Ethernet, becoming the most widely used local area network technology. Interconnecting Ethernet and CAN bus can reduce costs, increase the maximum number of CAN nodes in the system, expand the system's networking range, and enable communication between fieldbus subnets with different transmission speeds, as well as the integration of the device layer to the management layer. Therefore, this paper proposes a communication gateway design scheme that interconnects Ethernet and CAN bus.
1 Hardware Design
Figure 1 shows the overall block diagram of the design and implementation of this gateway module. The gateway module uses LPC2294 as the main controller and μC/OS-II operating system as the platform. It expands two network card interfaces and CAN interface, and completes the mutual conversion between CAN bus protocol and Ethernet protocol through software design, and finally realizes dual redundant communication between CAN network and Ethernet.
The hardware circuit can be divided into five parts: control circuit, storage circuit, auxiliary circuit, Ethernet interface circuit, and CAN bus interface circuit. The following analysis mainly focuses on the control circuit, Ethernet interface circuit, and CAN bus interface circuit.
1.1 System Controller
The system uses the ARM processor LPC2294 as the control chip, primarily due to its powerful functionality, low power consumption, and abundant on-chip resources. More importantly, it integrates four CAN controllers supporting the CAN 2.0B protocol and includes an advanced acceptance filter, enhancing system integration, complexity, and stability. To meet the system's program and data storage needs, a 1MB 16-bit Flash chip, SST39VF160, is externally used to store program code. The Flash address lines A1-A20 are connected to the LPC2294's A1-A20 terminals. Data lines ED0-ED15 are connected to the LPC2294's DQ0-DQ15 terminals via a dual-powered bidirectional transceiver. CE# is connected to the LPC2294's CS0 terminal and assigned to Bank0, with an address range of 0x80000000 to 0x80001000. OE# and OW# are connected to the LPC2294's OE# and WE# terminals, respectively. Simultaneously, a 1MB 16-bit SRAM memory IS61LV25616AL is externally connected for stack and data storage. The SRAM address lines A1-A20 are connected to A0-A19 of the LPC2294, and the data lines IO0-IO15 are connected to D0-D15 of the LPC2294 via a dual-powered bidirectional transceiver. CE# is connected to CS1 of the LPC2294 and assigned to Bank1, with an address range of 0x81000030-0x81001000. LB# and UB are connected to BLS0 and BLS1 respectively, used to control 8-bit or 16-bit read/write data. OE# and OW# are connected to OE# and WE# of the LC2294 respectively.
1.2 CAN Interface Circuit Design
The system has two CAN interfaces, one main interface and the other a redundant interface, both connected to the same CAN network to increase system reliability. The CAN 2.0B controller is directly integrated into the LPC2294, eliminating the need for an external independent CAN controller. The LPC2294 integrates four CAN controllers; in this system, the first and second CAN interfaces are selected. The CAT8250T CAN transceiver is used, primarily to convert the CAN controller's logic levels to the CAN bus's differential levels. Unlike the commonly used TJA1050T CAN transceiver, this transceiver integrates CAN node transmission and reception with high-speed optocouplers and power isolation into a single circuit module, offering an isolation voltage up to DC2500V. It features a simple interface, ease of use, and overvoltage protection for the CAN bus. Additionally, a 120Ω resistor is connected in parallel between CANH and CANL and ground to match the transmission impedance, absorb bus echoes, and ensure low electromagnetic radiation and communication reliability.
1.3 Ethernet Interface Circuit Design
The system consists of a DM9000E Ethernet controller, an HR601860 network card transformer, and an RJ45 interface, forming the Ethernet interface circuit. Two network ports are selected: a primary port and a redundant port. The LPC2294 uses a 16-bit bus to control the DM9000E, operating it in 100MHz full-duplex mode. The selection of the two network ports is achieved by controlling the chip select signal of the primary port via the CS3 and A22 pins of the LPC2294. These two pins are connected to pins 1 and 2 of the 74AC32 microcontroller, while pin 3 is connected to the ANE pin of the primary port. Similarly, the CS3 and A23 pins of the LPC2294 are connected to the ANE pin of the redundant port via the 74AC32. Finally, the CMD pin of the DM9000E is connected to pin A2 of the LPC2294. The data port addresses and index port addresses of the main network and redundant network interface card (NIC) chips can be configured as 0x8380000, 0x83800004 and 0x83400000, 0x83400004, respectively. The physical layer transmit and receive ports TXO+, TXO-, RXI+, and RXI- of the DM9000E are connected to the RJ45 interface via the network transformer chip HR601680. The remaining pins of the DM9000E can be connected according to the instructions in the datasheet, as shown in Figure 2.
Finally, the DM9000E chip is driven. The chip driver is mainly completed in three parts: `voidInitNic()` is used to initialize the chip and configure on-chip registers; `voidSend_Packet(struct_pkst*TxdData)` is the data sending function, and `uint8Rec_Packet(uint8num)` is the data receiving function. Upper-layer protocols send Ethernet data frames by calling these two functions.
2 Software Design
2.1 Message Structure
The software design for CAN bus and Ethernet interconnection mainly includes extracting CAN data from Ethernet and converting CAN bus data into Ethernet data. The CAN message structure can be divided into two different frame formats, differing in the length of their identifiers: the standard frame has an 11-bit identifier, while the extended frame has a 29-bit identifier. This design uses the extended frame. When the gateway module receives a message from the CAN board, it needs to encapsulate and package the CAN data according to the aforementioned Ethernet data transmission message format and send it via Ethernet. During this process, it is unnecessary to perform high-low bit conversion and shifting on the 13-byte CAN message data; a transparent conversion method is used. This reduces data parsing and processing time and improves data reliability during transmission.
As shown in Figure 3, the Ethernet frame format specified in this gateway includes five parts, in the order of encapsulation: encapsulated data (such as CAN data frames in this system), a custom UDP header, a standard UDP/TCP header, an IP header, an Ethernet header, and a final checksum. This system primarily uses the UDP protocol to allow for the use of custom control words to distinguish different types of messages, including: CAN data messages, timing messages, operational status request messages, heartbeat messages, and device fault diagnosis information messages. The timing message is a time synchronization request sent by the system upon power-on or every 30 minutes. The operational status message is automatically sent after each device is powered on or reset and is operating normally, and is also sent upon receiving an inquiry message or upon a status change; it mainly sends the timestamp and device ID information. The heartbeat message is sent every 5 seconds after each device is powered on or reset and is operating normally, its purpose being to notify the network whether its operational status is normal. The device fault diagnosis information message is sent when a fault diagnosis request message is received, or when the gateway detects a change in the fault status of the CAN card within the gateway box based on the data reception status of the CAN card. Generally, if the gateway does not receive data and remote frames from the corresponding node of the CAN card specified in the parameter setting message within 30 minutes, it can determine that the node is faulty and send a fault information message. This adds some management information to the system, enabling different communication functions based on different message types. The custom UDP encapsulation format is shown in Figure 4.
In the custom UDP encapsulation format, bytes 0-3 are fixed frame header information used to identify the datagram information of this gateway module. This format is used for CAN messages, timing messages, and operational status request messages. Datagrams that do not conform to this frame header are not processed by the gateway module. It is important to note that the actual data begins from bit 20. Each information unit has its own sequence number, identifier, and length. The sequence number indicates the position of the information unit within the UDP datagram; the identifier represents the type of message within the information unit.
2.2 Programming
The main function of the gateway module is to convert between Ethernet data packets and CAN data frames, thereby enabling communication between Ethernet and CAN networks. This module uses the embedded μC/OS-II operating system, which has been customized and ported to run smoothly on the LPC2294 controller. Furthermore, core functions of the TCP/IP protocol have been ported to the system, and six task functions have been written to collaboratively implement the module's various functions. System resources are allocated through the task scheduling and management mechanism of the μC/OS-II system.
The system first establishes a device initialization task, Task0. This task function mainly performs power-on self-test, two-channel CAN fault self-test, network port disconnection detection, and initialization of gateway parameters such as the local IP address, two-channel CAN baud rates, and two-channel network ports. After completing the above tasks, five subtasks are created, ordered from highest to lowest priority: TaskB, TaskC, TaskF, TaskD, and TaskE. The specific functions of these five subtasks are as follows:
Task B: Its main function is to receive and parse UDP messages and send them to CAN; if a timing message is received, it parses it according to the protocol and writes the timestamp information into the clock chip.
TaskC: Its main function is to receive TCP packets, parse them according to the protocol, and send them to CAN.
Task D: Receive data from CAN1 or CAN2, encapsulate the data into a message format according to the specified transmission method, and send it to the Ethernet.
TaskE: Receive data from CAN1 or CAN2, encapsulate the data using TCP transmission, and send it to the Ethernet.
TaskF: Its main function is to periodically send special messages, such as heartbeat messages, time synchronization messages, working status request messages, and equipment fault diagnosis information messages, to complete the working status detection and parameter configuration of the gateway module.
After the five subtasks are created, TaskB and TaskC enter a blocked state, waiting for their respective semaphores RecUdpQFlag and RecTcpQ-Flag. Since these two tasks have higher priority, the gateway module prioritizes converting data from Ethernet to the CAN bus. Therefore, when data arrives on the Ethernet, the corresponding semaphore is obtained based on the message type, and TaskB or TaskC immediately enters a ready state to wait for execution. If the currently executing task has a lower priority than these two tasks, TaskB and TaskC can preemptively execute. When the gateway module has not received Ethernet data or has completed processing, the task function TaskF checks the module's timer to determine whether special messages such as working status messages and heartbeat messages need to be sent. After execution, it checks whether the CAN node has data and selects to send it to the Ethernet using UDP or TCP, i.e., selecting to execute TaskD or TaskE, completing the data transmission process from CAN to Ethernet. During this period, TaskB and TaskC are allowed to preemptively execute. The system completes the format conversion and transmission between Ethernet data packets and CAN data frames by scheduling these five task functions. The program flow is shown in Figure 5.
3 tests
Set the host computer's IP address to 192.1.1.11, open the gateway parameter settings interface, and configure parameters such as the gateway parameter reply IP address, gateway parameter reply port, gateway module IP address, gateway receiving port number, and CAN data target IP address. Then, open the CAN bus data message testing software ZLGCANTest, set the CAN bus baud rate to 250 kWh·s⁻¹, and send the CAN message. Use ZLGCAN-Test, TCP & UDP testing tools, and EtherPeekNX software to check the network communication status. Figure 6 shows the results obtained from the ZLGCANTest software. As can be seen from the figure, the CAN data transmission frame type is an extended frame, the frame format is a data frame, the frame ID is 0x00000000, and each CAN protocol transmits 8 bits of data. Figure 7 shows the data obtained using the TCP & UDP testing tool, as indicated in the figure. This message header consists of an Ethernet header, an IP header, a UDP header, and a custom UDP header. The message identifier in the custom UDP header identifies it as a CAN message, and the subsequent data is the same 13-bit data from the CAN message in Figure 6. This demonstrates that the CAN network data was successfully sent to the Ethernet using a transparent conversion method. The same method can be used to test that data was successfully sent from the Ethernet to the CAN. The same applies to other types of messages in the network.
4. Conclusion
This paper describes the implementation process of a communication gateway for interconnecting Ethernet and CAN bus networks, based on the ARM7 series LPC2294. It outlines the message formats of the Ethernet and CAN buses used in this gateway and the structure of its custom UDP datagrams. The paper also proposes the software and hardware implementation methods for the gateway. Experiments show that this gateway module successfully achieves data transmission between Ethernet and CAN buses, demonstrating stability and high reliability.
