Fundamentals of driving the capacitive touch screen for Android platform

This address, reproduced please specify: http://blog.csdn.net/dearsq/article/details/51251009

How Hardware Works

The working principle of the touchscreen is to report the values of coordinate values, x-axis and y-axis. So the input subsystem is used in Linux to implement it.
Specific hardware principles can refer to this article capacitive touch-screen hardware fundamentals.

This paper mainly summarizes the driving principles and porting steps on Android platform, and summarizes the problems encountered during the transplant.

Driving Fundamentals

The drive portion of the touchscreen involves about three points:

Interrupt

The interrupt handling mechanism for the Linux kernel is as follows:

To find a balance between breaking execution times as short as possible and breaking processing to complete a large amount of work , Linux decomposes interrupt handlers into two halves: top half and bottom half (bottom half).

The top half completes as few of the more urgent functions as possible, and it often simply reads the interrupt status in the register and clears the interrupt flag to perform a " register break " job. A "registration break" means that the bottom half of the handler is hooked up to the bottom half of the device's execution queue.
In this way, the top half executes quickly and can serve more interrupt requests. Now, the focus of the interrupt processing is on the bottom half of the head, which completes most of the task of interrupting the event.
The bottom half of the interrupt handler is almost everything, and can be interrupted by a new interrupt , which is the biggest difference between the bottom half and the top half, as the top half is often designed to be non-disruptive. The bottom half is relatively non-urgent and relatively time-consuming and does not execute in the hardware Interrupt service program.

In a word, the interruption should be as short as possible, the system will resume normal debugging as soon as possible, so interrupt triggering, interrupt execution is separated, that is, the "upper half (interrupt trigger), the bottom half (interrupt execution)."

The upper half (interrupt trigger), bottom half (interrupt execution) is the interrupt context .
The lower half of the general Tasklet and Workqueue to achieve, touch screen is implemented by the Workqueue .

Work queue

The Tasklet works in a soft interrupt context, and the work queue works in the kernel process.
The Essential reason for this difference is that, in the work queue mechanism, the deferred work is handed over to a kernel thread called the worker thread (the worker threads) to complete (the single core is typically given the default thread events/0). Therefore, in this mechanism, the kernel is in the process context when it performs the remaining work of the interrupt. This means that the interrupt code executed by the work queue shows some of the characteristics of the process, and most typically, it can be re-dispatched or even slept.
For the tasklet mechanism (the same is true for interrupt handlers), the kernel executes in the interrupt context (interrupt context). The interrupt context has nothing to do with the process, so you can't sleep in the interrupt context.
Therefore, it should not be difficult to choose Tasklet or Work queue to complete the lower part. The work queue is no doubt your best option when the delayed part of the program needs sleep, otherwise, use Tasklet.

Interrupt context

Homogeneous concept: process Context : The general process runs in the user state, if the process makes a system call, then the program in the user space into the kernel space, and said that the kernel represents the process running in the kernel space. Because the user space and kernel space have different address mappings, and the process of user space to pass many variables, parameters to the kernel, the kernel will also save the user process of some registers, variables, etc., so that the system call back to the user space to continue execution. This results in a process context.

The process context actually refers to the value in all registers of the CPU, the state of the process, and the contents of the stack when a process executes .

How to use the Task Force column

1. Define a task queue using struct work_struct.

struct work_struct my_wq;

2. Define a handler function

void my_wq_func(strcut work_struct *work);

3. Initialize the work queue and bind the handler function

INIT_WORK(&my_wq,my_wq_func);

4. Scheduling Work Queue execution functions

schedule_work(&my_wq);

code example

/* Define work queues and related functions */structWork_struct Xxx_wq;voidXxx_do_work (structWork_struct *work);/ * Bottom half of the execution function * /voidXxx_do_work (structWork_struct *work) {...}/ * Top half of the execution function * /Irqreturn_t Xxx_interrupt (intIrqvoid*dev_id) {... schedule_work (&XXX_WQ); ...returnirq_handled;}/ * Device driver module load function * /intXxx_init (void){    .../ * Request interrupted * /result = Request_irq (XXX_IRQ, Xxx_interrupt,0,"XXX", NULL);    ...    Init_work (&xxx_wq, xxx_do_work); ...}/ * Device driver module unload function * /voidXxx_exit (void){    .../ * Release interrupt * /FREE_IRQ (XXX_IRQ, xxx_interrupt); ...}

Input Subsystem

The input subsystem consists of the input subsystem device driver layer , the input subsystem core layer (Inputcore) and the input Subsystem Event processing Layer (Handler).
The device driver layer provides read and write access to the hardware registers and translates the response of the underlying hardware to the user input to the standard input event, which is then submitted to the event processing layer through the core layer;
The core layer provides the programming interface of the device driver layer, and the programming interface of the event processing layer is provided.
The Event processing layer provides the interface of the unified access device and the event processing that the driver layer submits for our user-space applications.

The relationship between input subsystem and driver

Implementation principle of input Subsystem drive layer

The Input device is described by the INPUT_DEV structure, defined in the input.h.
You need to follow these steps:
1. The driver module loading function sets the input device to support input subsystem data;
2. Register the input device with the input subsystem;
3. Commit the key/coordinate state corresponding to the event that occurs when the input device takes place.

Ev_syn0x00Synchronization Event Ev_key0x01Key Event Ev_rel0x02relative coordinates (e.g., mouse movement, which is reported as relative to the last position offset) ev_abs0x03Absolute coordinates (e.g. touch screen and joystick, report absolute coordinate position) Ev_msc0x04Other ev_led0x11LED ev_snd0x12Sound Ev_rep0x14Repeat ev_ff0x15Force FeedbackThe functions used to submit the more commonly used event types to the input subsystem are:voidInput_report_key (structInput_dev *dev, unsignedintCodeint value);//function to submit key eventsvoidInput_report_rel (structInput_dev *dev, unsignedintCodeint value);///Submit a function for relative coordinate eventsvoidInput_report_abs (structInput_dev *dev, unsignedintCodeint value);//Submit the function of absolute coordinate event//After the event of the input device is submitted, the event must be synchronized in such a way that it informs the input system that the device driver has issued a complete report:voidInput_sync (structInput_dev *dev)

Multi-Touch protocol for Linux and Android

Linux & Android Multi-Touch protocol

Fundamentals of driving the capacitive touch screen for Android platform