PROJECT REPORT ON

I2C BASED ACCELEROMETER CHIP DRIVER ON

EMBEDDED LINUX

SUBMITTED TO C-DAC HYDERABAD IN PARTIAL FULFILLMENT OF

THE REQUIREMENT FOR THE AWARD OF

DIPLOMA IN EMBEDDED SYSTEMS DESIGN

(DESD)

SUBMITTED BY:
POLA OMKAR ESHWAR
PRATEEK JAIN
PRATHESHNA PADMASANAM
RAHUL KR DAS

-140250330046
-140250330047
-140250330048
-140250330049

CENTRE FOR DEVELOPMENT OF ADVANCED COMPUTING

HYDERABAD

CERTIFICATE

This is to certify that this is a bonafied record of project work done by POLA OMKAR ESHWAR,
PRATEEK JAIN, PRATHESHNA PADMASANAM, RAHUL KR DAS under the guidance of Mr. A
RAGHAVENDRA RAO in partial fulfillment of the requirement of Diploma In Embedded System
Design at C-DAC Hyderabad for academic session of February 2014.

PROJECT GUIDE
Name: Mr. A Raghavendra Rao
Designation: Project Engineer

ACKNOWLEDGEMENTS
We have taken efforts in this project. However, it would not have been possible without the kind
support and help of many individuals and organizations. I would like to extend my sincere thanks to all
of them.
We are highly indebted to CDAC for their guidance and constant supervision as well as for providing necessary information regarding the project & also for their support in completing the project.
We would like to express our gratitude towards our parents & member of DESD for their kind
co-operation and encouragement which help me in completion of this project.
We would like to express our special gratitude and thanks to industry persons for giving us such
attention and time.
Our thanks and appreciations also go to our colleague in developing the project and people who
have willingly helped us out with their abilities.

ABSTRACT
This project describes the development of I2C device drivers for the BeagleBone Black development
board, built on AM335X SOC from Texas Instruments running Angstrom Embedded Linux
distribution. An I2C based client driver has been implemented for MMA7660FC which is a 3-axis
orientation/motion sensor. The main functional aspect of this project is the client driver which
implements specific functionalities like detection of accelerometer movements in the X, Y, Z directions,
shake detection, device configuration and power management.
The entire basis of the prototype is to have an interfacing system that would allow an user application
to read the sensor movements through the I2C based chip driver. These sensor movements are
transmitted to an android device wirelessly via Bluetooth and display the changes in the sensor
movements on the user interface of the android application.

INDEX
1. Introduction
1.1 Linux on embedded systems
1.2 Linux Device Drivers
1.3 Introduction to I2C protocol
2. Design Goals
3.

Development
3.1
3.2
3.3
3.4
3.5

Project Setup
Linux I2C Subsystem
I2C Client Driver
Server Application
Client Application

Testing
4.1
4.2
4.3
4.4

Testing of the accelerometer sensor through i2c tools

Testing of the accelerometer sensor through evdev interface
Testing of the accelerometer sensor through our test application.
Testing of the accelerometer sensor using android application.

5.

Applications

6.

Conclusion

7.

References

8.

Appendix
-Source codes

1. Introduction

1.1 Linux on embedded systems

Today Linux is the operating system choice for many computer systems which include, not only
desktop and server supercomputers, but also a wide range of special-purpose electronic devices known
as embedded systems. An em bedded system is specifically designed to perform a set of designated
activities, and it generally uses custom, hetero-geneous processors. This makes Linux a flexible
operating system capable of running on a variety of architectures, such as ARM, PowerPC, MIPS,
SPARC, x86, and many others and this is known as embedded linux.
However, this flexibility doesnt come for free. While its true that the Linux highly modular
architecture facilitates the porting phase, still a lot of efforts are required to build new kernel
components to fully support the target platform. A big part of these efforts are in developing the lowlevel interfaces commonly referred to as device drivers. A device driver is a piece of software designed
to direct control a specific hardware resource using an hardware-independent well defined interface.

1.2 Linux Device Drivers

In computing, a device driver is a computer program that operates or controls a particular type of
device that is attached to a computer. A driver provides a software interface to hardware devices,
enabling operating systems and other computer programs to access hardware functions without needing
to know precise details of the hardware being used.
A driver typically communicates with the device through the computer bus or communications
subsystem to which the hardware connects. When a calling program invokes a routine in the driver, the
driver issues commands to the device. Once the device sends data back to the driver, the driver may
invoke routines in the original calling program. Drivers are hardware-dependent
An overview of the kernel and the driver mapped with the hardware is shown in Figure.1

