Serial Communication – Introduction
Hey folks! Guess what? It’s now time for one of the most desired tutorials on maxEmbedded – the Serial Communication series! In these series, we will discuss the basic concepts of serial communication; the loopback test, the USART/UART of AVR and then we will proceed towards implementing the SPI and I2C in AVR.
This post will cover the basics of serial communication and will be mostly a theoretical topic. We will do some practical stuff from next tutorial onwards. Lets have a glance at the contents.
- What is Communication?
- Why do we need Communication?
- Serial Communication
- Parallel Communication
- Serial vs Parallel Communication
- How is Data sent Serially?
- Serial Transmission Modes
- Serial Communication Terminologies
- The Catch in Serial Communication
- UART and USART
- Serial Communication Protocols
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.
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 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.
|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 transmit data||3. Higher number of cables required|
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:
- Bit Rate: It is the number of bits that are transmitted (sent/received) per unit time.
- 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
- 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:
- 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.
- 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.
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.
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.
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:
- 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.
- Simplex Communication: In this mode of serial communication, data can only be transferred from transmitter to receiver and not vice versa.
- 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.
- 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!
- 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 same baud 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:
- 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.
- 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:
- 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.
- 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.
- 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.
- Ethernet: Used mostly in LAN connections, the bus consists of 8 lines, or 4 Tx/Rx pairs.
- 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-.
- 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.
So that is it for now folks! We will be discussing about RS-232 and its basics in the next post! Don’t forget to post your comments and questions down below! And yes, subscribe to maxEmbedded and stay tuned! :)
VIT University, Vellore
QC and Mentorship By-
Arizona State University