When we need some feedback from microcontroller usually we use USART. It allows to output messages, debug information to terminal screen. Also data can be sent to MCU same way. For this purpose STM32 microcontrollers have more than one USART interface allowing to have multiple streams of data output and input.

 

USART interface is designed to be very versatile allowing to have lots of modes including LIN, IrDA, Smart card emulation, DMA based transmissions. But for now lets focus on standard USART communications we we could send and receive messages from terminal window.

STM32F100RB microcontroller in Discovery board has three USARTs (USART1, USART2 and USART3). Other higher level STM32 microcontrollers have even more. USART1 is connected to APB2 bus while other USART’s are located on APB1. Every USART has a two DMA channels allowing data transfer between memory and Rx/Tx. Each USART has ten interrupt sources and all are mapped to same NVIC channel. So it is up to code to find out what triggered an interrupt. This is done by identifying flag in status register. Why don’t we take a real example and see how things work.

For this we are going to program USART1 in our STM32VLDiscovery board. Discovery board only comes with naked pins that we have to connect to USART level converter like RS232 or USB. For this example we are going to use widely acceptable FT232RL based TTL to USB converter.

The FT232RL is a USB to serial UART interface with optional clock generator output. It’s the essential tools for establishing communication between PC and mostly MCU.

 

 

So we connect board pins to converter as follows:

STM32VLDiscovery PA9 to Rx of FT232RL board

STM32VLDiscovery PA10 to Tx of FT232RL board

STM32VLDiscovery 3.3V to VCC of FT232RL board

STM32VLDiscovery GND to GND of FT232RL board

 

Using STM32F10x_StdPeriph_Driver library programming task becomes very easy. Lets use our template from previous example. This time we are going to add couple more files to project called usart.c and usart.h. Here we are gonna to write USART initialization function and byte read and write routines. Lets start with Initialization:

Here we have a standard situation where we have to take care of enabling peripheral clocks. We know that USART1 is located on APB2 peripheral bus as GPIOA and AFIO. All these are needed because USART1 pins alternate functions of port A. These has to be clocked in order to use them:

Next task is to set up USART pins where Tx pin should behave as alternate function push-pull while Rx floating input. Once pins are set we need to take care of USART clock. As we are going to use standard set up we can use function helper that does this by setting default values:

 

Then we can set up USART specific settings by selecting baud rate, data word size, stop, parity bits and enable Rx and Tx modes. All this is done by setting values in USART_InitStructure as seen above. Last command simply enables USART1. From this moment USART1 is up and ready. New we can proceed to sending and receiving data functions:
We call them Usart1Put and Usart1Get functions that sends and receives data bytes. You can see in both functions that it is important to wait for transmission complete before sending next byte or storing received data. While loops simply check for proper flags to be set.

In main program we can call these functions to send and receive single bytes of data as follows:

 

Being able to send single byte is a good start where you can wrap this function with loops in order to send strings and so on. But what about sending numbers or specially formatted strings that would include some variable data. Writing these functions would be time consuming and meaningless because this has been done long time ago and is widely used. These are called iostream functions where data is sent by using standard streams with functions that allow formatting strings as you like. I/O streams originally were designed to support operation systems where data could be read from keyboard and sent to display or other output device. It seems that they fit well in embedded systems too with some tweaking. GCC tool chain uses a newlib C library that originally is used in Redhat and there fore it’s not adapted for microcontroller where basically is no operating system. (Opposite situation is with AVR GCC tools where avrlibc is specially adapted to support AVR microcontrollers and works out of box). So when we start dealing with OS dependable functions we face some stubs. Stubs are called system call functions that are served by operating system. As in microcontroller basically there is no OS these functions face dead-end leading to compile errors. Basic trick to avoid this we need to take care of these syscalls by writing some implementation where many of them can be dummy. Understanding them all and writing your own implementations would be to hard – at least in the beginning, so there are ready sources that can be used. I prefer to start with newlib_stubs.cdeveloped by nanoage.co.uk. This seems to work fine with I/O stream functions. There is a dozen of other system functions but most important are _write(), _read() and _sbrk(). _write function takes care of writing characters to stdout and stderr; _read() is to read from stdin; and _sbrk() is needed for malloc related functions where it is important to know if dynamic memory doesn’t collide with stack. In _read() and _write() functions we need to implement our byte send and read functions so when we call printf() function we could output string to USART:
and for writing to stdout and stderr:
simply speaking you can direct streams where ever you want (LCD, SPI, I2C, etc.) by putting send/receive byte functions here.

After setting this we can send formatted strings and read any type of data by using stdio functions:

 

And results in terminal screen:

In the next part we will be dealing with interrupt based buffered communications.