8155 is an integrated Ram , IO , and timer devices designed for 8085

8255 is a programmable IO Controller

Intel 8279
The Intel 8279 is a Keyboard/Display Controller is specially developed for interfacing keyboard
and display devices for the Intel 8085, 8086 and 8088 microprocessors. Its important features
are.

Simultaneous keyboard and display operations.

Scanned keyboard mode.

Scanned sensor mode.

8-character keyboard FIFO.

Right or left entry 16-byte display RAM.

Programmable scan timing.

Intel 8253
The Intel 8253 and 8254 are Programmable Interval Timers (PITs), which perform
timing and counting functions. They were primarily designed for the Intel
8080/8085-processors, but later used in x86-systems. They (or an equivalent circuit
embedded in a larger chip) are found in all IBM PC compatibles.

Operation Modes

History
The 8253 was used in IBM PC compatibles since their introduction in 1981.[1] In modern times,
this PIT is not included as a separate chip in an x86 PC. Rather, its functionality is included as
part of the motherboard's southbridge chipset. In some modern chipsets, this change may show
up as measurable timing differences in accessing a PIT using the x86 I/O address space. Reads
and writes to such a PIT's registers in the I/O address space may complete much faster.
Newer motherboards also include a counter through the Advanced Configuration and Power
Interface (ACPI), a counter on the Local Advanced Programmable Interrupt Controller (Local

APIC), and a High Precision Event Timer. The CPU itself also provides the Time Stamp Counter
(TSC) facility.

Features

Block diagram of Intel 8253

The timer has three counters, called channels. Each channel can be programmed to operate in
one of six modes. Once programmed, the channels can perform their tasks independently. The
timer is usually assigned to IRQ-0 (highest priority hardware interrupt) because of the critical
function it performs and because so many devices depend on it.[2]

Counters
There are 3 counters (or timers), which are labeled as "Counter 0", "Counter 1" and "Counter 2".
[3]
Each counter has 2 input pins "CLK" (clock input) and "GATE" and 1-pin, "OUT", for
data output. The 3 counters are 16-bit down counters independent of each other, and can be
easily read by the CPU.[4]
In the original IBM PCs, the first counter (selected by setting A1=A0=0, see Control Word
Register below) is used to generate a timekeeping interrupt. The second counter (A1=0, A0=1) is
used to trigger the refresh of DRAM memory. The last counter (A1=1, A0=0) is used to generate
tones via the PC speaker.
Besides the counters, a typical Intel 8253 microchip also contains the following components:

Data/Bus Buffer
This block contains the logic to buffer the data bus to / from the microprocessor, and to the
internal registers. It has 8 input pins, usually labelled as D7..D0, where D7 is the MSB.

Read/Write Logic
The Read/Write Logic block has 5 pins, which are listed below. Notice that "/X" denotes an
active low signal.

/RD: read signal

/WR: write signal

/CS: chip select signal

A0, A1: address lines

Operation mode of the PIT is changed by setting the above hardware signals. For example, to
write to the Control Word Register, one needs to set /CS=0, /RD=1, /WR=0, A1=A0=1.

Control Word Register

Port 43h R/W
Port 53h R/W second chip ...
This register contains the programmed information which will be sent (by the microprocessor) to
the device. It defines how the PIT logically works. Each access to these ports takes about 1 s.
To initialize the counters, the microprocessor must write a control word (CW) in this register.
This can be done by setting proper values for the pins of the Read/Write Logic block and then by
sending the control word to the Data/Bus Buffer block.
The control word register contains 8 bits, labeled D7..D0 (D7 is the MSB).
Bit# D7 D6 D5
Name SC1 SC0 RW1
0
0
x
0
1
x
1
0
x

D4
RW0
x
x
x

D3 D2 D1 D0
Short Description
M2 M1 M0 BCD
x x x x
Counter 0 at port 40h R/W
x x x x
Counter 1 at port 41h R/W
x x x x
Counter 2 at port 42h R/W

x
x

x
x

0
1

1
0

x
x

x
x

x
x

x
x

x
x
x
x
x

x
x
x
x
x

x
x
x
x
x

x
x
x
x
x

0
0
0
0
1

0
0
1
1
0

0
1
0
1
0

