I’ve been wanting to organize my findings in a easy to read/reference way. So, I’ll be using a standard lab journal format for most of the things that i start as of now. Of course, it does not apply to everything. I’ve done so much stuff that i never wrote down anywhere, i want to be sure i can look back at stuff i do from now on. Anyway the standard format ill be using (thanks to my teachers)
Standard Lab Format
The following is a description of the standard lab format to be used:
I. Each lab entry should start with the title of the experiment and a brief description
II. The equipment to be used should be listed; leave some room below the initial list to add additional equipment and parts.
III.A prelab section (when applicable) should include any preliminary work to be done prior to coming to the lab.
IV. The procedure section describes the activities done in the lab. The reader of your journal should be able to follow your description without referring to a manual or handout, but you may summarize in your own words. Record your data, figures, sketches and observations. Be sure to label everything.
V. In the conclusions, you should write in a narrative style. Summarize your results and condense data when appropriate. Answer all questions asked.
ZoneMikel
CENG 4534 Spring 09
Final Project Report
This was posted via office, links might not work. Here is the dsdprojectforweb word document.
The purpose of this project was to create a four-bit arithmetic logic unit. This ALU was to take two four bit numbers and do the following operations to them: add, multiply, shift, nor, nand, or and and. The ALU has six main components, a shifter, a logic unit, an arithmetic unit a controller and two multiplexors. The rest of the details are in the report.
This project was done in a structural manor, and as such we have separate components for each unit.
I have laid out this report so that the information portrayed will be easy to verify and comprehend. For each component, there will be three parts in this document: the code, the explanation, the test bench waveform. I will attempt to show all cases in the test bench waveform permitted it does not become unsightly. I hope the reader will realize that to do every test case we would have more than 64 cases for each test bench, because of this I will not be doing every possible case.
On each waveform output, I have rotated it 90 degrees and explained the inputs and outputs right beside them. This should allow the viewer to simply hold a sheet of paper over the waveform output and see the explanation of the inputs and results. Most of the digits were left in hexadecimal for clarity, opening up the signals in the test bench and exposing each bit would have convoluted the diagram in most cases. In almost all the cases A counts up from 0 to F and B counts down from F to 0.
While creating this ALU I spent most of my time on the shift unit. I tried to make the shift unit shift left or right based on the value in number b using one or two lines of code as such:
output(x1 downto x2) <= a(x3 downto x4);
where x1,x2,x3,x4 were variables based off of the number found in variable b. This method proved to be very troublesome and was abandoned.
All of the other units were straightforward. I did not use any of my old components from previous homework’s; all of the units were created from scratch.
I have tested all of the units separately and as a whole with several different cases and have found no error in them.
The carry out variable may give false highs due to it not being routed through any multiplexor. It is assumed that what ever this ALU’s function it is understood that carry out is irrelevant with operations such as or and shift.
I actually just got done creating one of these in my computer architecture class, this one was different though. I now feel that I have a very thorough understanding of how an ALU functions. I also feel that I could make a calculator from scratch using what I have learned with these ALU’s.
---------------------------------------------------------------------------------- -- Company: UHCL -- Engineer: Michael McCarty -- -- Create Date: 13:48:37 04/24/2009 -- Design Name: -- Module Name: FA_4bit - Behavioral (4 bit full adder) -- Project Name: DSD_Project (4 bit alu) ---------------------------------------------------------------------------------- library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; entity AU_4bit is Port( a, b : in std_logic_vector(3 downto 0); -- inputs s: in std_logic; -- select g : out std_logic_vector(3 downto 0); -- output Cout : out std_logic := '0'); end AU_4bit; architecture Behavioral of AU_4bit is signal sum, prod: std_logic_vector(3 downto 0); -- product and sum begin -- convert to integer, add then convert to vector, 6 bits sum <= conv_std_logic_vector(UNSIGNED(a) + UNSIGNED(b), 4); -- when select is 0 we add else we multiply for s=1 -- the product is only the first two lsb of each a(1)a(0)*b(1)b(0)= prod prod <= conv_std_logic_vector(UNSIGNED(a(1 downto 0))*UNSIGNED(b(1 downto 0)), 4); -- if s=0 output sum if s=1 output product g <= sum when (s='0') else prod; -- send carry out bit, if its more than 15 Cout <= '1' when (((conv_integer(a) + conv_integer(b)) > 15) and s='0') else '0'; end Behavioral;

