Ee475 Lab2 Final

Project 2
Microprocessor Based Data

Collection System
EE 475 B
May 03, 2016
NAME
Jeffrey Nguyen
Jesus Sandoval
Minhhue H. Khuu
SIGNATURE
STUDENT ID
Table of Contents:
1.
ABSTRACT ............................................................................................................................................... 3
2.
INTRODUCTION ...................................................................................................................................... 3
3.
DISCUSSION OF THE PROJECT ............................................................................................................ 3

3.1 DESIGN SPECIFICATION .......................................................................................................................... 3
3.1.1
System Description ....................................................................................................................... 4
3.1.2
Specification of External Environment ......................................................................................... 4
3.1.3
UML Diagram .............................................................................................................................. 8
3.1.4
UML Textual Description............................................................................................................. 8
3.2 DESIGN PROCEDURE ............................................................................................................................... 9
3.2.1
Tools ............................................................................................................................................. 9
3.2.2
Modelled Input design ................................................................................................................ 10
3.2.3
Measurement and Collection Unit Design ................................................................................. 10
3.2.4
Local Controller Design............................................................................................................. 11
3.2.5
Circuit Design and Implementation ........................................................................................... 11
3.2.6
Circuit Design and Implementation ........................................................................................... 11
3.3 SYSTEM DESCRIPTION .......................................................................................................................... 12
3.3.1
Hardware Modules..................................................................................................................... 12
3.3.2
Software Modules ....................................................................................................................... 13
3.3.3
Public Interface .......................................................................................................................... 13
3.3.4
Inputs .......................................................................................................................................... 13
3.3.5
Outputs ....................................................................................................................................... 14
3.4 SOFTWARE IMPLEMENTATION .............................................................................................................. 14
3.4.1
3.4.1 Phase One Software Implementation (C Code) ................................................................. 15
3.4.2
Phase Two Software Implementation (C Code) ......................................................................... 18
3.5 HARDWARE IMPLEMENTATION ............................................................................................................. 23
3.5.1
Block Diagrams .......................................................................................................................... 23
3.5.2
Thermocouple ............................................................................................................................. 25
3.5.3
Amplifying .................................................................................................................................. 25
3.5.4
Flow Rate ................................................................................................................................... 25
3.5.5
Measurement unit processor ...................................................................................................... 26
3.5.6
Shift Registers............................................................................................................................. 26
3.5.7
LCD ............................................................................................................................................ 26
3.5.8
Local Control unit processor ..................................................................................................... 26
3.5.9
SRAM ......................................................................................................................................... 27
4.
TESTING ................................................................................................................................................. 27
4.1 TEST PLAN............................................................................................................................................ 27
4.1.1
InfiniiVision 4000 X-Series Multiple Signal Oscilloscope ......................................................... 27
4.1.2
Digital Multimeter ...................................................................................................................... 27
4.1.3
LCD Display............................................................................................................................... 28
4.1.4
PuTTY Terminal display............................................................................................................. 28
4.2 TEST SPECIFICATION ............................................................................................................................ 28
4.2.1
Part 1: Simple Voltage Measurements ....................................................................................... 28
4.2.2
Part 2: Counter .......................................................................................................................... 28
4.2.3
Part 3:PIC Processor To LCD and SRAM ................................................................................. 28
4.3 TEST CASE ............................................................................................................................................ 30
4.3.1
Part 1: Simple voltage Measurements ........................................................................................ 30
4.3.2
Part 2: Flow rate counter digital input measurement ................................................................ 30
4.3.3
Part 3:PIC Processor to LCD and SRAM, PuTTY Terminal ..................................................... 30
5.
PRESENTATION, DISCUSSION, AND ANALYSIS OF THE RESULTS ........................................... 30

5.1 PART 1: VOLTAGE TESTING ON INPUT SIGNAL ..................................................................................... 30
5.2 PART 2: FLOW RATE MEASUREMENT DIGITAL COUNTER OUTPUT ........................................................ 31
5.3 PART 3: PIC PROCESSOR TO LCD AND SRAM, PUTTY TERMINAL ..................................................... 32
5.3.1
Testing I2C ................................................................................................................................. 32
5.3.2
Testing address Generation........................................................................................................ 34
5.3.3
Testing Write to SRAM ............................................................................................................... 35
5.3.4
Testing Read to SRAM................................................................................................................ 36
5.3.5
Testing a Full Measurement Reading......................................................................................... 37
5.4 FAILURE MODE ANALYSIS ................................................................................................................... 37
5.4.1
Phase 1 Data Collection Unit (Slave) ........................................................................................ 38
5.4.2
Phase 2 Local Controller (Master) ............................................................................................ 41
5.5 ANALYSIS OF ERRORS AND POSSIBLE ERRORS ..................................................................................... 42
5.5.1
Software ..................................................................................................................................... 42
5.5.2
Hardware ................................................................................................................................... 42
6.
SUMMARY AND CONCLUSION ......................................................................................................... 43
7.
AUTHORS AND CONTRIBUTIONS..................................................................................................... 44
1. Abstract
The goal of lab two was to create a measurement and collection system to record and display
4 types of measurements: salinity, carbon, flow rate and temperature. The system also would
implement a remote control unit that would communicate with multiple measurement units and
send, record and display measurement commands across a PC and store and read previous values.
In this report you will see how each part of this system was implemented starting from the design
specifications to the hardware and software designs. We tested varying input voltages simulating
carbon, salinity, and temperature voltage from a thermocouple as analog inputs and a digital flow
rate input simulated by square wave from a signal generator. Testing these using commands input
by a control pc for each reading and seeing correct values displayed on our pc and system LCD
display in the specified mapping and range of the design specifications. Finally, we analyzed the
results of these test for correctness and error and discussed our findings.
2. Introduction
In this project, we created a measurement and control unit using a pic microcontroller and c
programming to read measurement inputs for the 4 measurement types. We used op amps to
amplify simulated carbon and salinity input voltages and to amplify thermocouple temperature
voltage. We also used a 12-bit counter and and-gates to capture input flow rate from a signal
generator square wave. After inputs we programmed the pic to translate and map these values to
specified ranges and display them on an LCD. Next we implemented a controller unit also using a
PIC to select and transmit data between multiple measurement units. Using I2C protocol to
transmit and receive data between master control PIC and slave measurement PIC. We also
implemented RS-232 protocol on the controller pic to communicate with a PC for a user to input
desired measurement commands from a remote PC connected to the controller. Finally stored and
read measurement data to/from an SRAM. The tools we used to program the PIC was MPLAB
IDE and c language. Then used power supply, signal generators to power and input into the system
and mustimeters, oscilloscope and LCD display to test results. In the following discussion we
provide the details of the system for hardware and software.
3. Discussion of the Project

The overall project is designed with the intention of getting familiar with the lab equipment
for taking measurements for analysis and trouble shooting. For this Project, the project is broken
up into three parts: (1) Making Basic Measurements, (2) Making Complex Measurements, and (3)
Even More Complex Measurements using an SRAM and GAL chip.
For the record, the parts (1) and (2) are mostly tutorial sections, therefore they will be very
basic by nature. Part (3) consists of a design process and as a result, the bulk of this section will
focus on part (3).
3.1 Design Specification

This section contains the design specification written by our lab group, weeks prior to the
design procedure and has values that are the idealistic design speciation based on the description
given from the client. In the implementation created in this project from our lab group, we made
sacrifices to fit a more realistic and achievable result with the materials and budget given to us.
3.1.1 System Description

The first phase deliverables will include a stand-alone prototype system that will implement
the site based data collection, the sensor interfaces, the associated sensor drivers, the
environmental measurements, and the display of those measurements. Measurement results are
to be presented on an LCD display on the system front panel.
The second phase deliverables will include a local controller, an I C based local area network
between the local controller and the measurement collection system, and an RS-232 protocol
build between the local controller and a PC will be incorporated to complete the full system. The
local controller will be able to send commands from the PC to through the local area network
and then be able to receive and store data from the measurement processor.
2
3.1.2 Specification of External Environment

