Mastering Embedded Software Timers: Two Practical Timeout Designs

Software Timeout Mechanisms

Embedded software often needs to handle time‑outs or periodic actions without blocking the CPU. The following two designs use a hardware timer as a time base, allowing software timers and callback functions to be executed efficiently.

1. Background

During embedded program development, timeout handling is common: when a specified time elapses, the program must perform certain actions. Two design schemes are introduced to achieve this.

2. Scheme One

Idea: Use a timer interrupt that increments a global variable TICK every interrupt interval t. When starting a timeout, record the current STARTTICK. During execution, continuously read the current TICK and compute the elapsed time as (ENDTICK‑STARTTICK)*t.

The timer interrupt increments s_u32TCNT each t seconds. The following diagram shows the interrupt handling (image omitted for brevity).

A structure stores the start and end tick values:

When a timeout is needed, the current s_u32TCNT is read into u32EndTimeTick. The difference between u32StartTimeTick and u32EndTimeTick determines whether the timeout has occurred. Example code (illustrated in the original image) follows the same logic.

3. Scheme Two

Idea: Register a callback function for each timeout. The timer interrupt calls each registered callback; the callback simply decrements a counter TCNT. When TCNT reaches zero, the timeout flag is set, and the application checks this flag.

Multiple callbacks can be stored in an array. The registration and callback definitions are shown in the diagram below:

The timer interrupt iterates over the callback array and processes each entry:

4. Comparison and Summary

Scheme 1 advantages: minimal work inside the interrupt, easy to understand code. Disadvantages: the application must compute the tick difference each time, which can reduce efficiency.

Scheme 2 advantages: timeout handling is encapsulated in callbacks, offering better extensibility and higher execution efficiency. Disadvantages: the interrupt must traverse all registered callbacks, increasing interrupt workload.

STM32 Timeout Design Example

Typical unreliable busy‑wait code:

while(!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED));

A more robust timeout definition for the external crystal start‑up:

#define HSE_STARTUP_TIMEOUT ((uint16_t)0x0500) /*!< Time out for HSE start up */
do {
    HSEStatus = RCC->CR & RCC_CR_HSERDY;
    StartUpCounter++;
} while((HSEStatus == 0) && (StartUpCounter != HSE_STARTUP_TIMEOUT));

Timeout implementation for I2C EEPROM read/write:

uint16_t i = 0x0FFF;
while((!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED)) && i) {
    i--;
}

These examples illustrate how to replace blocking loops with timer‑based timeout mechanisms in STM32 firmware.