Bluetooth概要¶

概要¶

このガイドでは、SF32製品のBluetooth接続をどのように計画・実装するかを説明します。BLEとデュアルモードBluetoothの選択、GATTサービス設計、プロファイル選定、接続パラメーターの調整、ペアリングとセキュリティ、LE Audio、グラフィックス・オーディオ・センサーの各処理との共存など、実際の設計で必要となる判断を中心に扱います。

SF32は、アプリケーション処理と厳密なタイミングを要するBluetoothコントローラー処理を分担します。通常、製品ロジックとUIはアプリケーションプロセッサーが実行し、リンクレイヤーのタイミングと無線スケジューリングはBluetoothプロセッサーまたは低消費電力プロセッサーが担当します。ホストスタックとGATTサービスの実行先は、デバイスとSDK構成によって異なります。すべてのサービスがアプリケーションプロセッサーで動くとは想定せず、選んだサンプルのコア構成とコア間通信を確認してください。

基盤となるサブシステムのより詳細な説明については、Bluetoothプロセッサーアーキテクチャを参照してください。

製品に必要なロールとプロファイル、ユーザーが期待する応答性とバッテリー寿命、スマートフォン・無線部・アプリケーションファームウェアの役割分担を定義する際に、このページを参照してください。本ページは設計ガイドであり、対象のスマートフォンやアクセサリーを使った相互運用性の検証に代わるものではありません。

製品の無線接続要件を定義する¶

GATTのコードを書く前に、製品が実際に何を必要とするかを明確にしてください。

• BLEのみか、デュアルモードBluetooth（BT Classic + BLE）か。
• BluetoothオーディオはClassic（A2DP/AVRCP/HFP）か、それともLE Audioか。
• 一般的な接続間隔、レイテンシ、スループットの要件。
• アプリケーションプロセッサーをどの程度の頻度でスリープから復帰させる必要があり、どのくらいスリープ状態を維持できるか。
• 製品が既存のスマートフォン側のサービス（通知、メディア制御、通話）と相互運用する必要があるか、それともカスタムのコンパニオンアプリのみか。
• 想定される到達距離、アンテナ/筐体の制約、RF認証の目標。
• ファームウェア更新をBluetooth経由で配信するかどうか。

これらの要件に基づいて、デバイスと出発点となるSDKサンプルを選び、メインCPUをスリープ状態に維持できる時間を判断します。

BLE、Classic、デュアルモードを選ぶ¶

Bluetooth Low Energy（BLE）¶

BLEは、ほとんどの接続型ウェアラブルやセンサーにとって適切なデフォルトです。断続的でイベント駆動のトラフィック、低い平均消費電力、幅広いスマートフォンOSサポートを備えています。BLE優先の代表的な製品には、フィットネスバンド、健康センサー、ビーコン、コンパニオンアプリへの構成/制御リンクがあります。

Classic Bluetoothとデュアルモード¶

製品にオーディオストリーミング（A2DP/AVRCP）、ハンズフリー通話（HFP）、シリアル形式のデータリンク（SPP）、または既存のClassicプロファイルとの互換性が必要なら、Classic Bluetoothを追加します。デュアルモードでは、BLE専用の場合より無線スケジューリングと共存の要件が厳しくなります。専用Bluetoothプロセッサーは、こうした無線処理の負荷をシステムの他の処理から切り離すために用意されています。

すべてのSF32製品がデュアルモードBluetoothに対応しているわけではありません。型番を決める前に、Bluetoothプロセッサーアーキテクチャのデバイス表を確認してください。

適切なSF32デバイスを選ぶ¶

クロック速度だけでなく、製品が必要とする接続性の機能セットに基づいてデバイスを選んでください。

製品が接続性以上のものを必要とする場合は、グラフィックス概要とAIアクセラレーターのページから、ディスプレイ、メモリー、AIの要件と照らし合わせてください。

GATTサービスとSiblesフレームワーク¶

SiFli-SDKでは、Siblesを使ってGATTサービスを登録・利用します。GATTはサービス/キャラクタリスティックの階層構造と属性へのアクセス方法を定義し、GAPはデバイスの発見・アドバタイズ、接続の確立、および各ロールを扱います。両者は役割を分担しており、GATTがGAPの上に実装されるという意味ではありません。GATTデータベースを一から作るより、要件に近いSDKサンプルを出発点にしてください。

