APB (Advanced Peripheral Bus) is a low-speed, low-power bus in ARM's AMBA bus architecture, designed to connect peripheral devices such as UARTs, timers, GPIO controllers, and ADCs that do not require the high bandwidth of the main system bus. It is typically bridged off a higher-speed bus (AHB or AXI) through a bus bridge that handles protocol translation and, where clocks differ, clock-domain crossing.
In practice
On many ARM-based SoCs and MCUs, peripherals are divided between a fast bus domain (AHB or AXI) and one or more slower APB domains, though some SoCs use different interconnect topologies or vendor-specific naming. The split serves two purposes: it offloads the high-speed bus from the traffic of slow peripherals, and it allows APB-attached peripherals to run at a divided clock frequency to reduce power consumption. For example, on STM32F4 series MCUs, APB1 runs at up to 42 MHz and APB2 at up to 84 MHz, both derived from the 168 MHz AHB clock via configurable prescalers.
Because APB is a simple, non-pipelined protocol, peripheral register access over APB typically takes at least two bus cycles. This is usually invisible to the programmer — the CPU stalls transparently during the access — but it matters when estimating the timing of back-to-back register writes, such as in bit-banged or tightly timed peripheral sequences. On LPC17xx/40xx parts, the APB clock divider affects the baud-rate divisor calculations for UARTs and other clocked peripherals, making it a common source of misconfigured baud rates (covered in "NXP LPC17xx/40xx: Decoding the Part ID").
APB has gone through several revisions. APB2 (part of AMBA 2) is the version commonly encountered in Cortex-M MCUs from STMicroelectronics, NXP, and others, though the specific revision in use varies by vendor and chip family. Later revisions — APB3 (AMBA 3) and APB4 (AMBA 4/5) — introduced additional features on a per-revision basis: for example, PSLVERR (error response signaling) and wait-state support were introduced in APB3, while APB4 added further capability for larger application-class SoCs.
When configuring a peripheral, the APB clock feeding that peripheral must be enabled in the relevant clock-enable register before the peripheral registers are accessible. On STM32 devices this means setting the appropriate bit in RCC_APB1ENR or RCC_APB2ENR; failing to do so results in reads returning 0 and writes being silently discarded, a common early-development bug.
Frequently asked
What is the difference between APB and AHB?
AHB (Advanced High-performance Bus) is a pipelined, higher-bandwidth bus typically used to connect the CPU core,
DMA controllers, on-chip
SRAM, and
flash interfaces. APB is a simpler, non-pipelined bus intended for lower-speed peripherals. An AHB-to-APB bridge sits between them, serialising accesses and optionally dividing the clock. The result is that AHB can sustain one transfer per cycle while APB typically requires at least two cycles per transfer.
Why are there two APB buses (APB1 and APB2) on many STM32 devices?
STM32 devices use the two buses to partition peripherals by their maximum supported clock frequency and to allow independent clock scaling. APB1 typically runs at a lower maximum frequency (42 MHz on STM32F4, 36 MHz on STM32F1) and hosts lower-speed peripherals such as
I2C,
CAN, and some
UART/
SPI instances. APB2 runs faster (up to 84 MHz on STM32F4) and hosts higher-speed peripherals such as the
ADC, SPI1, and USART1. The division also helps manage power by letting the APB1 domain clock run slower.
Does the APB clock frequency affect peripheral timing, such as UART baud rate?
Yes. Peripherals such as
UARTs,
SPI controllers, and
I2C blocks derive their
baud-rate or bit-rate clocks from the APB clock feeding them. The baud-rate divisor register value must be calculated relative to the correct APB clock, not the CPU or
AHB clock. Incorrectly assuming the peripheral clock equals the CPU clock is a frequent cause of wrong baud rates, especially after changing
PLL or prescaler settings.
What happens if I access a peripheral's registers before enabling its APB clock?
On most ARM Cortex-M MCUs that use
AMBA APB, the peripheral's clock gate is closed and the bus bridge will typically return a default value (often 0) on reads and silently drop writes. The CPU may or may not receive a bus fault, depending on the specific silicon implementation. In practice this manifests as peripheral
registers appearing to be zero or ignoring writes, with no immediate fault. Always enable the APB clock for a peripheral in the RCC (or equivalent clock controller) before configuring or using it.
Is APB specific to ARM cores, or can it appear in other contexts?
APB is defined by ARM (now Arm Ltd.) as part of the
AMBA specification, so it is architecturally associated with ARM-based designs. However, because AMBA is an open standard, some non-ARM SoC designs and FPGAs (including Xilinx/AMD and Intel/Altera soft-processor ecosystems) incorporate APB-compatible buses or bridges when they want to reuse ARM-ecosystem peripheral IP. Outside of ARM and AMBA-derived systems it is not found.
Differentiators vs similar concepts
APB is often confused with
AHB (Advanced High-performance Bus) because both are part of the
AMBA specification and appear together in the same device reference manuals. The key distinction is purpose and performance: AHB is a pipelined, higher-throughput bus for
latency-sensitive masters and fast memories, while APB is a simple, non-pipelined bus for low-bandwidth peripherals. A related source of confusion is
AXI (Advanced eXtensible Interface), which appears on larger application-class SoCs (Cortex-A, Cortex-R) as the primary high-speed interconnect; on such devices APB peripherals are typically reached through an AXI-to-APB bridge rather than an AHB-to-APB bridge. APB should not be confused with the PB (Peripheral Bus) found on older or vendor-specific architectures (e.g., PIC32's Peripheral Bus, or AVR32's PB), which share a similar name and role but are not part of the AMBA standard.
