THE PENNSYLVANIA STATE UNIVERSITY EE 3OOW SECTION 3 FALL 2015 THE DREAM TEAM Lab 3: Embedded Systems William Stranburg, Sean Solley, Sairam Kripasagar
Table of Contents Introduction... 3 Rationale... 3 Theory of Operation... 3 Theory of Interfaces... 4 Implementation... 4 Explanation of Code and Circuitry... 4 Verification Testing... 11 Validation Testing... 19 Results from Integrated System... 19 Discussion... 20 Approach to Module, Network Interface, and Debugging... 23 Modifications to Design During Integration... 23 Changes to Better Perform If Lab Was Done Again... 24 Conclusion... 24 Appendices... 24 Appendix A: Gantt Chart... 25 Appendix B: Bill of Materials... 25
Introduction The purpose of this lab was to integrate multiple subsystems together in order to find out the contents of the given black box circuit. The four subsystems integrated together were the Keypad Subsystem used to send commands, the Digitalto-Analog Converter (DAC) Subsystem used to convert the digital waveforms to analog waveforms, the Digital Potentiometer (DigiPot) Subsystem used to scale the DAC output and serve as the input to the black box, and the Analog-to-Digital Converter (ADC) Subsystem which sampled the output of the black box. Our team was assigned two subsystems, the DAC and the DigiPot. Together, these subsystems generated all possible inputs to the black box. It was crucial to generate accurate and consistent inputs because we had to compare output to input. If we designed our subsystem haphazardly, we would not be able to characterize the black box. Rationale Theory of Operation Digital-to-analog conversion works by converting digital values into analog values in two steps. First, the system converts each time step of the digital input signal into an impulse. This pulse train produces a signal whose frequency response is periodic. The second step involves passing the resulting sequence of impulses through a low-pass filter. Doing so removes all of the high-frequency periodicities, leaving only the analog signal. Our DAC subsystem generated digital waveforms in C and outputted analog waveforms from the DAC based on commands from the Keypad Subsystem. We implemented this using an mbed LPC1768 Microcontroller and MCP4725 12-Bit DAC. A digital potentiometer works very much like an analog potentiometer, except it is digitally controlled by two resistances using the wiper position Dn: RA = RAB(256 Dn)/256 RB = (RAB Dn)/256 where RAB is the total resistance of the DigiPot. The voltage output can be found using: VOUT = VIN (1 + RB/RA). Digital potentiometers are often used in the trimming/scaling of analog signals by microcontrollers. Our DigiPot was used to modulate the DAC output to 0, +1Vpp, +2Vpp, +3Vpp, +4Vpp, or +5Vpp. We used an MCP41050 which had a maximum resistance of 50kΩ.
Theory of Interfaces The mbed was connected to a PC while we were in the individual debugging phase. PuTTY served as a terminal to send and receive messages serially with the device through USB. This was easier and less expensive than a parallel connection, but the sacrifice was speed. For our purposes, a serial connection was still fast enough. Our subsystem required multiple communication protocols. We used I2C to communicate from the mbed to the DAC, utilizing two connections of SDA (data) and SCL (clock). We also used SPI to communicate from the mbed to the DigiPot. The connections used were MOSI (Master-Out Slave-In) and SCLK (clock). Finally, our subsystem communicated with the Keypad subsystem via a CAN Bus, connecting our CAN High s and CAN Low s together. Implementation Explanation of Code and Circuitry From the functional decomposition in Figure 1, our DAC subsystem used an mbed and a DAC for hardware, and two While Loops and a series of if statements for the structure of the software. The protocol was to constantly check for a CAN Message, and output a waveform based on the message as seen in Figure 2. Figure 1: DAC Block Diagram
Figure 2: DAC Flow Chart The functional decomposition of the DigiPot (Figure 3) shows a software structure that checked for input from the DAC and contained a series of if statements that separated the peak to peak voltages. The protocol from Figure 4 was to check for two inputs: a signal from the DAC and a CAN Message to specify what voltage to scale to. The DigiPot output went to an op-amp circuit (Figure 12) which was needed to step up the voltage past 3.3V. The op-amp output went directly to the black box input. Figure 3: DigiPot Block Diagram (minus op-amp)
Figure 4: DigiPot Flow Chart The following portion of our C code established the header files we needed and configured the mbed pins. Next, it instantiated a class for the DAC. It also initialized a global variable, pi, used for sine wave generation. The rest of this block set up function prototypes to be used later in the code. Figure 5: Code Part 1
In this block, we started our main( ) function which printed out instructions to the user via PuTTY, which was useful for individual subsystem debugging. Next, we created CAN Message variables for waveform selection and DigiPot output voltage. The infinite while loop controlled when to start; when the Keypad team pressed 1 a CAN Message was sent to break out of the while loop and output a waveform. Figure 6: Code Part 2 This block of code (Figure 7) generated square waves at either 1Hz or 10Hz. The wait time controlled the frequency by writing 1 (0xFFF) for one half of the period, and writing 0 (0x000) for the other half of the period. After generating the waveform there were function calls which represented the DigiPot scaling. These function calls appear in each waveform block. Figure 7: Code Part 3
The code below generated sine waves at 1Hz or 10Hz, and could also stop the DAC Output which effectively turned off our subsystems. The sine waves were generated by creating a discrete time sinusoid. The wait time was determined through trial-and-error to produce the most accurate frequency and the factors of 0.5 were needed to avoid clipping. The DAC output was stopped by writing 0(0x000) when the # key was pressed on the Keypad. Figure 8: Code Part 4 The following code in Figure 9 told the DigiPot where to set the wiper in order to produce the desired peak to peak voltage. The Voltage Codes corresponded to a wiper position, Dn, which ranged from 0-255 (256 positions).
Figure 9: Code Part 5 The last block of our code wrote the wiper position to the DigiPot which set the output to half of the desired voltage. This voltage was then doubled through a noninverting op-amp with Rf=Ri (See Figure 11). The Digipot had the following protocol: Deselect the device, Select the device, Send a Command Byte telling the Digipot the data is coming, Send the Data, Deselect the device. Figure 10: Code Part 6
Figure 11: Multisim Implementation of DigiPot Circuit Figure 12 shows our DAC and DigiPot Subsystems connected and powered. The numbers represent: 1 = mbed, 2 = DAC, 3 = DigiPot, 4 = Op-amp, 5 = CAN Transceiver, and 6 = mydaq (used to power op-amp and measure input & output). Figure 12: DAC and DigiPot Circuitry
Verification Testing Description: Our DAC output tied directly to the DigiPot input. The DigiPot Output went to our op-amp circuit for scaling by a factor of 2. This voltage was then sent to the black box. (See Figures 11 and 12) Outlined in red is our total subsystem (Figure 13). It was responsible for generating inputs to the black box. Module and Interface Schematics: Below are the pinouts for the mbed (Figure 14), the DAC (Figure 15), the DigiPot (Figure 16), the op-amp (Figure 17), and the CAN Transceiver (Figure 18). Pins 9 and 10 on the mbed connected to Pins 4 and 5, respectively, on the DAC. This established the I2C connection. Pins 11, 13, and 14 on the mbed connected to Pins 3, 2, and 1, respectively, on the DigiPot. These connections were for the SPI communication and the Chip Select (Code Part 6). The DAC Output (Pin 6) connected to Pin 5 on the DigiPot. See Figure 11 for the other DigiPot and op-amp connections. To connect our CAN to the Keypad CAN, our pins 6 and 7 had to be tied together.
Figure 14: mbed Pinout Figure 15: DAC Pinout Figure 16: DigiPot Pinout Figure 17: Op-amp Pinout
Figure 18: CAN Transceiver Pinout Method of Testing and Verification of Requirements: To test the output of each subsystem, we utilized the oscilloscope functionality of the mydaq. The PuTTY software was used to observe the button presses from the pc keyboard and verify the mbed was receiving them correctly. We used pc.getc( ) in our C code for individual subsystem debugging. As shown in Figures 19-22, the waveforms were accurately generated. Figures 23-28 show various waveforms getting scaled to the appropriate levels. These results were highly accurate considering a finite number of positions of the wiper within the DigiPot. Our results could only be as accurate as the components used. We were limited by resistor tolerances and wiper positions. These prevented us from getting exactly the desired voltages. However, our results were within 2%.
Figure 19: DAC Output 1Hz Square Wave Figure 20: DAC Output 10Hz Square Wave
Figure 21: DAC Output 1Hz Sine Wave Figure 22: DAC Output 10Hz Sine Wave
Figure 23: DigiPot Output 0Vpp Figure 24: DigiPot Output 1Vpp
Figure 25: DigiPot Output 2Vpp Figure 26: DigiPot Output 3Vpp
Figure 27: DigiPot Output 4Vpp Figure 28: DigiPot Output 5Vpp
Testing Results: The results of our testing are shown below: Figure 29: DAC and DigiPot Subsystem Results These results are considered highly accurate because of component tolerances and a finite number of wiper positions on the DigiPot. Validation Testing Our subsystem was useful for generating the inputs to the black box. In order to see what s inside a black box one needs to generate inputs and collect outputs. The Keypad subsystem exposed us to CAN Protocol, but we could have used our method of pc.getc( ) to select waveforms and amplitudes as well. Results from Integrated System We tied together all subsystems without any error (Figure 30). Before we received the black box, we tied the op-amp output to the ADC input to verify they sampled exactly what we generated.
Keypad Circuit DAC and DigiPot Circuit Black Box ADC Circuit Figure 30: Total System Integration Once we had the black box circuit connected, we sent a series of waveforms and observed the changes from input to output. We observed that the Output voltage contained a factor of 0.1*Vin (Figures 31 and 33). We also noted an inversion of the waveform (Figures 32 and 34). We concluded that the Transfer Function of the black box was: Vout = 1-0.1Vin This showed the scaling factor and a DC Bias of 1V. These results were consistent with the changes in the waveform below. This circuit could have been created with an inverting op-amp, and Ri that was ten times larger than Rf. Then a DC Bias of +1V would create the suspected Transfer Function.
Figure 31: ADC Sampling when input is 1Vpp 1Hz Square from DigiPot (plotted in MATLAB) Figure 32: Oscilloscope Viewing Input and Output of Black Box for 1Hz Square
Figure 33: ADC Sampling when input is 1Vpp 1Hz Sine from DigiPot (plotted in MATLAB) Figure 34: Oscilloscope Viewing Input and Output of Black Box for 1Hz Sine
Discussion Approach to Module, Network Interface, and Debugging We approached the modules by first creating block diagrams and flow charts. This decomposition took difficult tasks and broke them down to simpler tasks that we could implement. We then started familiarizing ourselves with the mbed and how to flash code onto it. Next came waveform generation which started by creating an artibrary square wave. The sine waves were more difficult, but we eventually figured it out. The DigiPot subsystem was easier to create because we gained experience doing the DAC Subsystem. We merged the two subsystems and used a version of code containing pc.getc( ) commands, rather than CAN Messages, for debugging. This along with the mydaq as an oscilloscope was exactly what we needed. We verified accurate results and could then integrate with other teams. The network interfacing was done by reading the datasheets for the DAC and DigiPot. Within them, we saw typical applications using I2C and SPI, respectively. This expedited the implementation, allowing communication within our circuit. Once we integrated all subsystems and wired a CAN Transceiver, we learned of its usefulness. We no longer needed a host computer for our subsystem. Also, any messages that didn t pertain to our subsystem was ignored, like ADC Commands. There are other alternatives, but CAN is inexpensive and easy to implement. It is also widely used in industry, giving us valuable experience. Modifications to Design During Integration Our DAC design remained the same throughout the lab. We made a change to the DigiPot design, namely from using two op-amp circuits, to one. Originally, we were using two inverting op-amps with the DigiPot, but we could not get the correct output. After some research, we decided to change our design and it proved to be the right decision. During integration, we had to flash a different version of our code onto the mbed. We had one code for individual testing and debugging using the aforementioned pc.getc( ) commands. We also had the same structure in another code, replaced with CAN variables and messages. This kept everything organized and provided an easy way to go from integration to debugging and vice versa.
Changes to Better Perform If Lab Was Done Again If we did the lab again, one change would be to organize our group to work on certain tasks simultaneously. One person to record our findings and progress, and the other two to work on the circuitry and the code. Then every hour the tasks would circulate making each person capable of each task, if one was ever absent. With the other groups, we would communicate using email during the entire development process in order to speed up integration between the subsystems. It is important to have contact information for everyone in your group, but also at least 1 person from each subsystem. This makes it easy to coordinate integration outside of class, making Demo Day go much smoother. Conclusion The implementation was a success. All subsystems integrated together without any issues, which could be attributed to starting the integration ahead of schedule. It was important to not fall behind by sticking to the suggested timetable. Our design proved very effective in generating required inputs to the black box. This allowed us to determine what the transfer function was. In the real world, subsystems get integrated everywhere, so this lab was very practical and exposed us to various communication protocols. We gained valuable design experience in this lab, and can use the knowledge we gained to better our teaming skills and design skills in future projects. Appendices Appendix A: Gantt Chart
Appendix B: Bill of Materials