エネルギー最適化STM32：実用ガイド

こんにちは、Habr！



ネットワークには、エネルギー効率の高いデバイス（通常はバッテリー駆動のデバイス）でのSTM32マイクロコントローラーの動作に関する記事が非常に多くありますが、それらの中でも、それらを含む省エネモードとSPL / HALコマンドのリストを超えてこのトピックを理解していないのは残念です（ただし、同じ主張が適用されます） STM32での作業に関する記事の大部分に）。



一方、スマートホームとあらゆる種類のIoTの急速な発展により、トピックはますます重要になっています-そのようなシステムでは、多くのコンポーネントがバッテリー駆動であり、それらから何年もの連続動作が期待されます。



このギャップをSTM32L1の例で埋めます-非常に人気のあるコントローラーで、非常に経済的であると同時に、このシリーズに特有のいくつかの問題があります。 述べられているほとんどすべては、STM32L0およびSTM32L4に適用され、一般的な問題とアプローチの観点から、Cortex-Mコアに基づく他のコントローラーにも適用されます。







実際の結果は上の写真のようになります（そして、はい、マルチメーターや他の測定器の同様のタスクへの適用性についても説明します）。

STM32L1の省電力モード

バッテリー節約の基本は、プロセッサの主要な省電力モードです。 各メーカーとコントローラーの各シリーズには独自のものがあります（特定のセットは、周辺機器、電源電圧などに関するさまざまなニュアンスを持つ標準のCortex-Mコアモードのベンダー拡張です）。



具体的には、経済的な一連のコントローラーに属するSTM32L1は、これに関連して、拡張された一連の電力設定を受け取りました。

• 実行 -通常モード。 包括的、利用可能なすべての周辺機器、最大32 MHzの周波数。
• 低電力運転（LP運転）は、 周辺全体が 200μAであることを考慮して 、131 kHz以内の動作周波数と最大消費量を持つ特別なモードです。 LP実行モードでは、プロセッサー電源レギュレーターは特別な経済的なモードに入り、実行モードで同じ周波数で動作するのに比べて最大50マイクロアンペアを節約します。
• スリープ -カーネルを一時停止しますが、すべてのクロック周波数を保持します。 カーネルが必要としない場合、プロセッサ周辺機器は引き続き動作しますが、自動的にオフにすることができます。
• 低電力スリープ（LPスリープ） -スリープとスタビライザーのエコノミーモードへの移行の組み合わせ。 クロック周波数は131 kHz以下で、総消費量は200μA以下です。
• 停止 -外部または内部の「クロック」ジェネレーター32768 Hzを除く、すべてのクロック周波数の完全な停止。 STM32L1の場合、リアルタイムクロックのみがこのモードで動作し続け、他のすべては完全に停止します。 より新しいプロセッサでは、一部の周辺機器が低周波数からクロックする場合があります。 ほとんどすべてのプロセッサレッグが状態を保持します。 RAMの内容は保存され、外部割り込みは引き続き機能します。
• スタンバイ -リアルタイムクロックを除く、プロセッサコア、RAM、およびすべての周辺機器の完全なシャットダウン。 RAMは保存されません（つまり、ソフトウェアの観点からは、スタンバイ状態は電源の歪みとほぼ同じです-最初から開始）、RTCはチェックを続けます。 3つの特別なWKUPxレッグを除き、外部割り込みは機能しません。レッグの0から1への切り替えにより、プロセッサが起動します。

各モードに入るのは非常に簡単です-3〜5個のレジスタにフラグを設定し、その後（スリープモードの場合）WFIまたはWFE命令を呼び出す必要があります。これは標準のCortex-M命令で、「割り込み待ち」および「イベント待ち」を意味します。 フラグに応じて（プロセッサのリファレンスマニュアルに記載されています。STM32L1の場合はRM0038です ）、プロセッサ自体はこのコマンドでこのモードになります。



さらに、割り込みを禁止して（これにより、外部および内部イベントがプロセッサをスリープから復帰させる能力に影響を与えません）、DSBコマンドを使用して、レジスタからメモリへのデータの保存の完了を待ちます。



たとえば、停止モードへの移行は次のようになります。