SDKには、標準およびベンダー独自の複数のプロファイルのサンプル実装が同梱されています。

近い用途のサンプルから、登録処理、イベント処理、セキュリティチェックを再利用してください。標準プロファイルを実装する場合は、標準のUUIDと規定動作を維持します。製品のデータモデルに必要なら、独自のサービスとUUIDを設計して構いません。目的は検証済みの基盤処理を再利用することであり、すべてのアプリ連携を標準プロファイルに無理に当てはめることではありません。

Classic Bluetoothプロファイル¶

デュアルモード製品向けに、SDKは以下のサンプルプロファイル実装を提供します。

• SPP — シンプルな双方向シリアルデータ。レガシーまたは非GATTのコンパニオンアプリに有用。
• A2DP（シンクおよびソース） — Bluetoothオーディオストリーミング。
• AVRCP — A2DPリンクと併せた再生制御（再生/一時停止/トラック/音量）。
• HFP：ハンズフリー通話。HF（ハンズフリー機器）とAG（オーディオゲートウェイ）の役割があります。ドキュメントに掲載されたHFPサンプルはHFを実装しています。AGの対応は、選択したSDK構成で別途確認してください。
• PAN — Bluetooth経由のネットワーク。PANベースのOTA配信例を含む。

オーディオやレガシーのプロファイルは、一般的なBLE接続よりタイミングとスループットの要件が厳しい傾向があります。共存テストにも十分な時間を確保してください（下記の他のワークロードとの共存を参照）。

BluetoothオーディオとLE Audio¶

オーディオへのアプローチに応じて、2つの異なるパスがあります。

• Classic Bluetoothオーディオ — ストリーミング用のA2DP、再生操作用のAVRCP、通話用のHFP。成熟しており、既存のスマートフォンやヘッドセットと広く互換性があります。
• LE Audio — Basic Audio Profile（BAP）は、ユニキャストとブロードキャストの両方のLE Audioストリームを管理する手順を定義しています。SDKにはブロードキャストソースとシンクの例があり、移行期間中にClassic BTとLE Audioを併用する製品向けの、両方式を組み合わせたブロードキャストソースの例も用意されています。

どちらの方式でも、安定したタイミング、バッファリング、音声サンプルの確実な転送が必要で、通常はDMAを使います。必要なBluetoothオーディオの役割とSDK構成に対応するかを確認して、SF32LB52x/56x/58xを選んでください。SF32LB55xはBLE専用でClassic Bluetoothオーディオには対応しませんが、ローカル音声機能がないという意味ではありません。DMAとバッファリングについては、オーディオ概要とBluetoothプロセッサーアーキテクチャを参照してください。

Siblesサービスの実装パターン¶

保守可能なBLEサービスは、通常次のパターンに従います。

こうすることで、サービス定義、スマートフォンアプリとのインターフェース、セキュリティポリシー、電力特性を整合させられます。

アドバタイズと接続パラメーター¶

接続パラメーターとアドバタイズパラメーターは、レイテンシ、スループット、消費電力のバランスを調整する主な項目です。

これらはBLE ACLリンクの接続パラメーターであり、すべてのBluetooth音声転送に適用されるわけではありません。Classic Bluetooth音声はBR/EDRの転送タイミング、LE AudioはCISまたはBISのアイソクロナス転送タイミングを使います。BLE GATTの接続間隔を、そのまま両方式の音声経路に適用しないでください。各転送方式の違いはBluetooth SIGのLE入門資料で説明されています。

ビーコン形式の製品（iBeacon互換のアドバタイズ）や、周期的アドバタイズのユースケース（大規模または単方向ブロードキャスト向けの周期的アドバタイズ同期を含む）は、完全なGATT接続を必要とせず、専用のSDK例を通じてサポートされています。

接続間隔、ペリフェラルレイテンシ、スーパービジョンタイムアウトは、コントローラーと相手機器が受け入れられる有効な組み合わせにする必要があります。更新を要求しただけでは、設定が反映されたとは限りません。実際に合意された値を記録し、要求の拒否やアイドル時の省電力設定への復帰も含めて、対象のスマートフォンや周辺機器で検証してください。

製品フェーズごとのパラメータープリセット¶

すべてのフェーズで単一の折衷設定を使うのではなく、フェーズごとに適切なBluetoothパラメーターを設定してください。

