Вы находитесь на странице: 1из 14

ECSE 426 Microprocessor Systems Winter 2014 Marc-Antoine Ct

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
dont 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 boards
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 accelerometers 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 accelerometers
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. Its 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, "SPIbus 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].

Вам также может понравиться