Software Based UART Speed Test

UART is one of the most common and useful ways to communicate with the external world. But, there are a limited number of hardware UARTs available, then what to do if you need more? without add any other hardware? If you have some GPIO pin available, Software-based UART is the answer!

Software-based UART can be a solution, but with limits. On a Linux system, that is not a true realtime operating system (even with the RT preempt patch), is possible to implement a soft-UART? could the GPIO speed be precise and fast enough to achieve at least a 9600 8N1 UART? Well, let's see!

As the User-Space Vs Kernel-Space GPIO Speed test show us, from the user-space we have 100 uS as the fastest and controllable speed for a GPIO pin. A 9600 8N1 UART means: 104 uS for each bit, with 1 start bit and 1 stop bit, totalizing 10 bits in 1040 uS = 1,04 mS. So yes, the speed is enough.

The image below show the ASCII 'Z' character (code 90) being transmitted through the GPIO pin of a Broadcom BCM2835 SoC (Raspberry Pi / Raspbian) from an user-space C application:

The UART TX signal remain high until the start bit (first red '0') is sent, followed by the 8 bit character data 01011010 (ASCII 90 'Z') ending with the stop bit (last red '1'). So yes! is possible, right? Well... although this worked, won't work everytime. Remember, Linux is not a RTOS, this application is subject to be preempted any time, and if this happen in the 1,04 mS transmission window, the character received by the RX will be incorrect.

Why only 9600 kbps? 

If 100 uS is the minimal time, 9600 (104 uS) is the limit, because any baudrate above this value will need less than 104 uS, on the other hand, the transmission window would be smaller, suffering little with the preemption. 4800 kpbs and less would be worst, because the transmission window would be larger, suffering a lot with the preemption.

That's all, now you can see this working, playing with an user-space application or kernel-space driver!