フェーズ間の遷移条件を文書化してください。「ランダムに見える」Bluetoothの消費電力やレイテンシの問題は、状態が変わった後も製品が誤ったフェーズに留まっていることが原因の場合があります。

ペアリング、ボンディング、セキュリティ¶

BLEはペアリングなしでも接続できます。ペアリングではセキュリティ鍵を生成し、ボンディングでは後の接続で再利用するために鍵を保存します。すべての製品にボンディングが必要と決めつけず、各サービスに必要な暗号化、認証、鍵の永続保存を判断してください。

• Just Works、パスキー入力、数値比較のどのペアリング方式が必要かを早期に決めてください。Just Worksは中間者攻撃（MITM）を防ぎません。暗号化された接続でも、認証済みとは限りません。両機器のI/O能力と製品のセキュリティ要件に合う方式を選んでください。Bluetooth GAPのセキュリティ要件も参照してください。
• ANCSでは、スマートフォン側の利用許可と、リンクの暗号化やボンディングは別の条件です。許可の拒否や取り消しに対応してください。ANCSとAMSは接続中に公開・非公開が切り替わる場合があります。Service Changedを監視してサービスを再探索し、ペアリング後も常に利用できるとは想定しないでください。
• SDKが推奨するストレージ/パーティション方式に従ってボンディング情報を保存し、再起動やOTA更新後も保持できるようにしてください。
• 製品のUI側とスマートフォン側の両方に、再ペアリングと「デバイスを忘れる」フローを定義してください。
• セキュリティポリシー（暗号化要件、I/O能力、鍵サイズ）は、検討せずに放置するデフォルトではなく、製品としての判断として扱ってください。

マルチ接続とロール¶

SDKには、セントラルとペリフェラルの同時動作と複数の同時接続のサンプルがあります。スマートフォンにはBLEペリフェラルとして接続し、センサーにはセントラルとして接続する製品や、複数の相手機器と接続する製品で利用できます。役割の組み合わせと接続数の上限は、デバイス、コントローラーファームウェア、SDK構成、バッファー、無線処理の総負荷に応じて確認してください。サンプルの動作は、ファミリー全体で同じ接続容量が保証されることを意味しません。

リンクのスループットを上限近くまで高めたい場合は、制限がアプリケーションコードにあると決めつける前に、SDKのスループットサンプルを基準として試してください。

Bluetooth経由のOTAファームウェア更新¶

一般的な配信パスは2つあります。

• BLE経由のDFU形式の更新。ペリフェラル接続と統合されています（通常のペリフェラルGATTロールにOTAがどのように組み込まれるかについては、peripheral_with_otaの例を参照）。
• PAN OTA。データ用にすでにPANを使用しているデュアルモード製品向けに、Bluetooth PANネットワークリンク経由でファームウェアを配信します。

どちらの方式でも、出荷前にパーティション構成、障害復旧、ロールバックを計画し、検証してください。BLE OTAでは、転送中の接続間隔を短くし、ペリフェラルレイテンシを0にする設定を評価し、転送後に通常の省電力設定へ戻します。PAN OTAはClassic Bluetoothによる転送です。BLEの接続パラメーターを流用せず、スループットと復旧方法を別途調整してください。

他のワークロードとの共存¶

SF32上のBluetoothが単独で動作することはほとんどありません — グラフィックス、オーディオ、センサー、そして時には外部Wi-Fiとシステムを共有します。専用のBluetoothプロセッサーが時間制約の厳しいリンク処理の大部分を担いますが、アプリケーションレベルの共存には引き続き注意が必要です。

• アプリケーションプロセッサー上の長いクリティカルセクションや割り込みの無効化は、ホスト側のBluetooth処理を遅らせる可能性があります。
• ディスプレイとPSRAMのトラフィックは、Bluetoothオーディオバッファーとメモリー帯域幅を奪い合います。
• センサー割り込みがアプリケーションプロセッサーを頻繁に起こすと、Bluetoothプロセッサーがリンク処理を担う間、アプリケーションプロセッサーをスリープさせておけるという省電力効果が失われます。

システムレベルの説明は他のワークロードとの共存を参照してください。各サブシステムを単独で試すだけでなく、ディスプレイとオーディオを動作させながらBLEリンクにも負荷をかけるなど、実際に起こり得る厳しい組み合わせで検証してください。

