Abstract: This paper describes the implementation process of a fieldbus wireless communication card based on Linux, successfully solving the communication problem between the IO module control card and the card. The wireless communication card enables wireless field devices to access the existing fieldbus via standard wireless technology. Simple tests were conducted, demonstrating that the system operates well and achieves the expected goals. Keywords: Wireless Communication Card; Fieldbus; Linux driver; 1. Introduction The convenience of using wirelessly connected devices has led to unprecedented success in the consumer electronics (commercial) sector. Based on this , wireless applications are emerging in various fields. In industrial or factory environments, the advantages of using wireless technology are multifaceted. First , industrial environments often require extensive cabling; using wireless technology not only effectively reduces installation and maintenance costs but also makes equipment adjustment, planning, and reconfiguration easier. Second, the introduction of wireless technology is more effective in addressing the potential damage to various cables in harsh environments such as those with chemical corrosion, vibration, and moving parts. Third, considering the adaptability and flexibility of factory equipment, fixed systems can communicate via wireless technology and existing mobile subsystems or mobile robots. Fourth, wireless technology simplifies temporary access tasks in factory equipment (such as diagnostics or programming) (e.g., using wireless handheld devices). Wireless technology plays a significant role in solving many moving objects in industrial and process control environments, such as the coordination between mobile robots and autonomous transport equipment; rotating objects, such as robotic arms; and monitoring and control problems of hazardous objects, such as distributed control. Applying wireless technology to fieldbuses to solve the problems of traditional fieldbuses is receiving considerable attention from academia and industry. 2. Wireless Access Methods for Fieldbuses To enable seamless and wider application of wireless technology in industrial fields and to allow field devices to wirelessly access existing fieldbuses, engineers in related fields both domestically and internationally have made certain attempts. Access schemes can be divided into three main categories based on the different layers at which access is implemented: user layer access, data link layer access, and physical layer access. (1) User layer access: An OPC server is set up in the user layer to exchange data between the wired network segment and the wireless network segment. The advantage of this scheme is that it is simple to implement and both sides can keep their original structure unchanged. The "connection" between the two sides can be established or separated at any time through software control. The disadvantage is that there are too many intermediate links and the real-time performance cannot be guaranteed. (2) Physical layer access: A modem is installed "below" the wired connection of some stations. The signal of the wireless station is converted into a frame format by this wireless transceiver device and then connected to the wired network segment interface. Therefore, the remote wireless station is "treated" as a homogeneous station. In this way, all wired and wireless stations use the original fieldbus protocol. Only at some physical connections at the lowest level, the wireless connection replaces the wired connection. The disadvantage is that this method only realizes point-to-point connection and the wireless station does not have the ability of "roaming access". (3) Data link layer access: This method is derived from the connection method of WLAN and Ethernet, that is, a wireless gateway is added above the PHY layer and DDL layer. This wireless gateway implements data format conversion and forwarding between wireless and wired network segments. The existing fieldbus remains unchanged, and an access point (AP) for the wireless segment is added. Data is forwarded to the other end via the AP after protocol conversion when there is data exchange between the two segments. Data link layer access is currently the most promising method. Many specific implementation methods exist, but most are still in the theoretical research stage or require modifications to the existing fieldbus, which industrial manufacturers do not want to disrupt. This makes the application of some current wireless access technologies in fieldbus systems difficult. To enable wireless field devices to be used in industrial settings without modifying the existing fieldbus system, the most mature technology is to use a wireless distributed control station to connect to the existing fieldbus, enabling wireless access for field devices. A wireless distributed control station typically consists of an I/O module control card and a wireless communication card. The two cards exchange data through the dual-port RAM on the I/O module control card, triggering data read/write operations via interrupts to achieve communication. The key technology lies in the software design of the wireless communication card. 3. Linux-based Wireless Communication Card In the wireless distributed control station, the wireless communication card uses an AT91RM9200 controller and loads a wireless transmission module conforming to the 802.11b protocol via a USB interface. Its operating system is Linux. 3.1 Working Principle of the Linux-based Wireless Communication Card The wireless communication card runs a fieldbus protocol stack and function blocks (MAI, MAO, MDI, MDO), etc. The appropriate protocol stack is selected according to the different fieldbuses connected. It uses interrupts sent to and responded to by the I/O module control card to configure, read, and control field devices. Data transmission between the wireless communication card and the I/O module control card is achieved directly by reading and writing to the dual-port RAM on the I/O module control card. On the other hand, the wireless communication card loads a wireless transmission module conforming to the 802.11b protocol through its USB interface, enabling it to connect to a wired network and communicate with the corresponding fieldbus workstation. Its structural diagram is shown in Figure 3-1: [align=center] Figure 3-1 Structural diagram of the wireless communication card[/align] 3.2 Software Design of Linux-based Wireless Communication Card The software development of the wireless communication card in the wireless distributed control station is based on the Linux operating system. Since the wireless driver based on the 802.11b protocol in the Linux system is already mature, and the protocol stack software based on the Linux operating system is relatively easy to port, choosing the Linux system will effectively improve the development cycle of the wireless communication card. The Linux-based wireless communication card is roughly the same as the wired communication card in terms of protocol stack and function blocks; only the application needs to be ported to the Linux system. However, due to the use of the Linux system, the implementation of communication with the IO module control card is relatively complex. The flowchart of the program communicating with the I/O module control card is shown in Figure 3-2 below: [align=center] Figure 3-2 Flowchart of the program communicating with the I/O module control card[/align] 3.3 Solving Key Issues in Software Implementation Under the Linux operating system, there are specific specifications for operations on interrupts and other system resources. For example, kernel mode operations and user mode operations have different operation permissions, and kernel space and user space cannot freely access each other. This results in the protocol stack being unable to directly read and write to the dual-port RAM, nor being able to directly send and receive interrupts to the I/O module control card. Under the Linux system, this can only be done in kernel mode. Therefore, how to write data into the dual-port RAM, then send an interrupt signal to notify the other party, and how to respond to the other party's interrupt and read data from the dual-port RAM are key issues in software implementation. 3.3.1 Implementation of Interrupt Sending and Registration Interrupt Handlers Since interrupt sending and registration interrupt handlers are direct hardware operations, user programs cannot directly operate on their hardware under the Linux system. Therefore, a corresponding kernel module must be written to complete the interrupt sending and registration interrupt handler operations within the kernel module. The corresponding kernel module is dynamically loaded in the user program to achieve the effect of the user program issuing interrupts and registering interrupt handlers. The key kernel module code for registering the interrupt handler is as follows: int init_module(void) // Initialize the interrupt registration module { ... /* Initialization settings */ AT91_SYS->AIC_SMR[25]|=0X20; // Set the interrupt to be triggered by the falling edge if (request_irq(n, interrupt_program, INTERRUPT," IRQ1",NULL)) // Request the allocation of fast interrupt handler with interrupt number n // interrupt_program is a pointer to the interrupt handler that handles this interrupt { ... /* If the request is unsuccessful, perform error handling based on the return value * / } else { printk("<1> Interrupt registration successful! \n"); return 0; } init_waitqueue_head(&my_queue); } void cleanup_module(void) { ... /* Release resources */ free_irq(n,NULL); // Release interrupt line n } When an interrupt is triggered in the user program, the kernel module program is dynamically executed by calling `system(send_riq)` to control the signal of the interrupt sending pin, thus achieving the effect of triggering an interrupt in the user program. The key kernel module code for triggering the interrupt is as follows: `AT91_SYS->PIOC_PER |= AT91C_PIO_PC15; // Enable PC15 IO AT91_SYS->PIOC_OER |= AT91C_PIO_PC15; // Enable PC15 output // Send a square wave interrupt signal AT91_SYS->PIOC_CODR |= AT91C_PIO_PC15; for (i=1;i ... 3.3.2 Implementation of Dual-Port RAM Driver Since user programs cannot directly read and write to dual-port RAM, a driver for dual-port RAM must be written according to the needs of the user program and dynamically loaded into the system as a kernel module. The Linux system treats all devices as files; reading and writing to a device is equivalent to reading and writing to a file. After the dual-port RAM driver module is loaded, the user program can indirectly read and write to the dual-port RAM just like reading and writing to a file. The main implementation process of its dual-port RAM driver module is as follows: static int write_dpram(struct file *file, const char *buf, u32 count, loff_t *f_pos) { …… /* Write initialization */ copy_from_user(wMessage,buf,count); …… /* Perform data processing */ for (i=0;i;i } { writeb(wMessage[i], base+wadd); wadd++; } …… /* Send interrupt signal to IO module control card */ } static int read_dpram(struct file *file, char *buf, u32 count, loff_t *f_pos) { ... /* The read function calls the corresponding readb() and copy_to_user() functions, similar to the write function */ } static int open_dpram(struct inode *inode, struct file *file ) { ... /* Initialization */ if (!request_mem_region(AT91_DPRAM, BUF_LEN *sizeof(u8), DEVICE_NAME)) { ... /* Handle the situation if the memory space is not allocated */ } // Request memory space base = ioremap(AT91_DPRAM, BUF_LEN *sizeof(u8)); // Allocate virtual addresses for the device memory region ... /* Set DPRAM read/write timing */ } static int release_dpram(struct inode *inode, struct file *file ) { ... /* Release the corresponding resources iounmap() and release_mem_region(); } The above is the implementation of the open, read, write, and close functions of the DPRAM device driver. Then, the driver's functions are mapped to the specific implementation functions above through the following tokenization structure: static struct file_operations test_fops = { read:read_dpram, write:write_dpram, open: open_dpram, release:release_dpram }; In addition, the driver must be registered using register_chrdev() during driver initialization. Before loading the driver, the device file must be created and the device number assigned to the device must be created using system("mknod /dev/device_name c major_device_number minor_device_number"). This dual-port RAM driver is universal and can be used on any board with dual-port RAM and based on a Linux system. 4. Testing In order to test the performance of this wireless communication card, this test selected a device compliant with EPA (Ethernet for Plant) This system extends the fieldbus system to the EPA standard wirelessly. EPA is my country's first fieldbus standard with independent intellectual property rights. The test system built is basically the same as the wired EPA demonstration system. It includes an EPA wireless field device B (including an EPA wireless communication card and an IO module control card), an EPA wireless access bridge, a PC, and a light box, as shown in Figure 4-1. The temperature sensor in the light box is connected to the AI ​​module, transmitting the temperature value to the AI ​​module and then sending it to the Ethernet via device A. After receiving this temperature value, device B compares it with the rated temperature value. If it is lower than the rated temperature value, it controls the bulb heating in the light box by outputting current through the AO module; if it is higher than the rated temperature value, it interrupts the output current of the AO module, cutting off the current input to the bulb, thus lowering the temperature inside the light box and maintaining a constant temperature. [align=center] Figure 4-1 Schematic diagram of the test system[/align] Experiments show that the data transmission between the wireless communication card and the IO module control card is stable. The system operates well, achieving the expected goals and meeting the communication requirements of industrial field devices. At the same time, it does not change or affect the normal operation of the original wired fieldbus. 5. Summary Using wireless distributed control stations and wireless bridges to realize wireless access of fieldbus is currently a relatively stable and convenient method for unlimited expansion. The hardware and software implementation method of wireless communication card in wireless distributed control station proposed in this paper is a general and quick development scheme. Wireless technology brings many benefits to industry, such as reducing equipment configuration and installation time. The market also provides relatively mature wireless technologies such as IEEE 802.11 standard, IEEE 802.15.4 standard and Bluetooth technology. However, wireless technology is still not widely used in industrial field. One of the reasons is that the real-time performance and error rate of wireless channels do not meet the requirements. With the design of appropriate protocol mechanisms and transmission scheduling, and by carefully combining these schemes, wireless technology will surely be widely used in industrial fieldbus. Main references: [1] Wu Aiguo, Guo Xin. Combination of fieldbus CAN and wireless Ethernet IEEE802.11 [J]. Modular Machine Tool and Automated Processing Technology, 2004, (11): 61-62, 64. [2] Hou Weiyan, Xu Jing, Fei Minrui, Chen Boshi. Integration mode of industrial fieldbus and wireless communication [J]. Automation Instrumentation, 2003, 24(12): 10-14. [3] Gao Lu, Yu Haibin, Wang Hong, Xu Aidong. EPA network architecture [J]. Computer Engineering, 2004, 17(30): 81-82. [4] Alessandro Rubini. LINUX Device Drivers (Second Edition) [M]. China Electric Power Press, 2002.2.