/*  PDDS    Stop  Standby,    */ PWR->CR &= ~(PWR_CR_PDDS); /*  Wakeup   ,      */ PWR->CR |= PWR_CR_CWUF; /*    low-power ,    Stop -    */ PWR->CR |= PWR_CR_LPSDSR; /*    Vref   */ PWR->CR |= PWR_CR_ULP; /*     Cortex-M,  Stop,  Standby -   Deep Sleep */ /*      Deep Sleep */ SCB->SCR |= (SCB_SCR_SLEEPDEEP_Msk); /*  ;       */ unsigned state = irq_disable(); /*      */ __DSB(); /*  */ __WFI(); /*    */ init_clk(); /*     */ irq_restore(state);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

WFIはブロッキング命令であり、その上でプロセッサーはディープスリープに入り、何らかの割り込みが発生するまで終了しません。 はい、繰り返しますが、割り込みを明示的にオフにしたにもかかわらず、プロセッサは割り込みに応答して起動しますが、割り込みをオンに戻した後にのみ処理を開始します。 そして、これには深い意味があります。



上記のコードでは、WFIの後、動作周波数のある種の再初期化が行われているだけではありません-事実、L1は4.2 MHzの周波数で、この周波数のソースとして内部MSIジェネレーターで常にディープスリープを終了します。 多くの場合、プロセッサをウェイクアップする割り込みハンドラーがこの周波数で実行を開始するのは望ましくありません。たとえば、すべてのタイマー、UART、およびその他のバスの周波数がオフになるためです。 そのため、最初に動作周波数を復元します（または、MSIのままにする場合は、4.2 MHz未満の必要なバスを再計算します）。次に、割り込みに飛び込みます。



実際には、最も一般的に使用される2つのモードは実行と停止です。 実際のところ、LP Runは非常に遅く、プロセッサが外部イベントを待つだけでなく、何らかの計算を実行する必要がある場合には意味がありません。また、SleepおよびLP Sleepはあまり経済的ではなく（最大2 mAの消費）、必要な場合に必要です少なくともいくつかを保存しますが、同時に動作している周辺機器を離れる、および/またはイベントに対するプロセッサの可能な限り速い反応を提供します。 そのような要件は存在しますが、一般的にはそれほど頻繁ではありません。



通常、スタンバイモードは使用されません。これは、RAMのゼロ化により、中断したところから続行することが不可能であるためです。また、ハードウェアソリューションを必要とする外部デバイスにも問題があります。 ただし、デバイスがこれを念頭に置いて設計されている場合、このデバイスの長期保管中などに、スタンバイを「オフ」モードとして使用できます。



実際、このプレゼンテーションでは、ほとんどのマニュアルは通常勝手に途切れています。



問題は、それらに続いて、労働時間の停止で約束された1.4μAではなく、実際の消費量が100-200μAになることです-外部チップやセンサーなどを持たないNucleoリファレンスデバッグでもです。それに起因する可能性があります。



いいえ、プロセッサは動作しています。エラッタには何もありませんが、あなたはすべてを正しく行いました。



終わりではありません。

むずむず脚症候群

STM32L1の最初の問題は、 いくつかの記事で言及されていますが、ほとんどの場合フォーラムでのみ思い出されます。議論の3日目に、非常に100-200μAが発生した場所で 、誰かがAN3430の存在を覚えており、その中の19ページに到達しています-デフォルトでは脚の状態。



STMicro自体でさえスリーブを介して問題に言及していることに注意してください。エネルギー消費の最適化が考慮されるほとんどの文書では、理由を説明せずに、未使用の脚を地面に引っ張ったり、アナログ入力モードにしたりするアドバイスがある1つまたは2つのフレーズに制限されています。



悲しいことに、デフォルトでは、すべてのレッグがデジタル入力（GPIOx_MODERレジスタの0x00）として構成されています。 シュミットトリガーは常にデジタル入力にあり、この入力のノイズ耐性を改善しますが、完全に独立しています-これは単純なロジックエレメントであり、外部クロックを必要としないヒステリシスを備えたバッファーです。



