低消費電力設計の概要¶

本ガイドの目的と対象¶

このガイドでは、SF32デバイスの実践的な低消費電力設計を取り上げます。電源モード、実際にバッテリーを消費する要因、システムをできるだけ長く低消費電力状態に保つファームウェアの構成方法を説明します。消費電力はシステム全体で決まります。Bluetooth、グラフィックス、オーディオ、AIに関する設計判断はすべて消費電力に直結するため、ここでは各要素をまとめて扱います。

SiFli SDKでは、SF32LB52xを含む一部のデバイス向けに、RT-Threadベースの**PM（Power Management、電源管理）**ミドルウェアが提供されています。利用可能なモードやウェイク動作はデバイスやSDK設定によって異なるため、対象デバイスの資料で確認してください。選択したSDKがBluetoothコントローラーの処理を別のプロセッサーに割り当てるファミリー（Bluetoothプロセッサーのアーキテクチャを参照）では、アプリケーションCPUをイベントごとにウェイクさせずに無線イベントを処理できる場合があります。CPUがスリープを維持できるかどうかは、タスクの配置、設定されたウェイク要因、プロセッサー間通信に依存するため、対象デバイスで確認してください。

バッテリー駆動時間の目標を、測定可能な根拠に基づいてファームウェアとハードウェアの設計判断へ落とし込む際に、このページを参照してください。接続待機、ディスプレイ動作、オーディオ、センシング、AI、ユーザー応答性のバランスを取るエンジニアを対象としています。スリープを単一のAPI呼び出しとして扱うための資料ではありません。

まず製品の電力予算を定義する¶

電源管理コードを書く前に、その製品で何を「十分」とするのかを定義します。

• 目標バッテリー駆動時間（時間、日、週）とバッテリー容量
• 想定デューティー比：1日のうち、積極的に使用する時間、接続したまま待機する時間、完全にスリープする時間の割合
• システムをウェイクさせる必要があるイベントと、ウェイク後に許容できる応答時間
• 常時動作させる必要があるサブシステム（接続中のBluetoothリンク、常時表示ディスプレイ、音声トリガーなど）と、イベント発生時のみ動作させられるサブシステム
• 製品の電源方針に関係する場合は、充電動作と想定充電サイクル

これらの目標は、チップやディスプレイの選定、常時音声待ち受けや常時表示のような機能を電力予算内で実現できるかといったアーキテクチャ上の判断を、早い段階から導くものとして扱ってください。

電源モードとPMフレームワーク¶

次の分類はシステム状態を概念的に示すもので、SF32のハードウェアモードやSDKの列挙値をそのまま示すものではありません。対応するモード、ウェイク要因、状態保持の動作は、使用するデバイスとSDKの資料で確認してください。

実際の負荷に応じて、システムは状態間を遷移します。設定されたウェイク要因がCPUまたはサブシステムを低消費電力状態から復帰させます。ウェイクとクロック復帰の順序はデバイスによって異なります。処理後、担当するドライバーやタスクはスリープを阻止するPM要求を解除し、設定済みのポリシーが条件を満たす低消費電力状態を選択できるようにします。次の波形は相対的な遷移を示す概念図であり、実機固有の電流値や時間を示すものではありません。

図: 短い処理中の電源モード遷移の概念図

モードの選択とスリープの抑止は別の仕組みです。SiFliのSF32LB52x PMミドルウェア資料とSF32LB55x低消費電力ガイドでは、rt_pm_request(PM_SLEEP_MODE_IDLE)を呼ぶと、対応するrt_pm_release(PM_SLEEP_MODE_IDLE)が呼ばれるまでLIGHT、DEEP、STANDBYへの移行が禁止されることが説明されています。この要求自体が、より深いモードを選択するわけではありません。