If the select value is ‘0′ then we add A and B, if the select value is ‘1′ then we multiply the two LSB of A and B together. In most of the multiplication cases it the product turned out to be 0 or 2, the second to last one has a product of 6.
Almost all of the addition cases have a sum of F, due to the nature of counting up A while counting down B. This allows you to quickly look at the output and see that it is correct.
The cases at the end demonstrate the carry out bit, since 15+2 is 17 in decimal or 11 in hex, our output becomes 1 with a carry out of 1. This gives a binary output of 10001, which is also 17.
In order to simplify the code I made use of the built in conv_ functions of vhdl. Both the sum and product of the numbers are taken each time, then a simple when statement allows the right output to be outputted depending on the select variable.
---------------------------------------------------------------------------------- -- Company: UHCL -- Engineer: Michael McCarty -- -- Create Date: 13:48:37 04/24/2009 -- Design Name: -- Module Name: SU_4bit - Behavioral (shift unit, 4 bit) -- Project Name: DSD_Project (4 bit alu) ---------------------------------------------------------------------------------- library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; entity SU_4bit is Port( a : in std_logic_vector(3 downto 0):="0000"; -- inputs b : in std_logic_vector(3 downto 0); -- inputs d : in std_logic; -- direction g : inout std_logic_vector(3 downto 0):="0000");-- output end SU_4bit; -- d=0 left shift 1 right shift, only shifts up to 4 times architecture Behavioral of SU_4bit is begin process(a,b,d) begin case b is when "0000" => g<=a; when "0001" => if (d='0') then g<=a(2 downto 0)& '0'; else g <='0' & a(3 downto 1); end if; when "0010" => if (d='0') then g<=a(1 downto 0)& "00"; else g <="00" & a(3 downto 2); end if; when "0011" => if (d='0') then g<=a(0)& "000"; else g <="000" & a(3); end if; when others => g<="0000"; end case; end process; end Behavioral;

Since there were only 4 different values that B could shift A by I did a simple process with a case statement for the four different values. Any time you shift more than four bits to the left or the right you totally wipe out whatever value was in A so if it is shifted by any value that is not in the range of 0 to 3 the output is automatically set to zero.
There is a if statement to handle the direction. Also, in order to fill the remaining bits with zeroes after we do the shift I just use VHDL’s concatenation operator “&” to append zeroes to the start or end.
There is also a VHDL operator to do shifts and rotations SHL and SHR which could have been used to solve this problem easier.
I spent lots of time on this trying to shift a directly into the output and replacing the (x downto x) with the number in B converted to an integer, this took me hours and eventually I gave up. If I were to try that again first I would write down all the possible cases then try it. I also tried to use a for loop and that didn’t work for me either.
---------------------------------------------------------------------------------- -- Company: UHCL -- Engineer: Michael McCarty -- -- Create Date: 13:48:37 04/24/2009 -- Design Name: -- Module Name: LU_4bit - Logic Unit -- Project Name: DSD_Project (4 bit alu) ---------------------------------------------------------------------------------- library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; entity LU_4bit is Port( a,b:in std_logic_vector(3 downto 0); -- inputs op: in std_logic_vector(1 downto 0); -- opcode in g: out std_logic_vector(3 downto 0)); -- outputs end LU_4bit; architecture Behavioral of LU_4bit is begin process(a,b,op) begin case op is when "00" => g <= a nor b; when "01" => g <= a nand b; when "10" => g <= a or b; when "11" => g <= a and b; when others => g <= "0000"; end case; end process; end Behavioral;

