Using USART or UART on a Microcontroller

First, what is the difference between these terms, UART and USART? UART stands for Universal Asynchronous Receiver and Transmitter, and USART means Universal Synchronous and Asynchronous Receiver and Transmitter. Most microcontrollers today, like PIC and AVR, have USART, but the Synchronous function is not often used as they have other synchronous devices like I2C and SPI. So this post will concentrate on asynchronous transmission, which is the same on both devices.

Baud Rate
Asynchronous data transmission means without a separate clock signal, so both ends of the link must know what the data transfer rate should be, otherwise garbled transmission will occur. This is known as the baud rate, which is usually up to 115,200 bits per second when microcontrollers are used, although they can be much slower, such as 4,800, 9,600 or 19,200. Note that each step is double the last speed and the seemingly odd values are due to historic reasons.

You don’t actually have to use them but these are the standard values that all serial devices can be set to. If you were creating your own units at both ends of the link, you could use any baud rate you like, but would have to calculate how to setup the value in your microcontroller. The faster the baud rate, the more likely errors are to occur at the receiver so this is a trade-off between speed and reliability.

When using the USART on a microcontroller the error rate is also affected by the crystal frequency of the system as this affects how accurately the USART can generate the correct baud rate. For example, when using a 9.216MHz crystal, this divides exactly by the baud rate figures, like 9,216,000 / 19200 = 480, a whole number. A 9MHz crystal would give a fraction (9,000,000 / 19200 = 468.75) and this will create more errors on the UART. Look in your microcontroller datasheet for tables of UART errors at different baud rate and crystal frequencies. Errors above 0.2% can create unreliable transmission results, so you need to select your baud rate and crystal appropriately.

Start, stop and parity bits

Once we have chosen the baud rate, the other parameters we need to set to be the same at both ends of the link are start, stop and parity bits. All UART frames must have a start bit (1 to 0 transition) and either 1 or 2 stop bits (raise line back to 1), generally 1 stop bit is fine. Parity is a simple error check, and can be even or odd. If all the data bits are added together, the result will be odd or even and this is added to parity bit to give even or odd parity as selected.

With even parity, the parity bit is set to 1 if the number of ones in the data (not including the parity bit) is odd, making the number of ones in the entire set of bits (including the parity bit) even. If the number of ones in a given set of bits is already even, it is set to a 0. The reverse is true for odd parity. Parity is not a very good error check, and most designers use a checksum after a number of bytes are transmitted instead, so setting the UART to no parity is common.

Data bits

The default setting is 8 data bits per frame, but it can be set to between 3 and 9 if the type of data you are using needs it. Most applications use 8-bit or byte data.

Errors

The UART can generate errors, like framing errors if the correct number of bits aren’t received, parity errors if parity bit is wrong or overrun errors if data is too fast. In most microcontrollers, these cause a flag to be set in the UART control registers and these can either be polled or set to generate an interrupt. In simple applications, when communicating with one constant device, these don’t generally occur and are often ignored.

Flow Control

Most applications that are talking to one known device can ignore flow control, but if you are getting overrun or missing data errors then you may need to worry about it. This typically occurs if the receiving device has to do lots of processing with the data and the amount of data you are sending changes a lot. If you are sending a block of data that the receiver will then process, make the transmitting microcontroller delay before sending next block or get receiver to send an acknowledge when it is ready. If this isn’t practical, you may have to use flow control, which can either be hardware (extra lines – Data Ready) or software (Xon/Xoff).

Hardware

The main thing to remember is that the receive and transmit lines must be crossed, so RX pin on each device is connected to TX on the other, that is RX-TX, TX-RX not wired RX-RX, TX-TX. The same applies to hardware flow control lines if you have implemented them.

Most serial communications is carried out at either TTL level (0-5V) or RS-232 levels (+13V, -13V). The UART transmission and everything we have discussed is the same for both as RS232 is only a hardware standard.

If you are communicating with another microcontroller or a serial device that can use TTL levels, then use that. If you want to talk to a PC serial port or other RS-232 standard device, then you will need to setup RS232 and the easiest way to implement it is to use a specialist chip, such as MAX232 or ST232, as this deals with all the voltage conversion for you.

Click here for an example of how to setup and Use a USART in AVR C code.

One thought on “Using USART or UART on a Microcontroller”

Leave a Reply to kiranvarma-educations Cancel reply