ECSE 426 – Microprocessor Systems – Winter 2014 Marc-Antoine Côté

Tuesday, April 15, 2014 Payom Meshgin

Abdul Hakim Rasoli

Adam Pickersgill

Final Project Report

TABLE OF CONTENTS

1 Abstract ................................................................................................................................................. 2

2 Problem Statement ............................................................................................................................... 2

3 Background ........................................................................................................................................... 2

3.1 Timers............................................................................................................................................ 2

3.2 Threading and Memory Protection .............................................................................................. 2

3.3 SPI .................................................................................................................................................. 4

3.4 Wireless Communication .............................................................................................................. 4

3.5 MEMS Sensor angle reading ......................................................................................................... 5

3.6 PWM ............................................................................................................................................. 6

3.7 Filtering ......................................................................................................................................... 6

4 Implementation .................................................................................................................................... 6

4.1 Mechanical Design ........................................................................................................................ 6

4.2 Overview of System Components ................................................................................................. 7

4.2.1 Angle acquisition ................................................................................................................... 7

4.2.2 Wireless module ................................................................................................................... 8

4.2.3 Motor control ........................................................................................................................ 9

4.2.4 Keypad ................................................................................................................................... 9

5 Results / Testing .................................................................................................................................. 10

5.1 Wireless Driver ............................................................................................................................ 10

5.2 Tilt Angle Acquisition .................................................................................................................. 11

5.3 Motor control .............................................................................................................................. 11

5.4 Keypad driver .............................................................................................................................. 11

5.5 Integration .................................................................................................................................. 11

6 Observations ....................................................................................................................................... 11

6.1 Design Challenges ....................................................................................................................... 12

7 Design process .................................................................................................................................... 12

7.1 Timeline of work done ................................................................................................................ 12

2

7.2 Work breakdown ........................................................................................................................ 13

8 Conclusion ........................................................................................................................................... 13

9 References .......................................................................................................................................... 13

1 ABSTRACT

This document describes the results of our project team and our attempt to create a dual microcontroller

system where the tilt angle of one board is wirelessly passed to another, reproducing the angle of motion.

Our system was also equipped such that instructions dictating the appropriate angle tilting could

be passed from one board to another and then followed by the receiver board. Our report documents the

problems we addressed in our design and also discusses the positive and negative aspects of our design

and implementation process. We also discuss the relevant theory and background information pertinent

to the project and the tools utilized to implement said project. The project ended successfully with a well-

functioning wireless transmission system.

2 PROBLEM STATEMENT

The main requirement of this project is to control a platform with 3D orientation by reproducing the

orientation of another board. The board from which the orientation is acquired should wirelessly send its

current state to the board controlling the motors on the platform. There will be two modes of operation.

The first one is when the platform will replicate the 3D orientation of the remote board. The second mode

of operation uses a keypad to get the desired angle from the user. In that mode, the platform will no

longer imitate the orientation of the remote board. Instead, the user will input the desired 3D orientation

of the remote board together with the time delay for that transition to happen. To switch between the

two modes, the user should be able to simply press a button on the remote board.

3 BACKGROUND

3.1 TIMERS There are a total of 14 hardware timers that can be used on the board. Some of them can be used to

output a PWM signal which will be useful to control the motors. In general, the timers will be used to

execute a specific task periodically. The timers can be configured to raise a flag whenever they expire.

3.2 THREADING AND MEMORY PROTECTION Multi-threaded programming is a common practice when more than one task needs to be executed

concurrently. The Discovery STMF32M4 Board we used implemented this programming through the RTOS

RTX operating system. This miniature operating system supplied the chip with the requisite tools and

3

libraries necessary to fully integrate a multi-threaded solution. Threads running on a single processor

don’t truly run concurrently, or rather there is never simultaneous execution of instructions across threads.

Instead, threads operate concurrently through scheduling done by the operating system. Different thread

scheduling algorithms exist with varying benefits and costs. Below, in Figure 1, is a graphic explaining a

common scheduling algorithm, taken from [1].

Figure 1: Round-robin task scheduling algorithm

An interesting problem arises when one implements a multithreaded solution which is the concept of

memory protection and resource allocation. Essentially this refers to the idea that there might be issues

when two processes share the same memory space, or are both trying to access a specific resource,

memory or otherwise, simultaneously. The reasons this may be problematic are twofold, firstly there is