In Linux, a driver is always interfacing with a

framework that allows the driver to expose the
hardware features in a generic way.

A bus infrastructure , part of the device model,

to detect/communicate with the hardware.

A driver provides specific functionalities of

the device for the user applications.

A driver provides an interface for the user

applications to directly communicate with the
hardware attached to the system.

Figure.1: Device and driver model

1.3 Introduction to I2C Protocol

The Inter-Integrated circuit, or I2C , is a synchronous master-slave two wire serial bus or interface
used for interfacing peripherals like accelerometers, temperature sensors, LCD displays, etc in
embedded systems. I2C bus transactions takes place between a master host adapter(or controller) and
client devices ( or slaves).
The I2C bus consists of two bi-directional lines, one line for data (SDA) and one for clock (SCL), by
means of which a single master device can send informations serially to one or more slave devices
(Figure 2). Each I2C device attached to the bus has its own unique address. The standard I2C specifies
two different addressing schema, 7 and 10 bits, allowing at most 128 and 1024 devices connected at the
same time.

Figure 2: I2C serial bus

I2C is a single master or ( multiple master) bus protocol where the master initiates the communication
by generating clock pulses in the SCL line and the slave responds and communicates with the master
through the SDA line. The master controls the data transaction on the I2C bus and can communicate
with multiple slave devices on the same bus using their unique device addresses. Though it is a
bidirectional data bus, the communication is half-duplex since a single data line is used for data
transfer.
It is a low bandwidth protocol which allows up to 100Kbps in the standard mode and 400Kbps in the
fast mode. It is thus suitable for interfacing slow peripherals.
Prior to any data transaction on the I2C bus, master device generates a start condition to inform the I2C
devices about the beginning of a transaction and after the data transfer , it issues a stop condition to end
the transaction and release the bus.
Data transfer takes place one byte at a time. In 7-bit addressing mode, the slave address occupies the
seven most significant bits of the first byte, with the least significant bit serving as a read/write flag to
indicate whether data will be written to the slave (0) or data will be read from the slave (1). For
every byte received, the slave device sends back an acknowledge bit. Figure 3 shows an example of a
typical I2C transaction .

Figure 3: I2C bus transaction

2. Design Goals
1. Design an I2C based client driver (chip driver) for a 3- axis orientation/motion detection
sensor ( mma7660fc) interfaced with a Beaglebone Black embedded system from Texas
Instruments running Angstrom Linux distribution.
2. Implementation of specific functionalities by the client driver like device configuration, reading
the sensor movements in all the 3 axes, shake detection , power management.
3.

Develop an user test application which reads the accelerometer sensor movements (x,y,z data
register values) and the shake detection exported by the driver to the user space.

4. Develop a server application running on the Beaglebone black using RFCOMM protocol which
reads the sensor movements and shake detection and transmits it to a client application running
on an android device via Bluetooth.
5. Develop an android application (client) which receives the sensor values and display the values
in its user interface. It continuously updates the user-interface with the incoming values and
detects the shake on the accelerometer.

3. Development
3.1 Project setup
Development Board :
In this project we used beaglebone black from Texas Instruments board is used for developing
advanced applications featuring 512 Mb DDR3 ram, 2gb on-board emmc flash storage, 3d graphics
accelerator, USB support for power and communication , Ethernet, HDMI, micro-sd card connector ,
46 pin GPIO (expansion headers) for connecting external devices to the board.
The core of the board is built around a system -on-chip (Soc) AM335x 1GHz ARM Cortex-A8.

Figure 4: Beaglebone black

3-axis Orientation/motion detection sensor:

The accelerometer being used is an I2C based 3 -axis motion detection sensor mma7660fc from
Freescale Semiconductors . It is a +-1.5g 3 axis accelerometer with digital output. It is a low power
,low profile capacitive MEMS sensor featuring a low pass filter and conversion to 6 bit digital values at
a user configurable samples/second from 1 to 120 samples/second. The sensor can be used for sensor
data changes, orientation detection for Portrait/landscape capability, gesture detection including shake
and tap detection , auto wake/sleep feature for low power consumption.

Bluetooth and Android:

The Bluetooth dongle used for wireless communication is Cambridge Silicon Radio, Ltd Blue (HCI
mode) interfaced with the beaglebone black acting as a server for wireless transmission.
Android device used is HTC explorer for running the android application as a client for wireless
reception of messages from the server.

