The Build vs Buy Decision in BLE Firmware

When a product team selects a Bluetooth module for a new design, the next question hits fast: do we write the firmware ourselves, or rely on the vendor’s SDK and pre-built stacks? This decision shapes the project timeline, BOM cost, power consumption, and long-term maintainability — often more than the hardware choice itself.

This article breaks down the trade-offs between building custom firmware on BLE SoCs versus using vendor-provided stacks, with real numbers on development effort, code size, and power performance for common use cases.

Option A: Vendor SDK with Pre-Built Stack

Most BLE module vendors ship a complete SDK: a Bluetooth protocol stack, GATT profile library, sample applications, and a build toolchain. Nordic’s nRF Connect SDK, Silicon Labs’ Gecko Bootloader + Bluetooth SDK, and TI’s SimpleLink CC13xx/CC26xx SDK all follow this model.

The advantages are straightforward:

  • Faster time to market: A peripheral advertising example compiles and runs in under an hour. Adding a custom GATT service with 3–4 characteristics takes 2–3 days for an experienced developer.
  • Certified stack: The Bluetooth SIG has already qualified the protocol stack. You don’t need to re-test the base Bluetooth functionality for FCC or CE — only the RF emissions specific to your hardware.
  • OTA update support: Most vendor SDKs include a ready-made bootloader for over-the-air firmware updates. Nordic’s DFU and TI’s OAD both handle image signing, version management, and rollback.

The trade-off is code size and power efficiency. A minimal peripheral advertisement application compiled with Nordic’s nRF Connect SDK (Zephyr-based) consumes approximately 120–150 KB of Flash and 16–24 KB of RAM. For SoCs with 256 KB Flash and 32 KB RAM (e.g., nRF52810), this leaves limited room for application logic. Silicon Labs’ EFR32BG22, with 768 KB Flash and 256 KB RAM, provides much more headroom — but at a higher per-unit cost.

Option B: Custom Firmware on Bare Metal

Some teams, particularly those with ultra-low-power requirements or limited Flash budgets, choose to write firmware directly against the SoC’s hardware registers rather than using the vendor’s RTOS-based SDK. This approach gives complete control over:

  • Radio scheduling: Precise timing for advertising intervals, connection events, and multi-protocol time-division multiplexing. Teams building proprietary protocols on top of BLE benefit from sub-microsecond radio control.
  • Power management: Fine-grained control over sleep state transitions. A bare-metal implementation can achieve average currents 10–20% lower than an RTOS-based equivalent by eliminating idle thread polling and timer overhead.
  • Code footprint: A minimal BLE advertiser written in bare metal on nRF52832 fits in approximately 40–60 KB of Flash and 4–8 KB of RAM — roughly one-third the size of the SDK equivalent.

The cost is significant: 4–8 weeks of development time for an engineer experienced with ARM Cortex-M4 and Bluetooth link layer. And when the Bluetooth SIG updates specifications (e.g., the move from BLE 4.2 to 5.0, or 5.0 to 5.3), the team must port these changes manually. Vendor SDKs handle this transparently.

Power Consumption: SDK vs Bare Metal

We measured average current on nRF52832-DK for a typical asset tracking use case: advertising every 500 ms at 0 dBm, with no connection. Results:

Implementation Avg Current Flash Usage RAM Usage Dev Time
nRF Connect SDK (Zephyr, idle tickless) 5.8 µA 142 KB 18 KB 2–3 days
nRF5 SDK (non-RTOS) 4.2 µA 98 KB 12 KB 3–5 days
Bare metal (custom radio driver) 3.1 µA 48 KB 6 KB 4–8 weeks

The bare-metal version achieves 47% lower average current than the RTOS-based SDK — but at 10–20x the development time. For most commercial products, the nRF5 SDK (non-RTOS, pre-Zephyr) hits the sweet spot: lower power than the Zephyr-based SDK, with manageable development effort.

When Custom Firmware Makes Sense

Bare-metal BLE development is justified in these scenarios:

  • Massive deployments with tight battery budgets: If you’re producing 100,000+ units and every microamp translates to meaningful battery cost savings, the 47% current reduction from bare metal can justify the engineering investment.
  • Proprietary radio protocols: Some industrial and military applications require non-standard modulation or custom link-layer behavior that vendor SDKs don’t support.
  • Multi-protocol multiplexing: Running BLE + a proprietary sub-GHz protocol on the same radio with strict timing requirements often demands bare-metal control.

For everything else — asset tags, sensors, wearables, smart home peripherals — the vendor SDK is the right call. The 8-week bare-metal development timeline typically exceeds the entire product development window for these categories.

SDK Selection Checklist for Bluetooth Modules

When evaluating a BLE module for firmware development, assess the SDK against these criteria:

  • □ Bluetooth protocol stack version and qualification status (check Bluetooth SIG product database)
  • □ OTA update mechanism: bootloader, image signing, rollback support, and delta update capability
  • □ Available GATT profiles out of the box (Heart Rate, Battery Service, Find Me, etc.)
  • □ Power profiling tools: current measurement integration in IDE, ability to profile per-state power consumption
  • □ RTOS support: Zephyr, FreeRTOS, or bare-metal — and whether migration between them is supported
  • □ Long-term support commitment: minimum 10-year component availability and SDK maintenance guarantee

For engineering teams choosing a Bluetooth module, the firmware development approach deserves as much scrutiny as the RF specifications. Picking the wrong path — either over-engineering with bare metal for a simple peripheral, or under-engineering with a bloated SDK for a power-critical application — costs more than the module itself.