the possibility of stale data, and the second problem is concurrent memory access.

Stale data is the idea that if two processes are accessing the same variables or memory resource, and one

writes data to it that another is supposed to read or vice versa, there can be inconsistencies in the timing

of each thread which lead to either the data not being written by Task A yet when Task B goes to read it,

or that the data read by Task B is not the most up to date.

Concurrent memory access can be a bigger problem, if for example, Task A is writing to a memory location

and then Task B interrupts and reads from that location, there may be corrupted data read by Task B. In

order to prevent both this problem and stale data, memory needs to be properly protected. One way for

the operating system to achieve this is through Mutexes. A Mutex is essentially a flag which indicates

ownership of a resource. So if a thread is going to access a resource, it must first obtain the Mutex of that

resource, and must release the Mutex once finished accessing it. Since each Mutex can only be held by

one thread at a time, this ensures that each resource is only ever used by one thread at a time, and all

other threads are waiting for it in the meantime.

4

3.3 SPI The microcontroller is required to communicate with external devices like the MEMS sensor and the

wireless transceiver using an interface called SPI (serial programmable interface). This interface is

comprised of four pins: one for the common clock signal (SCK), one for enabling or disabling slaves (Slave

Select) for connections to supply (VDD) and ground voltages (GND) and two used for communication

purposes (MOSI, for Master Out Slave In and MISO, for Master In Slave Out). Using SPI, a simple

communication protocol can be established between the master device and a slave, described below.

First, in order to select a particular slave, the master unsets the Slave Select pin connected to the slave

which will be connected to the master. Then, during each clock cycle, a single bit is set at the MOSI pin of

the master which is connected to the corresponding pin of the slave. Hence, a serial stream of bits can be

transferred from the master to the slave, which reconstructs the stream in one byte chunks in a buffer,

which then is read by the slave. If the slave is to issue a response message, it sends the message back to

the master via its MOSI pin, similarly to the way message are sent by the master.

There are four different modes under which a device can implement SPI, based on parameters called clock

phase (CPHA) and clock polarity (CPOL), which are pictured in Figure 2 (taken from [2]). In essence, the

CPOL parameter determines whether a data signal is sampled while the clock signal is high (1) or low (0).

As for the CPHA parameter, it determines whether data is signal on a clock edge (1) or between clock

edges (0).

Figure 2: SPI implementation under 4 different modes

3.4 WIRELESS COMMUNICATION The wireless functionality of the system is provided by the Texas Instruments eZ430-RF2500 development

tool [3]. Inside the package resides a 2.4 GHz transceiver called the CC2500. The CC2500 is configured by

reading from a set of registers stored in memory. Moreover, wireless transmission functions in a similar

way, where data is read from a buffer during transmission and data is stored in a separate buffer during

5

transmission. The register values are set or read via SPI, with the master device set to the microcontroller

and the slave set to the transceiver.

Figure 3: State machine for the wireless transceiver

The wireless transceiver is driven by a state machine pictured in the datasheet [4] and shown in Figure 3.

3.5 MEMS SENSOR ANGLE READING The MEMS sensor can be used to measure the tilt angle of the board in two dimensions. The roll and the

pitch are the angles between the orthogonal axes (x and y) and the vertical plane. The data acquired from

the MEMS sensor is split in three parts, one for each axis. Using this data, the roll angle can be calculated

with Equation (1) which comes from the Application Note document [5].

𝑅𝑜𝑙𝑙 = 𝛽 = arctan𝐴𝑦

√(𝐴𝑥)2+(𝐴𝑧)2 (1)

In this equation, 𝐴𝑥 , 𝐴𝑦 and 𝐴𝑧 represent the raw measurements from the accelerometer for the three

axes. Note that the pitch can easily be calculated by interchanging 𝐴𝑥 and 𝐴𝑦. β represents the angle

between the x-axis and the vertical plane in radians.

6

3.6 PWM Pulse-width modulation (PWM) is a technique used to modify the duration of a periodic pulse wave. This

simple process allows an encoded signal to propagate on a single wire. This signal, among other uses, can

function as a control signal, as is the case in this experiment (where the signal is used to control the angle

of the motors).

The principle behind PWM communication is fairly simple. First, a common period is set between the

sender and the receiver. Initially, the voltage on the channel is set high during a particular time interval,

called pulse length. Then, for the remainder of the period, the voltage is set low. The pulse length, which

