Talk:Universal asynchronous receiver/transmitter

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing (Rated Start-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.


The IBM PC compatibles used National Semiconductor 8250, not the Intel serial chip - because the National chips had built-in programmable baud rate generators. The sucessors were also made by National. This article needs a block diagram of a UART, too. --Wtshymanski 05:58, 13 Apr 2005 (UTC)

I made a diagram of the encoding scheme. I don't know if that's what you meant, though. I'd like it if someone integrated it into the article for me - I fear I would not be able to do it properly. The diagram is here. RT Jones (talk) 00:18, 5 November 2008 (UTC)

RS 232 and so forth[edit]

These standards are discussed in their own articles; the UART may interface to the control lines of an RS 232 interface but doesn't directly generate the voltage levels that go out on the wire. --Wtshymanski 17:49, 17 May 2005 (UTC)

Programming tips for PCs[edit]

"INT 14" is hopelessly IBM-PC specific and not appropriate for a general article on UARTS. I've moved the following lines here but I don't think they belong in this article at all. --Wtshymanski 18:57, 24 February 2006 (UTC)

Common registers[edit]

In most UART chips, registers are grouped into 3 categories:

  • Data Registers: Receiver Buffer Register (RBR), Transmitter Holding Register (THR), Sratchpad Register (SCR)
  • Control Registers: Bitrate Select Register (DLL/DLM), Line Control Register (LCR), Modem Control Register (MCR), Interrupt Enable Register (IER), Interrupt Identification Register (IIR)
  • Status Registers: Line Status Register (LSR), Modem Status Register (MSR)


  • RBR Circuitry in the 8250 chip is programmable to work with 5, 6, 7, or 8 data bits
  • THR is used to hold temporary parallel data waiting to be converted to sequence of bits.
  • On a 8250 chip, the Read/Write SCR is not used
  • LCR is used to control the format of data character
  • LSR is usually the first register read by the microprocessor. This register is used to indicate the errors, if any, that may occur as well as the status of the current operation
  • MCR is used to control the interface with the modem/data set
  • MSR provides the microprocessor with the status of the modem input lines

Also, in some hardware manuals, DLab refers to the last bit (bit 7, or the most significant bit) of the Line Control Register (LCR)

Basic steps in serial port programming involving the UART[edit]

The software will need to initialise the serial port first. After successful initialisation, all operations on the serial port will be passed to and handled by the UART chipset. The basic steps are summarised below:

  • Initialise the serial port. To do this, one need to either call interrupt 14h, or write data to the port via its address directly. It is also important that the software set the data format (using LCR) and the data transfer rate (using MCR).
  • First level (or device-level) handshaking. The software and hardware will indicate their readiness for the operation. This includes sending Data Terminal Ready (DTR) and Data Set Ready (DSR) signals.
  • Second level (or data-level) handshaking. Both parties indicate their readiness for the data transfer process. The software and hardware will send Request To Send (RTS) and Clear To Send (CTS) signals respectively.
  • During the transfer process, both the software and the hardware will need to make sure that THR is empty before sending any data and that RBR is ready before reading any data from it.

Baud vs. bps[edit]

From the article:

Speeds for UARTs are in bits per second (bit/s or bps), although often incorrectly called the baud rate.

From the baud article:

In telecommunications and electronics, baud [...] is a measure of the symbol rate [...] Early modems operated only at one bit per symbol, and so baud rate and bit rate for those devices were equivalent.

Doesn't the second quote contradict the first quote? UARTS are 1 bit per symbol and their baud should therefor be equal to their bps. The first quote should therefor be changed. (I'm just passing by.) 20:40, 15 June 2007 (UTC)

Yes, for a UART, the bit rate and baud rate are the same. For an analog signal employing modulation, as used with modems on the public switched telephone network, more than one bit is usually encoded into a signal, so the baud rate is usually much lower than the bit rate. --Brouhaha 07:11, 16 June 2007 (UTC)


Someone gave a pronunciation of OO-wuh AT. I thought this was odd, so I edited it out. Please replace if I'm wrong - there's an English IPA key at {{IPA-en}}. kwami 06:16, 16 October 2007 (UTC)


An asynchronous transmission sends nothing over the interconnection when the transmitting device has nothing to send; but a synchronous interface must send "pad" characters to maintain synchronism between the receiver and transmitter. The two modes need to be swapped, don't they? Sevcsik 20:12, 27 October 2007 (UTC)

I've tweaked the article to now say "An asynchronous transmission sends no characters over the interconnection when the transmitting device has nothing to send".

Take the case where a USART ran out of things to send, but then 3 normal bit-times later, it was given a "W" to send. All the asynchronous transmitters I've studied send nothing when it had nothing to send -- in some cases "disconnecting" hi-Z from the transmission media, literally sending nothing; in other cases continuously transmitting the "logical 1 stop bit" until it has something else to send. In this case, the UART would send 3 stop bits (rather than the normal 1 stop bit between characters), then when the "W" character suddenly arrived, it would send the 1 start bit, then start sending the data bits that make up the "W". Those "extra" 2 stop bits do help maintain synchronism, but they are not considered an entire "character".