実装時は対象ファミリーの公式低消費電力ガイドを参照してください：SF32LB52x、SF32LB55x、SF32LB56x、SF32LB58x。利用できるモード、移行条件、ウェイク要因、保持される状態は、チップファミリー、ボード、SDK設定によって異なります。SF32LB52x低消費電力ガイドには、58x/56x/52x/57x向けと明記されたHibernate用ウェイクピン設定例があります。また、共通のSDK HAL PMU API資料には、SF32LB57xでHAL_PMU_EnablePinWakeup()に使用するインデックス範囲が0から13と記載されています。これらの資料が裏付けるのはこのウェイクピン設定までであり、52xのRT-Threadモードの対応状況、PMポリシーのしきい値、状態保持の仕様が57xにも適用されることを示すものではありません。これらの点は対象SDKとデバイス資料で確認してください。一般に、アイドル時間とその他の移行条件を満たす場合に限り、設定済みポリシーがより深い適格な状態を選択できます。要求を解除しないと、システムが想定より浅い状態にとどまることがあります。

SF32製品の電力消費要因¶

サブシステムごとに電力特性は異なります。

これらすべてを一度に改善できる単一の対策はありません。実製品の電力最適化では、各サブシステムの寄与を調整し、サブシステム間で共有される「どこまで深くスリープできるか」という条件を含め、全体の効果を検証します。

スリープを前提にしたファームウェア設計¶

大きな電力削減は、低レベルの工夫よりもファームウェアの構成から得られることが多くあります。

• ポーリングより、割り込みとイベントを優先する。 ポーリングループは、処理対象がないときもCPUを動作させ続けます。
• 処理をまとめる。 レイテンシーが許す範囲で、センサーサンプル、Bluetoothイベント、オーディオブロックを蓄積し、1件ごとにウェイクするのではなくまとめて処理します。
• スリープを阻止するPM要求を速やかに解除する。 より深い低消費電力状態への移行を阻止するPM要求を保持するドライバーやタスクは、その阻止が不要になった時点で対応する要求を解除してください。要求を解除しないと、システムが想定より浅い状態にとどまることがあります。
• フレームワークが対応する箇所では、UIとオーディオの経路をタイマー駆動ではなくイベント駆動で設計する。
• タイマーを監査する。 周期タイマーは将来の処理を予定し、システムをウェイクさせたり、PMポリシーが利用できるアイドル時間を短くしたりすることがあります。無害に見えるタイマーが複数あると、より深い低消費電力状態にとどまる時間が減る場合があります。

検証済みの低消費電力サンプルから始める¶

製品のバッテリー駆動時間を見積もる前に、不確実性が最も高い電源境界を確認できるSDKサンプルを選びます。低消費電力SDKサンプルでは、公式のPM、GPIO、プロセッサー、Bluetooth、ディスプレイ、GUI、画面更新、Raise-to-Wakeの各プロジェクトを、検証対象のシナリオと対応付けています。また、サンプルを製品の裏付け資料として使う前に再確認すべき電源接続、ボード、設定、ウェイク要因、外部回路、ワークロードの前提も説明しています。

Bluetoothの電力調整¶

Bluetoothの電力を左右する主な要素は接続パラメーターとアドバタイズパラメーターです（Bluetoothの概要の表を参照）。

• アイドル時間の長いリンクでは、接続間隔とスレーブレイテンシーを大きくします。
• 通信距離の要件を満たす範囲で、送信電力を可能な限り下げます。
• 初回の検出より再接続が想定される製品では、過度に頻繁なアドバタイズを避けます。
• 選択したSDKがBluetoothコントローラーのイベントを別のプロセッサーで処理する場合、アプリケーションタスク、ウェイク要因、プロセッサー間メッセージが不要であれば、アプリケーションCPUは接続イベント間にスリープできます。BluetoothコールバックごとにCPUをウェイクさせると、その利点が小さくなります。対象デバイスのコアとタスクの配置を確認してください。

Classic Bluetoothのみ、BLEのみ、および両者を併用するデュアルモードでの実消費電力をシナリオごとに測定する方法については、Bluetoothの消費電力を測定・分析するを参照してください。