Software Development Platform:

After the hardware platform is ready, the first thing is to get the updated linux kernel source from
( http://github.com ) by running an appropriate script and configure it for the target board.
For developing the applications, x86 platform running Ubuntu is used as a host computer. So to update
the kernel for the arm based platform, we used a cross-compiler (arm-gcc-linux-gnueabi toolchain) for
compiling the kernel source and installing the modules for the target platform.

For developing the android applications, android SDK platform is used .

3.2 Linux I2C Subsystem

Figure 5: I2C subsystem

Linux kernel I2C framework shown in figure 5 consists of a core layer which contains all the routines
and the data structures available to host adapter drivers and client drivers. The core also provides a
level of indirection that renders client drivers independent of the host adapter, allowing them to work
unchanged even if the client device is used on a board that has a different I2C host adapter.
In addition to the core, the kernel I2C infrastructure consists of the following:

Device drivers for I2C host adapters. They fall in the realm of bus drivers and usually consist of
an adapter driver and an algorithm driver. The former uses the latter to talk to the I2C bus.

Device drivers for I2C client devices.

I2c-dev, which allows the implementation of user-mode I2C client driver.

The kernel breaks down I2C into Buses and Devices, and then further breaks down buses into
Algorithms and Adapters, and devices into Drivers and Clients.

I2C bus driver

Algorithms

An Algorithm performs the actual reading and writing of I2C messages to the hardware this
may involve bit banging GPIO lines or writing to an I2C controller chip. An Algorithm allows
to define function pointers to functions that can write I2C messages (master_xfer) or SMBus
messages (smbus_xfer).
Representation in I2C core: struct i2c_algorithm
Adapters

An Adapter effectively represents a bus it is used to tie up a particular I2C/SMBus with an

algorithm and bus number.
Representation in I2C core: struct i2c_adapter

I2C bus drivers are usually implemented as part of the I2C core to control the I2C host adapter
device acting as a master which controls the data transactions over the I2C bus. We have
implemented the I2C client driver for the motion sensor.

3.3 I2C Client Driver

In this section, we provide an overview of an I2C client driver for the accelerometer sensor interfaced
with the beaglebone through an I2C interface. This section describes the algorithm for the client driver
implementation .
I2C devices can be classified into two sections:

1. client
2. driver

Client: Represents a chip (slave) like the accelerometer. It is represented by a structure

struct i2c_client in the I2C core which holds the chip address, pointer to the adapter, etc.
Driver: Represents a device driver for a particular class of I2C devices and is represented by a
structure struct i2c_driver which contains function pointers for probe and remove functions.
1. Initialization : When the driver is loaded in the kernel, during the initialization phase the
driver registers itself with the I2C framework using the API i2c_add_driver() as shown below:
------------------------------------------------------------------------------------------------------------------struct i2c_driver name_driver
.driver = {
.name="driver_name"
},
.probe = mma7660fc_probe,
.remove = mma7660fc_remove,
.id_table = chip_id_table,
};
init(){
i2c_add_driver(&name_driver);
}

------------------------------------------------------------------------------------------------------------------Driver registration with the I2C framework

The id_table member of the structure informs the I2C framework about which devices are supported
by the driver.
--------------------------------------------------------------------------------------------------------struct id_device_id _name[] ={
{device_name ,device_id},
{ },
};

----------------------------------------------------------------------------------------------------------2. Instantiating I2C device: Unlike USB or PCI, where auto-detection is usually preferred as they can
be plugged in and out at any time, I2C cannot be used as a hot pluggable device since the I2C bus is a
system bus in our system. So auto-detection is not preferred. Instead, the kernel should know which
devices are connected on which bus segment and the address assigned to each device on the bus. This is
achieved by instantiating or declaring the I2C device explicitly before the driver for the device is
loaded in the kernel.
We explicitly declared our client directly from the user space through the sysfs interface.
The sysfs interface is added in every I2C segment with two attribute files for the user to create and
delete the device using appropriate parameters.
---------------------------------------------------------------------------------------------------------------echo mma7660fc 0x4c > /sys/bus/i2c/devices/i2c-2/new_device ;
echo 0x4c > /sys/bus/i2c/devices/i2c-2/delete_device ;

----------------------------------------------------------------------------------------------------------------The name of the accelerometer sensor is mma7660fc residing at 0x4c address space of I2C bus-2.
3. Probing : When the driver is loaded, device/driver binding takes place and after the device is
successfully binded with the driver, the probe function of the driver is called. The binding
process binds a device with the appropriate driver that controls it by matching the name
registered by the driver with the device name.
This is known as probing . The probe function is called passing a pointer to the client device as
a parameter.

