world leader in high performance signal processing
This version (05 Sep 2012 14:09) was approved by mhennerich.The Previously approved version (09 Nov 2011 11:21) is available.Diff

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.

ad40-10_07a.jpg ad40-10_07b.jpg ad40-10_07c.jpg ad40-10_07d.jpg ad40-10_07e.jpg ad40-10_07f.jpg

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.

Configuration

Software configurable features

Source Code

Status

Source Mainlined?
git Yes

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.

21 Oct 2010 16:10 · Michael Hennerich

platform data, defines how the PCB info is implemented.

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.

For more information see: Documentation/i2c/instantiating-devices

21 Oct 2010 16:10 · Michael Hennerich

For AD7142 demo board, the platform information is:

file: arch/blackfin/mach-bf537/boards/stamp.c

static struct ad714x_button_plat ad7142_i2c_button_plat[] = {
	{
		.keycode = BTN_1,
		.l_mask = 0,
		.h_mask = 0x1,
	},
	{
		.keycode = BTN_2,
		.l_mask = 0,
		.h_mask = 0x2,
	},
	{
		.keycode = BTN_3,
		.l_mask = 0,
		.h_mask = 0x4,
	},
	{
		.keycode = BTN_4,
		.l_mask = 0x0,
		.h_mask = 0x8,
	},
};

file: arch/blackfin/mach-bf537/boards/stamp.c

static struct ad714x_platform_data ad7142_i2c_platform_data = {
	.button_num = 4,
	.button = ad7142_i2c_button_plat,
	.stage_cfg_reg =  {
		/* fixme: figure out right setting for all comoponent according
		 * to hardware feature of EVAL-AD7142EB board */
		{0xE7FF, 0x3FFF, 0x0005, 0x2626, 0x01F4, 0x01F4, 0x028A, 0x028A},
		{0xFDBF, 0x3FFF, 0x0001, 0x2626, 0x01F4, 0x01F4, 0x028A, 0x028A},
		{0xFFFF, 0x2DFF, 0x0001, 0x2626, 0x01F4, 0x01F4, 0x028A, 0x028A},
		{0xFFFF, 0x37BF, 0x0001, 0x2626, 0x01F4, 0x01F4, 0x028A, 0x028A},
		{0xFFFF, 0x3FFF, 0x0000, 0x0606, 0x01F4, 0x01F4, 0x0320, 0x0320},
		{0xFFFF, 0x3FFF, 0x0000, 0x0606, 0x01F4, 0x01F4, 0x0320, 0x0320},
		{0xFFFF, 0x3FFF, 0x0000, 0x0606, 0x01F4, 0x01F4, 0x0320, 0x0320},
		{0xFFFF, 0x3FFF, 0x0000, 0x0606, 0x01F4, 0x01F4, 0x0320, 0x0320},
		{0xFFFF, 0x3FFF, 0x0000, 0x0606, 0x01F4, 0x01F4, 0x0320, 0x0320},
		{0xFFFF, 0x3FFF, 0x0000, 0x0606, 0x01F4, 0x01F4, 0x0320, 0x0320},
		{0xFFFF, 0x3FFF, 0x0000, 0x0606, 0x01F4, 0x01F4, 0x0320, 0x0320},
		{0xFFFF, 0x3FFF, 0x0000, 0x0606, 0x01F4, 0x01F4, 0x0320, 0x0320},
	},
	.sys_cfg_reg = {0x0B2, 0x0, 0x690, 0x664, 0x290F, 0xF, 0xF, 0x0},
};

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().

For more information see: Documentation/spi/spi-summary

21 Oct 2010 16:10 · Michael Hennerich

For AD7147 demo board, the platform information is:

file: arch/blackfin/mach-bf537/boards/stamp.c

static struct ad714x_slider_plat ad7147_spi_slider_plat[] = {
	{
		.start_stage = 0,
		.end_stage = 7,
		.max_coord = 128,
	},
};

file: arch/blackfin/mach-bf537/boards/stamp.c

static struct ad714x_button_plat ad7147_spi_button_plat[] = {
	{
		.keycode = BTN_FORWARD,
		.l_mask = 0,
		.h_mask = 0x600,
	},
	{
		.keycode = BTN_LEFT,
		.l_mask = 0,
		.h_mask = 0x500,
	},
	{
		.keycode = BTN_MIDDLE,
		.l_mask = 0,
		.h_mask = 0x800,
	},
	{
		.keycode = BTN_RIGHT,
		.l_mask = 0x100,
		.h_mask = 0x400,
	},
	{
		.keycode = BTN_BACK,
		.l_mask = 0x200,
		.h_mask = 0x400,
	},
};

