Lab 3: Embedded Systems

___________________________________________________________________________

Final Report

Team Positron:
Matthew McTaggart
Michael Gordon
Hunter Rowe
Daniel Kleinhenn
Table of Contents

Introduction 3

Rationale 3
Theory of Operation 3
Theory of Interfaces 3
High Level Block Diagram 4

Implementation 5
Keypad Circuit and CAN Bus Communication 5
Keypad Control Code Explanation 7
Verification Testing 13
Validation Testing 17
Results from the Integrated System 17

Discussion 20
Module, Network integration, and Debugging 20
Subsystem Modifications 21
Group Organization and Teaming 21

Value Statement 21

Conclusion 21

Appendices 22

2
Introduction

The purpose of this lab was to design and test a diagnostics suite to characterize a “black
box.” Our group designed the keypad subsystem (control), which allows the user to enter the
desired output wave type (square or sinusoidal), and adjust its amplitude and frequency. The
selections from the keypad provide the inputs to all other subsystems including the digital to
analog converter (waveform generator) and the digital potentiometer (gain). Together, these
two subsystems allow the user-defined wave to be physically realized by generating a wave
of specified amplitude and frequency. This generated wave is the input to the “black box.”
Using an analog to digital converter subsystem, the “black box” output is sampled and sent to
the computer for data analysis. The “black box” circuitry can then be characterized based on
the transfer function of the output to the input waveforms.

Rationale

Theory of Operation

Our group designed and tested the keypad subsystem, which is used to control the operations
of all other subsystems. The requirements for this subsystem were to send commands to the
DAC subsystem to start/stop and select the waveform, send commands to the DigiPot
subsystem to select waveform amplitude, send commands to the ADC subsystem to start/stop
sampling, and receive user input from the keypad to send the aforementioned commands. To
meet these requirements, we designed a user interface that walks the user through the various
subsystems sequentially, beginning with the Digital to Analog Converter. Our interface relies
on prompts to obtain information from the user. For example, an initial prompt asks the user
to specify the wave type (square or sinusoidal). Pressing a ‘1’ on the keypad selects square
while pressing a ‘2’ selects sinusoidal. After a selection is made, a print statement confirms
the selection, and the next prompt then appears on the screen. At any time, the program can
be restarted by pressing ‘*’. The communication between the subsystems are controlled by a
controller area network (CAN) communication protocol. The CAN message were constructed
as one byte messages with a message ID of 255.

Theory of Interfaces

Integers representing one byte of data are broadcast as outputs of the keypad subsystem.
These outputs provide the inputs to the other subsystems after selections are made. For
example, a selection of “Start sampling,” will send a specified integer value to the ADC
subsystem, which instructs this subsystem to sample the “black box” output. The C++ code
for the user interface was compiled onto the mbed LPC1768 microcontroller. The PuTTY
software was used as the system console where the user can respond to prompts and where
confirmation statements are displayed. A transceiver connected to the CAN Bus serial
communication channel of the mbed broadcasts the outputs of the keypad subsystem to the
other subsystems.

3
High Level Block Diagram

We developed a high level block diagram which shows the structure of the entire diagnostics
suite, beginning at the embedded system level (N = 0) and ending at the hardware level
(N = 3). At the N = 0 level, the high-level block diagram shows the inputs and outputs to our
embedded system: the user input generated from the keypad and the output waveform.
The overall embedded system consists of four subsystems (Keypad, DAC, DigiPot, and
ADC) which are represented at the N = 1 level. The N = 2 level represents the control code
and circuitry for each subsystem while the N =3 level shows the hardware needed to realize
each subsystem.

Figure 1 - High Level Block Diagram

4
Implementation

Keypad Circuit and CAN Bus Communication

The keypad control system is interfaced with the other three subsystems using a controller
area network (CAN) bus communication protocol. This is done by using two 120(ohm)
terminating resistors between the CANHigh and CANLow lines for the CAN bus
communication line. Each subsystem transceiver (mcp2551) connects to the CAN bus line,
and is able to transmit or receive data. For the system, the keypad sends data while the other
three subsystems receive data.

The keypad controller implementation shown below in figure 2, shows how the keypad
control interfaces with sending data. In this setup, there is a second mbed that prints the
message received by the keypad transmission for testing purposes. The mcp2551 transceiver
is powered from the 5V (VU) and ground (GND) pins from the mbed. The mp2551 transmit
and receive pins are connected to the mbed pins p29 and p30, respectively. The Rs pin on the
mcp2551 controls the mode of operation for the transceiver. For the system, the Rs pin was
grounded for High-Speed mode, and the Vref pin was not connected.

Figure 2 - Keypad Control Circuit

5
Figure 3 shows the connection of the CAN bus transmission line. In this image it shows a
second CAN connection on the same mbed using pins 9 and 10. But, the project used two
mbeds to isolate the transmission code from the receiving code.