ディスプレイとバックライトの電力¶

ウェアラブルや携帯機器では、ディスプレイとバックライトが最大の消費電力要因になることがよくあります。

• パネルとUIが対応する場合は、全画面再描画ではなく、部分更新や変更領域のみの更新を使います（ディスプレイコントローラー：部分更新を参照）。
• 操作がないときは画面の輝度を下げ、バックライトを備えるパネルでは消灯します。画面が暗くなったり覆われたりしたら、アニメーションも停止します。
• 常時表示が必要な製品では、EPD、JDI／メモリーインピクセル、AMOLED、TFTなどを、常時表示時の実測エネルギーと必要な使い勝手で比較します。通常のアクティブ表示を動かし続けるのではなく、電力予算に合ったパネルと動作方針を選んでください。
• 常時表示は「アイドル」の意味自体を変えるため、独立した電力予算項目として扱います。

AIとセンサーの電力調整¶

オンデバイス推論とセンサーサンプリングは、常時実行せず、明確な方針に基づいてスケジュールしてください。

• 入力の有無にかかわらず固定タイマーで推論するのではなく、新しく有用なデータが得られたときに実行します。
• デバイスとSDKが対応する場合、軽量な常時センシングはメインのアプリケーションCPUをサンプルごとにウェイクさせるのではなく、低消費電力プロセッサーへ移します。
• レイテンシーだけでなく、推論1回またはサンプル1回あたりのエネルギーを測定します。処理が高速でも、その分早くスリープへ戻れる場合に電力上の利点があります。

精度、レイテンシー、電力のトレードオフはAI概要を参照してください。

メモリーとクロックの考慮事項¶

コードをどこから実行するかは、性能と電力の両方に影響します。該当するキャッシュ機能を実装し、有効にしているSF32デバイスでは、命令キャッシュとデータキャッシュによってFlashやPSRAMへのアクセス待ち時間を短縮できます。アクティブ時間を短くできれば、その分スリープ時間を増やせます。キャッシュとメモリーシステムについてはSTAR-MC1を参照してください。

CPU以外にも、次の点を考慮してください。

• 外付けPSRAMとFlashには、それぞれアクティブ／スタンバイ時の電力特性があります。スリープ中も大きなバッファーを保持する必要がある場合は、保持電力とアクセス電力をデータシートで確認します。
• クロック源（水晶振動子か内部発振器か、どのPLL／クロックドメインを動作させ続けるか）は、ウェイクレイテンシーとスリープ時の電力に影響します。
• 負荷の軽い処理ではCPU周波数を下げると効果が得られる場合があります。ただし、アクティブ時間が延びて効果が相殺されないことを確認してください。瞬時電流ではなく実際のエネルギーを測定します。

ハードウェアとRFの電力に関する考慮事項¶

ファームウェアの電源方針は、ハードウェアで実現できる範囲に制約されます。

• PMIC／LDOの効率は、無関係な負荷条件での公称効率より、製品が実際に使う負荷電流での効率が重要です。
• RFレイアウトとアンテナ調整は、安定した通信距離を得るために必要な送信電力に影響します。RF設計が不十分だと、ファームウェア側で送信電力を上げる必要が生じ、バッテリー駆動時間を縮めます。Bluetoothプロセッサーのアーキテクチャ：RFとクロックの考慮事項を参照してください。
• 水晶の精度は、RFのタイミングマージンと、ファームウェアが設定する監視タイムアウトやウェイクマージンに影響します。
• 量産試験／校正用のアクセスを設計に残してください。電力とRFの調整は、最初のハードウェアリビジョン後も続くことがあります。

ケーススタディ：手首を上げたときの画面点灯¶

