UNIT - 2

Embedded communications protocols

Many serial communication interfaces compete for use in embedded systems. The right serial interface for your
system depends on several key factors. In this article I will describe seven of the most common serial interfaces,
to help you decide which bus is right for your next project.

Why serial?

There are many different reasons to use a serial interface. One of the most common is the need to interface with
a PC, during development and/or in the field. Most, if not all PCs have some sort of serial bus interface available
to connect peripherals. For embedded systems that must interface with a general-purpose computer, a serial
interface is often easier to use than the ISA or PCI expansion bus.

A benefit of serial communications is low pin counts. Serial communications can be performed with just one I/O
pin, compared to eight or more for parallel communications. Many common embedded system peripherals, such
as analog-to-digital and digital-to-analog converters, LCDs, and temperature sensors, support serial interfaces.

Serial buses can also provide for inter-processor communication-a network, if you will. This allows large tasks
that would normally require larger processors to be tackled with several inexpensive smaller processors. Serial
interfaces allow processors to communicate without the need for shared memory and semaphores, and the
problems they can create.

This isn't to say that parallel buses have no use. For operational fetches, address and data buses, and other
microprogram control, parallel buses have always been the clear winner. "Memory-mapping" peripherals has
been a technique commonly used for systems with address and data buses. This tendency allows parallel access
to off-chip peripherals. However, with many 8-bit microcontrollers (let alone 8-pin) with no external
address/data bus available for designs, memory-mapping is not an option.

Terminology

Before we get into the individual interface details, we should define several terms:

 On an asynchronous bus, data is sent without a timing clock. A synchronous bus sends data with a timing
clock.
 Full-duplex means data can be sent and received simultaneously. Half-duplex is when data can be sent or
received, but not at the same time.
 Master/slave describes a bus where one device is the master and others are slaves. Master/slave buses are
usually synchronous, as the master often supplies the timing clock for data being sent along in both
directions.
 A multi-master bus is a master/slave bus that may have more than one master. These buses must have an
arbitration scheme that can settle conflicts when more than one master wants to control the bus at the same
time.
 Point-to-point or peer interfaces are where two devices have a peer relation to each other; there are no
masters or slaves. Peer interfaces are most often asynchronous.
 The term multi-drop describes an interface in which there are several receivers and one transmitter.
 Multi-point describes a bus in which there are more than two peer transceivers. This is different from a
multi-drop interface as it allows bidirectional communication over the same set of wires.
RS-232

TIA/EIA-232-F (typically referred to as RS-232) is a common interface that can be found on almost every
personal computer. RS-232 is a complete standard, not only including electrical characteristics, but
physical and mechanical characteristics as well, such as connection hardware, pin-outs, and signal names.
A point-to-point interface, RS-232 is capable of moderate distances at speeds up to 20Kbps. While not
specifically called out in the specification, speeds of greater than 115.2Kbps are possible, provided that
connections are short and proper grounding is used. Cable lengths of 30 feet are common, and cables of
over 200 feet can be attained with low-capacitance cable.

An RS-232 bus is an unbalanced bus capable of full-duplex communication between two

receiver/transmitter pairs, named data terminal equipment (DTE) and data communication equipment
(DCE). Each one has a transmit signal that is connected to the receive signal on the other end. As such,
there is a pin difference between the two sides. (Your PC is a DTE, while the connected peripheral is
DCE.)

Each transmitter sends data by varying the voltage on the line. A voltage higher than 3V is a binary zero,
while a voltage less than --3V is a binary one. Between these voltages, the value is undefined. To convert
from logic levels (0 and 5V) to these levels and back, an RS-232 conversion IC, such as the 1488, 1489, or
ubiquitous MAX232, can be used.