is configurable at each period, communicates a message to the receiver. In the case of motor control, a

particular pulse width specifies the angle at which the motor is requested to move.

3.7 FILTERING The MEMS sensor being subject to noise, it is necessary to filter the roll and pitch angles that were

calculated in Equation (1). A simple and efficient option is to use a moving average filter which would act

as a low pass filter. This type of filter uses a buffer of fixed size and compute the average of the data in

the buffer. When a new angle is calculated, it is stored in the buffer, replacing the oldest value. The

average of the buffer is then calculated using Equation (2):

𝑁𝑒𝑤𝐴𝑣𝑔 = 𝐶𝑢𝑟𝑟𝑒𝑛𝑡𝐴𝑣𝑔 +𝑁𝑒𝑤𝑆𝑎𝑚𝑝𝑙𝑒−𝑂𝑙𝑑𝑒𝑠𝑡𝑆𝑎𝑚𝑝𝑙𝑒

𝐵𝑈𝐹𝐹_𝑆𝐼𝑍𝐸 (2)

Where 𝑁𝑒𝑤𝐴𝑣𝑔 is the newly calculated roll angle in degrees, 𝐶𝑢𝑟𝑟𝑒𝑛𝑡𝐴𝑣𝑔 is the current average of the

buffer in degrees, 𝑁𝑒𝑤𝑆𝑎𝑚𝑝𝑙𝑒 is the newly calculated roll angle in degrees, 𝑂𝑙𝑑𝑒𝑠𝑡𝑆𝑎𝑚𝑝𝑙𝑒 is the oldest

data in the buffer in degrees, and 𝐵𝑈𝐹𝐹_𝑆𝐼𝑍𝐸 is the size of the buffer. Note that the buffer has to be

initially set to zero, as well as the current average. By changing the size of the buffer, it is possible to adjust

the sensitivity to a new sensor reading.

The noise affecting the MEMS sensor is not expected to deviate extremely from the actual acceleration it

is subject to. Therefore it is sufficient to take an average of many samples to reduce the effect of the noise.

Also, the moving average filter allows to easily modify its sensitivity to a change using a different size for

the buffer. This flexibility is highly beneficial as the filter can be parameterized depending on the noise

amplitude.

4 IMPLEMENTATION

4.1 MECHANICAL DESIGN For this project to be fully functional, a 3D orientation control platform had to be built so that one board

can mimic the orientation of another freely moved remote board. Servo motors had to be used to control

the roll and pitch angles of the fixed board.

7

The mechanical design of the base board platform was constructed from a LEGO kit and two servo motors.

The finished design is pictured in Figure 4. Designing the platform with LEGO kit gave us the freedom to

build a solid and robust system. Moreover, since the structure is built from hundreds of small LEGO pieces,

it is much easier to replace if some components break or a motor fails. To give the board higher freedom

of movement and less significant sources of error, it was decided to use strings to control the board’s

orientation.

Figure 4: Mechanical design of the platform

One board is attached to the side of the structure, whose function is to receive the roll and pitch angles

from the remote board and run the two servo motors. Another board is attached to the controlling servo

motors by means of four strings. The motors run on Pulse Width Modulation (PWM) and have a rotation

range of 0 to 180 degrees. When both motors are set to 90 degrees, the board orientation is flat, i.e.

parallel to the ground.

One motor is assigned to control the roll angle while the other controls the pitch angle. To achieve this

feature each motor arm is tied to two strings. When the motor rotates in one direction one string is pulled

while the other is relaxed and vice-versa in the other direction. This way, the board is rotated smoothly in

the desired direction. In addition, circular paper protractors were installed under each servo motor to

show the angles received by the receiver board.

4.2 OVERVIEW OF SYSTEM COMPONENTS

4.2.1 Angle acquisition

The MEMS sensor is an external sensor; it is not integrated in the STM32F4 microcontroller. Therefore, it

is necessary to use an external interrupt to receive the interrupt signals coming from the sensor. Here we

use the EXTI line 1 since it is hardwired to the second interrupt channel. The accelerometer has two

interrupt channels, but only one will be used for the DataReady interrupt signal. The DataReady signal

indicates when a new set of acceleration is available in the accelerometer’s register (see page 38, [6]). The

second interrupt channel (INT2) will be used for the DataReady signal while the first interrupt channel will

