Embedded Test System - Pennsylvania State University

Embedded Test System Design and Implementation of Digital to Analog Converter

TEAM BIG HERO 3 John Sopczynski

Karim Shik-Khahil

Yanzhe Zhao

EE 300W Section 1

Spring 2015

Big Hero 3 DAC | 2

INTRODUCTION (KS)

Often someone will receive an electrical component to utilize, but will not know how the component

operates. In order to identify the function of this component, one must apply controlled test signals to

this component, or “black box,” and observe the output. In this project, we are tasked with identifying

this black box’s function. This will be accomplished by building an embedded system to create the

needed test signals and analyze the black box’s output. The system consists of four subsystems: a

Digital-to-Analog Converter (DAC), a Digital Potentiometer (DigiPot), an Analog-to-Digital Converter

(ADC), and a Keypad. Our group was assigned to work on the DAC. The DAC will generate analog waves

that will be inputted to the black box. In order for the “black box” to have clear outputs that the ADC

can analyze, it is necessary to meet the wave amplitude and frequency requirements. Otherwise, the

“black box” will not output a useful waveform to the ADC leading to the potential failure of the project.

RATIONALE (KS)

The DAC subsystem is to output specific waveforms while receiving messages from other subsystems. In

order to understand the overall operation of the DAC subsystem, it is important to understand how the

DAC will operate as well as how it will interface with the other subsystems.

THEORY OF OPERATION (KS) The main task of the DAC subsystem is to generate a square or sinusoidal wave. These waves are to

oscillate at a frequency of either 1 Hz or 10 Hz with an amplitude from 0 ± 0.05 V to 3.3 ± 0.05 V. The

system user shall be able to set the waveform type and frequency and start or stop output of the

waveform.

The subsystem will generate a digital representation of the selected wave using the mbed LPC1768

microcontroller. The digital waveform will then be communicated to the DAC MCP4725 chip through I2C

communication. The DAC MCP4725 chip will then convert the digital waves into an analog waveform.

This waveform will be outputted to the DigiPot subsystem where a gain will be applied.

The desired waveform is generated through the use of various mathematical functions. The mbed will

generate the square wave by specifying the desired period inside an endless while loop. The mbed will

then output a voltage of one for half the period and zero for the other half. In order to generate the

sinusoidal wave, the mbed will execute an incremental “for loop” that runs from 0 to 359 to represent

the angle to evaluate the sine of each degree over one period. A wait function was placed inside of the

“for loop” to create the desired frequency. This “for loop” is placed inside an endless while loop to

create additional sinusoidal periods. The desired period for both waveforms was determined from the

inputted frequency.

Big Hero 3 DAC | 3

THEORY OF INTERFACES (KS) The DAC subsystem will interface with the rest of the system through a CAN bus. The DAC subsystem

will receive messages from the Keyboard subsystem. The DAC will not place any messages onto the CAN

bus. The Keyboard group established identification messages to notify which team they wish to

communicate with. The DAC was given a character value of ‘3’ as an identifier. In addition, when the

keyboard subsystem is done transmitting messages to any subsystem, the keyboard subsystem sends a

character ‘8’ on the CAN bus. This value alerts all subsystems to start looking for their identifier. If the

DAC reads an ‘8’ and then a ‘3,’ it will begin to look for inputs to determine waveform type, frequency,

and whether or not to output. If it reads an ‘8’ and then something other than ‘3,’ it will begin waiting

for another ‘8’ to be sent to the CAN bus. After collecting the necessary inputs from the keypad

subsystem, the DAC subsystem will go into the required state to generate the specified output.

IMPLEMENTATION (JS)

The Digital-to-Analog Converter is only a portion of the overall embedded test system. However, it plays

a crucial role within the overall system. It is subsystem that creates the test signal that will be applied to

the black box. In order to create this test signal, a circuit and code must be implemented. In order to

ensure that the code and circuit work as expected, one must perform verification and validation testing.

Once the functionality of all subsystems has been confirmed, the black box be analyzed and the

electrical component contained can be identified.

CODE AND CIRCUITRY (JS) The DAC subsystem can be broken up into two specific sections: the physical circuit and the C++ code

implemented on the mbed LPC1768 microcontroller. It is important to understand the physical circuit

before explaining the code. Doing so will aid comprehension of the code flow.

Physical Circuit The mbed will receive command signals over the CAN Bus from the Keypad Subsytem. These commands

will then determine the generated waveform that the DAC will output to the Digital Potentiometer.

Figure 1 displays the location and input/output pins of the DAC subsystem within the overall system.