手首を上げたときに画面を点灯するのは、ウェアラブル機器でよく使われる機能ですが、実装方法はセンサー、ボード、SDKによって異なります。SiFliのSF32LB52x向け手首上げ時の画面点灯サンプルは、sf32lb52-lchspi-ulpボードを対象とし、LSM6DSL（加速度センサー／ジャイロスコープ）の加速度データを200 ms間隔で取得して手首の上げ下げを認識します。10秒間操作がないとスリープし、手首上げを検出すると復帰して画面を点灯します。これは特定ボード向けの実装例であり、他のターゲットでセンサー割り込みが使われることや、同じPM動作が得られることを示すものではありません。対象センサーが動き検出／しきい値割り込みに対応していれば、設定したウェイク要因として利用し、アプリケーションCPUによる継続的なポーリングを避けられる場合があります。そうでない場合は、センサーのサンプリングとCPUのウェイクを電力予算に含めてください。実際のターゲットに応じて、センサー、ボード、ウェイク要因、PM設定を確認してください。

電力予算ワークシート¶

ファームウェアを調整する前に、製品目標を数値化します。通常は次のような簡単なワークシートで十分です。

互いに重ならない動作状態の組み合わせでは、average current = state current x duty cycle（平均電流 = 状態ごとの電流 × デューティー比）を見積もり、各状態の寄与を合計します。負荷が同時に動作する場合は、重複する状態を二重計上しないよう、該当シナリオの合計に含めてください。これにより設計上の問題を早期に把握できます。20 μAというスリープ電流の目標を達成しても、明るいバックライトや固定間隔の推論ループが動作している時間が長すぎる製品は救えません。

電力プロファイリング：モデル化、測定、更新¶

電力プロファイリングでは、電力予算を再現可能なエンジニアリングサイクルに変えます。代表的なシナリオを定義し、該当する電源境界で電圧と電流を記録するとともに、各負荷の継続時間と頻度を考慮します。時間に対するエネルギーを求め、電源レールごとの測定値は電源変換損失を含めてバッテリー側の消費量に換算してください。電圧の異なるレールの電流をそのまま足し合わせてはいけません。これによりバッテリー側の平均電流、1日あたりの電荷消費量、駆動時間を推定し、優先して測定・最適化するシナリオを選べます。

flowchart LR
    A["代表的な製品シナリオを定義"] --> B["電流、電圧、継続時間、頻度の前提を設定"]
    B --> C["イベント単位／日単位のエネルギーを算出"]
    C --> D["バッテリー予算と比較し、主な寄与要因を順位付け"]
    D --> E["優先シナリオを実機で測定"]
    E --> F["実測電流と時間でモデルを更新"]
    F --> B

プロファイルは電流計ではなく推定値として扱います。NordicのBluetooth LE向けオンライン電力プロファイラーも同じ考え方に基づいています。測定から作られたモデルを利用しますが、出力はあくまで期待値であり、特定製品の実測値ではありません。電流はシリコン、基板設計、バッテリー電圧、温度、RF環境、ファームウェアのタイミング、使用シナリオによって変動します。

各シナリオでは、エネルギーに大きく影響する前提を記録します。

• どのサブシステムが動作しているか。MCUは実際にどの電源モードへ移行しているか。
• バッテリー入力または各レギュレーター出力での電流はいくらか。
• 処理はどのくらい継続し、典型的な1日に何回発生するか。
• どの電流ピークが想定内で、どのピークが意図しない処理やスリープ失敗を示しているか。

推定値から予算への寄与が大きい項目を特定し、バッテリー駆動時間を主張する前に実機で該当シーンを検証します。スマートウォッチの消費電力分析では1日の使用モデルを使って手順を説明し、電力測定と検証では再現可能な測定方法を定義しています。

PM要求とウェイク要因のレビュー¶

信頼性の高い低消費電力設計では、すべてのウェイク要因とスリープを禁止する要求の担当を明確にします。設計レビューでは、次の項目を確認してください。

デバッグ時には、設定済みのPMポリシー、より深いモードを阻止している有効な要求、SDKやログが示す直近の低消費電力モードを記録してください。想定より浅い状態にとどまる場合、これらの記録は単独の電流値より診断に役立つことがあります。

