1. Technical Background CAN (Controller Area Network) is a high-performance serial data local communication network composed of CAN controllers, and is one of the most widely used fieldbuses internationally. It was first introduced by Bosch in Germany for data communication between measurement and actuation components within automobiles. Its bus specification has been standardized as an international standard by the ISO standards organization. Due to its many advantages, such as multiple hosts, long transmission distance (up to 10km), high transmission speed (up to 1Mbps), and strong anti-interference capability, it is considered one of the most promising fieldbuses. The CAN protocol is based on the Open Systems Interconnection model of international standards organizations. In September 1991, Philips Semiconductors developed and released the CAN technical specification Version 2.0, which is the current highest version. It specifies two modes: standard mode and extended mode. This article mainly introduces the standard mode. TCP/IP (Transmission Control Protocol/Internet Protocol) is an industry-standard protocol suite, including sub-protocols such as IP, TCP, and UDP, ensuring the correct transmission of data over a network. The TCP/IP protocol is the foundation of the modern Internet. The TCP/IP protocol is a four-layer model: application layer, transport layer, network layer, and data link layer. Each layer has different functions, and the layers are logically independent of each other. Each layer corresponds to some sub-protocols, as shown in Figure 1. The protocols used in this article include ARP, IP, and TCP. 2. Application Background CAN bus is widely used in many industries. Local area networks composed of CAN buses can connect many low-level measurement and control devices, with a maximum distance of 10km (without repeaters). Compared to other fieldbuses, this distance is already very long. However, with the development of Ethernet, people hope to achieve true remote control of low-level devices. Industrial control computers with interface cards have been used to achieve this purpose, but problems such as price and bottlenecks caused by interface cards have also been exposed. This article describes how to complete this function using a module with a microcontroller, CAN devices, and network chips as the core. This solution reduces costs and avoids bottlenecks. 3. Hardware Components There are several hardware implementation options. One approach is to use a microcontroller with integrated TCP/IP protocol, plus a CAN transceiver and controller; another is to use a microcontroller with integrated CAN controller, plus a CAN transceiver and network chip. This example uses a Philips P89C668 microcontroller without any integrated protocols, plus a CAN controller SJA1000, a CAN transceiver TJA1050, and a network chip RTL8019AS, forming a conversion module. P89C668: Microcontroller, the main control component, controls the network chip and CAN devices, and performs protocol conversion between them. SJA1000: CAN controller, with two operating modes (BasicCAN and PeliCAN). BasicCAN only supports standard mode, while PeliCAN supports both the standard and extended modes of CAN 2.0B (this article only describes the BasicCAN mode). It supports error analysis, controls the CAN transceiver, and provides a simple interface for the microcontroller to control the CAN bus. TJA1050: CAN transceiver. After the microcontroller configures the CAN controller accordingly, the transceiver automatically completes the corresponding CAN bus actions. RTL8019: Network chip. Provides a simple interface for the microcontroller to control Ethernet, allowing the microcontroller to perform Ethernet operations simply by reading and writing to it. In the experiment, another CAN module is used as a CAN node, forming a simple CAN network together with the conversion module. 4. Software Part 4.1 CAN Programming CAN programming in BasicCAN mode is relatively simple, requiring only read and write operations on the corresponding registers of the SJA1000. In this mode, the message identification code is 11 bits. After being filtered by the acceptance filter, only messages that meet the conditions can be received and stored in the SJA1000 receive buffer. The smaller the identification code value, the higher the priority. If a message collision occurs on the bus, the message with higher priority will occupy the bus. The maximum data transmitted between CAN nodes at one time is 10 bytes. The description of the transmit buffer register is listed in Table 1. It is largely the same in structure as the receive buffer register, only the address is different. Table 1 Transmit Buffer Register This experiment uses the external interrupt 1 of P89C668. This interrupt is triggered by SJA1000 and is set to send an interrupt signal to P89C668 when SJA1000 receives data from another node. In the interrupt handler, P89C668 reads and saves the value of the SJA1000 interrupt register as the basis for processing in the corresponding program. 4.2 TCP/IP Protocol The TCP/IP protocol is very complex and involves a lot of content. The following are just a few points. (1) Concept of encapsulation and layering When sending data, the data must be encapsulated layer by layer, that is, the corresponding header is added as the identifier of each layer. The specific principle is shown in Figure 3. The received data is encapsulated according to a certain structure. We need to determine which layer the data should be delivered to based on the header information and remove the corresponding header information. In this way, it is transmitted down the chain until the actual data is obtained. The specific principle is shown in Figure 4. (2) Ethernet Driver The Ethernet driver is a software interface that provides the physical interface of the link layer and the interaction between the network layer. Network layer data must first be delivered to the Ethernet driver, which will then package the network layer data and deliver it to the physical interface to complete the data transmission. Conversely, when the Ethernet driver receives data, it must process it in a form that the application layer can accept and deliver it to the network layer. (3) The ARP protocol, or Address Resolution Protocol, provides a dynamic mapping from logical addresses to physical addresses. The sending station must know the physical address of the receiving station in order to encapsulate the data and transmit it over the Ethernet. Therefore, knowing only the logical address of the receiving station is not enough; the physical address of the receiving station must be obtained in advance through the ARP protocol. (4) The IP protocol, or Network Protocol, provides an unreliable, connectionless service. Its functions include encapsulating transport layer data to be sent into IP datagrams, calling the Ethernet driver to send data, receiving data from the data link layer, and data verification. (5) The TCP protocol, or Transmission Control Protocol, is a connection-oriented, reliable transport protocol. The UDP protocol performs the same function, but it only sends datagram packets from one host to another and does not guarantee reliability. This paper mainly uses the TCP protocol for data exchange and does not use the UDP protocol. The experiment uses the P89C668's Timer 0 interrupt, which interrupts every 10ms, primarily for ARP aging and setting the TCP timeout flag. 4.3 CAN and Ethernet Data Exchange The data exchange principle is simply to layer the data received from the Ethernet. If it's a TCP datagram, the actual data is extracted and stored in an allocated data area. After analysis, it's sent according to BasicCAN mode. Conversely, received CAN data is stored in another data area, address and count information are removed, and the remaining data is encapsulated and sent according to the TCP/IP protocol. When an external interrupt is triggered by CAN reception, the values ​​of the SJA1000 interrupt register and status register are saved, and processed according to these values ​​in the CAN processing subroutine. When data arrives from another node, it's stored in the corresponding buffer, and a flag is set. In the TCP timeout processing subroutine of the main program, this flag is checked; if it's high, the data in the buffer is copied to the Ethernet transmit buffer, encapsulated, and sent. When the P89C668 receives a TCP datagram from Ethernet, it sets a flag to 1. In the CAN processing subroutine (see Figure 6), this flag is used to determine if there is data to be sent to another node. During debugging, a CAN node sends some data to the conversion module at regular intervals. After receiving the data, the node forwards it to the host computer via Ethernet, and the host computer displays the received data through a terminal emulator. Similarly, some typed data can be sent via a terminal emulator, transmitted to another CAN node through the conversion module, thereby changing some of its internal data. 5. Summary This experiment only implemented simple data exchange between Ethernet and CAN in BasicCAN mode, without involving higher-level CAN protocols and complex error handling. However, the successful attempt of this experiment makes it possible to implement conversion in PeliCAN mode and load a complete protocol. It can be said that this experiment has laid a solid foundation for the integration of CAN and Ethernet.