由于您最重要的限制是低功耗，我认为您已经在关注 2 个最重要的参数：每个频率的有源模式电流消耗，以及不同低功耗模式下的电流消耗。

将通信保持为一个常数（即相同的通信协议和 EM 频率），然后选择最佳 MCU 只是适当地聚合这两个参数的问题。下面是我将如何创建一个可以在所有选项中进行比较的单个数值：

1. 为设备创建一个计划的活动配置文件（它通信的频率和时间）在一段时间内 - 比如说一个多星期。
2. 计算通信处于活动状态时所选时间段内使用的 EM 频率的电流消耗 - 即 10 uA 消耗（@ 900 MHz 频率）持续 2 秒，每周 1000 x 活动意味着 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 个状态就足够了。

没有灵丹妙药，所以我认为建议会非常明显。首先开始削减最大的电力消费者。

您真的在空闲时关闭所有芯片和电路的电源吗？我知道一些业余爱好者的电路板和防护罩并不总是完全关闭您所期望的一切。

如果是执行器，您是否可以使用更轻的动力电机，或减少传动系统中的摩擦？更大的图景，您能否重新设计驱动负载以减少质量或更好地平衡？

如果是通信，请先查看通信频率。是什么因素推动了现有的“两分钟”决定？你能做出牺牲来减少交流吗？是否可以切换到发布-订阅模式，并在条件允许的情况下以更少的字节响应？

重新评估协议。您减少的每个字节都代表您当前射频功率预算的 1% 的节省。发送任何布尔值？使用位标志，而不是 ASCII 'Y' 或 'N'。确保使用尽可能小的容器 - 如果数字的允许范围仅为 0-99，则不要传输 16 位整数。大多数电池供电协议试图尽可能地将其压缩；例如，如果您报告的是 5x5 元素数组，则地址只需是 5 位字段，而不是 8 位字节。与传输不需要的位相比，将 CPU 周期用于与压缩相关的逻辑会导致总体功耗低得多。

如果大功率消耗是 CPU（值得怀疑，但可能），您是否可以做一些技巧，例如预先计算的查找表，甚至将一些工作卸载到远程服务？

没有单一的明确参数集可以用来选择这样的集成设备，但我认为作为第一个近似值，新设计的设备可能比几年前的设备要好得多。虽然这个概念并不新鲜，但这种集成度和激进的功率目标使其成为一个不断发展的市场。

从整个系统（稳压器、振荡器、传感器信号调节）的角度来看，请密切注意所提供的电源状态。您的 2 分钟活跃状态有可能（不太可能）受益于比正常操作状态更少的深度睡眠。

最低功耗有用状态应占您能源消耗的大部分。这对您来说究竟如何，取决于您是否可以在没有稳压器的情况下直接关闭电源、最低工作电压等。

对于活动状态，请考虑您的 RAM 或计算密集型操作，并使用您能找到的最接近的等效现成部件（基于 CPU、速度和内存架构）对它们进行基准测试。在您的应用程序中，准备负载和加密似乎相当简单，但通常这不是一个明显的假设。例如，保留状态可能允许传感器集成而无需状态保存/恢复。

将时钟速度和架构与您的应用程序的需求相匹配。在睡眠状态下，您可以节省漏电。设备的较低目标时钟速度可能意味着它需要更长时间地保持活动状态，但也会导致设计实现更好的泄漏性能（以及可能降低工作电压）。

在迭代不止一个设计之前，您不会知道绝对最好的设计——参数太多（此时，您的产品将开始变老），因此设计流程的更高级别方面仍然存在重要的。如果您可以优化您的架构以将唤醒事件减少 5%，这在电池寿命方面应该是显而易见的。

尽管这个问题已经很老了，但它仍然缺少一件非常重要的事情：

如果在特定国家使用是合法的。

由于欧盟法规比 FCC 更宽松，大多数 MCU 在法律上不允许在美国/加拿大和类似国家/地区使用，而其设计未经 FCC 认证。

天线增益、滤波器衰减、最大可能传输功率等设计选择都会影响设计是否满足允许的信道使用、最大允许传输功率、信道外和带外杂散传输等要求.

例如，ESP32 默认配置为以最大可能的传输功率传输，远远高于 FCC 和 ETSI (EU) 允许的传输功率。

因此，在大多数情况下，最好避免查看特定的 MCU，而是考虑使用带有制造商认可天线的预认证模块。