x
x
x
x
x

Counter Latch, value can be read out in the way

RW1, RW0 was set before. The value is held
until it is read out or overwritten.
Read/Write bits 0..7 of counter value
Read/Write bits 8..15 of counter value
2xRead/2xWrite bits 0..7 then 8..15 of counter
value
Mode 0: Interrupt on Terminal Count
Mode 1: Hardware Retriggerable One-Shot
Mode 2: Rate Generator
Mode 3: Square Wave
Mode 4: Software Triggered Strobe

Mode 5: Hardware Triggered Strobe

(Retriggerable)
Counter is a 16 bit binary
counter(0..65535,FFFFh)
Counter is a 16 bit decimal counter 4 x 4bit
decades(0..9999)

_____ _____
Name 1

count status

C2 C1 C0

Counter(C0..C2) value(s) can be read out.

Counter's(C0..C2) state(s) can be read out.
see below Status Byte
Counter's(C0..C2) value(s) and state(s) can be
read out.

When setting the PIT, the microprocessor first sends a control message, then a count message to
the PIT. The counting process will start after the PIT has received these messages, and, in some
cases, if it detects the rising edge from the GATE input signal.
On PCs the address for timer0 (chip) is at port 40h..43h like described and the second timer1
(chip) is at 50h..53h.

Status Byte
8 bit
The Status Byte is read like an 8 bit counter value (port 40h..42h R).
Bit#
Name

D7
output

D6
D5
D4
D3
D2
D1
D0
null RW1 RW0
M2
M1
M0
BCD
count
------------------------------------------0
x
x
x
x
x
x
x
1
x
x
x
x
x
x
x
------------------------------------------x
0
x
x
x
x
x
x
is loaded into the counter.
written to the latch.
x
1
x
x
x
x
x
x
------------------------------------------x
x
=
=
=
=
=
=
Control Word Register

Out Pin is 0
Out Pin is 1
The value of the latch
A new value can be
Counter value is 0.
like defined in the

Operation Modes
The D3, D2, and D1 bits of the Control Word set the operating mode of the timer. There are 6
modes in total; for modes 2 and 3, the D3 bit is ignored, so the missing modes 6 and 7 are aliases
for modes 2 and 3. Notice that, for modes 0, 2, 3 and 4, GATE must be set to HIGH to enable
counting. For mode 5, the rising edge of GATE starts the count. For details on each mode, see the
reference links.

Mode 0 (000): Interrupt on Terminal Count

Mode 0 is used for the generation of accurate time delay under software control. In this mode,
the counter will start counting from the initial COUNT value loaded into it, down to 0. Counting
rate is equal to the input clock frequency.
The OUT pin is set low after the Control Word is written, and counting starts one clock cycle
after the COUNT programmed. OUT remains low until the counter reaches 0, at which point
OUT will be set high until the counter is reloaded or the Control Word is written. The Gate signal
should remain active high for normal counting. If Gate goes low counting get terminated and
current count is latched till Gate pulse goes high again.

Mode 1 (001): Programmable One Shot

In this mode 8253 can be used as Monostable Multivibrator. GATE input is used as trigger input.
OUT will be initially high. OUT will go low on the CLK pulse following a trigger to begin the
one-shot pulse, and will remain low until the Counter reaches zero. OUT will then go high and
remain high until the CLK pulse after the next trigger.
After writing the Control Word and initial count, the Counter is armed. A trigger results in
loading the Counter and setting OUT low on the next CLK pulse, thus starting the one-shot
pulse. An initial count of N will result in a one-shot pulse N CLK cycles in duration.
The one-shot is retriggerable, hence OUT will remain low for N CLK pulses after any trigger.
The one-shot pulse can be repeated without rewriting the same count into the counter. GATE has
no effect on OUT. If a new count is written to the Counter during a oneshot pulse, the current
one-shot is not affected unless the counter is retriggered. In that case, the Counter is loaded with
the new count and the oneshot pulse continues until the new count expires.

Mode 2 (X10): Rate Generator

In this mode, the device acts as a divide-by-n counter, which is commonly used to generate a
real-time clock interrupt.

