i2c speed modes
Five official speeds, two you'll actually use. Here's the whole ladder, what real hardware supports, and why turning the clock up is sometimes the way to make a bus less reliable.
The ladder
All five i2c speed modes
| Mode | Clock | Reality check |
|---|---|---|
| Standard-mode (Sm) | 100 kHz | The universal default — everything supports it |
| Fast-mode (Fm) | 400 kHz | Supported by nearly all modern sensors and displays |
| Fast-mode Plus (Fm+) | 1 MHz | Needs strong pull-ups (~1 kΩ) and short wiring |
| High-speed (Hs) | 3.4 MHz | Special controller signalling — rare outside ICs designed for it |
| Ultra-fast (UFm) | 5 MHz | Write-only, push-pull, no ACK — a different animal, rarely seen |
Physics
Why faster i2c gets hard: the ladder gets steep
i2c edges rise through pull-up resistors, so each mode's tighter timing demands faster rising edges: the spec (NXP UM10204) allows 1000 ns of rise time in Standard-mode, 300 ns in Fast-mode, 120 ns in Fm+. That's why "just set 400 kHz" fails on a bus that was happy at 100 kHz — same wiring, one-third the rise budget. Speed trades directly against cable length and device count, and a logic analyzer shows the failure as edges that visibly never reach the top before the next clock.
Throughput math keeps expectations honest: 9 clocks per byte plus addressing overhead means ~8 kB/s real payload at 100 kHz and ~35–40 kB/s at 400 kHz. A full SSD1306 frame is 1 KB — hence ~25 ms per refresh at Fast-mode. If your bandwidth need has a megabyte in it, you want SPI, not a faster i2c.
Practice
Setting the i2c clock speed on each platform
All platforms default to 100 kHz; one line changes it:
// Arduino / ESP32
Wire.setClock(400000);
# MicroPython
i2c = I2C(0, sda=Pin(0), scl=Pin(1), freq=400_000)
# Raspberry Pi — /boot/firmware/config.txt, then reboot
dtparam=i2c_arm=on,i2c_arm_baudrate=400000The controller sets one clock for the whole bus, so it must respect the slowest attached device. The reliable workflow: bring everything up at 100 kHz, confirm with a scan, then raise to 400 kHz and re-test — and if anything wobbles, the answer is almost never "more speed," it's stronger pull-ups, shorter wires, or splitting the bus.
Questions
Speed mode FAQ
What is the maximum speed of i2c?
On paper: 5 Mbit/s (Ultra-fast mode, which is write-only and rare). In practice the ladder is 100 kHz Standard, 400 kHz Fast, 1 MHz Fast-mode Plus, 3.4 MHz High-speed — and almost all hobbyist hardware lives at 100 or 400 kHz. High-speed mode needs special controller support that microcontroller peripherals rarely have.
Is 400 kHz safe to use as a default?
Usually — nearly every modern sensor supports Fast-mode. The exceptions are long or heavily loaded buses (rise time suffers) and a few slow or stretching devices. Sound approach: develop at 100 kHz, switch to 400 kHz once everything works, and drop back if anything gets flaky.
Can devices with different maximum speeds share one bus?
Yes, but the bus must be clocked no faster than its slowest device — the controller sets one clock for every transaction it makes. If one slow part is throttling a display you care about, move it to a second bus or behind a multiplexer rather than overclocking it.
How much data can I actually move at 400 kHz?
Each byte costs 9 clocks (8 bits + ACK) plus addressing overhead per transaction, so Fast-mode tops out around 35–40 kB/s of real payload in long reads. Enough for sensors and small OLED animation; nowhere near enough for cameras or big displays — that's SPI territory.
Does increasing the speed change the wiring requirements?
Yes — every step up shrinks the rise-time budget, which means stronger pull-up resistors and less tolerance for bus capacitance. A cable-and-pull-up combo that's fine at 100 kHz can fail outright at 400 kHz; if you raise the clock, revisit both.