For the logic unit I created a process with a sensitivity list of A, B and Op, then I used a simple case statement based of the Op (opcode) to perform the logical operation required.
This unit was very simple. The test cases run A counting up and B counting down, the opcode goes to 3 and then returns to 0, this simulates every possible scenario. In most of the cases if you are counting up and counting down you end up with numbers that cancel each other out so in most, if not all cases you get a 0000 or 1111. This allows you to easily spot a error, if there were a output other than 0 or F that would be the most likely place for a error.
Since the code is so simple for this its straightforward and easy to debug. When things are simple they tend not to go wrong.
---------------------------------------------------------------------------------- -- Company: UHCL -- Engineer: Michael McCarty -- -- Create Date: 13:48:37 04/24/2009 -- Design Name: -- Module Name: MUX2_1_4bit two to one mux, 4 bits -- Project Name: DSD_Project (4 bit alu) ---------------------------------------------------------------------------------- library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; entity MUX2_1_4bit is Port( a,b : in std_logic_vector(3 downto 0); -- inputs s : in std_logic; -- select g : out std_logic_vector(3 downto 0));-- ouput end MUX2_1_4bit; architecture Behavioral of MUX2_1_4bit is begin g <= a when (s='0') else b; end Behavioral;



---------------------------------------------------------------------------------- -- Company: UHCL -- Engineer: Michael McCarty -- -- Create Date: 13:48:37 04/24/2009 -- Design Name: -- Module Name: ALU_Controller controls alu components bases off inputs -- Project Name: DSD_Project (4 bit alu) ---------------------------------------------------------------------------------- library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; entity ALU_Controller is Port( opcode : in std_logic_vector(1 downto 0); -- opcode and mode in mode : in std_logic; -- mode output : out std_logic_vector(5 downto 0)); -- all the outputs end ALU_Controller; architecture Behavioral of ALU_Controller is type arrayRom is array (0 to 7) of std_logic_vector (5 downto 0); constant Rom: arrayRom := ("000100","001010","000010","000000", "000001","010001","100001","110001"); begin output <= Rom(conv_integer(mode & opcode)); end Behavioral;