Like other modes, counting process will start the next clock cycle after COUNT is sent. OUT
will then remain high until the counter reaches 1, and will go low for one clock pulse. OUT will
then go high again, and the whole process repeats itself.
The time between the high pulses depends on the preset count in the counter's register, and is
calculated using the following formula:

Value to be loaded into counter =

Note that the values in the COUNT register range from

to 1; the register never reaches zero.

Mode 3 (X11): Square Wave Generator

This mode is similar to mode 2. However, the duration of the high and low clock pulses of the
output will be different from mode 2.
Suppose

is the number loaded into the counter (the COUNT message), the output will be

high for

high for

counts, and low for

counts, if

counts, and low for

is even.

counts, if

is odd.

Mode 4 (100): Software Triggered Strobe

After Control Word and COUNT is loaded, the output will remain high until the counter reaches
zero. The counter will then generate a low pulse for 1 clock cycle (a strobe) after that the
output will become high again.

Mode 5 (101): Hardware Triggered Strobe

This mode is similar to mode 4. However, the counting process is triggered by the GATE input.
After receiving the Control Word and COUNT, the output will be set high. Once the device
detects a rising edge on the GATE input, it will start counting. When the counter reaches 0, the
output will go low for one clock cycle after that it will become high again, to repeat the cycle
on the next rising edge of GATE.

Programming Considerations
On x86 PCs, many video card BIOS and system BIOS will reprogram the second counter for
their own use. Reprogramming typically happens during video mode changes, when the video

BIOS may be executed, and during system management mode and power saving state changes,
when the system BIOS may be executed. This prevents any serious alternative uses of the timer's
second counter on many x86 systems.
The timer that is used by the system on x86 PCs is Channel 0, and its clock ticks at a theoretical
value of 1193181.8181... Hz, i.e. one third of the NTSC color subcarrier frequency, which comes
from dividing the system clock (14.31818 MHz) by 12. This is a holdover of the very first CGA
PCs they derived all necessary frequencies from a single quartz crystal, and to make TV output
possible, this quartz had to run at a multiple of the NTSC color subcarrier frequency.
As stated above, Channel 0 is implemented as a counter. Typically, the initial value of the counter
is set by sending bytes to the Control, then Data I/O Port registers (the value 36h sent to port
43h, then the low byte to port 40h, and port 40h again for the high byte). The counter counts
down to zero, then sends a hardware interrupt (IRQ 0, INT 8) to the CPU. The counter then resets
to its initial value and begins to count down again. The fastest possible interrupt frequency is a
little over a half of a megahertz. The slowest possible frequency, which is also the one normally
used by computers running MS-DOS or compatible operating systems, is about 18.2 Hz. Under
these real mode operating systems, the BIOS accumulates the number of INT 8 calls that it
receives in real mode address 0040:006c, which can be read by a program.
As a timer counts down, its value can also be read directly by reading its I/O port twice, first for
the low byte, and then for the high byte. However, in free-running counter applications such as in
the x86 PC, it is necessary to first write a latch command for the desired channel to the control
register, so that both bytes read will belong to one and the same value.
According to a 2002 Microsoft document, "because reads from and writes to this hardware
[8254] require communication through an IO port, programming it takes several cycles, which is
prohibitively expensive for the OS. Because of this, the aperiodic functionality is not used in
practice."[5]

Intel 8257 DMA Controller

Intel 8259 is Programmable Interrupt controller (In computing, a programmable
interrupt controller (PIC) is a device that is used to combine several sources of
interrupt onto one or more CPU lines, while allowing priority levels to be assigned to
its interrupt outputs. When the device has multiple interrupt outputs to assert, it
asserts them in the order of their relative priority. Common modes of a PIC include
hard priorities, rotating priorities, and cascading priorities. [citation needed] PICs often allow
the cascading of their outputs to inputs between each other.)
The 8259 combines multiple interrupt input sources into a single interrupt output to
the host microprocessor, extending the interrupt levels available in a system

beyond the one or two levels found on the processor chip. The 8259A was the
interrupt controller for the ISA bus in the original IBM PC and IBM PC AT.

Functional description

