Windows XP driver touch panel (Overview)

With the popularity of the iPhone, touch screens have become the standard for many mobile electronic products, making the development of touch screen drivers increasingly important in embedded devices. Because of its small size, embedded mobile devices require the most convenient input tool. Touch screen users can easily perform operations on embedded mobile devices. The operation is simple and intuitive, making it an extremely convenient Human-Computer Interaction device.

 

 

 

1. wince driver model classification

The wince system has a convenient feature in driver design, that is, the original device manufacturer (OEMs) and independent hardware developer (ihvs) can develop device drivers to support their hardware. Therefore, it is necessary to thoroughly understand the driver mode of the wince system before developing the touch screen driver.

(1) classification of driver Loading Methods

 

To compile the wince driver, you must first determine which driver it belongs. Generally, devices used on the wince platform can be divided into two types: built-in devices and installable devices. Therefore, WinCE can be dividedBuilt-in driver and loadable driver).

The wince system can directly use built-in devices because the built-in device driver is closely linked to the core components of wince, that is, the built-in device driver is statically linked to GWES (graphics drawing wing and eventssubsystem. The devices corresponding to these drivers are usually loaded in the GWES process space when the system is started. They are mainly drivers related to display and input.

 

Because they do not exist in the form of independent DLL, each built-in driver must be consistent with a specific interface of the device driver interface (DDI. Built-in devices include display, touch screen, audio, serial port, led, battery, and PC card socket. Built-in drivers are generally designed as dynamic link libraries, but there are two exceptions: Battery and LED Drivers are designed as static libraries because of their small size. They are generally stored in ROM or flash memory.

 

A portable device is a third-party interface device that can be connected and separated from the platform. It can be installed and detached by users at any time. The drivers of these peripheral devices are also called flow drivers, which can be dynamically loaded by the Device Manager at system startup or at any time after startup. These drivers usually exist in the form of DLL dynamic link libraries, and the loaded drivers can only run as user roles. In wince, typical load-able drivers include PCMCIA Driver (PCMCIA. DLL), serial driver (serial. DLL), ataflashdriver (ATA. DLL), Ethernet Driver (ne2000.dll, smsc100fd. DLL ).

 

Unlike the built-in driver, all load-able stream drivers share a public interface, and the function matches the function in the file API used by the application. Therefore, the flow interface driver that controls the device to be loaded is generally accessed by the application. That is to say, the stream interface driver displays device functions to applications by a special file, which can be opened, read, written, and closed. Generally, only OEMs can modify internal device drivers. Other free device manufacturers do not involve too many internal device drivers because only additional hardware devices are provided.

 

 

(2) classification at the driver level

 

The biggest benefit of Wince is its customization. When its own driver cannot meet your requirements, you can write the corresponding driver on your own. Therefore, according to the structure, the wince driver can be divided into hierarchical drivers and non-hierarchical drivers. A layered driver consists of two layers:The upper layer is the model Device Driver (MDD), and the lower layer is the platform Driver (PDD).

 

In a layered driver, MDD is usually used directly without modification. The role of MDD is to link the PDD layer and define the function interface that it wants to call: devicedriver Service Provider Interface (ddsi ). At the same time, MDD provides different function sets to the wince kernel. These functions are called Device Driver interfaces (DDI ). A non-layered driver writes PDD and MDD together without a strict distinction. Generally, such drivers are relatively simple, such as atadisk. To put it simply, the built-in driver and the loaded stream driver are classified in the form of interfaces between the driver and other modules (callers) of the system; without hierarchy or hierarchy, the classification is based on the driving implementation method.

 

The MDD driver does not need to be modified during development. However, unlike the MDD-layer driver, the PDD-layer driver must be modified to code that matches the specific hardware. Programmers can develop a PDD program by themselves, but in most cases, developers are advised to modify the sample driver provided by platform builder. In the Win CE system, the touch screen driver is a hierarchical driver.

 

 

 

 

2. Design and Implementation of touch screen driver

The Touch Screen of embedded devices can be divided into five categories based on their technical principles: vector pressure sensing, resistance type, Capacitive Type, infrared type and Surface Acoustic type. The resistive touch screen is widely used in embedded systems. The resistive touch screen can be divided into four lines, five lines, and seven lines. Generally, the design and implementation of the wince touch screen driver are as follows:

 

(1) configure and initialize the touch screen

 

The Touch Screen driver calls the touchpanelenable function during initialization. The ddsi function called by this function is ddsitouchpanelenable and ddsitouchpaneldisable. These two ddsi interface functions are the key to driver implementation and are used to enable and disable touch screen hardware respectively. However, in order to reduce power consumption, these two functions can not really operate the hardware, but only implement software control.

 

At the same time, these configurations and initialization are also required during initialization: first, create the event htouchpanelevent and hcalibrationsampleavailable, the former is triggered when a touch pen is pressed or the data needs to be collected periodically after being pressed, while the latter is triggered when there is a calibration data input in the calibration state. The second is to check the interrupt gintrtouch (touch screen interrupt) and gintrtouchchanged (timer interrupt) required for initialization, and associate the two interrupts with the event htouchpanelevent. The third is to create an ISR thread touchpanelpisr to wait for and process the touch screen event htouchpanelevent, which is also the only event source in the entire driver.

 

 

(2) Calibration of touch screen reference parameters

 

After completing the tedious work, all the functions of the driver are ready. Now you can touch the screen. However, in general, the resistive touch screen needs to be calibrated, that is, the MDD layer needs to call the corresponding ddsi function during the driver startup to read the correction data correction touch screen in the registry. Ideally, the calibration program runs once during the initial power-on test of the embedded device, and the reference values are stored in non-volatile memory, this prevents users from performing calibration during subsequent power-on startup. However, high-quality touch screen drivers should provide users with a way to enter the calibration routine, so as to re-calibrate when the calibration is inaccurate due to temperature drift or other factors.

 

Ideally, only two sets of raw data are required for the touch screen baseline correction, that is, the minimum and maximum values for reading on the diagonal corner of the screen. However, in practical applications, because many resistive touch screens have obvious non-linear characteristics, a simple insertion position value between the minimum and maximum values may cause the driver to be very inaccurate. Therefore, you need to obtain multiple calibration points in wince. The number of commonly used calibration points is 5.

 

The method is:

① First, the driver sets the number of calibration points in the ddsitouchpanelgetdevicecaps function;

② The system obtains the screen coordinates of each calibration point in touchdrivercalibrationpointget;

③ A position symbol is displayed at the coordinate of the calibration point on the screen interface. You need to press the touch screen accurately on the position symbol;

④ The driver reads the corresponding touch screen coordinate value through the touchpanelreadcalibrationpoint function;

⑤ Then start the next calibration point until the screen coordinates of the collected touch screen coordinates and calibration points are sent to the touchpanelsetcalibration function for processing after the number of cycle settings, this function generates calibration benchmark parameters. After the calibration is complete, the touch screen can start normal operation.

 

 

(3) Determine whether the screen is touched

 

Once the touch screen hardware settings, initialization, and benchmark parameter calibration are complete, a reliable method is needed to determine whether the screen is touched. Wince provides a screen touch detection mechanism, and you can choose whether to interrupt the main processor when a touch event occurs. The function used to determine whether the screen is touched is waitfortouchstate (). When the screen is touched for the first time, the host interruption is awakened, which is called the pen_down interrupt. In this way, the driver can interrupt its execution when the screen is not touched, without consuming any CPU resources. Once the user touches the screen, the driver is awakened and enters the conversion mode.

 

After being awakened, a group of module data is waiting for conversion and an interruption signal is generated. Interrupt is an important way to deal with hardware and software, so most drivers involve interrupt processing. In terms of Interrupt Processing, WinCE adopts a unique method. It divides the interrupt processing into two steps: the interrupt service routine (ISR) and the interrupt service thread (IST ). Specifically, the device interrupt request (IRQ) of each hardware is associated with an ISR. When an interrupt is not blocked, the kernel calls the ISR of the interrupt registration. Because ISR runs in the kernel mode, it should be designed as short as possible. The basic responsibility of Isr is to guide the kernel to schedule and start the appropriate ist. Ist is written in the device driver software module. It obtains or sends data and control code from the hardware and further handles device interruptions.

 

The wince touch screen driver detects the touch pen press status in the interrupt mode. When the touch pen is pressed, an event is triggered to notify a worker thread to start data collection. At the same time, the driver will turn on a hardware timer, as long as it detects that the touch pen is still pressed, it will trigger the same event to notify the working thread to continue to collect data until the touch pen is lifted and the timer is closed. Simply put, the driver uses both touch screen interrupt and timer interrupt. The purpose is not only to monitor the touch pen press and lift status, but also to detect the drag track when the touch pen is pressed. The two logical interruptions of touch screen interruptions are: sysintr_touch is used to generate corresponding interruptions when the touch screen is clicked by touch pen; sysintr_touch_change is used to generate corresponding interruptions when the touch pen leaves.

 

 

(4) obtain stable and dejitters measurement data

 

When developing a touch screen program, you must note that the raw touch measurement data often has some noise and deviation, which is normal. Generally, two consecutive readings can be obtained only when the user holds the resistive touch screen tightly. However, we will find that when the touch pen or finger presses or leaves the touch screen, reading changes are much greater than maintaining stable pressure. This is because the user mechanically connects two planar resistors-the touch layer. When the user presses and releases the touch screen, the electrical connection of the touch screen is in critical state for a short period of time. At this time, we need to discard these readings until the system is stable, otherwise the submitted touch position readings will generate a sharp jump, resulting in serious distortion or touch position drift.

 

In this case, you need to consider the compromise, which is also the key to the design of the touch screen driver. If we require a narrow and stable window, the driver will not be able to track the fast "drag" operation; if the stable window is widened, there may be many risks, these risks include receiving inaccurate touch data or layer connection results described above in the critical state. In this case, we need to use experiments to determine the optimal value suitable for the system.

 

Under normal circumstances, when the screen is touched, the driver should get each stable reading, and convert the raw data into pixel coordinates using a simple linear interpolation method. The coordinates for reading touch points are implemented by the ddsitouchpanalgetpoint () function. In addition, before and after each conversion process, the driver must check and confirm that the screen is still in the touch state. Because we do not want to collect stable readings that are actually in an open-circuit state. Therefore, when reading the touch data, we need to perform dejitter processing on the raw data, and then determine whether there is a stable reading when the screen is touched; if the data is unstable, continue reading the data and perform dejitters until stable data is obtained.

 

Finally, the touch screen driver should send the touch status and location change information to higher-level applications to complete a complete touch operation.