Typical RS-232 communication consists of a start bit, data bits, parity bits (if any), and stop bit(s). When
communicating with PCs, the typical format is eight data bits, no parity, and one stop bit (8N1). Seven data
bits, even parity, and one stop bit (7E1) is also common. A start bit is often a zero and a stop bit is often a
one, as shown in Figure 1. The official specification does not delineate any communications protocol,
including the use of start/stop bits.

Figure 1: RS-232

Many embedded systems that use the RS-232 bus either interface with PCs or PC peripherals such as
modems. Other systems use RS-232 so that bus traffic can be monitored easily with an inexpensive
protocol analyzer or a PC equipped with two serial ports.

Almost every microcontroller vendor has products that include hardware support for RS-232, called
Universal Asynchronous Receiver Transmitters (UARTs). UARTs are often interrupt-driven and capable
of speeds up to 115.2Kbps with little software overhead, although this varies by architecture.

RS-422 and RS-485

TIA/EIA-422-B (typically referred to as RS-422) and TIA/EIA-485-A (typically referred to as RS-485) are
balanced, twisted-pair interfaces capable of speeds up to 10Mbps and distances up to 4,000 feet. Being
differential buses, each uses signals from 1.5V to 6V to transmit the data. (With a differential, balanced
bus, noise immunity is increased over a comparable single-ended, unbalanced bus such as RS-232.)

The RS-422 interface is a multi-drop interface, giving unidirectional communication over a pair of wires
from one transmitter to several receivers, up to 10 unit loads (UL). If the devices receiving the data wish to
communicate back to the transmitter, the designer must use a separate, dedicated bus between each
receiver and the transmitter. (Using this return bus will allow full-duplex transmissions.) For that reason,
RS-422 is seldom used between more than two nodes.

The RS-485 interface, on the other hand, is a bidirectional communication over one pair of wires between
several transceivers. The specification states that the bus can include up to 32 UL worth of transceivers.
Many manufacturers produce fractional-UL transceivers, thereby increasing the maximum number of
devices to well over 100.

The RS-422 and RS-485 interfaces often use the same start bit/data/stop bit format of RS-232. In fact,
several converters exist to go from RS-232 to RS-485 and back. Do keep in mind, however, that RS-232 is
a full-duplex interface, while RS-485 is half-duplex.

Several microcontroller manufacturers provide built-in UARTs that boast special RS-485 abilities.

I2C

The Inter-Integrated Circuit bus (I2C) is a patented interface developed by Philips Semiconductors. (In
order for an IC manufacturer to implement the I 2C bus in hardware, they must obtain licensing from
Philips.)

The I2C bus is a half-duplex, synchronous, multi-master bus requiring only two signal wires: data (SDA)
and clock (SCL). These lines are pulled high via pull-up resistors and controlled by the hardware via open-
drain drivers, giving a wired-AND interface.

I2C uses an addressable communications protocol that allows the master to communicate with individual
slaves using a 7-bit or 10-bit address. Each device has an address that is assigned by Philips to the
manufacturer of the device. In addition, several special addresses exist, including a "general call" address
(which addresses every device on the bus) and a high-speed initiation address.

During communication with slave devices, the master generates all clock signals for both communication
to and from the slave. Each communication begins with the master generating a start condition, an 8-bit
data word, an acknowledge bit, followed by a stop condition or a repeated start. Each data bit transition
takes place while SCL is low, except for the start and stop conditions. The start condition is a high-to-low
transition of the SDA line while the SCL line is high. A stop condition is a low-to-high transition of the
SDA line while the SCL line is high (see Figure 2). The acknowledge bit is generated by the receiver of the
message by pulling the SDA line low while the master releases the line and allows it to float high. If the
master reads the acknowledge bit as high, it should consider the last communication word not received and
take appropriate action, including possibly resending the data.
Figure 2: I2C

I2C has a rather interesting feature called clock stretching, which is done when the slave device is unable to
process the bit and wishes for more time. When this happens, the slave pulls the SCL line low. Since the
signal behaves as a wired-AND, when the master releases the SCL line while the slave is "stretching" the
clock, the master should notice that the line stays low. Upon seeing this, the master waits until the slave
has processed the data bit and released the line. Once released by the slave, the SCL line floats back high,
signaling to the master to send the next data bit..

