| |
Description
The actual RS-232 receiver circuit.
It consists of three main sub-components:
the controller state machine,
the serial-in parallel-out shift-register,
and the 8-bit output register.
Click the input-switches or type the 'c' and 'd' bindkeys to control the clock and data (RS-232) inputs. A low value on the data-input at the rising edge of the clock signal indicates the start-bit and triggers the controller sequence. Nine clock pulses (8 data-bits and parity bit) later, the contents of the sift-register is read-out and stored into the output-buffer register.
The RX input signal with the RS-232 protocol serial-data stream is directly connected to the controller state-machine and the serial-in shift-register. Both of these sub-components are clocked with the rising edge of the clock signal, whose frequency must match the selected baud-rate.
As used here, the controller subdesign simply counts the next cycles after the start-bit has been detected, and generated a single 'latch' output pulse at the correct time to read-out the shift-register contents in the output buffer. One cycle later, a 'strobe' output pulse signals the arrival of the new character on the parallel output lines to the external world. The extra inverters behind the 'latch' output are used as a delay-line. This is required because the controller and the shift-register are both driven with the same clock, so that the shift-register shifts its data at the same time as the controller generates the 'latch' pulse. Without the extra delay, setup- and hold-time violations would occur fo all flipflops in the output-buffer register.
Warning: The clocking strategy shown here is used for simplicity. It is also broken, and cannot be used reliably in practice. The problem is that the input-data may arrive at any time, without respect for the clock signal of the receiver. If the transitions of the incoming data-signal are very close to the active edge of the clock signal, hazards will occur, and the flipflops in the controller and shift-registers may store the wrong values. Also, there is no way to ensure that the clock signals of the receiver and the (remote) transmitter have exactly the same period. In fact, the RS-232 specs and most actual UART devices provide for some clock mismatch, even up to the order of up to 10 percent.
The solution to the synchronization and clock-skew problem is to use oversampling. That is, the receiver is run at a higher clock frequency than the baud-clock - often, four times the expected baud rate. Also, extra flipflops are inserted into the RX signal, to greatly reduce the probability of metastable behaviour when the input signal and the clock signal change at (almost) the same time. As soon as a high-to-low transition (the start-bit) is detected on the RX line, the controller initiates the sequence to receive one character. However, the RX line is now sampled near the middle of the expected baud-rate period, which guarantees a stable input data value. With four-times oversampling, the data is sampled two receiver clock periods after the start-bit was detected. Extra voting circuits may be used to check that no RX data transitions occur when the data bits (and optional parity bits) are next sampled.
Run the applet | Run the editor (via Webstart)