EE 300W Lab 3 - Embedded Systems

Digital-to-Analog Converter Subsystem

DACs Out for Harambe

Bryan Burns
Harvish Mehta
Hengliang Yao

Table of Contents
Introduction3
Embedded System..3
Digital-to-Analog Converter..4
Rationale4
Operation of Digital-to-Analog Converter.4
Operation of Embedded Subsystem Integration....4
Implementation..5
Explanation of Circuitry.....5
Explanation of Code............6
Verification Testing...............10
Validation Testing................11
Results from Integrated System........12
Integration Without Black Box..........12
Discussion12
Value Statement....13
Conclusion14
Appendices...14
Table 1: Bill of Materials...14
Table 2: Gantt Chart...14

Introduction
The purpose of this lab is to create 4 embedded systems that adjust and manipulate waveforms to
deduce the inner workings of a black box (Figure 1). There are four embedded systems in this lab
Keypad, Digital-to-Analog, Digital Potentiometer, and Analog-to-Digital Converter Subsystems:
Embedded System:

Figure 1: Diagnostics System Block Diagram

The Digital-to-Analog Converter (DAC) subsystem will create square and sinusoidal
waves at either 1 Hz or 10 Hz spanning 0 to +3.3 V based on a command from the
Keypad subsystem.
The Digital Potentiometer (DigiPot) subsystem will modulate the DAC subsystem output
to have a voltage range of 0 to +1, 2, 3, 4, or 5 V. These outputs will be inputted to the
black box.

The Analog-to-Digital Converter (ADC) subsystem will sample the output of the black
box at 100 Hz and manipulate the samples through a PC.

The Keypad subsystem sends commands to the DAC, DigiPot, and ADC subsystems to
start/stop them as well as to choose a specific output.

Digital-to-Analog Converter:
3

Our embedded subsystem was the Digital-to-Analog Converter which recieved commands from
the Keypad to create 4 waveforms peak to peak with 3.3V:
Sine Waveform 1 Hz
Sine Waveform 10 Hz
Square Waveform 1 Hz
Square Waveform 10 Hz

Rationale
Operation of Digital-to-Analog Converter:
The Digital to Analog will work with three components:
mbed NXP LPC1768 microcontroller
MCP4725 12-Bit Digital-to-Analog converter
MCP2551 CAN Bus transceiver
The Digital to Analog mbed will receive waveform and on/off specifications from the Keypad
mbed through CAN Bus protocol. The Digital to Analog, based on the command, will send a
signal to the DAC using I2C protocol to output that waveform.
Operation of Embedded Subsystem Integration:
The embedded will communicate through digital protocols. More specifically, CAN (controller
area network) busses will be used for the keypad to communicate to each subsystem which has
its own mbed to receive commands and manipulate waveforms. Waveform signals will be
directly and serially sent through the DAC, DigiPot, Black Box, and ADC.

Implementation
Explanation of Circuitry:

Figure 2: Schematic of Digital-to-Analog Converter Subsystem

The wiring schematic of the DAC subsystem is shown in Figure 2 above. The DAC microchip,
as well as the CAN bus transceiver, are powered using the 5V USB power line of the mbed
microcontroller. The mbed is powered through a USB serial connection to the Keypad
Subsystem PC.

Figure 3: DAC Pinout

Figure 4: CAN Pinout

The MCP2551 CAN bus transceiver (Figure 4) is designed to receive CAN messages from the
Keypad Subsystem through the CAN H and CAN L ports. The CAN bus then sends the required
data from TxD and RxD ports to the CAN td and CAN rd LPC1768 mbed microcontroller ports,
respectively.

Figure 5: Mbed Microcontroller Pinout

The Mbed Microcontroller (Figure 5) and MCP4725 DAC microchip (Figure 3) communicate
through I2C protocol. The SDA and SCL ports of both the mbed and DAC are connected to pass
data and clock signals. The DAC microchip will output the desired waveform after reading the
information sent from these signals. This waveform is then sent to the Digipot Subsystem from
the output voltage port.
Explanation of Code:
Mbed, CAN, and DAC Initializations (Figure 6):
Line 5-7 creates and initializes a CAN bus with mbed pin 30 as the receiver and
pin 29 is the transmitter.
Line 8 creates a serial connection between the mbed and the PC. This can display
CAN and DAC values in PuTTY with a PC write function.
Lines 11-14 initializes all four LEDs on the Mbed.
Line 16 creates a serial I2C connection between the DAC and Mbed using mbed
pin 28 (SDA) and 27 (SCL) using a 400kHz bus speed, and hex 0x62 is the
default I2C address.
Lines 18-23 initialize all variables used in the code.
CAN Communication (Figure 6):
Line 6 creates the msg variable as a medium for other subsystems to communicate
with the DAC subsystem.
Lines 30-31 standardize the msg format and give the msg an identifier.
Lines 32-33 describe the number of bytes sent as well as the frequency the
embedded systems are communicating on.

Figure 6: Initialization Code

Wave Generation and Execution (Figure 7 and 8):
Lines 37-41 print the received message to the PuTTY or PC by storing the first
byte in test. The variable test will control the waveform to output.
Lines 35-111 are switch-case statements that write the waveform outputs to the
DAC based on the test variable. The DAC will output the specified signal.
Case 4: Creates Sine 1 Hz Wave 3.3 Vp-p
Case 5: Creates Sine 10 Hz Wave 3.3 Vp-p
Case 6: Creates Square 1 Hz Wave 3.3 Vp-p
Case 7: Creates Square 10 Hz Wave 3.3 Vp-p
Case 8: Stops Wave Output
These case numbers are specified by the keypad system.

