コンテンツにスキップ

Bluetoothプロセッサー

はじめに

Bluetoothプロセッサーは、SF32LBデバイスに搭載された無線制御専用のサブシステムです。無線通信のスケジューリング、リンク制御、低消費電力での接続維持、メインのアプリケーションプロセッサーとの連携など、厳密なタイミング制御が必要なBluetooth処理を担います。

この構成は、バッテリー駆動の接続型製品に有効です。SF32は異種マルチコア構成で処理を分担するため、無線イベントごとにメインのアプリケーションCPUを起動する必要はありません。アプリケーションプロセッサーが製品ロジックとユーザー向け機能を担い、低消費電力のBluetoothプロセッサーまたは常時動作プロセッサーが無線リンクを維持します。

低消費電力プロセッサーでアプリケーションコードを実行できる範囲は、シリーズによって異なります。下の比較を参照し、対象品種とSDKで利用できるタスク配置を検証してください。

このページでは、Bluetoothのタイミング制御やコントローラーファームウェアの実行場所、選定した品種の低消費電力コアをプログラムできるかどうか、アプリケーションCPUを休止させながら接続を維持する方法を説明します。サービスの設計や製品へのBluetooth統合については、Bluetooth概要を参照してください。

専用Bluetoothプロセッサーが重要な理由

Bluetoothは、必要なときだけバックグラウンドで動く単純なソフトウェアプロトコルではありません。接続機器は、アドバタイズ、スキャン、接続イベント、パケット交換、音声伝送、暗号化、ほかのシステム処理との共存において、厳密な無線時間要件を満たす必要があります。

専用のBluetoothサブシステムは、時間制約の厳しい無線処理をアプリケーションの主な処理から分離します。これにより、次のような利点が得られます。

  • 接続済みスタンバイ中の平均消費電力の低減。
  • UI、グラフィックス、オーディオ、AIの処理が重い場合でも、無線通信のタイミングを安定して維持できる。
  • コントローラー側の無線イベントを、毎回アプリケーションCPUを起動せずに処理できる。
  • アプリケーションファームウェアとプロトコル制御ファームウェアのより明確な分離。
  • メインCPUが休止している間も接続を維持する製品を実現しやすい。

ウェアラブルや携帯機器では、この分離が特に有効です。製品の稼働時間の大半を低消費電力の接続状態で過ごし、ユーザー操作、センサーイベント、画面更新、音声処理、スマートフォンとの同期が必要なときだけ起動できます。

これらは設計上の利点であり、特定の消費電力や復帰時間を保証するものではありません。ホストスタックの実行場所、割り込み、クロックの起動、スリープ方針、アプリケーション通信量によって実測値は変わります。対象のファームウェアと処理負荷で、電流と応答時間を測定してください。

SF32システムにおける位置づけ

簡略化したSF32の無線アーキテクチャは次のようになります。

図: SF32の無線アーキテクチャ(簡略図)
アプリケーションプロセッサー
  - 製品ファームウェア
  - UIとグラフィックス
  - オーディオアプリケーションの制御
  - ユーザー向けサービス
        │
        ▼
Bluetoothホスト/システムサービス
        │
        ▼
Bluetoothプロセッサー/コントローラーファームウェア
  - リンク層のタイミング制御
  - 無線スケジューリング
  - 低消費電力時の接続イベント
  - コントローラー側のプロトコル処理
        │
        ▼
Bluetooth無線部とRFフロントエンド

ホスト、コントローラー、アプリケーションファームウェアの分担は、SDK、スタック構成、製品要件によって異なります。ただし、メインのアプリケーションプロセッサーを、Bluetooth処理に関わる唯一のCPUとして扱うべきではありません。Bluetoothサブシステムは独自の実行環境を持ち、無線動作の決定性を保ちながら電力効率を高めるよう設計されています。

デバイスファミリーの違い

SF32LBファミリーでは、デバイスのクラスによって低消費電力プロセッサーの構成が異なります。使用する品種のデータシートとSDKドキュメントを必ず確認してください。

