|
|
|
&n=
bsp; |
&n=
bsp; |
App Note 206: Using a PC's RS-232 Serial
Port To Communicate with 2-Wire Devices
Introduction Overview This application not=
e has
been written to aid customers who would like to build their own circuit to
facilitate communications between a PC and 2-wire devices, and to show th=
em
how to generate their own custom software specific to their application. =
It
is broken up into four sections that concentrate on hardware design,
firmware, software, and a final section that provides a step-by-step
walk-through showing how to build the reference design, program the PIC, =
and
begin writing custom software for a 2-wire application. Designing
Hardware to Interface a PC to a 2-Wire Device There are a lot of w=
ays to
transmit data from a PC to external hardware, so why is the serial port
preferred for many applications? First, serial ports are available on eve=
ry
PC, and accessing the port has been clearly defined by the RS232 standard.
Additionally, both PCs and microprocessors contain serial ports, so
communication with a microprocessor is very simple to establish. Three ot=
her
notable advantages of this standardization are the PC will send the data =
out
at the same baud rate regardless of its processing power, the serial port=
is
generally free on most PCs, and software written for serial ports tends to
work across all Windows™ operating system platforms. It is also
possible to parasitically power some adapters by stealing power from the =
I/O
signals of the serial port; however, this is not possible for the referen=
ce
design because it draws too much power. This is primarily a result of the
fact the design operates at a relatively high frequency (3.6864MHz), which
increases the power requirements beyond what can be parasitically powered=
. The major disadvanta=
ge of
choosing the serial port is it will definitely require a microprocessor to
translate the RS232 data format to the 2-wire protocol, where it is possi=
ble
with some other I/O devices to perform the task without the addition of a
microprocessor. Additionally, the serial port uses ±12V signals for
communications. This will require an IC to translate the signal levels to
levels a microprocessor can handle. Although it is possible to operate at
data rates >115.2kbps, both the PC and the microprocessor need to have=
the
ability to operate at the chosen speed. Generally PCs are able to support=
all
standard baud rates, but the microprocessor may present some limitations =
with
respect to the speed it can send and receive data. There are other opti=
ons
for building PC hardware. The two most common other than the serial port =
are
using the parallel port or a general-purpose input/output card (GPIO). Bo=
th
of these options have problems that must be handled to successfully use t=
hem.
The parallel port is not as standard as the serial port. There have been =
four
standards for the parallel port over the course of time, and there are a
variety of chipsets that operate the port in different modes. The original
standard parallel port (SPP) was the first standard and is supported by m=
ost
all PCs. The problem is the SPP mode of the port may have to be enabled in
the BIOS of the computer running the application. Additionally, timing is=
difficult
to handle on the parallel port since it depends heavily on the speed of t=
he
computer being used. GPIO cards are not
standard equipment on PCs, so they must be purchased separately and insta=
lled
after the PC is purchased. Additionally, there is not a GPIO card standar=
d,
so it is impossible to ensure the software written for one card will work
with multiple systems. Another option that =
has
become popular is USB. The primary advantages of USB are the ability to
parasitically power larger circuits, and the bandwidth of the connection.=
The
disadvantages are the circuit would have to operate from the system volta=
ge
of 5V, and the firmware and software become much more complex since they =
now
must be able to communicate using device drivers. Since the serial por=
t is
being used for communication to 2-wire devices in the reference design, t=
hree
main things need to be addressed to allow communication between the PC and
the microprocessor.
Because
serial ports use ±12V signals for communication, they cannot be
interfaced directly to a microprocessor. Fortunately, both Dallas
Semiconductor and Maxim make several RS232 level converter chips to trans=
late
the ±12V signals to 0 to 5V or 0 to 3V signals. The easiest to use
that are 100% RS232 specification compliant are the DS232A, the MAX3221, =
and
the MAX3223. The DS232A is a 5V part, and converts RS232 signal levels to=
0
to 5V signals, the two Maxim chips work from 3V to 5.5V and have either o=
ne
(MAX3221) or two (MAX3223) serial channels. All support baud rates up to
120kbps. UARTs
are used to maintain the timing of the communication while sending and
receiving data. Many, but not all, microprocessors contain an RS232-compl=
iant
hardware UART. In addition to handling the timing, a hardware UART handles
the serialization of the data from bytes to a bit stream, and it
sends/receives the start and stop control bits without software intervent=
ion.
All of the above mentioned can be handled by a software UART, but it
generally must be at slower baud rates, and it can take a significant por=
tion
of the microprocessor's time to handle just the serial port communication.
Conventional wisdom states it is generally better to buy the microprocess=
or
with hardware UART. It allows efficient interrupt driven code to control =
the
serial port peripheral, it tends to be more reliable, and the cost increa=
se
is generally minor due to the fact RS232 ports are very commonplace. One
important thing to consider when using a hardware UART is to use either u=
se
an oscillator or crystal with a frequency that will work with the
microprocessor's baud rate generator. Baud rate generators generally use =
the
clock frequency divided by a power of 2 to set the baud rate. Clock
frequencies that are fractions or multiples of 11.0592MHz are generally
suitable for this task. Once a crystal frequency has been chosen, the baud
error should be calculated using the equation in the microprocessor's
datasheet. If it is greater than 3%, it is likely communications will not=
be
able to be established between the microprocessor and the PC. Also, a
microprocessor using a resistor/capacitor (RC) clock source will most lik=
ely
not be able to maintain serial communications due to fact the frequency of
operation is likely to drift more than 3%. Since the baud rate error will
follow the percentage change in the microprocessors clock frequency, this
poses the same problem as having a 3% static baud rate error. Once
the PC and the microprocessor are communicating, two open collector I/O
lines, with pull-ups to the 2-wire device's VCC level are requ=
ired
for communication to the 2-wire device. The PIC reference design uses two
tri-stateable totem pole outputs, but it emulates an open-collector devic=
e by
either driving the signal low or tri-stating the output. The only differe=
nce
between this and a true open-collector output is the VCC level=
of
the 2-wire device must be at or below the VCC level of the PIC
circuit. If that relationship is not maintained the voltage level of the
input will violate the PIC's specification for input levels. The
remaining part of this section concentrates on specifics of the reference
design's hardware. Figure 1 shows a block diagram of the reference design
circuit.
In
addition to the criteria at the beginning of this section, the following
items were design goals for this circuit:
To
accomplish these goals, a PIC16LF628 processor was chosen primarily becau=
se
of the low-voltage operation and low cost. Other desirable features inclu=
de a
hardware UART for fast interrupt based communication, crystal inputs that
allow accurate bard rates, and it is available in a small 20-pin 173mil T=
SSOP
package. To
translate the signal levels for the RS232 port, a MAX3223 was chosen beca=
use
it provides true RS232 signal levels when used with a single power supply
(3.0V to 5.5V). Additionally it has two channels, which will allow the us=
e of
the serial port's DTR (data terminal ready) signal to reset the board. Th=
is
part is also available in a tiny 20-pin TSSOP package. The MAX3223 and the
PIC can operate off of the same VCC supply, and both chips wil=
l work
over a 3V to 5.5V range. This allows the board to work with both 3V and 5V
2-wire parts. Signals
RA0 and RA1 are used to communicate with the 2-wire devices and pull-ups =
are
connected to them for the open collector 2-wire bus. RB1 and RB2 are
interfaced to the serial port via the MAX3223, which uses external capaci=
tors
(not shown) to generate true RS232 levels. The remaining I/O pins are bei=
ng
used for bit I/O. They can be used for other serial protocols, or to cont=
rol
the other digital inputs on the 2-wire parts if desired. This will be
described more in depth in the firmware section. The most complicated sec=
tion
of the circuit shown on the block diagram is the reset circuitry. On a PIC
microprocessor, MCLR is an active-low reset signal. The gate of the NMOS =
is
connected to the DTR signal, which is being level shifted by the MAX3223.=
If
the DTR signal at the gate of the NMOS is high, the NMOS will be on, which
will hold the PIC in reset. If the DTR signal is low at the gate the NMOS=
, it
will release the MCLR signal, which will allow the MCLR signal to adjust
itself to be either VCC in normal operation or VPP =
if
the PIC is being incircuit programmed. The Schottky diode is present to
isolate the VPP supply from the VCC supply during
programming, and the resistor is limiting the diode's through current when
the NMOS is forcing the processor into reset. Although MCLR is brought ou=
t to
a connector, this pin should be left disconnected during normal operation=
. It
is used only for in-circuit programming the PIC. A
complete schematic and bill of materials (BOM) for the entire reference
design are available on Dallas Semiconductor's FTP site. A link to the
location on the FTP site has been provided in the walk-though section of =
this
document. Designing Firmware to Communicate with PCs and 2-Wire
Devices The
items considered essential and basic for 2-wire communication were the st=
art
(re-start) bus command, stop bus command, write a data byte, read a data =
byte
with acknowledge, and read a data byte without acknowledge. Three other i=
tems
are supported by the firmware. The first is a command to toggle SCL nine
times, which is useful to reset the 2-wire bus if there is an error detec=
ted
during communication. The last two are bit I/O reads and writes, which ei=
ther
reads the state of an I/O pin or sets the state of the I/O pin depending =
on
which command is issued. These commands are present to allow using the
remaining I/O signals on ports A and B of the PIC for whatever may be des=
ired
by the designer. Figure
2. Serial port commands to communicate with the PIC circuit=
Figure
3 demonstrates the sequence required to communicate with a 2-wire device
responding to address 0x40. Each operation requires the PC to send two by=
tes
to the PIC. Once the second byte is received by the PIC, it will begin to
process the data it has received. The first byte received determines the =
type
of operation (start, send data, etc.) to be executed. If the command requ=
ires
a data operand, it will look at the second byte sent, else the second com=
mand
byte is ignored. Since the processor expects two bytes per instruction a
dummy byte must be sent if the second byte is not required for the comman=
d.
If the PIC receives an invalid command, it will return 0xFA, which indica=
tes
a failure. At
least one value is always returned to acknowledge the command has complet=
ed
successfully or failed, and in the case of a 2-wire read byte operation, =
both
the data byte and the command's acknowledgement is returned. The acknowle=
dge
byte the PIC is returning for each instruction is really informing the
software that two items are both happening successfully. First, it confir=
ms
the PIC is communicating with the PC. This may seem simple and reliable m=
ost
of the time, but it does provide feedback to inform the user of a
disconnected serial cable, or power has not been applied to the applicati=
on
board. Second, it verifies the PIC, which is continually monitoring the
2-wire communication, is seeing the acknowledgement it expects. This means
there is no breakdown in communication from either the PC to the PIC, or =
from
the PIC to the 2-wire device. Figure
3. Example 2-Wire write and read communication sequences
The
bit I/O commands (0xE? and 0xF?) can used to set the state of an I/O pin =
as
an output, or it can place the pin in a high-impedance state and read it =
as
an input. Since this application note is not aimed at bit I/O operations,=
it
will not be discussed in depth at this junction. However, the command
protocol is included in Figure 2, and the ? values that identify a specif=
ic
I/O pin can be seen in Figure 4. Figure
4. Bit I/O Read and Write Addresses
To
implement the firmware discussed above, the program flow shown in Figure 5
was constructed. The program waits to receive two command bytes, and
validates each byte as it is received. Once two valid bytes are received,=
the
program executes the command. If two valid bytes are not received, the
firmware rejects the command, and returns an error code instead of the
command acknowledgment. The firmware (dsio.hex) is available on the FTP s=
ite.
In
the event custom firmware is required for a project, it is highly recomme=
nded
the firmware is written and debugged separate of the PC software. This ca=
n be
accomplished using a terminal program to emulate what is required of the =
PC
during firmware development. This allows a separation of issues, and it c=
an
keep the debug time minimal. Writing Low Level Software for the PC to Control the P=
IC C++
is a very powerful language, which incorporates both a large number of
predefined variable types, as well as classes, which allow the definition=
of
user-defined objects and variables. The way the code was made reusable in
this instance was a C++ class was written to handle all communication to =
the
PIC circuit. Because all of the communication requirements were contained
within a single class, any instance of the class is hence able command the
circuit to do any of its functions. The provided class is called CdsPic, =
and it
is contained in two files, DSPIC.cpp, and DSPIC.h. The
C++ class initializes the serial port in the class's constructor. The
initialization opens COM1, resets the PIC, and then waits for the PIC's
serial port initialization banner to identify the PIC circuit to the PC. =
If
the PIC is "not found", the constructor will close COM1, and try
COM2, then COM3, and finally COM4. Once the correct port is found, it will
exit the constructor, and the DetectBoard() function will return true when
called. If the PIC is not found after all four ports are checked, the
constructor will exit, and the DetectBoard() function will return false w=
hen
called. If the function returns false, it is up to the application softwa=
re
to handle the issue. Assuming
the adapter is "found," all of the 2-wire functions of the class
can be called as long as the class remains within scope. These functions
include, Start2W(), WriteSlave2W(), ReadSlave2W(), and Stop2W().
Additionally, there is a command (ToggleSCL9x()) to clock the 2-wire bus =
nine
times which can be used to reset the bus in the event communications are
disturbed during any transmission. To communicate with the PIC's firmware,
these commands call several routines to read and write data via the serial
port. These routines are present in two additional files, DSIOLIB1.cpp and
DSIOLIB1.h. Once
the class leaves scope, generally when the application is exited, applica=
tion
will deallocate all of the memory being used for its variables. This will
call the CdsPic class's destructor, and the destructor will close the ser=
ial
port. Since
the 2-wire routines are provided for customers, the most of the details of
the implementation will not be discussed in this application note. One th=
ing
that should be mentioned is the serial port code included will only work =
in a
Window's environment (Windows NT 3.1, Windows 95, or subsequent versions =
of
either). If a different programming language or operating system is desir=
ed,
the communications software will have to be rewritten to accommodate the =
OS
and language requirements. The easiest way to do this would be to look at=
the
provided C++ code to see what must be sent and what is received while
communicating with the firmware. Then mimic the transactions with the new
software. The serial port settings required to establish communication are
57600 baud, 1 stop bit, and no parity. Building Application Hardware and PC Software Using the
Reference Design
An
example 2-wire application was generated that can be downloaded from Dall=
as
Semiconductor's FTP site. It is called DS2W, and it is a generic 2-wire t=
ool
that allows the user to communicate with 2-wire devices from Window's dia=
log
box interface. The GUI for the program is shown below.
The
source code for this application is included on the FTP site, and can be =
used
as an example to aid in development with the PIC circuit. The code shows =
how
to use all of the 2-wire related functions available in CdsPic class to b=
uild
a Windows-based application. Additionally,
the executable DS2Wa.exe can be downloaded and executed if the hardware is
built as described above. The
FTP site information referenced above is available at the following locat=
ion:
ftp://ftp.dals=
emi.com/pub/system_extension/AN206/
Summary Hopefully
this application note will simplify new product development using Dallas
Semiconductor's 2-wire devices. Please direct any questions regarding
development of 2-wire applications to the Mixed Signal Applications email
address, . Note: As an example, Dallas Semiconductor has provided a reference hardware des= ign, firmware, and PC software with this application note; however, use the provided materials at your own risk. Dallas Semiconductor will not be held liable for any complications or damages associated with use of the provid= ed materials. <= o:p>
|
<=
!-- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -->
|
Copyright © 2005 by Maxim Integrated Products
• Legal Noti=
ces
• <=
span
style=3D'color:#6060A0;text-decoration:none;text-underline:none'>PRIVACY PO=
LICY