The probe function performs the following operations:

1. Allocate memory for the device specific structure.
2.

Save the address of the client in the private device specific structure.

3.

Configure the sensor.

Enable the sensor for the shake detection

Configure it in active mode to enable the sensor measurement system.

4. Registration with the input subsystem.

To enable device polling.

Dynamically create device nodes during runtime.

Input Subsystem : The input subsystem is part of the I2C framework. The representation of an input
subsystem is shown in Figure 6.

Figure 6: Input subsystem

The input subsystem is divide into three sections: 1. Device drivers

2. Input core
3. Event drivers

An Input subsystem provides an easy event interface for dispatching input events to user applications.
The input driver does not have to create and manage /dev nodes and related access methods. Instead, it
can simply invoke input APIs to send the sensor movements to the user space. The device nodes are
created dynamically a runtime.
From Figure 6, we can say the subsystem contains two classes of drivers that work in tandem: event
drivers and device drivers. Event drivers are responsible for interfacing with applications, whereas
device drivers are responsible for low-level communication with input devices. Both event drivers and
device drivers can avail the services of an efficient, bug-free, reusable core, which lies at the heart of
the input subsystem.
Event drivers are standardized and available for all input classes, we will use a suitable existing event
driver via the input core to interface with user applications.
The Evdev Interface:
Evdev interface is a generic input event driver. Each packet produced by evdev has the following
format :
--------------------------------------------------------------struct input_event {
struct timeval time ;
__u16 type;
__u16 code;
__s32 value

/*
/*
/*
/*

Timestamp */
Event type */
Event code */
Event value */

}
----------------------------------------------------------------------

Device Polling: In order to export the input events produced the sensor to the evdev interface, the
driver needs to continuously poll the device at regular intervals.
To implement the polling feature the driver registers itself with the kernels input subsystem, this
involves registering open(), close() and poll() call- back functions, specifying the polling interval,
setting up the type of events involved, etc. The input subsystem takes care of calling the poll() function
at the specified rate, registering any event notification reported by the driver and dispatching it to the
user-space via sysfs in /dev/input/eventX (X is a numeric identifier assigned when the driver registers
with the input core). A snippet of the registration with the input subsystem is shown below:
-----------------------------------------------------------------------------------------------------------------struct input_polled_device *input_polled;
struct input_device *input;
/* allocate memory for input device */
input_polled = input_allocate_polled_device();
/* setup input parameters */
input_polled->poll = mma7660_poll;
input_polled->poll_interval = POLL_INTERVAL;
input = input_polled->input;
input->name = "mma7660fc_accelerometer";
input->dev.parent = &priv->client->dev;
input->id.bustype = BUS_I2C;
/* setting up the input events */
/* event-type (relative events) */
set_bit(EV_REL, input->evbit);
/* event codes */
set_bit(REL_X, input->relbit);
set_bit(REL_Y, input->relbit);
set_bit(REL_Z, input->relbit);
/* registraton with input core */
input_register_polled_device(priv->polled_dev);
-----------------------------------------------------------------------------------------------------------Registration with the input subsystem

3.4 Server Application

The server application runs on the beaglebone black using RFCOMM bluetooth protocol for wireless
communication. A concurrent server for handling multiple clients is much more efficient but we have
only configured it for a single client since we are using it as a test application to demonstrate the
working of the driver.
RFCOMM protocol : It is one of the two protocols supported by the bluetooth protocol host stack.
The Radio Frequency Communications (RFCOMM) protocol is a reliable streams-based protocol. This
is a general purpose transport layer protocol that emulates RS-232 serial ports.
Using this protocol, the server communicates with the client through a channel by creating
a
bluetooth socket and then waiting for the client request for communication. As soon as the client make
a request for communication, the server running on the board accepts the connection.
The server reads the sensor movement values in all the three axes (x, y and z data registers) and shake
detection of the accelerometer and transmits it via the connected RFCOMM channel to the android
application.

3.5 Client Application

The client application is developed as an android application running on an android device.
The application framework provides access to the Bluetooth functionalities through appropriate APIs
for establishing a RFCOMM channel with the server side for communication.
Bluetooth Adapter: It represents local Bluetooth adapter. It checks for the Bluetooth adapter by
calling the getDefaultAdapter() method.
Bluetooth Device: Represents a remote Bluetooth device.This is used to request a connection with a
remote device through a Bluetooth socket.
Bluetooth socket: Represents the interface for a Bluetooth socket .This is the connection point that
allows an application to exchange data with another Bluetooth device via InputStream and
OutputStream.

