I am learning about old computers, and I have found the following image from this article:
They use the terms "UART" instead of "serial port" and "UART driver" instead of "serial port driver", I have also read the same thing on other articles.
Why do they do that?
A UART (Universal Asynchronous Receiver-Transmitter) is a particular kind of hardware device that uses digital sampling to convert serial data that uses embedded start and stop bits for synchronization into and from parallel data. Not all forms of serial communication use start and stop bits, and not all devices that use this form of serial communication uses some sort of UART hardware. A serial port could be something completely different.
In traditional asynchronous serial communication, data has transmitted a series of "mark" and "space" values. How these values are represented depends on the communication medium, for example RS-232C defines mark as being a voltage in the range of -3V to -15V, while space is defined when voltage is in the range of +3V to +15V. In order to know where each byte (or character) starts and ends, each byte is prefixed with a space value (start bit) that indicates the start of the byte, and suffixed with one or more mark values (stop bits) that indicate the end of a byte. In between the start and stop bits each byte is transmitted as a series of mark (1) and space (0) values.
The start and stop bits help in providing the necessary synchronization for this form of serial communication to work by just transmitting mark and space values without needing precisely synchronized clocks or by also transmitting a clock separately. The start bit lets the receiver know that a fixed number of bits will follow at a given rate. The transmitter and receiver must be configured beforehand to use the same parameters, the same number of bits in a byte, the same number of stop bits, and the same baud rate. Once the receiver has received the start bit it samples the communication line at the specified baud rate to obtain each bit of the transmitted byte in sequence.
The receiver ignores the stop bit, but it performs two functions. First, it gives time for the receiver to prepare for the next byte, and this was crucial on old mechanical devices like teletypes. Secondly, it guarantees that the start bit, a space value, is preceded by a mark value, meaning each transmitted byte is preceded by a transition from mark to space. This allows the receiver to resynchronize with the serial data byte steam if starts receiving in the middle of a byte being transmitted or noise or other problem causes it to lose synchronization.
Since the start bit in fact causes the receiver to resynchronize with the transmitter every time a byte is transmitted, this means the receiver doesn't need to be sampling each bit at precisely the same rate as the transmitter is sending them. Since normally only 10 or fewer bits, including start, data, and stop bits, are transmitted before this resynchronization occurs even a relatively large 5% difference in transmitting and receiving baud rates won't cause errors.
A UART does everything necessary to implement asynchronous serial communication in hardware and does so digitally (other earlier asynchronous hardware implementations used analog timing circuits that needed manual calibration.) However, it's also possible to implement an asynchronous serial device in software using a technique called bit banging. This was done on old computers like the Commodore 64 in order to save money and is still done from time to time in modern embedded applications for the same reason.
Finally, there are other ways of transmitting data serially, like synchronous serial communication methods where a separate clock signal is transmitted alongside the serial data. In fact, many modern computer interfaces, like USB, Serial ATA, and PCI Express are actually serial devices. So while a "serial port" normally refers to an asynchronous serial device usually implemented with some sort of UART, strictly speaking, it could potentially mean a wide range of devices. By calling the hardware device used a "UART", and the software driver for it a "UART driver" the diagram you've shown in your question is actually more precise about what it's describing.
Simply, a UART is a serial port, but a serial port is not necessarily a UART.
Serial port is a general term for anything serial, without further specification, while a UART defines a transceiver for a specific asynchronous format. That Ports using asynchronous protocols like RS232 or TTY are colloquially simplified as serial port shouldn't promote technical documentation to be as unspecific.
On a more technical side, a SPI is also a serial port, but I doubt that any UART driver will be able to handle its specifications.
UART is an initialism for "Universal Asynchronous Receiver/Transmitter", the manufacturer's name for the 8250 that was used in the original PC (and elsewhere) to run the serial port. That initialism continued to be used when labelling the 16550 which succeeded the 8250 and the term has attached itself to the serial port ever since.
tty is nearly synonymous with 'console', despite almost nobody having seen a teletype in years and a teletype not being required for a console.
– Tommy
Nov 14 '17 at 04:14
Adding to the other answers:
Other than distinguishing pure asynchronous operation from asynchronous/synchronous transmission/receive (opposing the term USART), the term could also have been used for other reasons:
A denomination of UART serial port could distinguish your product from a non-UART serial port as "has some chip that relieves the CPU from the burden of transmitting bits".
The Sinclair ZX Spectrum with its IF1 had, for example, a (asynchronous) serial port that was bit-banged by the CPU, so kept the CPU pretty busy while transmitting/receiving, which also limited the maximum speed at which this port could operate (while keeping hardware cost at a limit).
UARTs instead were known to reach acceptable bandwidth transmissions and known to relieve the CPU from bit transmission and were thus a unique selling point.
The UART is one of the functional blocks required to implement what was traditionally called a serial port (aka RS-232 port) - the other one is an RS-232 line driver / receiver. Originally the UART and line driver/receiver were separate chips, but more recently they are just blocks within a chipset.
So the serial port is the entire set of functionality (or the connector, depending on how you view things :)) while the UART is one of the pieces that makes it work.
Your article is wrong. A UART is a specific device (universal asynchronous receiver/transmitter) dealing with all the timing (and some buffering and framing error detection) of an asynchronous serial line transmission. They are usually employed for serving serial lines since they take load and timing requirements off the main CPU.
However, they do not include the line level drivers: those are conspicuously absent from your diagram. For RS232, eventually Maxim came up with notorious drivers working at 5V and including the respective switching voltage multipliers/inverters at a time switching drivers were kind of unusual (outside of memory chips where they started being a thing with, uh, 4164 dynamic RAM chips and 2716 EPROMs? since the 12V and -5V requirements of earlier RAM and EPROM chips were becoming a nuisance because of pin count and PCB layout).
A UART is a Univeral Asynchronous Receiver and Transmitter. It is an electronic circuit which handles communication over an asynchronous serial interface - very often an RS232 interface.
Serial Port or RS232 is a specification for serial communications between a DCE and DTE (For example communication between computer and modem); it defines electrical characteristics, the 25-way 'D' connector and the various functions of the various signal lines.
Serial ports include line drivers, whereas UARTs are used to frame asynchronous data streams. UARTs precede line drivers.
"UART driver" is not even hardware -- it is software -- notice that it is part of the kernel in your diagram, so -- they are referring to the operating system there. In IBM PCs that ran DOS -- that was not the case. There were a couple of BIOS service calls in the firmware, but -- the 8250 style UART was not controlled by the "kernel" at all -- it was controlled largely by user written code, or a third party driver until DOS 5.0 / Win3.1 -- Many flavors of BASIC contained routines for serial communications at that time.
Your diagram also refers to TTYs -- teletypes -- which -- are primarily driven by RS-232 as well.
