1 Introduction The PC104 embedded industrial computer has been widely used due to its small size, stacked connection, and easy bus driving. In the fieldbus field, the CAN bus has received widespread support from computer chip manufacturers, who have launched microprocessor (MCU) chips with direct CAN interfaces. The total number of MCU chips with CAN has reached 130 million, so in terms of interface chip technology, CAN has far surpassed all other fieldbuses such as FF, PRO-FIBUS, and LONWORKS. However, the PC104 bus cannot communicate directly with the CAN bus, making it difficult to use in CAN bus control systems. To address this issue, a PC104 to CAN bus conversion card was designed using an AVR microcontroller as a coprocessor. Considering that the PC104 embedded industrial computer usually runs the Linux operating system, a driver program for accessing the dual-port RAM of the PC104 bus under Linux was written for the conversion card. The conversion card has been applied in an industrial control system, and practical results show that it can operate stably and reliably. 2 Hardware Part The hardware system block diagram of the PC104 to CAN bus conversion card is shown in Figure 1. In communication between the PC104 bus and the CAN bus, the main issue to consider is data synchronization. The PC104 bus and the CAN bus have significantly different bus speeds. A common approach to address this is to use a dual-port RAM or FIFO as a buffer. Here, a dual-port RAM is used as the data buffer, with a few bytes reserved in the dual-port RAM for soft handshake signals between the ATmega64 processor and the PC104 embedded computer. This method achieves data synchronization between the PC104 bus and the CAN bus. The EPM7128 is an Altera CPLD, primarily used for address decoding in the PC104 to CAN bus conversion card. The CAN bus communication is implemented using the SJA1000 CAN bus controller. To withstand the harsh electromagnetic environment of industrial sites, optical isolation is applied between the SJA1000 and the PC82C250. 2.1 PC104 Bus and IDT7134 Interface Circuit The interface circuit diagram between the PC104 bus and the IDT7134 is shown in Figure 2. To read data from the dual-port RAM IDT7134, the PC104 embedded computer first maps the IDT7134 to the PC104 embedded computer's memory space, using SMEMR* and SMEMW* as the IDT7134's OER and R/W control signals. Additionally, the CPLD EPM7128 decodes the high 3 bits of the PC104 bus address (SA19, SA18, SA17) as the IDT7134's chip select signal. 2.2 ATmega64 and IDT7134 Interface Circuit: The ATmega64 processor uses time-division multiplexing of address and data lines, thus requiring address latching. The EPM7128 incorporates this address latch designed using VHDL hardware description language. The ATmega64 and IDT7134 interface circuit is shown in Figure 3. 2.3 CPLD EPM7128 Internal Logic: The CPLD EPM7128 primarily performs decoding and address latching functions throughout the design. In the Quartus II 6.0 environment, the above functions are accomplished using the VHDL hardware description language. The source code is as follows: In the VHDL code above, CSSJA1000 is the SJA1000 chip select signal, CS7134L is the IDT7134 left port chip select, and CS7134R is the IDT7134 right port chip select. 3. Software Part To achieve data communication between the PC104 bus and the CAN bus, as mentioned in the hardware design above, a dual-port RAM is used as a data buffer. This involves allocating a data area in the dual-port RAM as a soft handshake flag between the PC104 embedded PC and the ATmega64. The handshake process is implemented in the software programs of the PC104 embedded PC and the ATmega64, and the process is as follows: First, two buffers are allocated in the dual-port RAM to buffer the CAN bus transmit and receive data. When data is sent from the PC104 bus to the CAN bus, the data is first written to the CAN data transmission buffer in the dual-port RAM. Then, a specific value is written to the reserved flag field in the dual-port RAM to notify the ATmega64 that data is to be sent via the CAN bus. The ATmega64 uses a polling method to detect this flag field. When the specific value of the flag field is detected, it reads the CAN data transmission buffer in the dual-port RAM and simultaneously sends the read data to the CAN bus. After the above process, the ATmega64 program resets the flag field. This completes the data transmission from the PC104 bus to the CAN bus. The data transmission from the CAN bus to the PC104 bus is the reverse process. 3.1 ATmega64 Processor Program The ATmega64 processor performs low-level read and write operations on the CAN bus, simultaneously writing data to the dual-port RAM IDT7134 and setting the first byte stored in the IDT7134 as a flag bit to notify the PC104 embedded PC that data has been updated and requesting the PC104 embedded PC to perform a read operation on the IDT7134. Based on the above process, the ATmaga64 processor program includes the SJA1000 initialization program, the SJA1000 interrupt handler, and the program for accessing the IDT7134. 3.2 Linux driver for PC104 bus access to dual-port RAM The Linux driver is structurally divided into three parts: (1) Device configuration and initialization, including checking the existence and status of the device, device registration, and initialization of related device drivers. Generally, this part of the program is only called once during initialization, and it is contained in the init_module() routine. (2) I/O request service program mainly completes the user's request function through system calls, such as Read, Write, etc. Most of the device operations are completed by the I/O request service, mainly including Read, Write, Ioct1, etc. routines. (3) Interrupt service subroutine, which is received by the system from all hardware interrupts and then calls the corresponding interrupt service subroutine. In the Linux system, device drivers appear as files, so the interface of the device driver is a file system interface, which is defined by a data structure struct file_operations{}, which is the standard interface of the entire virtual file system. Therefore, the data structure for accessing the dual-port RAM driver file system via the PC104 bus is first defined. For the PC104 memory segment, the Linux kernel establishes page tables for accessing these addresses during startup. The virtual addresses accessing these addresses are different from the actual physical addresses; therefore, ioremap is needed to map the physical addresses to virtual addresses before the PC104 bus can be accessed to read dual-port RAM data. The ioremap function is defined as: `Void*ioremap(unsigned long phy_addr, unsigned longsize)`. The parameter `phys_addr` is the physical address, and `size` is the length of the physical address. The return value of the ioremap function is a special virtual address that can be used to access the specified physical memory region. This virtual address must be released by calling `iounmap`. The following will detail the specific implementation of each function in the Linux driver. 3.2.1 Initialization and Unloading Functions The device configuration and initialization function `init_module()` calls the following respectively: `register_chrdev()`: register the device; `request_irq()`: request an interrupt channel; `request_mem_region()`: allocate an I/O memory region; `ioremap()`: map the physical address to the virtual address. The program source code is as follows: This completes the device driver initialization. The device driver unloading part is the opposite of the initialization program; unloading reclaims various resources allocated to the device driver. In `cleanup_module()`, the following are called respectively: `iounmap()`: releases the virtual address; `release_mem_region()`: releases the memory region; `free_irq()`: releases the interrupt channel. The program source code is as follows: 3.2.2 Read Function Implementation The read function defines the process of reading the dual-port RAM, and the source code is as follows: `copy_to_user` copies `count` data items from the virtual address `pPxp-VirtStartAddr` to the user space pointed to by the `buf` pointer using the kernel function. Previously, the `ioremap()` function in the device configuration and initialization function `ink_module()` mapped the dual-port RAM physical address to the virtual address `pPxpVirtStartAddr`, so the dual-port RAM can be read using the `pxp_read()` function. 3.2.3 Write Function Implementation: When writing to the dual-port RAM, the `pxp201_write()` function is called. Its principle is similar to reading from the dual-port RAM, except that `pxp201_write()` calls the `copy_from_user()` kernel function. 3.2.4 Open and Release Function Implementation: The `pxp_open()` function is implemented as follows, using `MOD_INC_USE_COUNT` to increment the device's reference count. The `pxp201_release()` function is the reverse of `pxp_open()`, using `MOD_DEC_USE_COUNT` to decrement the device's reference count. At this point, the driver module for the dual-port RAM under Linux is complete. The `Insmod` tool can be used to load the driver module into the kernel. This allows access to the dual-port RAM under the Linux operating system of the PC104 embedded industrial computer. 4 Conclusion This paper introduces the hardware implementation of communication between the PC104 bus and the CAN bus, and develops a driver program for accessing the dual-port RAM IDT7134 using the PC104 embedded computer's Linux operating system. A flag area was created within the IDT7134, and data communication between the PC104 bus and the CAN bus was achieved using a soft handshake method. This converter card has been tested in industrial control systems and proven to operate stably and reliably.