The main signal pins on an 8259 are as follows: eight interrupt input request lines named IRQ0
through IRQ7, an interrupt request output line named INTR, interrupt acknowledgment line
named INTA, D0 through D7 for communicating the interrupt level or vector offset. Other
connections include CAS0 through CAS2 for cascading between 8259s.
Up to eight slave 8259s may be cascaded to a master 8259 to provide up to 64 IRQs. 8259s are
cascaded by connecting the INT line of one slave 8259 to the IRQ line of one master 8259.
There are three registers, an Interrupt Mask Register (IMR), an Interrupt Request Register (IRR),
and an In-Service Register (ISR). The IRR maintains a mask of the current interrupts that are
pending acknowledgement, the ISR maintains a mask of the interrupts that are pending an EOI,
and the IMR maintains a mask of interrupts that should not be sent an acknowledgement.
End Of Interrupt (EOI) operations support specific EOI, non-specific EOI, and auto-EOI. A
specific EOI specifies the IRQ level it is acknowledging in the ISR. A non-specific EOI resets
the IRQ level in the ISR. Auto-EOI resets the IRQ level in the ISR immediately after the
interrupt is acknowledged.
Edge and level interrupt trigger modes are supported by the 8259A. Fixed priority and rotating
priority modes are supported.
The 8259 may be configured to work with an 8080/8085 or an 8086/8088. On the 8086/8088, the
interrupt controller will provide an interrupt number on the data bus when an interrupt occurs.
The interrupt cycle of the 8080/8085 will issue three bytes on the data bus (corresponding to a
CALL instruction in the 8080/8085 instruction set).
The 8259A provides additional functionality compared to the 8259 (in particular buffered mode
and level-triggered mode) and is upward compatible with it.

Intel 8251

The 8251 Universal Synchronous/Asynchronous Receiver/Transmitter (A universal

asynchronous receiver/transmitter, abbreviated UART is a piece of computer hardware that

translates data between parallel and serial forms. UARTs are commonly used in conjunction with
communication standards such as EIA, RS-232, RS-422 or RS-485. The universal designation
indicates that the data format and transmission speeds are configurable. The electric signaling
levels and methods (such as differential signaling etc.) are handled by a driver circuit external to
the UART.
A UART is usually an individual (or part of an) integrated circuit used for serial communications
over a computer or peripheral device serial port. UARTs are now commonly included in
microcontrollers. A dual UART, or DUART, combines two UARTs into a single chip. An octal
UART or OCTART combines eight UARTs into one package, an example being the NXP
SCC2698. Many modern ICs now come with a UART that can also communicate synchronously;
these devices are called USARTs (universal synchronous/asynchronous receiver/transmitter).

) packaged in a 28-pin DIP made by Intel. It is typically used for

serial communication and was rated for 19.2 Kbits per second
signalling rate.

It includes 5 sections
1. read/write control logic
2. transmitter
3. receiver
4. data bus system
5. modem control

Serial Communication
Embedded electronics is all about interlinking circuits (processors or other
integrated circuits) to create a symbiotic system. In order for those individual
circuits to swap their information, they must share a common communication
protocol. Hundreds of communication protocols have been defined to achieve this
data exchange, and, in general, each can be separated into one of two categories:
parallel or serial.
Parallel vs. Serial

Parallel interfaces transfer multiple bits at the same time. They usually require buses of data transmitting across eight, sixteen, or more wires. Data is transferred in huge, crashing waves of
1s and 0s.

An 8-bit data bus, controlled by a clock, transmitting a byte every clock pulse. 9 wires are used.
Serial interfaces stream their data, one single bit at a time. These interfaces can operate on as
little as one wire, usually never more than four.

Example of a serial interface, transmitting one bit every clock pulse. Just 2 wires required!

Think of the two interfaces as a stream of cars: a parallel interface would be the 8+ lane megahighway, while a serial interface is more like a two-lane rural country road. Over a set amount of
time, the mega-highway potentially gets more people to their destinations, but that rural twolaner serves its purpose and costs a fraction of the funds to build.
Parallel communication certainly has its benefits. Its fast, straightforward, and relatively easy to
implement. But it requires many more input/output (I/O) lines. If youve ever had to move a
project from a basic Arduino Uno to a Mega, you know that the I/O lines on a microprocessor
can be precious and few. So, we often opt for serial communication, sacrificing potential speed
for pin real estate.
Asynchronous Serial

