Start with the timer input clock

This article uses an up-counting, edge-aligned timer time base. The value you need is the clock actually entering the timer (timerClock), in hertz. It may differ from the CPU clock and from the APB bus clock. STM32 families and APB prescaler settings do not all route clocks in the same way, so confirm the effective timer clock in your part’s clock tree and reference manual.

What PSC and ARR control

PSC is the prescaler. A register value of 71 divides the timer input by 72, because the divider is PSC + 1. ARR is the auto-reload value. In an up-counter, the counter visits zero through ARR, so one period contains ARR + 1 counter ticks. CCR is the capture/compare value; with PWM mode 1, edge alignment, and active-high polarity, it sets the compare point and gives the ideal duty calculation below.

counterClock = timerClock / (PSC + 1)
frequency = timerClock / ((PSC + 1) × (ARR + 1))
period = 1 / frequency
duty = CCR / (ARR + 1) × 100%

These equations describe the stated mode, not every STM32 timer mode. Center-aligned counting, down-counting, repetition counters, preload/update timing, dead time, and inverted outputs need device-specific treatment.

Three hand-calculated examples

1) 72 MHz, 1 kHz, 25% duty

Take timerClock = 72,000,000 Hz, PSC = 71, ARR = 999, and CCR = 250.

• Counter clock = 72,000,000 / (71 + 1) = 1,000,000 Hz.
• Period ticks = 999 + 1 = 1,000.
• PWM frequency = 1,000,000 / 1,000 = 1,000 Hz; period = 1 ms.
• Ideal duty = 250 / 1,000 × 100 = 25%.

2) 72 MHz, 100 Hz, 50% duty

With PSC = 719, ARR = 999, and CCR = 500, the counter clock is 72,000,000 / 720 = 100,000 Hz. Dividing by 1,000 period ticks gives 100 Hz, a 10 ms period, and 50% ideal duty.

3) 80 MHz, 1 kHz, 75% duty

With PSC = 79, ARR = 999, and CCR = 750, the counter clock is 80,000,000 / 80 = 1,000,000 Hz. The result is 1,000 Hz, 1 ms, and 75% ideal duty.

Reproduce the calculation

I maintain the STM32 Timer & PWM calculator. It is a theoretical calculation aid, not an oscilloscope and not ST’s configuration tool. Enter 72000000 Hz, select 16-bit, set PSC to 71, ARR to 999, and CCR to 250, then calculate. The expected counter clock is 1 MHz, PWM frequency 1 kHz, period 1 ms, and duty 25%. Comparing each field with the hand calculation is a useful sanity check.

Boundaries that matter in real firmware

Do not substitute a CPU or APB frequency for the effective timer input without checking the clock tree. Do not drop the +1 terms. PSC and ARR determine the period; CCR determines the compare point. The calculator validates integer register ranges for 16-bit and 32-bit selections, rejects an out-of-range CCR, and its target solver reports frequency error while searching valid integer pairs.

The equations assume a continuously running, up-counting, edge-aligned timer. Startup latency, preload and update-event timing, interrupt or DMA scheduling, output polarity, oscillator tolerance, and board-level effects can change what you observe. Center-aligned and other specialized modes are not interchangeable with this formula.

References and disclosure

ST’s AN4776 timer cookbook provides official timer and PWM configuration examples. For STM32F1 devices, see the general-purpose timer sections in RM0008. Always use the reference manual for the exact MCU and clock configuration.

AI assisted with drafting and language editing. The equations and numerical examples were independently recomputed from the model above; no hardware measurement or performance claim is implied.

A small UART timing model

This article counts UART data frames. A frame count is not a Unicode character count, a string length, or an automatic description of an application buffer.

frameBits = 1 + dataBits + parityBits + stopBits
totalBits = frameCount × frameBits
payloadBits = frameCount × dataBits
timeSeconds = totalBits / baudRate

For a positive frame count, payloadBitRate = payloadBits / timeSeconds. Payload bits include only the UART data field. They do not subtract application headers, escaping, checksums, retries, or buffering. The time calculation assumes back-to-back frames with no intentional idle gap. Driver scheduling, DMA/FIFO behavior, flow control, USB adapters, and software delays can increase elapsed time.

Microchip's USART documentation describes 8N1 as one start bit, eight data bits, no parity bit, and one stop bit. That is 10 line bits per frame. Device-specific modes and register limits still belong to the target chip's data sheet.

Example 1: 115200 baud, 8N1, 100 frames

For 8N1, frameBits = 1 + 8 + 0 + 1 = 10 bits/frame.

• Line bits: 100 × 10 = 1,000 bits
• Data-field bits: 100 × 8 = 800 bits
• Wire time: 1,000 / 115,200 = 0.0086805556 s ≈ 8.68056 ms
• Data-field bit rate: 800 / 0.0086805556 = 92,160 bit/s

The line rate is 115200 bit/s, while the theoretical data-field rate is 92160 bit/s. In this specific 8-bit example, that is equivalent to 11,520 B/s after dividing by eight. It is not 115200 bytes/s, and it is not an end-to-end application throughput guarantee.

Example 2: 9600 baud, 7N1, 100 frames

Seven data bits and one stop bit produce 9 line bits per frame. The stream uses 900 line bits and 700 data-field bits, takes 900 / 9,600 = 0.09375 s (93.75 ms), and has a data-field rate of approximately 7,466.67 bit/s.

A 7-bit frame is not automatically an 8-bit byte. If an application starts with arbitrary 8-bit bytes, it needs an explicit packing or encoding layer. This model does not invent one.

Example 3: 115200 baud, 9N1, 100 frames

With nine data bits and one stop bit, the stream uses 11 bits per frame, 1,100 line bits, and 900 data-field bits. The wire time is approximately 9.54861 ms, and the data-field rate is approximately 94,254.55 bit/s. The 9-bit field also does not define how a higher-level byte stream is encoded.

Zero frames and practical boundaries

Zero is a valid frame count. The format still determines frameBits, but total line bits, data-field bits, time, and bit rate are all defined as zero. There is no 0/0 calculation. Negative, fractional, non-finite, or unrepresentably large frame counts should be rejected.

This calculation answers one narrow question: how long a known number of complete frames would occupy the wire under continuous transmission. It does not model application protocol structure or hardware scheduling. If protocol headers or checksums are sent through UART, count their encoded frames as part of the stream before estimating time.

A calculator for checking your own parameters

I develop and maintain the UART Transmission Time Calculator. It accepts baud rate, frame count, data bits, parity, and stop bits, then reports theoretical line time and data-field bit rate. It is useful for repeating the arithmetic with your own parameters; it is not a hardware measurement or an official certification.

To reproduce the 7N1 example, enter baud rate 9600, number of frames 100, data bits 7, parity None, and stop bits 1. The expected result is 9 bits per frame, 900 total line bits, 700 data-field bits, 93.75 ms, and approximately 7466.67 bit/s.

References and disclosure

• Microchip TB3216: Getting Started with USART
• Microchip UART peripheral overview

This article was drafted and edited with AI assistance. I reviewed the formulas and wording against the cited source and the calculator's current implementation; the numerical examples are independent arithmetic checks, not hardware measurements. I remain responsible for the published content.