The measurement system will be placed in remote locations where the sensors will be exposed
to the outside environment, wind, rain, snow, and sun. Sensors will have exposure to temp within
the range of measurement of -30 C to 100 C. Also have exposure to air samples The measurement
device will not have a dedicated power source available at measurement locations. The unit is to
be portable and battery operated for all four sensors.
3.1.2.1 Phase 1 Data Collection Unit
3.1.2.1.1 System Inputs
The system shall support the measurement of the following kinds of signals
Carbon Sensor Readings:
High Readings: 5.0 mV
-Translates to 10.0 ppm 6%
Low Readings: 250.0 mV
-Translates to 350.0 ppm 6%
Salinity Sensor Readings:
High Readings: 300.0 mV
-Translates to 50.0 ppt 2%
Low Readings: 100.0 mV
-Translates to 5.0 ppt 2%
Flow Rate Sensor Readings:
High Readings: 10.00 KHz
-Translates to 1000.0 liters per second 1%
Low Readings: 1.0 KHz
-Translates to 100.0 liters per second 1%
Temperature Sensor Readings:
Readings per hour: 10 readings
Voltage Given By: Function Voltage minus Room Temperature
High Readings: Determined By Testing.
-Translates to 95 F 10%
Low Readings: Determined By Testing.
-Translates to 40 F 10%
Modeled input sensor reading and amplification

High Readings: 5V
Low Readings: 0V
3.1.2.1.2 System Outputs
The system shall display the four readings on a LCD.
High Readings: 5.0 mV. 0.01mV
-Translates to 10.0 ppm
Low Readings: 250.0 mV. 0.01mV
-Translates to 350.0 ppm
High Readings: 300.0 mV . 0.01mV
-Translates to 50.0 ppt
Low Readings: 100.0 mV. 0.01mV
-Translates to 5.0 ppt
High Readings: 10.00 KHz 0.01 Hz
-Translates to 1000.0 liters per second
Low Readings: 1.0 KHz 0.01 Hz
-Translates to 100.0 liters per second
LCD Display output
Temp
-30 to 100 Celsius
Conversion to F
50 to 90 Fahrenheit
Carbon
10.0 - 350.0 PPM
Salinity
5.0 -50.0 PPT
Flow Rate
100.0 LPS -1000 LPS
3.1.2.1.3 User Interface
The user shall be able to select the following using buttons and switches on the front panel of
the instrument
Selection between Four Reading Types:
Temperature
Conversion between C to F
Flow Rate
Carbon level
Salinity level
Power ON/OFF Switch
Reset Switch
The measurement results shall be presented on a LCD display. User choices are made via
PC remotely. Until remote system is active 2 Button select between 4 readings, 1 button select
for temperature conversion C to F.
3.1.2.1.4 System Functional Specification
The system is intended to make 4 different kinds of measurements taken from Voltage
readings and frequency readings. These measurements comprise of flow rate, temperature,
carbon, and salinity. The user should be able to change which sensor will be read. The user can
convert temperature readings from C to F. The system will be intended to be done remotely. The
system shall take in analog readings for temperature, flowrate, carbon and salinity. The system
will measure these readings and map them to an accurate and specified range. The system will be
selectable between different sensor reading options and display the selected reading on the LCD
display.
3.1.2.1.5 Operating Specifications
The system will be initiated with a reset signal to all reseting components
The system shall operate in the following reading areas.
Temperature: Between 0 to 20 C
Salinity: 5 to 50 ppt
Carbon: 10 to 350 ppm
Flow Rate: Between 100 to 1000 liters per second
Switches will control sensor reading to be displayed
3.1.2.2 Phase 2 Local Controlling Unit
3.1.2.2.1 System Description
The second phase deliverables will include a local controller, an I C based local area
network between the local controller and the measurement collection system, and an RS-232
protocol build between the local controller and a PC will be incorporated to complete the full
system. The local controller will be able to send commands from the PC to through the local area
network and then be able to receive and store data from the measurement processor.
2
3.1.2.3 System Inputs

The system shall control the settings for the measurements and save the data to the
SRAM. Inputs to the system are the measurements taken from Phase I and transferred via the
communications.
Selected Data: Selected Data controls the measurements taken from the measurement
management system.
Select Data [1:0]: Two-bit control line that selects what the measurement system will measure.
- 2b00 = Measure Carbon
- 2b01 = Measure Salinity
- 2b10 = Measure Flow Rate
- 2b11 = Measure Temperature
Measured Data: Measured data selected from Selected Data

-If Carbon: Carbon reading 10-350 ppm 6%
-If Salinity: Salinity reading 5-50.0 ppt 2%
-If Temperature: Temperature reading 40F -95F 10%
-If Flow Rate: 100.0-1000.0 LPS 1%
Console Input: Allows the user to control what readings they want to read from the SRAM.
3.1.2.4 System Outputs
The system shall display the four readings on the console from the SRAM dependent on the
user input.
Console Outputs:
10-350 ppm 6%
5-50.0 ppt 2%
100.0-1000.0 LPS 1%
Temperature Readings:
Fahrenheit /Celsius: Selected from console input
40F -95F 10%
4.4C 35C 10%
8-bit Bus Via the I C and RS-232 networks:
Select [1:0]: 2-bit data f selection of measurement
Sending a character: This character gets read from the slave (measurement capture system)
and gets interpreted as an input for measurements.
2
3.1.3
UML Diagram
3.1.4
UML Textual Description
3.1.4.1 Phase 1
Read Temperature
o The user can see a current sample of temperature reading
o Exceptions - out of range below -30 Celsius or above +100 Celsius
Select Celsius or Fahrenheit
o Select between Celsius or Fahrenheit conversion
o Exceptions not in temp read mode
Read Salinity
o The user can see a current sample of Salinity content
o Exceptions - out of range below 5.0 PPT or above 50.0 PPT
8
Read Carbon Level

o The user can see a current sample of Carbon content
o Exceptions - out of range below 10.0 PPT or above 350.0 PPM
Read Flow Rate
o The user can see a current sample of Flow Rate
o Exceptions out of range below 100.0 LPS 1000.0 LPS
LCD Display
o The user will see a displayed output values for all measurements
3.1.4.2 Phase 2
Select Measurement Unit 1-7
o The user will be able to remotely select between 7 measurement units
Read previous 16 readings
o The user will be able to remotely select between the previous 16
measurements
o Exceptions if less than 16 measurements have been measured, only
recorded values
3.2 Design Procedure

In this section we discuss the overall procedure we went through to design our system
according to the design specification. This means starting with the tools we identified to design
and test with, then proceeding to the three important designs to include the modelled inputs design,
Measurement and control unit design, and Local Controller And LAN design.
3.2.1 Tools
In this lab we used a multitude of tools primarily for creating and modeling analog input
signals, programming PIC microprocessor and then testing and measuring results.
We start with the tools needed to model input signals. Since not all sensors were available to
take measurements we needed we created sample signals using DC power supply for carbon and
salinity voltages varying in the specified ranges. For flow rate we used a function generator to
provide a square wave of a consistent frequency to model a specified flow rate also varying
between specified ranges.
To program our logic device which would be our PIC microprocessor we used C programming
language which was edited and created on Notepad++ and then analyzed compiled or built on the
MPLAB IDE. This combined with the PICKIT3 in circuit debugger allowed for us to program the
PIC microprocessor to our specified code giving it specific input and outputs and logic decision
making.
For communicating across RS-232 we selected PuTTY communication terminal. This allowed
for us to select communication ports as well as provided a visual textual input/output for our PC
to local controller.
Finally, the last tools we used were for testing/analysis of signals input and output. We used
a digital multimeter to measure voltages, resistance and current across our circuit for correct
9
values. More importantly we used InfiniiVision 4000 X-Series MSO to analyze multiple digital
logic waveforms and analog oscilloscope waveforms which were vital in testing and accuracy of
our desired signals.
Table 1. Table of Tools Used for this Lab
Tool
InfiniiVision 4000 X-Series MSO
DC Power Supply
Function Generator
Digital Multimeter
Notepad++
MPlab IDE
PICKIT3
PuTTY
Purpose
Analyze real world digital logic waveforms.
Used Fixed +5V Rail to power circuit
Used to generate a clock pulse.
Used to troubleshoot by measuring analog voltages.
Text editor.
Program Pic Microprocessor
Hardware programmer/debugger for PIC processor
Terminal communication software for RS232 commands
3.2.2
Modelled Input design

We were limited as most system designers are to actual inputs that would be connected to
our system. So in order to provide correct design we modelled sensors that would be fed into the
system. This included Carbon, Salinity, Temperature and Flow Rate sensor. We designed our
model for carbon and salinity sensors which would be voltage readings from specified ranges of
5-250mV and 100-300mV respectively by using a DC voltage supply. This would then be
amplified by an Op amp circuit with specific resistor values to be provided in the hardware details
but give a gain of 15-20 to be measurable and mapped in the measurement system. Temperature
would be provided by a J thermocouple voltage which would be in the microvolt range and would
also need amplification with an op amp circuit. Finally a Flow rate sensor would need to be
modeled by a function generator square wave which would provide a measureable and accurate
frequency and would be Anded with a controlled timed high input. This would be the modeled
input for an unknown flow rate which when processed by the measurement unit we could compare
results to the actual square wave frequency for correctness. This is how we designed the modeled
input for simulated inputs to our system.
3.2.3
Measurement and Collection Unit Design

