スリープモードの使い分けとFW実装のポイント
バッテリ駆動の組み込み機器で消費電力を追い込むカギは、ハードウェアの選定だけではありません。スリープモードの使い分け、クロックと電圧の動的制御、DMAによるCPU稼働時間の最小化、パワープロファイラによる実測と検証などがあります。
このようにファームウェア開発者が主導権を握れる領域は想像以上に広く、設計の早い段階で押さえておくと後工程の手戻りが減るでしょう。
- なぜFW開発者が低消費電力設計を主導すべきか
- スリープモードの種類と使い分け
- クロックと電源の動的制御
- DMA・割り込み・スヌーズモードの活用
- 消費電力の計測と最適化サイクル
- 低消費電力設計のハマりどころチェックリスト
なぜFW開発者が低消費電力設計を主導すべきか
バッテリ駆動の組み込み機器で消費電力を決めるのは、ハードウェアの選定よりFW側のスリープ遷移とクロック管理です。
というのも、あるマイコンのマニュアルを見ると、ノーマルモード時に最大12 mA流れる電源電流が、ソフトウェアスタンバイでは0.25µAまで落ちます。この差は大きく、蛇口を開けっぱなしにして節水シャワーヘッドの効果を期待するようなものです。そのため、 回路設計者任せではどうにもなりません。
ただ、どのタイミングでスタンバイへ入れ、どの周辺モジュールを止めるかはFWの設計判断そのものです。ここは地味ですが効いてくるところで、スリープモードの選び方やクロック・ペリフェラルの制御、計測による改善サイクルまで、FW開発者がペリフェラル単位で握っておく必要があります。
スリープモードの種類と使い分け
MCUの低消費電力モードはスリープからスタンバイまで多段階にわかれており、消費電流が下がるほど復帰は遅い傾向です。
そのため許容できる復帰時間から逆算して選ぶのが手っ取り早く、ここを曖昧にしたまま進めると後から設計が揺れます。
Sleep／Stop／Standbyの違い
ARM Cortex-Mのコアが持つ低消費電力命令はWFIとWFEの2つで、SLEEPDEEPビットによりSleep／Deep sleepを切り替えます。各ベンダーがこの上にチップ固有のモードを重ねており、STM32シリーズではSLEEPがSleepモード、DEEPSLEEPがStop／Standbyに該当します。
Sleepはコアだけ停止でペリフェラルは動いたまま、STM32L0では復帰が0.36 µsと高速です。一方Stopになると大半のクロックが止まり、復帰にはµs～msかかりますが、SRAMは保持されるためそのまま処理を再開できます。
Standbyまで落とすとSRAMが消え、復帰はリセット相当です。ここの線引きは後から変えにくいため、バッテリ寿命最優先の用途でなければStopを基本に据えておくのが手堅いでしょう。
ウェイクアップソースの選定と復帰時間の設計
ウェイクアップソースは用途で絞り込むのが先です。定周期ならRTCアラーム、外部イベントならGPIO割り込み、通信待受けならUART受信、アナログ監視ならコンパレータしきい値。このように、必要なソースによってモードの選択肢が決まります。
その際に見落としやすいのが復帰後のクロック構成です。STM32ではStopモード復帰時にPLLが止まっているため、高速クロックがいる場面では再起動の安定待ちが避けられません。なお、内蔵RC発振（HSI）をウェイクアップクロックに指定しておけば、この待ちは省けます。
クロックと電源の動的制御
スリープモードだけが省電力の手段ではありません。MCUが動いている間も、クロック周波数や電源電圧を絞ることで消費電力は下げられます。
動的周波数スケーリング（DFS）と電圧スケーリング
処理負荷に応じてクロック周波数を落とせば、動的消費電力はほぼ比例して下がります。RA2E3では48 MHz時に4.80 mA、8 MHzで1.40 mAという差です。STM32LのようにVOSで内部電圧を段階切替できるMCUなら、さらに静的電流も削ることができます。
ただし周波数を変えるとUSARTのボーレートなどにも響くため、切替タイミングの設計では手を抜けない部分です。
ペリフェラルのクロックゲーティング
使っていないペリフェラルのクロックを止めるだけでも、消費電流は目に見えて変わります。STM32ではRCCレジスタでUART・SPI・TIMERなどのクロックを個別にON／OFFできますが、HALの初期化テンプレートがデフォルトで一括有効にしているケースは少なくありません。
「全部ONのまま動いていた」と気付くのはたいてい計測段階のため、ここは初期化コードを一度さらっておくだけで確実に消費電力を削れます。
DMA・割り込み・スヌーズモードの活用
消費電力を削るもう一つの軸は、CPUが起きている時間そのものを短くすることです。データ転送や待受けをCPU以外に任せる設計パターンを押さえておくと、スリープ比率を大きく伸ばせます。
DMA転送でCPUスリープ時間を最大化する
ADCの連続変換結果をDMAでSRAMへ運び、バッファが埋まった時点の割り込みではじめてCPUを起こします。これが「イベント駆動＋DMA」の基本パターンです。UART受信でも、DMAとIDLE検出割り込みを組み合わせれば1バイトごとにCPUを起こさずに済みます。
なお、こうしたパターンを使わずにポーリングでCPUを回し続ける構成と比べると、消費電力の差は10倍から、設計次第で100倍近くまで開くこともあります。地味な配線仕事に見えますが、スリープ比率への影響は大きいでしょう。
スヌーズモード：CPUを起こさずペリフェラルだけで判定する
ルネサスRA・RXシリーズのスヌーズモードでは、ソフトウェアスタンバイ中にADCだけが間欠動作し、コンパレータでしきい値を判定して超えたときだけCPUを起こします。CPUが関与しない区間はスタンバイ相当の消費電流のまま常時監視を続けられる仕組みです。
STM32ではLPTIMとADC自動インジェクションで近い構成を組めますが、レジスタの設定手順はかなり異なります。考え方は共通でも、実装は各社ごとに読み替えがいるところです。
消費電力の計測と最適化サイクル
設計どおりの消費電力に収まっているかは、計算やシミュレーションだけでは見切れません。実機にプローブを当てることで、はじめて見えてくる差分があります。
パワープロファイラによる可視化
µA～mA帯の電流変化を時系列で捉えるには、いくつかのメーカが販売している、パワープロファイラを使います。スリープ→ウェイクアップ→処理→スリープの1サイクルを波形で表示し、想定外の電流ピークがどの区間で出ているかを特定するのが基本の使い方です。
データシートの代表値と実波形を突き合わせると、机上では見えなかった数十µAの漏れが浮かび上がることがあります。原因はペリフェラルの停止忘れやGPIOのフローティングが大半ですが、波形に出てしまえば切り分けは早いものです。
バッテリ寿命の見積もり計算
平均消費電流は（Irun × Trun ＋ Isleep × Tsleep）÷（Trun ＋ Tsleep）で求めます。たとえばCR2032（公称220 mAh）で、Run 10 ms／1 s周期、Irun=5 mA、Isleep=2 µAなら平均は約52 µA。220÷0.052で約4200時間、およそ半年の計算です。
ただし自己放電や温度特性、経年劣化があるため、実寿命は計算値の70～80％で見積もるのが無難です。バッテリ寿命計算ツールでも消費率のデフォルトは0.7に設定されていることが多く、計算値そのままを仕様書に書くと後で痛い目を見ることもあります。
低消費電力設計のハマりどころチェックリスト
見落としやすいポイントを一覧にしました。設計レビューやデバッグ時のチェック用にどうぞ。
- 未使用GPIOがフローティング入力のままになっていないか
- LDOの無負荷時消費電流（Iq）がスリープ電流を支配していないか
- デバッグ接続（SWD）をはずさずに電流を計測していないか
- 外付け部品にスリープ前のシャットダウンコマンドを送り忘れていないか
- プルアップ抵抗経由で常時µAオーダーの電流が流れていないか
一つでも残っていると、ファームウェア側でどれだけ追い込んでもスリープ電流は下がりません。「コードは完璧なのに数字が合わない」という場面では、まずこのリストを上から順に当たってみるとよいでしょう。