The I2C bus has three speeds: slow (under 100Kbps), fast (400Kbps), and high-speed (3.4Mbps), each
downward compatible. Philips has specified a recommended wiring arrangement should the signals need to
leave the circuit board.

I2C bus distances are often limited to on-board communications, although I have heard of developers using
I2C successfully over distances of 50 feet! The true limit to I 2C distances is the bit-rate and capacitance of
the bus. As such, for off-board communications, I2C is practically limited to under 10 feet for moderate
speeds.

For more details on I2C, read David and Roee Kalinsky's "Beginner's Corner: I2C" (August 2001).

SPI

The Serial Peripheral Interface (SPI) is a synchronous serial bus developed by Motorola and present on
many of their microcontrollers.

The SPI bus consists of four signals: master out slave in (MOSI), master in slave out (MISO), serial clock
(SCK), and active-low slave select (/SS). As a multi-master/slave protocol, communications between the
master and selected slave use the unidirectional MISO and MOSI lines, to achieve data rates over 1Mbps
in full duplex mode. The data is clocked simultaneously into the slave and master based on SCK pulses the
master supplies. The SPI protocol allows for four different clocking types, based on the polarity and phase
of the SCK signal. It is important to ensure that these are compatible between master and slave.

In addition to the 1Mbps data rate, another advantage to SPI is if only one slave device is used, the /SS line
can be pulled low and the /SS signal does not have to be generated by the master. (This capability is,
however, dependent on the phase selection of the SCK.)

A disadvantage to SPI is the requirement to have separate /SS lines for each slave. Provided that extra I/O
pins are available, or extra board space for a demultiplexer IC, this is not a problem. But for small, low-
pin-count microcontrollers, a multi-slave SPI interface might not be a viable solution.

What is Communication?
Before we move on to serial communication, lets discuss a bit about communication in general. In
simple terms, communication is an exchange of ideas between two individuals. Ideas can be anything
and in any form – they could be written/spoken words, in form of media like audio/video, or if you like
sci-fi, then it can also in form of telepathy! ;)
But what does communication between two microcontrollers mean? Its simple! An exchange of data
(bits)! There are many protocols for communication (which would be discussed later) but all of them
are based on either serial communication or parallel communication.

Why do we need Communication?

Lets take an example. As kids, we all must have played with those remote controlled toy cars and
airplanes. It was pretty fun and fascinating at that time. I am sure that most of us at that time didn’t try
to figure out how it was possible! How could the remote control device in your hand control the car or
the aeroplane? Well, of course, the device in your hand sends some data, which is received by the
car/aeroplane. There is a microcontroller onboard the toy, which interprets the signals and acts
accordingly. Correct! So far so good, but now it doesn’t end here. As grown ups, there are a few more
questions which should arise! Like how does the device send the signal? From where is the signal being
sent? What is actually being sent? Who receives it? How is it processed?
Lets take another example. This one’s a more common example. You have a file in your mobile and
you would like to share it with your friend who is sitting next to you? How would you do it – Bluetooth,
IR, NFC, LAN or email? Mostly people would use Bluetooth. IR is obsolete, NFC is still in
developmental phase and isn’t available in most devices, LAN needs a WiFi/LAN network whereas
email requires an active Internet connection. The same questions can be put forth here as well – how is
it send, from where is it sent and to where, what is being sent and how is it processed?!
Well, this is why communication is required! And to answer all those questions, several communication
protocols have been developed! Now lets discuss a little about serial and parallel communication.

Serial Communication

Serial Transfer

In Telecommunication and Computer Science, serial communication is the process of sending/receiving

data in one bit at a time. It is like you are firing bullets from a machine gun to a target… that’s one
bullet at a time! ;)

