Atmel AT89C51, Приложение

Страница: 3 / 11

tion, programmer signals may be buffered with three-state
buffers similar to the 74xx125.
The AT89C51 in the programmer does not utilize external
program or data memory, which would require sacrificing
needed I/O pins. This requires that program code and I/O
buffers be kept small enough to fit in on-chip memory.
Remote Programming Over a Commercial
Telephone Line
The programmer and display application described pre-
viously are connected to a phone line via a modem at a
remote site. Using a personal computer with a modem, a
user can upload a new program containing a new mes-
sage, which is programmed into the AT89C51 embedded
in the application. When programming is complete, the
application executes the new program, which displays the
new message.
Local Station
The local station in the test configuration consists of an
IBM PC AT-class computer connected to a Hayes-com-
patible, Prometheus 1200 baud modem. The modem was
selected because it was inexpensive and available. A
faster modem may be used if desired, although once the
file transmission time is reduced below one minute, further
reductions in transmission time do not further reduce con-
nect time charges. A possible advantage to higher trans-
mission speeds is the automatic error detection and cor-
rection available in some high speed modems.
Procomm Plus version 2.01, a commercial data communi-
cations package, is used to configure the modem, set up
communications parameters, and establish a link with the
remote modem. Procomm Plus includes a macro lan-
guage called ASPECT, which allows the user to write and
compile scripts which implement custom file transfer pro-
tocols. A simple ASPECT script was written to read the
contents of a program file and upload it to the remote pro-
grammer.
The file transfer protocol (FTP) implemented is a simple
send-and-wait, packet-oriented protocol. The transmit
and receive modes of the FTP are illustrated by the flow-
charts in figures 4 and 5, respectively. The transmitter
sends each packet without flow control and waits for a re-
sponse. The programmer (the receiver) reads and dis-
sects the packet while calculating a checksum. If the cal-
culated checksum is valid, the programmer acknowledges
the packet by sending an ACK. If the checksum is in error,
the programmer negatively acknowledges the packet by
sending a NAK. Upon receipt of an ACK, the transmitter
sends the next packet. If the transmitter receives a NAK,
it resends the same packet. Transmission proceeds in this
manner until the entire file has been transferred.
The programmer might respond to a packet by sending a
CAN, which indicates that a non-recoverable error has oc-
curred and that the transmitter should immediately abort
the file transfer. If the programmer fails to respond to a
packet within a limited period of time, the transmitter will
resend the same packet. The transmitter will continue to
resend the same packet until a valid response is received
or until the allowed number of attempts is exceeded, at
which time the file transfer is aborted.
After each packet is received and validated by the pro-
grammer, the data contained in the packet is programmed
into the AT89C51 controller in the application. After pro-
gramming, the data is read back from the controller and
verified against the received packet data. Successful veri-
fication indicates successful programming, causing the
programmer to send ACK to the transmitter. If program-
ming fails, the programmer sends CAN to signal the trans-
mitter to abort the file transfer.
The simplicity of the FTP reduces the amount of AT89C51
program memory used in the programmer. The send-and-
wait nature of the FTP allows inter-packet delays due to
AT89C51 program and erase times to be easily absorbed.
Support for program verification is transparent, requiring
no explicit command or result codes, or additional data
transfers.
The files which are uploaded to the programmer are cre-
ated with the tools in the Intel MCS-51 Software Develop-
ment Package for the IBM PC. Included in the package
are the MCS-51 Macro Assembler, MCS-51 Relocator
and Linker, and a useful utility, OH. OH converts an abso-
lute 8051 object file to an equivalent ASCII hexadecimal
object file.
The records in the hex file produced by the OH utility
serve, unchanged, as the packets in the FTP described
above; no service fields need to be added. The colon
which begins each record serves as the packet signature
field. The load address field serves as the packet se-
quence number. A checksum is provided as the last field
in each record. Since seven-bit ASCII coding is utilized,
the eighth bit of each byte is available to be used for parity
checking.
Because the AT89C51 in the programmer does not utilize
external data memory, necessary packet buffering must
be done using internal RAM. Limited memory precludes
the use of conventional FTPs which utilize packets of 128
bytes and larger. The hex packet format used in this appli-
cation limits packet data fields to 16 or fewer entries, re-
quiring little memory for buffering.
The ready availability of a utility for creating the packet-
ized program file, combined with small packet size and
adequate error checking, makes the hex packet format a
near ideal solution for this application. A disadvantage is
Microcontroller
4-11