Figure 1: High Level Block Diagram of Embedded System

Big Hero 3 DAC | 4

The DAC subsystem is composed of three physical components: the mbed LPC 1768 microcontroller, the

MCP2551 CAN Bus Transceiver, and the MCP4725 DAC. Figure 2 displays the connection of the

MCP4725 and MCP2551 to the mbed. The figure also displays the power rails sourced by the mbed.

These rails are utilized to power the MCP2551 and MCP4725.

Figure 2: mbed LPC1768 Pinout Diagram

Since the mbed LPC1768 is CAN compatible, messages sent over the CAN Bus are able to be read into

the microcontroller. However, a CAN bus transceiver is needed to properly receive these messages and

input them into the mbed. Figure 3 displays the MCP2551 CAN bus transceiver utilized and its

connection to both the mbed and CAN bus. Note the 120 Ohm terminating resistor connected between

pins 6 and 7 on the MCP2551. This resistor is important for proper operation of the CAN Transceiver as it

eliminates transmission line effects.

Figure 3: MCP2551 (CAN Transceiver) Pinout

Upon receiving the commands through the MCP2551, the mbed code is then able to determine the

proper digital wave to output to the MCP4725 DAC. The mbed communicates to the DAC using I2C

protocol. Figure 4 displays the connection of the MCP4725 DAC to the mbed. The figure also displays the

DAC’s output to the Digital Potentiometer.

Figure 4: MCP4725 (DAC) Pinout

Big Hero 3 DAC | 5

mbed Code The mbed code is comprised of three main sections: message interrupt, output state determination, and

physical output. The message interrupt and output state determination sections are contained within a

void function titled readCAN(). This function is attached to the CAN class. By attaching the function, each

time the code is operating in the main function and a new message is received, the code will enter the

readCAN function. Figure 5 displays the block diagram of the readCAN function. Throughout the rest of

the document, bold font is used to identify code variable names. ID is a character received by the CAN

Bus. RCV is a Boolean value utilized to determine whether or not the DAC subsystem needs to be

listening to the CAN bus.

Figure 5: readCAN Function High Level Block Diagram

Upon DAC subsystem startup, RCV flag defaults to True. This means that the code will be looking for the

value ‘3’. The first character sent to the CAN Bus is read in as ID. If this value is equal to ‘3’, the code will

enter the “Determine State” state. If ID does not equal 3, RCV will be set to false. This will prevent the

DAC subsystem from looking for inputs until the keypad has sent an ‘8’. Once this 8 has been received,

the DAC subsystem knows to begin looking for its identifier again by resetting RCV to True.

Upon entering the “Determine State,” the DAC subsystem’s mbed will read in four subsequent messages

from the CAN bus and determine an output state dependent on the messages received. This code flow

can be seen in Figure 6.

Figure 6: “Determine State” Code Block Diagram

Big Hero 3 DAC | 6

The variables of Waveform, Freq, and Output are character values of either 1 or 2. Each value selects a

waveform type, frequency, and output state. end_TX is a dummy variable created to store the ‘8’ value

that signifies the end of transmission. Since the code knows it has received all variables, this ‘8’ is

unneeded within the state determination process. Once the code has received all the values from the

CAN bus, it will determine the appropriate state value and exit the readCAN function while setting RCV

to true. The relationship between the variables and the selected state value is shown in Figure 7. In

addition, Figure 7 shows what output each state value represents.

Figure 7: State Value and Corresponding Inputs and Output

All of the operations described above are contained within the readCAN function. The code will utilize

the state value determined by the function readCAN in order to properly output a waveform to the DAC.

The main function of the code contains a switch statement that will select the appropriate waveform

according to the state variable determined from the readCAN function.

Contained within the code was coding to place the output voltage level on mbed on-board LED. This

allows one to visually observe the outputted wave form without the use of an oscilloscope. This could be

observed on LED4. Additionally, another LED was utilized to confirm that the code had entered state 0,

or the state of no output. This could be observed on LED3. These LEDs allowed for quick confirmation

that the mbed was outputting the proper wave.

*Figures 2, 3, and 4 of the Appendix display the code in its entirety.

VERIFICATION TESTING (JS) In order to verify proper operation of the DAC, the DAC subsystem was connected to the keypad system

through the CAN bus. Upon connection, the keypad was utilized to select various output waveforms.

This confirmed communication between the keypad and the DAC. In addition to sending commands to

the DAC, commands were sent to other subsystems to confirm that the DAC subsystem ignored these

messages and only received messages upon being identified by the keypad. With the use of the on-