The Bluetooth adapter instantiates the remote device with the known MAC address of the server for
ommunication. For creating a Bluetooth socket, we used the method of Bluetooth reflection for binding
the socket with the same RFCOMM channel used by the server application so that the client and the
server can connect properly. After the connection is established, the incoming data is received from the
inputstream and stored in a buffer for later use. A snippet of the bluetooth socket creation using
bluetooth reflection is shown below:

Bluetooth Reflection
****************************************************************************
Method
m=device.getClass().getMethod("createInsecureRfcommSocket",new
{int.class });

Class[]

btsocket=(BluetoothSocket)m.invoke(device,Integer.valueOf(22));
***********************************************************************************

In this client application, we used multi-threading for receiving the data from the Inputstream and
updating the user interface with the received data. The child thread is responsible for establishing the
connection between the client and the server and then continuously receive the incoming packet and
storing it in a buffer.
After receiving the incoming packet from the server, the child thread calls the thread handler in the
main thread and passes the data packet to it. The thread handler installed in the main thread receives the
packet and display the sensor movement values to the x, y and z axis fields of the user interface and
also detects the shake on the accelerometer.

4. Testing
4.1. Testing of the accelerometer sensor through i2c tools:
Usually i2c devices are controlled by a kernel driver. But it is also possible to access the devices from
user-space without any driver with the help of i2c tools. It allows to test the device before the driver
development from the user-space. The i2c-tools need to be installed in the system.

I2cdetect -r 2

: To detect the i2c sensor on the i2c adapter 2

.................................................................................................................................
0 1 2 3 4 5 6 7 8 9 a b c d e f
00:
-- -- -- -- -- -- -- -- -- -- -- -- -10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -40: -- -- -- -- -- -- -- -- -- -- -- -- 4c -- -- -50: -- -- -- -- UU UU UU UU -- -- -- -- -- -- -- -60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -70: -- -- -- -- -- -- -- -.......................................................................................................................................
i2c-2 address space: The accelerometer sensor is found at 0x4c address.
I2cdump 2 0x4c: This shows the register map of the sensor at 0x4c address.

........................................................................................................................................
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0123456789abcdef
........?.......
................
................
................
................
................
................
................
........?.......
................

a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

................
................
................
................
................
................

.............................................................................................................................................
mma7660fc sensor register map: sensor in standby mode
The accelerometer sensor is mapped in the address space: 0x00 to 0x0A .

Register map:
XOUT
YOUT
ZOUT
TILT
SRST
SPCNT
INTSU
MODE
SR
PDET
PD

0x00
0x01
0x02
0x03
0x04
0x05
0x06
0x07
0x08
0x09
0x0A

Mode register controls the mode of the operation. The sensor works in 3 different mode:
1. Off mode:The sensor is inactive.
2. Standby mode: The sensor is active but the sensor measurement is disabled on all the three axes.
3. Active mode: Sensor measurement is enabled on all the three axes and the X, Y and Z data registers
are updated according to its movement.

2cset 2 0x4c 0x07 01: sensor in active mode.

....................................................................................................................................
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: 30 36 09 19 01 00 00 01 01 00 00 00 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 30 37 09 19 01 00 00 01 01 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0123456789abcdef
06???..??.......
................
................
................
................
................
................
................
07???..??.......
................
................
................
................
................
................
................

..........................................................................................................................................
mma7660fc : sensor in active mode.
4.2 Testing the accelerometer sensor through evdev interface:
Evdev interface is a generic interface which is used by the user application to access the sensor.
The mma7660fc client driver exports the events to the evdev interface in the user space through the
input subsystem. An evtest application is used to test the sensor in active mode.

----------------------------------------------------------------------------------------------------------------Input driver version is 1.0.1

Input device ID: bus 0x18 vendor 0x0 product 0x0 version 0x0
Input device name: "mma7660fc_accelerometer"
Supported events:
Event type 0 (EV_SYN)
Event type 2 (EV_REL)
Event code 0 (REL_X)
Event code 1 (REL_Y)
Event code 2 (REL_Z)
Properties:

Testing ... (interrupt to exit)