Parallel Communication
 Parallel Transfer

Parallel communication is the process of sending/receiving multiple data bits at a time through parallel
channels. It is like you are firing using a shotgun to a target – where multiple bullets are fired from the
same gun at a time! ;)

Serial vs Parallel Communication

Now lets have a quick look at the differences between the two types of communications.
Serial Communication Parallel Communication
1. One data bit is transceived at a time 1. Multiple data bits are transceived at a
time
2. Slower 2. Faster
3. Less number of cables required to 3. Higher number of cables required
transmit data

Serial vs Parallel

So these were the basic differences between serial and parallel communication. From the above
differences, one would obviously think that parallel communication is far better than serial
 communication. But wait, these are just the basic differences. Before we proceed further, we need to be
acquainted with a few terminologies:
1. Bit Rate: It is the number of bits that are transmitted (sent/received) per unit time.
2. Clock Skew: In a parallel circuit, clock skew is the time difference in the arrival of two sequentially
adjacent registers. To explain it further, let us take the machine gun example again. When, say around
5 people are firing at the same time, there is bound to be a time difference in the arrival of the bullet
from the first shooter and that from the second shooter and so on. This time difference is what we call
clock skew. This is better illustrated in the picture below: There is a time lag in the data bits through
different channels of the same bus. Clock skew is inevitable due to differences in physical conditions
of the channels, like temperature, resistance, path length, etc
3. Crosstalk: Phenomenon by which a signal transmitted on one channel of a transmission bus creates an
undesired effect in another channel. Undesired capacitive, inductive, or conductive coupling is usually
what is called crosstalk, from one circuit, part of a circuit, or channel, to another. It can be seen from
the following diagram that clock skew and crosstalk are inevitable.

Major Factors Limiting Parallel Communication

Before the development of high-speed serial technologies, the choice of parallel links over serial links
was driven by these factors:
1. Speed: Superficially, the speed of a parallel link is equal to bit rate*number of channels. In
practice, clock skew reduces the speed of every link to the slowest of all of the links.
2. Cable length: Crosstalk creates interference between the parallel lines, and the effect only magnifies
with the length of the communication link. This limits the length of the communication cable that can
be used.
These two are the major factors, which limit the use of parallel communication.
Advantages of Serial over Parallel
Although a serial link may seem inferior to a parallel one, since it can transmit less data per clock cycle,
it is often the case that serial links can be clocked considerably faster than parallel links in order to
achieve a higher data rate. A number of factors allow serial to be clocked at a higher rate:
 Clock skew between different channels is not an issue (for un-clocked asynchronous serial
communication links). 
 A serial connection requires fewer interconnecting cables (e.g. wires/fibers) and hence occupies less
space. The extra space allows for better isolation of the channel from its surroundings.
 Crosstalk is not a much significant issue, because there are fewer conductors in proximity. 
In many cases, serial is a better option because it is cheaper to implement. Many ICs have serial
interfaces, as opposed to parallel ones, so that they have fewer pins and are therefore less expensive. It
is because of these factors, serial communication is preferred over parallel communication.

How is Data sent Serially?

Since we already know what are registers and data bits, we would now be talking in these terms only.
If not, I would recommend you to first take a detour and go through the introduction of this post by
Mayank.
When a particular data set is in the microcontroller, it is in parallel form, and any bit can be accessed
irrespective of its bit number. When this data set is transferred into the output buffer to be transmitted,
it is still in parallel form. This output buffer converts this data into Serial data (PISO)
(Parallel In Serial Out), MSB (Most Significant Bit) first or LSB (Least Significant Bit) first as
according to the protocol. Now this data is transmitted in Serial mode.
When this data is received by another microcontroller in its receiver buffer, the receiver buffer converts
it back into parallel data (SIPO) (Serial In Parallel Out) for further processing. The following diagram
should make it clear.

