UART - Serial communication (2024)

Universal Asynchronous Receiver/Transmitter orUART for shortrepresents the hardware - integrated circuit, used for the serial communication through the serial port.UART is astandalone integrated circuit (IC) but also as a part of microcontrollers.

It is important to understandthe difference between standalone UART modules and the UART modules integrated in MCU modules, and how MCU modules usually control the output of UART, while standalone modules usually do not. Conversion of the UART's output to physical signal on transmitter side and vice versa, is done by a separated circuitdepending on the communication standard used, (RS-232, RS-422,RS-485). All ofthese standards define different methods for physical signal generation which also differs from an MCU's TTL class of digital circuits on the output.

In reality, this means that additional circuit is needed to achieve communication between MCU's UART module anda PC peripheral device or PC serial port - just because there aredifferences in transmission methods. For example, in the case of TTL, voltages on the UART output can be in range of 0 V up to Vccwhere Vcc represents logical 1 and logical 0 is 0 V on output. On the other hand according to the RS-232 logical 0 is positive voltage between 3 and 25 V and logical 1 is negative voltage between -3 and -25 V.

Therefore from the software side MCU's UART module and PC peripheral are the same and most of the embedded devices are easy adaptable to communicate with the PC serial port or even USB which waswhatreplaced the RS-232 when we talk about PC world. This is also the reason why RS-232 is the most importantstandard from the point of view of an embedded developer. Some rules from RS-232 found it's own usage in the embedded world - Data Flow Control for example, which will be explained with more details later. Anotherreason is the desire by hardware producers tomake theirown products also adaptable to the PC peripherals with addition of just one circuit.

Communication

Because the UART is the device used for serial communication, it is good to explain what itstands for. Probably the shortest definitionwould bethat serial communication stands for the process of sending data one bit at a time, sequentially, through the bus or communication channel. Shift registers are afundamental method of conversion between serial and parallel forms of data, and therefore are an unavoidable part of every UART. Just likeserial communicationhas two primary forms, (synchronous and asynchronous) there are also twoforms of UART, known as :

UART - Universal Asynchronous Receiver/Transmitter
USART - Universal Synchronous/Asynchronous Receiver/Transmitter

The asynchronous type of transmitter generates the data clock internally and dependent to the MCU clock cycles. There is no incoming clock signal that is associated with the data, so in order to achieve proper communication between two modules, both of them have to have the same clock cycle length, which means that they must work on the same baud rate.

The data is normally transmitted in the form of a byte. On the other hand, a synchronous type of transmitter generates a clock used by the receiver side to recover data from the stream without knowledge of the transmitter's baud rate. In cases where a separated line is used to carry the clock signal, UART can achieve very high transfer rates, up to 4.000.000 bits per second which is high above the UART limits. USARTdata transfers are usually in the form of a block.

It is important to say that a USART module, (because of higher speed and ability to transfer blocks of data) can generate data in a form corresponding to many different standard protocols such as IrDA, LIN, Smart Card etc. The ability to generate clocked data allows the USART to operate at baud rates well beyond a UART's capabilities. USART does encompass the capabilities of UART. Though, and in many applications, despite having the power of a USART, developers use them as simple UARTs, ignoring or avoiding the synchronous clock generation capability of these powerful peripherals. No wonder so many people use the terms as though they were synonyms.

UART in MikroC

All of our MikroC compilers have UART library for easier access to the UART module built into the MCU. As we said earlier not all MCUs have a UART module but when you have that kind of MCU there are software UART libraries which use the so-called "bit-banging" technique to emulate a real UART modulewith the usage of the simple GPIO pins. As you probably conclude the real hardware UART module and software emulation can't be compared if we talk about performance, so the software one should be used only in cases when the MCU has no available UART module.