---------------------------------------------------------------------------------- -- Company: UHCL -- Engineer: Michael McCarty -- -- Create Date: 13:48:37 04/24/2009 -- Design Name: -- Module Name: ALU_4Bit_main this puts everything together to make the alu -- Project Name: DSD_Project (4 bit alu) ---------------------------------------------------------------------------------- library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; entity ALU_4bit_Main is port(a, b : in std_logic_vector(3 downto 0); -- input numbers op : in std_logic_vector(1 downto 0); -- opcode mode: in std_logic; -- mode and clock --clk : in std_logic; -- clk not used in this Cout : out std_logic; -- carry out g : out std_logic_vector(3 downto 0):="0000");-- output end ALU_4bit_Main; architecture Behavioral of ALU_4bit_Main is -- arithmatic unit component AU_4bit Port( a, b : in std_logic_vector(3 downto 0); -- inputs s: in std_logic; -- select g : out std_logic_vector(3 downto 0); -- output Cout : out std_logic := '0'); end component; -- shift unit component SU_4bit Port( a : in std_logic_vector(3 downto 0):="0000"; -- inputs b : in std_logic_vector(3 downto 0); -- inputs d : in std_logic; -- direction g : inout std_logic_vector(3 downto 0):="0000");-- output end component; -- logic unit component LU_4bit Port( a,b:in std_logic_vector(3 downto 0); -- inputs op: in std_logic_vector(1 downto 0); -- opcode in g: out std_logic_vector(3 downto 0)); -- outputs end component; -- two to one multiplexor component MUX2_1_4bit Port( a,b : in std_logic_vector(3 downto 0); -- inputs s : in std_logic; -- select g : out std_logic_vector(3 downto 0));-- ouput end component; -- controller component ALU_Controller Port( opcode : in std_logic_vector(1 downto 0); -- opcode and mode in mode : in std_logic; -- mode output : out std_logic_vector(5 downto 0)); -- all the outputs end component; -- variables signal cont:std_logic_vector(5 downto 0); -- logic out, arith out, shift out, MUX out signal LO,AO,SO,MO,M2O : std_logic_vector(3 downto 0); begin -- controller (opcode, mode outputs to cont) C1 : ALU_Controller port map(op, mode, cont); -- logic unit (a b 5th and 4th bit of control outputs to Logic out L1 : LU_4bit port map(a, b, cont(5 downto 4), LO); -- arithmatic unit (a, b 2nd bit of control outputs AO and Cout A1 : AU_4bit port map(a, b, cont(2), AO, Cout); -- shift unit (a, b 3rd bit of control outputs to SO S1 : SU_4bit port map(a, b, cont(3), SO); -- multiplexors first mo gets Arith and Shift and outputs to second M1 : MUX2_1_4bit port map(AO, SO, cont(1), MO); M2 : MUX2_1_4bit port map(MO, LO, cont(0), M2O); -- output is the output from the second Mux g <= M2O; -- If you want this to all happen to a clock, comment above line and uncomment below -- process(clk) -- begin -- if clk'event and clk='0' then -- g <= M2O; -- end if; -- end process; end Behavioral;

With this main design most of the code was declaring the entities. Then they were all port mapped to their right locations.
The output of each component was sent to a variable, for example the output of the shift unit was sent to SO. In this way I routed each of the components to each other through the signals. I’m not sure if you can route the components directly to each other but that would have been nice.
The final output comes from the second multiplexor and goes into the signal M20, from there we just output that. If we want it to only output on the rising or falling edge of a clock we could uncomment the process at the end of my code. This would hold the output in the signal and only pass it to the actual output on the rising edge of a clock. However, since I wanted to maintain clarity in this project I took it out. This way you can easily see the outputs of the ALU without having to worry about the clock.
|
Lab Project. The word document is here telecomprojectreportnn |
|
Pic 12F675 Temp Sensor Transmit Uart RS-232 |
|
This was posted via Office so it might look a little strange |
| 4/28/2009 |

The goals of this project were to demonstrate analog to digital conversion, and UART to RS-232 conversion, while working with a group.
Analog to digital conversion is used in many telecommunications networks such as VO-IP and streaming video, and signal conversion is used in almost any signal transmission. Knowledge of these two staples of the telecommunication world gives us a better understanding of the underlying foundation of community and our current communication infrastructure.
Team Basic consists of 6 members; members were polled and separated into three groups according to their ability and interests. The three categories were Hardware, Software and Documentation. There was lots of overlap between the categories and contributions, we all had to write documentation and there was a software aspect to the hardware.
A lassie-fair/human resources management style was used, in which each group member was given the chance to contribute his or her suggestions. This management style works best with rapid prototyping development, and for accessing the abilities and prospects of group members.
Execution of the product design and implementation was completed with minimal group friction and error. Group think was also kept to a minimum thanks to the open natured group environment.
Using current technologies and current information was vital to the simplicity of our design and allowed group members to spend time creating and improving as opposed to debugging.
| ID | Activity | Date | Description | Deliverables | Duration | People |
| 1 | Assign Tasks |
3/31/2009 |
Develop a preliminary design, Divide into groups to handle certain tasks |
1 |
||
| 1.1 | Hardware | PIC ??, LM 34 |
1 |
Mike McCarty, Ray Olsson | ||
| 1.2 | Software | LabView, C#, .NET |
1 |
Drew Delheimer, Josue Salazar | ||
| 1.3 | Documentation | WBS, Costs, PowerPoint | Lab Reports |
1 |
Freyja Harris, Duc Tran | |
| 2 | Prototype |
4/7/2009 |
Ascertain Design, begin implementing the design, test the program that handles the PIC | |||
| 2.1 | Hardware | LM335, PIC12F675 | Circuit |
1 |
Mike McCarty, Ray Olsson | |
| 2.2 | Software | LabView, C# | Program |
1 |
Drew Delheimer, Josue Salazar | |
| 2.3 | Documentation | WBS, schematics, Lab Reports | Lab Reports |
1 |
Freyja Harris, Duc Tran | |
| 3 | Completing the Design |
4/14/2009 |
Complete the circuit, revise and finish the program to handle the PIC, test the design | Complete Circuit |
1 |
|
| 3.1 | Hardware | LM335, PIC12F675 | Circuit |
1 |
Mike McCarty, Ray Olsson | |
| 3.2 | Software | C# | Program |
1 |
Drew Delheimer, Josue Salazar | |
| 3.3 | Documentation | WBS, Schematics, Lab Reports, Costs | WBS, Lab Reports |
1 |
Freyja Harris, Duc Tran | |
| 4 | Wrap up, Presentation |
4/21/2009 |
Test design once more, discuss the final Lab Report and PowerPoint presentation |
1 |
||
| 4.1 | Hardware | Documentation on LM 335 and PIC | Documentation |
1 |
Mike McCarty, Ray Olsson | |
| 4.2 | Software | Documentation on LabView and C# | Documentation |
1 |
Drew Delheimer, Josue Salazar | |
| 4.3 | Documentation | Lab Report and PowerPoint Presentation | Lab Report and PowerPoint |
1 |
Freyja Harris, Duc Tran | |
| 5 | Presentation |
4/28/2009 |
During the presentation, everyone will discuss their contribution to the project | Presentation |
1 |
Evereyone |
Table 1WBS
Our initial design was to use a PIC to receive the analog input from the LM34. The PIC would then handle the analog to digital conversion, as well the UART process. Depending on the PIC we choose to use, we could have had software or hardware UART. We would then use software to convert the data from the UART to RS-232. Finally, the data would be displayed on the computer using some sort of graphical representation. Figure 1 below illustrates this concept. This design would reflect on our realized design as it much resembles in function and components.










Figure 1Preliminary Design
Our design rests on the capabilities of the PIC 12F675. The PIC averages 100 analog readings of the LM335 and converts this data to a string representation of a floating point number and sends it via the UART process. The PC would then receives and manipulates the 8 bit data so it can be displayed using LabView. The temperature that is displayed is accurate to within 2 degree Celsius and will display a temperature range from 0 to 130 degrees Fahrenheit. Figure 2 depicts the circuit (not connected to PC).

Figure 2 Circuit Design
The LM335Z is a low cost precision integrated circuit temperature sensor that operates from –40 to 100 degrees Celsius. It has an input impedance of less than 1 ohm and operates over a current range from 400 micro amps to 5 milliamps with minimal changes in the devices in circuit performance. The package type is the TO-92 plastic package.
The LM335 operates as a 2-terminal Zener diode with the breakdown voltage level directly proportional to an absolute temperature at +10 mV per degree Kelvin and must be reversed biased in order for it to generate a temperature dependent analog output voltage. The sensor does not require load impedance, but does require a current limiting source resistor to place the device in the proper operating mode. The adjustment input of the LM335 can be used to calibrate the temperature sensor for higher degrees of accuracy. This is accomplished by connecting a potentiometer across the LM335 with the center tap connected to the adjustment input terminal of the temperature sensor.
The calibration is then performed so that the analog output voltage of the sensor as measured between the + output terminal of the sensor and ground corresponds to the ambient temperature of the room. Using the formula Ta in degrees, the temperature conversion to degrees Fahrenheit can be made by multiplying the degrees Celsius by 9/5 and adding 32. Since the LM335 temperature sensor operates on a linear scale, errors in the sensors output voltage are only scale factor errors. This means that the slope calibration at one temperature corrects for errors at all temperatures. Figure 3 illustrates this notion. The accuracy of the sensor Celsius is to within 2 degree Celsius when operated within the specified current range, which provides for sufficient current to drive the sensor, potentiometer, and the load.

Figure 3 Accuracy Calibration
In order for the sensor to be utilized in a variety of environmental conditions a 10-µF decoupling capacitor was added between the voltage source and ground. This provides isolation from potential switching transients that could propagate into the temperature sensors circuit. A filter capacitor of 0.1-µF Ceramic was also placed between the output from the LM335Z and ground to minimize the effects of noise.
We have chosen the PIC 12F675 to handle this project because it was the smallest and cheapest PIC available that fits this project. The PIC consists of 5 analog inputs and 1024 ROM words. One of the tradeoffs for using this PIC was a lack of hardware UART to transmit the data. In order to solve this, we resorted to using software UART.
This PIC has very little ROM program memory, thus many initial programs did not work because they used too much ROM memory. However, after several tries we were able to take 100 measurements and average them, then output them. This used up 95% of the PIC’s ROM.
“ROM used: 969 (95%), 969 (95%) including unused fragments” – compiler output
Figure 4 is a simple diagram of the PIC circuit:
Figure 4 PIC Pin out
An alternate design we could have chosen was to use a PIC 12F629. The PIC 12F629 is very similar to the PIC 12F675 except that the former holds twice as much memory (2048 ROM words). However, we did not have to resort to this design since the PIC 12F675 had sufficient memory for our project code.
Software UART was our only option in this project, given the PIC we used. Software UART uses time driven hardware interrupts to send data at set time intervals. We decided to use 9600/N/8 as the settings because that is the default settings for most applications. We transmit our bits for seconds, or 104 µseconds. Every 104 µseconds the next bit in the data to be transmitted must be moved to the transmit pin. Since changing a pin from low to high just takes a second, in between changing the transmit (tx) pin we will be processing our other functions.
For instance if we were going to transmit “0011001″:

Figure 5 PIC Process Timeline
In the conversion from UART to RS-232 the ‘0′ bit is inverted and the ‘1′ bit is given a negative voltage. Figure 6 is a diagram to illustrate the two.

Figure 6 UART and RS-232
In order to convert from UART to RS-232 for a logic 0 it is enough to invert the TTL/CMOS output. This method would mean that 0v would become 5v which is a logic 0 in RS-232. There is no way for us to generate negative voltages from the PIC, so for the RS-232 equivalent of a ‘1′ we will need to generate a voltage less than -3v, this can only be done by using a transistor and a resistor. Figure 7 below illustrates this concept.
Figure 7 Transistor Conversion
•Note: All of this works because we are not going long distances; if we were going to have cable from one room to another then this method might not work. This method is not recommended for cables longer than 10 feet. An alternate power supply with ± 12v or a MAX-232 chip would be advised for transmitting on a longer cable.
In order to receive and manipulate the data coming from the PIC microcontroller, our team had the opportunity to create two programs in different programming languages. One of them was done with the graphical programming environment LabView and the second program was done with C#.
The block diagram in Figure 8 graphically presents the inputs and outputs of the receiver (in our case, the PC). The flow of data begins with the PC receiving a floating point number composed of eight characters. One character represents a whole digit, one the period (.) , and the other six are decimal digits. The COM port of the PC will receive the 8 characters and software code will extract them from the selected port. After that the programmed code manipulates the data converting it into Celsius and Fahrenheit units. This information is then displayed by the software as an output. The LM335 output represents the actual floating point number received from the PIC microcontroller.

Figure 8 Receiver Block Diagram
LabView provides a virtual instrument called “Visa Configure Serial Port” which lets you open the COM port and use it with the desired a configuration. The signal configuration was hard coded on the PIC with a baud rate of 9600 bps, 8 data bits, no parity, one stop bit, and no flow control. So to allow the receiver to understand the received signal we need to replicate this configuration on the “Visa Configure Serial Port.” The block diagram in Figure 9 shows how this VI (virtual instrument) is configured.
From left to right the next component following the “Visa Configure Serial Port” is a Loop which first contains a “Visa Read” virtual instrument. This VI is the component that actually polls the COM port and waits for the eight characters every time the loop is executed. The output of this VI is a string containing the eight character floating point number. This string is then transformed into a Double by another virtual instrument called “Fract/Exp String to Number.” After this, the Double number is manipulated in order to convert it into degrees Celsius and Fahrenheit. Then the appropriate conversions are displayed in number and graphically using the “Thermometer Numeric Indicator.” On Figure 10 you can see the software user interface.

Figure 9 LavView Block Diagram

Figure 10 LabView Front Panel
Since LabView is a graphical programming language, it is easier to understand the data flow and transformations. This means that one can visually track how the data moves through the different virtual instruments (which represent functions) until the output is displayed.
Another advantage of using LabView is that it is easy to integrate dynamic graphical indicators for the output data.
Table 2 below shows the cost of the hardware and labor involved within this project.
| Hardware Components |
|
|
|
|
|
|
Cost |
| LM335Z |
|
|
|
|
|
|
$0.66 |
| PIC 12F675 |
$1.22 |
||||||
| DB9 Connector |
$1.33 |
||||||
| Resistors(470Ω , 1kΩ, 10kΩ ) |
$1.50 |
||||||
| Transistor(2N3906) |
$0.10 |
||||||
| Capacitors(10µF, 22pF) |
$1 |
||||||
| Breadboard(solder, solderless) |
$11 |
||||||
| Wiring |
$3 |
||||||
| 20 MHZ Clock |
$0.52 |
||||||
| Total |
|
|
|
|
|
|
$16.33 |
| Employment Hours |
|
|
|
|
|
|
|
| People |
|
# of hours |
|
Salary Cost |
|
|
Total |
| .. |
10 |
$20 |
$200 |
||||
| .. |
10 |
$20 |
$200 |
||||
| .. |
10 |
$20 |
$200 |
||||
| .. |
10 |
$20 |
$200 |
||||
| .. |
10 |
$20 |
$200 |
||||
| .. |
|
10 |
|
$20 |
|
|
$200 |
| Total |
|
60 |
|
$20 |
|
|
$1,200 |
|
|
|
|
|
|
|
|
|
| Total Cost |
|
|
|
|
|
|
$1,216.33 |
Table 2 Cost Analysis
We were able to reach our goals of implementing a simple, functional, and cost effective design of a telemetering module. The capabilities of a PIC microcontroller in combination with the flexibility of software make this temperature gauge system consistent and successful. It was due to everyone’s contributions that made this project quick and unproblematic. Further documentation can be found within the Appendices.
Figure 3 Accuracy Calibration 6
Figure 5 PIC Process Timeline 8
Figure 7 Transistor Conversion 8
Figure 8 Receiver Block Diagram 9
Figure 9 LavView Block Diagram 10
Figure 10 LabView Front Panel 10
Figure 11 Picture of Circuit 16
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 | #include <12F675.h> #device adc=8 #use delay(clock=20000000) #fuses NOWDT,HS, NOCPD, NOPROTECT, MCLR, NOPUT, BROWNOUT #use rs232(baud=9600,parity=N,xmit=PIN_A2,bits=8) #include "12f675test.h" #include <float.h> //#include <math.h> #include <stdio.h> //#include <string.h> // adc variables int i =0; int adc_value; float volts; //float diff = 30.4; // scale it down ? int32 total = 0; //float temp = 0; // chop off the .xx void main() { setup_adc_ports(sAN0|VSS_VDD); setup_adc(ADC_CLOCK_DIV_8); set_adc_channel(0); setup_timer_0(RTCC_INTERNAL|RTCC_DIV_1); setup_timer_1(T1_DISABLED); setup_comparator(NC_NC_NC_NC); setup_vref(FALSE); while(1){ //temp=0; total = 0; for (i=0; i<100; i++) { adc_value = read_adc(); total = total + adc_value; //printf("\n\r %d : %U",i,total); delay_us(1000); } volts = (float)((total/100)*5)/255; delay_ms(500); printf("%f",volts); } } |

Categories
Tag Cloud
Blog RSS
Comments RSS

Void « Default
Life
Earth
Wind
Water
Fire
Light 