Figure 3 - CAN Bus Transmission Line Circuit

Figure 4 shows the mbed pin layout with the physical mbed image. Although not shown, p9
and p10 can be used for the CAN bus communication protocol.

Figure 4- Pin Layout for the mbed LPC 1768

6
Keypad Control Code Explanation

The design of the keypad control code is very linear. When the mbed is started, the code
remains in Case 0, and progresses to Case 5. If the user resets the system when prompted, the
program resets to Case 0, re-initializes all variables, and instructs the other subsystem that it
has restarted. The code includes the “mbed.h” and “Keypad.h” libraries included on the mbed
website. The mbed communicates with the PuTTY over the USB connection, instructed by
“Serial PC(USBTX, USBRX)”. The CAN bus communication transmits over the mbeds pins
29 and 30 for transmission and receive, respectively. Figure 5 shows the initialization of our
keypad control. The keypad table is initialized to match the 3x4 key keypad being used as the
control. The index changes when a key is pressed, and points to the appropriate key from the
keytable. After each press, the index is set back to -1 so that it does not continuously register
what was pressed beyond the keypress.

Figure 5 - Code Initialization

The mbed toggles an LED1 every time a message is transmitted. Figure 6 shows the “send”
function handle which transmits a signal over the CAN bus. Each time a message is
transmitted, the keypad PuTTY terminal will print the message that was sent.

Figure 6 - Send Function for CAN Bus Transmission

7
The message transmitted over the CAN bus has a unique ID of 255, and is one byte of data
long. In the main function, the message is assigned an integer value to a character variable
“message” that represents an instruction to all other subsystems connected on the CAN bus.

The table 1 shows the instructions for each transmitted message.

Table 1 - Instructions for all Subsystems

CAN Bus Value (Decimal) Description
0 Initial State, Waiting for Instructions
11 DAC - 1Hz Square Wave
12 DAC - 1Hz Sinusoid
13 DAC - 10Hz Square Wave
14 DAC - 10Hz Sinusoid
15 DAC - Stop
16 DAC - Start
21 DigiPOT - 1 Volt
22 DigiPOT - 2 Volt
23 DigiPOT - 3 Volt
24 DigiPOT - 4 Volt
25 DigiPOT - 5 Volt
31 ADC - Start
32 ADC - Stop

The main function is as follows. It initializes the keypad and its pins for the corresponding
rows and columns. All variables are initialized to zero. The state controls the linearity of the
user interface, the waveflag and wavetemp variables are used as decision parameters for the
CAN messages 11, 12, 13 and 14. The temp variables control the print to the screen for each
state, so that it only prints once when it enters a state. The toggle and toggle2 variables
control when the DAC and ADC are toggled on and off, respectively.

Figure 7 - Initialization of Main Function and User Interface

8
The first state (case 0) is the start state, indicating that it is ready to begin interfacing with the
user. The user may select the waveform, either sinusoid (‘1’) or square wave (‘2’). The
waveflag variable is used to remember which waveform was chosen. If the user does not
select ‘1’ or ‘2’, then the interface prompts them that they entered an invalid entry.

Figure 8 - Stage 1 of User Interface

The second state (case 1) is the frequency select state. The user may select either 1Hz (‘1’) or
10Hz (‘2’). Once the user has selected the frequency, wavetemp saves the combination of
frequency and waveform the user choses.

Figure 9 - Stage 2 of User Interface

9
The third stage (case 2) starts the DAC with what the user specified. The program remembers
the selection from the wavetemp variable. It allows the user to control when to start the DAC
(‘#’) and whether the system should be restarted (‘*’). This is the first stage in which a
message is sent. For each waveform and frequency selected, the message (of type char) is
assigned the number corresponding to the instruction. The send function is called once the
value of message has been set. If the user selects to reset the system, all variables and states
are set back to the initial values of 0.

Figure 10 - Stage 3 of User Interface

The fourth stage (case 3) controls the amplitude of the digital potentiometer. At the stage, the
user selects ‘1’ to ‘5’ on the keypad, for 1 to 5 volts for the potentiometer, respectively. The
user can also toggle the DAC operation using ‘#’. This stage writes the corresponding
message to the CAN bus for the DAC, based on the user’s instruction.

10
 Figure 11 - Stage 4 of User Interface

The fifth stage (case 4) controls when to start the ADC sampling. This is done by the user
confirming by pressing ‘#’. Once the ADC sampling begins, it moves to the final stage (case
5) which allows the user to toggle sampling using ‘#. The user can reset the program to the
initial stage using ‘*’.

11
Figure 12 - Stage 5 of User Interface

12
Verification Testing

