Design of Communication between PC104 Bus and CAN Bus Based on Linux

1 Introduction

PC104 embedded industrial computers have been widely used due to their small size, stacked connection, and easy bus drive. In the field of fieldbus, CAN bus has been widely supported by computer chip manufacturers, who have launched microprocessor (MCU) chips with direct CAN interface. The total number of MCU chips with CAN has reached 130 million pieces, so in terms of interface chip technology, CAN is far ahead of all other fieldbuses such as FF, PRO-FIBUS, LONWORKS, etc. However, PC104 bus cannot communicate directly with CAN bus, so it is difficult to use in CAN bus control system.

In view of the above problems, a conversion card between PC104 bus and CAN bus was designed with AVR microcontroller as coprocessor. Considering the characteristics of Linux operating system usually running on PC104 embedded industrial computers, a driver program for PC104 bus access to dual-port RAM under Linux was written. The conversion card is used in industrial control systems and it is actually shown that it can run stably and reliably.

2 Hardware

The hardware system block diagram of the PC104 to CAN bus conversion card is shown in Figure 1. In the communication between the PC104 bus and the CAN bus, the main issue to be considered is the data synchronization between the PC104 bus and the CAN bus. There is a big difference between the bus speeds of the PC104 bus and the CAN bus. The method usually used to solve this problem is to use a dual-port RAM or FIFO as a buffer. Here, a dual-port RAM is used as a data buffer, and a few bytes are reserved in the dual-port RAM as soft handshake signals between the ATmega64 processor and the PC104 embedded computer. The data synchronization between the PC104 bus and the CAN bus is completed by the above method. EPM7128 is Altera's CPLD. The CPLD used here is mainly used for address decoding of the PC104 to CAN bus conversion card. The CAN bus communication is implemented using the SJA1000 CAN bus controller. In order to adapt to the harsh electromagnetic environment of the industrial site, optical isolation is performed in the SJA1000 and PC82C250.

2.1 PC104 bus and IDT7134 interface circuit

The circuit diagram of the PC104 bus and IDT7134 interface is shown in Figure 2.

In order to read the data of dual-port RAM IDT7134, PC104 embedded computer first maps IDT7134 to the memory space of PC104 embedded computer, and uses SMEMR* and SMEMW* as OER and R/W control signals of IDT7134. In addition, CPLD EPM7128 is used to decode the high 3-bit address SA19, SA18, and SA17 of PC104 bus as chip select signal of IDT7134.

2.2 ATmega64 and IDT7134 interface circuit

The processor ATmega64 uses the time-sharing multiplexing technology of address lines and data lines, so address latching is required. The address latch is designed in EPM7128 using VHDL hardware description language. The interface circuit between ATmega64 and IDT7134 is shown in Figure 3. [page]

2.3 CPLD EPM7128 internal logic

CPLD EPM7128 mainly completes the decoding and address latching functions in the whole design. In the QuartusⅡ6.0 environment, the above functions are completed through VHDL hardware description language. The program source code is as follows:

In the above VHDL code, 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

To realize data communication between PC104 bus and CAN bus, the method of using dual-port RAM as data buffer has been mentioned in the above hardware design, which involves opening up a data area in the dual-port RAM as a soft handshake flag between PC104 embedded PC and ATmega64. The handshake process should be implemented in the software program of PC104 embedded PC and ATmega64, and the process is as follows: First, two buffers are opened in the dual-port RAM, which are used to buffer the receiving and sending data of the CAN bus. When the PC104 bus has data to send to the CAN bus, the data is first written to the CAN data sending buffer of the dual-port RAM, and then a specific value is written to the flag field reserved in the dual-port RAM to notify ATmega64 that there is data to be sent through the CAN bus. ATmega64 uses a query method to detect this flag field. When a specific value of the flag field is detected, the CAN data sending buffer of the dual-port RAM is read, and the read data is sent to the CAN bus. After the above process, the ATmega64 program resets the flag field. At this point, the data transmission from the PC104 bus to the CAN bus is completed. The data transmission from CAN bus to PC104 bus is the opposite of this process.

3.1 ATMaga64 Processor Program

The ATMaga64 processor performs the bottom-level reading and writing of the CAN bus, writes the data to the dual-port RAM IDT7134, and sets the first storage byte in the IDT7134 as a flag, notifying the PC104 embedded PC that data has been updated, and requiring the PC104 embedded PC to read 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 accessing 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, registering the device, and initializing the related device drivers. Generally, this part of the program is only called once during initialization, and it is included in the init_module() routine.

(2) The I/O request service program mainly completes the user's request functions, such as Read, Write, etc., through system calls. Most operations of the device are completed by the I/O request service, which mainly includes routines such as Read, Write, and Ioct1.

(3) Interrupt service subroutine: the system receives all hardware interrupts and then calls the corresponding interrupt service subroutine.

In Linux system, device driver appears as a file, so the interface of device driver is a file system interface, which is defined by a data structure struct file_operations{}, which is the standard interface of the whole virtual file system. Therefore, the data structure of PC104 bus accessing dual-port RAM driver file system is defined first.

For the PC104 memory segment, the Linux kernel creates a page table to access these addresses when it starts. The virtual address to access them is different from the actual physical address, so it is necessary to use ioremap to map the physical address to the virtual address in order to access the PC104 bus to read the 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 area. This virtual address must be released by calling iounmap. The following will introduce the specific implementation of each function of the Linux driver in detail. [page]

3.2.1 Initialization function and uninstallation function implementation

The device configuration and initialization functions init_module() are called separately:

register_chrdev(): register the device;

request_irq(): request interrupt channel;

request_mem_region(): allocates I/O memory area;

ioremap(): Maps physical addresses to virtual addresses.

The program source code is as follows:

This completes the initialization of the device driver. The uninstallation of the device driver is the opposite of the initialization program. Uninstallation is to recycle various resources allocated to the device driver. In cleanup_module(), the following are called:

iounmap(): release 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 reading process of the dual-port RAM. The source code is as follows:

The copy_to_user kernel function copies count data at the virtual address pPxp-VirtStartAddr to the user space pointed to by the buf pointer. The ioremap() function in the previous device configuration and initialization function ink_module() has mapped the dual-port RAM physical address to the virtual address pPxpVirtStartAddr, so the dual-port RAM can be read through the pxp_read() function.

3.2.3 Write function implementation

When writing to the dual-port RAM, the pxp201_write() function is called. The principle is similar to reading the dual-port RAM, except that the copy_from_user() kernel function is called in the pxp201_write() function.

3.2.4 Implementation of open function and release function

The implementation of the pxp_open() function is as follows, where MOD_INC_USE_COUNT is used to increment the reference count of the device.

The pxp201_release() function is the opposite of the pxp_open() process and uses MOD_DEC_USE_COUNT to decrement the reference count of the device.

Since then, the driver module of the dual-port RAM under Linux has been completed, and the driver module can be loaded into the kernel using the Insmod tool. In this way, the dual-port RAM can be accessed under the Linux operating system of the PC104 embedded industrial computer.

4 Conclusion

This paper introduces the hardware implementation of the communication between PC104 bus and CAN bus, and develops the driver for PC104 bus to access dual-port RAM IDT7134 under the Linux operating system of PC104 embedded computer. The flag area is opened in IDT7134, and the data communication between PC104 bus and CAN bus is realized by using the soft handshake method. The conversion card is used in industrial control system and has been tested to be stable and reliable.