If we talk about an MCU's UART module, which is the most common case for embedded developers, every module has it's own set of registers responsible for the different aspects of the communication, configuration and state of the device. The organization of these registers inside the MCU vary from the platform to platform. Sometimes an MCU on the same platform doesn't have thesame registers names for UART modules but MikroC makes all platforms look the same for thedeveloper. The function set for UART control is pretty same on all our compilers and there are just few differences in the initialization routines.

The very first thing needed to do is initialization of the UART module. All compilers have two possible ways to do this: UARTx_Initand UARTx_Init_Advanced. UARTx_Init is common for all compilers and requires the one parameter which represents the baud rate of the UART module. Therest of the configuration parameters are the most common UART configuration -8N1- 8 data bits, no parity and one stop bit. UART_Init_Advanced allows us to configure every aspect of the communication when it is needed.

UART1_Init_Advanced( 115200, _UART_8_BIT_DATA, _UART_NOPARITY, _UART_ONE_STOPBIT, &_GPIO_MODULE_USART1_PA9_10 );

This code shows an example of the initialization routine on the STM32 microcontroller. Advanced initialization routine arguments vary from platform to platform but it is pretty understandable what every argument means,and compared to the raw registers, editing it is less painful especially if you are new inside this world or you just have switched to your favorite platform.

To continue our journey let's go to the transmission process and functions UARTx_Writeand UARTx_Write_Text. It is good to know whatactually goes on when we call some of these functions. Both of the functions are doing the same thing except UARTx_Write_Textis sequentially writing until it arrives to the end of the string (null terminator). When the write function is called the argument is copied to the UART's transmission (TX) register. After that, it depends on the type of MCU, usually a few additional actions, like asserting transmission bits inside the control register, are needed to start the transmission process. All of this is handled by theUARTx_Writefunction.

Sometimes this function can rewrite the content of the TX register before the data from register is shifted out to the bus. If we want to be sure that we have avoided that occurrence function UARTx_Tx_Idlecan be used to check if theUART module has finished the transmission of the TX register. You might be wondering why this check is not included to the existing write function - the answer is, sometimes we want to rewrite existing content of the TX register. Also in that case UART_Writebecoming a blocking function which is not so good when we have no multiple threads.

if( UART1_Tx_Idle() ) { UART1_Write( 55 );}

In the case of UART, it is much harder to handleits' reception process. Compared to the previous explained serial communication protocols like I2C or SPI where we have a master on the bus which initiates the transfer, UART is totally different. Reception of the data by UART module starts with reception of the signalbyusing theshift register process for populating the UART receive register (RX). After that, a few additional occurrences happen, for example UART asserts a bit in the UART control register to inform the user that new data has arrived. It is important to say that every new data received will overwrite the existing content of the RX registers. This means that if we haven'talreadyread the RX register the data is lost.

This problem can be solved in two ways :

Polling
Interrupt

Polling is much more understandable. We are constantly querying the UART control register for the information "has new data arrived or not?". That is actually what theUARTx_Data_Readyfunction is for. When the query result says that there is new content inside the RX register, then data can be obtained with theUARTx_Readfunction.

while( 1 ){ if( UART1_Data_Ready() ){ receive = UART1_Read(); break; }}

This actually blocks the execution of the whole program until data becomes available, which is a very bad, dangerous and inefficient solution. This can only be acceptable in thecase of multi-threading embedded where we can have threads reserved only for polling.

A much more efficient but at thesame time more complex way is theusage of interrupts. The UART module inside the MCU can be set up to executea special kind of function called an Interrupt Service Routine (ISR) in the case of some event related to the UART module itself occurring.The interrupts are a special kind of MCU routine which will be processed in one of the next articles, but for now, we are goingto justexplain how interruptscan be used to avoid polling.

When we define the ISR and enable the interrupts, inside the ISR we can process the received data and achieve the same thing we did with polling without any blocking process. The ISRwill be called any time the UART module receivessome data so it is important to say that it is not acceptable fora lot of timeto bewasted inside of theISR. The best solution is that theISR routine is used to just store the received data to the buffer which will be later processed outside of the ISR. Let's see that in the example on the ATMEGA32.

