1. Introduction Configuration software device drivers provide software interfaces for connecting to computer hardware. After being loaded, they become part of the operating system kernel, meaning they are trusted by the operating system. Therefore, even a small error in a device driver can cause the operating system to crash. To avoid this, the code must be repeatedly tested, and the rules for writing drivers must be followed. The simplest method is to purchase off-the-shelf drivers to directly handle our devices, but such drivers carry the risk of connection and embedding errors. Alternatively, various commercially available drivers can be modified to work with many simple devices. If writing your own drivers, try to use a standard bus driver or class driver, as they typically implement most of the required functionality. If a device has only one specific purpose, writing a single driver to handle all device requests may be the simplest solution. The 3D Force Control configuration software provides the Force Control I/O Driver Interface Software Development Kit (FIOS SDK). The FIOS SDK provides a standard development interface. Developers only need to fill in the implementation code of a few scan functions according to the specific communication protocol or driver interface specification of the I/O device, and perform necessary debugging and testing to complete the development of a FIOS. [b]2 Background of the Project[/b] The project I am currently working on is the computer monitoring system for navigation lights at X Airport. When the airport lights are operating under Category II conditions, the visibility is between 800m and 400m. The lighting equipment is required to be highly reliable and have few failures. However, the failures of the lights during operation are often random. When the failure rate reaches a certain value, it will not meet the requirements of Category II operation [1][2]. In order to ensure the stability and reliability of the monitoring system, a dual-machine fault-tolerant mode is adopted in combination with ForceControl industrial control configuration software. Through hardware redundancy, reliable design of software configuration, combination of Visual C++ and ForceControl configuration software, and RS-485 bus as network connection line, a distributed database configuration is realized. A dual-machine fault-tolerant system based on ForceControl configuration environment is designed. One of the tasks in developing this system is to independently develop the driver program and write the custom communication protocol into the driver program. The 3D force control configuration software provides an I/O driver interface development toolkit (FIOS SDK). Therefore, the main task of driver development is to use the interface functions and input/output class libraries provided by the configuration software to write the code in Ioapi to meet the control requirements of I/O devices [3]. Since the development of this project is carried out in the Visual C++ 6.0 environment, learning Windows WDM driver design is also very helpful for a deep understanding of kernel-mode driver development and writing corresponding interface programs. [b]3 Development Tools - Introduction to FIOS SDK [5][6] [/b] The FIOS SDK development environment is based entirely on the 32-bit Windows platform. It uses dynamic link library (DLL) technology to integrate the code developed by developers into the force control configuration software system. The FIOS SDK provides programmers with API functions and C++ class libraries as development interfaces. The FIOS SDK mainly consists of four parts: device configuration interface (Iodevcfg), data connection configuration interface (Ioitemui), I/O monitoring interface Ioapi, and I/O server program Ioserver. The system comprises three components: Iodevcfg (managing device configuration), Ioitemui (managing data connection configuration), and Ioapi (completing data exchange with I/O devices and monitoring devices, including parsing communication protocols and converting data formats). Ioserver, provided by the FIOS SDK, dynamically loads Ioapi and calls and executes its exported functions. It encapsulates most of the technical details developers don't need to worry about, such as handling low-level communication with I/O devices (serial communication, network communication, etc.), device timeout processing, and device fault diagnosis. Ioserver also handles communication with the real-time database (DB), submitting data collected from I/O devices to the DB after parsing and converting it via Ioapi, or writing data from the DB to the I/O devices after parsing and converting it via Ioapi. Therefore, developers only need to develop the code for Iodevcfg, Ioitemui, and Ioapi. The following section uses the code and interface development of these three components as examples to illustrate the steps of driver development in the ForceControl configuration software. [b]4 Development Examples[/b] Taking the C8051 microcontroller for data acquisition as an example, we will develop a driver program for the lower-level RS-485 bus communication. 4.1 Device Configuration Interface (Iodevcfg) Development (1) I/O Description File When configuring with ForceControl, the definition process of I/O devices is generally involved. The file name of the I/O description file is Iodesc.txt. The format of the file content is as follows (where represents a newline): Category; Manufacturer or I/O program description; IOID Subtype 1; Type number; Default communication mode; Provide device address Subtype 2; Type number; Default communication mode; Provide device address ... Therefore, the I/O description file in this project is defined as: “X Computer Monitoring System; Department of Control, Huazhong University of Science and Technology; CCMSController; 0; 1; 0” indicates that the type number is 0, RS-485 communication, and no device address is set. (2) Development of Iodevcfg.dll Developers mainly complete two functions when writing the Iodevcfg interface program: one is to provide an interface for users to configure devices; the other is to save the device parameter information configured by the user for use when developing the programming interface Ioapi. If the standard device configuration interface provided by ForceControl can completely describe the relevant information of the device, there is no need to write the Iodevcfg interface program. The standard interface is shown in Figure 1, and the serial port is set as shown in Figure 2. 4.2 Development of Data Connection Configuration Interface (Ioitemui) When configuring with ForceControl, the process of establishing a connection between the point parameters in the real-time database DB and the specific channel of a certain device is called the data connection process. Ioitemui must be provided in the form of a DLL, which must be an MFC extension DLL, and its default file name is Ioitemui.dll. The form and content of the data connection process may be completely different for different I/O devices. Therefore, it is necessary to design corresponding data connection forms for different I/O devices to save various parameter information. When developing the Ioitemui interface program, developers mainly complete two functions: first, to provide an interface for users to configure data connections; and second, to store the device parameter information configured by the user in the data connection item structure (hereinafter referred to as the connection item structure) IOITEMDEF for use when developing the I/O monitoring interface Ioapi. This connection item structure is a general structure, which is assigned and interpreted by the developers themselves. The interface is shown in Figure 3: [align=center]Figure 3 Data Connection Configuration Interface[/align] 4.3 I/O Monitoring Interface Ioapi Development Ioapi is one of the most important programming interfaces provided by FIOS. The main task of developers is to develop the program code for the Ioapi part. Ioapi provides a set of API functions (scanning functions) and some C++ class libraries (IOC, Input Output Class). These IOC class libraries are all provided in the form of pure virtual classes, and only have member functions, not member variables. They mainly include 5 classes: CItem (data item class), CPacket (data packet class), CDevice (device class), CChannel (channel class), and CManager (manager class). It manages points, packets, devices, and channels in a hierarchical structure, enabling the acquisition of device configuration, data configuration, parameter information, and data exchange with the real-time database (DB). The Ioapi.dll program mainly performs the following exported functions (unnecessary functions must be deleted to improve program efficiency): OnCreate – Called immediately after Ioapi.dll is loaded, at which point the channel, device, packet, and point do not exist. It is generally used to set the program title, making the program's purpose clear to the user; OnSortItem – Called after all points have been imported, at which point no packets have been created; OnItemToPacket – Loops through and adds all points to each packet multiple times. The basic principle is to group points that can be processed at once into one packet to optimize packaging; OnBeforeScan – Called once after packaging is complete and before actual scheduling, iterating through the manager, channel, device, packet, and point; OnCreateDeviceLink – Device initialization; OnCreatePacketLink – Packet initialization; OnReadData – The IOSCAN program cyclically scans and schedules, forming a data acquisition command string; OnWriteData – Called when data is sent, forming a data sending command string; OnIsResponseComplete – In asynchronous mode, checks whether data reception is complete and whether the data should be set to the database. OnAfterSend – Called once after data is sent; during debugging, this allows you to check if the sent command string is correct. OnTimeout – Called when a timeout occurs. OnUnloadPacket – Called during packet destruction. OnClose – Called once during CManager destruction. Developers can write the communication protocol into the OnReadData() and OnWriteData() functions according to the project's custom communication protocol to implement data acquisition and downloading. The following is a partial code snippet of the OnReadData function: INT OnReadData( CPacket * pPacket, LPTSTR lpszSendString, INT& nSendStringLen ) { pPacket->SetReady(TRUE); // Generate the acquisition command string CDevice * pDevice = pPacket->GetDevice(); // Get the device pointer CChannel * pChannel = pDevice->GetChannel(); // Get the channel pointer pChannel->ClearAcceptBuffer(); // Clear the receive buffer CString csDeviceAddr = pDevice->GetAddr(); // Get the actual device address IOITEMDEF * pItemStru = pPacket->GetItem(0)->GetItemStru(); // Get the packet data BYTE ucIoType = pItemStru->n[IO_TYPE]; // Get the I/O type of the send command BYTE ucDeviceAddr = pItemStru->n[DEVICE_ADDR]; // Get the device address input by the user... // The relevant program needs to be written according to the actual communication protocol. CString csCommand = ""; csCommand = BYTE(FRAME_HEAD); // Write the frame header... csCommand += BYTE(QUERY); // Define the frame information type csCommand += BYTE(0x01); // The effective information length is 1 byte csCommand += BYTE(ucDeviceAddr); // Write the device address csCommand += LRCCheck(temp_que, 2); // Write the LRC checksum of the frame end nSendStringLen = csCommand.GetLength(); CString csPmessage; csPmessage.Format("Read data: device address %X", ucDeviceAddr); pDevice->ShowProcessMessage(csPmessage); pDevice->ShowEventMessage(csPmessage, FALSE); // For debugging, used to display the triggered event for (int i = 0; i < nSendStringLen; i++) lpszSendString[i] = csCommand; return SEND; } [/i]4.4 Driver Debugging Programs written in Visual C++ 6.0, such as Iodevcfg.dll, Ioitemui.dll, and Ioapi.dll, must be generated as Release versions. Otherwise, during debugging, the I/O Server will encounter an error and immediately exit program execution. The debugging display process is shown in the attached table. Attached Table: Device Driver Debugging Process Information [align=center][i]Attached Table: Device Driver Debugging Process Information[/i][/align]　　The debugging results show that the driver can achieve asynchronous communication with the C8051 microcontroller, complete data acquisition, and then realize the control of the navigation lights. 5 Conclusion Configuration software, as a special software for field production data acquisition and process control, is used in many industries. However, the driver of any configuration software cannot encompass the drivers of all devices, especially devices with specific requirements for communication protocols. Therefore, developers need to write corresponding driver code according to their own communication protocols and debug it in conjunction with actual devices. A good driver design should be configurable, portable, preemptive, interruptible, and multiprocessor safe [4]. If you want to master the development of drivers well, the most fundamental thing is to read the driver documentation and write the driver yourself. Editor: He Shiping