Pi Pico Puts Bluetooth Keyboards on the I2C Bus

The Raspberry Pi Pico has become one of the maker community's most versatile microcontrollers, and a growing category of projects in 2026 demonstrates one of its more specialized capabilities: acting as a transparent bridge that accepts Bluetooth HID keyboard input and forwards decoded keystroke data downstream over the I2C bus. The result is a low-cost, low-power solution that lets embedded systems, industrial controllers, and custom smart-home setups accept wireless keyboard input without deploying a full USB host stack or a general-purpose Linux SBC.

This synthesis draws on official Raspberry Pi technical documentation, community firmware repositories, and published open-source project logs.

Why the Pi Pico Belongs in This Role

The RP2040 — the microcontroller at the heart of the original Pi Pico — pairs two ARM Cortex-M0+ cores running at up to 133 MHz with eight Programmable I/O (PIO) state machines. PIO is the key differentiator for protocol-bridging work: each state machine can execute custom bit-bang logic independently of the main CPU cores, freeing those cores to manage the Bluetooth host stack and I2C framing simultaneously without software-timed delays. Per the official RP2040 datasheet, the two PIO blocks each support four independent state machines capable of running at full system clock speed, enabling deterministic, low-jitter protocol handling that would be difficult to achieve with a purely software-driven implementation.

The Pi Pico 2, introduced in 2024, replaces the RP2040 with the RP2350 — a dual-core ARM Cortex-M33 (or dual RISC-V Hazard3, selectable at boot) running at up to 150 MHz. Per Raspberry Pi's RP2350 product page, the newer silicon adds hardware floating-point acceleration, 520 KB of on-chip SRAM (versus 264 KB on the RP2040), and improved power-management modes. Community project logs on Hackaday.io indicate that the RP2350's deeper sleep states deliver meaningfully lower standby current compared with the RP2040, though exact figures vary with peripheral configuration.

The W Variants and Bluetooth

The standard Pico and Pico 2 boards carry no wireless radio. The Pi Pico W and Pi Pico 2 W add an Infineon CYW43439 combo chip providing 2.4 GHz Wi-Fi and Bluetooth 5.2. According to the Pi Pico W datasheet, the CYW43439 connects to the RP2040 via a dedicated SPI interface and runs the Bluetooth protocol stack on its own embedded processor, offloading that work from the RP2040 cores entirely. The Pico 2 W pairs the same CYW43439 with the faster RP2350.

For keyboard-bridging projects, the BLE Central role is the critical one. The Pico W acts as the Bluetooth host: it scans for advertising BLE devices, connects to a keyboard that exposes a standard HID (Human Interface Device) GATT service, and subscribes to HID Input characteristic notifications. Each notification payload encodes up to six simultaneous keycodes plus modifier flags (Shift, Ctrl, Alt, GUI) per the USB HID specification — the same report format used over USB, transported here over BLE.

How the Bridge Architecture Works

The logical data flow proceeds in three stages:

1. BLE Central (Pico W) — scans for advertising BLE HID peripherals, pairs and bonds, then receives HID Input reports as GATT notifications. The CYW43439 handles all BLE lower layers; the RP2040 receives decoded report bytes via SPI.

1. HID Decode and Key Mapping — firmware decodes the raw HID report bytes, resolves keycode-to-character or keycode-to-command mappings, and builds an I2C payload. Community projects reuse HID parsing modules from the KMK Firmware — a CircuitPython keyboard firmware — whose HID decode utilities port to the Pico W with minimal modification.

1. I2C Controller — the Pico W drives the I2C bus as the controller node, transmitting decoded keystroke payloads to one or more I2C peripheral devices downstream. Per the Pico C/C++ SDK documentation, the RP2040 exposes two hardware I2C controllers supporting standard-mode (100 kHz) and fast-mode (400 kHz) operation natively. PIO state machines can extend this further for custom protocols.

Because the Pico W manages BLE reception, HID decoding, and I2C driving in software — with PIO available for edge cases — the total hardware cost for a basic bridge is the Pico W board itself (approximately $6–7 at retail) plus a small number of passive components.

Choosing a Pi Pico Variant

Source: Raspberry Pi product pages

For a pure Bluetooth-to-I2C keyboard bridge, the Pico W is the minimum viable platform. The Pico 2 W is preferred when key-mapping logic is complex enough to benefit from the M33's improved single-thread throughput or when the project also incorporates heavier compute tasks on the same board — the doubled SRAM alone removes a practical ceiling that MicroPython projects occasionally hit on the RP2040 when managing large keymap tables.

Firmware Ecosystem

Three firmware paths are actively used in the maker community:

MicroPython — The official MicroPython port for RP2040 and RP2350 exposes machine.I2C for I2C controller and peripheral operation, and bluetooth.BLE for Central/Peripheral roles. The BLE API covers GAP scanning and GATT client operations required to subscribe to HID Input characteristics. HID report-descriptor parsing must be handled by user code or adapted from community libraries. MicroPython's lower entry barrier makes it the most common starting point for first-time Pico bridge builders.

CircuitPython + KMK — KMK Firmware is written entirely in CircuitPython and is designed primarily for keyboards running on the Pico, but its HID parsing and keycode modules are reusable in bridge contexts. Adafruit's CircuitPython BLE library provides a high-level BLESimpleCentral class that streamlines pairing with BLE HID peripherals, handling connection management that would otherwise require several hundred lines of raw GAP/GATT code.

