EE 682
Midterm Project Report:
Wireless Sensor Module
Team Blimpyk:
Jason Alber
Joey Cheng
Nathan Eggan
Barry Hubbard
Tom Metcalf
Peter Shempp
2/25/2002
Prof. Steven Bibyk
i
TABLE OF CONTENTS
TABLE OF CONTENTS ............................................................................................................................ II
LIST OF FIGURES .................................................................................................................................... III
LIST OF TABLES ...................................................................................................................................... III
ABOUT THE AUTHORS .......................................................................................................................... IV
1.
INTRODUCTION............................................................................................................................... 7
1.1 MOTIVATION FOR THIS REPORT, AND OUTLINE OF CONTENT ................................................................. 7
2.
INDIVIDUAL COMPONENTS/SYSTEMS ..................................................................................... 8
2.1
2.2
2.2.1
2.2.2
2.3
2.4
2.4.1
2.4.2
2.4.3
2.5
2.5.1
2.5.2
MICROCONTROLLER (MCU), AND ITS DEVELOPMENT ENVIRONMENT......................................... 8
SENSORS ...................................................................................................................................... 9
LM34 temperature sensor ....................................................................................................... 9
NPC-410 Pressure Sensor .....................................................................................................11
USER INTERFACE.........................................................................................................................13
SERIAL COMMUNICATIONS (NOT FOR PROGRAMMING THE PIC) ................................................14
MAX233 Serial Driver ...........................................................................................................14
Wireless Communication .......................................................................................................15
Data Packet ...........................................................................................................................17
POWER ........................................................................................................................................18
Power Supply .........................................................................................................................18
Voltage Regulation ................................................................................................................18
APPENDIX ..................................................................................................................................................20
1.
DOWNLOADED SAMPLE MCU CODE .......................................................................................21
1.1
1.2
2.
TEAM BLIMPYK’S MCU PROJECT CODE (NOTE: ONLY MAJOR FILES SHOWN.).....22
2.1
2.2
3.
Sample A/D Code from http://www.workingtechnologies.com/htpic/ ....................................21
Sample Serial Code from http://www.workingtechnologies.com/htpic/.................................22
main.c ....................................................................................................................................22
serial.c ...................................................................................................................................24
TEAM BLIMPYK'S USER INTERFACE CODE ..........................................................................28
3.1
3.2
Code to Set-up and Open Serial Port ....................................................................................28
Code to Process MSComm Events .........................................................................................29
ii
LIST OF FIGURES
FIGURE 2.1.1 – PIC INITIAL WIRING ................................................................................................................ 8
FIGURE 2.2.1.1 – DIAGRAM SHOWING THE WIRING OF THE LM34 TO THE PIC ...............................................10
FIGURE 2.2.2.1 – DIAGRAM SHOWING THE WIRING OF THE NPT-410 TO THE PIC ..........................................12
FIGURE 2.4.1 - TEAM BLIMPYK'S USER INTERFACE ........................................................................................14
FIGURE 2.3.1 – DIAGRAM SHOWING THE WIRING OF THE MAX233 TO THE PIC .............................................15
FIGURE 2.4.2.1 - TEAM BLIMPYK'S DATA PACKET .........................................................................................17
FIGURE 2.5.1.1 – THE SOLAR CELL .................................................................................................................18
LIST OF TABLES
TABLE 2.2.1.1 – PIC CODE FOR TEMPERATURE SAMPLING .............................................................................10
TABLE 2.2.2.1 – PIC CODE FOR PRESSURE SAMPLING ....................................................................................12
iii
ABOUT THE AUTHORS
Team Blimpyk
Jason Alber – …………….……………………………………………...alber.4@osu.edu
Jason is a senior at The Ohio State University, College of Engineering,
Department of Electrical Engineering. He is a full-time student, working towards a BS in
Electrical and Computer Engineering.
Jason investigated possible alternatives to implementing GPS and the hardware
side of the user interface. He also is working with GPS in the hopes of creating a
feedback controls system to make the blimp autonomously fly a predisposed track.
Joey Cheng --……………………………………………………….. cheng.182@osu.edu
Joey is a senior at The Ohio State University, College of Engineering, Department
of Electrical Engineering. He is a full-time student and expects to graduate in Spring
Quarter, 2002.
Joey is responsible for power management. He will also be working with Jason
on GPS.
Nathan Eggan -- ……………………………………………………..... eggan.2@osu.edu
Nathan is a 5th year senior at Ohio State completing his BS in Electrical Computer
Engineering. After graduation this coming June (2002), he plans on embarking on an
engineering career in either the aerospace or communications field.
iv
Nathan has been responsible for the majority of the work associated with the PIC
MCU, the sensors, and the corresponding C code needed to the drive the two.
Barry Hubbard --…………………………………………………. hubbard.60@osu.edu
Barry is a 5th year senior and The Ohio State University majoring in Electrical and
Computer Engineering. He is actively involved with the FIRST robotics team and has
been a Teaching Assistant for the Freshman Engineering Honors program and robot
competition for the last 4 years.
Barry did much of the research and compiled the information for the wireless
communications link that is onboard the Blimpyk wireless sensor module. Barry also
wrote the introductory and concluding comments.
Tom Metcalf --………………….……………………………………metcalf.26@osu.edu
Tom is currently a senior at The Ohio State University, College of Engineering,
Department of Electrical Engineering. Tom is a full-time student majoring in Electrical
and Computer Engineering and will graduate at the end of Spring Quarter 2002. Tom is
also working under the guidance of Dr. Ali Keyhani on an undergraduate thesis in
Software Engineering.
Tom has been responsible for researching both Video hardware and the software
side of the User Interface.
Peter Shempp--……………………………………………………... shempp.1@osu.edu
Peter Shempp is a fifth year senior, who plans to graduate in the spring. He
spends most of his time working at his two jobs and hanging out with his friends. Peter is
interested in working in technical sales or consulting. He would like to live in New York
v
City, and plans to move there after graduation.
Peter is helping with the Graphical User Interface and the proximity sensor and is
working on the class web page.
vi
1. INTRODUCTION
1.1 Motivation for this report, and outline of content
The purpose of this report is to offer our constituents a follow-up discussion of the
progress Team Blimpyk is making on our design and implementation of the wireless
sensor platform. To keep this follow-up short, we will assume a relative understanding of
our complete project report that was completed and submitted at the end of last quarter.
This document then, can serve as an update to that report by describing the changes that
we have had to make along the way, and as a progress report by describing what we have
completed thus far.
With this goal in mind, we have chosen to use a very procedure-oriented structure
for this report. We plan to address each of the separate sections of this document less
from a perspective of what or why, and more from a perspective of how. Hopefully this
will provide our constituents with a great understanding of what we have done and are
doing, and how we have been able to do it.
7
2. INDIVIDUAL COMPONENTS/SYSTEMS
2.1
Microcontroller (MCU), and its Development Environment
As stated in our design report from last quarter, Team Blimpyk chose to utilize
the Microchip PIC16F877 microcontroller. Following the procurement of this device,
our first task was to connect the PIC to our breadboard and wire it appropriately so that
we could communicate with it through its in-circuit debugger (ICD) using the serial port
of our development computer. Once this communication link was established, we would
be able to begin the development process.
To do this, we first connected the PIC to our breadboard, along with its external
4MHz clock, and wired it up as seen in Figure 2.1.1.
Figure 2.1.1 – PIC initial wiring
Next, we installed Microchip’s MPLAB software development tool on our developing
machine. This software gave us an environment for developing code that would be used
8
to program the PIC, and provided us with the serial interface to the ICD that established
communication with the PIC itself. After a minimal amount of debugging, this circuit
was complete and operational.
While the provided MPLAB software gives a nice user interface for development
using the PIC’s assembly code, Team Blimpyk chose to follow the recommendations of
our faculty instructor, Dr. Steven Bibyk, and try to implement our designs using a
compiler that complied C code to executable PIC code.
Though there are many
compilers that do this on the market today, the one available to us was the HI-TECH PIC
C compiler. Fortunately, this compiler cleanly integrates into the MPLAB development
environment.
To do this integration, we used a tutorial found at PICWEB
(http://www.workingtechnologies.com/htpic/Hi-Tech_C_tutorial.htm.)
(For
more
information on PICWEB, please see the appendix.) After completing the tutorial, we
tested our new development system by downloading a sample C code file from the same
site, compiling it, and programming it into the PIC microcontroller. With this task
complete, our MCU and its development environment were in place.
2.2
Sensors
Once communication was established between the PIC and our development
computer, we were ready to begin connecting the desired sensors to PIC. As stated in the
design report from last quarter, we planned on attaching a temperature sensor and a
pressure sensor to our system.
2.2.1 LM34 temperature sensor
The first sensor we interfaced to our PIC MCU was the LM34 temperature sensor.
9
This device has a simple one-line, analog signal output of 10mV/°F. The interfacing of
this device is shown in Figure 2.2.1.1.
Figure 2.2.1.1 – Diagram showing the wiring of the LM34 to the PIC
Reading data from this sensor became much easier thanks to the ability to use C
code rather than assembly code to power the A/D converters. This task became even
easier when we again found very usable sample code from PICWEB. This sample code
gave us a set of simple function calls that could be used to initialize the PIC’s A/D
converters and to read data from them. (Note: This sample code can be found in the
index along with our complete project code.) This made reading the temperature sensor
and storing its result in a variable extremely simple. Please see Table 2.2.1.1 below.
Table 2.2.1.1 – PIC code for Temperature sampling
// re-initialize to Port RA0 & Vref=GND
InitialiseADC(0,0);
ReturnedTempData = ReadADC(0);
// Divide by 2 to get accurate readout
ReturnedTempData = (ReturnedTempData/2);
10
2.2.2 NPC-410 Pressure Sensor
While our design report requested the use of the Motorola MPX4115 pressure
sensor, the only one available to us was the Lucas NovaSensor NPC-410. These two
devices are very similar, and therefore we had little trouble adapting our designs to utilize
this new device.
The major difference between using the NPT-410 over the MPX4115 was the
connecting of it to the PIC. The MPX had pinout very much like that of the LM34, so we
expected to use the same interfacing techniques used in connecting the LM34 to the PIC.
The NPT has a few more pins, and rather than one output line (with ground as a reference
voltage), the NPT has two. The analog output voltage is taken across these two outputs.
To solve this connectivity problem, we finally settled on using one lead, the Outpin of the NPT, as the Vref+ to the PIC and the other, the Out+, as the actual analog line
data line for RA1 of the PIC. (Vref- on the PIC was tied to ground for this case.) This
meant that we would need to initialize the A/D converters each time we wanted to read
from a different A/D sensor because the two sensors did not share a common
configuration.
Figure 2.2.2.1 shows this configuration.
11
Figure 2.2.2.1 – Diagram showing the wiring of the NPT-410 to the PIC
As with the LM34, it was very easy for us to use the sample A/D code found at
PICWEB to read data from this device. Please see Table 2.2.1.1 below for a simple
code fragment showing this process.
Note, as mentioned before, that the A/D is
initialized differently due to the changes the converter must make to sample each device.
Again, the full project code and the sample codes downloaded from PICWEB can be
seen in the Appendix section of this report.
Table 2.2.2.1 – PIC code for Pressure sampling
// re-initialize to Port RA1 and Vref = RA2
InitialiseADC(1,1);
ReturnedPressure = ReadADC(1);
ReturnedPressure = (ReturnedPressure);
12
2.3 User Interface
Originally, Team Blimpyk had chosen to develop the user interface in the
LabView software, but due to the time required to learn LabView Team Blimpyk decided
to use Visual Basic 6.0 (VB6). Team Blimpyk was already familiar with VB6 and this
made development of the user interface very quick.
The core of Team Blimpyk's user interface is the MSComm component, an
ActiveX control that allows a VB6 executable to open, close, and set-up a serial port.
MSComm is a standard Microsoft component that can be included in any VB6 executable
and is modeled after the VB6 event driven model. That is, when a packet becomes
available on the serial port buffer, MSComm notifies the VB6 executable so that the
packet in the buffer can be processed.
Once Blimpyk's user interface is notified of a packet, the MSComm1_OnComm
procedure, see Appendix 3.1 and 3.2, first checks that the string "5A5A" was received. If
"5A5A" is not seen, the user interface assumes that it is not synchronized with the PIC
and an error warning is given to the user. Otherwise, if the user interface is synchronized
with the PIC, the data packet received is parsed, checked for errors, and if no errors are
found, the data is updated on the user interface.
Blimpyk's user interface displays sensor data graphically and numerically.
Graphically, data is represented on graphs and gauges. For example, Team Blimpyk
developed a thermometer to display temperature data. Numerically, each sensor has a
text box which displays the current sensor data. The Stop buttons in the Current
Temperature and Current Pressure boxes allow the user to freeze the data display to
capture an instance of the sensor data. The Quit button at the bottom of the user interface
13
quits the program. Currently, File, View, and Help menus are not functional.
Figure 2.4.1 - Team Blimpyk's User Interface
2.4
Serial Communications (NOT for programming the PIC)
As discussed in our design report from last quarter, it is of no use to be able to
collect various sensor readings into the PIC if there is no way to transfer that data to a
location where a user can use it. To solve this problem, we chose to implement a
standard RS-232 serial link between the PIC MCU and our bay station.
2.4.1 MAX233 Serial Driver
To create this interface, we used the TTL outputs of the PIC in combination with
a MAX233 serial driver chip. The MAX233 simply converts the TTL outputs to RS-232
outputs and forwards them on. Figure 2.3.1 shows this wiring configuration.
14
Figure 2.3.1 – Diagram showing the wiring of the MAX233 to the PIC
Unfortunately, this connection is not nearly as easy to implement in code as it is
to implement the A/D routines. Fortunately, PICWEB also had a working example of C
serial code for the PIC. This proved to be a huge resource for us. This code provided a
working main function and by simply loading the code into a new project in MPLAB,
compiling it, and running it, a quick serial demonstration was possible. This code was so
good, it formed the framework for our entire project. With some simple modifications, it
was exactly what we needed. (Due to the extensive nature of this sample code, it is not
included here. However, it can be seen in the Appendix as “serial.h” and “serial.c”.)
2.4.2 Wireless Communication
Team Blimpyk chose to use the AC5124 wireless transceiver, available from
Aerocomm (www.aerocomm.com), for the wireless component of the design. The
Aerocomm unit offers seamless serial integration at 9600 baud through the use of the
development kit’s serial interface board. It is important to note, however, that there are
two different models of the serial interface board available with the AC5124C
15
transceivers. Both serial interface boards offer similar features however the newer boards
contain a voltage regulation circuit. Because of this, the board requires a 6V input vs. a
5V input for the older board. Because the 5V source voltage requirement is compatable
with the power requirements for the rest of the wireless module, the Blimpyk team has
chosen to use the older style interface boards (recognized by a lack of LED’s on the face
of the board).
As of yet, Team Blimpyk has not seen a need to increase the bandwidth of the
Aerocomm board beyond the 9600 baud available by bypassing the EEPROM settings.
In order to “peg” the board at 9600 baud, it is necessary to tie pin 24 to logic low or
ground. Also, SW3, the slider switch located next to the power jack on the board must be
switched to the high position to enable communication. The newer style interface boards
can also be set to 9600 baud by selecting the slider switch located in the center of the
board.
The Aerocomm boards allow for both RS-232 and TTL serial transparent modes.
The board is set to RS-232 vs. TTL through the jumper pins located on the edge of the
board. For the sake of testing and to ease debugging issues, Team Blimpyk is using the
RS-232 interface option into the board. This method requires a MAX 232 serial driver to
be placed between the PIC USART output and the DB-9 input of the AC5124 but has
provided the team with a familiar and reliable interface. Because this interface requires
the conversion of line levels to RS-232 and back to TTL (through MAX 202 chips
onboard the serial interface board), team Blimpyk plans on moving to a completely TTL
interface on the blimp side of the module.
16
2.4.3 Data Packet
Team Blimpyk has chosen to use a data packet of 32 ASCII characters .
Currently, only 9 of these characters are used. The first and next to last characters of the
packet are the packet number which are encoded in ASCII values. Since only ASCII
values 33 through 255 are printable, Team Blimpyk can send 223 packets before starting
the packet count back at 33. The reason for beginning and ending the data packet with
the packet number is to help the user interface catch erroneous or lost packets. The
packet also contains three characters for temperature data and three characters for
pressure data. The last character is a null character, which is needed to send the packet as
a string.
Packet No.
Temperature
Data
Pressure Data
Packet No.
Null Character
Figure 2.4.2.1 - Team Blimpyk's Data Packet
17
2.5
Power
Power is one of the major concerns for Team Blimpyk in the design of the
wireless sensor module. The power system is responsible for getting the required voltage
to each of the sensors, the Aerocomm transceiver unit and other components installed on
the blimp. An input voltage of 5V is required for our design.
2.5.1
Power Supply
There are a few possible alternatives for power supply, which are batteries and
solar cell. One 9-Volt Li/MnO2 battery on the market is the Energizer L522. It delivers
1200 mAh at 900 ohms to 5.4 Volts/cell. The battery weights approximately 1.2oz. On
the other hand, the solar cell we have available can generate 10V output voltage and 2mA
output current. Higher current output could be achieved if we increase the light intensity.
Figure 2.5.1.1 – The solar cell
2.5.2 Voltage Regulation
There will need to be a step down the voltage as the components in the wireless
module won’t be able to operate directly off the batteries or the solar cell. Voltage
regulators will be needed. Team Blimpyk chooses to use a couple of Vortex
18
VC78053CT voltage regulators. The Vortex VC78053CT is sufficient enough to run
our power system, as it can regulate input voltages down to 5V output voltage.
19
APPENDIX
APPENDIX
1.
DOWNLOADED SAMPLE MCU CODE
1.1
1.2
2.
TEAM BLIMPYK’S MCU PROJECT CODE (NOTE: ONLY MAJOR FILES SHOWN.)
2.1
2.2
3.
SAMPLE A/D CODE FROM HTTP://WWW.WORKINGTECHNOLOGIES.COM/HTPIC/
SAMPLE SERIAL CODE FROM HTTP://WWW.WORKINGTECHNOLOGIES.COM/HTPIC/
MAIN.C
SERIAL.C
TEAM BLIMPYK'S USER INTERFACE CODE
3.1
3.2
CODE TO SET-UP AND OPEN SERIAL PORT
CODE TO PROCESS MSCOMM EVENTS
20
1.
Downloaded Sample MCU Code
1.1 Sample A/D Code from http://www.workingtechnologies.com/htpic/
adc.c
/*
*
Header file for the ADC unit - designed for PIC16F876/7
* BE CAREFUL WITH ADCON1 - IT HAS TO BE MANUALLY ADJUSTED FOR YOUR HARDWARE
* IN THE InitialiseADC ROUTINE.
*/
/*
Freely distributable in this original form.
(c) Feb 2000 Shane Tolmie
(c) KeyGhost, now you can record keystrokes on PC with tiny device
Any questions or comments? shane@keyghost.com
Updates to FAQ available from http://www.keyghost.com/htpic
*/
/*
sample C code
InitialiseADC(--Channel--);
blah = ReadADC(--Channel--);
*/
#include
#include
<pic.h>
"control.h"
//
Pic CPU header file
/*--------------------------------------------------------------Initialising the ADC channels
---------------------------------------------------------------*/
void InitialiseADC (unsigned char ADC_Channel) {
if
(ADC_Channel == 0)
TRISA0 = INPUT;
else if (ADC_Channel == 1)
TRISA1 = INPUT;
else if (ADC_Channel == 2)
TRISA2 = INPUT;
else if (ADC_Channel == 3)
TRISA3 = INPUT;
/*
-----Specify all to be analogue inputs, refered to VDD.
Please refer to Page 118 from PIC manual for other configurations.
------ */
/* Analogue-RA0/RA1/RA3 Digital-RA2/RA5
ADCON1 = 0b10000100;
*/
}
/*--------------------------------------------------------------Reads the ADC level input on a specified ADC channel.
Takes in an 10-bit ADC channel number.
Returns an 10 bit number that signifies this level.
Approximate sampling time = 76.8us
---------------------------------------------------------------*/
unsigned int ReadADC(unsigned char ADC_Channel){
volatile unsigned int ADC_VALUE;
/* Selecting ADC channel */
ADCON0 =
(ADC_Channel << 3) + 1;
ADIE
ADIF
ADRESL
ADRESH
ADGO
=
=
=
=
=
0;
0;
0;
0;
1;
/* Enable ADC, Fosc/2 */
/* Masking the interrupt */
/* Resetting the ADC interupt bit */
/* Resetting the ADRES value register */
/* Staring the ADC process */
21
while(!ADIF) continue; /* Wait for conversion complete */
ADC_VALUE
=
ADRESL;
/* Getting HSB of CCP1 */
ADC_VALUE
+=
(ADRESH << 8); /* Getting LSB of CCP1 */
return (ADC_VALUE);
/* Return the value of the ADC process */
}
1.2 Sample Serial Code from http://www.workingtechnologies.com/htpic/
Please just see our project code. Since the code for this section is several pages
long, we felt displaying it here would not be necessary. The entire sample project
including all of the code, etc., can be downloaded from:
http://www.workingtechnologies.com/htpic/Hi-Tech_C_sample_code.htm#serial
2.
Team Blimpyk’s MCU Project Code (Note:
Only major files shown.)
2.1 main.c
#define PIC_CLK 4000000 //change this to 3.6864, 4, 16 or 20MHz
//this affects mainser.c, for USART speed, and delay.h for delays
/*
Serial port tester
Designed by Shane Tolmie Jun 1999 to May 2001
Microprocessor:
Microchip PIC16F87x
Compiled with:
Hitech-C v7.87, MPLAB v5.30.00
Emulated with:
MPLAB ICE 2000 or ICD
Documentation:
all references are to PIC16F87x PDF version of Microchip manual
Overall goal:
serial port tester @ 19200 baud
Notes: to save memory, you have to comment out a function or else it will be included
even if its never called
*/
//*****
//include header files
#include
<pic.h>
#include
<conio.h>
#include
<stdlib.h>
#include
<stdio.h>
#include
<ctype.h>
#include
<string.h>
#include
"always.h"
#include
"delay.h"
#include
"error.h"
#include
"maths.h"
//****************
//global variables
unsigned int ReturnedTempData;
// Nate (2/7/02)
unsigned int ReturnedPressure;
// Nate (2/13/02)
//****************
//*****
//include C files
#include
"delay.c"
#include
"serial.h"
#include
"serial.c"
//#include
"lowlevel.c"
#include
"error.c"
#include
"maths.c"
#include
"eeprom.c"
#include
"eep_init.c"
#include
"adc.h" // Nate (2/7/02)
#if defined(_16F876) || defined(_16F877) || defined(_16F873) || defined(_16F874) ||
defined(_16C76)
__CONFIG(UNPROTECT|BODEN|FOSC1|BKBUG|WRT);
#else
22
#error Must be compiled for 16F87x, MPLAB-ICD or 16C76
#endif
/*--------------------------------------------------------------Initialising the ADC channels
---------------------------------------------------------------*/
void InitialiseADC (unsigned char ADC_Channel, unsigned char Vref)
{
if (ADC_Channel == 0)
TRISA0 = INPUT;
else if (ADC_Channel == 1)
TRISA1 = INPUT;
else if (ADC_Channel == 2)
TRISA2 = INPUT;
else if (ADC_Channel == 3)
TRISA3 = INPUT;
/*
-----Specify all to be analogue inputs, refered to VDD.
Please refer to Page 118 from PIC manual for other configurations.
------ */
/* Analogue-RA0/RA1/RA3 Digital-RA2/RA5
*/
if (Vref == 1)
ADCON1 = 0b10001000;
else
ADCON1 = 0b10000100;
// Add delay here?
}
/*--------------------------------------------------------------Reads the ADC level input on a specified ADC channel.
Takes in an 10-bit ADC channel number.
Returns an 10 bit number that signifies this level.
Approximate sampling time = 76.8us
---------------------------------------------------------------*/
unsigned int ReadADC(unsigned char ADC_Channel)
{
volatile unsigned int ADC_VALUE;
/* Selecting ADC channel */
ADCON0 =
(ADC_Channel << 3) + 1;
/* Enable ADC, Fosc/2 */
ADIE
=0;
/* Masking the interrupt */
ADIF
=0;
/* Resetting the ADC interupt bit */
ADRESL=0;
/* Resetting the ADRES value register */
ADRESH=0;
ADGO
=1;
/* Staring the ADC process */
while(!ADIF) continue;
/* Wait for conversion complete */
ADC_VALUE = ADRESL;
/* Getting HSB of CCP1 */
ADC_VALUE += (ADRESH << 8);
/* Getting LSB of CCP1 */
return (ADC_VALUE);
/* Return the value of the ADC process */
}
/*--------------------------------------------------------------MAIN function
---------------------------------------------------------------*/
void main(void)
{
unsigned char getch_timeout_temp,pass;
unsigned int x=0;
unsigned int temp=0;
unsigned int i=0;
unsigned char c=0;
unsigned int PacketNum = 33;
char packet[32];
char StringTempData[4];
char StringPressureData[4];
OPTION=0xFF;
CLRWDT();
serial_setup();
//could use printf() here but putst saves 1k of rom space
c=0;
//Syncronization bits
23
putst("5A5A");
for(;;)
{
getch_timeout_temp=getch_timeout();
if (getch_timeout_temp==0)
{
InitialiseADC(1,1);
// re-initialize to Port RA1 and Vref
= RA2
ReturnedPressure = ReadADC(1);
ReturnedPressure = (ReturnedPressure);
InitialiseADC(0,0);
// re-initialize to Port RA0 and Vref
= GND
ReturnedTempData = ReadADC(0);
ReturnedTempData = (ReturnedTempData/2);
if (ReturnedTempData >= 1000)
ReturnedTempData = ReturnedTempData % 1000;
packet[0] = PacketNum;
//packet[1] = ',';
// convert temp data to string
packet[3] = ReturnedTempData % 10 + '0';
ReturnedTempData /= 10;
packet[2] = ReturnedTempData % 10 + '0';
ReturnedTempData /= 10;
packet[1] = ReturnedTempData % 10 + '0';
//packet[5] = ',';
if (ReturnedPressure >= 1000)
ReturnedPressure = ReturnedPressure % 1000;
packet[6] = ReturnedPressure % 10 + '0';
ReturnedPressure /= 10;
packet[5] = ReturnedPressure % 10 + '0';
ReturnedPressure /= 10;
packet[4] = ReturnedPressure % 10 + '0';
//packet[9] = ',';
packet[7] = PacketNum;
packet[8] = '\0';
putst(packet);
// Commented this out. Was causing unexpected carriage return in
output - Tom 2/21/02
//c++;
//if (c>8)
//{
//
putst("c>8");
//
c=0;
//
putlf;
//}
PacketNum++;
if (PacketNum > 255)
{
PacketNum = 33;
}
}
else
{
putst("error"); // Trying to figure out what this is - Tom 2/21/02
putch(getch_timeout_temp+1);
putlf;
}
}
}
2.2 serial.c
/*
24
Interface PIC
Designed by Shane Tolmie Feb 2001.
Microprocessor: Microchip PIC16F87x
Compiled with: Hitech-C v7.87, developed using MPLAB v5.3
Note: all references are to PIC16C7X PDF version of Microchip manual, DS30390E
Overall goal: serial comms using USART to comm port of an ibm pc compatible computer
*/
#include
#include
#include
#include
#include
<pic.h>
<conio.h>
<stdio.h>
"always.h"
"delay.h"
void serial_setup(void)
{
/* relates crystal freq to baud rate - see above and PIC16F87x data sheet under
'USART async. modes'
BRGH=1, Fosc=3.6864MHz
--------------------Baud
SPBRG
1200
191
2400
95
4800
47
9600
23
19200 11
38400 5
57600 3
115200 1
BRGH=1, Fosc=4MHz
----------------Baud
SPBRG
1200
207.3
2400
103.2
4800
51.1
9600
25.0
19200 12.0
38400 5.5
57600 3.3
115200 1.2
BRGH=1, Fosc=8MHz BRGH=1, Fosc=16MHz
---------------------------------Baud
SPBRG
Baud
SPBRG
1200
415.7
9600
103
2400
207.3
19200
51
4800
103.2
38400
25
9600
51.1
57600
16
19200
25.0
115200
8
38400
12.0
57600
7.7
115200 3.3
*/
/*
* Comms setup:
*/
#define BAUD 9600
// super-important line!!!!!
#define DIVIDER ((PIC_CLK/(16UL * BAUD) -1))
#define HIGH_SPEED 1
//you can comment these #assert statements out if you dont want error checking
/*
#if PIC_CLK==3686400 && BAUD==19200
#assert DIVIDER==11
#elif PIC_CLK==4000000 && BAUD==19200
#assert DIVIDER==12
#elif PIC_CLK==16000000 && BAUD==19200
#assert DIVIDER==51
#elif PIC_CLK==20000000 && BAUD==19200
#assert DIVIDER==64
#endif
*/
SPBRG=DIVIDER;
BRGH=HIGH_SPEED;
SYNC=0;
SPEN=1;
CREN=1;
SREN=0;
TXIE=0;
RCIE=0;
TX9=0;
RX9=0;
TXEN=0;
TXEN=1;
//data rate for sending
//asynchronous
//enable serial port pins
//enable reception
//no effect
//disable tx interrupts
//disable rx interrupts
//8-bit transmission
//8-bit reception
//reset transmitter
//enable the transmitter
}
unsigned char dummy;
#define clear_usart_errors_inline
\
25
if (OERR)
\
{
\
TXEN=0;
\
TXEN=1;
\
CREN=0;
\
CREN=1;
\
}
\
if (FERR)
\
{
\
dummy=RCREG;
\
TXEN=0;
\
TXEN=1;
\
}
//writes a character to the serial port
void putch(unsigned char c)
{
while(!TXIF)
//set when register is empty
{
clear_usart_errors_inline;
CLRWDT();
}
TXREG=c;
DelayUs(60);
}
//gets a character from the serial port without timeout
unsigned char getch(void)
{
while(!RCIF)
{
CLRWDT();
clear_usart_errors_inline;
}
return RCREG;
}
unsigned char getch_timeout(void)
{
unsigned char i;
unsigned int timeout_int;
// retrieve one byte with a timeout
for (i=2;i!=0;i--)
{
timeout_int=timeout_int_us(240000);
while (hibyte(timeout_int)!=0) //only check the msb of the int for being
0, it saves space, see always.h for macro
{
CLRWDT();
timeout_int--;
if (RCIF)
{
return RCREG;
}
}
}
return 0;
26
}
void clear_usart_errors(void)
{
clear_usart_errors_inline;
}
/*
writes a character to the serial port in hex
if serial lines are disconnected, there are no errors
*/
void putchhex(unsigned char c)
{
unsigned char temp;
// transmits in hex
temp=c;
c=(c >> 4);
if (c<10) c+=48; else c+=55;
putch(c);
c=temp;
c=(c & 0x0F);
if (c<10) c+=48; else c+=55;
putch(c);
}
void putinthex(unsigned int c)
{
#define ramuint(x)
(x)))
#define ramuint_hibyte(x)
#define ramuint_lobyte(x)
#define ramuchar(x)
(x)))
(*((unsigned int *)
(*(((unsigned char *)&x)+1))
(*(((unsigned char *)&x)+0))
(*((unsigned char *)
putchhex(ramuint_hibyte(c));
putchhex(ramuint_lobyte(c));
#undef
#undef
#undef
#undef
ramuint(x)
ramuint_hibyte(x)
ramuint_lobyte(x)
ramuchar(x)
}
//if there has been a previous timeout error from getch_timeout, this returns TRUE
unsigned char usart_timeout(void)
{
//
return usart_timeout_error;
return FALSE;
}
/*
writes a character to the serial port in decimal
if serial lines are disconnected, there are no errors
*/
void putchdec(unsigned char c)
{
unsigned char temp;
temp=c;
//hundreds
if ((c/100)>0) putch((c/100)+'0');
c-=(c/100)*100;
27
//tens
if (((temp/10)>0) || ((temp/100)>0)) putch((c/10)+'0');
c-=(c/10)*10;
//ones
putch((c/1)+'0');
}
void putst(register const char *str)
{
while((*str)!=0)
{
putch(*str);
if (*str==13) putch(10);
if (*str==10) putch(13);
str++;
}
}
3.
Team Blimpyk's User Interface Code
3.1
Code to Set-up and Open Serial Port
Private Sub Form_Load()
TempCnt = 0
Sync = 1
debugcnt = 1
' Set-up serial port
With MSComm1
' Set serial port number
.CommPort = 1
.DTREnable = True
.Handshaking = comRTS
.InBufferSize = 1024
' Set number of bytes to grab from buffer when
' input is requested
.InputLen = 9
'
Set data in buffer to text
.InputMode = comInputModeText
.NullDiscard = False
.OutBufferSize = 1024
.ParityReplace = "?"
.RThreshold = 1
.RTSEnable = True
' Set baud rate, flow control, data bits, and stop bit
.Settings = "9600, n, 8, 1"
' Set number of bytes in buffer before MSComm should fire
' packet received event
.SThreshold = 9
End With
28
' Open serial port
MSComm1.PortOpen = True
:
:
:
End Sub
3.2
Code to Process MSComm Events
Private Sub MSComm1_OnComm()
Dim InBuff As String
Dim pos1 As Integer
Dim RawTemperature As String
Dim RawPressure As String
Dim Temperature As String
Dim Pressure As String
Dim Remainder As String
Dim PacketNum As String
' If MSComm sends comEvReceive then there is a packet in the buffer
' to read
If MSComm1.CommEvent = comEvReceive Then
' Check that the program sees the beginning of the stream
' in order to syncronize the PIC and the program
If Sync Then
If MSComm1.Input = "5A5A" Then
Sync = 0
End If
ElseIf Sync = 0 Then
' Read in packet from buffer
InBuff = MSComm1.Input
' Parse packet for sensor data
PacketNum = Left(InBuff, 1)
Remainder = Right(InBuff, 7)
RawTemperature = Left(Remainder, 3)
Remainder = Right(InBuff, 4)
RawPressure = Left(Remainder, 3)
Remainder = Right(InBuff, 1)
If Left(RawTemperature, 2) = "00" Then
Temperature = Right(RawTemperature, 1)
ElseIf Left(RawTemperature, 1) = "0" Then
Temperature = Right(RawTemperature, 2)
End If
If Left(RawPressure, 2) = "00" Then
Pressure = Right(RawPressure, 1)
ElseIf Left(RawPressure, 1) = "0" Then
Pressure = Right(RawPressure, 2)
End If
' If the user has the temperature display on the user
' interface enabled, then display new data
If goTemperature Then
txtTemperature.Text = Temperature & " °F"
shpTemperature.Top = (100 - CInt(Temperature)) * Increment
data1 = Temperature
End If
' If the user has the pressure display on the user
29
' interface enabled, then display new data
If goPressure Then
txtPressure.Text = Pressure & " PSI"
shpPressure.Top = (100 - CInt(Pressure)) * Increment
data2 = Pressure
End If
End If
End If
End Sub
30