The "U" in "UART" stands for "Universal", but I'm having trouble finding any standard that describes the framing protocol that's used in UART; e.g. the start bit, stop bit, parity options, and baud rates that you see in serial communication clients like minicom or putty.
I understand that there are well known conventions for how these things are done at this point, but standards like RS-232/RS-422/D-subminiature don't seem to describe or suggest anything above the physical signaling.
I've also been having trouble finding a specification for the mapping of serial signaling onto the pinout of a DE9 connector which would let UART hardware from different vendors communicate effectively over a common pinout (like a "null modem" connector).
Is it all accomplished by convention (e.g. by the historical dominance of a few bits of a serial hardware in the marketplace such as 16*50s), or am I missing some standards out there? TIA for the insights!
Best Answer
Wikipedia has a fairly decent description of how the various things like start bits, stop bits, and parity bits work. You can find it here. It does not really describe baud rate. That is just the number of bits per second that are being transmitted, including any start bits, stop bits, and parity bits. As a rough rule-of-thumb, you can assume that it takes about 10 bits to send one byte.
As far as the mapping of the serial lines to the pins of a DE9 connector is concerned, this can be a little confusing at first. When two devices are connected using RS232 and a straight-through cable, one side is the Data Terminal Equipment (DTE) and one side is the Data Communications Equipment (DCE). Regardless of which side is which, the pins on the cable are always named from the standpoint of the DTE. That leads to the confusing situation where the DCE is transmitting on the receive line (because the DTE will receive that signal) and receiving on the transmit line (because that is where the DTE will be transmitting). Most people tend to want to be the DTE so that they do not have to reverse everything in their heads. If you have two DTEs that want to talk to each other, then you need a null modem cable. That basically just swaps various pins so that the transmit data pin on one side connects to the receive data pin on the other side, etc.
The pins on a DE9 connector are as follows:
Most of these pins are there for legacy reasons and it is not likely that you will need them. The three that you will need are Transmit Data (Pin 3), Receive Data (Pin 2) and Ground (Pin 5). If you really are connecting these signals to a DE9 connector, then Transmit Data and Receive Data will connect to the corresponding RS232 signal level pins on your RS232 transceiver chip (like a MAX232) and the logic level side of your RS232 chip will connect to your UART. The Ground pin will connect to the ground pin of the RS232 transceiver chip and to the ground pin of the UART. One thing to keep in mind if you start probing the signals on the DE9 connector with a meter or a scope is that the RS232 transceiver will invert and level shift all of the signals. What was a 0 Volt logic low signal on the UART will become a positive voltage of between 5 and 15 volts on the DE9 connector. What was a logic high signal on the UART will become a negative voltage of between -5 and -15 volts on the DE9 connector.
If you are not really going through a DE9 connector but are really just connecting two UARTs together on the same board, then you can skip the RS232 transceiver chips. An example of where you might run into this is an application where you are connecting a microprocessor to an off-the-shelf radio module that uses a UART interface.
As I said earlier, it is not likely that you will need the other pins. They were mainly needed when remote communications was done via dial-up telephone modems. If you have an application that says that it uses hardware flow control, then some or all of these pins will be needed. Here is what they are for:
RTS and CTS are the most commonly used pins for hardware flow control. If you have two pieces of DTE that want to connect to each other through a null modem cable and use hardware flow control, then the cable will need to connect RTS on one side to CTS on the other, and vice versa. These signal would then run through the RS232 signal level side of your RS232 transceiver chip and the logic side would connect to general purpose IO pins on your microprocessor that would assert the RTS pin when it wanted to communicate and that would monitor the CTS pin to see when the other side of the communications link was ready to communicate.
The alternatives to using hardware flow control are:
Flow control, whether hardware of software, is not something that your UART will handle itself. You will have to have software in your application that handles it if necessary. Many applications do not use low level flow control at all. They run fast enough to handle the low speed communications that happens over UARTs without using flow control to throttle at the low level. At the high level (like "Am I really connected to the device at the far end?"), they use higher level software. An example of this would be some low-powered processor that talked over a serial link to a module that set up an Ethernet link. In that case the high-level question of "Am I connected?" would be handled using things like TCP/IP.