この場合、これは、ストップモードでクロックをオフにし、シュミットトリガーが何も起こらなかったように動作し続けたことを意味します。入力信号のレベルに応じて、出力を0と1に切り替えます。



同時に、典型的な回路のプロセッサレッグの一部が宙に浮いています。つまり、それらに明瞭な信号はありません。 わかりやすい信号がないということは、これらのレッグに高い入力インピーダンスが原因でこれらのレッグに0が存在しないことを意味すると考えるのは間違っているでしょう。ピックアップと隣接するトラックから最初のテレビチャンネルに流れる電流から、不定値のランダムノイズがあります、足がアンテナとして機能するのに十分な長さである場合（ただし、ロシアのアナログテレビはすぐにオフになり、誤って構成されたマイクロコントローラーの電力消費がいくらか削減されるはずです）。



これらの変動に応じて、レッグは何らかのランダムな方法で0と1の間で切り替わります。CMOSロジックはスイッチング時に電流を消費します。 つまり、デジタル入力モードで構成された空中にぶら下がっているプロセッサ脚は、 それ自体で顕著な電流を消費します 。



この方法は簡単です-プログラムを起動するとき、すべてのレッグをアナログ入力の状態に設定する必要があります。 STM32は、ADCに接続されているかどうかに関係なく、例外なくすべてのレッグに対して正式に設定されており、入力にシュミットトリガーがない場合のみデジタル入力と異なります。







これを行うには、値0xFF ... FFをすべてのGPIOx_MODERレジスタに書き込むだけで十分です。上記のように、開始時にすぐにこれを行うのが最も簡単です。次に、プレイ中に、このデバイスで必要に応じて個々のレッグを再構成します。



ただし、ここでは2次の問題が発生します。ファームウェアが1つの特定のコントローラーで動作するので、GPIOxでxが何であるかを常に把握していると便利です。 さらに悪いことに、ファームウェアがユニバーサルな場合-STM32は最大 8つのポートを持つことができますが、それより小さくすることもできます。 コントローラのこのモデルに存在しないポートに書き込もうとすると、ハードフォールトが発生します。 カーネルクラッシュ。



ただし、この場合でも回避することができます-Cortex-Mでは、アドレスの有効性を確認できます。さらに、M3およびM4の場合、確認は一般に簡単ですが、M0では多少の魔法が必要ですが、実現可能です（ 詳細については 、こちらの記事を参照してください。 ）



つまり、一般に、プロセッサが起動し、周波数を調整し、すぐに利用可能なすべてのGPIOポートを通過して、それらをMODERポートに書き込みます（以下のコードはRIOT OS向けに記述されていますが、一般的にはコメントなしで3分に転送できます）その他のプラットフォーム）。

 #if defined(CPU_FAM_STM32L1) /* switch all GPIOs to AIN mode to minimize power consumption */ GPIO_TypeDef *port; /* enable GPIO clock */ uint32_t ahb_gpio_clocks = RCC->AHBENR & 0xFF; periph_clk_en(AHB, 0xFF); for (uint8_t i = 0; i < 8; i++) { port = (GPIO_TypeDef *)(GPIOA_BASE + i*(GPIOB_BASE - GPIOA_BASE)); if (cpu_check_address((char *)port)) { port->MODER = 0xffffffff; } else { break; } } /* restore GPIO clock */ uint32_t tmpreg = RCC->AHBENR; tmpreg &= ~((uint32_t)0xFF); tmpreg |= ahb_gpio_clocks; periph_clk_en(AHB, tmpreg); #endif
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これはL1シリーズにのみ適用され、L0およびL4ではエクスペリエンスが考慮され、デフォルトでは、起動時にすべてのポートがアナログ入力として設定されることに注意してください。



これらのすべての手順を注意深く行って、完成したデバイスにファームウェアを入力します...そして、ボードではんだ付けしたすべてのデータシートから推定値が最も悲観的であるという事実にもかかわらず、プロセッサとすべての外部チップで停止モードで150 uAを取得します10μAを超えないようにしてください。



さらに、プロセッサを停止ではなくスタンバイにしようとします。 ほぼ完全にオフにするだけで、電力消費は低下する代わりに3倍に増加し、約0.5ミリアンペアに近づきます！