表: デバイスファミリーの違い
デバイスファミリー Bluetooth機能 低消費電力プロセッサーの役割 一般的な位置づけ
SF32LB52x デュアルモードBluetooth(クラシックBluetooth + BLE) LCPUはBluetoothスタックを実行し、アプリケーションコードからは利用できない 低コストのBluetoothモジュール、オーディオアクセサリ、エントリー向けウェアラブル、コンパクトなHMI製品。
SF32LB55x BLE SDKがサポートするアプリケーションタスクをLCPUで実行可能 BLEウェアラブルや、多数のセンサーを使う低消費電力製品。
SF32LB56x デュアルモードBluetooth(クラシックBluetooth + BLE) SDKがサポートするアプリケーションタスクをLCPUで実行可能 高機能ディスプレイ製品、ネットワーク接続型HMI、ウェアラブル機器。
SF32LB57x デュアルモードBluetooth(クラシックBluetooth + BLE) LCPUがBluetoothと電力に敏感なタスクを担当。対応するタスク配置を確認 HCPU/ACPUでグラフィックスとローカル音声処理を分担する製品。
SF32LB58x デュアルモードBluetooth(クラシックBluetooth + BLE) SDKがサポートするアプリケーションタスクをLCPUで実行可能 高度なグラフィックスやオーディオ、AI、複雑な接続機能を必要とする上位製品。

SiFliのSF32LB52x HALガイドは、LCPUがBluetoothプロトコルスタックを実行し、ユーザーアプリケーションからは利用できないと説明しています。SF32LB55x、SF32LB56x、SF32LB58xのHALガイドでは、BLEやセンサー処理など消費電力に敏感な機能をLCPUに配置する構成が説明されています。SF32LB57xについて、SDKのACPUガイドはHCPU/ACPU/LCPUの3コア構成と、BLEやセンサーデータ処理などをLCPUで実行する構成を示していますが、ユーザーが任意のタスクを追加して実行できるか、その範囲までは明記していません。各シリーズのLCPUが同じ範囲でプログラムできると考えないでください。対象品種のコア構成をデータシートで確認したうえで、使用するSDKリリースとボード構成で目的のアプリケーションタスクをLCPU上で実行できるか確認します。その組み合わせの資料がなければ、タスク配置は「未確認」とし、採用前に利用可能なメモリーとスケジューリング上の制約も確認してください。

同じACPUガイドではアプリケーションコアの役割も区別されています。SF32LB57xのACPUは音声とグラフィックスを処理し、SF32LB58xでは音声DSPを担います。これらはBluetoothコントローラーの処理とは別の役割です。対象ボードとSDKで利用できるタスク配置を確認してください。

表のBluetooth機能はシリーズ単位の資料を要約したものであり、すべての品種やSDKビルドで全プロファイルが使えることを保証するものではありません。SiFliのSF32LB52xデータシート、SF32LB55xデータシート、SF32LB56xデータシート、SF32LB58xデータシートには、表に記載したBLEまたはデュアルモード対応が示されています。SDKのBluetoothシグナリングテストガイドではBR/EDRとBLEのテストを扱い、SF32LB57xも対象に含まれています。利用する品種とSDKリリースで、プロファイル、機能、構成の対応状況を確認してください。

アプリケーションのプログラマビリティとコントローラーファームウェア

LCPUでアプリケーションタスクを実行できても、それだけでBluetoothコントローラーのソースコードにアクセスできたり、無線スタックを置き換えられたりするわけではありません。サポートされるファームウェア更新やパッチの方法、メモリー予算、スケジューリング上の制約は、品種とSDKごとに固有です。

  • 低消費電力アプリケーションの開発。 対応構成では、センサー取得、軽量な処理、システム管理をLCPUに移せます。スタックのメモリー使用量、実行時間、HCPUとの通信を見積もってください。
  • コントローラーの保守とカスタマイズ。 対象デバイスとSDKに対してベンダーが提供する更新・パッチ機構を使ってください。アプリケーションコアがプログラム可能でも、独自コントローラーのソースや代替無線スタックが利用できるとは限りません。その可否はSiFliに別途確認してください。