Figure 7: Code Waveform Generation - Part 1

Figure 8: Code Waveform Generation - Part 2

Verification Testing:
In order to verify our subsystem was working, we performed three test verifications:
First, we implemented the Hello World program (Figure 9) from the mbed
development website. This test was proved successful when the LED began to blink when the
mbed was reset.

Figure 9: Hello World Code

Next, we downloaded the the sample code (Figure 10) from CANVAS. We used this
code to initialize the pins on the mbed and the DAC. This test resulted in a square waveform read
as an analog signal on the lab station oscilloscope.

10

Figure 10: DAC and Mbed Sample Test Code

Finally, we verified that the DAC subsystem works by programming it to output 1 or 10
Hz sine waves and 1 or 10 Hz square waves spanning 0 to +3.3V on the lab station oscilloscope
(Figure 11-12). We added the switch statement to our code and tested that the subsystem can
receive CAN messages from the Keypad subsystem and output the corresponding waveform.

Figure 11: DAC system output signals (3.3 Vp-p) - Square 1Hz (left) and Square 10Hz (right)

Figure 12: DAC system output signals (3.3 Vp-p) - Sine 1Hz (left) and Sine 10Hz right)
Three tests demonstrated that the DAC subsystem has the ability to output the specified
waveforms.
Validation Testing:.
The Digital-to-Analog Converter subsystem successfully creates four waveforms with a 3.3Vp-p
amplitude (Figure 11-12). These waveforms are manipulated by the DigiPot and inputted into the
black box to determine the device hidden within the box.
11

Results from Integrated System:

Our embedded system team had a partial integration that integrated the Keypad, DAC,
and ADC. These systems communicated through the CAN bus. However, the waveforms (from
DAC) bypassed the Digipot and black box, because the ADC and Digipot groups were unable to
integrate a black box into their designs. Therefore, the function of the black box remains
unknown.
Integration Without Black Box:

Figure 13: ADC Output Without Blackbox

Figure 13 represents our partial integration result, which excludes the DigiPot and Black box.
Thus, the PC will portray the same unchanged signal sent.

Discussion
Our group discussed with the Keypad subsystem group what signals they would send us
and how we would interpret those signals as inputs to our subsystem. In order for each
12

subsystem to communicate with each other effectively, we were required to implement the CAN
bus transceiver into our designs. The CAN bus protocol was effective at reading the signals sent
from the Keypad group and allowing each group to successfully communicate with each other.
The CAN bus is a simple solution to connect multiple mbed microcontrollers together.
An alternative to the CAN bus is an SPI (Serial Peripheral Interface) bus. This is commonly used
to send data between microcontrollers and small peripherals such as switch registers, sensors,
and SD cards. It is based on push/pull technology which allows running at high speeds. It has a
simple hardware interface and a full duplex mode that uses master-slave architecture. Data is
sent synchronized by the clock line which is driven by the master.
After the initial coding of the system was completed, we were unable to receive the
message sent to us from the Keypad subsystem through the CAN bus. We were able to fix this
problem by adding lines 30-33, as seen in Figure 6. These lines of code are used to identify the
messages sent by the Keypad subsystem.
If we had the opportunity to change how this lab was performed, we would request CAN
busses equipped with wireless communication. During our final presentation, the overabundance
of connections between groups became cumbersome and hard to keep track of. Wireless CAN
busses would greatly simplify the wiring process and eliminate a large margin of error.
Another possible change to this lab is by removing the CAN communication between
groups altogether. Many groups, including ourselves, had a difficult time trying to send and
receive CAN messages between subsystems. It should be possible to simply send information
directly to the inputs and outputs of the mbeds and subsystem chips. This is a plausible solution,
because we only have 4 subsystems that need embedding.

Value Statement
Automobiles have transitioned to become more electronically dependent, because
connecting each system directly to another led to a disarray of harnesses. Therefore, the CAN
(controller area network) module was created in the 1980s and its purpose was to incorporate
multiple systems through a CAN serial protocol. This links all systems and networks through a
single CAN bus. Our project exemplifies the importance of the CAN, by linking its protocol to
all four embedded subsystems. Instead of having the Keypad subsystem send an individual
message to each subsystem, the Keypad can now send a single signal through the CAN bus. This
signal will be read by all subsystems at the same time, thereby reducing the amount of
connections and increasing the efficiency.

13

Conclusion
Team DACs Out for Harambe has developed a Digital-to-Analog Converter (DAC) that
generates analog waveforms, which are outputted to the Digital Potentiometer (DigiPot). In order
for a waveform to be chosen by the Keypad, a CAN bus was implemented to link each teams
protocol. This created synchronous communication system between all subsystem. However, we
achieved a partial integration that failed to discover the contents of the black box. Overall, our
individual subsystem function as required, while the integrated embedded system functioned
partially.

Appendices

Table 1: Bill of Materials - Financial Statement

Table 2: Gantt Chart - Schedule Breakdown

14

Figure 14: Physical DAC Subsystem Layout

15