パニックする必要はありません。 ご想像のとおり、すべてを正しく行いました。 しかし、最後までではありません。

むずむず脚症候群-2

次の問題には2つの部分があります。



最初のものは非常に明白です：デバイスが1つのマイクロコントローラーで構成されていない場合、シュミットトリガーがハングし、さらにチップの内部ロジックを呼び起こすことができる入力信号が外部チップにもあることを忘れないことが重要です。 たとえば、UARTチームによってスリープから取り下げられ、スリープから解除されたチップは、バスの動きに応じて、バス上のデータを読み取ろうとします。



したがって、これらの脚がすべて空中にぶら下がっていると、何も得られません。



どのような条件下で、彼らは空中で終わるのでしょうか？



まず、コントローラーがスタンバイモードになると、すべてのGPIOは高抵抗状態でHigh-Z状態に移行します。つまり、実際には、それらに接続された外部チップは空中にあります。 これをSTM32L1でプログラムで修正することは不可能です（他のシリーズおよび他のコントローラーでは異なる方法で発生します）。そのため、唯一の方法はスタンバイモードを使用するシステムで、外部チップの入力はグランドにプルするか、外部抵抗によって給電する必要があります。



特定のレベルは、チップの観点からラインが非アクティブになるように選択されます。

• UART TXの場合は1
• SPI MOSIの場合は0
• SPIモード0または1のSPI CLKの場合は0
• SPIモード2または3のSPI CLKの場合は1
• SPI CSの場合は1

第二に、 STOP （sic！） モードを使用するSTM32では、インターフェイスの内部ハードウェアブロックに接続されているGPIO の状態が異なる場合があります。 つまり、同じSPIインターフェイスが構成されている場合、Stopで突然、デジタル入力、または一般にHigh-Zのいずれかになることが判明し、それに対応する結果として、外部チップがハングします。 ドキュメントには脚が良好な状態にあると記載されていますが、脚を通常のGPIOとして使用する場合にのみ事前に信頼できます。



理解して許すことはできませんが、覚えて修正することはできます。このように動作するインターフェイスの場合、このインターフェイスの非アクティブレベルに対応するレベルで、通常のGPIOへの強制切り替えを追加する必要があります。 スリープ状態から抜けた後、インターフェイスを復元できます。



