Design and implementation of touch screen drivers – Hitech

Embedded device contact screens can be divided into five categories according to their technical principles: vector pressure sensing, resistive, capacitive, infrared, and surface acoustic waves. Among them, resistive contact screens are used more in embedded systems, and resistive contact screens can be divided into four wires, five wires, seven wires and so on. Generally speaking, there are several processes to plan and complete the WinCE touch screen driver:

Design and implementation of touch screen drivers – Hitech

Design and implementation of touch screen drivers – Hitech

(1) Equip and initialize the contact screen

During initialization, the contact driver calls the TouchPanelEnable function, which calls the DDSI functions DdsiTouchPanelEnable and DdsiTouchPanelDisable. These two DDSI interface functions are the key to the end of the drive, and they are used to open and close the touch screen hardware. However, in order to reduce power consumption, these two functions can actually operate the hardware without real operation, and only complete the software control.

Together, these equipment and initialization are also required during initialization: one is to create things hTouchPanelEvent and hCalibrationSampleAvailable, the former is triggered under normal conditions when a contact pen is pressed or the need to collect data regularly after being pressed; The latter is triggered when there is a calibration data input in the calibration condition. The second is to check the aborts required for initialization, gIntrTouch (contact screen abort) and gIntrTouchChanged (timer abort), and associate these two aborts to the thing hTouchPanelEvent. The third is to create an ISR thread TouchPanelpISR that waits and handles the touch screen thing hTouchPanelEvent, which is also the only thing source in the entire driver.

(2) Calibrate the reference parameters of the contact screen

After finishing the previous tedious work, the various functions of the driver are now ready to go, and you can now actually touch the screen. But generally speaking, the resistive contact screen needs to be calibrated, which means that during the driver startup process, the MDD layer will call the corresponding DDSI function to read the proofreading data in the registry to proofread the contact screen. In the case of ambition, the calibration procedure only needs to be run once during the initial power-up test of the embedded device, and the reference values are stored in non-volatile memory, eliminating the need for the user to recalibrate during future power-up periods. However, a high-quality touchscreen driver should provide a way for the user to enter the calibration routine to recalibrate if the calibration is inaccurate due to temperature drift or other factors.

In the case of ambition, proofreading a touchscreen datum requires only two sets of raw data, the minimum and maximum values read diagonally across the screen. However, in practice, due to the obvious nonlinearity of many resistive contact screens, if only the minimum and maximum values are simply inserted, the driver will be very inaccurate. Therefore, multiple calibration points need to be obtained in WinCE, and the number of commonly used calibration points is 5.

The method is as follows: (1) firstly, the driver sets the number of calibration points in the function DdsiTouchPanelGetDeviceCaps; (2) The system obtains the screen coordinates of each calibration point in the TouchDriverCalibrationPointGet; (3) It is to display a bearing symbol at the coordinates of the calibration point of the screen interface, and the user needs to press the contact screen accurately in the direction symbol; (4) The driver reads the corresponding contact screen coordinate value through the TouchPanelReadCalibrationPoint function; (5) Then start the next calibration point until the number of cycles set, and send the collected contact screen coordinate value and calibration point screen coordinates to the TouchPanelSetCalibration function for processing, and the function will occur the calibration reference parameter. After calibration, the contact screen is ready to operate normally.

(3) Determine whether the screen is touched

Once the touch screen hardware setup, initialization, and benchmark calibration are complete, the next step is to have a reliable way to determine whether the screen is being touched. WinCE provides a mechanism to detect if the screen has been touched, and there is also the option to abort the host processor if something touches occurs. The driver function that determines whether the screen is being touched is called WaitForTouchState(). An abort that wakes up the host when the screen is first touched, called PEN_DOWN abort. This allows the driver to abort its execution when the screen is not being touched, without consuming any CPU resources, and as soon as the user touches the screen, the driver wakes up and goes into conversion form.

When awakened, there is a set of analog-to-digital data waiting to be converted and an abort signal occurs. Abort is an important way for hardware to deal with software, so most drivers involve abort handling. As far as abort processing is concerned, WinCE has chosen a unique approach. It divides abort processing into two steps: Abort Service Routine (ISR) and Abort Service Thread (IST). Specifically, each hardware device abort request (IRQ) is associated with an ISR, and when an abort occurs and is not masked, the kernel calls the abort registered ISR. Since ISRs operate in kernel form, they should be planned for as short as possible, and the basic responsibility of ISRs is to guide kernel scheduling and initiate appropriate IST. IST is written in a device driver software module, which obtains data and manipulates code from or to the hardware and further processes device aborts.

The WinCE contact screen driver uses the abort method to detect the pressing status of the contact pen, and when it detects that the abort occurs when the contact pen is pressed, it will trigger an event to tell a job thread to start collecting data. Together, the driver will flip over a hardware timer, just detect that the contact pen is still pressing, and tell the job thread to continue collecting data until the contact pen is lifted and the timer is closed. To put it simply, the driver will choose the two abort sources together: contact abort and timer abort. The intention is not only to monitor the pen pressing and lifting, but also to detect the dragging trajectory when the pen is pressed. The two logical aborts of the contact screen are as follows: SYSINTR_TOUCH is used for the corresponding abort when the contact pen clicks on the contact screen; SYSINTR_TOUCH_CHANGE is used to abort when the contact pen is disengaged.

(4) Obtain stable and de-fluttering measurement data

When developing a contact screen program, it is normal to note that the original contact measurement data often has some noise and deviation. Generally speaking, it takes the user to hold the resistive contact screen tightly to get two consecutive readings, however we will find that when the stylus or finger is pressed on or off the contact screen, the change in the reading is much greater than when maintaining a steady pressure. This is due to the fact that the user mechanically connects the two planar resistor-contact layers, and when the user presses and releases the contact screen, the electrical connection of the contact screen is in a critical state for a short period of time. At this point, we need to discard these readings until the system is stable, otherwise the submitted contact azimuth readings will jump significantly, resulting in significant distortion or contact azimuth drift.

At this time, a compromise on requirements is also the key to touchscreen-driven planning. If we require a narrow stable window, the driver will not be able to keep track of the fast "drag"; If the stability window is widened, there are many dangers that can be exposed, including the receipt of inaccurate contact data, or the results of layer articulation described above in a critical state. At this point, the requirements are tested to determine the optimal value for the system.

Under normal circumstances, the driver should get every safe reading when the screen is touched, and use simple linear interpolation to convert the raw data into pixel coordinates. Reading the coordinates of the touchpoint is done by the DdsiTouchPanalGetPoint() function. In addition, before and after each conversion process, it is necessary for the driver to check and confirm that the screen is still being touched. Since we don't want to collect stable readings that are actually in an "open road situation". Therefore, when reading the contact data, we need to deflutter the original data, and then determine whether there is a stable reading when the screen is contacted; If it is unstable, continue to read the data and perform defluttering until it stops when stable data is obtained.

Finally, the contact screen driver should send the contact status and orientation change information to the higher-level user software to complete a complete contact operation.

Design and implementation of touch screen drivers – Hitech

Sections viewed

Contact

working hours