【正文】 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 sevenbit 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 application limits packet data fields to 16 or fewer entries, requiring little memory for buffering. The ready availability of a utility for creating the packetized program file, bined with small packet size and adequate 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 he x characters. This demands that nearly twice as many bytes be transferred as might otherwise 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 previously, connected to a Hayespatible, Prometheus 1200 baud modem. During normal operation, the application executes its internal program while the modem and programmer monitor the phone line for ining calls. After a call has been detected and a connection established, the programmer forces the application to suspend execution of its program. The new program is then downloaded and programmed into the AT89C51 embedded in the application. When programming is plete, the application is allowed to begin execution of its new program, and the programmer returns to monitoring the phone line for the next call. The programmer powers up with its programming control outputs inactive, allowing the application to run normally. After configuring the modem to answer ining calls, the programmer puts itself to sleep. The programmer will not disturb the application until a new program is to be downloaded. The programmer controls the modem by sending ASCII mand strings over the serial interface, to which the modem responds with Hayesstyle ASCII numeric codes. The software is designed for use with Hayespatible modems, which includes the Prometheus ProModem 1200 used here. The serial interface, through which the programmer connects to the modem, supports two handshaking signals, DTR and DSR. On power up, the programmer asserts DTR, to which the modem responds by asserting DSR. If the modem should fail to respond to any mand, including the mand to hang up, the programmer deasserts DTR, which forces the modem to drop the line. The modem monitors the phone line while the programmer sleeps, waiting for an ining call. When a call is detected, the modem answers and attempts to establish munication with the caller. If a connection is established, the modem sends a code to the programmer, waking it up. The programmer verifies the connect code and begins polling for a valid packet header. Ining packets must arrive fewer than thirty seconds apart, or the modem drops the line (hangs up) and the programmer returns to sleep, waiting for the next call. If the caller hangs up, the thirty second period must expire before another call will be answered. Calls ining during the reset delay period are ignored. If a valid packet header is received prior to the expiration of the reset delay period, the programmer will attempt to read and validate the ining packet. At any time during packet reception, an invalid character, parity error or timeout during character reception will cause the partial packet to be declared invalid and discarded. Two packet types are defined: data and endoffile. A data packet contains five fields in addition to the packet header, one of which is a variable length data field. The data field contains program data to be written into the AT89C51 controller in the application. The load address field contains the address at which the data is to be written. The endoffile packet contains the same fields as the data packet, except that the data field is empty. This packet type has special meaning to the programmer, as explained below. Any packet which contains an invalid record type, record length or checksum is invalid. Program data accumulated during the processing of an invalid packet is discarded. The programmer sends a NAK to the transmitter to signal reception of an invalid packet and resumes polling for a valid packet header. Receipt of the first valid data packet causes the programmer to interrupt the application controller. The controller responds to the interrupt by abandoning execution of its usual program and displaying a message indicating that programming is taking place. If this is the first valid data packet since power was applied or an endoffile packet was received, the programmer asserts