The design of our measurement and control unit is centered around our 18F25K22 PIC
microprocessor. This would have programmed to handle and process all inputs reading values and
output desired display to an LCD and send information across I2C protocol to a local controller.
Our design takes 3 analog inputs for the carbon, salinity and temperature as measureable voltage
and mapped that to the ADC on the PIC. The ADC had a 10-bit mapping which we would have to
map to a desired value mapping of the ranges these represented on sensor scale. The flow rate
would be brought in on a digital data input bus from a 12-bit counter implementation of the flow
rate sensor. This means we would also take these digital inputs of high and low representing a
digital binary value for flow rate scale and map that with the desired output mapping for flow rate.
Each measurement reading would be initially selected with 2 control bits to select the desired
reading input for ADC or digital input bus and designated mapping but after I2C would be
implemented this would be changed to I2C commands and interpretation for desired reading. Once
a measurement was selected and mapped then we would design the character mapping for output
10
value along with descriptive text to display on the LCD display. For the 2nd phase of this system
we design I2C protocol commands to transmit desired measurement to be received by the
measurement unit and output data transmitted of the reading value to be sent by the measurement
unit. All this would be implemented by coded functions that would be programmed onto the PIC
microprocessor.
3.2.4
Local Controller Design

The local controller design would have three main functions to design, again centered
around the PIC microprocessor. First RS-232 communication from a master PC to this controller
PIC using RS232 protocol and connections to transmit and receive character for processing
commands and displaying information. Next we would design and implement I2C protocol to
connection with a slave measurement unit and possibly a large number of measurement units but
the for the purposes of this project only seven units but only implementing one. This I2C LAN
connection is designed to connect with the desired measurement unit, send a measurement type
command for initiating a measurement recording scan and then receiving data measurements from
the collection unit. Finally, we designed the local controller to interact with an SRAM for storing
and reading up to 16 previous readings from any of the 4 desired measurements and any of the 7
desired measurement units. So we decided to keep the measurement values in final form which
were positive values that varied from 0-1000 so we designed a 2-byte mapping of these integer
values and were mapped to the SRAM on dedicated locations for each measurement unit and
measurement type. After planning the design, we would implement this by connecting relevant
hardware and programming this controller pic to do all logic, mapping and translating of I2C data
transfer and RS-232-character recognition and display and read and translation to the SRAM.
3.2.5 Circuit Design and Implementation
In our circuit we decided to cleanly connect all components using stripped and measure wires
for power and ground and most relevant communication and measurement wires. Only on larger
data busses we decided to use jumper wires of same color and length and taped together and
isolated. Also we used jumper wires were inputs of reconnecting of those wires pins may change
often. We arranged all components to be relatively close to the system inputs they would be on to
minimize wiring length and color coded most common wires. Final depiction of our real life circuit
is provided below.
3.2.6 Circuit Design and Implementation
The circuit was designed and implemented. The components used will be explain in greater
detail in the hardware implementation. The fully built circuit is shown in Figure 1.
11
Figure 1. Real Life Circuit.
3.3 System Description

Our system is made up a measurement and collection unit and local controller for selection
and remote use of modeled multiple measurement and collection units the following describes the
hardware and software modules along with the input and outputs to the systems along with
descriptions of error handling and procedures for the overall system.
3.3.1
Hardware Modules
We have two systems in place the measurement and collection unit and then the local
controller and LAN unit.
First amplification module made of Op-amps for amplifications of input signals for 3
voltage reading for carbon, salinity, temperature. Temperature voltage being fed into the op-amp
by a j-type thermocouple. The next module is for the flow rate sensor which is an 12-bit counter
clocked by an anded and controlled unknown flow rate(signal generator square-wave) and
controlled high pulse from the PIC microprocessor. These are the inputs to our system for
modeling measured readings. Our processing module which is done solely by the PIC
microprocessor and handles on the logic of the system. The last module on the measurement and
collection system is the display module which utilizes a shift register for consolidation and
serialization of some data out ports to the lcd, and the LCD unit itself which is the display for all
measurements.
On the local controller there are 2 hardware modules, the processing and data storage. For
processing communication and selection for and across LAN we again use the PIC microprocessor
for all logic. The second module for memory is made up again of a shift register for port
consolidation and and SRAM for storage of all necessary data.
12
For both local controller and measurement and collection device there was a 20MHz clock
implemented as input for both PIC processors on the system.
3.3.2
Software Modules
Our software modules on the measurement and collection are 4 separate mapping modules,
one for each sensor which map the input values from ADC or digital bus to designated range value
for each type of reading. The next module is an output to LCD module which takes in reading
value from the previous modules and translate that to characters and designated descriptive text
display for reading type and then outputs to the LCD. To conclude the measurement and collection
device software module is the I2C module which interprets selection of measurement device as a
slave acknowledges, and accepts commands for reading type and in turn sends out measurement
data across same interface.
On the local controller there are four software modules, first the RS-232 module which
interprets characters across the RS232 protocol from a master pc and determines measurement and
collection device selection and measurement type selection. Also in this module measurement and
status of request will be displayed back to the terminal using character values as displayed text
across this RS232 protocol. The second module is for I2C protocol to first send request to a slave
measurement and collection device receive acknowledgment and then send commands for what
type of measurement is desired. Also on this module is receiving and translating data sent back
from the slave as measurement data again all while conforming to the I2C protocol. The final two
modules are to store and read data to and from the SRAM this will take the data from transmitted
from the measurement and collection units and store upto the last 16 measurements and when
reading will take from the designated measurement type and device requested from RS232
commands and display on across the terminal the selected reading.
3.3.3
Public Interface
Our public interface will be master pc terminal which has a welcome screen and
predetermined greeting and instructions for set text input commands for selecting a measurement
device, selecting a measurement reading type, and reading from previous 16 measurements of
selected type and device. This same terminal will display textual readings from the selected
measurement and device. Also it will indicate connection and status of taking measurement and
read and store mode. On the individual measurement and collection device there is a LCD which
will also textually display current reading of selected measurement.
3.3.4
Inputs
Input Signal
Temperature
Size
ADC
Carbon
ADC
Salinity
ADC
Description
Input voltage represented by 10-bit ADC conversion after
amplification of an op amp, describes the voltage range of
temperature from a thermocouple temperature reading.
amplification of an op amp, describes carbon voltage level input from
a modeled sensor reading
amplification of an op amp, describes salinity voltage level input from
a modeled sensor reading
13
Flow Rate
10 bit
Textual
commands
Chars
Counter output data bus, decribes value of a flow rate measurement

from an input unknown frequency measurement captured by the
counter increments.
Input character text by a user will initiate system commands for
measurement and reading selections.
3.3.5 Outputs
Output
Description
Signal
LCD TEXT Textual data representation for user to read measurement reading on a terminal
window, with descriptive information about readings
Terminal
Textual data representation for user to read measurement reading on a terminal
TEXT
window, with descriptive information about readings and commands
3.4 Software Implementation

To develop the state machine for our system, we had to utilize Verilog. With our Verilog code,
we were able to convert it to a EDIF file that could help bypass the Symbolic FSM compiler. After
bypassing the Symbolic FSM Compiler in ISPlever, we were then able to create the JEDC file that
could then be loaded through Super Pro onto our chip.
The code for this lab can be found in the included zip file submitted on canvas. Table 1 shows
the folder names that contain the implemented code after extraction.
Table 1. Folder names that contains the code written for this lab
Folder name of Code Purpose
/C/
Folder contains the two project files which contains the code for the
entire project.
To develop the microprocessor based data collection system, we had to develop it using C.
With our C code were able to utilize the program MPLAB X IDE to build, compile, and program
our microprocessor. The microprocessor that we used to program the C code onto was the
18F25K22 PIC microprocessor. For Phase One, of the data collection system, all software was
connected to the microprocessor directly through the PICKIT 3. For Phase Two, using a terminal
connection service such as PuTTY, we were able to utilize the serial communication of data from
the computer with the RS-232 connector.
14
3.4.1 3.4.1 Phase One Software Implementation (C Code)