たとえば、スリープする前の同じSPI（単純にするために、RIOT OSからコードを取得しました。同じことがレジスタに実装するのが簡単であることは明らかです）。

 /* specifically set GPIOs used for external SPI devices */ /* MOSI = 0, SCK = 0, MISO = AIN for SPI Mode 0 & 1 (CPOL = 0) */ /* MOSI = 0, SCK = 1, MISO = AIN for SPI Mode 2 & 3 (CPOL = 1) */ for (i = 0; i < SPI_NUMOF; i++) { /* check if SPI is in use */ if (is_periph_clk(spi_config[i].apbbus, spi_config[i].rccmask) == 1) { /* SPI CLK polarity */ if (spi_config[i].dev->CR1 & (1<<1)) { gpio_init(spi_config[i].sclk_pin, GPIO_IN_PU); } else { gpio_init(spi_config[i].sclk_pin, GPIO_IN_PD); } gpio_init(spi_config[i].mosi_pin, GPIO_IN_PD); gpio_init(spi_config[i].miso_pin, GPIO_AIN); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでの出力は、レベル0または1のGPIO_OUTとしてではなく、0または1へのプルアップを持つ入力として構成されていることに注意してください-これは基本的なポイントではありませんが、間違えて何らかの種類のプルプッシュをしようとすると、追加のセキュリティが提供されますこのチップを反対方向に引っ張る外部チップ。 GPIO_OUTを使用すると、プルアップ付きのGPIO_INを使用して、短絡を調整できます。



さらに、SPI CS信号は影響を受けません。この場合、プログラムによって、つまり通常のGPIOによって生成され、夢の中で自信を持ってその状態を維持します。



スリープを終了するときに脚の状態を復元するには、変更されるレジスタ（MODER、PUPDR、OTYPER、OSPEEDR-特定のケースの状況を参照）の値を入り口で変数に書き込み、変数からスリープを解除するときにレジスタにロールバックするだけで十分です。



そして今... ta daaam！ タイトル画像。 1.5マイクロアンペア。



しかし、祝うには時期尚早です。 これで、エネルギー消費の静的な最適化が終了しました。そして、私たちの先には動的なものがあります 。

アキレスvsタートル

どちらが良いですか-より多く食べてより速く走るか、より少なく食べますが、より遅く走りますか？ マイクロコントローラーの場合、この質問に対する答えは自明ではありません。



まず、動作周波数は、65 kHz（LP実行）から通常モードで32 MHzまでの非常に広い範囲で変更できます。 他のCMOSチップと同様に、STM32には消費電力に静的と動的の2つのコンポーネントがあります。 2番目は周波数に依存し、1番目は一定です。 その結果、エネルギー消費は動作周波数や生産性ほど速く低下せず、タスクによっては、エネルギー効率の観点から最適な周波数が異なる場合があります-何らかのイベントを待つ必要があるが、何らかの理由で眠ることができない場合、低周波数は効果的で、数字を脱穀するだけです。 典型的な「病院平均」タスクでは、通常、2〜4 MHz未満にすると意味がありません。



第二に、これはささいなことではありませんが、睡眠から抜け出す割合は、動作周波数と受信方法に依存します。



最悪の場合は、外部クオーツから32 MHzの周波数でスリープ状態から抜け出すことです（STM32L1は内部4 MHzオシレーターで起動することを思い出させてください）。

• 実際にプロセッサはスリープから復帰します
• クォーツ世代安定化（1-24 MHz）
• PLL生成の安定化（32 MHz）

実際にここでプロセッサをスリープ状態から解除することは、4.2 MHzの周波数では約10μsかかりますが、最小の問題です。 ただし、クォーツの安定化には最大1 msかかります（通常、高速共振器の場合は数百マイクロ秒のオーダーでさらに高速ですが）、PLLモードへのアクセスはさらに160μsです。



これらの遅延は、めったに起動しないシステム（1秒に1回以下）のエネルギー消費の観点からは重要ではないかもしれませんが、起動間隔が数十ミリ秒以下で、起動自体が短い場合、オーバーヘッドは既に測定可能な追加を開始しますプロセッサの起動中に消費される電流は比較的小さいことを考慮してください。



これで何ができますか？ 一般的に、答えは明らかです。外部クオーツの使用を避けるようにしてください。 たとえば、正確なタイミング（たとえば、ささいなもの-UARTデータ交換）を必要とするまれな重いサブタスクや、頻繁な単純なサブタスクがあるプログラムは、目覚めるたびに、今のままにする必要があるかどうかを判断できます。または、プロセッサが周波数の初期化に多くの時間を費やすことなく既に起動しているMSIジェネレータで現在のタスクを実行するのが簡単（かつ高速！）になります。



ただし、この場合、周辺クロック周波数の調整、フラッシュメモリアクセスモード（遅延サイクル数）、プロセッサコア電圧（STM32L1では3つの可能な値から選択）などの調整が必要になる場合があります。 ただし、カーネルお​​よびメモリの動作モードに関しては、使用される最大周波数に推奨されるモードを選択することにより、それらを微調整することが可能です。これは、これらの周波数でのタスク量が少ないため、低周波数でのコアの非最適な動作が実際のパフォーマンスと消費電力に大きな変化を与えないためです実行されました。



そのような手段はすべて、モードの微調整にすでに適用されていますが（たとえば、ほとんどのOSやライブラリは、ボックスに近いものさえ知りません）、場合によっては、パーセント単位のスケールで、時にはそれ以上で平均消費量を減らすことができます。 たとえば、50 msごとにリードスイッチの接点をポーリングする水道メーターを想像してください。実際の調査には数十マイクロ秒かかります。この時間までにコントローラーを起動するまでに500μsを追加しますか？

耐えられないほど長い秒

エネルギー保存に直接関係しないが、それに関連して必然的に発生する別の問題-1秒未満の時間間隔をカウントする方法は？



事実、STM32L1には停止モードで動作するタイマーが1つしかありません。これはRTCであり、標準の時間単位は1秒です。 同時に、プログラムでは、少なくとも同じ水道メーターを取得するために、数十ミリ秒から数百ミリ秒の単位の時間間隔が常にあります。



になる方法 32768 HzからクロックできるLPTIMタイマーを備えたプロセッサーで実行しますか？ 実際には良いオプションですが、必ずしも必要なわけではありません。 それなしでも可能です。



すべてのSTM32L1ではありませんが、Catで始まります。 2（これらはプロセッサSTM32L151CB-A、STM32L151CC以降）、RTCブロックに新しいレジスタ（SSR、SubSeconds Register）が追加されました。 より正確には、ユーザーに見えるほど補足されていませんでした。さらに、サブ秒アラームALRMASSRとALRMBSSRが追加されました。



このレジスタには、理解できる時間単位は含まれていませんが、技術的な内部カウンターから収集されました。 STM32L1では、32768 Hzで刻々と進むクロックは、非同期と同期の2つの分周器カウンターを通過し、通常合計32768で分周してクロックの1秒の刻みを取得します。 したがって、SSRは2番目のカウンターの現在の値にすぎません。



SSRはミリ秒単位ではなく単位でカウントしますが、これらの単位の次元は、RTC入力で標準の1秒を取得するために32768に等しい合計係数を維持しながら、同期および非同期カウンターの除数の比率を変更することで変更できます。 これらの係数がわかれば、SSRの1区分の価格をミリ秒単位で計算でき、ここから1秒未満のアラームのプログラミングに進むことができます。



非同期予備カウンターは同期SSRよりも経済的であるため、1に設定し、入力周波数をSSRに32768で除算し、わずか30μsのカウントを受け取っているため、エネルギー的に不利なことに注意してください。 私たち自身は、同期-4095（（7 + 1）*（4095 + 1）= 32768）の予備除算器7の最適値を決定しました。 予備分周器がさらに減少すると、RTCのエネルギー消費量はわずかなマイクロアンペアで測定可能に増加し始めますが、これを停止モードの「基準」1.4μAと比較するため、フラクションも重要です。 デフォルトでは、STM32L1の場合、これらの値は127と255です。 基準価格は約4ミリ秒で、これは少し大雑把です。



コードをさらに深く掘り下げたい場合は、やがてRIOT OSの標準RTCドライバーを完成させ、 RTC_SSRとミリ秒間隔をサポートします。 それ以来、私たちは文字通りすべてのステップでそれを使用してきました（そして、OSで作業しているため、サービスもその上でハングアップし、手首を振るだけで1つのハードウェアタイマーで任意の期間のほぼすべてのタスクをハングアップできます）。



同じアプローチがSTM32L0およびSTM32L4コントローラーに転送され、そのすべてのモデルにRTC_SSRレジスタがあります。 これにより、LPTIMタイマーが不要になり、異なるプラットフォームのコードが統一されます。

マルチメーターが嘘をついていることを理解する方法

もちろん、すべての最適化の後、正当な疑問が生じます。実際、私たちは何を達成しましたか？それに対する答えを知らなくても、正しく設定されたフラグを持つ1つのWFEに完全に制限し、スリープ状態に入り、200〜500μAを取得できます。



電流を測定する最も伝統的な方法は、もちろん、マルチメーターです。動的消費のあるマイクロコントローラーのように負荷の上にあることを理解するのは非常に簡単です-オンにすると、横になります。



ただし、これはマルチメーターがこの問題で役に立たないという意味ではありません。あなたはそれを適用できる必要があります。



まず、マルチメーターは非常に遅いものであり、1カウントの典型的な時間は2番目のスケールであり、マイクロコントローラーが状態を変更する典型的な時間はマイクロ秒のスケールです。そのペースで消費量を変更するシステムでは、マルチメーターは単にランダムな値を表示します。



ただし、私たちにとって興味深い非ランダム変数の1つは、スリープモードでのマイクロコントローラーの消費です。データシートで推定した値を大幅に超える場合、明らかに何かが間違っています。これは静的システムの消費量です。つまり、マルチメーターで測定できます。



タイトル写真に示されている最も簡単な方法は、マイクロアンメータモードのマルチメータです。これは現在、ほとんどのミッドレンジモデルにあり、精度と分解能が優れています。 UT120Cの分解能は0.1μAで、精度は±1％±3放電です。これで十分です。



このモードには問題が1つしかありません。マルチメータの直列抵抗が大きく、数百オームのスケールがあるため、通常モードでは、電源回路にこのようなマルチメータがあるマイクロコントローラは起動しません。幸いなことに、スケール上のほとんどすべての機器の「mA」と「uA」の位置は近く、両方の範囲で測定するソケットは同じです。したがって、コントローラーを「mA」の制限で安全に実行し、スリープ状態になったら「uA」をクリックします「-これは十分に速く行われるため、コントローラが電力を失って再起動する時間がありません。



コントローラのアクティビティが急上昇する場合、この方法は適用できないことに注意してください。たとえば、デバイスのファームウェアではウォッチドッグタイマーが15秒ごとにリセットされます。これらの瞬間に、マルチメーターは27μAの領域で何かを表示しますが、これはもちろん火星の天気とは関係ありません。 5-10秒に1回以上、システム上で勝手に短い何かが発生した場合、マルチメーターは単純に嘘をつきます。静的



を測定する別の方法（私はこの言葉を直接強調しています）マルチメーターによる消費は、外部シャントでの落下の測定値です。数十マイクロアンペアのスケールの超微小電流を測定する場合、大きなシャント（たとえば、1 kOhm）を並列に接続する必要があります-直接接続のショットキーダイオード。シャントが0.3 Vを超えると、ダイオードが開き、電圧降下が制限されます。最大0.3 Vの場合、1 mV = 1μAの範囲でマルチメータを使用して安全に降下を測定できます。



残念ながら、典型的なマルチメーターで低インピーダンスのシャントのドロップを測定することはできません。中級クラスのデバイスは、100μV未満の値を示しても、この範囲では残念です。 1μVを表示できる優れたデスクトップデバイスがあれば、私のアドバイスはもう必要ありません。



しかし、静力学は良いのですが、力学はどうですか？平均電力消費に対する異なる周波数の同じ効果を評価する方法は？



ここではすべてが複雑です。



基本的な要件を書き留めましょう。

• 少なくとも1μA-100 mA（10 ^ 5）の電流範囲
• 測定期間は10μs以下
• 100 mV以下の電圧降下
• 測定時間-無制限

単純に数値に変換すると、入力バイアスが30μV未満の比較的高速で18ビット以上のADC、1μVからの電圧を測定できるアナログフロントエンド、およびこれらすべてを転送できるコンピューターへのクイックインターフェイスが得られます保存します。



そして、これらはすべて1回の使用で済みます。



あなたは、はい、なぜそのようなものが10ドルの隅々に横たわっていないのですか？ Keysight N6705Cは最初の近似値で要件を満たしていますが、価格は7960ドルです。



たとえば、予算ソリューションから、SiLabsは現在の測定をそのデバッグに統合します-Advanced Energy Monitoring（AEM）システムの特性は特定のデバッグモデルに依存し、最大の問題は測定速度にあります。古い「スターターキット」では、STK3300 / 3400は100 Hzのみで、新しいデバッグではSTK3700 / 3800（黒いテキソライトで簡単に認識可能）-6.25 kHz、DKシリーズの古いモデルでは最大10 kHzに達しますが、コストもかかります彼らはすでに300ドル以上です。深刻なタスクについては、SiLabsは前述のKeysightを公式に推奨しています。



原則として、このようなデバイスは自分で設計することができます-まず、OPA2335のような最小限の入力バイアスで非常に優れたオペアンプが必要です。このようなオペアンプは、異なる増幅係数を持つ2〜3個の同じシャントに配置され、それらはすべて異なるADC入力に巻かれます（このアプローチでは、内蔵のマイクロコントローラを使用することは可能です）。瞬間は過負荷ではなく、それからの測定値がカウントされます。



コンピューターへのデータ転送速度の問題は非常に簡単に解決されます-実際の目的では、実際のシステムの平均消費に主に関心があるため、メーターのオンボードマイクロコントローラーでマイクロ秒の読み取り値を収集し、合理的なミリ秒スケールの算術平均を送信することができます



さらに、実践が示すように、メーターロガーは非常に便利ですが、シンプルであまり正確ではありませんが、常に手元にあります-省エネによって破壊された何らかのファームウェアの変更に驚かないようにするためです。



たとえば、標準のUSBアダプターUMDK-RFに組み込みました。これは、ファームウェアのデバッグ時に常に使用されます。既にDAPLinkプロトコル、USB-UARTブリッジ、および電源管理ロジックをそれぞれサポートするSWDプログラマーがあり、消費メーターがありますほとんど無料です。メーター自体は1オームシャントおよびINA213アンプ（ゲイン50倍、標準的なゼロオフセット5μV）：







アンプはマイクロコントローラーのADC（STM32F042F6P6）の入力に直接接続され、ADCはハードウェアタイマーを使用して10μsの周期で処理し、USB経由で起動します100ミリ秒間隔の平均データが出力されます。その結果、ファームウェアロジックで何かを変更すると、煙を出したりコーヒーを飲んだりして、デバイスをテーブルに置いたまま戻り、次のようなスケジュールを見ることができます。







もちろん、このような「無料」デバイスの精度は高くありません-12ビットADCと1つのアンプを使用すると、最小量子は16μAになりますが、エネルギー消費の観点からデバッグされたデバイスの動作を迅速かつ定期的に評価するのに非常に役立ちます。結局、ファームウェアまたはデバイスで何か間違ったことをした場合、非常に高い保証があれば、マイクロアンプのユニットから少なくとも数百を引き出すことができ、これははっきりと見えます。







別の素晴らしいボーナスは、データがテキスト形式（マイクロアンペア単位の値）で仮想COMポートに送信されるため、デバイスのコンソールを表示するウィンドウの隣に端末ウィンドウを配置し、デバッグメッセージと同時に電力消費を確認できることです。



これには理由があることを自慢し、この最小限の（そして非常に安価な）デバッガプログラマを自分のプロジェクトで使用したいすべての人に提供します。ここで



図を描くことができます（DipTraceのソース）、ここでファームウェアをドラッグアウトできます（ターゲットを構築するときのumdk-rfブランチ、dap42プロジェクトに基づくUMDK-RF ）。ダイアグラムは乱雑に描かれていますが、要点が明確であることを願っていますが、ファームウェアはlibopencm3を使用してCで記述され、通常のarm-none-eabi-gccでアセンブルされます。追加機能として、ファームウェアには電源管理機能があり、コントロールキーから過負荷信号をキャッチし、ボタンを長押ししてネイティブブートローダーに接続されたコントローラーを入力します。



NB：プログラマー自身のコントローラーを通常の方法でブートローダーに入れるためのブートボタンが必要な場合、接続の極性を変更し、最初のブート時のコントローラーのオプションバイト編集とブートローダーへのプログラム入力を削除し、通常の割り込み極性を持たせる必要がありますこのボタンの機能。



ゲイン係数が異なるオペアンプのペアで電流がどのように測定されるかを見ることができます（たとえば、タスクの上記のデバッガーを改善するため）、ここ（p。9）、1つのオペアンプと高価な24ビットADC - TIの持っている（5ページのEnergyTraceを）。



PS接続されたUARTまたはJTAG / SWDを使用したデバッグ中に、足から小さな電流が漏れる場合がありますが、これはデバイスの実際の動作中には存在しません。したがって、SWDにUMDK-RFは、15マイクロアンペア（およびSWDことなく、基板の古いバージョンで行わしたがって資本マルチ測定画像）について漏洩し、STM32ヌクレオにSWDによって寄生消費のケースがあった200マイクロアンペアに関する。測定に使用されるデバッグボードは、そのような機能があるかどうかを確認する必要があります-そのような可能性がある場合は、インターフェイスラインを切断するか、デバッグ用にインストールせずに測定したデバイスの消費量と結果を比較します（たとえば、静的モードのマルチメーター）

結論の代わりに

マイクロコントローラのプログラミングをあなたの主な専門分野として選択することによって、あなたが犯した間違いをすでに理解していることを願っています。