Introduction In railway systems, to ensure the safe operation of trains, real-time monitoring of the rails and surrounding conditions is necessary. Currently, the method involves installing multiple monitoring devices along the railway line to detect natural disasters such as floods, strong winds, and mudslides, as well as parameters like rail temperature. These devices typically use RS232, RS485, or CAN communication methods and are connected to various monitoring devices in the monitoring center via dedicated lines. This method wastes significant line resources and is not conducive to unified equipment management. Therefore, a device installed along the railway line is needed to collect information from nearby monitoring devices and transmit it directly to the monitoring center via a dedicated line. To communicate with multiple monitoring devices, multiple RS232, RS485, and CAN interfaces are required. Based on this application requirement, this paper proposes a method to expand multiple CAN bus interfaces. 1 System Structure 1.1 Chip Introduction The system uses Atmel's AT91RM9200 (hereinafter referred to as "9200") as the MCU. This processor is based on the ARM920T core, achieving a performance of 200 MIPS at a main frequency of 180 MHz; the maximum main frequency is 209 MHz. The processor also has abundant peripheral resources, which is very suitable for industrial control applications[1]; the operating system used is ARMLinux, and the kernel version is 2.4.19. Currently, the mainstream CAN protocol controllers generally use I/O bus (SJA1000, etc.) or SPI interface (MCP2515, etc.) to communicate with the MCU. Since this design uses PC/104 bus expansion card to expand multiple RS232 and RS485 interfaces, there are no extra I/O chip select lines available. Therefore, the SPI interface of 9200 and MCP2515 are finally selected to expand multiple CAN bus interfaces. MCP2515 is an independent CAN controller with SPI interface launched by Microchip. It fully supports the CAN V2.0B technical specification, and the communication rate can reach up to 1 Mbps. It contains 3 transmit buffers, 2 receive buffers, 6 29-bit acceptance filter registers and 2 29-bit acceptance mask registers[2]; its SPI interface clock frequency can reach up to 10 MHz, which can meet the needs of one SPI host interface to expand multiple CAN bus interfaces. 1.2 System Hardware Interface Figure 1 is a block diagram of the interface principle between the 9200 and MCP2515. Five MCP2515s are connected through the SPI interface of the 9200. Since the number of SPI slave chip select lines of the 9200 is limited, a chip select decoding method is used. NPCS0 can be used as a general external interrupt line (NPCS0 and IRQ5 are multiplexed pins). Due to the limited external interrupt line resources of the 9200, an interrupt line sharing method is adopted, that is, two MCP2515s share the same interrupt line, and the last MCP2515 has a dedicated interrupt line to meet the data processing needs at different communication rates. [align=center] Figure 1 Block diagram of the interface principle between AT91RM9200 and MCP2515[/align] Figure 2 is a block diagram of the external CAN bus interface of the MCP2515. The interface between the MCP2515 and the 9200 is omitted in the figure. Since the equipment needs to be installed along the railway line, it must have lightning protection capabilities. Therefore, a high-speed optocoupler is used for complete electrical isolation between the MCP2515 and the CAN bus transceiver (TJA1050), and the power supply of the circuits at both ends of the optocoupler must also be isolated by a power isolation module to achieve true isolation. Two 30 pF capacitors are connected between the CANH and CANL pins of the TJA1050 and ground to filter high-frequency interference on the CAN bus; two diodes provide protection against transient interference in the bus voltage. When the optocoupler is working normally, the input current is about 10 mA, and the forward voltage drop of the internal LED is about 1.7 V. Therefore, special attention should be paid to the selection of the resistance value of the series resistor at the input end. [align=center] Figure 2 MCP2515 CAN bus interface circuit[/align] 2 SPI Master Operation Mode The 9200 communicates with five MCP2515s through the SPI interface. The SPI controller of the 9200 operates in master mode, and the MCP2515 operates in slave mode. The MCP2515 supports multiple instructions (such as reset instructions, read instructions, write instructions, etc.) to enable the 9200 to perform read/write operations on the internal registers of the MCP2515 through the SPI interface. The working mode flow of the 9200 SPI controller as the master is shown in Figure 3 [1]. [align=center] Figure 3 AT91RM9200 SPI controller master mode flow[/align] It should be noted that after SPI is enabled, the corresponding chip select will only be enabled according to the chip select configuration (fixed peripheral or variable peripheral) when there is data in SPI_TDR (transmit data register); when there is no data in SPI_TDR, the chip select is automatically disabled. Therefore, when the 9200 sends multiple bytes to the MCP2515 continuously, it is necessary to ensure that the next byte is written into SPI_TDR before the previous byte is transmitted to avoid the chip select being automatically disabled; at the same time, after transmitting each byte, it is also necessary to read SPI_RDR (receive data register). The following uses the read instruction of MCP2515 as an example to illustrate the process of the driver shown in Figure 4 completing a read instruction operation (reading only one byte of data), and assumes that the 9200 SPI adopts the fixed peripheral chip select configuration method. The software implementation process of other instructions is similar to that of the read instruction. [align=center] Figure 4 Software flow of SPI read instruction operation[/align] 3 Driver Design The driver is the intermediate software layer between the application and the hardware, which completely hides the details of the device operation. The Linux operating system divides devices into three types according to the different information transmission methods in the device: character devices, block devices and network devices[3]. The communication between 9200 and MCP2515 is carried out in bytes through the SPI interface, so MCP2515 belongs to the character device. Since the five MCP2515 share one SPI interface of 9200, a driver is used to manage all MCP2515, which is beneficial for unified management of all devices. 3.1 Main data structures defined in the driver CAN bus communication is based on message frames. In the driver, both sending and receiving data are based on message frame operations [4]. Therefore, it is necessary to design appropriate data structures to meet the needs of data operations. 3.1.1 CAN message frame receiving and sending structure Wherein, node_num is the node number of MCP2515 (0~4), id is the identifier of CAN message frame, dlc is the data length (0~8), data is the data buffer of CAN message frame, ext_flag is used to identify whether CAN message frame is an extended frame, and rtr_flag is used to identify whether CAN message frame is a remote frame. 3.1.2 Device configuration structure (1) Baud rate and message filtering configuration structure Wherein, node_num is the node number of MCP2515 (0~4), baudrate is the CAN bus communication rate, filter is the message filtering configuration structure, br_flag is used to identify whether the baud rate configuration is valid, and fi_flag is used to identify whether the message filtering configuration is valid. The data structure types of baudrate and filter are defined as follows: (2) Working mode configuration structure Where node_num has the same meaning as above, and oper_mode represents the working mode of the node. MCP2515 has 5 working modes, namely configuration mode, sleep mode, listen-only mode, loopback mode and normal mode. Generally, the device works in normal mode. 3.1.3 Ring data receiving buffer structure Where can_recv_buf is the ring data buffer for receiving CAN message frames, recv_pos and read_pos represent the positions of data storage and reading buffers respectively; wq defines a waiting queue, which is used to implement blocking read operations. 3.2 Driver interface The driver interface is mainly divided into 3 parts: initialization and exit function interface, which completes the device installation and uninstallation operations; file system interface, which is completed by the file_operations data structure; and device interface, which completes the reading/writing operations of the device. 3.2.1 Initialization and exit function When installing the driver, the operating system will call the initialization function to perform device registration, device initialization and installation of interrupt handling routines. Reference [3] discusses the device registration method in detail, while this article mainly discusses the configuration method during device initialization. In this driver, device initialization is divided into two steps: one is to initialize the SPI controller of 9200, and the other is to initialize the five MCP2515s. When uninstalling the device driver, the exit function will be called. The exit function mainly completes the device deregistration and interrupt release. Reference [3] discusses the installation of the interrupt handling routine, the device deregistration and interrupt release method in detail, which will not be detailed here. 3.2.2 Interrupt Receive Service Routine After the MCP2515 receives the CAN message frame, it generates an interrupt and sets the INT pin low. The 9200 responds to the external interrupt and calls the interrupt handling routine corresponding to the external interrupt. There are three interrupt handling routines: at91_mcp2515_irq_handler_0 responds to the IRQ0 interrupt, at91_mcp2515_irq_handler_1_2 responds to the IRQ1 interrupt, and at91_mcp2515_irq_handler_3_4 responds to the IRQ2 interrupt. IRQ0 is connected to only one MCP2515, while IRQ1 and IRQ2 are shared by two MCP2515s respectively. The interrupt handling flows for IRQ0 and IRQ1 are shown in Figures 5 and 6 respectively, and the interrupt handling flow for IRQ2 is the same as that for IRQ1. [align=center] Figure 5 IRQ0 Interrupt Handling Flow[/align] [align=center] Figure 6 IRQ1 Interrupt Handling Flow[/align] It should be noted that there is no interrupt clearing operation in the processing flow in Figure 5. This is because the RX read buffer instruction is used to read data from the MCP2515 RX buffer. After the instruction operation is completed, the MCP2515 will automatically clear the corresponding receive interrupt flag. 3.2.3 File System Interface Definition The members of the file system interface struct file_operations are all function pointers, which indicate the entry point location provided by the device driver. The file_operations defined in this driver are: 3.2.4 ioctl Function The ioctl function is used to configure the device. We implemented two commands in the ioctl function: IOCTRL_CONFIG_CAN_DEV, used to configure the node's CAN bus baud rate and message filtering, and IOCTRL_SET_OPER_MODE, used to configure the node's operating mode. The configuration parameters for these two commands are pointers to the corresponding application-layer data structures, which have already been introduced in section 3.1.2. When configuring the baud rate and message filtering using the IOCTRL_CONFIG_CAN_DEV command, after configuration, if the node is in the INACTIVE state, the node's internal receive interrupt needs to be enabled, the corresponding external interrupt needs to be enabled, and the node's state needs to be set to ACTIVE. Normally, after executing the IOCTRL_CONFIG_CAN_DEV command on the node to be configured using the ioctl function, the IOCTRL_SET_OPER_MODE command should also be executed on the configured node to put the node into normal operating mode. 3.2.5 Regarding Race Conditions This system is a single-CPU system using the Linux 2.4.19 kernel, and it is non-preemptive. Furthermore, the driver design only allows one process to open and operate the device at a time. In this case, the race conditions in the driver mainly involve resource contention between the interrupt handler kernel code and the kernel code operating other devices. All device operations mentioned above communicate with the MCP2515 via the SPI interface of the 9200. Communication between the 9200 and MCP2515 begins with a command byte, and during a command operation (generally involving the continuous transmission of multiple bytes), the chip select and clock cannot be disabled; otherwise, the operation will fail. Therefore, a complete command operation of the MCP2515 constitutes a critical section. During a command operation on the MCP2515, all interrupts must be disabled to ensure normal execution. In the driver, the `local_irq_save` and `local_irq_restore` functions are used to disable and restore interrupts. The code executing a command operation on the MCP2515 is located between these two function calls. Conclusion This paper proposes a multi-channel CAN bus interface and driver design for specific application requirements. After testing, it can run stably and normally. The compilation and running methods of the driver are well explained in reference [3]. The upper-level test program is also relatively simple to write, but attention should be paid to the definition of data structure and the consistency of the underlying driver. This paper focuses on introducing the basic design method and implementing basic functions. MCP2515 itself provides many functions. On the basis of implementing basic functions, functions can also be extended according to the application needs. References [1] Atmel corporation. AT91RM9200 data sheet, 2006. [2] Microchip Technology Inc. MCP2515 data sheet, 2005. [3] Wei Yongming, Luo Gang, Jiang Jun. LINUX Device Drivers [M]. 2nd Edition. Beijing: China Electric Power Press, 2004. [4] Du Shangfeng, Cao Xiaozhong, Xu Jin. CAN Bus Measurement and Control Technology and Its Application [M]. Beijing: Electronic Industry Press, 2007.