C/C++ SDK + BTstack — For the lowest achievable latency, the Pico C/C++ SDK paired with the integrated BTstack Bluetooth host stack is the appropriate path. BTstack supports BLE HID host profiles natively; the SDK's hardware I2C driver optionally uses DMA for efficient bus transfers that do not stall the CPU. This path is preferred for industrial or musical instrument applications where end-to-end keystroke latency is a hard requirement.

For a look at how on-device AI is increasingly intersecting with keyboard intelligence, related SpecPicks coverage includes Acti Puts AI Agents in Your Keyboard: On-Device vs Local-GPU Inference and On-Device AI Keyboards: Can an RTX 3060 12GB Train the Model?.

Hardware Checklist

Beyond the Pico W board itself, a minimal bridge requires:

• Logic-level shifter — If downstream I2C peripherals operate at 5 V (common on legacy industrial hardware and older Arduino-ecosystem modules), a bidirectional level shifter is essential. The RP2040 and RP2350 GPIO pins are 3.3 V only; sustained 5 V exposure risks permanent silicon damage. BSS138-based modules and the TXB0108 are both widely used in community builds.
• Pull-up resistors — I2C requires pull-up resistors on the SDA and SCL lines. For 400 kHz fast-mode operation, typical values fall in the 1–2 kΩ range to 3.3 V; the correct value depends on total bus capacitance (number of devices, PCB trace length, cable runs).
• Decoupling capacitors — 100 nF ceramic capacitors placed close to the Pico W's 3.3 V supply pin reduce power-rail noise that can corrupt I2C arbitration, particularly in motor-adjacent or switch-mode supply environments.
• Sufficient Flash for keymap tables — Complex key remapping tables, Unicode character maps, or multi-layer keymap definitions can consume several hundred kilobytes. The Pico W's 2 MB of on-board Flash is sufficient for most projects; the Pico 2 W's 4 MB provides headroom for larger CircuitPython runtimes plus keymap data.

Real-World Applications

Industrial IoT input terminals — I2C's 127-device address space (in standard 7-bit addressing mode) enables multi-drop bus topologies where a single Bluetooth keyboard provides text entry to multiple headless PLCs, data loggers, or controller boards over a shared bus. Physical USB cabling into sealed enclosures becomes unnecessary, reducing ingress-protection engineering complexity.

DIY MIDI and audio controllers — Community synthesizer and drum-pad projects documented on Hackaday.io exploit the Pico's dual-core architecture to run BLE HID reception on one core and I2C MIDI-bridge logic on the other using CircuitPython's asyncio cooperative scheduler, keeping both subsystems responsive without preemptive threading overhead.

Retro computing emulation — Related community work has pushed the Pi Pico 2 into retro-system emulation, where the RP2350's larger SRAM and faster core clock enable workloads impossible on the original Pico. The SpecPicks coverage of the Amstrad CPC 464/6128 Emulator on Raspberry Pi Pico 2 illustrates how rapidly the hardware ceiling is rising; the follow-up Amstrad CPC Emulator Now Runs on the Raspberry Pi Pico 2 tracks further community progress. Bridging a Bluetooth keyboard into the emulator's I2C input path is a natural next project step that several community members are actively prototyping.

Smart-home sensor hubs — Combining BLE keyboard input with an I2C sensor array (temperature, humidity, CO₂, ambient light) on the same bus lets a single Pico W act as both user-interface node and environmental data concentrator, reducing MCU count and simplifying power routing in custom enclosures.

Networking experiments — Builders pushing the Pico 2 W toward network-appliance roles will find useful context in Ethernet WiFi Router on a Pi Pico 2W: What's Possible, which charts realistic throughput ceilings and architectural tradeoffs for the platform — relevant when designing a bridge that also needs to forward decoded keystrokes to a network endpoint.

Known Limitations

Before committing to a Pi Pico W bridge design, public project logs highlight several constraints worth planning around:

• Single BLE connection per Pico W — The CYW43439 in Central role supports one concurrent BLE connection. Multi-keyboard setups require one Pico W module per keyboard, with the modules themselves communicating downstream over the shared I2C bus.
• No concurrent Wi-Fi and BLE at full throughput — The CYW43439 shares its radio between both protocols. Firmware must time-multiplex or dedicate the radio to one mode; projects requiring continuous BLE keyboard reception alongside steady Wi-Fi data upload need careful firmware scheduling.
• Python interpreter overhead — MicroPython and CircuitPython introduce interpreter latency on each decode iteration. Keystroke-to-I2C round trips in Python-based firmware are typically measured in low milliseconds; the C/C++ SDK path reduces this substantially for latency-sensitive applications.
• I2C speed ceiling — 400 kHz (fast-mode) is the practical ceiling supported by the RP2040 and RP2350 hardware I2C controllers without moving to Fast-Mode Plus or PIO-driven bit-banging. Most I2C peripheral ICs support fast-mode, but some older industrial sensors and display controllers are limited to 100 kHz standard mode.

For the original news coverage of this project category, see Pi Pico Puts Bluetooth Keyboards on the I2C Bus. For further context on where embedded keyboard intelligence is heading, On-Device AI Keyboards: What a Sub-2GB LLM Needs to Run Local explores the inference side of the same hardware ecosystem.

Citations and sources

• RP2040 Datasheet — Raspberry Pi
• RP2350 Product Page — Raspberry Pi
• Raspberry Pi Pico W Datasheet
• Raspberry Pi Pico C/C++ SDK Documentation
• Raspberry Pi Product Pages
• KMK Firmware — CircuitPython Keyboard Firmware
• MicroPython for Raspberry Pi Pico
• Adafruit CircuitPython BLE Library Documentation
• Hackaday.io — Community Project Hub

This piece is editorial synthesis based on publicly available information. No independent first-party benchmarking is reported.