board LEDs, successful communication and output state selection was quickly confirmed.

After verifying communication between the keypad and the DAC, we connected the output of the DAC

to the oscilloscope in order to observe the output waveform. We continued to select the waveform with

the use of the keypad. As a reminder, the DAC output was required to meet the following specifications:

Square and sinusoidal waveforms

Frequencies of 1± 0.1 Hz and 10± 0.1 Hz

Voltage spanning 0± 0.05 V to 3.3± 0.05 V

Big Hero 3 DAC | 7

All four possibilities were observed on the oscilloscope in order to confirm if they met the specifications.

Figures 8-11 display the four waveforms as well as the minimum value, maximum value, and the

frequency.

Figure 8: 1 Hz Square Wave

1Hz Square Wave does not completely meet the requirements

0.998 Hz which satisfies 1 ± 0.1 Hz

Min of -0.06 V, additional error due to noise. Marginal error with respect to the

requirement.

Max of 3.29 V which satisfies 3.30 ± 0.05 V.

Figure 9: 10 Hz Square Wave

10 Hz Square Wave does not completely meet the requirements



requirement.


Big Hero 3 DAC | 8

Figure 10: 1 Hz Sine Wave

1 Hz Sine Wave does meet the requirements


Min of -0.04 V which satisfies 0 ± 0.05 V

Max of 3.29 V which satisfies 3.30 ± 0.05 V

Figure 11: 10 Hz Sine Wave

10 Hz Square Wave does not completely meet the requirements



requirement.


Due to time constraints, the marginal error due to noise at 0V was difficult to eliminate. The error must

be to be taken into consideration when performing mathematical analysis of the black box’s response to

the test signals.

Big Hero 3 DAC | 9

VALIDATION TESTING (JS) Since the DAC has met its requirements, it is now useful to the overall embedded system. The digital

potentiometer (DigiPot) is expecting an input of 0 – 3.3 Volts. Since proper output has been verified, the

output will be useful to the digital potentiometer. In addition, the DAC is very easy to control with the

use of the keypad due to the use of the identifiers and end transmission variables. The user can

seamlessly switch from one form of output to another without disrupting the operation of the other

subsystems. This will allow for quick, controlled testing of the “black box.”

INTEGRATED SYSTEM RESULTS (KS & JS) Upon applying various test signals to the black box, the group as a whole obtained various plots

displaying the input and output of the black box. Figure 12 and Figure 13 display the results of two

different test signals applied to the black box. Input is represented by the blue line and output is

represented by the red line.

Figure 12: Input is 2V Sine Wave at 1Hz

Figure 13: Input is 5V Sine Wave at 1 Hz

Big Hero 3 DAC | 10

The graphs obtained do not reflect an accurate maximum input of 2V and 5V. However, it is possible to

approximate these graphs to identify the transfer function. The following analysis will focus on Figure 13.

Analyzing the output when the input is a minimum and maximum will allow for identification of the gain.

Figure 14: Input and Output of Black Box for 5V Sine Wave

Since the output is 1 V when the input is 0 V, it is safe to identify a DC offset of 1 VDC. In order to identify

the gain, the following equation is established:

𝑉𝑜𝑢𝑡 = 1 𝑉 + (𝐺𝐴𝐼𝑁) ∗ 𝑉𝑖𝑛

Substituting in known values for an input of 5V, the equation becomes:

0.5 𝑉 = 1𝑉 + (𝐺𝐴𝐼𝑁) ∗ (5 𝑉)

Solving this equation for GAIN produces a gain of -1/10 applied to the input voltage. This provides a final

transfer function of:

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

Applying the same process to Figure 12 will yield the same result.

Since a positive DC offset and a negative gain have been identified, it is clear that the black box contains

a negative inverting operational amplifier with a DC offset. A possible configuration for the black box is

displayed in Figure 14. There will be four resistors (R1-R4) in order to establish the correct gain and DC

offset.

Figure 14: Potential Black Box Configuration

In order to create the proper transfer function, R2 and R1 must have a ratio of 1:10. Additionally, R4 and

R3 must have a ratio of 1:14.

Input Output

0 V ~1 V

~5 V ~0.5 V

Big Hero 3 DAC | 11

DISCUSSION (JS)

Throughout the design and implementation, many issues that the group did not foresee became

apparent. These issues arose with interfacing with the system, necessary modifications to the DAC

subsystem code, and organizational issues that would have improved group performance at the

conclusion of the project.

INTERFACING AND CAN BUS (JS) On deciding the approach to communicating over the CAN Bus, the entire system agreed to utilize