コントローラー専用構成でも、ベンダーが提供する更新を適用できる場合があります。固定で変更不能なイメージとは限りません。変更後はBluetooth認証、相互接続性、ホストとコントローラーの互換性、OTAの障害復旧を検証してください。障害復旧用のロールバックと、脆弱な旧ファームウェアの導入を防ぐセキュリティポリシーは区別して設計してください。

BLEとデュアルモードBluetooth

SF32デバイスが対応するBluetooth機能は品種によって異なり、Bluetooth Low Energy(BLE)のみの場合と、クラシックBluetoothとBLEの両方を使えるデュアルモードBluetoothの場合があります。

Bluetooth Low Energy

BLEは低消費電力のデータ交換のために最適化されています。一般的に次のような用途で使用されます。

  • フィットネスバンドとスマートウォッチ。
  • 健康センサーとウェアラブル。
  • スマートフォンの通知とコンパニオンアプリ。
  • センサーの同期。
  • ビーコンと位置情報対応デバイス。
  • 低消費電力の制御・構成チャネル。

BLE通信はイベント駆動で断続的に行われるため、低消費電力Bluetoothプロセッサーに適しています。

クラシックBluetoothとデュアルモード設計

デュアルモードBluetoothでは、BLEに加えてクラシックBluetoothも利用できます。次のような製品に適しています。

  • Bluetoothオーディオアクセサリ。
  • ワイヤレスアダプターとモジュール。
  • 既存のクラシックBluetoothプロファイルとの互換性が必要な機器。
  • BLEによる制御と、クラシックBluetoothによる音声やデータの通信を組み合わせる製品。

音声や従来型のプロファイルでは、より高いスループット、低いレイテンシ、厳しい共存条件が求められることがあります。そのため、デュアルモード動作はBLEのみの場合よりシステム負荷が高くなることがあります。専用Bluetoothサブシステムにより、こうした処理がメインCPUの負荷変動に影響されにくくなります。

BluetoothオーディオとLE Audio

Bluetoothオーディオ製品では、無線のタイミング制御に加えて、バッファリング、コーデック処理、クロック同期、ときにはユーザーインターフェースの更新も必要になります。そのため、システム全体の設計負荷が高まります。

適切に設計されたSF32のBluetoothオーディオシステムでは、通常、次のように役割を分担します。

  • Bluetoothプロセッサーがコントローラー側の無線とリンクのタイミングを処理する。
  • アプリケーションプロセッサーが製品ロジック、UI、より高レベルのオーディオ挙動を処理する。
  • I2S、PDM、ADC、DACなどのオーディオインターフェースで、サンプルデータを入出力する。
  • DMAとバッファリングが、連続的なオーディオストリーミング中のCPUオーバーヘッドを削減する。

LE Audioを含む新しいBluetoothオーディオ用途では、ファームウェア構成、スタックの対応状況、コーデック、メモリー帯域幅、電力管理方針が製品の実現性を左右します。SiFliのSF32LB56xおよびSF32LB58xのデータシートにはBLE Audio対応が明記されていますが、BLE対応やデュアルモード対応だけでLE Audio対応が保証されるわけではありません。プロファイル、コーデック、SDKの実装経路は品種とSDKリリースによって異なるため、採用前に確認してください。Bluetoothプロセッサーはタイミング制御の基盤を担いますが、製品全体の動作はSDKとアプリケーションの設計にも依存します。

低消費電力動作

Bluetoothサブシステムの利点が最も生きるのは、無線リンクを維持したまま、メインのアプリケーションプロセッサーをスリープさせられる場合です。接続中の待機状態では、次のような必要なイベントに限ってアプリケーションプロセッサーを起動すればよくなります。

  • 受信した通知またはコマンド。
  • 接続状態の変化。
  • スケジュールされた同期タスク。
  • オーディオストリームの開始または停止。
  • センサーまたはユーザー入力イベント。
  • ファームウェア更新またはプロビジョニング操作。

この構成なら、メインCPUを可能な限り低消費電力状態に保てます。Bluetoothプロセッサーと無線部は、予定された接続イベントに合わせて起動して必要なプロトコル処理を行い、その後、システムを再び低消費電力状態へ戻します。