I've seen a few synchronous transmission protocols that would simply stop not transmit those 3 bit clock pulses when it had nothing to send, which seems to contradict the article.

However, all the USARTs I've studied (which is the focus of this article, right?) conform to the article's description. They all continuously transmit bit clock pulses at a constant rate whether or not it has anything to send. If such a synchronous transmitter immediately started sending the "W" 3 bit clocks after the last byte sent, then the receiver would lose the byte alignment. So, in practice, -- in synchronous mode -- the USART immediately must start sending the "pad" character after sending the last real data bit; then it delays sending the "W" until all 8 bits of that pad character have been transmitted, and so maintains byte alignment.

Some higher-level protocols -- especially when communication goes over noisy radio links, rather than hard-wired links -- do send extra "pad" characters to maintain synchronism between the receiver and transmitter, whether or not the underlying hardware uses synchronous or asynchronous transmission. These pad characters -- even when the underlying hardware uses asynchronous transmission, and so does not need them to maintain byte alignment -- helps the higher-level protocol maintain packet alignment (which byte is the start of the packet?), and can also help underlying hardware maintain bit alignment (is this exactly 7 zeros in a row, or 8 zeros?).

Does that answer your question? -- (talk) 17:07, 16 July 2008 (UTC)

My experience with USARTs when they are operating synchronously is that "pad" data is unnecessary. Also, when operating synchronously, they will still include the framing data--the start,stop and (optional) parity bits.

The "pad" characters are unnecessary since, just as when operating asynchronously, the transmission line will be held in the idle state. And, just as when operating asynchronously, a start bit is used to indicate a start send condition.

A USART operating synchronously operates pretty much like a traditional UART with the exception that the two ends of the transmission share the same transmission clock. One end acts as a master and generates a clock signal which it shares with the slave. The slave then uses this external clock signal for synchronization when sending and receiving. The two ends still need to agree on which frame format will be used but no longer need to agree to a baud rate since this is determined by the clock signal generated by the master.

When operating synchronously, the two ends need to agree about which edge of the clock will be used for data sampling and which edge of the clock will be used for changing the data.

The clock signal that the master generates will continue to run even when it (the master) isn't sending data. This is neccessary so that the slave can transmit data to the master. I imagine some implementations may stop the clock if the master doesn't receive data from the slave but I don't know that for certain. -- (talk) 10:53, 24 February 2010 (UTC)


So is UART similar to RAMDAC (in Graphics card and TV Tuner cards), except they translate Digital-to-Analog vs UART that translate parallel-to-serial? --Ramu50 (talk) 17:36, 18 July 2008 (UTC)

No. At least not in any sense stronger than the way sheep are similar to fish, except that they give milk.--Wtshymanski (talk) 20:54, 18 July 2008 (UTC)

roflmao....milk Do they come in Human Breast Milk yogurt form......(slap in the face) joking, jokin --Ramu50 (talk) 00:01, 21 July 2008 (UTC)

Yes. There are several similarities between a UART and a combination of a graphics card RAMDAC and a TV tuner card ADC. Both are integrated circuits. The CPU sends information -- a bitmap image to the buffer RAM on the graphics card, characters to the character buffer inside the UART. The chip then sends that information out at a steady pace, one significant condition at a time. The graphics card also adds a "frame" of HSYNC and VSYNC signals, analogous to the "start" and "stop" framing bits generated by the UART. The signals coming out the UART pins or RAMDAC pins flow into a line driver, and the signals from the line driver in turn typically flow into some kind of D-subminiature connector connected to a cable to the outside world.
At the receiver, incoming signals go through the connector to an analog amplifier; the amplifier output flows into the UART or TV decoder pins.
The TV tuner card uses the HSYNC and VSYNC to synchronize with the transmitter and discover the beginning and the end of the image, analagous to the way the receiving UART uses the framing bits to synchronize with the transmitter and discover the beginning and end of the character. Both systems have a small buffer memory to hold the data. With both systems, the CPU typically pulls the data out of that buffer and stores it on a hard drive.
Both systems often have software handle bigger chunks of data and decide where those chunks begin and end (the beginning and end of a movie for the graphics card / tuner card; the beginning and end of a packet or a file for the UART).
Other than that, I agree with the previous poster that UART vs. RAMDAC are totally different categories of things. :-). -- (talk) 02:33, 21 July 2008 (UTC)
Right. After all, both sheep and fish are found in Scotland. But one must work hard to find the similarities and I doubt they explain the operation of either system well. --Wtshymanski (talk) 01:00, 23 July 2008 (UTC)

must be set for the same ... stop bits for proper operation[edit]

Except for many if not most systems, the stop bits don't have to be the same, because there is nothing timing the stop level. It all gets re-synchronised at the next start bit. That's the beauty of asynchronous communication.

