AD714X Input CapTouch® Programmable Controller Linux Driver

Supported Devices

Evaluation Boards

Description

Capacitance Touch Sensors

Capacitance sensors detect a change in capacitance when something or someone approaches or touches the sensor. The technique has been used in industrial applications for many years to measure liquid levels, humidity, and material composition. A newer application, coming into widespread use, is in human-to-machine interfaces. Mechanical buttons, switches, and jog wheels have long been used as the interface between the user and the machine. Because of their many drawbacks, however, interface designers have been increasingly looking for more reliable solutions. Capacitive sensors can be used in the same manner as buttons, but they also can function with greater versatility, for example, when implementing a 128-position scroll bar.

For more info on how these types of sensors work, take a peek at the ADI web site.

Overview

Implementing a capacitive touch sensor solution using the AD714x requires three components:

the AD714x capacitive-to-digital converter IC,

sensors on a PCB or Flex Circuit,

software to communicate with the AD714x.

The sensor traces can be any number of different shapes and sizes. Buttons, wheels, scroll-bar, joypad, and touchpad shapes can be laid out as traces on the sensor PCB.

Many options for implementing the user interface are available to the designer, ranging from simply replacing mechanical buttons with capacitive button sensors to eliminating buttons by using a joypad with eight output positions, or a scroll wheel that gives 128 output positions.

The number of sensors that can be implemented using a single device depends on the type of sensors required. The AD7142 has 14 capacitance input pins and 12 conversion channels, the AD7143 and AD7148 have 8 capacitance input pins and 8 conversion channels, and the AD7147 and AD7147A have 13 capacitance input pins and 12 conversion channels.

Status

Files

In Linux, there are three driver modules for the AD714x:
linux-2.6.x/drivers/input/misc/ad714x.c
linux-2.6.x/drivers/input/misc/ad714x-spi.c
linux-2.6.x/drivers/input/misc/ad714x-i2c.c.

ad714x.c fulfills the common arithmetic and state machines for sliders, keypads, touchpads and so on. ad714x-spi.c and ad714x-i2c.c, which call common probe/remove entries in ad714x.c, merge the bottom ad714x driver into Linux SPI/I2C device driver framework. The code included works with the AD7142 and AD7147 demo board.
Note that this code is covered under the GPL - if you want non-GPL source, have a look at ADI's Web site.

Example platform device initialization

For compile time configuration, it’s common Linux practice to keep board- and application-specific configuration out of the main driver file, instead putting it into the board support file.

For devices on custom boards, as typical of embedded and SoC-(system-on-chip) based hardware, Linux uses platform_data to point to board-specific structures describing devices and how they are connected to the SoC. This can include available ports, chip variants, preferred modes, default initialization, additional pin roles, and so on. This shrinks the board-support packages (BSPs) and minimizes board and application specific #ifdefs in drivers.

Declaring I2C devices

Unlike PCI or USB devices, I2C devices are not enumerated at the hardware level. Instead, the software must know which devices are connected on each I2C bus segment, and what address these devices are using. For this reason, the kernel code must instantiate I2C devices explicitly. There are different ways to achieve this, depending on the context and requirements. However the most common method is to declare the I2C devices by bus number.

This method is appropriate when the I2C bus is a system bus, as in many embedded systems, wherein each I2C bus has a number which is known in advance. It is thus possible to pre-declare the I2C devices that inhabit this bus. This is done with an array of struct i2c_board_info, which is registered by calling i2c_register_board_info().

So, to enable such a driver one need only edit the board support file by adding an appropriate entry to i2c_board_info.

Declaring SPI slave devices

Unlike PCI or USB devices, SPI devices are not enumerated at the hardware level. Instead, the software must know which devices are connected on each SPI bus segment, and what slave selects these devices are using. For this reason, the kernel code must instantiate SPI devices explicitly. The most common method is to declare the SPI devices by bus number.

This method is appropriate when the SPI bus is a system bus, as in many embedded systems, wherein each SPI bus has a number which is known in advance. It is thus possible to pre-declare the SPI devices that inhabit this bus. This is done with an array of struct spi_board_info, which is registered by calling spi_register_board_info().

Page Tools

When you partner with Analog Devices, you get access to best-in-class products, cutting-edge reference materials and a vast network of experts that help you drive from concept to completion fast. It's problem-solving made simple one system at a time.

Interested in the latest news and articles about ADI products, design tools, training and events? Choose from one of our 12 newsletters that match your product area of interest, delivered monthly or quarterly to your inbox.