低電力のエッジデバイス用に統合されたwifi MCUを選択する際に考慮すべき要素は何ですか？

この質問の動機は、しばらく前に、マイクロコントローラーとCC3100 Wifiネットワークプロセッサーを使用して、簡単な概念実証（PoC）IoTエッジデバイスを作成したという事実にあります。このプロトタイプの問題の1つは、構成にかなりの電力が必要なことでした。したがって、バッテリーと使用頻度の選択に応じて、2〜10年以上続く既存の低電力デバイスの利点を克服できませんでした。

用途に応じて、現在の製品は、容量が1400 mAh〜2400 mAhの6V DCバッテリーを使用しています。このデバイスには、低電力検出要素と作動メカニズムがあります。ほとんどの場合、ペイロードは約100バイトになります。通信の頻度は、ピークアクティビティ中は約2分ごとです。IoTの進歩と市場の需要により、このPoCは注目を集めています。

いくつかのIOTプラットフォームプロバイダーの提案に従って、主にCC3100の後継であるため、Texas InstrumentのCC3200ワイヤレスMCUを検討しています。使用していないときのシステムレベルでは、CC3100の電源を完全にオフにすることができます。これは、システムレベルでの低電力にとって大きな利点です。アクティビティが検出されると、検知要素が割り込みを介してマイクロコントローラを起動します。ESP8266、BCM43362、ATWINC1500B、88MC200など、他の統合されたwifi MCUがあります。ULPBenchスコアを使用して、低電力マイクロコントローラーの1次分析を行い、次に以下のような分析を行います。低電力アプリケーション用のマイクロコントローラーの選択方法は？ 低電力マイクロコントローラーの選択を支援します。周波数ごとのアクティブモードの電流引き込みなどのパラメーターを使用し、情報に基づいた選択を行うために、さまざまな低電力モードの電流引き込みを使用しました。したがって、低電力オプションを維持し、IoT機能を追加するために、統合されたwifi MCUを選択する際に細心の注意を払う必要がある重要なパラメーター（ワイヤレス通信に関連する可能性がある）は何ですか？

参照：

• SimpleLink™CC3100 / CC3200 Wi-Fiインターネットオンチップネットワーキングサブシステムの電源管理
• Wi-Fiモジュールの選択方法は？

最も重要な制約は低消費電力であるため、2つの最も重要なパラメーターに既に注意を払っていると思います。周波数ごとのアクティブモードの電流引き込みと、さまざまな低電力モードでの電流引き込みです。

通信を定数（つまり、同じ通信プロトコルとEM周波数）として保持し、最適なMCUを選択するのは、これら2つのパラメーターを適切に集約するだけです。そして、すべてのオプションで比較できる単一の数値を作成する方法は次のとおりです。

1. ある期間、たとえば1週間にわたって、デバイスの予測アクティビティプロファイル（通信の頻度と期間）を作成します。
2. 通信がアクティブな場合、選択された期間の時間に使用されるEM周波数での電流引き込みを計算します。つまり、1週間に1000 xのアクティビティで2秒間10 uA引き込み（@ 900 MHz周波数）は20,000 uA-s /を意味します週間。
3. デバイスがデフォルトの低電力モードにある場合、選択した期間の時間の消費電流を計算します。つまり、[7日x 24時間x 60分x 60秒-1000 x 2秒のアクティビティ]で10 nAの消費は6,028 uAを意味します-s /週。
4. この仮想MCUの2つの電流を追加すると、26,028 uA-s /週の電流が得られます。
5. この計算された毎週の電流は、すべてのMCUで比較できます。

これはMCUアクティビティを表示する非常に単純な方法であることがわかります。つまり、アイドル状態と通信状態の2つの状態と見なされますが、他の状態はこれら2つのいずれかに比例してわずかに寄与します。計算（命令サイクル）は、通信状態とともにバンドルすることができ、通信サブシステムと比較して、電力に関して非常にわずかな寄与しかありません。ポイントは、これら2つの状態を確認するだけで、選択プロセスに十分であるということです。

魔法の弾丸はないので、アドバイスは痛々しいほど明白になると思います。最初に最大の電力消費者からチップを始めます。

アイドル状態のときに、すべてのチップと回路の電源を本当にオフにしますか？趣味のボードとシールドのいくつかは、あなたが期待するすべてを常に完全にオフにするわけではないことを知っています。

アクチュエーターの場合、より軽量のモーターを使用できますか、またはドライブトレインの摩擦を軽減できますか？全体像として、駆動負荷をリエンジニアリングして質量を減らしたり、バランスを改善したりできますか？

通信の場合は、通信の頻度を確認することから始めます。既存の「2分間」の決定を下した要因は何ですか？コミュニケーションを犠牲にして犠牲を払うことはできますか？pub-subモデルに切り替えて、条件が許す場合により少ないバイトで応答できますか？

プロトコルを再評価します。シェービングするバイトごとに、現在のRF電力バジェットの1％を節約できます。ブール値を送信しますか？ASCIIの「Y」または「N」ではなく、ビットフラグを使用します。可能な限り最小のコンテナを使用していることを確認してください。数値の許容範囲が0〜99の場合、16ビット整数を送信しないでください。ほとんどのバッテリー駆動プロトコルは、可能な限りそれを絞ろうとします。たとえば、要素の5x5配列についてレポートする場合、アドレスは8ビットバイトではなく、5ビットフィールドのみで十分です。圧縮関連のロジックにCPUサイクルを使用すると、不要なビットを送信するよりも全体の消費電力がはるかに少なくなります。

大きな消費電力がCPUである場合（疑わしいが、可能）、事前計算されたルックアップテーブルのようなトリックを実行できますか、または一部の作業をリモートサービスにオフロードできますか？

このような統合デバイスを選択するために使用できる単一の決定的なパラメーターセットはありませんが、最初の近似として、新しく設計されたデバイスは数年前のものよりも大幅に優れていると思います。コンセプトは新しいものではありませんが、このレベルの統合と積極的な電力目標により、これは進化する市場です。

システム全体の観点から見た、提供される電力状態（レギュレータ、発振器、センサー信号調整）に細心の注意を払ってください。2分間のアクティブ状態が、通常の動作状態よりも浅い睡眠の恩恵を受ける可能性は（ほとんどありませんが）あります。

消費電力の大部分は、最低電力有効状態で占められている必要があります。これが正確にどのように機能するかは、レギュレーター、最小動作電圧などを使用せずに電源から直接動作できるかどうかなどによって異なります。

アクティブ状態については、ほとんどのRAMまたは計算集中型の操作を検討し、（CPU、速度、およびメモリアーキテクチャに基づいて）見つけることができる最も近い同等の既製の部品を使用してベンチマークします。アプリケーションでは、ペイロードと暗号化の準備はかなり簡単なように見えますが、一般的にこれは明らかな仮定ではありません。保持状態により、たとえば状態の保存/復元なしでセンサーを統合できる場合があります。

クロック速度とアーキテクチャをアプリケーションの要求に合わせます。スリープ状態では、漏れ電力を節約できます。デバイスのターゲットクロック速度が低いと、アクティブ状態を長く維持する必要があることを意味する場合がありますが、設計により漏れ性能が向上します（動作電圧が低くなる場合もあります）。

複数の設計を反復するまで絶対的な最良の設計を知ることはできません-パラメーターが多すぎるため（この時点で製品は古くなり始めます）、設計フローのより高いレベルの側面はまだです重要。ウェイクイベントを5％削減するようにアーキテクチャを最適化できる場合、これはバッテリー寿命で顕著になります。