Is there an example of a system that requires the stop bits to be set the same? Change it back if I'm wrong.

Think about this. If the sending end sends a shorter stop bit than the receiver expects, the receiver will never be ready for a new character unless there are intervals betweeen transmitted characters. The reciever needs at least the stop bit time to recognize the end of a character. I suppose if the sender sends a longer stop bit than the reciever expects, this would work, but the link would be slower than necessary. It is more accurate to say the stop bits must match than to leave them out. --Wtshymanski (talk) 18:09, 8 August 2008 (UTC)
The systems that I use don't care about the number of stop bits. Think about it: If it cares about the length of the word, it is a synchronous system, not an asynchronous system. UARTs re-synchronise on the start bit, and if they have got a bit out of sync by the end of the previous byte, they don't care.
I am using physical systems that do not care about the number of stop bits. I know that most current physical devices do not care about the number of stop bits (mechanical tty did not have UARTs anyway).,
What I mean is, change it back if you know that there is a specific Windows implementation which requires matched stop bits, and it would confuse people to put in the truth about current normal implementations. Obviously, most modems don't care about the number of stop bits, but they don't count, because they are auto-synchronising anyway. Assuming you use serial comms on your PC, does setting the stop bits wrong matter? It doesn't on mine: I can do laplink with mis-matched stop bits. It doesn't on any current hardware I'm familiar with, but if in practice it would confuse people I'm willing to let it stand. You need to find an actual example though. —Preceding unsigned comment added by (talk) 03:12, 12 August 2008 (UTC)
It's got nothing to do with Windows, PCs, UARTs or mechanical teletypes - imagine youself as a device watching a serial line. I've just gotten a start bit, I count bit times and now I have my eight (or seven or five or whatever) data bits, I'm expecting two stop bits...suddenly I get another edge. Chaos! Is this a new start bit? What do I do with the old character - it never completed it's frame, I must raise an overrun error. And, at the very least, sending two stop bits on every character when the receiver needs only one is inefficient. If mechanical TTYs didn't care about two stop bits, then why did they send two stop bits? I'd also be wary of anything PC-hosted communications software tells you about how characters are set up - I'd like to see it on a scope, because I think some software lies about what it is doing. I'm restoring it, oh annonymous co-editor. Have you considered logging in? It makes this sort of collabrative discussion much easier. Also then we dont' get those annoying bot-generated signatures. --Wtshymanski (talk) 13:37, 13 August 2008 (UTC)
No examples, no references, no indication that you've read either of the references I provided, but an admirable belief in the righteousness of your cause. What should I try next? You are painting me into a corner here. —Preceding unsigned comment added by (talk) 08:41, 25 August 2008 (UTC)
You must have at least one stop bit to distinguish between the end of this character and the start of a new one. The only reason that more than one stop bit was implemented was to allow the receiver time to process the just-received character and prepare for the next one. This would largely be for historical reasons when chips processed data quite slowly compared to today. Bear in mind that the indeterminate amount of time between characters (since this is an asynchronous system) effectively means that there could be hundreds of "stop bits" before the next character, so there could not be any major reason not to send more stop bits than the receiver is expecting, excepting a slight inefficiency. Thus, sending two stop bits when the receiver is expecting one would not cause problems, unless you count wasting the time spent to send the extra bit as a problem. However sending one stop bit when the receiver is expecting two could cause major problems if (and only if) the hardware actually needed the extra time to process the just-received character. I don't believe the UART would raise a framing error if it didn't get the second stop bit, although I can't find any authoritative reference off-hand. For it to check that it got two stop bits would defeat the purpose of having two stop bits in the first place - to give the UART time to move the completed character into its buffer and notify the processor that the incoming character had arrived. If it could do all that and also check that it got two stop bits it may as well just require one stop bit. From what I have seen, the framing error is simply caused by not having a logic 1 at the point when the stop bit should have arrived (and not that you check for a second logic 1 when the second stop bit should have arrived). Putting it another way, at the point you should be checking for the stop bit value you would be half-way through the stop bit, and thus have half a bit time to prepare for the next start bit. Some of that might be chewed up by slight clock differences between sender and receiver. So, depending on the speed of the chips in question, and the bit rate, you might specify two stop bits to give you that extra time. Zoewyr (talk) 04:12, 3 January 2011 (UTC)


The term "TAE" is mentioned but this term is not defined in this article or in other articles in Wikipedia (in a relevant meaning, anyway). I would love to rectify this but I don't know what's TAE and neither Google "define" nor the free acronyms dictionary had the answer :-( 22:07, 2 September 2008 (UTC)

It caught my attention too. I also couldn't find any other reference to TAE so I checked the page history and it was the last change made. I checked the author's recent contributions and they are all acts of vandalisms. My guess is a vandal got newly assigned that IP (some earlier contributions are a legitimite ones). I reverted the edit. If anybody can come with a good explanation what TAE is, just put it back, please. (talk) 10:13, 10 September 2008 (UTC)