Protocol: UART — Universal Asynchronous Receiver / Transmitter
The first communication protocol embedded systems enthusiasts should perfect.
* Disclaimer — This blog post is written not to teach or understand the workings of UART of different microcontrollers or embedded IC’s. The main aim of this article is to point out the various use cases of UART communication and to help understand its limitations and the learning that it provides to developers who have used it.
Many a times users of our Bolt IoT platform want to interface a wide range of sensors with the development board , but are not able to do so as a few sensor require communication protocols which Bolt does not provide. For example DHT11 temperature and humidity sensor. A simple work-around for this is interfacing the sensors first with an Arduino board and then communicating the sensor data from the Arduino to Bolt so that it can be uploaded to the Bolt cloud for further processing. This communication between the two boards is made feasible by the use of the UART.
Uses Cases: Why UART is one of the most important protocols for product developers and makers alike.
Let’s list a few projects and see the peripherals that are required for the same, which use UART:
1) GSM / GPS modules like SIM900/800 uses UART communication for accepting AT commands that are used to control them and gather the replies. Example: In regions where WiFi is not available we had to interface Bolt with a GSM unit for global monitoring and control.
2) Identification projects that use RFID modules can be built with modules that have an UART interface. This even applies to some Finger Print sensors.
3) To communicate between a microcontroller and your PC (desktop/laptop) we generally use a USB to UART converter for communication, which converts USB communication to UART message from the PC to the microcontroller and vice versa.
4) Apart from the above many ICs also act converters from many standard peripheral communications protocols like SPI and I2C to UART, thus even those peripherals that do not have an onboard UART can still use it.
5) Even for long range wired communications we can convert UART protocol using an external IC to RS232 or RS485, the latter of which can be used for wired communication @100 kbits/s up to 1.2 Km.
Now I would like to elaborate on a few terms closely associated with the use of the UART.
Asynchronous : Now as clear as this term may seem to most with a well versed vocabulary, with respect to UART it means that the two microcontrollers or the microcontroller and its peripheral involved in communicating over this protocol, need not be working at the same clock frequency.
For example, let us say we have microcontroller-A(μA) which is running at 80Mhz frequency (e.g.ESP8266 used on Bolt IoT) which needs to communicate microcontroller-B(μA) which itself is running at 16 Mhz (Atmel controllers used for Arduino boards). This creates a clear problem in communications which is, if μA sends data to μB (when both are transmitting and receiving at full speed) since the speed of reading of μB is around 1/40th the speed of μA that means by the time μA has sent all its data μB will have read only approximately 2% of sent data. The reverse case μA will have stopped reading much before μB can even finish transmitting all the data it needs to send.
UART communication tackles this issue by ensuring both parties involved agree upon a pre-defined rate to transmit and receive data, which is termed as the Baud rate.
Baud rate: Often there is a confusion involved with this term, and before we proceed I would like to clear that out for few of the readers who may still have it.
To explain this lets say μA is sending 8bits of data to μB. It takes x amount of time to transmit all of the bits to μB.
This means every bit is being sent to μB at the speed 8/x bits per second (bps). This is known as the bit rate involved in the communication and should not be confused with the term baud rate.
Baud rate, is the rate at which the binary bits of data being communicated are supposed to change i.e. undergo a transition from 1 to 0 or 0 to 1. When both microcontrollers know the baud rate at which data is being communicated at, they can sample the voltage present on the communication wire at the rate of 1/(baud rate) per second and determine whether the data bit is 1 (if sampled voltage is 5v) and 0 (if sampled voltage is at Ground or 0V) *Assuming TTL logic.
Hence if the baud rate is 1, only one bit of data will be sampled and read per second. Even if the μA has sent 8bits to μB in one second, μB will only sample the voltage once in that duration and whichever voltage value it comes across at the time of sampling will be read as a valid single bit of data.
So now lets me explain in brief how the UART protocol uses the baud rate to tackle the issue of Asynchronous communication.
Now consider the most commonly used baud rate i.e. 9600. This means that the data can sampled at the speed of 9600 samples per second in other words the data stream can undergo 9600 transitions between 0 and 1 per second. This thus implies that effectively 9600 data bits can be read per second and 9600 data bits can be transmitted per second. This tells us by agreeing upon the Baud rate beforehand we are also setting the maximum bit rate for communication.
Error Rate : This is calculated based on the Baud rate agreed upon and Baud rate that the microcontroller or peripheral can actually be set at due to internal hardware limitations. The formula for the same is (calculated in percentage)
Error% = ((Actual_baud/Baud_desired) — 1) * 100%
Example : We want a baud rate of 2400 but the microcontroller practically can only give an accurate baud rate of 2396 , we get.
Error% = ((2396 / 2400) — 1) * 100%
Error% = -0.16%
UART Working (In brief):
Before two devices can communicate using this protocol they must
1) Agree upon a pre-determined baud rate at which the communication will take place at.
2) Ensure that the bit transitions adhere to this rate.
3) Have two dedicated lines(wires/pins) for Transmission and reception
a. UART protocol is designed to be an effective full duplex communication, i.e. each device is capable to transmit and receive simultaneously.
4) Make sure the communication error rate is less than +/- 2%.
a. For Atmel ATMega series of controllers there is a quick reference guide for error rate and oscillator frequency at http://wormfood.net/avrbaudcalc.php
5) For UART communication we use a null modem or cross over cable which simply means that the Rx(Receive pin) of μA is connected to Tx(Transmit pin) of μB and Tx pin of μA is connected to Rx pin of μB.
a. Note Having a common ground is important for all types of wired communication between 2 or more microcontrollers and its peripherals.
Now once all the five points above are covered the UART communication can take place. Few additional details like data packet size , start bit and stop bits, and for error handling the use of parity bit can all be understood by referring to the following link.
https://learn.sparkfun.com/tutorials/serial-communication
Learning: As you begin to use the UART for communication you will face many issues, debugging these will largely improve your coding sense and logic ability.
1) Code timings and delays:
a. UART communication being asynchronous, your code logic must incorporate a communication flow that should
i. Not block other segments of running code
ii. Make sure that incoming bytes are being read before the FIFO buffer at the dispose of the receiver becomes full, this will cause loss of data.
b. This forces the user to choose between reading on the fly i.e. the main loop of your is dedicated to reading the UART and other code runs based on preset delays after reading is done or
c. Reading the UART in an interrupt based subroutine which is triggered if the Receiver Buffer has received a Byte or
d. Reading the UART in an interrupt based subroutine which is triggered after the Transmitter has sent a command to the peripheral and needs to wait for the reply before further execution.
2) Using GPIOs for handshaking.
a. This implies that sometimes some peripheral may want to request data without sending data itself, in which case it may change the state of a predetermined IO pin indicating the request.
b. Or the peripheral wants to send data and the master needs to be interrupted / made aware of the communication by changing the state of the IO pin.
c. The same logic can be further extended as a way of telling each other that
i. Communication was received and has been processed
ii. Indicate that the device is ready for the communication to start
iii. Communication cannot currently take place
3) Apart from above two , you will face many more issues during communication which may just seem mind boggling in the beginning , but the solutions to which you will later realise are sometimes just a question of adding one line of delay statement in your code. This process will definitely sharpen your debugging skills.
So finally we’ll look at the limitations UART protocol has.
1) Large chunks of data which need to transferred at a very high rate (bps) sometimes face limitations when using UART depending on various factors such as the clock frequency of the microcontroller.
2) For high speeds the wires used for communication also need to be very short otherwise there are high chances of signal corruption due to noise.
3) Error handling is only limited to addition of parity bit.
4) Its recommended of staying within a limit of 2% error rate.
In conclusion, UART is a very easy to start off with communication protocol and is designed for simplicity. Learning it will build a solid base before moving on to coding for other protocols like SPI and I2C.
If you are looking for a hands on experiment on UART with Bolt then check out Instructable Link: http://www.instructables.com/id/Interfacing-Bolt-With-Arduino-Bolt-UART/
Till then, if you are you looking to build an IoT product for yourself or looking for an end-to-end IoT solution for your company, then I will be glad to have a chat with you and guide you on how to go about it. Please fill a short form at www.boltiot.com/app/consult.php and we can schedule a call.