file: arch/blackfin/mach-bf537/boards/stamp.c

static struct ad714x_platform_data ad7147_spi_platform_data = {
	.slider_num = 1,
	.button_num = 5,
	.slider = ad7147_spi_slider_plat,
	.button = ad7147_spi_button_plat,
	.stage_cfg_reg =  {
		{0xFBFF, 0x1FFF, 0, 0x2626, 1600, 1600, 1600, 1600},
		{0xEFFF, 0x1FFF, 0, 0x2626, 1650, 1650, 1650, 1650},
		{0xFFFF, 0x1FFE, 0, 0x2626, 1650, 1650, 1650, 1650},
		{0xFFFF, 0x1FFB, 0, 0x2626, 1650, 1650, 1650, 1650},
		{0xFFFF, 0x1FEF, 0, 0x2626, 1650, 1650, 1650, 1650},
		{0xFFFF, 0x1FBF, 0, 0x2626, 1650, 1650, 1650, 1650},
		{0xFFFF, 0x1EFF, 0, 0x2626, 1650, 1650, 1650, 1650},
		{0xFFFF, 0x1BFF, 0, 0x2626, 1600, 1600, 1600, 1600},
		{0xFF7B, 0x3FFF, 0x506,  0x2626, 1100, 1100, 1150, 1150},
		{0xFDFE, 0x3FFF, 0x606,  0x2626, 1100, 1100, 1150, 1150},
		{0xFEBA, 0x1FFF, 0x1400, 0x2626, 1200, 1200, 1300, 1300},
		{0xFFEF, 0x1FFF, 0x0,    0x2626, 1100, 1100, 1150, 1150},
	},
	.sys_cfg_reg = {0x2B2, 0x0, 0x3233, 0x819, 0x832, 0xCFF, 0xCFF, 0x0},
};

Adding Linux driver support

To select it from menuconfig:

Device Drivers  --->
  Input device support  --->
   [*]   Miscellaneous devices  --->
    <*>   Analog Devices AD714x Capacitance Touch Sensor
       <*>     support I2C bus connection
       <*>     support SPI bus connection

Hardware configuration

We connected the AD7142 demo board to the TWI/I2C connector and AD7147 demo board to the SPI connector on the BF537 STAMP board.

For BF537 STAMP board, please set SW5-3 off as the interrupt input.

And For AD7147 eval-board, please set S4-2 on and other positions off.

Driver testing

Some testing output from the event_test application:

root:~> modprobe ad7142.ko 
input: ad7142 joystick as /class/input/input0
ad7142_js_attach: at 0x58
root:~> event_test /dev/input/event0 
Input driver version is 1.0.0
Input device ID: bus 0x18 vendor 0x1 product 0x1 version 0x100
Input device name: "ad7142 joystick"
Supported events:
  Event type 0 (Reset)
    Event code 0 (Reset)
    Event code 1 (Key)
  Event type 1 (Key)
    Event code 103 (Up)
    Event code 105 (Left)
    Event code 106 (Right)
    Event code 108 (Down)
    Event code 294 (BaseBtn)
    Event code 295 (BaseBtn2)
    Event code 296 (BaseBtn3)
    Event code 297 (BaseBtn4)
Testing ... (interrupt to exit)
Event: time 398.520833, type 0 (Reset), code 0 (Reset), value 0
Event: time 400.734865, type 1 (Key), code 108 (Down), value 1
Event: time 400.734874, type 0 (Reset), code 0 (Reset), value 0
Event: time 400.853353, type 1 (Key), code 108 (Down), value 0
Event: time 400.853360, type 0 (Reset), code 0 (Reset), value 0
Event: time 400.930182, type 1 (Key), code 103 (Up), value 1
Event: time 400.931390, type 0 (Reset), code 0 (Reset), value 0
Event: time 401.046258, type 1 (Key), code 103 (Up), value 0
Event: time 401.047461, type 0 (Reset), code 0 (Reset), value 0
Event: time 402.361193, type 1 (Key), code 294 (BaseBtn), value 1
Event: time 402.362403, type 0 (Reset), code 0 (Reset), value 0
Event: time 402.555558, type 1 (Key), code 294 (BaseBtn), value 0
Event: time 402.556760, type 0 (Reset), code 0 (Reset), value 0
Event: time 402.942508, type 1 (Key), code 295 (BaseBtn2), value 1
Event: time 402.942516, type 0 (Reset), code 0 (Reset), value 0

More Information