device identifiers and handshakes to ensure proper device selection and communication. However,

implementing handshakes between two devices on the CAN bus began to create issues that were

difficult to debug. As a result, the overall group decided to forgo handshakes and trust that the code

would send and receive messages over the CAN Bus properly. Despite the issues with handshakes, the

overall system benefitted from the use of identifiers.

CAN bus was an effective communication protocol to implement in this embedded system. Char based

messaging allowed for easy data transfer. In addition, the nature of the CAN class allowed for interrupt

functions to be implemented with ease in the code. By combining the interrupt functions with the

identifiers, subsystems were able to identify and collect needed data transferred on the CAN bus.

An alternative communication protocol that could have been utilized is I2C protocol. I2C is a multi-

master, multi-slave communication method. Handshakes and identifiers are engrained within the I2C

protocol as the master needs to select the slave that it wishes to communicate to. The mbed LPC1768

has two I2C channels, allowing additional components such as the MCP4725 to continue communication

on an I2C channel. In this test system, the keypad would have acted as the master. The DAC, DigiPot, and

ADC would have been the slaves. This would have been another effective way to communicate within

the overall system.

MODIFICATIONS DURING INTEGRATION (JS) Throughout the integration of the DAC subsystem with others, three major issues were found with the

communication code of the DAC subsystem.

The first issue was that handshakes were not working throughout the system. As a result, all code

pertaining to handshakes was either commented out or deleted in each subsystem. In doing so, this

issue was eliminated.

Secondly, the code structure of the DAC was identified as being poorly constructed. The DAC was

originally polling for inputs in each iteration of the code, missing messages from the keypad as a result.

The code was restructured to implement the readCAN function currently utilized as well as an output

state machine within the main function. This change ensured that the code would not miss any more

inputs from the keypad.

Finally, the DAC subsystem would sometimes encounter an error due to a ‘3’ being sent to the DigiPot.

The DAC subsystem would read the ‘3’ in as an identifier and then wait for other inputs. This interrupted

Big Hero 3 DAC | 12

output of the prior waveform. To correct this, a Boolean variable RCV was implemented in the code.

This variable allowed the code to read in the correct variables and ignore ones not needed. This

eliminated the error experienced with messages sent to the DigiPot. After the implementation of these

changes, the DAC communicated seamlessly with the keypad and did not run into any more issues

during integration.

ORGANIZATIONAL CHANGES (JS) One theme that can be seen within the issues that occurred during integration is implementing a

common communication protocol among all systems. It would have been beneficial to all groups to

establish a set communication protocol at the beginning of the project. We found our group searching

for answers about the communication protocol as the demonstration day arrived, but the keypad

subsystem had not determined what inputs and outputs it would be looking for. The communication

code was constructed as the group went along. Code was added as more information about the

communication protocol was received from the keypad group. In creating a set protocol at the

beginning, all groups would have experienced a little more success integrating together.

CONCLUSION (KS)

Our group was able to successfully build a DAC subsystem and that met system requirements. The DAC

subsystem was successfully integrated with other subsystems to create an effective test system. The

system applied a test signal to the “black box” in order to determine its function. The results revealed it

to be an inverting op amp with a transfer function of 𝑉𝑜𝑢𝑡 = 1𝑉 − 0.1 ∗ 𝑉𝑖𝑛. For future designs similar

to this, it is recommend to utilize an asynchronous interrupt in the code to avoid missing inputs from a

command subsystem. It is also recommend to use LEDs to aid in debugging the code. During the testing

process, having the LEDs represent the outputted wave made it a lot easier to identify errors in the code.

We also recommend keeping contact with all the other team and making sure we all on the same page

regarding the communication protocols.

Big Hero 3 DAC | 13

APPENDICES

Appendix 1: Financial Statement

DAC Subsystem Financial Statement Product Function Quantity Price

mbed NXP LPC1768 Microcontroller 1 $59.95

MCP2551 CAN Bus Transceiver 1 $1.22

MCP4725 12-Bit DAC w/ I2C Interface 1 $4.95

120 Ohm Resistor Terminating Resistor for CAN Bus

1 $0.15

Wire Physical Connections As needed --------

Total Price $66.27

Appendix 2: Lab3_Final.cpp (Initialize Functions Section)

Big Hero 3 DAC | 14

Appendix 3: Lab3_Final.cpp (void readCAN() function)

Big Hero 3 DAC | 15

Appendix 4: Lab3_Final.cpp (main function operation)

Embedded Test System - Pennsylvania State University

Documents

Transcript of Embedded Test System - Pennsylvania State University