RF、相互運用性、認証への準備¶

Bluetoothファームウェアは、RFハードウェアと同じ厳格さで検証されるべきです。

• 1台の開発用スマートフォンだけでなく、複数のスマートフォンベンダー、OSバージョン、再接続シナリオでテストしてください。
• 古いボンド、スマートフォン側での「デバイスを忘れる」操作、デバイス側の工場出荷時リセット、OTAの後の挙動を確認してください。
• バッテリー、ディスプレイ、充電器、ユーザーが装着/保持する位置とともに、最終的な筐体で到達距離とパケットの安定性を検証してください。
• 量産と認証サポートのために、RFテストモード、校正アクセス、ログを利用可能な状態に保ってください。
• プロファイルの多い製品では、認証/プロファイルテストの時間を確保してください。デモアプリが動作することは、相互運用可能であることと同じではありません。

Bluetoothの問題のデバッグ¶

よくある間違い¶

• 製品がすでにClassicオーディオを必要としているのに、BLE専用のハードウェアを選んでしまう。
• サービスの基盤処理を不要に作り直したり、独自データモデルを不適切な標準プロファイルに当てはめたりする。
• ほとんどの時間をアイドルで過ごすリンクで、ペリフェラルレイテンシを0のままにしてしまう。
• ディスプレイ/オーディオ/Bluetoothが初めて組み合わされる、統合の終盤まで共存テストを怠ってしまう。
• ペアリング/ボンディングを、設計されたUXフローではなく後回しの検討事項として扱ってしまう。
• 最終的なPCBリビジョンまで、RF立ち上げ検証（アンテナ、マッチングネットワーク、クリスタルの精度）を省いてしまう。
• ファームウェアだけのチューニングで、貧弱なRFレイアウトを補えると想定してしまう。

立ち上げチェックリスト¶

• BLE専用かデュアルモードかの要件を確認し、それに合ったSF32デバイスを選定する。
• 製品のユースケースに最も近いSDKのプロファイル/サービス例を特定する。
• 発見、アクティブな利用、アイドル状態のためのアドバタイズおよび接続パラメーターの目標を定義する。
• ペアリング、ボンディング、「デバイスを忘れる」UXを設計する。
• 実際のハードウェアでRFレイアウト、アンテナマッチング、クリスタルの精度を検証する。
• 選定したプロファイル（GATTサービス、A2DP/AVRCP/HFP、またはLE Audioブロードキャスト）を実際のスマートフォンまたはリファレンスホストに対して立ち上げる。
• 現実的な組み合わせ負荷の下で、ディスプレイ、オーディオ、センサーのワークロードとの共存をテストする。
• ファームウェア更新をBluetooth経由で配信する場合は、OTA配信パスを計画・テストする。
• 接続アイドル時の消費電力を測定し、アプリケーションプロセッサーが想定どおりにスリープすることを確認する。

要点のまとめ¶

• まずBLE専用かデュアルモードBluetoothかを決めてください。これがデバイス選定と、その後のSDK開発方針を大きく左右します。
• ゼロから構築するのではなく、SDKの既存のGATTサービスとClassicプロファイルの例（HRPC、DISS、CTS、HID、ANCS/AMS、SPP、A2DP、AVRCP、HFP、PAN）から始めてください。
• 接続間隔、ペリフェラルレイテンシ、スーパービジョンタイムアウト、送信電力が、レイテンシ、スループット、消費電力のバランスを取る主な調整項目です。
• Bluetooth音声では、選択したデバイスとSDK構成が必要なClassic BluetoothまたはLE Audioの役割に対応するか確認し、バッファリングと共存を設計・検証してください。ファミリー全体の機能説明だけでは判断できません。
• Bluetoothはシステムレベルの関心事です。RFレイアウト、クロック、ペアリングUX、グラフィックス/オーディオ/センサーとの共存は、GATTコード自体と同じくらい重要です。

現行のClassic Bluetooth、BLE、LE AudioのSDKプロジェクトを開発タスク別に整理した一覧については、Bluetooth SDKの例を参照してください。

対象デバイスの実際のBluetooth消費電力を測定・分析する実践的な方法については、Bluetoothの消費電力を測定・分析するを参照してください。

最終更新: 2026-10-19