When first programming to the 18F25K22 PIC microprocessor, we first have to declare the
ports. Using the following declarations, we were able to set the ports shown in Figure 2.
TRISA = 0b10111111;
TRISC = 0b00000000;
TRISB = 0b11111111;
ANSELA= 0b00000111;
ANSELB= 0b00000000;
Figure 2. Declaring the Ports and Inputs and Outputs for Analog.
Then to directly read the inputs and outputs, we declared the following variables as the
following pins shown in Figure 3.
#define _RS LATCbits.LATC3
#define _RW LATCbits.LATC2
#define _E
LATCbits.LATC1
#define _SERIAL LATCbits.LATC4
#define _OE
LATCbits.LATC5
#define _RCLK LATCbits.LATC6
#define _SRCLK LATCbits.LATC7
#define _SwitchPin0 PORTAbits.RA3
15
#define _c0
#define _c1
#define _c2
#define _c3
#define _c4
#define _c5
#define _c6
#define _c7
PORTBbits.RB0
PORTBbits.RB1
PORTBbits.RB2
PORTBbits.RB3
PORTBbits.RB4
PORTBbits.RB5
PORTBbits.RB6
PORTBbits.RB7
Figure 3. Declared Variables for Ports A, B, and C.

Then the next part of implementation of Phase One was to initialize our LCD. TO have our
LCD display data correctly, we had to follow a specific initialization process found in the LCDs
data sheet. Shown in Figure 4 is the initialization process determined for the LCD display.
void lcdINIT(){
delayMS(15);
setDB(_FUNCTION_SET);
toggle();
delayMS(5);
toggle();
delayMS(1);
toggle();
setDB(_SET_LINE); //FUNCTION SET/SET NUM OF LINES
toggle();
setDB(_DISPLAY_OFF);// DISPLAY OFF
toggle();
setDB(_CLEAR); //CLEAR DISPLAY
toggle();
setDB(_ENTRY_MODE); // ENTRY MODE SET
toggle();
setDB(_CURSOR); // DISPLAY ON: TURN ON BLINK /CURSOR
toggle();
}
Figure 4. Initialize LCD process.
Where in the initialization process, we have a delay function that sets a delay for 1 ms. When
creating the delay function, we called a series of Nop() that intentionally tells the processor to do
nothing for a set amount of time. As shown in Figure 5through though measurement using the
logic analyzer, we were able to get a near perfect delay of 1 ms 1%.
16
void delayMS(unsigned int unit){

unsigned int i;
unsigned int j;
for (i = 0; i < (2*unit); i++) {
/* exactly 1 ms */
for(j = 0; j < 127; j++){
Nop();
}
}
}
Figure 5. Delay function set to 1 ms.
Then for the measurement collection system itself, we would receive an analog reading of 0
1023, that would be mapped from a voltage given by the four system sensors. Plotting voltages
to the associated data values netted us the following equations shown in Figure 6.
carbonResult = (int)((.339321*carbonResult) +3.125);
salinResult = ((.109756 * salinResult) - 51.3048);
flowResult = flowResult;
if((tempSave >0) && (tempSave <322)){
tempSave = (int)((.10891 *tempSave) + 39.2);
}else if((tempSave> 322) && (tempSave<342)){
tempSave = (int)((.2 * tempSave) + 3.6);
}else if((tempSave > 342) && (tempSave< 455)){
tempSave = (int)((.141593*tempSave) + 25.57522);
}
}
Figure 6. Equations for Measuring System.
Notice in Figure X4, that the temperature has different mappings based off the voltage given.
This is modeled as such because temperature readings using the thermocouple wire is not strictly
a y = mx + b equation. So to model this, we created multiple y= mx + b equations when using
different temperature readings.
To send data through to LCD, we had to implement a shift register to save I/O ports on the
processor. Shown in Figure 7 is the code to set and shift data through to the LCD.
17
for(i = 0; i < 8; i++) {

_SERIAL = (parallel >> (7-i)) & 0x01;
shift();
}
Figure 7. Setting and shifting data to LCD.
3.4.2 Phase Two Software Implementation (C Code)
During the second phase we were to develop a local controller that utilizes a I2C and a Rs_232
between the local controller and the PC. As such this requires coding for two different 18F25K22
PIC microprocessors. As such we had to do two separate codes for the local controller and the
measurement collection system.
The measurement collection system was much like the code from phase 1, however it had to
implement the I2C network. As such it would read and send date through the network. For each
individual measurement collection system slave, it would be designated a slave number and when
designated, it would then function based off the clock send from the master local controller.
3.4.2.1 Measurement Collection System Slave:
Shown in Figure 8, is the receive function for the slave.
if(j == 8) {
break;
}
if(_CLOCKI2C == 1) {
if( j < 7) {
address += (_IN_DATA << 6 - j);
} else {
RW = _IN_DATA;
}
j++;
while(_CLOCKI2C == 1) {
}
}
Figure 8. Reading from local controller.
For the read function, the slave will activate on the first negative edge of the local controllers
sent clock. After receiving the neg. edge, it would then receive the data the command and
increment. The while(CLOCKI2C = 1) allows us to continuously wait until the next falling edge.
This assures us that each data read is on the clock cycle.
18
/* START TRANSMISSION */
while(1) {
if(j == 8) {
break;
}
command += (_IN_DATA << 7 - j);
j++;
while(_CLOCKI2C == 1) {
}
}
}
break;
}
Figure 9. Sending data to slave.
For the write function, the slave will send data to the local controller based on the clock. After
receiving the neg. edge, it would then shift the data to the command and increment. Data sent
through will be sent one bit a time, where the local controller will interpret and read the results to
SRAM.
3.4.2.2 Local Controller
The first part of implementing the Local Controller would be to receive commands through
the RS232 and interpret the data. As shown in Figure 10, we first receive the data after waiting
4750 bps and then receiving the data at a rate of 9600 bps. This ensures that we wont receive data
immediately on the clock edge.
19
void getRX() {
/* HALF DELAY */
delay_9k6();
delayTX9k6();
rx0 = _RX;
delayTX9k6();
rx1 = _RX;
delayTX9k6();
rx2 = _RX;
delayTX9k6();
rx3 = _RX;
delayTX9k6();
rx4 = _RX;
delayTX9k6();
rx5 = _RX;
delayTX9k6();
rx6 = _RX;
delayTX9k6();
rx7 = _RX;
}
Figure 10. RX data received.
After receiving the data from the RS-232, we can then interpret the data. When interpreting
the data, we could map the character received to w to be able to write the measurement data and
then press f,c,t, or t to select the data for the slave. Then by pressing r , the user can then
receive data from the slave. By pressing r, the local controller will then receive 16 data values
which can then bet written to the SRAM. Shown in Figure 11, is the code to interpret the received
data from the console.
20
getRX();
storedChar = getRXChar();
writeTXc(storedChar);
if(storedChar == 'w') {
/* writing */
writeI2C_slave_address(2, 0);
} else if (storedChar == 'f') {
writeI2C_data(0);
readingVar =0;
} else if (storedChar == 'c') {
writeI2C_data(1);
readingVar = 1;
} else if (storedChar == 's') {
writeI2C_data(2);
readingVar = 2;
} else if (storedChar == 't') {
writeI2C_data(3);
readingVar = 3;
} else if(storedChar == 'r') {
writeI2C_slave_address(2, 1);
writeTXnl();
strcpypgm2ram(buf, "RECIEVING DATA FROM SLAVE...");
writeTXsln(buf);
delayMS(100);
for(j = 0; j < 32; j++) {
readI2C(j);
}
writeToSRAM();
Figure 11. Interpreting Console Data and Writing to the SRAM.
To write directly through to the I2C line, we have to first set a pulse signal (the clock) and
then output the data to the data line. Shown in Figure 12is how we set the clock and the output.
21
delayMS(100);
_OUT_DATA = 0;
delayMS(50);
_CLOCKI2C = 0;
/* CLOCK */
delayMS(50);
_OUT_DATA = (c >> 7) & 0x01;
delayMS(50);
_CLOCKI2C = 1;
delayMS(25);
_CLOCKI2C = 0;
delayMS(50);
_OUT_DATA = (c >> 6) & 0x01;
delayMS(50);
_CLOCKI2C = 1;
delayMS(25);
_CLOCKI2C = 0;
Figure 12. Writing to I2C Network.
Do note that in Figure X10s data it is being sent 8 times and as such only 2 clock pulses are
shown in Figure 13.
To read through the I2C network, it is sent in a similar manner, data bits are being sent 8 times
with a generate clock cycle. Shown in Figure X11, is how we read through the I2C network.
toggleReadI2C();
byte[i] = 0x00;
/* init values */
delayMS(100);
_CLOCKI2C = 0;
delayMS(100);
_CLOCKI2C = 1;
delayMS(100);
byte[i] +=_IN_DATA;
_CLOCKI2C = 0;
delayMS(100);
Figure 13. Reading through the I2C Network.
Then to write to the SRAM we have to get the address by the following formula:
Address = (slave Number * 128) + (read Number *32) + (measurement Number*2);
After setting the address location, we can then just set the data byte directly to the SRAM as
shown in Figure 14.
22
void setDataByte(int num){

_OUT_D0= num & 1;
_OUT_D1= (num>>1) & 0x01;
_OUT_D2= (num>>2) & 0x01;
_OUT_D3= (num>>3) & 0x01;
_OUT_D4= (num>>4) & 0x01;
_OUT_D5= (num>>5) & 0x01;
_OUT_D6= (num>>6) & 0x01;
_OUT_D7= (num>>7) & 0x01;
}
Figure 14. Writing Directly to SRAM
3.5 Hardware Implementation

This is our hardware implementation starting with our top level block diagrams of both
subsystems of our design, measurement and collection system and Local controller over LAN.
Then we go into the specifics of the hardware and explanation of each design choice in our
implementation.
3.5.1
Block Diagrams
23
Table 7. Table of Hardware Chip Components Used

Hardware
Component
Part No.
Description/Purpose
20 Mhz oscillator
OSC-20
Input clock to system input to both local controller

and measurement unit
12-bit Counter
CD4040B
Modeling and capturing Flow rate sensor data
And Gate
CD4081
Modeling and capturing Flow rate sensor data
Non-inverting Opamp
UA741CN
Amplify input voltage signal for modeled temp,

carbon, and salinity
PIC Microprocessor
18F25K22
Logic unit and processor for measurement system

and local controller
Shift register
C595N
Reduce pin usage with serialization of data
LCD Display
HD44780
Display measurement results to user
SRAM
CY7C128A
SRAM
Storage for the Data values
RS-232 adapter
MAX232
Implement connection of RS-232 from system to PC
24
3.5.2
Thermocouple
A J-type thermocouple wire was used to provide a voltage for temperature measurement.
This measurement temperature difference would be in the microvolt range so would need
amplification for measureable values input into our measurement system.
3.5.3 Amplifying
We used to 3 Op-Amps UA741CN chips to amplify the voltage signals of the 3 inputs for
modeled measurements of carbon, salinity and actual thermocouple temperature voltage. We
designed the op-amp circuit to have different gains using the below picture as reference and
specified resistor values to reach gains of 20, 15, and 1000 respectively. We also flipped the input
voltage references to cancel out the inversion of the inverting op-amp design.
Gain Rf (Ohms) Rin (Ohms)

20
20000
1000
15
15000
1000
1000 1000000
1000
3.5.4 Flow Rate

To model and capture flow rate measurements we used 3 hardware components. We start with
an input flow rate modeled by a function generated square wave at a set frequency within our range
of 1 KHz to 10 KHz. This signal is used with an CD4081 AND gate connected to +5 power and 0
ground using one 2 input channel for the generated square wave and a controlled second input of
a measured time we chose 100ms high pulse. The combination would give us a oscillating output
25
wave for the set amount of 100 ms which we input into a CD4040b 12-bit counter clock input.
This 12-bit counter was also connected to +5v power and 0v ground and 10 bits of output were
connected on a digital input bus to the pic microprocessor. Also a reset input signal to the counter
was set after collecting any sample by and from the PIC microprocessor. This flow rate system
allowed for a count which could processed and calculated in software to measure frequency or
simulated flow rate.
3.5.5
Measurement unit processor

We used the 18F25K22 PIC microprocessor to process all logic on input and output of this
measurement unit system. Connected to +5v power and 0v ground, we used a manual switch to
power and ground for its reset as input on its reset port. Three analog ports were used for analog
input of carbon, salinity, and temperature inputs. A clock input from a 20MHz crystal oscillator
would input to the PIC for system clock. We also had 10 digital input data bus for the flow rate
sensor. As far as outputs we were able use 2 outputs ports for flow rate control as described above.
Two ports were set as clock and data for I2C implementation and as a slave unit meaning the clock
was solely and input while data was I/O. The remaining ports were used for LCD control and data
but the data was serialized and sent through a shift register to consolidate ports from 8 to 4. This
was the purpose of using this processor on top of it being cheap it was powerful enough and had
enough ports for use with our design and when limited we consolidated using shift registers.
3.5.6
Shift Registers
The C595N shift register was used importantly on our data busses to consolidate pins and
allowed for us to economise pin usage. We simply used 4 pins 2 clocks for generated from the
PIC processor and 1 serialized data pin and an output enable control pin also generated by our
PIC processor.
3.5.7
LCD
The LCD we chose was a standard HD44780 2x16 display. It allowed us to write ascii
characters to display our measurement readings. We connected control pins and data pins from the
Measurement unit processor along with +5v power and 0V ground and used software in the
processor to encode the characters we wanted to display. We were able with the 16 characters on
one line to display description of the reading along with value of no more than 5 digits and units.
3.5.8
Local Control unit processor

For the processor of the controller unit we also used the 18F25K22 PIC microprocessor as
it it was capable providing enough I/O ports for I2C, RS-232 , and finally Address and data bus to
the SRAM for storage. We still used a 20 MHz crystal oscillator for input clock signal to this
control unit. Again 2 ports were used for I2C protocol as master meaning the clock signal was
solely generated by this PIC and dat was I/O. RS232 used 2 ports for transmit and receive, output
and input respectively. 8 ports were used as an input and output data bus connection the the SRAM.
6 ports were used as output address ports to the SRAM, along with 2 control bits for write enable
and output enable on the SRAM. This allowed for full control of the SRAM read and write and
were able to communicate with master pc through rs232 port. I2C allowed for us to connect to
multiple slave measurement units but in this specification we simulated 7 units only implementing
one actual unit to read on 7 slave addresses.
26
3.5.9 SRAM
One CY7C128A 2048x8 SRAM chip was used as memory for writing to and reading
from measured data.. This chip was provided in the EE 475 lab kit. This chip has 11-bits inputs
for the address lines connected by the register from the counter. It also has 8 data input/output bits,
which is input by the tri state buffer when being written and as output when being read. It has 3
control inputs CE (chip enable) active low used when using multiple SRAMs which we connected
to ground for the purposes of this lab as it is the only memory chip we will be accessing. WE
(writeEnable) and OE (outputEnable) which were inputs from our state machine and were active
low. These signals were offset to WE active OE not active when writing to the SRAM and WE not
active and OE active when reading from the SRAM otherwise they were both set to not active by
the state machine. Finally, VCC and GND were connected to 5V power and 0V ground
respectively to power the chip.
4. Testing
The testing of the design was broken up into three segments, all of which contributed to the
testing process: (1) Test Plan, (2) Test Specifications, and (3) Test Cases. The test cases are
developed based on the specifications of the test for the general test plan for each testing tool. The
results of the test are shown in Section 5.
4.1 Test Plan

In this lab, the followings tools were used to test and measure results for our lab
InfiniiVision 4000 X-Series Multiple Signal Oscilloscope
Digital Multimeter
LCD display
PuTTY Terminal
4.1.1 InfiniiVision 4000 X-Series Multiple Signal Oscilloscope
Having experience using the MSO we break down the use which consisted of the following
steps:
1. Determine the desired pins to measure.
2. Assign pins to a logic channel.
3. Set ground.
4. Add busses and labels.
5. Auto set and Scale.
6. Check threshold voltages.
7. Run/Stop and take a screenshot and save.
8. Or set trigger, run a single instance, and take a screenshot.
9. Evaluate result.
10. Repeat.
4.1.2
Digital Multimeter
The following steps were used for testing with digital multimeter in order to run test on
single channel voltages:
1. Determine the desired pin to measure.
2. Set voltage reading
27
3.
4.
5.
6.
Connect ground wire to reference ground on board

Connect Red measurement wire to desired pin
Evaluate result.
Repeat.
4.1.3
LCD Display
Testing for final output of the measurement and collection unit we use its display
capabilities to determine correct output. You select measurement unit and measurement type and
then read textual output
4.1.4
PuTTY Terminal display

Testing for final output of the local controller unit we use its display capabilities to
determine correct output. You select measurement unit and measurement type using specfied
commands and then read textual output on the terminal screen.
4.2 Test Specification

4.2.1 Part 1: Simple Voltage Measurements
1. Find all power, ground, and reset on all applicable hardware
2. Measure all specified ranges for input voltage and output voltage of sensors
4.2.2
1.
2.
3.
1.
Part 2: Counter
Verify the activity indicators for all 12 Digital Channels
Change the view to that of a Bus and back.
Display in HEX then back to binary.
Working with the users guide, configure the Pattern Trigger to trigger on the state binary
3 of the counter.
2. Modify the Pattern Trigger to trigger on the rising of bit 2 of the counter.
3. Change the view to that of a HEX Bus and configure the Pattern Trigger to trigger on the
state HEX A8 of the counter.
4. Configure the OR Trigger to trigger on the rising edge of counter bits 2, 4, or 6.
4.2.3
Part 3:PIC Processor To LCD and SRAM

Here we we decide how we measure desired output of the processor for both measurement
and collection unit and local controller.
4.2.3.1 Testing LCD Data and control signals
1. Using MSO Set the labels on digital input channels D8 ... D0 to R/W, RS, E.
2. Use 11 digital inputs for Data lines going into LCD display
3. Configure LCD input to run a character into LCD
4. Verify correct encoding of all input signals with waveform on logic analyzer
5. Using the LCD Display test whether correct display of a character is on the screen
28
4.2.3.2 Testing I2C

1. Connect MSO to 2 oscilloscope probes one for Data Line and one for clock.
2. Run a command or communication across I2C
3. Scale MSO to capture full waveform timing of a single command
4. Capture waveform
5. Verify clock signal set to oscillate given pulses for specified bit amounts
6. Verify correct waveform for designated value address, acknowledge, Data bytes
4.2.3.3 Testing RS-232
1. Run character input to through PuTTy Terminal
2. Program Pic processor to echo Back character read sent by master
3. Read character typed into PuTTY terminal
4.2.3.4 Testing Address Generation to SRAM
1. Set the labels on digital input channels D10 ... D0 to A10...A0.
2. Use the digital input channels D10 ... D0 to monitor the signals address lines on the data
out of the local controller PIC. Use your labels to help you keep track of your signals.
3. Verify the activity indicators for all Digital Channels
4. Verify that proper the waveforms are displayed on the screen of your logic analyzer.
5. Configure the 12 digital channels as a bus and to display in HEX.
6. Your counter circuit is designed to count from 000 to 7FF. Verify that these values are
displayed on the screen of your logic analyzer.
4.2.3.5 Testing Write to SRAM
1. Move the digital input channels D7...D0 to the input / output lines on the SRAM. Connect
D10...D8 to the 3 control lines, and D15...D11 to the 3 most significant address bits.
2. Enable your local control PIC to repeatedly execute a write cycle to the SRAM. Confirm
that the sequence of all signals involved in the write operation agrees with that from the
data sheet.
3. Confirm that the block of patterns 00 to FF is written to the SRAM eight times. Note: here
we are only confirming that the data and write control signals are being properly
generated. We are not confirming that data is actually being written to the SRAM.
4.2.3.6 Testing Read to SRAM
1. Without changing the digital input channel configuration from the previous test, ensure
that the desired patterns are written to all 2K locations in the SRAM.
2. Enable your code in processor to repeatedly execute a read cycle from the SRAM. Confirm
that the sequence of all signals involved in the read operation agrees with that from the data
sheet.
3. Confirm that the block of patterns 00 to FF has been correctly written to the SRAM eight
times. By reading the stored data, we are confirming that data has been properly written
to the SRAM.
29
4.2.3.7 Testing a Full Measurement Reading

1. Select a measurement type and send command over PuTTY interface
2. Read measurement on LCD Type and value
3. Verify measurement on LCD is displayed on terminal PuTTy interface
4.3 Test Case

4.3.1 Part 1: Simple voltage Measurements
We will make measurements and ensure that the following are met:
Power +5V, ground 0V, and Reset to all
Measure voltage input ranges of sensor signals to specified ranges
4.3.2 Part 2: Flow rate counter digital input measurement
Counter counts
Waveform matches at trigger condition
Reset resets counter
4.3.3 Part 3:PIC Processor to LCD and SRAM, PuTTY Terminal
SRAM is able to read and write
LCD and terminal are able to display measurement reading
PIC microprocessor sends out correct results and output.
Waveform matches trigger conditions.
Resets reset PIC for measurement unit and local controller
Terminal displays for a designated command onto Putty Terminal interface
5. Presentation, Discussion, and Analysis of the Results

5.1 Part 1: Voltage Testing on Input Signal
The first test measurements we took were simple voltage measurements of power and ground
for all devices on the circuit. These values were easily read to be +5V and 0V. Resets that were
manually set also were measures to be either high value of +5 and low of 0V.
More importantly were the measured voltage values for input measurement signals for carbon
salinity and temperature and then the amplified values. We Created a table of captured
measurements.
Reading
Measure Input voltage range
Amplified Voltage range
Carbon
5mV-250mV
20mV-5.0V
Salinity
100mV-300mV
2.5V-4.5V
Temperature
.400mV-2.700mV
400mV-6.0V
30
The measured results for input sensor voltages test were measured to be in specified ranges
for both carbon and salinity sensors as we used a DC supply to model and input voltage at desired
ranges, after amplification of gain of 20-15 respectively we saw correct amplification readings and
results. For temperature although we saw specified microvolt ranges the amplification was not a
consistent gain of 1000 as the it seems the low voltage input would not give an accurate and
measurable input voltage to the op amp circuit. Therefor the op-amp amplification would
sometime vary from being a consistent 1000 gain amp. We adjust for the small range of of
measureable temperature differences and settled the amplification, then mapped this to a range of
values consistent with the actual temperature as measured by a temperature gun.
5.2 Part 2: Flow Rate Measurement digital Counter output

We hooked up digital probes to the output of our flow rate counter and triggered the unit with
the specified signal square wave signal anded with timed pulse to clock and watched for correct
triggering and up counting of this flow rate system.
Flow rate counter measurement.

This measurement verified correct functioning of our flow rate counter as it counted up
correctly as the square and pulse were activated. Correct translation of the flow rate sensor would
be tested and displayed later in LCD and terminal output.
31
5.3 Part 3: PIC Processor to LCD and SRAM, PuTTY Terminal

5.3.1 Testing I2C
Testing I2C protocol was more extensive through oscilloscope probing on the MSO as this
system could not be tested for correctness otherwise without implementing all other parts of the
system so we capture Default State, Write and Data transfer commands of our I2C implementation
to analyze correct setting of bits for transfer.
Default State
Analysis of Default state was that we were getting correct values for clock and data input
when not in use as both signals would be set high. The trigger for any start of communication
would be a low trigger as described in next section.
Write Function would trigger by a low data value on that data line driven by the master PIC
processor and then a pulsing clock signal from the master and corresponding bits would we set up
by a master PIC processor the values sent across so following bits would be verified for correct
implementation and an acknowledgement final data bit would test for communication on I2C.
32
Write Function I2C address 2 write command and acknowledgment

We analyzed sending a 7-bit address of 2 on data line with this waveform capture above
implementation as you can see by the waveform and significant clock values we get a start bit with
a following verified address of 2 on the first 7 bits, the following 2 bits were for Read/Write
function command and acknowledgement. So we were able to verify correct clock and target
address generation. All these signal values and timing conformed to I2C protocol.
Finally, full working I2C implementation would visible through a data transfer waveform as
we could see the correct start bit, clock timing and clock pulse number for desired bits along with
acknowledgement signal and following clock pulses and 2-byte data. The following waveform
capture from MSO would be our testing guideline for I2C.
33
Testing Data transfer of value 72 degrees Fahrenheit

Analysis of data transfer, we found correct data transfer values after address and
acknowledgement and command for temperature were processed the remaining signals were
indicative a of 2 Byte transfer of data. In our tested we sent the measurement multiple times as you
can see the signal repeating but this was a constant and unchanging temperature reading of 72
degrees. This verified our desire data transfer with lowest significant bit first as described in our
I2C implementation. Correct values were being transferred across the I2C line.
5.3.2 Testing address Generation
To test address generation, we used a PIC microprocessor to implement an incrementing
address bus to see changing address values then we measure these values on the MSO data inputs
probes hoping to see an incrementing address bus to show good address generation from the PIC
microprocessor.
34
Figure 27. Part 3, Address Bus

Analysis of address generation was that we had good incrementing value as displayed by the
figure above. This meant we had good address generation by the PIC microprocessor
5.3.3 Testing Write to SRAM
The writing operations are done by having the write signal high with a high reset signal. The
read signal must stay low for the operation to commit. During the write operation the PIC
microprocessor will test count from 0 to 2047. However, we will only be writing 0 to 255 on the
SRAM for all of the 2048 address locations as we did in previous lab for testing to the write to the
SRAM. In order, to ensure that we are writing to all address bit we will monitor the top 3 most
significant bits of the address and monitor the data bus. Figure 23, shows the waveform of a general
writing sequence. Notice that the read signal is low, whereas the write and reset signal are high.
35
Figure 23. Data and Address Bus, Writing

Analyzing the test results showed we were able to send the correct signals into the SRAM
which was a great test and result for our signals we want to be sent across the lines but to be sure
of correct writing to the SRAM we needed to Test reading from the SRAM as described in the
next section.
5.3.4 Testing Read to SRAM
The reading operation can only show non high results when there has been something written
into the SRAM. That being said we ran the read operation after running the write operation for a
duration in which all the memory locations have been written to. To enter the reading operation,
the read signal is high and the reset signal is high. The write signal must be low for the operation
to commit.
When the read operation starts, the PIC microprocessor will begin counting and the address
will be fed into the SRAM and with the output enable signal low (active low) the SRAM will begin
outputting data for us to capture. The read operation will read all 2048 memory locations of the
SRAM. The figure below, shows a general read operation. Notice that the read and reset signal is
high, and the write signal is low. In the waveform, there are slight glitches here and there. This is
the result of noise that is interfering with the circuit.
36
Figure . Data and Address Bus, Reading

Analyzing the read function from SRAM we see the correct values were written and stored
into each location of the SRAM this means that after implementing our read and write functions
for specific address and data we will be able to store desired measurements taken from our system
and recall them for display this will be tested in the final measurement testing section but we found
that we got correct and exact values for reading and writing to SRAM.
5.3.5
Testing a Full Measurement Reading

Testing a full measurement reading would be trivial of the system as we just check given
input and command for reading input on the PuTTY terminal. Comparison would be made of the
resulting measurement reading on the LCD screen and PuTTY terminal if we had same and
accurate measurement we had a fully working system.
Analysis, we were able to correctly display desired measurement readings for all 4
measurement types on both LCD and PuTTY terminal although we were not able to correct test or
verify correct reading and storing of SRAM data as our values different than the measured values.
This would be discussed in the error analysis but is indicative of a flaw in translating the data bytes
to store on the SRAM since we successfully tested we were able to write and read from the SRAM
as described previously.
5.4 Failure Mode Analysis

This section will cover the possible failures that will occur within our system based on the
type of input signals that are retrieved in both the local controller and data collection units are
stuck in a logical high or logical low state. In our system implementation a logical high is represent
at as 5V and a logical low is represented at 0
37
5.4.1 Phase 1 Data Collection Unit (Slave)

This section will focus on the data collection unit and the inputs and the system will face in
the operations permitted within the system. The inputs signals consist of reset, clock, flow rate,
carbon, salinity, and temperature input, I2C data, and I2C clock signals. This analysis primarily
focuses on the updated phase 1, which discards the selection switches for the temperature and
Celsius conversions.
38
Table 2. SA0 Input of State Machine Analysis

Input Signal
Reset
Clock
Flow Rate
Carbon
Salinity
Temperature
I2C Data
I2C Clock
SA0 Result
When the input is stuck on 0, the entire system will not operate. This is
because the input signal is an active low signal. If the power is also off while
the reset is off, then the entire system will be powered off yielding an output
of 0 on all lines. If the power is on, then the output of the system will yield
unstable and undeterminable results.
If Clock is stuck at 0, the entire system will fail, the system will never be able
to execute an operation. The system is dependent on a pulsing clock to be able
to move on an execute the program that is programmed on the PIC system.
If the flow rate temperature is stuck a logical 0, then the counter will NEVER
start counting and as a result the count on the flow rate will ALWAYS yield 0.
This result is too low to be mapped and as a result the LCD display will display
an ERROR describing it as too low to be considered as a result. Additionally,
the system will not log that as information and will indefinitely wait until 16
actual measurements are created that are in the bounds of our system
description.
If the carbon is stuck a logical 0, then based on the mapping from described in
our design procedure, it will yield a result that is too low to be mapped and as
a result the LCD display will display an ERROR describing it as too low to be
considered as a result. Additionally, the system will not log that as information
and will indefinitely wait until 16 actual measurements are created that are in
the bounds of our system description.
If the salinity is stuck a logical 0, then based on the mapping from described in
our design procedure, it will yield a result that is t0o low to be mapped and as
a result the LCD display will display an ERROR describing it as too low to be
If temperature is stuck a logical 0, then based on the mapping from described
in our design procedure, it will yield a result that is t0o low to be mapped and
as a result the LCD display will display an ERROR describing it as too low to
be considered as a result. Additionally, the system will not log that as
information and will indefinitely wait until 16 actual measurements are created
that are in the bounds of our system description.
If the I2C data line is stuck at logical 0, then at the moment that it became 0,
the unit will start checking and waiting for the I2C clock to start rising and use
it to catch data and check the addressing for the communication to the master.
That being said the unit will indefinitely wait for a clock edge and the system
is now stuck in an eternal wait.
If the I2C clock line is stuck at logical 0, then nothing will happen. The clock
line does not trigger anything by itself. However, if the I2C data line is also 0
then the clock line will be responsible for advancing the system forward out of
its eternal wait.
39

Input Signal
Reset
Clock
Flow Rate
Carbon
Salinity
Temperature
I2C Data
I2C Clock
SA1 Result
When the input is stuck on 1, the entire system will be operational. This is
because the input signal is an active low signal. The system will begin
behaving as programmed and described in the system description.
If the flow rate temperature is stuck a logical 1, then the counter will NEVER
start counting and as a result the count on the flow rate will ALWAYS yield 0.
This result is too low to be mapped and as a result the LCD display will display
an ERROR describing it as too low to be considered as a result. Additionally,
the system will not log that as information and will indefinitely wait until 16
actual measurements are created that are in the bounds of our system
description.
If the carbon is stuck a logical 1, then based on the mapping from described in
our design procedure, it will yield a result that is too low to be mapped and as
a result the LCD display will display an ERROR describing it as too high to be
If the salinity is stuck a logical 1, then based on the mapping from described in
our design procedure, it will yield a result that is t0o low to be mapped and as
a result the LCD display will display an ERROR describing it as too high to be
If temperature is stuck a logical 1, then based on the mapping from described
in our design procedure, it will yield a result that is t0o low to be mapped and
as a result the LCD display will display an ERROR describing it as too high to
be considered as a result. Additionally, the system will not log that as
information and will indefinitely wait until 16 actual measurements are created
that are in the bounds of our system description.
If the I2C data line is stuck at logical 1, then the system will not do anything,
because by default the data line is stuck at a logical 1. This means if any
communication needs to be done and the data line is stuck at 1, the
communication will never begin and as a result the system will not
acknowledge a transmission ever occurring and will indefinitely wait for a low
pulse to start the communication.
If the I2C clock line is stuck at logical 1, then nothing will happen. The clock
line does not trigger anything by itself. However, if the I2C data line is also 0
then the clock line will be responsible for advancing the system forward out of
its eternal wait.
40
5.4.2 Phase 2 Local Controller (Master)

This section will focus on the local controller unit that is responsible for selecting and targeting
slaves to start the communication system. The local controlling unit consists of the following input
signals which includes reset, clock, RSR232 RX, and I2C data.
Input Signal
Reset
Clock
RS232 RX
I2C Data
SA0 Result
When the input is stuck on 0, the entire system will not operate. This is
because the input signal is an active low signal. If the power is also off while
the reset is off, then the entire system will be powered off yielding an output
of 0 on all lines. If the power is on, then the output of the system will yield
unstable and undeterminable results.
If the RS232 RX line is stuck at logical 0, then the entire system will
indefinitely and eternally always read character 0x00 as an input character. The
system will echo at character 0x00 indefinitely at rate of 960 Hz. Other than
echo back the character 0x00, the system will print out an ERROR message
stating that the user needs to input a valid command character for a command.
As a result, while the signal is stuck at logical 0, then the entire system will
print out an error message indefinitely eternally.
While the system is retrieving data from the slave because of a read operation,
if the I2C data is stuck at logical 0, then the master will be reading the data bit
0 indefinitely. However, this is controlled by the I2C Clock line, when the edge
is pulsing.
41

Input Signal
Reset
Clock
RS232 RX
I2C Data
SA0 Result
When the input is stuck on 1, the entire system will be operational. This is
because the input signal is an active low signal. The system will begin
behaving as programmed and described in the system description.
If the RS232 RX line is stuck at logical 1, then the system will never read any
character from the RS232 communication system, as a result if a transmission
were to occur and the PIC is supposed to receive characters, then the PIC would
not receive any characters because the start bit can never start which is the
catalyst for the transmission line (the logical 0 start bit).
While the system is retrieving data from the slave because of a read operation,
if the I2C data is stuck at logical 1, then the master will be reading the data bit
1 indefinitely. However, this is controlled by the I2C Clock line, when the edge
is pulsing.
5.5 Analysis of Errors and Possible Errors

5.5.1 Software
When creating the measurement collection device, we first began to intercept and read signals
as inputs and outputs. With the received data, we would then be able to interpret and handle the
data.
When communicating between the PICs required us to minimize all ports through the use of
shift registers. Another difficulty was connecting and interpreting the data. When receiving data
through the I C.
Finding errors and anticipating difficulty then creating necessary solutions for the customer
was the greatest takeaway of this lab. Figuring out how to push through and meet deadlines of a
full design cycle made this lab realistic and very educational for real world needs and we feel
prepares us for engineering the real world.
2
5.5.2 Hardware
Throughout the entire project hardware wiring was an issue that became apparent. Most of the
time the wiring for the project was perfect and there wasnt that many times needed to actually
rewire things. However carefully, selecting the location for a chip to be placed was important for
the wiring of our system. The system consisted of custom wire that was stripped down to have a
perfect length that was as minimal as possible to prevent a signal integrity issue from occurring
due to the length of wire and the parasitic capacitance and inductance properties of wire.
However, when stripping down these wires it was difficult to place all of the strands of the
wires into a dip slot in the solderless bread board. As a result, when dealing with the RX and TX
wires for RS232 chip it was important to have the connection as clean as possible. This was to
ensure that the signal from the computer was perfect because at a frequency of 9600 and the delay
42
function made in the software implementation (roughly 9570 Hz) any amount of noise could mess
up the transmission and cause the RX and TX transmission to fail completely.
The integrity of the wiring was not as tight for the I2C communication since we were using a
smaller frequency but it was still slightly important to have good contact to have clean signal
transmission for the communication between slave and master.
When designing the op amp circuit there were many problems with the temperature op amp
which had a gain of 1000. Because the input voltage was so small any slight change in input could
easily swing the output of the amplifier. This was because the op amp used was not meant for such
delicate input voltages that were in the 100s of micro volt range. This was accommodated by using
capacitors at the output stage to hold the voltage for a while to reduce the amount of noise cause
from electrical properties due to electrical magnetic interference from the airwaves and other
natural occurrences. Signal integrity was also important and as a result we made the wires as short
as possible to prevent that from causing any issue.
Another issue we faced related to hardware was accurately connecting the wire to the
corresponding pins. A couple times in the lab, we were placing wires one slot away from the actual
slot that was required to make the connection. This was most likely due to the fact that we were
getting tired these errors were really hard to identified, but by the end we realized that this was a
common problem and we consistently checked each other on wiring.
Other than the issues mentioned earlier, there were no big hardware issues. We spent a lot of
time making the circuit as tight and clean as possible to prevent any signal integrity problems and
just make the circuit look neat and clean. We are quite proud of the presentation of our project.
The possible errors that we couldve faced include many things. If we didnt spend the time
making the wiring as tight and clean as possible, we couldve had issues with signal integrity. We
also couldve had errors when transitioning the project from one place to another, because the wire
would be loosely connecting making it prone to being disconnected accidently. Additionally, not
grounding certain ports could cause an error as well. On top of not grounding certain ports, not
carefully connecting all the ports in an IC chip could cause an error. Furthermore, reading the
specification of the ports in the data sheet was also an important factor because if the ranges arent
within specification this could cause an error. Therefore, the biggest take away in hardware was
making sure the wiring is tight and reading the datasheet for all IC chips used to ensure that the
system is behaving correctly because the chips are properly hooked up and used properly in its
specified range.
6. Summary and Conclusion

In summary this lab provided us the necessary design cycle experience for implementing a
measurement and collection and remote controller system. We started from the design
specification from the customer desired requirements and designed to those customer needs. This
included a system that would have 4 sensor inputs of carbon, salinity, temperature and flow rate.
We modeled and created inputs, amplifying signal for measurable values and sampling using flow
rate counters and control signals. Next we processed so those reading for display as the customer
specified on the LCD by input into a PIC microprocessor for handling analog and digital input and
translating and mapping the desired mapping for measurement values in software. Next the
processor would output to LCD display for visual readings. The second part of the system would
be a local controller designed to select a specific measurement unit and measurement type over
commands from a master PC. This was required to be implemented RS-232 communication cable
43
and protocol and from PC to local controller and from master local controller to slave measurement
unit over I2C protocol. We implemented these function using our software design PIC
microprocessor for the local controller in conjunction with the previous pic microprocessor from
the measurement unit. Correct transfer of data would be evident by display on the master pc
terminal which we implemented for RS-232 communication and user interface. Finally, with added
the feature to store and read previous readings by writing and reading to an SRAM and using
master pc commands to display these recorded values. We went through the design cycle of
implementing high level design with block diagrams and to real circuit implementation and
software coding and programming onto PIC processors. Then we would test expected and recorded
results at each module level in order to verify correct functionality of each subsystem. Once all
systems were would have correct functionality we could combine the system for general use and
debugging. Finally, and importantly we continued to document design, implementation, and
testing for record of our design cycle system development. We presented a final project demo and
supporting documentation for desired outcomes and shortfalls and analysis of measurement and
collection system. This was culmination of our real product development and design cycle lab.
In conclusion, the difficulty of this lab was figuring out how to model and use the PIC
microprocessors.
7. Authors and Contributions

NAME
CONTRIBUTIONS
Jeffrey Nguyen
Lead C Programmer, Measurement Mapping for Flow

Rate, Carbon, Salinity, and Temperature, print to
LCD, Hardware/Software Debugging, Lab Report
Jesus Sandoval
Lead Reporter (Diagrams and Analysis), SRAM

Implementer, Mapping Commands,
Hardware/Software Debugging, Lab Report
Minhhue H. Khuu
Lead Hardware Implementer, Lead Communication

Implementer (RS232 and I2C), Hardware/Software
Debugging, Made Internal C Libraries, Lab Report
44

Ee475 Lab2 Final

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ee475 Lab2 Final

Uploaded by

Copyright:

Available Formats

Project 2

Microprocessor Based Data

DISCUSSION OF THE PROJECT ............................................................................................................ 3

PRESENTATION, DISCUSSION, AND ANALYSIS OF THE RESULTS ........................................... 30

SUMMARY AND CONCLUSION ......................................................................................................... 43

AUTHORS AND CONTRIBUTIONS..................................................................................................... 44

3. Discussion of the Project

3.1 Design Specification

3.1.1 System Description

3.1.2 Specification of External Environment

Modeled input sensor reading and amplification

3.1.2.3 System Inputs

Measured Data: Measured data selected from Selected Data

UML Textual Description

Read Carbon Level

3.2 Design Procedure

Modelled Input design

Measurement and Collection Unit Design

Local Controller Design

Figure 1. Real Life Circuit.

3.3 System Description

Counter output data bus, decribes value of a flow rate measurement

3.4 Software Implementation

3.4.1 3.4.1 Phase One Software Implementation (C Code)

Figure 3. Declared Variables for Ports A, B, and C.

void delayMS(unsigned int unit){

for(i = 0; i < 8; i++) {

void setDataByte(int num){

3.5 Hardware Implementation

Table 7. Table of Hardware Chip Components Used

Input clock to system input to both local controller

Modeling and capturing Flow rate sensor data

Modeling and capturing Flow rate sensor data

Amplify input voltage signal for modeled temp,

Logic unit and processor for measurement system

Reduce pin usage with serialization of data

Display measurement results to user

Storage for the Data values

Implement connection of RS-232 from system to PC

Gain Rf (Ohms) Rin (Ohms)

3.5.4 Flow Rate

Measurement unit processor

Local Control unit processor

4.1 Test Plan

Connect ground wire to reference ground on board

PuTTY Terminal display

4.2 Test Specification

Part 3:PIC Processor To LCD and SRAM

4.2.3.2 Testing I2C

4.2.3.7 Testing a Full Measurement Reading

4.3 Test Case

5. Presentation, Discussion, and Analysis of the Results

Measure Input voltage range

Amplified Voltage range

5.2 Part 2: Flow Rate Measurement digital Counter output

Flow rate counter measurement.

5.3 Part 3: PIC Processor to LCD and SRAM, PuTTY Terminal

Write Function I2C address 2 write command and acknowledgment

Testing Data transfer of value 72 degrees Fahrenheit

Figure 27. Part 3, Address Bus

Figure 23. Data and Address Bus, Writing

Figure . Data and Address Bus, Reading

Testing a Full Measurement Reading