1 Introduction 1.1 Background Introduction With the development of information technology, embedded systems are increasingly widely used in aerospace, communication equipment, industrial control and other fields. Due to size limitations, touch screens have replaced keyboards and mice as the preferred input tool for embedded systems. At the same time, embedded systems are gradually abandoning the traditional loop control mode and introducing operating systems to complete inter-process switching and task scheduling. μClinux is an excellent open-source embedded operating system. After various miniaturization modifications, it has formed a highly optimized and compact embedded Linux. Although it is small in size, μClinux still retains most of the advantages of Linux: stable and good portability, excellent network functions, complete support for various file systems and a rich standard API. Compared with other widely used embedded operating systems, such as VxWorks and WinCE, its relatively low price and convenient user program development are undoubtedly its huge advantages. Users can easily find the latest kernel version, compiler and other necessary software environment from the Internet, which has also prompted many enthusiasts to join. 1.2 Research Status Due to the increasingly widespread use of touch screens, there is a lot of corresponding research and engineering practice. In existing work, many engineers have researched the hardware connection between the ADS7846 touchscreen controller and the StrongARM platform, as well as the development of software drivers in the WinCE operating system, and have explored ways to improve the hardware accuracy of the touchscreen controller. The main contribution of this paper is a detailed description of the hardware and software design of the touchscreen driver in the μClinux embedded operating system. Practice has proven that this design has high accuracy, stability, and openness, and also good cross-platform compatibility, thus providing more options for embedded devices. 2 Hardware Design In this design, the microprocessor used is the Motorola MC68VZ328, a 32-bit low-power microprocessor based on the M68k architecture, designed using SoC technology and possessing typical characteristics of embedded microprocessors. The touchscreen uses the TI ADS7843 (formerly a product of Burr-Brown, but since Burr-Brown has been acquired by TI, TI will be used throughout this paper). In this design, the CPU and touchscreen work in a master-slave mode, with the touchscreen operating as a slave device. The hardware circuit in this design differs from traditional designs, fully utilizing the BUSY signal line in the ADS7843, as shown in Figure 1. The ADS7843 is a four-wire resistive touchscreen control chip that primarily performs two functions: switching electrode voltages and acquiring the voltage value at the contact point. It consists of two transparent resistive conductor layers, with an insulating layer made of a viscous insulating liquid and electrodes made of a highly conductive material between them. When the touchscreen is working, the upper and lower conductor layers act as a resistive network, as shown in Figure 2. When a voltage is applied to one electrode layer, a voltage gradient is formed on this network. If an external force causes the two layers to contact at a point, the voltage at the contact point can be measured on the other layer where no voltage is applied, thus determining the coordinates of the contact point. For example, if a voltage is applied to the electrodes (X+, X-) on the top layer, a voltage gradient is formed on the top conductor layer. When an external force causes the upper and lower layers to contact at a certain point, the voltage at the contact point can be measured on the bottom layer. Based on the distance between this voltage and the electrode (X+), the X coordinate of that point can be determined. Then, the voltage is switched to the bottom electrode (Y+, Y-), and the voltage at the contact point is measured on the top layer to determine the Y coordinate. For switching the voltage between the horizontal and vertical conductor layers and for A/D conversion, a control word needs to be sent to the ADS7843 via the Serial Peripheral Interface (SPI). After the conversion is completed, the voltage conversion value is read out via SPI. 3 Software Design 3.1 Characteristics of Drivers under μClinux μClinux inherits the device management method of Linux, treating all devices as specific files and accessing them through the file system layer. Therefore, in the Clinux framework, device-related processing can be divided into two layers—the file system layer and the device driver layer. The device driver layer hides the details of specific devices, while the file system layer provides users with a unified and standardized user interface. This device management method effectively achieves "device independence," allowing Clinux to easily expand based on the development of hardware peripherals. For example, to implement a device driver, one only needs to provide a set of access interfaces to the file system according to the specific hardware characteristics. Devices in μClinux can be divided into three categories: character devices, block devices, and network devices. Character devices have no buffer; data processing is performed sequentially in bytes, and they do not support random read/write. Touchscreens are a type of character device. There are two ways to load drivers into the kernel: one is to compile them directly into the kernel and register the device during system initialization; the other is a modular loading method, where the driver is compiled into an object file (*.o), and when a device needs to be added, it is registered with the system using the insmod command; when it is no longer needed, it is unloaded using the rmmod command. For basic input tools like touchscreens, it is recommended to compile them directly into the kernel so that they can be used immediately upon system startup. The function to register a character device with the kernel is: extern int register_chrdev(unsigned int major, const char *name, struct file_operations *fops); the kernel uniquely identifies a device using its major and minor device numbers. The parameter `major` corresponds to the requested major device number, `name` corresponds to the device name, and `fops` is a pointer to a `file_operations` structure. This is a crucial data structure used in Clinux for writing drivers, providing an interface between the application space and the driver. Each item in this data structure points to a function performed by the driver. In kernel version 2.4, this structure uses a tagged structure initialization syntax. Compared to kernel version 2.0, this syntax offers better portability, readability, and code compactness. Taking a touchscreen as an example: `static struct file_operations ts_fops = { owner: THIS_MODULE, read: ts_read, // read data operation poll: ts_poll, // non-blocking operation ioctl: ts_ioctl, // I/O control operation open: ts_open, // open device release: ts_release, // release device fasync: ts_fasync, // asynchronous trigger}` The complete structure also includes function pointers for `llseek`, `readdir`, etc., but these are omitted because they are not used in this program; the kernel defaults to NULL. 3.2 Touchscreen Driver Flow and Key Functions In this design, we use the μClinux 2.4 kernel. The main design idea of ​​the driver is: after initialization, the driver enters an idle state, waiting for an interrupt. Once a pen interrupt (pen_irq) occurs, the interrupt handler is entered to sample, convert, and transmit data. Simultaneously, the program identifies and handles various exceptions. The touchscreen software flow is shown in Figure 3. The driver program sets seven different states for the touchscreen, represented by numbers from -1 to 5. These seven states constitute a touchscreen state machine, and the system makes the next step of processing based on the current state, as shown in Table 1. The entire software design can be divided into five parts according to function: initialization, device opening, read operation, interrupt handling, and I/O control. Each part is described in detail below. 3.2.1 Driver Initialization In mc68328digi_init(), the device driver function is registered with the kernel: err=misc_register(&mc68328_digi). In init_ts_settings(), the current parameters of the touchscreen are set: kernel version number, pen movement discrimination threshold, sampling time, anti-jitter switch, anti-jitter time, etc. These parameters are customized by the user according to their LCD screen and accuracy requirements, or they can be set in the application using the I/O control function ioctl(). The meaning of these parameters will be analyzed in detail in the parameter analysis section of this paper. 3.2.2 Opening the Device In the ts_open() function, the driver program registers interrupts with the kernel. Interrupts can also be registered with the kernel during system initialization, but this is generally not recommended because it can cause interrupt conflicts when many devices are loaded. A better strategy is to enable a device first and then allow it to use the interrupt handler. Registering interrupt handlers with the kernel mainly achieves two functions: registering the interrupt number and registering the interrupt handler function. In this program, two interrupt handlers are registered with the kernel: `request_irq(PEN_IRQ_NUM, handle_pen_irq, IRQ_FLG_STD, “touch_screen”, NULL)` and `request_irq(SPI_IRQ_NUM, handle_spi_irq, IRQ_FLG_STD, “spi_irq”, NULL)`. In the former, `PEN_IRQ_NUM` is the interrupt number, which can be specified or dynamically assigned. In this driver, the pen interrupt allocation interrupt number is specified as 19; handle_pen_irq is the interrupt handling function, IRQ_FLG_STD is the option at request, which determines some characteristics of the interrupt handler, here indicating that it is occupied by the system internally; touch_screen is the device name. In the latter, the program registers the SPI interrupt with the kernel to transfer data between the CPU and the peripheral, the allocated interrupt number is 0, and handle_spi_irq is the SPI interrupt handling function. In addition, in the touch screen driver initialization sub-function init_ts_drv(), the following work is performed: (1) Initialization of the touch screen state; (2) Initialization of pen information (pen_values); (3) Initialization of the timer and setting the timeout function handle_timeout(); (4) Initialization of registers. Initialize the wait queue, which is a queue composed of processes waiting for touch events to occur. It includes head and tail pointers and a linked list of sleeping processes; (5) Set the touch screen state to idle. Since this initialization consumes some system resources, it is handled when the device is turned on, rather than in the initial device initialization section, to save resources. 3.2.3 Read Function ts_read() Once the user program calls read() to perform a read operation on the touchscreen, the driver calls the entry point function ts_read() for processing. If no data arrives at this time, and the driver selects a blocking operation, it calls interruptible_sleep_on(&queue->proc_list) to block the process and enter the waiting queue, while setting the touchscreen state to waiting; if a non-blocking operation is selected, the program returns immediately when no data arrives, and then uses an asynchronous trigger fasync() to notify of the arrival of data. During the waiting period, if a touch action (pen interrupt pen_irq) occurs, the interrupt handler is entered. In the interrupt handler, the data is sampled and converted, and the current coordinate information is placed in the queue. After the process is woken up (using `wake_up_interruptible(&queue->proc_list)`), the program retrieves position coordinates, event sequence information, etc., from the queue and puts them into user space (`put_user`), making them available to user programs and avoiding direct interaction between the user and the hardware. 3.2.4 Driver Interrupt Handling Functions When a pen interrupt occurs, the program enters the interrupt handling function. In the interrupt handling function, two interrupts are handled: the external touch interrupt (pen interrupt) and the SPI data conversion interrupt. The interrupt handling functions corresponding to these two interrupts are crucial to the touchscreen software design. The driver uses timers to handle time-related operations within the interrupt handling function. Define the function `set_timer_irq()` as follows: `static void set_timer_irq(struct timer_list *timer, int delay) { del_timer(timer); timer->expires = jiffies + delay; add_timer(timer); }` `jiffies` is a variable representing the number of clock cycles the system has run since startup, and `delay` is the set extension time (using clock cycles as the counting unit). Once the number of clock cycles exceeds the set value, a timeout function is triggered; in this program, it is `handle_timeout()`. The purpose of introducing a timer is twofold: first, to more accurately control the time required for the system to eliminate signal jitter caused by level fluctuations; and second, to effectively control the number of sampled coordinates without introducing a simple delay function that consumes a large amount of system resources. The problem of generating a large amount of coordinate data using SPI interrupts has not been well addressed in the literature; the solutions are simply to reduce the SPI clock frequency to obtain less data. This design introduces a timer, which effectively solves the above problem. In the `handle_timeout()` function, the program uses a conditional selection statement to judge the touchscreen state value (`ts_drv_state`). If it is not an error state, SPI is enabled, and the program enters `handle_spi_irq()` to communicate with the ADS7843. In `handle_spi_irq()`, the program uses the conditional selection statement to perform data conversion operations based on the touchscreen state value (`ts_drv_state`). It obtains the X and Y coordinates by sending the control word mentioned earlier to the touchscreen control chip. See the program flowchart for the specific logic. Once a conversion is complete, the program identifies the nature of the click based on the click status information (`state_counter`). In the `cause_event()` function, it makes judgments on clicks and movements respectively. The judgment method is relatively simple; it only requires comparing the difference between two sampled coordinates with a movement threshold to draw a conclusion. Furthermore, it distinguishes between signal errors and coordinate changes caused by pen movement; the judgment threshold can be set by the user. 3.2.5 I/O Control For various hardware parameters, including sampling time, debouncing switch, and debouncing time, the I/O control function `ioctl()` can be set in the user program, avoiding the time overhead of directly changing the driver and recompiling the kernel each time. In this program, the I/O control function is defined as: `static int ts_ioctl(struct inode * inode, struct file * file, unsigned int cmd, unsigned long arg);` The parameter `cmd` has two values: `TS_PARAMS_GET` and `TS_PARAMS_SET`, which indicate whether the parameter is being retrieved or set. When calling this function, the user only needs to assign a value to this parameter according to a pre-defined format to easily obtain or change the current parameters of the touchscreen. `arg` is a pointer to the passed parameter. 4 Conclusion After obtaining the original coordinates of the touch point (the numerical range is determined by the number of bits of the selected A/D converter), it is necessary to convert them according to the actual pixels of the specific LCD screen used to facilitate subsequent development of the graphical interface. Considering the threshold of two adjacent movements, the touch screen coordinates are calculated according to the following formula: Where XV is the displayed value of the X coordinate of the touch point, and XW is the measured value of the X coordinate of the touch point (original coordinate value). Equations (1), (2), and (3) are obtained during touch screen initialization. The method is to take any point on the left and right sides of the touch screen in the X direction, and measure with X△V=X△W=1 and Xoffrer=0 as the initial values ​​to obtain three new parameters: X△V, X△W, and Xoffrer (in actual use, this work belongs to the calibration of zero point offset). Then these three parameters will not change. For any measured original coordinate XW of the touch point, directly substitute it into equation (4) to calculate the pixel display coordinate XV of the touch point. Where XV1 is the displayed value of the left side of the touch screen; XV2 is the displayed value of the right side of the touch screen; XW1 is the measured value of the left side of the touch screen; and XW2 is the measured value of the right side of the touch screen. This design uses MicroWindows as the user interface, customizes the coordinate area of ​​each desktop icon, combines the sampled coordinates of the touch screen, determines whether it is within the coordinate area of ​​the icon, and then performs the corresponding event processing. The development platform used in this design has a 320×240 pixel LCD screen with physical dimensions of 80mm×60mm. The ADS7843 microcontroller uses a 12-bit conversion precision, and the theoretical touchscreen resolution is 80/2^12 = 0.020mm. However, due to level interference and physical interference during touch actions, the actual accuracy cannot reach this value. Testing on our platform showed a click accuracy of 1.0mm at the same point. This driver program can effectively distinguish between click and movement signals. When used in conjunction with handwriting recognition software, it can serve as the underlying driver for a handwriting tablet, enabling handwriting input.