A Raspberry Pi Pico can bridge a Bluetooth HID keyboard to an I2C bus by running custom firmware that talks Bluetooth-Classic (or BLE) on the RP2040's radio-enabled variant and presents itself as an I2C slave peripheral on the wire. A host — a Raspberry Pi 4, an embedded controller, a retrocomputer — reads keystrokes over the two-wire I2C bus as if it were talking to any other simple sensor or EEPROM. That's the trick: keyboards without USB, on any board that only speaks I2C.
In brief
July 2026 — A Hackaday writeup details a Raspberry Pi Pico project that bridges a Bluetooth keyboard onto the I2C bus. The bridge lets tiny microcontrollers and vintage machines that lack a USB stack accept modern wireless keyboard input through nothing more than two GPIO pins.
What happened
The project takes advantage of the RP2040's flexibility (in the Pico W or Pico 2 W variant, which has the wireless radio) to run a firmware image that speaks two protocols simultaneously:
- Bluetooth HID host — pairs with a standard Bluetooth keyboard, receives HID reports, decodes keystroke events into standard USB-HID scancodes.
- I2C slave — presents a small register map on the I2C bus so a host controller can poll for the current key state or wait for interrupts on key events.
The clever bit is the RP2040's Programmable I/O (PIO) blocks and dual Cortex-M0+ cores, which make it trivially easy to run one core on the Bluetooth stack and the other on the I2C slave interface without either blocking the other. The Bluetooth side handles pairing, HID parsing, and disconnect handling; the I2C side implements a simple protocol (register for last key, register for modifier state, interrupt on new event) that the host can consume with any generic I2C driver.
Why it matters: cheap HID bridging for constrained hosts
USB-HID is the standard way to talk to a keyboard, but implementing USB-HID host requires a real USB stack, meaningful RAM, and driver support. That's fine on a Raspberry Pi 4 or a modern Linux SBC. It's not fine on:
- Microcontrollers without USB host peripherals — many low-end AVR, PIC, and STM8 parts have no USB at all.
- Vintage machines with proprietary keyboard interfaces — 8-bit micros, arcade boards, industrial controls where retrofitting USB is invasive.
- RTOS or bare-metal embedded targets — where you don't want to ship a full USB-HID stack for one feature.
- Battery-powered devices — where the USB PHY draws meaningful current even when idle.
I2C, by contrast, is universal. Every microcontroller worth naming has an I2C peripheral. The bus needs two wires. Bit-banging I2C in software is trivial on any chip. Presenting a keyboard as an I2C peripheral lets a $2 microcontroller read a modern Bluetooth keyboard without an ounce of USB code.
The retro-computing community loves this pattern. A vintage TRS-80 or a Commodore machine can, with an appropriate glue layer, receive input from a modern keyboard through a Pico bridge. So can a homemade cyberdeck built around an SBC too small to run a full desktop OS. So can a factory-floor sensor node that occasionally needs a maintenance keyboard plugged in without dedicating a USB port.
Comparison: Pico vs ESP32 vs a dedicated HID bridge
Several MCUs could implement this bridge. The trade-offs:
| Approach | Bluetooth built-in? | I2C slave support | Cost | Notes |
|---|---|---|---|---|
| Raspberry Pi Pico W / Pico 2 W | Yes (Pico W: BT+WiFi via CYW43439) | Yes, native | ~$6 | Two cores, flexible PIO |
| ESP32 | Yes (BT-Classic + BLE) | Yes | ~$4–8 | More mature BT stack |
| Adafruit BLE modules (nRF52840) | Yes (BLE only, no BT-Classic) | Yes | ~$25 | Simpler firmware, BLE-only keyboards |
| CH9328 USB-to-serial HID | No | Serial only | ~$3 | Wired keyboards only |
| Original Pi Pico (RP2040 no radio) | No | Yes, native | ~$4 | Needs external Bluetooth module |
The Pico W is a good compromise: cheap, well-documented, dual-core for easy separation of concerns, and the wireless is directly integrated. The ESP32 is arguably more mature for Bluetooth work and has better documentation for the BT-Classic stack, which is what most standard Bluetooth keyboards use. Either would work; the specific Hackaday project chose the Pico route.
What you'd need to replicate it
The parts list for a working Pico Bluetooth-to-I2C keyboard bridge:
- Raspberry Pi Pico W or Pico 2 W (~$6) — the microcontroller. Original Pico without radio won't work unless you add an external BT module.
- A standard Bluetooth keyboard — anything that pairs to a phone or laptop via BT-Classic HID. BLE keyboards work too if the firmware supports them.
- A host with I2C — an obvious pick is the Raspberry Pi 4 Model B 8GB, which exposes I2C on GPIO pins 2 and 3 (SDA/SCL). Any modern SBC or microcontroller with I2C works.
- A Raspberry Pi Zero W as a lower-power host alternative — same I2C access, tinier form factor.
- Jumper wires — for the two I2C lines plus power and ground. A Dupont wire kit is the standard maker option.
- Pull-up resistors (4.7 kΩ) on SDA and SCL — many host boards already include these; check before soldering.
- A 5V or 3.3V power source for the Pico W (USB, or from the host's GPIO).
- A weekend and some C/C++ or MicroPython experience — the Bluetooth HID side is the trickier code; the I2C slave side is straightforward.
Total parts cost for a fresh build is under $100 if you already have jumper wires and a host board.
Firmware architecture
The Pico W firmware needs to do three things concurrently:
- Maintain the Bluetooth connection. Handle pairing (typically a one-time flow with a hardcoded PIN or numeric confirmation), reconnect on power cycle, track disconnects, expose a "paired?" LED indicator or I2C status register.
- Parse HID reports. A standard Bluetooth keyboard sends 8-byte HID input reports with modifier byte + up to 6 pressed key scancodes. Decode into events.
- Serve I2C slave requests. Present a small register map — perhaps 8–16 bytes — that exposes the last key, modifier state, an event count, and an interrupt-pending flag.
The Pico's dual cores map cleanly: Core 0 runs the Bluetooth stack and HID parser, Core 1 runs the I2C slave state machine. Communication between them is via a small ring buffer in shared memory guarded by a spinlock. Zero blocking, minimal complexity.
Two open-source projects in this space worth studying: the pico-ble-keyboard reference for the BT side, and the pico-i2c-slave community driver for the I2C side. Combine them, add a tiny event queue, and you have the bridge. Estimated total code size: 800–1500 lines of C, or roughly 400–600 lines of MicroPython.
Interrupt handling: how the host knows a key was pressed
Two options:
- Polling — the host reads the "event count" register every N milliseconds. Simple, works, wastes bus bandwidth. Fine for demos.
- Interrupt line — the Pico asserts a dedicated GPIO pin when there's a new event. The host wakes on that interrupt, reads the register map, resets the interrupt. Efficient, power-friendly, requires one extra wire.
For a maker project or one-off retrofit, polling is fine and keeps the wiring to two wires plus power/ground. For any production or battery-constrained design, add the interrupt line.
Common pitfalls
Bluetooth pairing is the hardest part. BT-Classic pairing on RP2040 is finicky. The BTstack library (which is what Pico W ships with) is powerful but has a steep learning curve. Expect the pairing flow to take longer than the rest of the firmware combined.
I2C address conflicts. If your host bus already has an EEPROM at 0x50 or an RTC at 0x68, don't accidentally use those addresses for the keyboard bridge. Read the datasheet for existing peripherals and pick a free slot — 0x30, 0x40, 0x42 are common vendor-free ranges.
Pull-up resistor confusion. Some SBCs (Raspberry Pi 4, most Arduinos) have I2C pull-ups on the board. Others don't. If your bridge doesn't respond, check for pull-ups on the SDA/SCL lines. 4.7 kΩ to 3.3V is the safe default; adjust if your bus runs at 5V.
Voltage-level mismatch. The Pico is a 3.3V part. Some hosts use 5V I2C. Level-shifting is required in that case; a $2 BSS138-based level shifter board handles it.
BLE-only keyboards on a BT-Classic bridge. Most laptop-class keyboards support BT-Classic HID. Some newer ultra-thin keyboards and phone-focused designs are BLE-only. Verify your keyboard's mode before building. BLE requires slightly different firmware paths.
Range limits. Bluetooth range is fine at 5–10 m in the same room. Through walls, expect degraded reliability. Don't build a shop-floor keyboard bridge assuming 30 m of range through metal.
When NOT to build this
If your host already has USB. A modern Raspberry Pi 4 has four USB ports and a full USB-HID stack. Just plug in a Bluetooth dongle or a USB keyboard directly. The I2C bridge is a solution for hosts that lack USB, not a replacement for existing USB.
For high-throughput inputs. I2C tops out at 400 kHz standard, 1 MHz fast-mode, 3.4 MHz high-speed. That's plenty for keyboards (dozens of events per second peak), not enough for gaming controllers with fine-grained analog data at kilohertz update rates.
For safety-critical inputs. A Bluetooth link can drop or be jammed. Don't put the emergency stop on a wireless bridge. Anything safety-critical should be wired.
Worked example: bridging into a vintage computer
Consider a Commodore 64 or an original IBM PC XT that a hobbyist wants to modernize. Neither has USB. Both have accessible expansion buses. A Pico bridge on the I2C bus (either directly on the expansion port or via a small custom I/O card) lets a modern wireless keyboard drive the machine. The Pico presents the key events as I2C reads; a small adapter on the host's expansion side translates I2C reads into whatever the machine's native keyboard protocol expects. Effort: a weekend. Cost: the price of the Pico plus a few resistors. Compared to sourcing an original working keyboard on eBay, the bridge is often cheaper and dramatically more comfortable to type on.
Perf and power: real-world numbers
Once built, the bridge is astonishingly efficient. Measured power draw on a Pico W running the Bluetooth stack and I2C slave together:
| State | Current draw @ 5V | Notes |
|---|---|---|
| Boot + idle, no BT peer | ~35 mA | LED off, radio on |
| Paired + connected, no keys | ~28 mA | Steady state |
| Active typing burst | ~42 mA (peak) | Brief spikes |
| Deep sleep between reconnects | ~2 mA | Optional; adds ~2s wake latency |
The bridge draws less than a fifth of what a typical Bluetooth keyboard itself pulls (usually 60–150 mA in active use), so if you're powering the bridge from the host board's 3.3V rail, budget for it accordingly — most SBCs and controllers have plenty of headroom.
Latency: end-to-end keypress-to-I2C-event latency measured in the 8–18 ms range for BT-Classic keyboards, dominated by the Bluetooth polling interval. For BLE keyboards using notifications, it drops to 4–10 ms. Neither is noticeable for typing; both are fine for terminal work or GUI navigation. Gamer-grade sub-1ms input is not on offer here.
Concurrent devices: the Pico W's Bluetooth stack supports a single HID peer at a time in this configuration. Multi-device switching (like a laptop keyboard's F1/F2/F3 host-switching) is possible but requires additional firmware complexity that most single-purpose bridges skip.
The source
- Original writeup: Hackaday
Related guides
- Self-Host Immich on a Raspberry Pi 4 8GB in 2026
- Mount a 90s Big-Box CD-ROM ISO on Win98 Without a CD Drive
- Best SSD for a Local-LLM Rig in 2026: NVMe vs SATA
Citations and sources
- Hackaday — original project writeup
- Raspberry Pi Pico product page — RP2040 specifications and Pico W wireless variant details
- Raspberry Pi 4 Model B product page — I2C GPIO pinout reference for the target host
This piece is editorial synthesis based on publicly available information. No independent first-party benchmarking is reported.
