Rainbow Electronics АТ89С51 - Manual (Page 3)

Microcontroller
5-13
Remote Programming Over a Commercial
Telephone Line
The programmer and display application described previ-
ously 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 appli-
cation 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-compatible,
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 connect time
charges. A possible advantage to higher transmission
speeds is the automatic error detection and correction
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 language
called ASPECT, which allows the user to write and compile
scripts which implement custom file transfer protocols. A
simple ASPECT script was written to read the contents of a
program file and upload it to the remote programmer.
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 flowcharts
in figures 4 and 5, respectively. The transmitter sends each
packet without flow control and waits for a response. The
programmer (the receiver) reads and dissects the packet
while calculating a checksum. If the calculated checksum is
valid, the programmer acknowledges the packet by send-
ing 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
occurred 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 verifi-
cation indicates successful programming, causing the pro-
grammer to send ACK to the transmitter. If programming
fails, the programmer sends CAN to signal the transmitter
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 trans-
fers.
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 absolute
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 sequence 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, requir-
ing little memory for buffering.
The ready availability of a utility for creating the packetized
program file, combined with small packet size and ade-
quate error checking, makes the hex packet format a near
ideal solution for this application. A disadvantage is the use
of ASCII, which requires each program data byte to be
expressed as two hex characters. This demands that
nearly twice as many bytes be transferred as might other-
wise be required. This is not a severe limitation, however,
since typical file transfer times are less than one minute.
Overall, the simplicity of the custom FTP/hex packet format
implementation outweighs the drawbacks.
Remote Station
The remote station in the test configuration consists of the
display application and programmer circuits, described pre-
viously, connected to a Hayes-compatible, Prometheus