The TL16C550
C UART includes an auto-flow control facility, so that the RTS
handshaking line will tell the other party to stop transmitting as soon as the UART's
FIFO gets full, and the UART will stop transmitting whenever CTS is deasserted. Because this is done by the UART in hardware, it isn't subject to
interrupt latency and is therefore much quicker. The result is that if a pair of linked devices are both using hardware flow control, no data will be lost, whatever the
interrupt latency of the
device drivers.
Related components are
- The TL16C551, which includes a 16C550 UART and a parallel port in a single IC sharing the same processor interface
- The TL16C552, which includes two 16C550 UARTs
- The TL16C554, which includes four 16C550 UARTs
The TL16C750 UART is backwards-compatible with the TL16C450 and TL16C550 types, but adds a 64-deep FIFO mode and can be run faster. It also supports auto-flow control.
The OX16C950 UART adds 128-deep FIFOs and a whole lot more control registers via a complex accessing system. Features include flow control using the DTR and DSR handshaking lines, isochronous serial communication, and finer control of baud rates. It can also run much faster than the TL16C750. OX16C951, OX16C952 and OX16C954 devices also exist, being multi-function chips as in the TL16C55x family.
All the 16C45x, 16C55x and 16C75x chips generate their baud rates as follows: the chips are fed a clock, which is usually at 1.8432 MHz. The device driver sets a 16-bit divisor value by writing to two registers, and a digital frequency divider generates a baud clock by dividing the input clock by this integer divisor. The actual baud rate is then the frequency of this baud clock, divided by 16.
The result of this is:
baud_rate = clock_frequency/(16 x divisor)
From this you can see that the fastest baud rate you can get is one-sixteenth of the UART clock frequency, and the next one down is half of that. You just can't get anything inbetween.
So where does the factor of 16 come from? This is needed for synchronisation of received serial data. When the UART is waiting for a new serial byte to come in, it looks for eight sequential baud-clock cycles with the serial input pin low, and takes this to be the first half of a start bit. It then waits another 16 baud-clock cycles, which should be around the centre of the first data bit. It continues to count 16 baud-clock cycles between sampling the serial input line, until it has read in all the data, parity and stop bits, at which point it goes back to hunting for the next start bit. By using a clock at 16 times the baud rate, the serial data is sampled at within one-sixteenth of the centre of each bit, allowing for the edges of each bit to have moved during the transmission process.