be unused and grounded. The interrupt channel INT2 is hardwired to the GPIO pin PE1 as shown in the

Discovery Board Manual [7].

8

The accelerometer will use other pins for the SPI communication (PE3, PA5, PA6, and PA7). Those four

pins are hardwired to the four lines of the SPI of the accelerometer (CS, SCK, MISO, and MOSI) as shown

in the Discovery Board Manual [7]. Those lines are used to read and write data in the accelerometer’s

register. It is not necessary to configure those four pins because the accelerometer driver already

configure all the proper pins for SPI communication when the accelerometer is initialized.

The MEMS sensor will be acquiring data at a rate of 100 Hz. Since we used the same board as in the

previous labs, we simply reused the calibration matrix that we had to calibrate the data coming from the

accelerometer. When we acquire the raw data from the sensor, we first calibrate it, then the roll and the

pitch angle are calculated. Finally, the angles are filtered using a moving average filter. From the previous

lab, we have tested that the optimal window size for the filter is 22.

4.2.2 Wireless module

All packets transmitted from the sender to the receiver follow a custom protocol designed for this project,

displayed in Figure 5.

Roll Angle (1 byte)

Pitch Angle (1 byte)

Time / Mode (1 byte)

Check byte (1 byte)

Figure 5: Packet format

First, packets between the receiver and the sender are 4 bytes in length. Three bytes hold relevant data

indicating the roll angle, the pitch angle, and the time interval over which the adjustment of the tilt angle

will be performed. If the tie interval has a value of 0, then the system will enter instantaneous mode

(changes to the tilt angle are done as quickly as possible). Finally, a check byte, set to a constant value,

allows the receiver to filter out any unwanted packets not coming from the sender. Once the desired

protocol has been designed, the transceiver on either sender or receiver must be configured to

successfully communicate under the above protocol.

Before data can be transferred, the wireless transceiver modules connected to the sender and the receiver

must first be configured. As mentioned in section 3.4, the transceivers are configured by writing values

into a set of configuration registers. For the most part, most of the registers retain their default value, but

a few are changed to set up a communication channel between the sender and the receiver. Most notably,

registers related to packet length (PKTCTRL0, PKTLEN) are set so that packets are fixed to a length of 4

bytes. Finally, the built in CRC feature is enabled by setting the CRC_EN bit in the PKTCTRL0. This feature

ensures that corrupted data does not enter the receive buffer of the receiver.

In the code, the wireless data transmission is handled in a layered approach. At the low level, primitive

commands, such as writing to and reading from registers, and configuring the transceiver are

implemented. Moreover, at the low level, the transceiver is initialized, i.e. appropriate GPIO pins are

configured as SPI configured pins and the SPI on both chips is configured as well. The transceivers are

manually reset using a known sequence provided in [4].

At a higher level, functions related to packet transmission are implemented. For transmission, data is

stored in the send TX buffer with a “write” command. For receiving wireless data, the receive buffer is

9

checked to verify that the buffer is not empty. In that case, a stream of bytes are read from the buffer.

Since data can only arrive in chunks of 4 bytes, the transceiver is guaranteed to provide entire packets of

data.

At the highest level, packet processing is performed. On the receiver end, packets are deconstructed into

the appropriate fields. In addition, once the validity of the packet is confirmed, the motor thread is

signaled to activate the motors based on the values just received by the transceiver, which are passed via

shared memory. Note that in this implementation, no concurrency issues can arise from these shared

memory values since the motor controller thread and the packet reading thread can never run

simultaneously.

4.2.3 Motor control

The system makes use of two motors in order to control the tilt angle of the suspended platform. The

microcontroller manipulates the angle of each motor with two PWM signals each generated by a

hardware timer outputted to a GPIO pin (PD12 and PE15) connected to the control wire of a motor. First,

each timer (in this case, timers TIM4 and TIM9 were chosen) is configured to produce a PWM signal of a

period of 20 ms, which is the period expected by the motor. Next, to set the motor to an appropriate

angle, the pulse length of each signal is made to be configurable using shared memory variables. Then,

upon the reception of a new data packet from the wireless transceiver, the ReadPacket thread signals the

MotorControl thread, which changes the pulse lengths of the motors to produce the desired angle stored

in the packet.

In addition to an “instantaneous” change in the motor angle, the motor controller features a “timed” tilt