Over the years, dozens of serial protocols have been crafted to meet particular needs of
embedded systems. USB (universal serial bus), and Ethernet, are a couple of the more wellknown computing serial interfaces. Other very common serial interfaces include SPI, I2C, and
the serial standard were here to talk about today. Each of these serial interfaces can be sorted
into one of two groups: synchronous or asynchronous.
A synchronous serial interface always pairs its data line(s) with a clock signal, so all devices on a
synchronous serial bus share a common clock. This makes for a more straightforward, often
faster serial transfer, but it also requires at least one extra wire between communicating devices.
Examples of synchronous interfaces include SPI, and I2C.
Asynchronous means that data is transferred without support from an external clock signal.
This transmission method is perfect for minimizing the required wires and I/O pins, but it does
mean we need to put some extra effort into reliably transferring and receiving data. The serial
protocol well be discussing in this tutorial is the most common form of asynchronous transfers.
It is so common, in fact, that when most folks say serial theyre talking about this protocol
(something youll probably notice throughout this tutorial).
The clock-less serial protocol well be discussing in this tutorial is widely used in embedded
electronics. If youre looking to add a GPS module, Bluetooth, XBees, serial LCDs, or many
other external devices to your project, youll probably need to whip out some serial-fu.
Suggested Reading

This tutorial builds on a few lower-level electronics concepts, including:

How to read a schematic

Analog vs Digital

Logic Levels

Binary

Hexadecimal

ASCII

If youre not super familiar with any of those concepts, consider checking those links out.
Now then, lets go on a serial journey
Rules of Serial

The asynchronous serial protocol has a number of built-in rules - mechanisms that help ensure
robust and error-free data transfers. These mechanisms, which we get for eschewing the external
clock signal, are:

Data bits,

Synchronization bits,

Parity bits,

and Baud rate.

Through the variety of these signaling mechanisms, youll find that theres no one way to send
data serially. The protocol is highly configurable. The critical part is making sure that both
devices on a serial bus are configured to use the exact same protocols.
Baud Rate

The baud rate specifies how fast data is sent over a serial line. Its usually expressed in units of
bits-per-second (bps). If you invert the baud rate, you can find out just how long it takes to
transmit a single bit. This value determines how long the transmitter holds a serial line high/low
or at what period the receiving device samples its line.
Baud rates can be just about any value within reason. The only requirement is that both devices
operate at the same rate. One of the more common baud rates, especially for simple stuff where
speed isnt critical, is 9600 bps. Other standard baud are 1200, 2400, 4800, 19200, 38400,
57600, and 115200.
The higher a baud rate goes, the faster data is sent/received, but there are limits to how fast data
can be transferred. You usually wont see speeds exceeding 115200 - thats fast for most

microcontrollers. Get too high, and youll begin to see errors on the receiving end, as clocks and
sampling periods just cant keep up.
Framing the data

Each block (usually a byte) of data transmitted is actually sent in a packet or frame of bits.
Frames are created by appending synchronization and parity bits to our data.

A serial frame. Some symbols in the frame have configurable bit sizes.
Lets get into the details of each of these frame pieces.
Data chunk

The real meat of every serial packet is the data it carries. We ambiguously call this block of data
a chunk, because its size isnt specifically stated. The amount of data in each packet can be set to
anything from 5 to 9 bits. Certainly, the standard data size is your basic 8-bit byte, but other sizes
have their uses. A 7-bit data chunk can be more efficient than 8, especially if youre just
transferring 7-bit ASCII characters.
After agreeing on a character-length, both serial devices also have to agree on the endianness of
their data. Is data sent most-significant bit (msb) to least, or vice-versa? If its not otherwise
stated, you can usually assume that data is transferred least-significant bit (lsb) first.
Synchronization bits

The synchronization bits are two or three special bits transferred with each chunk of data. They
are the start bit and the stop bit(s). True to their name, these bits mark the beginning and end of
a packet. Theres always only one start bit, but the number of stop bits is configurable to either
one or two (though its commonly left at one).
The start bit is always indicated by an idle data line going from 1 to 0, while the stop bit(s) will
transition back to the idle state by holding the line at 1.
Parity bits

