Site version is  Page last edited on 20030727 All links last checked on 20030727 Have this site translated Other mirror sites Forum

About UART's and selecting one for a project.

UARTs (Universal Asynchronous Receiver Transmitters) or SIO*'s (Serial Input Output) or ACIA*'s (Asynchronous Communication Interface Adapters) are used to send data serially over one single line per direction.

The protocol that is used is simple:

• The line is normally high.
• Before each byte a low bit is send.
• The data bits are send with the least significant bit first, with the line being high for a 1 and low for a 0.
• A parity bit is added for protection.
• One or two stop high bits are added. But this is equal to an idle line, so this is just the space, before the next byte may be send.

There is also a synchronous protocol and many UART's can handle this too, but it is seldomly used since it requires both sides to have synchronized clocks.

UART's are generally used with RS-232 hardware which converts the 5V to -12V and the 0V to +12V and vice-versa. If -12V and +12V is available in a system, then an 1488 and 1489 are generally used as driver and receiver.
Otherwise the MAX232 is a good solution because it generates it's own -12V and +12V from 0 and 5V and because it integrates both driver and receiver.

Early UART's like General Instruments' AY5-1013A used to be stand-alone devices which could be used in processorless printers for example. Later UART's had a processor interface which means that the processor can instruct the UART what to do by filling memory-like registers with commands and settings.

Other (mainly compatible) stand-alone UART's are:
AMI	S1883
GI	AY3-1015, AY5-1013
Philips/Signetics	2536
SMC	COM2017, COM2502, COM8017, COM8502
TI	TMS6011
WD	TR1402, TR1602

If you need a UART for some project the 16450, 16550, 2661, 2681, 2698, 6551(?), 6850, 68661(?), 68681, 8250(+), 8251 or Z8530 are likely candidates. Each with their own pro's and con's.

The main design choices are, I guess:

• How much UARTs per chip: 1,2,4,8?
• Does it have a internal baudrate* generator?
• Kind of bus type: Intel/Motorola/specific?
• How much board space does it need?

Most controllers today already contain one UART and sometimes two. If you need an external UART, you will likely choose a UART with an internal Baudrate* generator unless you will use it for Midi* for example which always operates at the same Baudrate* (32 kbps (?)).

In some UART's you can choose from a preprogrammed range of external clock to Baudrate* divisors, which forces you to supply the correct external clock rate. More universal UART's let you program the divisor from 1 to 64k, with sometimes even an added predivisor with a factor of 1, 4, 16 or 64.

If you need a single UART, have a look at the 8250(+), which was used in the PC, so can easily be found second hand at PC-fairs etc. (Just buy a cheap PC-com-board with one on it. When you want a dual* UART have a look at the 'industry standard' Z8530. If you need a lot of UART channels, try the 2698 Octal* UART, which contains four 2681 Dual* UART's or the very recent OX10864 from Oxford Semiconductor.

Latest developments

Date:    19951214
From:    Ulf Samuelsson
To:      ganswijk@xs4all.nl
Subject: New UART

NSC is releasing a new UART for Infrared communication.
This is the PC87108.
It is upwards compatible with the NS16550 UART but will allow higher speed
than the typical 115kbps available with the NS16550.

Best Regards
Ulf Samuelsson

UART's on the net

Date:    19960306
From:    yishai kagan
To:      ganswijk@xs4all.nl
Subject: Startech
X-Url:   www.hitex.com/chipdir/f/uart.htm

If you look at the Exar (www.exar.com/) page, you will find some great
UARTs made by Startech: 16C654, 68C654

Serial interface with serial interface from Maxim!

More news from Maxim

The newest and fastest PC UART

Date:    19970618
From:    James Lewis <oxsemi2@oxsemi2.demon.co.uk>
To:      ganswijk@xs4all.nl
Subject: UARTs

Please take a look at Oxford Semiconductor's revised web pages. We now
offer the world's fastest 8-channel UART (OX10864) and the world's
fastest PC compatible 2-channel UART (OX16C952).

Full information is on our web site at:

        www.oxsemi.com/

--
JAMES LEWIS
Marketing Director
==========================================================
Oxford Semiconductor Ltd        Tel:    +44 (0)1235 861461
68 Milton Park                  Fax:    +44 (0)1235 821141
Abingdon
Oxfordshire OX14 4RX            E-mail: james@oxsemi.com
United Kingdom                  www.oxsemi.com/
==========================================================

Date:    20000223
From:    Jaap van Ganswijk [mailto:ganswijk@xs4all.nl]
To:      Ewen Dave
Subject: Re: Chip Question

On 20000223 Ewen Dave wrote:

Would you happen to know if there is a way to tell when a 16550-compatible UART is ready to accept one more TX character? I am looking at the 16550 status bits and it seems you can tell that the TX fifo is empty but there is no way to tell when it is full. This seems strange to me.

You seem to be right. I just checked the datasheet again. Was some years ago that I programmed for it and that was mostly before the FIFO* was commonly present in PC's...

It seems to be that the philosophy is that you only get an interrupt when the write FIFO* is completely empty. Then you can fill it guaranteed with 16 (or in later versions 64) bytes so you don't have to poll during filling it, which makes the driver a lot more efficient.

This philosophy is different from the philosophy used in the case of the receiving FIFO*, in the case of receiving it may be that during the interrupt routine is started more bytes may have to be put in the receiver FIFO*. Therefore it's possible to set a level of fullness at which an interrupt is generated.

The same principe with a threshold might also been used in the case of the transmit FIFO*, but it's not necessary as with the receiving FIFO*, since output can generally wait... So they choose between using the threshold system (which might give a slightly higher throughput) or the easy of always being able to put 16 bytes in the FIFO* once an interrupt occurs (which saves a lot of cycles in the interrupt routine).

When you're using the UART polled, it seems a bit silly, but on the other hand: Serious applications only use the UART in interruption mode... A polling CPU* is always fast enough to fill the transmit register anyway and doesn't really need a FIFO*. Condider also that there is already a buffer for the transmitter: While one byte is being shifted out, you can already fill the transmitter holding register. Even at 115k bps* you have about 100 us to do this, which is a long time in MCU* terms when it's polling.

From: Jaap van Ganswijk

On 20000224 Ewen Dave wrote:

Thank you for the response. I guess it is as you say -- everyone uses interrupts. I just don't see as much need for TX interrupts as I do for RX interrupts.

You're right. When I was porting my software on a new embedded platform I would do it in the following order:

• both polled
• input on interrupt basis
• both on interrupt basis (when needed)

The reason for doing the output on interrupt basis also can for example be that it will not tie up the foreground process, which may be needed for other processes. However once the software UART output buffer is full, it will slow down the foreground anyway since it will start polling the output buffer for available space...

See also

Tip from Beverly Wade of InnovASIC (on 20010227):

Here's an InnovASIC UART product to add to your list:

Part Number = IA82510

Part Name = Asynchronous Serial Controller

Description: UART for modem* and serial port communications, 288K Baud* Rate, Error Detector, MCS-51 Protocol Support(Compatible with Intel 82510)

SY6551 and CDP65C51