angle controller, where changes in the tilt angle of the platform are made gradually over a configurable

amount of time. In this implementation, this time is provided by the keypad and is expressed as an integral

number of seconds. The desired behavior is accomplished by changing the pulse width of each PWM signal

in an apparently continuous manner over the provided time. Furthermore, to achieve a linear progression

in the motor angle, the pulse width must be changed at a linear pace, or in other words, it must increase

or decrease by a constant amount in periodic intervals. In code, this feature is implemented by a loop

containing a software delay (osDelay()) followed by the pulse width of each motor being incremented by

a constant amount, until the new pulse width reaches the desired amount.

4.2.4 Keypad

In order properly implement the keypad functionality, our system utilized the scanning algorithm

discussed within the tutorial using interrupts to trigger the scan. The pins PB2, PA3, and PC4 were each

configured for EXTI lines 2, 3, and 4 respectively. These lines were then hooked up to the columns on our

keypad. The lines PD4-7 were used to connect to the rows on our 12 button keypad. The graphic on Figure

6 provides an example schematic for this type of configuration [8].

10

Figure 6: Electrical schematic for the 12 button keypad

Each interrupt signaled a thread which ran the scan and interpreted each button press based on the bit

string created from combining the bits of all seven lines connected to the keypad. We elected to use a

rising edge triggered interrupt, and used a logic high to indicate a button pressed while logic low suggested

the lines were not connected.

5 RESULTS / TESTING

In order to validate the system, the individual components of the system were tested individually in an

isolated environment. In other words, during unit tests, only the components to be tested were initialized

and configured in the design. Hence, the wireless driver, the tilt angle acquisition, the motor controller,

the keypad driver and the user button driver were all tested independently.

5.1 WIRELESS DRIVER In the case of the wireless driver, testing was also cut into different stages, due to the driver following a

layered design. Initially, the first test runs verified whether the SPI between a board and its transceiver is

functioning correctly. Essentially, these tests consisted of reading values from registers that contained

default values, storing values into the registers and verifying the implementation of the manual reset

sequence. Next, the following series of runs were related to simple wireless transmission. In these tests,

a single byte of data is transferred from the sender to the receiver. Finally, entire packets of data are

transmitted and verified on the receiver end of the transmission.

11

5.2 TILT ANGLE ACQUISITION The tilt angle is computed using a driver developed during a previous experiment. Furthermore, since the

board used to acquire tilt angles is the same used in the previous experiment, the MEMS sensor did not

require recalibration. Hence, no further tests were necessary to verify the functionality of the tilt angle

acquisition.

5.3 MOTOR CONTROL For the most part, the motor controller retains a similar structure to a controller developed in a previous

lab experiment. However, since a second motor is added to the controller, the second motor needed to

be tested to verify that an input angle is correctly mapped to a pulse width that would produce the given

angle at the motor. Once the second motor is working correctly, a test was made to check that both

motors could be controlled simultaneously. Finally, the biggest addition to the controller, i.e. the timed

motor control feature, must be verified. Thus, given a particular angle and a length in time, the motor

controller was tested so that the motors were controlled to appear as if the tilt angle was being adjusted

gradually over the specified period of time.

5.4 KEYPAD DRIVER The keypad driver was tested in isolation. First, we ensured that a keypress is detected by the driver. Then,

the button debouncing algorithm was tested so that only one keypress event is detected when the user

presses a button. Next, once the state machine behind the UI has been coded, more tests were made to

check that the user can input three numbers representing the roll, the pitch and the number of seconds

by pressing the appropriate keys.

5.5 INTEGRATION Once testing for each component is completed, the module is integrated to the design. Hence, at the

sender side, the tilt angle acquisition, wireless module, and keypad driver were put together, while the

only the motor controller and the wireless module were added to the design for the receiver. It’s at this

point that multithreading and shared memory for each module were included. Hence, all modules were

tested on the sender side until the receiver could read packets holding the tilt angle of the sender or the

desired angle entered using the keypad. Then, on the receiver end, a similar testing process is used, where

packets arriving at the receiver are being deconstructed and sent appropriately to the motor controller.

6 OBSERVATIONS

Our final project worked mostly as expected, our wireless integration achieved our desired results where

the second board followed the first with pretty good response time. The hardware allowed a surprisingly

effective degree of freedom, although we did have some difficulties when the angles approached 90