Parity is a form of very simple, low-level error checking. It comes in two flavors: odd or even.
To produce the parity bit, all 5-9 bits of the data byte are added up, and the evenness of the sum
decides whether the bit is set or not. For example, assuming parity is set to even and was being

added to a data byte like 0b01011101, which has an odd number of 1s (5), the parity bit would
be set to 1. Conversely, if the parity mode was set to odd, the parity bit would be 0.
Parity is optional, and not very widely used. It can be helpful for transmitting across noisy
mediums, but itll also slow down your data transfer a bit and requires both sender and receiver
to implement error-handling (usually, received data that fails must be re-sent).
9600 8N1 (an example)

9600 8N1 - 9600 baud, 8 data bits, no parity, and 1 stop bit - is one of the more commonly used
serial protocols. So, what would a packet or two of 9600 8N1 data look like? Lets have an
example!
A device transmitting the ASCII characters O and K would have to create two packets of data.
The ASCII value of O (thats uppercase) is 79, which breaks down into an 8-bit binary value of
01001111, while Ks binary value is 01001011. All thats left is appending sync bits.
It isnt specifically stated, but its assumed that data is transferred least-significant bit first.
Notice how each of the two bytes is sent as it reads from right-to-left.

Since were transferring at 9600 bps, the time spent holding each of those bits high or low is 1/
(9600 bps) or 104 s per bit.
For every byte of data transmitted, there are actually 10 bits being sent: a start bit, 8 data bits,
and a stop bit. So, at 9600 bps, were actually sending 9600 bits per second or 960 (9600/10)
bytes per second.

Now that you know how to construct serial packets, we can move on to the hardware section.
There well see how those 1s and 0s and the baud rate are implemented at a signal level!
Wiring and Hardware

A serial bus consists of just two wires - one for sending data and another for receiving. As such,
serial devices should have two serial pins: the receiver, RX, and the transmitter, TX.

Its important to note that those RX and TX labels are with respect to the device itself. So the RX
from one device should go to the TX of the other, and vice-versa. Its weird if youre used to
hooking up VCC to VCC, GND to GND, MOSI to MOSI, etc., but it makes sense if you think
about it. The transmitter should be talking to the receiver, not to another transmitter.
A serial interface where both devices may send and receive data is either full-duplex or halfduplex. Full-duplex means both devices can send and receive simultaneously. Half-duplex
communication means serial devices must take turns sending and receiving.
Some serial busses might get away with just a single connection between a sending and receiving
device. For example, our Serial Enabled LCDs are all ears and dont really have any data to relay
back to the controlling device. This is whats known as simplex serial communication. All you
need is a single wire from the master devices TX to the listeners RX line.
Hardware Implementation

Weve covered asynchronous serial from a conceptual side. We know which wires we need. But
how is serial communication actually implemented at a signal level? In a variety ways, actually.
There are all sorts of standards for serial signaling. Lets look at a couple of the more popular
hardware implementations of serial: logic-level (TTL) and RS-232.
When microcontrollers and other low-level ICs communicate serially they usually do so at a TTL
(transistor-transistor logic) level. TTL serial signals exist between a microcontrollers voltage
supply range - usually 0V to 3.3V or 5V. A signal at the VCC level (3.3V, 5V, etc.) indicates
either an idle line, a bit of value 1, or a stop bit. A 0V (GND) signal represents either a start bit or
a data bit of value 0.

RS-232, which can be found on some of the more ancient computers and peripherals, is like TTL
serial flipped on its head. RS-232 signals usually range between -13V and 13V, though the spec
allows for anything from +/- 3V to +/- 25V. On these signals a low voltage (-5V, -13V, etc.)
indicates either the idle line, a stop bit, or a data bit of value 1. A high RS-232 signal means
either a start bit, or a 0-value data bit. Thats kind of the opposite of TTL serial.

Between the two serial signal standards, TTL is much easier to implement into embedded
circuits. However the low voltage levels are more susceptible to losses across long transmission
lines. RS-232, or more complex standards like RS-485, are better suited to long range serial
transmissions.
When youre connecting two serial devices together, its important to make sure their signal
voltages match up. You cant directly interface a TTL serial device with an RS-232 bus. Youll
have to shift those signals!