Data Transfer in Serial Communication

 This is how serial communication works! But it is not as simple as it looks. There is a catch in it, which
we will discuss little later in the same post. For now, lets discuss about two modes of serial data transfer
– synchronous and asynchronous.

Serial Transmission Modes

Serial data can be transferred in two modes – asynchronous and synchronous.
Asynchronous Data Transfer
Data Transfer is called Asynchronous when data bits are not “synchronized” with a clock line, i.e. there
is no clock line at all!
Lets take an analogy. Imagine you are playing a game with your friend where you have to throw colored
balls (let’s say we have only two colors – red (R) and yellow (Y)). Lets assume you have unlimited
number of balls. You have to throw a combination of these colored balls to your friend. So you start
throwing the balls. You throw R, then R, then Y, then R again and so on. So you start your sequence
RRYR… and then you end your round and start another round. How will your buddy on the other side
know that you have finished sending him first round of balls and that you are already sending him the
second round of balls?? He/she will be completely lost! How nice it would be if you both sit together
and fix a protocol that each round consists of 8 balls! After every 8 balls, you will throw two R balls to
ensure that your friend has caught up with you, and then you again start your second round of 8 balls.
This is what we call asynchronous data transfer.
Asynchronous data transfer has a protocol, which is usually as follows:
 The first bit is always the START bit (which signifies the start of communication on the serial line),
followed by DATA bits (usually 8-bits), followed by a STOP bit (which signals the end of data packet).
There may be a Parity bit just before the STOP bit. The Parity bit was earlier used for error checking,
but is seldom used these days.
 The START bit is always low (0) while the STOP bit is always high (1).
The following diagram explains it.

Asynchronous Data Transfer Timing Diagram

Synchronous Data Transfer

Synchronous data transfer is when the data bits are “synchronized” with a clock pulse.
 We will take the same analogy as before. You are still playing the throw-ball game, but this time, you
have set a timer in your watch such that it beeps every minute. You will not throw a ball unless you
hear a beep from your watch. As soon as you hear a beep from your watch, you and your friend, both
know that you are going to throw a ball to her. Both of you can keep a track of time using this; say you
start a new round after every 8 beeps. Isn’t it a much better approach? This approach is what we
call synchronous data transfer.
The concept for synchronous data transfer is simple, and as follows:
 The basic principle is that data bit sampling (or in other words, say, ‘recording’) is done with respect to
clock pluses, as you can see in the timing diagrams.
 Since data is sampled depending upon clock pulses, and since the clock sources are very reliable, so
there is much less error in synchronous as compared to asynchronous.

Synchronous Data Transfer Timing Diagram

Serial Communication Terminologies

Now its time to learn about some new words, which we will use frequently in the next few posts. There
are many terminologies, or ‘keywords’ associated with serial communication. We will discuss all of
them one by one:
1. MSB/LSB: this stands for Most Significant Bit (or Least Significant Bit). You can refer to
Mayank’s this post for more information on MSB and LSB. Since data is transferred bit-by-bit in serial
communication, one needs to know which bit is sent out first: MSB or LSB.
2. Simplex Communication: In this mode of serial communication, data can only be transferred from
transmitter to receiver and not vice versa.
3. Half Duplex Communication: this means that data transmission can occur in only one direction at a
time, i.e. either from master to slave, or slave to master, but not both.
4. Full Duplex Communication: full duplex communication means that data can be transmitted from the
master to the slave, and from slave to the master as the same time!
 Types of Transmission

5. Baud Rate: according to Wikipedia, baud is synonymous to symbols per second or pulses per second.
It is the unit of symbol rate, also known as baud or modulation rate. However, though technically
incorrect, in the case of modem manufacturers baud commonly refers to bits per second.
Importance of Baud Rate
For two microcontrollers to communicate serially they should have the samebaud rate, else serial
communication won’t work. This is because when you set a baud rate, you direct the microcontroller to
transmit/receive the data at that particular rate. So if you set different baud rates, then the receiver might
miss out the bits the transmitter is sending (because it is configured to receive data and process it with
a different speed!)
Different baud rates are available for use. The most common ones are 2400, 4800, 9600, 19200, 38400
etc. You cannot choose any arbitrary baud rate, there are some fixed values which you must use like
2400, 4800, etc. Please note that the unit of baud rate is bps (bits per second).

