AN2781
Application note
UART emulation software in STM8S and STM8A microcontrollers
Introduction
This application note describes how to emulate the UART behavior and functionality using
routines in STM8S microcontrollers. The UART peripheral is emulated on hardware that has
the capture & compare interrupt capability. Such emulation is useful in applications that
require more than one UART, or when the dedicated serial communication hardware
peripherals are being used in another way.
This software solution is suitable for standard full-duplex speeds of up to 57 600 Bd for the
core running at 24 MHz or, of up to 19200 Bd for the core running at 16 MHz. Its main
feature is that it runs in the background with a time reserve, so that the main process stream
can continue and control the rest of the application processes. The higher communication
speeds can be achieved when polling and controlling I/O pins in the main stream, but, as a
result, the control of all other application processes is sidetracked while receiving or sending
a message and the full-duplex capability might even be lost.
Standard data frame formats are supported, as well as options like parity, ninth data bit and
double stop bit. Double data registers, noise detection logic, frame generation and overflow
logic are implemented with minimum MCU hardware usage.
A firmware package is delivered with this document. It contains the complete C source code
so that the user can compile, link or modify it as necessary. It also includes a number of
precompile configurations to help optimize the compiled code.Doc ID 14762
August 2011 Doc ID 14762 Rev 2 1/14
www.st.com
Contents AN2781
Contents
1 Principle of the software solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1 Application interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Precompile interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Firmware package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4 Test environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5 CPU workload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6 Other solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7 Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2/14 Doc ID 14762 Rev 2
AN2781 List of tables
List of tables
Table 1. Status register bit definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Table 2. Auto reload register settings (TIM3_PSCR=0) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Table 3. List of the files included in the firmware package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Table 4. CPU usage and maximum latency times for a speed of 57.6 KBd when the
core runs at the maximum HSE frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Table 5. CPU usage and maximum latency times for a speed of 19.2 KBd when the
core runs at the maximum HSI frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Table 6. Document revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Doc ID 14762 Rev 2 3/14
List of figures AN2781
List of figures
Figure 1. Capture & compare timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4/14 Doc ID 14762 Rev 2
AN2781 Principle of the software solution
Tx
TCC OVF
TCC CC
Rx
Bit sampling (TCC OC)
Start bit detection
(TCC IC)
ai15179
1 Principle of the software solution
All transmit and receive processes run in the background. They are all timed by a single
CPU capture & compare timer. The associated input capture pin is dedicated to receiving
data. Any general-purpose output pin can be used for data output. The overflow period of
the timer equal to half a bit by setting the autoreload register of the timer. Figure 1 illustrates
the timing diagram.
Transmission is based on TCC overflow interrupts. After a byte is stored into the transmit
buffer, an internal transmission request appears and the nearest OVF interrupt is used to
start the current transmission. So the maximum latency for transmission start could be half a
bit. This is because the same timer is used for independent (unsynchronized) transmit and
receive processes. Every pair OVF (overflow) interrupt controls the consecutive edge
changes of the transmitted signal on the dedicated output pin until the end of the frame
transmission. Odd OVF interrupts are discarded. Any CPU pin with the output capability
could be used as a transmit pin.
Figure 1. Capture & compare timing
The receive process uses the capture and compare feature of a single timer channel and its
dedicated pin. Initially, the input capture is performed at the channel. After detecting the first
falling edge, the value captured in the TCC capture registers is then used for compare
purposes because the channel input capture functionality is switched to output compare
(without affecting the output pin of the channel since it is not enabled). Due to the half-a-bit
overflow period of the timer, the nearest output compare event must point to the middle of
the first receive bit (start bit). Three consecutive samples are performed at the input pin at
that moment and if, for each of them, a low level is detected, the correctly received start bit is
evaluated. The receive process then continues watching every next odd output compare
interrupt. The three samples are performed with noise detection logic for the other received
data bits until the end of the current receive frame. All even compare interrupts are
discarded. After the stop bits of the frame are sampled, the dedicated timer channel is
switched back to input capture mode and waits for the next frame start condition. The
detection of noise while the stop bits are being sampled always causes a frame error. If
noise is detected in the start bit, the receive process is aborted and the Rx pin switches
back to input capture mode and waits for the next falling edge capture.
Doc ID 14762 Rev 2 5/14