1、科技文章摘译 英文原文 Determining Clock Accuracy Requirements for UART Communications Abstract: This application note discusses the timing requirements for the commonly used serial asynchronous communications protocol implemented in UARTs, and shows how to determine the tolerance for the UART clock source at
2、both ends of an asynchronous link. Background The RS-232 specification dates back to 1962, when it was first released by the EIA (Electronic Industries Association). The specification has changed over time, incorporating higher data rates and closing the compatibility gaps between TIA (Telecommunica
3、tion Industry Association) and international (ITU, ISO) standards. The current version of the RS-232 specification is EIA/TIA-232-F, dated October 1997. The protocol benefited from the availability of MSI ICs from the late 1970s which had the complexity to handle the standard at reasonable cost. The
4、se ICs are generically called UARTs (Universal Asynchronous Receive Transmit). Many LSI ICs (including microcontrollers) now include the functionality. As is often the case, the availability of UARTs drove the industry to use the RS-232 serial protocol in non-RS-232 ways. Common examples are RS-485
5、transmissions, opto-isolated transmissions, and transmissions using a single-ended physical layer (i.e. 0 - 3.3V instead of 5V or 10V). This note covers the general timing aspects of the serial interface, not application nuances of handshaking or the physical layer, and so is applicable to all gener
6、alized UART applications. UART Timing A typical UART frame is shown in Figure 1. It comprises a Start bit, 8 data bits, and a Stop bit. Other variants are also possible in RS-232 applications - the data packet could be 5, 6, or 7 bits long, there could be 2 Stop bits, and a Parity bit could be inser
7、ted between the data packet and the Stop bit for rudimentary error detection. Figure 1 shows the signaling as seen at a UARTs TXD (Transmit Data) or RXD (Receive Data) pins. RS-232 bus drivers invert as well as level shift, so a logic 1 is a negative voltage on the bus, and a logic 0 is a positive v
8、oltage. Figure 1.A typical UART data frame. When two UARTs communicate, it is a given that both transmitter and receiver know the signaling speed. The receiver doesnt know when a packet will be sent, with respect to the receiver clock, hence the protocol is termed asynchronous. The receiver circuitr
9、y is correspondingly more complex than that of the transmitter. While the transmitter simply has to shuffle out a frame of data at a defined bit rate, the receiver has to recognize the start of the frame to synchronize itself, and therefore determine the best data sampling point for the bitstream. F
10、igure 2 shows a common method used by UART receivers to synchronize to a received frame. The receive UART uses a clock which is 16 times the data rate. A new frame is recognized by the falling edge at the beginning of the active-low Start bit, when the signal changes from the active-high Stop bit or
11、 bus idle condition. The receive UART resets its counters on this falling edge, and expects mid Start bit to occur after 8 clock cycles, and the mid point of each subsequent bit to appear every 16 clock cycles thereafter. The Start bit is typically sampled at the mid bit time to check that the level
12、 is still low, to ensure that the detected falling edge was a Start bit not a noise spike. Another common improvement is to sample each bit not simply once at the mid bit position (clock count 8 out of 16), but three times (clock counts 7, 8, and 9 out of 16). Figure 2. UART receive frame synchroniz
13、ation and data sampling points. Timing Accuracy So the question is: how accurate does the receive UART clock have to be to be sure of receiving data correctly? (Actually, a better question is to ask how far different the transmit and receive UART clocks can be, since the absolute clock rate is unimp
14、ortant for the purposes of accurate reception. More on this later.) To answer this, the first point to understand is that because the UART receiver synchronizes itself to the start of each and every frame, we only care about accurate data sampling during one frame. There isnt any buildup of error be
15、yond a frames Stop bit, which simplifies analysis because we only have to consider one frame as the worst case. When do we get a timing error due to transmit-receive clock mismatch? Well, we are attempting to sample each bit at the mid point (Figure 2). If we sample a bit a bit period too early or t
16、oo late, we will sample at the bit transition and have problems (Figure 3). Figure 3. UART receive sampling range. In reality, we cant (reliably) sample close to the bit transition point. The dominant reason for this is the finite (and typically slow) transmission rise and fall times, made even slow
17、er if overly capacitive cabling is used. A long bus incurs high attenuation, reducing noise margin, making it more important to sample when the bit level has settled. It is difficult to assess a worst case acceptable sampling range across a bits period in a quantitive manner. EIA/TIA-232-F does spec
18、ify a 4% of bit period maximum slew time for a transmission, but this is difficult to achieve for long runs at 192k/bits-1. But let us define two data path scenarios for the purpose of this note. Consider a nasty scenario which can only be sampled reliably within the middle 50% of the bit time (Figu
19、re 4). This could equate to a long, capacitive RS-232 run. The normal scenario can be sampled within the middle 75% of the bit time (Figure 5), equating to a relatively benign bus (such as a metre or two run with buffered CMOS logic levels or an RS-485 differential pair) within an equipment chassis.