Before integrating with the entire system, the keypad control was tested to see whether a
signal was transmitted by the keypad control transceiver, and received by the test mbed
receiver. Figure 13 shows this functionality. On keypad COM5 PuTTY, the user selected a 1
Hz sinusoid. The COM4 PuTTY receives the message 12, which is the instruction for the 1
Hz sinusoid. Later on, the user selects 2V for the digital potentiometer and COM4 PuTTY
sends a message 22 to the COM5 PuTTY, for this instruction.

Figure 13 - CAN Bus Message Sent and Receive Testing

The keypad control subsystem was required to select the waveform for the DAC, the voltage
for the potentiometer, and when to start and end sampling for the ADC. Figure 14 shows a
run through of the system through PuTTY. The user can start and stop the waveform
generated at the DAC, select the voltage for the digital potentiometer, and toggle the
sampling at the ADC.

Figure 14 - User Interface Run Through

13
The hierarchy of the system integration is shown in figure 15 and table 2 shows the
subsystem requirements.

Figure 15- Hierarchy of the System Integration

Table 2- Subsystem Requirements

Keypad Subsystem Digital-to-Analog Digital Potentiometer Analog to Digital
Converter Subsystem (DigiPot) Converter
Subsystem Subsystem
(DAC) (ADC)

Send commands to the Create square and Modulate the DAC Sample the output
DAC subsystem to sinusoidal waves at 1 subsystem output to of the black box
start/stop and select the Hz and 10 Hz have a voltage range at 100 Hz
waveform spanning 0 to +3.3 V of 0,1,2..5 V

Send commands to the Receive commands Output the modulated Output the
DigiPot subsystem to from the Keyboard waveform to the black samples to a PC
select waveform subsystem to box terminal over
amplitude stop/start and select USB or save
the waveform locally
on the mbed

Send commands to the Receive commands

ADC subsystem to from the keyboard
start/stop sampling subsystem to select
amplitude

Receive user input from

the keypad to send the
aforementioned
commands

14
Figure 16 through 18 show the pinout labels of the subsystems.

Figure 16 - DAC Pinout

Figure 17 - DigiPOT Pinout

Figure 18 - ADC Pinout

15
Figure 19 shows the fully integrated system. The blue and white wires correspond to the
CAN bus transmission line. Blue represents CANH and white corresponds to CANL. The
black box is located behind the held keypad.

Figure 19 - Overall System Connection

The following PuTTY terminals (figure 20) shows the entire black box analysis system under
operation. The COM10 PuTTY is the user interface and shows the messages being sent at
each stage. In this screenshot all subsystems are doing their tasks. The user entered a 1Hz
Sinusoid and the COM20 PuTTY is acknowledging the command and its function by printing
“1 Hz Sine”. The gain of the potentiometer is set to 5V, and on COM21 PuTTY we see
“xx25” being received. This scales the 1Hz Sinusoid to 5V peak to peak. Finally, the analog
to digital convertor sampled the output from the black box. The COM22 PuTTY displays “we
got gud//.” to indicate a successful sample and records a value. The data is stored in a text file
on the mbed.

16
Figure 20 - Overall System Operation

Validation Testing

The keypad subsystem performed the desired task for controlling all the other subsystem to
analyze the black box. The keypad controlled the type of frequency and waveform for the
digital to analog converter, the voltage scale for the waveform and frequency through using
the digital potentiometer, and sampling the data at the output of the black box. The entire
system was able to characterize the black box because it was able to generate a known signal
and sample the output of the altered waveform. The difference between the input signal and
the output signal successfully indicated the black box’s transfer function. These results are
shown in the following “Results from Integrated System” section.

Results from Integrated System

Figure 21 and 22 show the results sampled from the black box. For comparison purposes, an
ideal case for the input is plotted above the sampled result. The actual waveform from the
digital to analog converter is not this ideal. In each case, the sampling may not have started at

17
the same location of the generated waveforms as defined at 0 seconds from the ideal
MATLAB plots.

Figure 21 shows the black box response to the 2V 1Hz square waveform. The input wave is
not perfectly 1 Hz, but very close. The slight deviation is frequency is seen on the black box
output. The sloped transition regions are due to connecting samples by straight lines.

Figure 21 - Results from Ideal 2V 1Hz Square Wave Input

Figure 22 shows the black box response to the 5V 1Hz sinusoid waveform. Similar to before,
the input waveform is a representation of the input waveform. It is apparent that the input
frequency for the sinusoid is also not quite 1Hz. Some errors are present in the plot due to
connecting samples using straight lines.

Figure 22 - Results from Ideal 5V 1Hz Sinusoidal Input