実際の電力測定¶

推測ではなく測定してください。基本的な電力検証環境には、次のものが必要です。

• バッテリー／電源とボードの間に入れる電流プローブまたはインライン電力アナライザー
• 実際の製品使用に即した試験シナリオ：接続アイドル、UI操作、オーディオ再生、AI推論バースト、複合負荷の最悪条件
• 電流変化をコード経路に対応付けられるよう、アクティブ／アイドル／スリープなどのファームウェア状態を記録またはマークする方法

SiFli SDKの資料には、一部のデバイスやボード向けに、AMOLED／JDIディスプレイ、GPIO、BLE／Classic Bluetooth、CoreMark形式のCPU負荷などを扱う電力特性評価用サンプルがあります。対象SDKとボードの資料で、サンプルの有無と設定方法を確認してください。該当するサンプルは測定手順の参考や電流値の妥当性確認に使えますが、製品固有の電力を保証するものではありません。

電力検証マトリクス¶

ファームウェアのリビジョン間で改善を比較できるよう、再現可能な試験シナリオを用います。最低限、次を測定してください。

ファームウェアのバージョン、ボードリビジョン、バッテリー／電源電圧、温度、アンテナ／筐体の構成、試験スクリプトを記録します。これらのメタデータがないと、電力値を比較しにくく、誤って解釈しやすくなります。

消費電力が大きい場合のデバッグ¶

よくある間違い¶

• 電力最適化を初期設計の制約ではなく、最後の仕上げとして扱う。
• 割り込みやイベントを使わず、センサー、Bluetooth状態、タイマーをポーリングする。
• 必要な処理が終わった後もPM要求を保持する。
• 小さなUI変更のたびにディスプレイ全体を再描画する。
• RFレイアウトの品質を軽視し、ファームウェア側で送信電力を上げて補う。
• 現実的な使用シナリオでのエネルギーではなく、瞬時電流だけを測定する。
• ベンチ上だけで電力を検証し、実アンテナとバッテリーを使った最終筐体で試験しない。

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

• 目標バッテリー駆動時間、デューティー比、必要なウェイク要因を定義する。
• 常時動作が必要なサブシステムと、完全にイベント駆動にできるサブシステムを特定する。
• 各ドライバー／タスクが使用後すぐにPM要求を解除することを確認する。
• 実際の製品使用パターンに合わせてBluetoothのアドバタイズ／接続パラメーターを調整する。
• 対応するディスプレイ経路で部分更新を使い、バックライト方針を製品の動作に合わせる。
• 周期タイマーをすべて監査し、不要なタイマーを削除または統合する。
• 電流測定環境を用意し、アクティブ、アイドル、スリープ状態を個別に検証する。
• 複合負荷の最悪条件（該当するBluetooth、ディスプレイ、オーディオ、AI）を試験し、電力予算を満たすことを確認する。
• プロジェクト終盤だけでなく、重要なファームウェア変更のたびに電力を再検証する。

要点¶

• 電力はシステム全体の特性です。Bluetooth、ディスプレイ、オーディオ、AI、メモリーの設計判断は、デバイスがどれだけ深く、どれほど頻繁にスリープできるかに影響します。
• 設定済みのPMポリシーは、条件を満たす低消費電力状態から移行先を選びます。より深い状態を阻止する要求が解除されないと、システムは想定より浅い状態にとどまることがあります。
• 電力が重要な場面では、ほとんどの場合、イベント駆動／割り込み駆動設計がポーリングより有効です。
• 接続状態を維持するウェアラブル製品では、Bluetooth接続パラメーターとディスプレイ更新方針が特に大きな調整要因になります。
• 現実的な複合ワークロードを実機と最終筐体で測定してください。ベンチ測定や個々のサブシステムの測定だけでは、実製品の消費電力を過小評価する場合があります。

電圧からバッテリー残量の割合を推定する方法は、バッテリー残量の推定を参照してください。

最終更新: 2026-10-21