Continuing on, well explore the tool microcontrollers use to convert their data on a parallel bus
to and from a serial interface. UARTs!
UARTs

The final piece to this serial puzzle is finding something to both create the serial packets and
control those physical hardware lines. Enter the UART.

A universal asynchronous receiver/transmitter (UART) is a block of circuitry responsible for

implementing serial communication. Essentially, the UART acts as an intermediary between
parallel and serial interfaces. On one end of the UART is a bus of eight-or-so data lines (plus
some control pins), on the other is the two serial wires - RX and TX.

Super-simplified UART interface. Parallel on one end, serial on the other.

UARTs do exist as stand-alone ICs, but theyre more commonly found inside microcontrollers.
Youll have to check your microcontrollers datasheet to see if it has any UARTs. Some have
none, some have one, some have many. For example, the Arduino Uno - based on the old
faithful ATmega328 - has just a single UART, while the Arduino Mega - built on an
ATmega2560 - has a whopping four UARTs.
As the R and T in the acronym dictate, UARTs are responsible for both sending and receiving
serial data. On the transmit side, a UART must create the data packet - appending sync and parity
bits - and send that packet out the TX line with precise timing (according to the set baud rate).
On the receive end, the UART has to sample the RX line at rates according to the expected baud
rate, pick out the sync bits, and spit out the data.

Internal UART block diagram (courtesy of the Exar ST16C550 datasheet)

More advanced UARTs may throw their received data into a buffer, where it can stay until the
microcontroller comes to get it. UARTs will usually release their buffered data on a first-in-firstout (FIFO) basis. Buffers can be as small as a few bits, or as large as thousands of bytes.
Software UARTs

If a microcontroller doesnt have a UART (or doesnt have enough), the serial interface can be
bit-banged - directly controlled by the processor. This is the approach Arduino libraries like
SoftwareSerial take. Bit-banging is processor-intensive, and not usually as precise as a UART,
but it works in a pinch!
Common Pitfalls

Thats about all there is to serial communication. Id like to leave you with a few common
mistakes that are easy for an engineer of any experience level to make:

RX-to-TX, TX-to-RX

Seems simple enough, but its a mistake I know Ive made more than a few times. As much as
you want their labels to match up, always make sure to cross the RX and TX lines between serial
devices.

FTDI Basic programming a Pro Mini. Note RX and TXs crossed!

Contrary to what the esteemed Dr. Egon Spengler would warn, cross the streams.
Baud Rate Mismatch

Baud rates are like the languages of serial communication. If two devices arent speaking at the
same speed, data can be either misinterpreted, or completely missed. If all the receiving device
sees on its receive line is garbage, check to make sure the baud rates match up.

Data transmitted at 9600 bps, but received at 19200 bps. Baud mismatch = garbage.
Bus Contention

Serial communication is designed to allow just two devices to communicate across one serial
bus. If more than one device is trying to transmit on the same serial line you could run into buscontention. Dun dun dun.
For example, if youre connecting a GPS module up to your Arduino, you may just wire that
modules TX line up the Arduinos RX line. But that Arduino RX pin is already wired up to the
TX pin of the USB-to-serial converter, which is used whenever you program the Arduino or use
the Serial Monitor. This sets up the potential situation where both the GPS module and FTDI
chip are trying to transmit on the same line at the same time.

Two transmitters sending to a single receiver sets up the possibility for bus contention.
Two devices trying to transmit data at the same time, on the same line, is bad! At best neither
of the devices will get to send their data. At worst, both devices transmit lines go poof (though
thats rare, and usually protected against).
It can be safe to connect multiple receiving devices to a single transmitting device. Not really up
to spec and probably frowned upon by a hardened engineer, but itll work. For example, if youre
connecting a serial LCD up to an Arduino, the easiest approach may be to connect the LCD
modules RX line to the Arduinos TX line. The Arduinos TX is already connected to the USB
programmers RX line, but that still leaves just one device in control of the transmission line.

Distributing a TX line like this can still be dangerous from a firmware perspective, because you
cant pick and choose which device hears what transmission. The LCD will end up receiving
data not meant for it, which could command it to go into an unknown state.
In general - one serial bus, two serial devices!