sbit RTR at PORTA5_bit; // RTR pin sbit CTS at PORTD2_bit; // CTS pinvolatile bool flag; // Process flag volatile char received[8]; // Buffervolatile unsigned int count; // Buffer counterextern void process_data( char data );main(){ DDA5_bit = 1; // Set RTR as output DDD2_bit = 0; // Set CTS as input UART1_Init( 9600 ); // Peripheral serial UCSRB |= ( 1 << RXCIE ); // Enable UART RX interrupt SREG |= ( 1 << SREG_I ); // Enable Global interrupts while( 1 ) { if( flag ) { while( count-- ) // Process the data process_data( received[count] ); flag = false; } } }void UART_RX_ISR() iv IVT_ADDR_USART__RXC ics ICS_AUTO // ISR function{ char tmp = UART1_Read(); if( ( tmp == 13 ) || ( count == 8 ) ) flag = true; else received[count++] = tmp;}

Well this looks good but if we look closer - it is not so safe. ISR is accessing the global variables which are also used by process_dataso the program's behavior is not predictable at marked lines. Let's imagine the process_datafunctionrefreshing the TFT screen and writing the characters received. That process takes much more time so the chance that something went wrong are increased so far. The simple solution might be copying the content of the buffer to another buffer which is not used in the ISR but even then the chance still exists and alongside with that we are capturing one more part of the RAM for it.Now, remember the part from the beginning with RS-232 rules for data flow controls?

When processing of received data takes a long time, data flow control should take over, stopping the data flow from DCE until the DTE processesthe collected data. Using data flow control will avoid losing bytes received, while the DTE isstill processing previously received bytes. Of course this is the case when DCE supports it. From the DTE side, wherethe MCUusually isin our case, RTS (RTR) and CTS lines are, as we said, nothing more than a GPIO. This also means they are easy for handling, especially in cases when DCE firmware supports the handshake method for the "negotiation".

...void send_command( char *buffer, unsinged int count ){ while( count ) { if( !CTS ) { // If DCE is ready send data UART11_Write( *buffer++ ); count--; } }}main(){ ... while( 1 ) { if( flag ) { RTS = 0; // DTE is not ready because of data processing while( count-- ) process_data( received[count] ); RTS = 1; // Data processing finished DTE is ready again flag = false; } } }...

Careful reading of the datasheet about hardware flow control is needed because, as we said earlier, there are two different methods for this. There also might be some timing requirement by the device we are using. For example, sometimes with assertion of the RTR the data flow doesn't stop immediately. DCE needs time to detect the signal and stop the stream and therefore something must be implemented to handle this problem.

UART is alsovery useful for debugging. It is usually used to log the data on the reception. So if we imagine that our ATMEGA32 has two UARTs we could do something like this.

void UART_RX_ISR() iv IVT_ADDR_USART__RXC ics ICS_AUTO // ISR function{ char tmp = UART1_Read(); ...#ifdef _DEBUG_ UART2_Write( tmp );#endif}

This last one was just an example because ATMEGA32 has only one UART module but usually MCUs have more than one. In addition, it is good to say that, we should initialize "debug" UART with a higher baudrate than UART used for the communication with the peripheral. This method is extremely usable in cases like the previous one where we are retrieving data through the interrupt because the debug breakpoints can't stop the data flow from the DCE.

Summary

Serial communication is a fundamental type of communication between two devices and is used everywhere around us. I2C, SPI, CAN, LIN and so on are all some kindof serial communication. Serial communication is simply the connection between PC and the embedded world allowing PC software developers to handle embedded devices and vice versa for embedded developers. MikroElektorinka offers a wide spread of devices that are excellent for learning and exploring the world of UARTs.

References

RS-232 Wikipedia