実際の電力プロファイルは、接続間隔、送信電力、アドバタイズの挙動、スリープモード、水晶振動子の構成、RFレイアウト、ファームウェアの方針、アプリケーションプロセッサーの起動頻度に左右されます。

ホスト、コントローラー、アプリケーションの境界

Bluetoothソフトウェアはしばしば2つの主要なレイヤーとして説明されます。

表: ホスト、コントローラー、アプリケーションの境界
レイヤー 主な責務
ホスト プロファイル、サービス、ペアリングポリシー、アプリケーション向けAPI、より高レベルのプロトコル挙動。
コントローラー リンクレイヤー、無線スケジューリング、パケットタイミング、暗号化サポート、低レベルのBluetooth手順。

SF32システムでは、コントローラー側の責務はBluetoothプロセッサーと無線サブシステムに密接に結びついています。ホスト側は、スタックアーキテクチャに応じて、アプリケーションプロセッサー上、システムファームウェア上、あるいはSDKが提供する複数のコンポーネントに分散して実行される場合があります。

アプリケーション開発者にとって最も重要な点は、Bluetoothの挙動がCPUの境界をまたぐということです。共有メモリー、プロセッサー間メッセージング、イベント、SDK APIは製品アーキテクチャの一部です。Bluetoothを、メインアプリケーションにリンクされた単なるライブラリとしてではなく、サブシステムとして扱ってください。

アプリケーションプロセッサーとの相互作用

アプリケーションプロセッサーは通常、製品レベルの挙動を制御します。

  • アドバタイズの開始と停止。
  • 接続の作成または受け入れ。
  • GATTサービスとキャラクタリスティックの管理。
  • ペアリング、ボンディング、セキュリティポリシーの処理。
  • スマートフォンまたはゲートウェイとのアプリケーションデータの交換。
  • Bluetoothの状態が変化した際のUI状態の更新。
  • オーディオストリーム、センサー、電力モードの調整。

Bluetoothプロセッサーは、接続を維持するために必要な低レベルの処理を担当します。両者の間の通信は、通常SDKのAPI、イベント、キュー、またはプロセッサー間通信の仕組みによって抽象化されています。

良いアプリケーション設計は、不必要な処理のためにメインCPUを起こすことを避けます。可能な場合はイベントをバッチ処理し、適切な接続パラメーターを選び、イベント駆動のコールバックが利用可能な場合は高頻度のアプリケーションポーリングを避けてください。

RFとクロックに関する考慮事項

Bluetoothプロセッサーだけでは良好な無線性能を実現できません。周辺のハードウェア設計が重要です。RFレイアウト、アンテナのチューニング、クロックの精度、電源品質、量産時の校正はすべて、到達距離、感度、送信電力、接続の安定性に影響します。

重要なハードウェア上の考慮事項には次のものがあります。

  • 推奨されるRFマッチングネットワークとアンテナレイアウトを使用する。
  • RF配線は短く、インピーダンスを制御し、ノイズの多い信号から十分に分離しておく。
  • ハードウェア設計ガイドの水晶振動子に関する要件に従う。
  • RFとクロック回路には低ノイズの電源を供給し、部品の近くにデカップリングコンデンサーを配置する。
  • RF校正と量産時のファームウェア書き込みに必要なテスト用接続を確保する。
  • ディスプレイやストレージの高速配線、スイッチング電源の配線を、ノイズの影響を受けやすいRF経路に近づけない。

ソフトウェアチームとハードウェアチームは、Bluetoothの性能をシステムの特性として扱うべきです。ファームウェアのパラメーターは、不適切なRFレイアウトや不安定なクロックを完全に補うことはできません。

他の処理との共存

SF32デバイスでは、グラフィックス、オーディオ、センサー、ストレージ、場合によっては外部Wi-FiとBluetoothを同時に動かします。これらのサブシステムは、電力、クロック、メモリー帯域幅、ピン、CPU時間などの資源を共有します。

