Time: delays, timers and PWM

The blink example waits with a delay function. Inside, the crude version is a loop that counts to a large number and does nothing. It works in a debug build, then with optimization on it takes no time at all: the compiler sees a loop with no effect and removes it. Marking the counter volatile stops that, but the real lesson is that timing should come from hardware, not from counting instructions.

A hardware timer is a counter that ticks from a clock. Two numbers set its rate. Taking an STM32 as the example: the prescaler divides the input clock, so with a 72 MHz clock and a prescaler value of 71 the counter ticks 72 MHz / 72 = 1 MHz, one million times per second. The auto-reload value, called ARR, is where the counter wraps to zero. The period is ARR + 1 ticks, so 1 MHz ticks with ARR = 999 give an update 1000 times a second. Other chips divide differently (AVR has a fixed set of dividers, the RP2040 a fractional one), so check the timer chapter of your chip's manual for the exact formula.

Nearly every Cortex-M chip also has SysTick, a simple 24-bit timer that counts down and reloads. Most libraries use it for a millisecond tick, which gives you a millis() style clock. With that you can wait without blocking: remember when something started, and check on each loop whether enough time has passed.

PWM, pulse width modulation, is a timer trick: the output pin goes high at the start of each period and low when the counter reaches a compare value. The fraction of the period the pin is high is the duty cycle. Compare 500 out of 2000 counts is 25 percent. Switch fast enough and an LED looks dimmed, a motor runs slower, a servo moves to a position. The pin is still only ever fully on or fully off.