------------------------------------------------------------------------------------------------------------------Event: time 3954.804730, type 2 (EV_REL), code 0 (REL_X), value -15
Event: time 3954.804730, type 2 (EV_REL), code 1 (REL_Y), value -9
Event: time 3954.804730, type 2 (EV_REL), code 2 (REL_Z), value 10
Event: time 3954.804730, -------------- SYN_REPORT -----------Event: time 3955.437219, type 2 (EV_REL), code 0 (REL_X), value -15
Event: time 3955.437219, type 2 (EV_REL), code 1 (REL_Y), value -10
Event: time 3955.437219, type 2 (EV_REL), code 2 (REL_Z), value 9
Event: time 3955.437219, -------------- SYN_REPORT -----------Event: time 3955.732894, type 2 (EV_REL), code 0 (REL_X), value -15
Event: time 3955.732894, type 2 (EV_REL), code 1 (REL_Y), value -10
Event: time 3955.732894, type 2 (EV_REL), code 2 (REL_Z), value 11
Event: time 3955.732894, -------------- SYN_REPORT -----------Event: time 3956.032460, type 2 (EV_REL), code 0 (REL_X), value -15
Event: time 3956.032460, type 2 (EV_REL), code 1 (REL_Y), value -11
Event: time 3956.032460, type 2 (EV_REL), code 2 (REL_Z), value 10
Event: time 3956.032460, -------------- SYN_REPORT -----------Event: time 3956.333274, type 2 (EV_REL), code 0 (REL_X), value -14
Event: time 3956.333274, type 2 (EV_REL), code 1 (REL_Y), value -10
Event: time 3956.333274, type 2 (EV_REL), code 2 (REL_Z), value 10
Event: time 3956.333274, -------------- SYN_REPORT -----------Event: time 3956.632406, type 2 (EV_REL), code 0 (REL_X), value -15
Event: time 3956.632406, type 2 (EV_REL), code 1 (REL_Y), value -9
Event: time 3956.632406, type 2 (EV_REL), code 2 (REL_Z), value 9
Event: time 3956.632406, -------------- SYN_REPORT -----------Event: time 3956.932872, type 2 (EV_REL), code 0 (REL_X), value -14
Event: time 3956.932872, type 2 (EV_REL), code 1 (REL_Y), value -9
Event: time 3956.932872, type 2 (EV_REL), code 2 (REL_Z), value 8
Event: time 3956.932872, -------------- SYN_REPORT ------------

4.3 Testing the accelerometer sensor through our test application :

4.4 Testing the accelerometer sensor using an android application

5. Applications
Accelerometers sensors are widely used in today's modern applications in mobile phones , automobiles,
computers , human-computer interaction, etc.

Accelerometers are used in mobile phones for orientation detection, Image stability, motion
dialing, tap to mute.

These are also used in gaming for motion detection

Several IBM/Lenovo laptops have an accelerometer that detects sudden movement. The
generated information is used to protect the hard disk from damage using a mechanism called
Hard Drive Active Protection System (HDAPS).

Accelerometers are widely used for gesture control mechanisms. It can be used for
identification of hand gestures for controlling a system, can be emulated as a virtual mouse and
in many other gesture recognition systems.

6. Conclusion
This project mainly focused on the implementation of I2C based accelerometer chip driver .
More emphasis has been given in driver development rather than developing a complex application
around it. Since device drivers always provide specific functionalities and more control over a device
than the generic interfaces used for accessing the hardware from user space. Once a fully functional
driver is ready for the target device, then we can develop any application for that device using our own
driver. We have tested the driver with a simple application covering most of the aspects like Bluetooth
and android programming for the application part.

7. References
1. I2C on a Linux based embedded system -Design of a bus driver and a client driver for the
Nomadik NHK8815 platform - Ghiringhelli Fabrizio
2.
3.

Essential Linux Device Drivers - Sreekrishnan Venkateswaran

Linux Device Model ppt- A Raghavendra Rao

4. Jonathan Corbett, Alessandro Rubini & Greg Kroah-Hartman, Linux Device Drivers ,3rd
edition,O' Reilly
5.

Kernel.org for for documentation on writing clients.

6.

Free electrons for Linux device drivers

7.

Linux Journal for documentation on drivers

8.

Embedded-bits.co for introductory part of drivers

9.

developer.android.com for android bluetooth programming

10.

redacacia.me for android bluetooth programming

11.

Stack Overflow Forum

12.

Techotopia Basic overview of android threads and thread handler.

13.

Datasheet for mma7660fc Accelerometer sensor .