外文翻译--单片机在编程电路中的应用(编辑修改稿)

外文翻译--单片机在编程电路中的应用(编辑修改稿)内容摘要：

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 nonrecoverable 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 programmer, the data contained in the packet is programmed into the AT89C51 controller in the application. After programming, the data is read back from the controller and verified against the received packet data. Successful verification indicates successful programming, causing the programmer 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 sendand wait nature of the FTP allows interpacket delays due to AT89C51 program and erase times to be easily absorbed. Support for program verification is transparent, requiring no explicit mand or result codes, or additional data transfers. The files which are uploaded to the programmer are created with the tools in the Intel MCS51 Software Development Package for the IBM PC. Included in the package are the MCS51 Macro Assembler, MCS51 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 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 hex 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。