The Catch in Serial Communication

Now it’s all clear to you. You have data. You decide how to send your data
(synchronous/asynchronous). You send your data by following proper protocols. The transmitter
converts your parallel data to serial, sends it across the channel, then the receiver converts your serial
data to parallel. Bingo! But that’s not sufficient for a proper serial communication. There are two things
which still needs to be taken care of:
1. Baud Rate: Unless the baud rate of both the transmitter and receiver are the same, serial communication
cannot work. The reason is specified in the previous section.
2. Address: If you are trying to send multiple data together over the same channel and/or you are sharing
the same channel space with other users sending their own data, then you need to take care to properly
address your data. We won’t discuss about it in this post, but we will surely discuss about it in one of
our upcoming posts.
If you take care of these two factors, your serial communication will be established perfectly and your
data will go through properly. These are the two main reasons for unsuccessful serial link.

UART and USART

 UART stands for Universal Asynchronous Receiver Transmitter, whereas USART stands
for Universal Synchronous Asynchronous Receiver Transmitter. They are basically just a piece of
computer hardware that converts parallel data into serial data. The only difference between them is that
UART supports only asynchronous mode, whereas USART supports both asynchronous and
synchronous modes. Unlike Ethernet, Firewire etc., there is no specific port for UART/USART. They
are commonly used in conjugation with protocols like RS-232, RS-434 etc. (we have specific ports for
these two!).
In synchronous transmission, the clock data is recovered separately from the data stream and no
start/stop bits are used. This improves the efficiency of transmission on suitable channels since more of
the bits sent are usable data and not character framing.
The USART has the following components:
 A clock generator, usually a multiple of the bit rate to allow sampling in the middle of a bit period
 Input and output shift registers
 Transmit/receive control
 Read/write control logic
 Transmit/receive buffers (optional)
 Parallel data bus buffer (optional)
 First-in, first-out (FIFO) buffer memory (optional)

Serial Communication Protocols

A variety of communication protocols have been developed based on serial communication in the past
few decades. Some of them are:
1. SPI – Serial Peripheral Interface: It is a three-wire based communication system. One wire each for
Master to slave and Vice-versa, and one for clock pulses. There is an additional SS (Slave Select) line,
which is mostly used when we want to send/receive data between multiple ICs.
2. I2C – Inter-Integrated Circuit: Pronounced eye-two-see or eye-square-see, this is an advanced form
of USART. The transmission speeds can be as high as a whopping 400KHz. The I2C bus has two wires
– one for clock, and the other is the data line, which is bi-directional – this being the reason it is also
sometimes (not always – there are a few conditions) called Two Wire Interface (TWI). It is a pretty
new and revolutionary technology invented by Philips.
3. FireWire – Developed by Apple, they are high-speed buses capable of audio/video transmission. The
bus contains a number of wires depending upon the port, which can be either a 4-pin one, or a 6-pin
one, or an 8-pin one.
4. Ethernet: Used mostly in LAN connections, the bus consists of 8 lines, or 4 Tx/Rx pairs.
5. Universal serial bus (USB): This is the most popular of all. Is used for virtually all type of connections.
The bus has 4 lines: VCC, Ground, Data+, and Data-.

USB Pins

6. RS-232 – Recommended Standard 232: The RS-232 is typically connected using a DB9 connector,
which has 9 pins, out of which 5 are input, 3 are output, and one is Ground. You can still find this so-
called “Serial” port in some old PCs. In our upcoming posts, we will discuss mainly about RS232 and
USART of AVR microcontrollers.