BLEファームウェアのビルドvsバイの判断
製品チームが新しいデザインにBluetoothモジュールを選定した後、すぐに次の問いが浮上する：ファームウェアは自社で開発するか、ベンダーのSDKと既製スタックに頼るか。この決定はプロジェクトのタイムライン、BOMコスト、消費電力、長期的な保守性に影響する — 多くの場合、ハードウェア選択以上に。
オプションA：ベンダーSDKと既製スタック
ほとんどのBLEモジュールベンダーは、Bluetoothプロトコルスタック、GATTプロファイルライブラリ、サンプルアプリケーション、ビルドツールチェーンを含む完全なSDKを出荷している。
- 市場投入までの時間短縮：ペリフェラル広告のサンプルは1時間以内にコンパイル・実行可能。カスタムGATTサービスの追加は経験豊富な開発者で2〜3日。
- 認証済みスタック：Bluetooth SIGがプロトコルスタックをすでに認定済み。FCCやCEのテストはRFエミッション部分のみ。
- OTAアップデート対応：NordicのDFUやTIのOADはイメージ署名、バージョン管理、ロールバックを処理。
トレードオフはコードサイズと電力効率。ZephyrベースのnRF Connect SDKでコンパイルした最小限のペリフェラル広告アプリは、Flash約120〜150 KB、RAM 16〜24 KBを消費する。
オプションB：ベアメタルでのカスタムファームウェア
- 無線スケジューリング：広告間隔、接続イベント、マルチプロトコルTDMの精密なタイミング制御。
- 電源管理：スリープ状態遷移の細粒度制御。ベアメタル実装はRTOSベース比で平均電流を10〜20%削減可能。
- コードフットプリント：nRF52832上の最小BLEアドバタイザはFlash約40〜60 KB、RAM 4〜8 KB — SDK比で約1/3。
コストは大きい：ARM Cortex-M4とBluetoothリンクレイヤに精通したエンジニアで4〜8週間の開発期間。Bluetooth SIGが仕様を更新するたびに手動でポートが必要。
消費電力：SDK vs ベアメタル
nRF52832-DKで資産追跡ユースケース（500 msごとに0 dBmで広告、接続なし）を測定：
| 実装 | 平均電流 | Flash | RAM | 開発期間 |
|---|---|---|---|---|
| nRF Connect SDK（Zephyr） | 5.8 µA | 142 KB | 18 KB | 2〜3日 |
| nRF5 SDK（非RTOS） | 4.2 µA | 98 KB | 12 KB | 3〜5日 |
| ベアメタル | 3.1 µA | 48 KB | 6 KB | 4〜8週間 |
ベアメタル版はRTOSベースSDK比で47%低い平均電流を達成 — しかし開発時間は10〜20倍。ほとんどの商用製品では、nRF5 SDK（非RTOS、Zephyr前）が最適なバランスを提供する。
カスタムファームウェアが合理的なケース
- 大量展開でバッテリー予算が厳しい場合：10万台以上の生産で毎マイクロアンペアが意味を持つ場合。
- 独自無線プロトコル：非標準変調やカスタムリンクレイヤ動作が必要な産業・軍事用途。
- マルチプロトコル多重化：BLE + 独自サブGHzプロトコルを厳密なタイミング要件で同一無線機に実行。
資産タグ、センサー、ウェアラブル、スマートホームペリフェラルではベンダーSDKが適切。8週間のベアメタル開発期間はこれらのカテゴリの製品開発ウィンドウを超える。
Bluetoothモジュール用SDK選択チェックリスト
- □ Bluetoothプロトコルスタックバージョンと認定状況
- □ OTAアップデート機構：ブートローダー、イメージ署名、ロールバック、デルタ更新
- □ 利用可能なGATTプロファイル
- □ 電力プロファイリングツール
- □ RTOSサポート：Zephyr、FreeRTOS、ベアメタル間の移行対応
- □ 長期サポート：最低10年のコンポーネント提供とSDKメンテナンス保証
Bluetoothモジュールの選定では、ファームウェア開発アプローチがRF仕様と同等に重要。単純なペリフェラルにベアメタルを適用したり、電力重視アプリに肥大化したSDKを使用したりすると、モジュール自体以上のコストがかかる。