共存時には、たとえば次の点に注意が必要です。

  • ディスプレイのリフレッシュやPSRAMトラフィックが利用可能なメモリー帯域幅に影響すること。
  • オーディオDMAとBluetoothオーディオバッファーが安定したタイミングを必要とすること。
  • センサー割り込みがアプリケーションプロセッサーを頻繁に起こしすぎること。
  • 外部Wi-Fiやその他のRFソースがBluetoothの性能に影響すること。
  • 長いクリティカルセクションや割り込みの無効化が、ホスト側のBluetooth処理を遅らせること。

Bluetoothプロセッサーはタイミングが乱れるリスクを抑えますが、共有資源のボトルネックをすべて解消するわけではありません。オーディオ、リッチなUI、外部無線接続を備える製品は、実際の使用を想定した最悪条件でテストしてください。

一般的なユースケース

Bluetoothプロセッサーは、多くのSF32製品カテゴリの中心にあります。

  • Bluetoothモジュールとシリアルアダプター。
  • エントリーレベルのスマートウォッチとフィットネスバンド。
  • BLE健康センサーとウェアラブルデバイス。
  • Bluetoothオーディオアクセサリ。
  • スマートバッジと電子棚札。
  • スマートフォンに接続されたダッシュボードとHMIデバイス。
  • スマートホーム制御機器やスマートフォン連携製品。
  • センサー同期とデータロギングデバイス。

適切なSF32の型番は、BLEのみでよいか、デュアルモードBluetoothが必要かに加え、オーディオ、ディスプレイ、メモリー容量、ユーザーがプログラムできる低消費電力処理の要件によって決まります。

実践的な設計ガイダンス

SF32向けにBluetoothファームウェアを設計する際は、まず製品の接続要件を整理してください。

  • 製品はBLEのみ必要か、それともデュアルモードBluetoothが必要か。
  • Bluetoothオーディオは必要か。
  • どのような接続間隔、レイテンシ、スループットが必要か。
  • メインのアプリケーションプロセッサーをどの程度の頻度でスリープから復帰させる必要があるか。
  • どのイベントがシステムをDeep SleepやStandbyから起こさなければならないか。
  • センサーまたはUIタスクがBluetoothのタイミングと競合しているか。
  • どのようなRF到達距離と送信電力の目標が必要か。
  • 量産時のファームウェア書き込みとRF校正はどのように処理されるか。

堅牢なBluetooth設計では、Bluetoothプロセッサーに加え、適切な接続パラメーター、イベント駆動型のアプリケーションコード、低消費電力状態の計画、適切なRFレイアウトを組み合わせます。

要点のまとめ

  • SF32LBデバイスは、無線動作の信頼性と電力効率を保つために、専用のBluetoothまたは低消費電力プロセッサーサブシステムを使用します。
  • SF32LB52xはBluetoothコントローラー専用の低消費電力コアを使用します。SF32LB55x、SF32LB56x、SF32LB58xでは、SDKがサポートする構成に限り、LCPUにアプリケーションタスクを割り当てられます。SF32LB57xはLCPUをBluetoothと電力に敏感な処理に使用しますが、計画しているユーザータスクごとに、対象のSDKとボードでの対応を確認してください。
  • プログラム可能なLCPUでは、SDKの制約内でアプリケーション処理を実行できます。コントローラースタックのソース利用や変更の可否は別途確認し、ベンダーが提供する更新を使って変更後の動作を検証してください。
  • BLEは低消費電力の接続製品向けに最適化されており、デュアルモードBluetoothはオーディオやレガシープロファイルなど、クラシックBluetoothの用途にも対応します。
  • Bluetoothプロセッサーは、接続、アドバタイズ、スケジュールされた無線イベントが継続する間も、メインのアプリケーションCPUがスリープするのを助けます。
  • 良好なBluetooth性能は、ファームウェアアーキテクチャとハードウェア設計の両方に依存します。RFレイアウト、クロック、電源、アンテナのチューニング、校正を含みます。
  • Bluetoothを、ホスト/コントローラーの境界、プロセッサー間通信、電力ポリシーの判断、共有リソースの制約を持つサブシステムとして扱ってください。

最終更新: