Skip to main content
shopping_basket Basket 0
Log in

Catching a Bus: Basic Serial Communication Part 1, the UART

Image credit: Simon A. Eugster

Most modern peripheral device chips, such as sensors and motor drivers, communicate with a controller via a serial data bus. Microcontrollers usually support one or more of three basic types: UART, SPI and I2C. How do they work and which to choose?

Early Telegraphy

In the days before voice could be converted to an (analogue) electrical signal and conveyed over long distances by wire, there was digital telegraphy. Well, sort of. A human operator sent text characters encoded in groups of short and long current pulses (dots and dashes) by tapping a sprung-loaded switch known as a Morse key. At the receiving end, a solenoid-driven ink stylus reproduced these ‘marks and spaces’ on paper tape fed from a roll by a clockwork motor. Alternatively, the ticks and tocks of the solenoid could be interpreted directly by a trained Morse code telegraphist. I won’t cover the very similar ‘Ticker-tape’ systems designed for stock market price communication as these are now well and truly obsolete.

Keyboards and printers

Sending and reading messages in Morse code was never going to catch on as a means of mass communication because it’s too slow and requires a trained operator at each end. Though when combined with long-range HF radio, it’s great for sending three-character messages like “SOS” from ships in distress. What was needed was a means of replacing the Morse keys with office typewriter keyboards. A way had to be found for converting a key press to a coded stream of electrical pulses, which could then be decoded and converted to a character printed on paper at the receiving end. All this had to be achieved with the only technology available at the time: mechanical mechanisms driven by electric motors and solenoids. No electronics. The electromechanical Asynchronous Receiver Transmitter was born.

Asynchronous communication and the UART

To make life easier, each character is represented by a fixed-length 5-bit binary code (unlike Morse) and the distinction between ‘zeros’ and ‘ones’ based on voltage or current level, not pulse length (Fig.1). For signalling purposes each character is preceded by a Start bit - always a zero, and ends with a Stop bit (always a one). The signal line is held in the ‘one’ state when nothing is being transmitted.


One feature of all types of digital communication system is that the clock signal which puts the data on the line, in the serial case one bit at a time, is precisely synchronised with the receiver’s clock taking it off. This can be achieved in one of two ways:

  • The transmitter clock is supplied to the receiver via another wire.
  • The receiver ‘recovers’ the clock from the data signal itself.


The first method is used over short distances where there is no problem providing an extra wire. For example, when linking a peripheral device to a microcontroller on the same PCB. The SPI bus which I’ll talk about next time is frequently used in this situation.

The second approach is invariably used in wireless systems to avoid dedicating a separate frequency channel to the clock signal. It was also required in early telegraphic systems which used existing long-distance cables where adding extra wires would have been prohibitively expensive. Sending digital messages between two devices that don’t share the same clock signal is called Asynchronous communication and the peripheral interface hardware present in most microcontrollers is the Universal Asynchronous Receiver-Transmitter or UART (pronounced ‘you-art’ for short).

The (Non-)Standard Asynchronous Serial Bus

At this point I have to say that there is no complete ‘standard’ for this type of serial digital communication. The earliest, and now obsolete signalling format is shown in Fig.1a, based on the 5-bit Baudot code (plus a number of variants). In the 1960’s a 7-bit code was devised – American Standard Code for Information Interchange or ASCII code. Although developed for telegraphic use, it quickly became the standard for textual data stored on computers and has been ever since. Fig.1b shows the similarity in signal format between an ASCII character and its 5-bit predecessor. The addition of an optional Parity bit for the purpose of error checking brings the total number of bits per character to eight – plus the start and stop bits. The format shown in Fig.1c is very commonly used nowadays for short links between microcontroller chips and peripheral devices often mounted on the same board. The parity bit is replaced by a further data bit so a complete byte of binary data, i.e. not necessarily ASCII-coded text may be transmitted.

Start and Stop

So, what function do the Start and Stop bits have – apart from marking the beginning and end of a short stream of data bits? As I mentioned above, the early teleprinters contained no electronics so the signal format was developed based on the limitations of electromechanics. Somewhat simplified, this is how a stream of electrical pulses were converted to a character printed on a roll of paper:

  • The leading (falling) edge of the Start bit causes the wiper arm of a five-contact rotary switch driven by an electric motor to begin moving. Its speed is matched to the data rate.
  • The incoming signal line is ‘sampled’ as the wiper crosses the first contact and the value of bit 0 recorded as the position, up or down of a metal pin. The other four bits are recorded in turn on other pins as the wiper rotates.
  • After this ‘serial to parallel conversion’ has taken place, a mechanical ‘decoder’ causes an incredibly complicated series of levers and cranks to rotate and lift the print head into the correct position, before bashing it through an inked ribbon onto the paper.
  • The Stop bits represent the minimum time that must pass before the Start bit of another character may be accepted. Hence the ‘one and a half’ bits for 5-bit machines and two for ASCII-based printers. Of course, an electronic UART doesn't really need anywhere near even a 1-bit interval.


Note how synchronisation of transmitter and distant receiver is achieved at the character level when the Start bit triggers the mechanism. The system assumes that the motors (‘clocks’) at each end are governed to run at approximately the same speed. The long bit intervals resulting from a low baud rate means that the receiver timing will not have drifted far enough to cause an error by the time the Stop bit arrives. The same principle applies when using electronic circuits, except that tighter tolerances on the clock signals mean that maximum baud rates are higher.

UART Communication today

Those old teleprinters of the past were fantastic examples of precision mechanical engineering, but electronics and the ‘glass terminal’ (CRT display and keyboard) have swept them all away. All except the signalling format that is. One of the first large-scale integrated (LSI) chips produced in the 1970’s was for an electronic UART. At its heart the device consists of two shift registers: a parallel-in serial-out type for transmission and a serial-in parallel-out for reception. To cater for all the variations in format in use at the time, even these early devices could be programmed for character length, number of stop bits and selection of even, odd or no parity. The data or baud rate was set by an external oscillator connected to a device pin. The receiver and transmitter were completely independent and could even operate with different baud rates! Hence the ‘standard’ rate available of 75 baud for the relatively slow humans typing on the keyboard and 1200 for the electronic display unit. For modern inter-chip communication you’re unlikely to use less than 9600 baud. This programmability of the serial interface for different signal formats explains the ‘U’ for Universal in the term UART. Stand-alone UART chips still are available, but just about every modern microcontroller chip has at least one built-in.

The RS-232 standard

Now we come to one of the most mis-used terms in electronic communications: RS-232. You will frequently find chip or module manufacturers claim on their datasheets that the UART channel on their device conforms to it. It rarely does. The international standard RS-232 defines the electrical characteristics of the serial link such as signalling voltage, line impedance and the functionality of all the 25 signals (!) that could be used in a full implementation. It does not specify data formats, baud rates, error protocols or a maximum cable length. On chips with an integral UART you will usually find the two serial I/O pins marked as Tx and Rx, sometimes accompanied by ‘handshaking’ pins RTS and CTS. These operate with normal logic-level voltages and not the higher bipolar voltages specified by the RS-232 standard. The standard applies to low-speed serial cable links (up to about 20 kBaud) between pieces of equipment no more than a few metres apart.


Most likely your connection will only be few centimetres long, so no other interface circuits are required (Fig.2a). On the other hand, if a project involves a serial connection to a PC via its 9-pin COM socket for example, then an RS-232 interface chip (Fig.2b) will be needed to convert your board's UART logic-level voltage to the PC's bipolar signalling level of around ±12 volts. PC COM ports will often work with just the logic voltage – but this falls into the category of ‘Things-You-Might-Get-Away-With’ and is not recommended.


A big disadvantage with a transmitter operating independently of the receiver is that it can just begin sending data even if the receiving device is not ready for it. With a low baud rate and at least one buffer register at each end, this kind of operation is practical. It’s called ‘double-buffering’ on a UART datasheet, and hence a simple bi-directional asynchronous link may only need three wires for Tx, Rx and Ground. At high data rates, two ‘handshaking’ signals defined in the RS-232 standard, usually Request to Send (RTS) output and Clear to Send (CTS) input will be required to provide ‘Flow Control’. These are shown as dotted lines in Fig.2.

Driver code for an MCU UART

Here is a code fragment for basic UART I/O functions on a Microchip dSPIC33 DSC chip. The initial setting up routine is not shown, but you can see how the attachment of Start/Stop bits, etc. to the data byte is all handled by the hardware making the driver routines very small indeed.



This form of serial communication has been superceded long ago by newer, faster technologies such as SPI, I2C and USB. But it still hangs on as a simple to implement solution where speed is not an issue and all you need is a one-to-one, non-networked connection.

For those interested in electromechanical communication, here is a glimpse of the past showing how a teleprinter’s Baud Rate Generator frequency was adjusted….

A somewhat scruffy but otherwise in full working order Creed 75 teleprinter of about 1960 vintage. Capable of printing 10 characters per second from a 75 baud asynchronous serial link. Originally designed for telegraphy work, they were frequently used as keyboard terminals on British computers of the time.

Rear view with the casing removed. The motor underneath the paper roll governed the signal timing and provided the force to move the huge number of levers and cranks making up the mechanical ‘logic’ system. The speed governor is in that drum with the white patch on the right-hand motor shaft. It’s a simple spring-loaded switch that opens when the rotational speed exceeds the set value.

Baud rate timing adjustment – electromechanical style. This special tool is a tuning fork with a shutter on the end which opens and closes at fixed frequency when the fork is struck.

The vibrating fork is held in front of the rotating governor and the white bands observed through the shutter. This is a mechanical stroboscope and the drum will appear stationary if the speed is correct. If not, then an adjustment is made to the screw in the black band on the drum.

More Content in this series

Serial Peripheral Interface (SPI)

Prototyping a wireless robot control box

I2C communication interface

If you're stuck for something to do, follow my posts on Twitter. I link to interesting articles on new electronics and related technologies, retweeting posts I spot about robots, space exploration and other issues.

Engineer, PhD, lecturer, freelance technical writer, blogger & tweeter interested in robots, AI, planetary explorers and all things electronic. STEM ambassador. Designed, built and programmed my first microcomputer in 1976. Still learning, still building, still coding today.


March 17, 2020 11:35

Thanks for the excellent write-up. I also had the opportunity to work with UART on FPGA quite recently where I depicted the 'critical' role of bit sampling on the receiver side:

0 Votes

March 17, 2020 17:01

@stavros Thanks! I was not aware of this 'triple-sampling' technique.

March 9, 2020 13:15

Thanks. This takes me back to the days when we connected teleprinters to HF radio with things called an Elmux to manage the links. Some nice explanations on the RS-232. I find it valuable.

0 Votes

March 9, 2020 11:07

As you explained, the UART defines the nature of the encoding of parallel data into a serial stream of ones and zeroes with specific timing, and RS-232 defines one method of representation of those ones and zeroes as signal levels on transmit and receive data lines, as well as some handshaking signals to manage the flow of information. A logic 1 (Mark) is represented as a negative voltage at least 3 volts negative with respect to ground, and a logic 0 (Space) is represented as a positive voltage at least 3 volts above ground. The RS-232 output drivers usually have a source impedance of 300 ohms, limiting the current in case of shorts to ground (which should still be avoided)!

There are also several other standards methods for representing binary serial data as electrical signals. One of the early ones is a 20 ma current loop. This became a de facto standard due to its use on the Model 33 Teletype, released commercially in 1963.
As its name indicates, the 20ma current loop represents the data as changes in current, rather than a change in voltage. A current of 20ma signifies a logic 1 (Mark), and a current of 0 (open circuit) signifies a logic 0. This method has the advantage of working over
distances up to several thousand feet at 19,200 baud, and even longer at lower baud rates. The receiver can easily be an optocoupler with logic level output, adding the benefit of voltage isolation between the transmitting equipment and the receiving equipment. The disadvantage is lack of a clear standard for electrical and mechanical implementation. The current source could be anywhere in the loop - at the transmitter, or at the receiver, so the installer needed to know a little bit about the equipment to be connected.

The other prevalent alternatives to RS-232 use balanced data lines, with a two wire twisted pair carrying the transmitted data, instead of a single wire. The receiver looks at the polarity of the difference between the two signal wires, instead of the voltage on a single wire with respect to ground. This gives greater noise immunity, as any noise gets coupled to both wires of the pair nearly equally, and when the receiver takes the difference between them, the noise in one line cancels out the noise in the other line, leaving just the signal. RS-485 is a common implementation. Like the 0-20ma standard, it is capable of handling relatively long (1/4 mile) distances. The combination of long distance plus high noise immunity makes it very popular in industrial settings like manufacturing plants or water treatment facilities. It is also capable of a fair bit of common mode voltage, and of driving many receivers off a single transmitter.

0 Votes

March 9, 2020 11:07

Bill, you mentioned DTR and DSR in your reply to Boss. The RS-232 DTR (Data Terminal Ready) and DSR (Data Set Ready), along with CD (Carrier Detect) and RI (Ring Detect) signals provided management of the interface with the modem. The first two allowed the terminal (or computer) and modem to know when the other was present and powered up. The carrier detect let the terminal or computer know when the modem had an active connection to the modem on the far end of the phone or other communications line. And the ring indicator signal provided indication of an incoming phone call. These four signals, along with TX and RX data and RTS, CTS, and Ground, round out the lines present on a 9-pin serial port.
Note that it wasn't always a mis-use for a program not to communicate if it didn't see the DSR signal. It all depends on context. If a communication link is local, with no modems / phone lines present, then RTS / CTS provide a sufficient mechanism for managing the data flow. But if it is a remote communications link, it is entirely appropriate for software to make sure the modem is powered up and ready before sending data to the modem (which may include commands to the modem itself), and further to require detection of carrier before transmitting data intended for the remote end.
Since the same software would sometimes be used for both link types, a "null modem" connector or jumper wires were used on local lines. This wiring fed the Data Terminal Ready signal from the terminal or computer directly back to the Data Set Ready and Carrier Detect lines, so as soon as the computer or terminal asserts DTR (saying "I'm up and ready"), it sees that same signal coming back telling it that the modem is up and ready (DSR), and that the comm link to the remote end is up (CD). This is the spoofing you referred to.

The additional lines on a 25 pin RS-232 connector were for less commonly used / implemented features. These allowed for a secondary data channel, and for explicit clock signals to be supplied, especially important for synchronous data links. (The ubiquitous UART is for Asynchronous serial, but there were also USART chips that could do asynchronous or synchronous communications. Some of these also included Manchester coding of the data, which allowed the data to contain its own recoverable clock.)

Also, the RTS / CTS handshaking evolved over the years. In the early days of half-duplex modems, the handshake was asymmetric. The terminal would assert RTS, asking the modem to turn on the transmit portion, and the modem would assert CTS once it had established synchronization with the modem on the other end. But there was no corresponding signal to tell the modem the terminal's buffer was ready to receive. As modems evolved, full-duplex became the norm, and faster transmission rates meant bi-directional throttling via handshake became more important. (Throttling becomes more important when new characters are coming in fractions of millisecond apart, to a computer that may be servicing interrupts from many peripherals, increasing the likelihood the processor won't always be ready for more data.) The RTS signal evolved into a meaning more accurately described as Ready To Receive.
All these issues help explain why RS-232 breakout boxes became an essential item in the toolbox of anyone doing much with serial communications!

0 Votes

March 9, 2020 18:25

@BradLevy My view is that the RS-232 standard was obviously devised by a very large committee and shows what happens when nobody will compromise! Do you really need 25 signals to provide a low-speed serial comms link between Data Terminal Equipment (DTE) - a teletypewriter, and Data Communication Equipment (DCE) - a modem? The fact is that in most cases only a maximum of perhaps 6 pins on the 25-way DB25 connector were ever actually wired up. This became obvious when IBM reduced the COM port connector for their PC AT range to the smaller 9-pin DE9 type instead. The trouble was that manufacturers of peripheral devices could pick and choose which pins they used for their particular design resulting in the customer wondering why the product didn't work when they plugged it into their computer. Getting RS-232 links to work was a nightmare. If that wasn't bad enough, using all those tempting 'spare' pins for other purposes created even more confusion. For this reason the RS-232 'standard' became no standard at all.

March 9, 2020 22:25

@Bill Marshall I take a more charitable view of the RS-232 standard. It is true there are some circumstances in which 3 wires would suffice: TXD, RXD, and Ground. That works as long as you don't care if the other end sends data when you aren't ready for it, and don't care if your data gets through. There are plenty of times where that is fine. But there are times when it isn't, so you need handshaking lines. And over a phone connection via modem? You need the ring indicator and carrier detect. You are up to at least seven of the nine pins of that DB-9 at that point. The standard defined what most of the pins in the 25 pin connector were to be used for. Only three were unassigned or reserved for test purposes. The others provided loopback and test capability, a secondary channel, and external timing sources. Each of those were important capabilities in some environments and use cases - they just may not have been the environments you worked in. Problems did occur when some people appropriated some of the lines not needed in their use case to other purposes, ignoring the standard, and sometimes created potential for damage in the process.
One of the biggest causes of cabling not working right off the bat has to do with the sense of direction of TXD and RXD. A straight-through cable worked for connecting the DTE (Data Terminal Equipment) to the DCE (Data Communication Equipment, typically a modem). The TXD line carries data from the DTE to the DCE, and the RXD line carries data from the DCE to the DTE. But if you are connecting two DTE devices (computers or terminals) directly to each other, the TXD line of one needs to go to the RXD line of the other, and vice-versa. Otherwise the two transmitters will be fighting each other over the TXD line, while the two receivers will both be listening on the RXD line, but have no signal to listen to. Similarly with the handshake lines. So a "null modem" crossover adapter would be used.
This problem wasn't due to lack of adherence to the standard, just to a different use case: two DTEs talking to each other, instead of each talking to a modem. The same issue popped up in 10Base-T Ethernet cabling: peer-to-peer connections (directly connecting two computers) required a crossover cable, while computer-to-router or router-to-modem used straight through wiring. In the case of Ethernet, auto MDI-X circuitry was eventually developed that allowed smart Ethernet interfaces to automatically negotiate which end was going to transmit on one pair and which end was going to transmit on the other pair, eliminating the issue for newer installations.

March 9, 2020 11:07

Yes a great post, brought back so many memories with all the different breakout boxes we had (still have some!). Also recall interfacing an RS232 (expensive) microbalance to a "Pet" computer (this dates it!), after a few minutes smoke came from the balance which ended up with a burnt-out PCB! The manufacturers had put the +/- 24V power onto "unused" RS232 pins for their own expansions purposes!!!
I particularly like the reference to the mechanical strobe, I was not aware of these.

0 Votes

March 9, 2020 11:07

@Boss Your experience with RS-232 sounds all too typical! Even today I find manufacturers of say, wireless modules, play fast and loose with both the logic levels and the signals they use for flow control. Fortunately most have now settled on RTS/CTS, but older equipment might (mis)use DTR/DSR instead or as well, requiring 'spoofing' of connections to make the interfaced equipment work.
As for the printer I have nothing but admiration for the engineers who designed all this mechanical logic. The service engineers were a pretty impressive bunch too. I have the original user and service manuals for the Creed 75 as well as the 'special tools' which include the tuning fork shown, spring balances to check spring tensions and a key to wind the mechanism round by hand. Use of that key was I guess equivalent to 'single-stepping' a processor chip. I imagine a mis-alignment in any of the levers/cranks and that big motor could wreck the mechanism completely. The manual key must have been the service engineer's best friend!

March 9, 2020 11:07

@Bill Marshall wow, treasure that tuning fork! Having completed my degree I think at least for me working with service engineers, well at least looking over their shoulders provided me with a great foundation for design. These are a professional group of people! I also took every opportunity to dig in and fault find, it provided a great foundation to build upon.
As for RS 232, the parity check bit also added to the confusion when there was the typical lack of documentation! Thanks for a very interesting post, really enjoyed it.

March 9, 2020 11:07

Great post, Bill! Reminded me also of an FPGA workshop we ran a few times, called ChipHack, where an introductory exercise was to build a UART transmitter and receiver in RTL.

0 Votes
DesignSpark Electrical Logolinkedin