degrees, though we usually were able to recover by having the board travel to a different angle. Our

second mode of operation worked fairly effectively from the standpoint of the wireless communication

12

and servo motor application, though we had more difficulties with the keypad interface as it was not

particularly user friendly and had issues with debouncing which will be covered in further detail in section

8.1.

6.1 DESIGN CHALLENGES An initial issue we faced in the hardware was that the USB cable was fairly heavy when connected to the

board and would skew the angle being shown as the string was not strong enough to counteract the

weight of the cable. We first tried to resolve this by removing the board and simply having the receiver

board stationary and attached to the rig and having a blank frame display the angle. This worked with

some level of effectiveness but was much improved when we placed an unpowered STM board in the

frame as this increased the tautness of the string without debalancing the rig.

Regarding debouncing, we had issues with button presses being registered twice and while we tried to

have some sort of debouncing on the keypad handler, we still were caught by noise as we forgot to

debounce upon a key release as well as a key press. Aside from these difficulties, we had one or two issues

with integration, but otherwise things were relatively smooth.

7 DESIGN PROCESS

Our team worked autonomously and in parallel for the most part. Our team split the work near the

beginning of the project and from there we were able to work without interfering with one another and

holding unnecessary and inefficient meetings. Once it was time for integration we met as a team to put

the whole system together. This allowed us to work in tandem to resolve any integration bugs that came

up during the integration process. Overall our strategy was effective in maximizing the utility of each team

member to complete the project in the most efficient fashion we could conceive of.

7.1 TIMELINE OF WORK DONE A graphical representation of the timeline is shown in Figure 7.

Figure 7: Timeline of work done

13

7.2 WORK BREAKDOWN The workload between the four team members is broken down in Table 1.

Table 1: Workload between team members

Team Member Description of Work

Payom Wireless Driver and transceiver receiver side

Path interpolation over time

Integration and Debugging

Marc-Antoine

Wireless Driver and transceiver sender side

Integration of Wireless with Servo motor functionality

Integration and Debugging

Hakim

Harness Rig Design and Implementation

Servo motor functionality

Integration and Debugging

Adam

Keypad Driver Design and Implementation

Keypad input and sender integration

Integration and Debugging

8 CONCLUSION

In summary, this project focused on the implementation of a system capable of wirelessly transmitting

data between two transceivers connected on separate boards. Furthermore, the system successfully

sampled raw values from an external MEMS sensor, filtered the data, and converted it to a tilt angle (roll,

pitch), which is packaged in a wireless packet transmitted to a mobile platform. Also, the platform

manipulated a set of motors to orient the platform at the specified angle, realizing that a PWM signal can

be manipulated to control the direction of the motors). Moreover, a keypad driver was developed to allow

custom entered values to be entered as input to the system. Finally, using hardware timers (and their

corresponding interrupts) as well as threads, the various functionalities of the system are performed in

parallel.

9 REFERENCES

14

[1] M. Soczka, "Scheduler Design," January 2011. [Online]. Available:

http://groups.inf.ed.ac.uk/teaching/slipc10-11/maciej.php?page=docs/design. [Accessed 12 April

2014].

[2] Wikipedia, "SPI bus timing diagram," 7 Septmeber 2010. [Online]. Available:

http://en.wikipedia.org/wiki/File:SPI_timing_diagram2.svg. [Accessed 13 April 2014].

[3] Texas Instruments Inc., "MSP430 Wireless Development Tool," Texas Instruments Inc., 2014. [Online].

Available: http://www.ti.com/tool/ez430-rf2500. [Accessed 13 April 2014].

[4] Texas Instruments Inc., "Low-Cost Low-Power 2.4 GHz RF Transceiver (Rev. C)," 19 May 2009.

[Online]. Available: http://www.ti.com/lit/ds/symlink/cc2500.pdf. [Accessed 14 April 2014].

[5] STMicroelectronics, "AN3182 Application Note: Tilt measurement using a low-g 3-axis

accelerometer," STMicroelectronics, 2010.

[6] STMicroelectronics, "AN2335 Application note: LIS302DL," STMicroelectronics, 2006.

[7] STMicroelectronics, "UM1472: User Manual," STMicroelectronics, 2014.

[8] Futurlec, "Technical Information - KEYPADSM," 2014. [Online]. Available:

https://www.futurlec.com/KeypadSm.shtml. [Accessed 12 April 2014].