18
Figure 23 shows the black box response to the 4V 10 Hz sinusoid waveform. This result is
not as favorable because it appears the analog to digital converter was not sampling at the
specified 100Hz but rather 10Hz. Aliasing is the dominant factor to the distortion in the 10Hz
waveform generations. Specifically, the 10Hz waveforms are being aliased to 5Hz
waveforms. Despite the aliasing problems, the amplitude of the black box output is as
expected.

Figure 23 - Results from Ideal 4V 10Hz Sinusoidal Input

Through analyzing these results, the black box transfer function is defined as follows:

𝑉𝑜𝑢𝑡 = 1 − 0.1 × 𝑉𝑖𝑛

Figure 24 on the following page shows black box results to the ideal transfer function and
waveforms as defined above. In this case the 2V 1Hz square wave is considered. The samples
have been adjusted to align the important points between all waveforms. The frequency
seems to decrease with time because of the sampling locations. The digital to analog
converter does not create a perfectly steady 1Hz square wave. As the frequency deviates, the
samples at the transition regions will sample on the wrong side of the transition region.

19
 Figure 24 - Verification of Transfer Function Classification

Discussion

Module, Network Integration, and Debugging

CAN bus is an asynchronous peer-to-peer network architecture that allows communication
between microcontrollers without the need for a host computer. When a specific module is
ready to transmit data, the module will confirm that the bus is not busy and then broadcast a
CAN frame (digital transmission unit) onto the network. CAN frames make use of a unique
arbitration ID that labels that specific frame. Because of this unique ID, neither the
transmitting or receiving node address is attached to the frame and all module on the CAN
bus receive the frame. Once each node receives the frame, that node can determine whether to
accept or reject. CAN busses can make use of electronic control units (ECUs) which further
improves the efficiency of the network.

Alternatively, an I2C bidirectional two-wire serial interface can be used. I2C is a

synchronous protocol that allows communication between compatible devices. I2C is a fairly
simple and common multi-master multi-slave protocol but can slow significantly when a
single device on the commination bus fails. Because our integrated system makes use of
multiple modules, CAN bus is a more effective communication protocol for our embedded
systems’ requirements.

The CAN bus provides quick and reliable serial communication between the keypad and each
subsystem. However, the system’s CAN bus was limited to wired communication. The
inability to communicate wirelessly with each subsystem significantly hindered integration.
A simple serial WiFi Adapter (such as the RS232) allows secure wireless communication via
TCP or HTTP transfer and can utilize the existing WiFi network connectivity. Wireless
system integration would allow each team to continually debug and update their individual
subsystem without moving the physical subsystem itself.

20
Subsystem Modifications
Our keypad subsystem remained largely unchanged throughout the project lifecycle. The
code’s case structure design served as an effective architecture for command broadcasting
and communication between multiple modules.

Group Organization and Teaming

In order to adhere to the proposed project timeline, our group’s system was divided into four
subsystems. The use of subsystems allowed the system group to effectively manage time and
delegate project tasks. Inter-team communication was efficient and fluid. Idea exchange
between teams provided resources for each subsystem while still allowing for specialization.
Additionally, our team was able to ensure that each subsystem adhered to the same coding
standards and allowed for seamless system integration

Our team created high-level block diagrams in order to decompose our subsystem into
specific tasks for delegation within the team. We then acquainted ourselves with the mbed
microcontroller as well as the PuTTY serial terminal. Intra-team task delegation could be
significantly improved for the keypad subsystem. Following the initial setup, the keypad
subsystem requires large amounts of code and minimal circuitry. The obvious advantages to
having one team member work on the subsystem’s code difficult for the entire team to remain
fully involved with the subsystem. Apportioning the mbed code for the keypad subsystem
could further complicate integration and require additional debugging.

Value Statement
The importance of embedded systems is growing yearly due to Moore’s Law. With the
increased amount of transistors per area, embedded systems are becoming more powerful and
commonplace. It is important to explore the functionality of this rapidly increasing
technological field. Our team was able to successfully analyze an array of devices through the
use of data sheets and troubleshooting and integrate them into a fully functioning system
consisting of multiple embedded systems communicating through a series of CAN busses.
The device is operated using a keypad and a user interface displayed on the screen using
PuTTY terminal. Excluding costs of labor, the system is inexpensive compared to similar
commercial systems and allows for the user to manipulate the device through the mbed
device platform.

Conclusion
The embedded system effectively generated custom square and sinusoidal waves, based on
the user inputs from the keypad control subsystem. After sampling the “black box” output
and reconstructing the output waveform, the “black box” was characterized as an inverting op
amp with a 1V DC offset. Integrating the four subsystems (Keypad control, DAC, DigiPot,
and ADC) required the use of four mbeds. However, since each mbed contains two pairs of
CAN Bus communication channels (pins p29&p30, and p9&p10), we could have designed
the system to use fewer mbeds. This strategy would be more economical and simplify
integration.

21
Appendices

Bill of Materials

22