毕业论文(设计)科技文献翻译
院 系： 自动化工程学院电子工程系
专 业：
班 级：
姓 名：
指导教师：
2012年4月10日
译文题目：
原稿题目：
原稿出处：
毕业设计（论文） 译文及原稿 51单片机在编程电路中的应用 AT89C51 In-Circuit Programming www.atmel.com/dyn/resources/prod_documents/doc0287.pdf
AT89C51 In-Circuit Programming
This application note illustrates the in-circuit programmability of the Atmel AT89C51 Flash-based microcontroller. Guidelines for the addition of in-circuit programmability to AT89C51 applications are presented along with an application example and the modifications to it required to support in-circuit programming. A method is then shown by which the AT89C51 microcontroller in the application can be reprogrammed remotely, over a commercial telephone line. The circuitry described in this application note supports five volt programming only, requiring the use of an AT89C51-XX-5. The standard AT89C51 requires 12 volts for programming. The software for this application may be obtained by downloading from Atmel’s General Considerations
Circuitry added to support AT89C51 incircuit programming should appear transparent to the application when programming is not taking place.
EA/VPP must be held high during programming. In applications which do not utilize external program memory, this pin may be permanently strapped to VCC. Applications utilizing external program memory require that this pin be held low during normal operation.
RST must be held active during programming. A means must be provided for overriding the
application reset circuit, which typically asserts RST only briefly after power is applied.
PSEN must be held low during programming, but must not be driven during normal
operation.
ALE/PROG is pulsed low during programming, but must not be driven during normal
operation.
During programming, AT89C51 I/O ports are used for the application of mode select,
addresses and data, possibly requiring that the controller be isolated from the application circuitry. How this is done is application dependent and will be addressed here only in general terms.
Port Used for Input
During programming, the controller must be isolated from signals sourced by the
application circuitry. A buffer with threestate outputs might be inserted between the application circuitry and the controller, with the buffer outputs three-stated when programming is enabled. Alternately, a multiplexer might be used to select between signal sources, with signals applied to the controller by either the application circuitry or the programmer circuitry.
Port Used for Output
No circuit changes are required if the application circuitry can tolerate the state changes
which occur at the port during programming. If the prior state of the application circuitry must be maintained during programming, a latch might be inserted between the controller and the application circuitry. The latch is enabled during programming, preserving the state of the application circuitry.
An Application Example
The AT89C51 application shown in Figure 1 is an implementation of a moving display. This
application was selected for its simplicity and ability to show graphically the results of in-circuit reprogramming. The text to be displayed is programmed into the controller as part of its firmware, and cannot be changed without reprogramming the device.
The displayed text is presented in one of two modes selected by the four-position DIP
switch. In the first mode, one character at a time enters the display from the right and moves quickly to the left through each element of the display to its final position in the assembled message. In the second mode, the message moves through the display, from right to left, with the display acting as a window onto the message. This mode is familiar as the method often used in displays of stock prices.
The output consists of four DL1414T, four-digit, 17-segment alphanumeric displays with
integral decoders and drivers. This yields 16 total display elements, each capable of displaying digits 0-9, the upper case alphabet, and some punctuation characters. The displayable character codes are ASCII 20H-5FH.
A power-on reset circuit and a 6-MHz crystal oscillator complete the application. Neither
external program memory nor external data memory is used.
Modifications to the Application to Support
In-Circuit Programming Figure 2 shows the application modified for in-circuit
programming.
It is assumed that the programmer, when inactive, will neither drive nor excessively load the
application. Since the application does not use external program memory, EA/VPP on the controller is connected to VCC. This meets the requirement for programming.
The reset circuit has been modified by the addition of twotransistors, which allow RST on
the controller to be forced high by the programmer.
PSEN and ALE/PROG, unused in the basic application, areunder the direct control of the programmer.
Programming requires programmer access to all of the four AT89C51 I/O ports, as
documented in the data sheet. The programmer is connected directly to those controller pins which are unused by the application, while access to pins used by the application requires special treatment, as explained in the following paragraphs.
The least significant four bits of the address generated by the programmer are multiplexed
onto port one of the controller with the data from the DIP switch. Note that the four resistors added at the switch are not required in the basic application, since the AT89C51 provides internal pull-ups on port one.
During the normal operation of the application, controller ports zero and two provide data
and control signals (respectively) to the displays. During programming and program verification, the programmer asserts control of port zero and part of port two. The programmer is connected to ports zero and two without buffering, since, when inactive, its presence does not affect the normal operation of the application.
A transparent latch has been added between port two of the controller and the display
control inputs. The latch holds the display control signals inactive during programming, which eliminates erratic operation of the displays due to programmer activity on ports zero and two. No isolation of
the display data inputs is required, since data applied to the inputs is ignored when the
control signals are inactive.
The AT89C51 reset circuit, input multiplexer and output latch are controlled by a single
signal generated by the programmer. During programming, reset is asserted, the multiplexer switches inputs, and the latch freezes the display control lines.
To ensure that the display control lines are in a known state before they are latched, an AT89C51 external interrupt is used to allow the programmer to signal the application before asserting reset. The application firmware responds to the interrupt by displaying a message and deactivating the display control lines.
After programming, when reset is deasserted, the controller ports are high as the latch
becomes transparent. Since the display control inputs are inactive high, the display contents are not disturbed until the new program writes the display. Although not essential to this application, it might be imperative in some applications that the state of the peripheral circuitry not be disturbed during programming.
The Programmer
The programmer (Figure 3) generates the addresses, data and control signals necessary to
program the AT89C51 embedded in the application.
The programmer circuitry consists of an AT89C51 and an RS-232 level translator. The
controller runs at 11.0592 MHz, which allows the serial port to operate at a number of standard baud rates. A Maxim MAX232 line driver/receiver produces RS-232 levels at the serial interface while requiring only a five volt supply.
Many of the signals generated by the programmer are connected directly, without buffering,
to the AT89C51 in the application. These signals, when inactive, are not threestated, but are pulled high. The AT89C51 has internal pull-ups of approximately three Kohms on ports one, two and three. Because port zero does not have internal pull-ups, external pull-ups of ten Kohms have been added to permit proper operation of program verification mode. The sample application operates correctly in this environment. If required for compatibility with an application, 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 previously 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 message, 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-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 communications 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 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 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 send-andwait 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 created with the tools in the Intel MCS-51 Software Development 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 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, combined 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 Hayes-compatible, Prometheus 1200 baud modem. During normal operation, the application executes its internal program while the modem and programmer monitor the phone line for incoming 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 complete, 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 incoming 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 command strings over the serial interface, to which the modem responds with Hayes-style ASCII numeric codes. The software is designed for use with Hayes-compatible 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 command, including the command 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 incoming call. When a call is detected, the modem answers and attempts to establish communication 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.
Incoming 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 incoming 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 incoming 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 end-of-file. 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 end-of-file 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 end-of-file packet was received, the programmer asserts the control signals necessary to erase the program memory in the application controller. The programmer then places the controller in programming mode.
The first and subsequent valid data packets are dissected as they are received and the data which they contain is programmed into the application controller at the address indicated in the packet load address field. After programming, the data is read back from the controller and verified against the received packet data. Successful verification indicates that programming was successful, causing the programmer to send ACK to the transmitter. The programmer then resumes polling for a valid packet header, subject to the thirty second reset delay.
If programming fails, the programmer sends CAN to signal the transmitter to abort the file transfer. The modem drops the line and the programmer returns to sleep, waiting for the next call. The application controller is left in programming mode, preventing it from executing the incomplete or invalid program which it contains.
It is important to note that invalid packets are NEVER programmed into the application controller. To do so would require that the program memory in the controller be completely erased before the error could be corrected, causing the non-recoverable loss of all previous program data.
Upon receipt of an end-of-file packet, the programmer returns its control outputs to the inactive, power on state, allowing the application controller to begin execution of the new
program. The programmer then resumes polling for a valid packet header, subject to the thirty second reset delay.
If a valid packet is received prior to the expiration of the thirty second delay, another programming cycle begins, which can only be terminated by the reception of a valid end-of-file packet.
If the reset delay expires prior to the reception of a valid end-of-file packet, the modem will drop the line and the programmer will return to sleep, waiting for the next call. In this case, the application controller is left in programming mode, preventing it from executing its program. To return the application to normal operation, another call must be received, and a valid program file uploaded, terminated by an end-of-file packet.
51单片机在编程电路中的应用
本应用指南说明了Atmel AT89C51是可在线可编程的微控制器。它为电路编程提出了相应的例子，程序的修改需要在线编程的支持。这类显示方法在应用程序中的AT89C51单片机可通过电话线远程控制。该应用指南所描述的电路只支持5v电压下编程。此应用软件可以到Atmel进行下载。
总论
当不在进行程序设计的时候，在电路设计中的AT89C51设计将变得透明化。
在编程期间必须重视EA/VPP这一脚。在不使用外部程序存储器的应用程序中，这脚可能会永久接到VCC。应用程序使用的外部程序存储器要求这一脚为低电平才能正常运行。
RST在编程期间必须为高电平。应该提供一种方法使得电路通入电源以后，使RST代替主要的复位电路起到复位的作用 。
在编程过程中，PSEN必须保持低电平，在正常运行期间绝不能使用。
ALE/ PROG在编程过程中输出低电平，在正常运行期间绝不能使用。
在编程过程中，AT89C51的I / O端口是用于模式应用程序，地址和数据选择的，可能需要该控制器从应用的电路隔离。如何做到这一点取决于应用程序。
输入端口
在编程过程中，控制器必须与应用电路的信号来源隔离。带有三个输出状态的缓冲区会在应用程序之间插入电路和控制器，同时在编程时缓冲区输出三种状态。一个多路复用器可用于信号源之间进行选择，适用于任何一方的应用电路或编程控制器电路的信号。 输出端口
如果应用的电路可以允许端口在编程过程中的状态变化，则不需要改变电路。如果应用电路的状态，必须事先在编程过程中的保持不变，可能在控制器和应用电路中插入锁存。锁存在编程期间是可用的，并保存应用程序的电路状态。
应用实例
应用是该AT89C51一个移动的显示情况。此应用程序有在电路重新编程时将结果以图表的形式显示的简单能力。文本显示被设计作为其硬件的一部分，不能在无改编情况下变化。
显示的文本可在4位DIP开关选择两种模式之一中进行。在第一种模式的时候，进入一个字符从右边显示和快速移动，通过每个元素显示其在最后的装配位置的左侧。在
第二个模式，信息在信息窗口中右到左移动显示。这种模式与常常在股票价格的显示器所使用的方法类似。
输出包括四个DL1414T，4位17段的积分解码器和驱动程序的字母数字显示器。这就产生了16名显示元素，每个数字有0-9的显示能力，是大写字母，标点符号和一些字符。
可显示字符的ASCII 码，范围为20H-5FH。上电复位电路和一个6 MHz的晶体振荡器完成应用软件程序。无论外部程序存储器或外部数据存储器都时可用的。
支持应用程序的修改
据推测，编程器在休眠时，既不会驱动，也不会加载应用程序。由于应用程序不使用外部程序存储器，EA/VPP脚接VCC电源。复位电路被两种转换器改变状态，此转换器允许编程时RST接高电平。在基本应用时未使用的PSEN和ALE/ PROG，是被程序员直接控制的。
编程器的编程需要获得所有数据表中记录的AT89C51的I / O端口。编程器是与那些应用程序未使用的控制器的引脚相连的，而这些应用程序的引脚需要最低有效位的四所产生的地址是可获得的，如下段所述。
由编程器生成的最小的四位地址是与DIP转换的数据在控制器的端口多路复用的 请注意，加在开关上的四个电阻在基本应用中并不是必须的，因为AT89C51的端口上提供一个内部上拉电阻。
在应用程序的正常运作时，控制器端口0，1个分别在显示器上提供数据和控制信号。在编程和程序验证时，编程受端口0和端口2的一部分控制。程序设计器连接端口0和1，没有缓冲，因为，在不活动时，它的存在不影响应用程序的正常运作。
透明锁存器被加在了控制器的两个端口之间做输入控制。锁存持有的显示控制信号在编程过程中不反应，从而消除端口0和2由于程序控制器的活动造成操作失误。显示数据输入是不能被孤立的，因为数据应用到输入被忽略时，控制信号无效。
AT89C51单片机复位电路，输入多路复用器和输出锁存器是由程序控制器生成一个单一的信号来控制的。在编程过程中，复位键生效，多路开关信号输入，以及冻结显示锁存控制线。
为确保控制线显示在已知的状态前锁定，AT89C51的外部中断是用来允许程序控制器在复位之前向应用程序发出信号。应用程序固件响应中断显示一条消息，关闭显示控制线。
编程后，当复位生效，当锁存可视控制器端口输出高电平。由于显示控制输入不为高电平，直到新的程序写入显示器内部不被打乱。虽然这个应用程序是没有必要的，它可能在某些应用中必须指出，在编程过程中不会扰乱外围电路的状态
程序控制器
程序控制器生成的地址，数据和控制信号，对嵌入到程序中的AT89C51有重要作用。 程序控制器电路由一个AT89C51和一个RS - 232电平转换器组成。该控制器运行在11.0592兆HZ，此频率允许串口运行在一个标准波特率下。一个MAXIM MAX232线路驱动器/接收器产生RS - 232水平，而只需要5伏的电源系统。
程序控制器所产生的信号许多只需直接连接到AT89C51，无需缓冲。这些信号，在不活动时，不再是三种状态，但被接高电平。AT89C51的端口1，2，3内部有大约3000欧
姆的上拉电阻，因为端口0没有内部上拉电阻，所以外部10千欧姆的上拉电阻已经加上允许适当的程序认证模式操作。示例应用程序在这种环境下可正常运行。如果有需要的应用程序兼容性，程序发出的信号可能在类似74xx125三态缓冲缓冲区内缓冲。
AT89C51的程序不使用外部程序或数据存储器，这需要牺牲所需要的I / O引脚。这就要求程序代码和I / O缓冲区保持足够小以适合片上存储器。
商业电话线远程编程
编程器和前面描述的显示应用是与通过调制解调器连接在远程站点电话线相连的。使用链接调制解调器的个人电脑，用户可以上传包含一个新的消息的程序，这个信息被变成进了嵌入到应用程序的AT89C51中。当编程完成后，应用程序执行新的程序，它显示新信息。
本地配置
测试配置的本地配置包括一台IBM个人电脑级的计算机连接到与Hayes兼容的，普罗米修斯1200波特的调制解调器。选择此调制解调器，因为它是廉价可得。更快的调制解调器如果需要的话可使用更快速的调制解调器，尽管一旦该文件的传输时间低于1分钟，进一步削减的传输时间不会进一步降低连接时间费用。更高的传输速度的可能优势是在某些高速调制解调器内的自动错误检测和纠正。
Procomm Plus版本2.01，是一个商业数据通信软件包，用于配置调制解调器，建立通讯设置参数，并建立与远程调制解调器的链接。 Procomm Plus包括所谓的宏语言方面，它允许用户编写实现自定义的文件传输协议的脚本。一个简单的脚本编写用来读取一个程序文件的内容，并上传到远程编程器 。
文件传输协议（FTP）的实施，是一个简单的发送和等待的，数据包导向的协议。FTP模式发送和接收的是用数字4和5，如流程图所示。不在流程控制下发射器发送每个数据包，并等待响应。
在计算校验和时那个程序控制器（接收器）读取并剖析了数据包。如果计算出的校验和是有效的，程序员通过发送一个ACK承认此数据包。如果校验和错误，程序员通过发送一个NAK来否定。当接收一个ACK后，发射器发送下一个数据包。如果传送者接收到NAK，它重新发送相同的数据包。以这种方式传输，直到整个文件已被移交。
程序控制器可能通过发送一个CAN来响应数据包，CAN表明一个不可恢复的错误发生，而发射机应立即中止文件传输。如果程序员没有在有限的时间内响应到一个数据包，发送器将重新发送相同的数据包。
发射器将继续重发，直到接收到一个有效的反应，或者，超出文件传输被中止的时间。每个数据包接收和通过程序员验证后，数据包中包含的数据被加载到的AT89C51单片机控制器编程。
编程后，数据从控制器读回并对接收的数据包进行验证。成功的审查表明，成功的程序设计，使程序员发送ACK给传送者。如果编程失败，程序员发送CAN向传送者发送信
号中止文件传输。
简单的FTP减少了AT89C51的程序在编程时使用的内存量。由于AT89C51的编程和擦除时间可以很容易地吸收，FTP发送和等待的性质允许跨包延迟。对程序验证的支持是透明的，不需要明确的命令或结果代码，或转让的其他数据。
上传到程序控制器的文件是用英特尔MCS- 51软件开发包来创建的。在包中包括了MCS - 51宏汇编，MCS - 51单片机Relocator和连接器，以及一个有用的工具，OH。OH将8051绝对目标文件转换为为等效的ASCII十六进制目标文件。
远程配置
在测试配置中的远程配置包括显示应用程序和程序员电路，如前所述，连接到一个与Hayes兼容的普罗米修斯1200波特调制解调器。在正常操作时，应用程序执行其内部程序，而调制解调器和程序员监测来电电话线。
通话被检测到并连接建立后，程序器强迫暂停其程序的执行。新的程序就被下载并嵌入到应用程序中的AT89C51的编程。当编程完成后，应用软件程序获准开始其新的程序执行，而程序控制器返回监督下一个通话的电话线。
程序控制输出无效时程序控制器上电，允许应用程序正常运行。在配置调制解调器接听来电后，程序控制器停止工作。是程序控制器不会影响到程序直到一个新的程序应用程序被下载。
程序员通过发送控制在串行接口上的ASCII命令字符串来控制调制解调器，对此调制解调器响应海斯式调制解调器的ASCII数字代码。该软件是专为与海斯兼容使用的调制解调器，其中包括这里使用的1200普罗米修斯ProModem。
串行接口，程序员通过它连接到调制解调器，它支持两个握手信号，DTR和DSR。上电时，程序控制器判定DTR，断定为DTR后调制解调器响应。如果调制解调器不响应任何命令，包括命令挂断，程序控制器抬高DTR点位，强制调制解调器下降。
当程序控制器停止工作后，监测调制解监听电话线，等待来电呼叫。当检测到输入，调制解调器响应并试图与输入建立通信。如果建立了连接，调制解调器发送一个代码，唤醒程序控制器。程序控制器验证连接的代码，并开始审查有效的数据包报头。
传入数据包必须在少于30秒内到达，否则调制解调器挂断和程序控制器继续停止工作，等待下一次呼叫。如果来电挂断，在得到下一次呼叫之前，三十秒时间必须终止。在复位延迟时间传入是被忽略的。
如果复位延迟时间结束之前收到一个有效的数据包报头，程序控制器将尝试读取和验证传入的数据包。在数据包的接收过程中的任何时间，无效字符，奇偶校验错误或超时的时间内接待字符将导致部分数据包被宣布无效，并丢弃。
两个数据包类型定义：数据和最终文件。数据包包含五个领域，除了包报头，是一个可变长度的数据字段。数据字段包含程序的数据在应用程序中被写入在AT89C51的控制器。负载地址字段中包含数据写入的地址。末端文件包中包含与数据包相同的领域的文件，
但该数据字段是空的。这包类型对程序控制器具有特殊的意义，如下所述。
任何包含有效文种的数据包，记录长度或校验和无效。程序数据在一个无效的数据包被丢弃的处理过程中被积累。编程器给传送者发送一个NAK作为信号数据包的接收和恢复为一个有效的数据包报头审查的警示信号。
第一个有效数据的接收引起编程器中断应用程序控制器。该控制器的中断响应放弃其正在运行的程序，并显示一条消息，表明程序已经被替代。如果这是由于接收了末端文件或者是电源触发从而接收的第一个有效的数据包，运用必要的控制信号清除在应用控制器内的记忆程序。然后编程器在程序模式中放置控制器。
当接收到第一个和其后的有效数据程序包时，将它们分开，它们包含的数据被编程到程序包负载地址域中的地址中的应用控制器内。编程后，从控制器内将数据读回并与接收到的数据包中的数据进行比较。成功的核查表明，方案是成功的，导致编程器向传送者发送ACK信号。由于30秒的复位延迟，编程器重新对有效的数据包报头进行测试。
如果编程失败，编程器向传送者发送信号CAN中止文件传输。调制解调器掉线，程序器继续休眠等待下一次呼叫。应用控制在程序模式中被保留，用以阻止它包含的不完整的或无效的程序。
重要的是要注意，无效的数据包永远不会规划到应用程序控制器。这样做将要求错误被纠正之前，编程器中的记忆程序被彻底抹掉，造成先前所有数据的不可恢复。
根据末端文件的接收，编程器向闲置的状态电源返回其控制输出，允许应用程序控制器，开始执行新的程序。然后编程器在三十秒延迟之下重新开始对一个数据包报进行审查。
如果一个有效的数据包在30秒延迟之前接收，另一个只能被接受一个有效的末端文件而终止的程序循环开始执行。
如果复位在收有效末端文件之前终止，那么调制解调器会掉线，编程器停止工作，等待下一次传入。在这种情况下应用控制器被保留在程序设计模式，以防止它执行这个程序。要返回应用程序的正常运行，另一个传入必须被接收，一个有效的程序文件被上传，由末端文件包终止。
毕业论文(设计)科技文献翻译
院 系： 自动化工程学院电子工程系
专 业：
班 级：
姓 名：
指导教师：
2012年4月10日
译文题目：
原稿题目：
原稿出处：
毕业设计（论文） 译文及原稿 51单片机在编程电路中的应用 AT89C51 In-Circuit Programming www.atmel.com/dyn/resources/prod_documents/doc0287.pdf
AT89C51 In-Circuit Programming
This application note illustrates the in-circuit programmability of the Atmel AT89C51 Flash-based microcontroller. Guidelines for the addition of in-circuit programmability to AT89C51 applications are presented along with an application example and the modifications to it required to support in-circuit programming. A method is then shown by which the AT89C51 microcontroller in the application can be reprogrammed remotely, over a commercial telephone line. The circuitry described in this application note supports five volt programming only, requiring the use of an AT89C51-XX-5. The standard AT89C51 requires 12 volts for programming. The software for this application may be obtained by downloading from Atmel’s General Considerations
Circuitry added to support AT89C51 incircuit programming should appear transparent to the application when programming is not taking place.
EA/VPP must be held high during programming. In applications which do not utilize external program memory, this pin may be permanently strapped to VCC. Applications utilizing external program memory require that this pin be held low during normal operation.
RST must be held active during programming. A means must be provided for overriding the
application reset circuit, which typically asserts RST only briefly after power is applied.
PSEN must be held low during programming, but must not be driven during normal
operation.
ALE/PROG is pulsed low during programming, but must not be driven during normal
operation.
During programming, AT89C51 I/O ports are used for the application of mode select,
addresses and data, possibly requiring that the controller be isolated from the application circuitry. How this is done is application dependent and will be addressed here only in general terms.
Port Used for Input
During programming, the controller must be isolated from signals sourced by the
application circuitry. A buffer with threestate outputs might be inserted between the application circuitry and the controller, with the buffer outputs three-stated when programming is enabled. Alternately, a multiplexer might be used to select between signal sources, with signals applied to the controller by either the application circuitry or the programmer circuitry.
Port Used for Output
No circuit changes are required if the application circuitry can tolerate the state changes
which occur at the port during programming. If the prior state of the application circuitry must be maintained during programming, a latch might be inserted between the controller and the application circuitry. The latch is enabled during programming, preserving the state of the application circuitry.
An Application Example
The AT89C51 application shown in Figure 1 is an implementation of a moving display. This
application was selected for its simplicity and ability to show graphically the results of in-circuit reprogramming. The text to be displayed is programmed into the controller as part of its firmware, and cannot be changed without reprogramming the device.
The displayed text is presented in one of two modes selected by the four-position DIP
switch. In the first mode, one character at a time enters the display from the right and moves quickly to the left through each element of the display to its final position in the assembled message. In the second mode, the message moves through the display, from right to left, with the display acting as a window onto the message. This mode is familiar as the method often used in displays of stock prices.
The output consists of four DL1414T, four-digit, 17-segment alphanumeric displays with
integral decoders and drivers. This yields 16 total display elements, each capable of displaying digits 0-9, the upper case alphabet, and some punctuation characters. The displayable character codes are ASCII 20H-5FH.
A power-on reset circuit and a 6-MHz crystal oscillator complete the application. Neither
external program memory nor external data memory is used.
Modifications to the Application to Support
In-Circuit Programming Figure 2 shows the application modified for in-circuit
programming.
It is assumed that the programmer, when inactive, will neither drive nor excessively load the
application. Since the application does not use external program memory, EA/VPP on the controller is connected to VCC. This meets the requirement for programming.
The reset circuit has been modified by the addition of twotransistors, which allow RST on
the controller to be forced high by the programmer.
PSEN and ALE/PROG, unused in the basic application, areunder the direct control of the programmer.
Programming requires programmer access to all of the four AT89C51 I/O ports, as
documented in the data sheet. The programmer is connected directly to those controller pins which are unused by the application, while access to pins used by the application requires special treatment, as explained in the following paragraphs.
The least significant four bits of the address generated by the programmer are multiplexed
onto port one of the controller with the data from the DIP switch. Note that the four resistors added at the switch are not required in the basic application, since the AT89C51 provides internal pull-ups on port one.
During the normal operation of the application, controller ports zero and two provide data
and control signals (respectively) to the displays. During programming and program verification, the programmer asserts control of port zero and part of port two. The programmer is connected to ports zero and two without buffering, since, when inactive, its presence does not affect the normal operation of the application.
A transparent latch has been added between port two of the controller and the display
control inputs. The latch holds the display control signals inactive during programming, which eliminates erratic operation of the displays due to programmer activity on ports zero and two. No isolation of
the display data inputs is required, since data applied to the inputs is ignored when the
control signals are inactive.
The AT89C51 reset circuit, input multiplexer and output latch are controlled by a single
signal generated by the programmer. During programming, reset is asserted, the multiplexer switches inputs, and the latch freezes the display control lines.
To ensure that the display control lines are in a known state before they are latched, an AT89C51 external interrupt is used to allow the programmer to signal the application before asserting reset. The application firmware responds to the interrupt by displaying a message and deactivating the display control lines.
After programming, when reset is deasserted, the controller ports are high as the latch
becomes transparent. Since the display control inputs are inactive high, the display contents are not disturbed until the new program writes the display. Although not essential to this application, it might be imperative in some applications that the state of the peripheral circuitry not be disturbed during programming.
The Programmer
The programmer (Figure 3) generates the addresses, data and control signals necessary to
program the AT89C51 embedded in the application.
The programmer circuitry consists of an AT89C51 and an RS-232 level translator. The
controller runs at 11.0592 MHz, which allows the serial port to operate at a number of standard baud rates. A Maxim MAX232 line driver/receiver produces RS-232 levels at the serial interface while requiring only a five volt supply.
Many of the signals generated by the programmer are connected directly, without buffering,
to the AT89C51 in the application. These signals, when inactive, are not threestated, but are pulled high. The AT89C51 has internal pull-ups of approximately three Kohms on ports one, two and three. Because port zero does not have internal pull-ups, external pull-ups of ten Kohms have been added to permit proper operation of program verification mode. The sample application operates correctly in this environment. If required for compatibility with an application, 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 previously 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 message, 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-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 communications 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 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 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 send-andwait 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 created with the tools in the Intel MCS-51 Software Development 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 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, combined 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 Hayes-compatible, Prometheus 1200 baud modem. During normal operation, the application executes its internal program while the modem and programmer monitor the phone line for incoming 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 complete, 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 incoming 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 command strings over the serial interface, to which the modem responds with Hayes-style ASCII numeric codes. The software is designed for use with Hayes-compatible 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 command, including the command 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 incoming call. When a call is detected, the modem answers and attempts to establish communication 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.
Incoming 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 incoming 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 incoming 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 end-of-file. 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 end-of-file 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 end-of-file packet was received, the programmer asserts the control signals necessary to erase the program memory in the application controller. The programmer then places the controller in programming mode.
The first and subsequent valid data packets are dissected as they are received and the data which they contain is programmed into the application controller at the address indicated in the packet load address field. After programming, the data is read back from the controller and verified against the received packet data. Successful verification indicates that programming was successful, causing the programmer to send ACK to the transmitter. The programmer then resumes polling for a valid packet header, subject to the thirty second reset delay.
If programming fails, the programmer sends CAN to signal the transmitter to abort the file transfer. The modem drops the line and the programmer returns to sleep, waiting for the next call. The application controller is left in programming mode, preventing it from executing the incomplete or invalid program which it contains.
It is important to note that invalid packets are NEVER programmed into the application controller. To do so would require that the program memory in the controller be completely erased before the error could be corrected, causing the non-recoverable loss of all previous program data.
Upon receipt of an end-of-file packet, the programmer returns its control outputs to the inactive, power on state, allowing the application controller to begin execution of the new
program. The programmer then resumes polling for a valid packet header, subject to the thirty second reset delay.
If a valid packet is received prior to the expiration of the thirty second delay, another programming cycle begins, which can only be terminated by the reception of a valid end-of-file packet.
If the reset delay expires prior to the reception of a valid end-of-file packet, the modem will drop the line and the programmer will return to sleep, waiting for the next call. In this case, the application controller is left in programming mode, preventing it from executing its program. To return the application to normal operation, another call must be received, and a valid program file uploaded, terminated by an end-of-file packet.
51单片机在编程电路中的应用
本应用指南说明了Atmel AT89C51是可在线可编程的微控制器。它为电路编程提出了相应的例子，程序的修改需要在线编程的支持。这类显示方法在应用程序中的AT89C51单片机可通过电话线远程控制。该应用指南所描述的电路只支持5v电压下编程。此应用软件可以到Atmel进行下载。
总论
当不在进行程序设计的时候，在电路设计中的AT89C51设计将变得透明化。
在编程期间必须重视EA/VPP这一脚。在不使用外部程序存储器的应用程序中，这脚可能会永久接到VCC。应用程序使用的外部程序存储器要求这一脚为低电平才能正常运行。
RST在编程期间必须为高电平。应该提供一种方法使得电路通入电源以后，使RST代替主要的复位电路起到复位的作用 。
在编程过程中，PSEN必须保持低电平，在正常运行期间绝不能使用。
ALE/ PROG在编程过程中输出低电平，在正常运行期间绝不能使用。
在编程过程中，AT89C51的I / O端口是用于模式应用程序，地址和数据选择的，可能需要该控制器从应用的电路隔离。如何做到这一点取决于应用程序。
输入端口
在编程过程中，控制器必须与应用电路的信号来源隔离。带有三个输出状态的缓冲区会在应用程序之间插入电路和控制器，同时在编程时缓冲区输出三种状态。一个多路复用器可用于信号源之间进行选择，适用于任何一方的应用电路或编程控制器电路的信号。 输出端口
如果应用的电路可以允许端口在编程过程中的状态变化，则不需要改变电路。如果应用电路的状态，必须事先在编程过程中的保持不变，可能在控制器和应用电路中插入锁存。锁存在编程期间是可用的，并保存应用程序的电路状态。
应用实例
应用是该AT89C51一个移动的显示情况。此应用程序有在电路重新编程时将结果以图表的形式显示的简单能力。文本显示被设计作为其硬件的一部分，不能在无改编情况下变化。
显示的文本可在4位DIP开关选择两种模式之一中进行。在第一种模式的时候，进入一个字符从右边显示和快速移动，通过每个元素显示其在最后的装配位置的左侧。在
第二个模式，信息在信息窗口中右到左移动显示。这种模式与常常在股票价格的显示器所使用的方法类似。
输出包括四个DL1414T，4位17段的积分解码器和驱动程序的字母数字显示器。这就产生了16名显示元素，每个数字有0-9的显示能力，是大写字母，标点符号和一些字符。
可显示字符的ASCII 码，范围为20H-5FH。上电复位电路和一个6 MHz的晶体振荡器完成应用软件程序。无论外部程序存储器或外部数据存储器都时可用的。
支持应用程序的修改
据推测，编程器在休眠时，既不会驱动，也不会加载应用程序。由于应用程序不使用外部程序存储器，EA/VPP脚接VCC电源。复位电路被两种转换器改变状态，此转换器允许编程时RST接高电平。在基本应用时未使用的PSEN和ALE/ PROG，是被程序员直接控制的。
编程器的编程需要获得所有数据表中记录的AT89C51的I / O端口。编程器是与那些应用程序未使用的控制器的引脚相连的，而这些应用程序的引脚需要最低有效位的四所产生的地址是可获得的，如下段所述。
由编程器生成的最小的四位地址是与DIP转换的数据在控制器的端口多路复用的 请注意，加在开关上的四个电阻在基本应用中并不是必须的，因为AT89C51的端口上提供一个内部上拉电阻。
在应用程序的正常运作时，控制器端口0，1个分别在显示器上提供数据和控制信号。在编程和程序验证时，编程受端口0和端口2的一部分控制。程序设计器连接端口0和1，没有缓冲，因为，在不活动时，它的存在不影响应用程序的正常运作。
透明锁存器被加在了控制器的两个端口之间做输入控制。锁存持有的显示控制信号在编程过程中不反应，从而消除端口0和2由于程序控制器的活动造成操作失误。显示数据输入是不能被孤立的，因为数据应用到输入被忽略时，控制信号无效。
AT89C51单片机复位电路，输入多路复用器和输出锁存器是由程序控制器生成一个单一的信号来控制的。在编程过程中，复位键生效，多路开关信号输入，以及冻结显示锁存控制线。
为确保控制线显示在已知的状态前锁定，AT89C51的外部中断是用来允许程序控制器在复位之前向应用程序发出信号。应用程序固件响应中断显示一条消息，关闭显示控制线。
编程后，当复位生效，当锁存可视控制器端口输出高电平。由于显示控制输入不为高电平，直到新的程序写入显示器内部不被打乱。虽然这个应用程序是没有必要的，它可能在某些应用中必须指出，在编程过程中不会扰乱外围电路的状态
程序控制器
程序控制器生成的地址，数据和控制信号，对嵌入到程序中的AT89C51有重要作用。 程序控制器电路由一个AT89C51和一个RS - 232电平转换器组成。该控制器运行在11.0592兆HZ，此频率允许串口运行在一个标准波特率下。一个MAXIM MAX232线路驱动器/接收器产生RS - 232水平，而只需要5伏的电源系统。
程序控制器所产生的信号许多只需直接连接到AT89C51，无需缓冲。这些信号，在不活动时，不再是三种状态，但被接高电平。AT89C51的端口1，2，3内部有大约3000欧
姆的上拉电阻，因为端口0没有内部上拉电阻，所以外部10千欧姆的上拉电阻已经加上允许适当的程序认证模式操作。示例应用程序在这种环境下可正常运行。如果有需要的应用程序兼容性，程序发出的信号可能在类似74xx125三态缓冲缓冲区内缓冲。
AT89C51的程序不使用外部程序或数据存储器，这需要牺牲所需要的I / O引脚。这就要求程序代码和I / O缓冲区保持足够小以适合片上存储器。
商业电话线远程编程
编程器和前面描述的显示应用是与通过调制解调器连接在远程站点电话线相连的。使用链接调制解调器的个人电脑，用户可以上传包含一个新的消息的程序，这个信息被变成进了嵌入到应用程序的AT89C51中。当编程完成后，应用程序执行新的程序，它显示新信息。
本地配置
测试配置的本地配置包括一台IBM个人电脑级的计算机连接到与Hayes兼容的，普罗米修斯1200波特的调制解调器。选择此调制解调器，因为它是廉价可得。更快的调制解调器如果需要的话可使用更快速的调制解调器，尽管一旦该文件的传输时间低于1分钟，进一步削减的传输时间不会进一步降低连接时间费用。更高的传输速度的可能优势是在某些高速调制解调器内的自动错误检测和纠正。
Procomm Plus版本2.01，是一个商业数据通信软件包，用于配置调制解调器，建立通讯设置参数，并建立与远程调制解调器的链接。 Procomm Plus包括所谓的宏语言方面，它允许用户编写实现自定义的文件传输协议的脚本。一个简单的脚本编写用来读取一个程序文件的内容，并上传到远程编程器 。
文件传输协议（FTP）的实施，是一个简单的发送和等待的，数据包导向的协议。FTP模式发送和接收的是用数字4和5，如流程图所示。不在流程控制下发射器发送每个数据包，并等待响应。
在计算校验和时那个程序控制器（接收器）读取并剖析了数据包。如果计算出的校验和是有效的，程序员通过发送一个ACK承认此数据包。如果校验和错误，程序员通过发送一个NAK来否定。当接收一个ACK后，发射器发送下一个数据包。如果传送者接收到NAK，它重新发送相同的数据包。以这种方式传输，直到整个文件已被移交。
程序控制器可能通过发送一个CAN来响应数据包，CAN表明一个不可恢复的错误发生，而发射机应立即中止文件传输。如果程序员没有在有限的时间内响应到一个数据包，发送器将重新发送相同的数据包。
发射器将继续重发，直到接收到一个有效的反应，或者，超出文件传输被中止的时间。每个数据包接收和通过程序员验证后，数据包中包含的数据被加载到的AT89C51单片机控制器编程。
编程后，数据从控制器读回并对接收的数据包进行验证。成功的审查表明，成功的程序设计，使程序员发送ACK给传送者。如果编程失败，程序员发送CAN向传送者发送信
号中止文件传输。
简单的FTP减少了AT89C51的程序在编程时使用的内存量。由于AT89C51的编程和擦除时间可以很容易地吸收，FTP发送和等待的性质允许跨包延迟。对程序验证的支持是透明的，不需要明确的命令或结果代码，或转让的其他数据。
上传到程序控制器的文件是用英特尔MCS- 51软件开发包来创建的。在包中包括了MCS - 51宏汇编，MCS - 51单片机Relocator和连接器，以及一个有用的工具，OH。OH将8051绝对目标文件转换为为等效的ASCII十六进制目标文件。
远程配置
在测试配置中的远程配置包括显示应用程序和程序员电路，如前所述，连接到一个与Hayes兼容的普罗米修斯1200波特调制解调器。在正常操作时，应用程序执行其内部程序，而调制解调器和程序员监测来电电话线。
通话被检测到并连接建立后，程序器强迫暂停其程序的执行。新的程序就被下载并嵌入到应用程序中的AT89C51的编程。当编程完成后，应用软件程序获准开始其新的程序执行，而程序控制器返回监督下一个通话的电话线。
程序控制输出无效时程序控制器上电，允许应用程序正常运行。在配置调制解调器接听来电后，程序控制器停止工作。是程序控制器不会影响到程序直到一个新的程序应用程序被下载。
程序员通过发送控制在串行接口上的ASCII命令字符串来控制调制解调器，对此调制解调器响应海斯式调制解调器的ASCII数字代码。该软件是专为与海斯兼容使用的调制解调器，其中包括这里使用的1200普罗米修斯ProModem。
串行接口，程序员通过它连接到调制解调器，它支持两个握手信号，DTR和DSR。上电时，程序控制器判定DTR，断定为DTR后调制解调器响应。如果调制解调器不响应任何命令，包括命令挂断，程序控制器抬高DTR点位，强制调制解调器下降。
当程序控制器停止工作后，监测调制解监听电话线，等待来电呼叫。当检测到输入，调制解调器响应并试图与输入建立通信。如果建立了连接，调制解调器发送一个代码，唤醒程序控制器。程序控制器验证连接的代码，并开始审查有效的数据包报头。
传入数据包必须在少于30秒内到达，否则调制解调器挂断和程序控制器继续停止工作，等待下一次呼叫。如果来电挂断，在得到下一次呼叫之前，三十秒时间必须终止。在复位延迟时间传入是被忽略的。
如果复位延迟时间结束之前收到一个有效的数据包报头，程序控制器将尝试读取和验证传入的数据包。在数据包的接收过程中的任何时间，无效字符，奇偶校验错误或超时的时间内接待字符将导致部分数据包被宣布无效，并丢弃。
两个数据包类型定义：数据和最终文件。数据包包含五个领域，除了包报头，是一个可变长度的数据字段。数据字段包含程序的数据在应用程序中被写入在AT89C51的控制器。负载地址字段中包含数据写入的地址。末端文件包中包含与数据包相同的领域的文件，
但该数据字段是空的。这包类型对程序控制器具有特殊的意义，如下所述。
任何包含有效文种的数据包，记录长度或校验和无效。程序数据在一个无效的数据包被丢弃的处理过程中被积累。编程器给传送者发送一个NAK作为信号数据包的接收和恢复为一个有效的数据包报头审查的警示信号。
第一个有效数据的接收引起编程器中断应用程序控制器。该控制器的中断响应放弃其正在运行的程序，并显示一条消息，表明程序已经被替代。如果这是由于接收了末端文件或者是电源触发从而接收的第一个有效的数据包，运用必要的控制信号清除在应用控制器内的记忆程序。然后编程器在程序模式中放置控制器。
当接收到第一个和其后的有效数据程序包时，将它们分开，它们包含的数据被编程到程序包负载地址域中的地址中的应用控制器内。编程后，从控制器内将数据读回并与接收到的数据包中的数据进行比较。成功的核查表明，方案是成功的，导致编程器向传送者发送ACK信号。由于30秒的复位延迟，编程器重新对有效的数据包报头进行测试。
如果编程失败，编程器向传送者发送信号CAN中止文件传输。调制解调器掉线，程序器继续休眠等待下一次呼叫。应用控制在程序模式中被保留，用以阻止它包含的不完整的或无效的程序。
重要的是要注意，无效的数据包永远不会规划到应用程序控制器。这样做将要求错误被纠正之前，编程器中的记忆程序被彻底抹掉，造成先前所有数据的不可恢复。
根据末端文件的接收，编程器向闲置的状态电源返回其控制输出，允许应用程序控制器，开始执行新的程序。然后编程器在三十秒延迟之下重新开始对一个数据包报进行审查。
如果一个有效的数据包在30秒延迟之前接收，另一个只能被接受一个有效的末端文件而终止的程序循环开始执行。
如果复位在收有效末端文件之前终止，那么调制解调器会掉线，编程器停止工作，等待下一次传入。在这种情况下应用控制器被保留在程序设计模式，以防止它执行这个程序。要返回应用程序的正常运行，另一个传入必须被接收，一个有效的程序文件被上传，由末端文件包终止。