RT-Thread功耗调优项目实战-如何做好功耗

原创 RTThread物联网操作系统 2022-03-09 19:16

TI MCU方案：电动汽车实时控制 【免注册下载】创新MCU提升高压系统的实时性能

引言

浅谈最近一个基于RT-Thread的穿戴项目的功耗调优流程，引入如何做功耗的话题
谈到功耗，如果使用RT-Thread，就会提到RT-Thread的PM框架，当然只有PM框架，是无法真正解决功耗问题的，尤其是一个复杂的低功耗产品
万事开头难，做什么事情，都有第一次，有了第一次，就有了经验与收获，再次遇到相关的问题，会迎刃而解或举一反三

入项

这是一个不算复杂的项目，我主要参与的是功耗优化相关的工作，入项时项目立项大概有两个月了，项目硬件已经初步定型，并且软件部分都有了基本功能，接下来就被拉入项目，功耗要干起来了，客户在催进度了。
刚入项目时，对项目一头迷雾，如需要了解如下的一些相关的信息：

我刚入项，还对一切不太了解，虽说项目比之前做的项目简单N倍，但是对项目需要有一个熟悉的过程
上面提到的问题，都需要一个个确认清楚，包括功耗目标，不是说待机功耗调到最优就解决战斗
之前接触的一些项目因为硬件设计无法满足低功耗要求，需要硬件改版，这个周期还是挺长的。
项目做的是什么：穿戴产品
项目目前的进展是什么：功能调的差不多了，甚至开关机都有了，功耗还【没有开展】
用的什么平台（MCU）：国产的，资料没提供多少
用了哪些功能外设（LCD、TP、传感器）：都用了，大部分都是些低成本的
功耗或续航的目标是什么：不太明确，一周？十天？边做边确认？没谈好！【注意：埋下伏笔】
用的电池容量多大：150mAH？200mAH？不太明确。其实结构定了，就已经差不多明确了，穿戴产品电池大不了，受限空间与体积限制，容量越大，电池体积就越大，穿戴产品不可能做的很大很笨重。
开发周期：这个一上来就问我，我比较迷惑，有点保守，不过还是硬把1个月，改成2个月，理由就是：

正式入项

解决仪器短缺问题：

电源分析仪：高档的：【KEYSIGHT N6705C 直流电源分析仪】，之前项目用，感觉很强大，功耗调试方便与精确，不需要电脑配合，就可以轻松的获取功耗情况，超低精度显示，精度1uA级别，当然价格也高的离谱。
中档的，power monitor，配合电脑，应该也可以在功耗调优上【大干一番】，精度在10uA级别吧。
最终敲定，采用国产的电源分析仪：uA级别的精度。

再配合一个精度较好的【万用表】，电源【供电】与【分析】、【测量】的问题得到解决
要到一块这个MCU的开发板，我不满足，后来要来一块PCBA小板，还不满足，我提出了要做一个【功耗大板】的建议，理由如下：

MCU开发板，功能不全，没有低功耗设计，只能用于验证初步的电源模式，无法分析与优化项目本身的功耗
小板PCBA只有电池的引脚焊盘与程序下载的焊盘，这不方便调试功耗，无法很快的【拆解功耗】，更无法细致的调优功耗。
PCBA短缺，飞线飞的像个【八爪鱼】，不方便程序的调试，一不小心扯掉【焊盘】，板子就报废一半了
电路板外部连着调试器、电源或电池、串口线等，不像小学生的【橡皮尺子】可以方便的相互借来借去使用。
功耗拆解在前期，可能会拆解部分器件，如断开某路电源，为了验证某个模块是否正常，设置需要【割线】调试。
部分外设有多组电源供电，需要确认各个电源支路的电流，才能评估哪里有漏电或可以进一步优化，小板下不了手。

如上，通过设计功耗大板，解决板子功耗调试问题

前期沟通

MCU 是国产的，是否像STM32那样，MCU本身有完善的电源模式，如运行、IDLE、STOP等模式？

答案是否定的。这颗国产MCU功耗并没有做的极致，关机电流都可能大于STM32F系列的STOP模式电流，最致命的就是这个MCU的LIGHT轻度睡眠模式，普通中断都无法唤醒，需要唤醒引脚，且唤醒引脚很少。

电池容量问题：是否可以改大？

答案是，尽可能改大，如200mAH 改为 300mAH。但最终还是定为200mAH左右，原因应该是结构已经定型。【这就是功耗入项晚】或【项目前期不考虑功耗】的问题症结吧。【木已成舟】，无法更换

初步扫了一眼原理图，发现电池电压转换到1.8V，使用的是LDO，而不是电源转换效率较高的DCDC。是否可以改为DCDC？

这个问题提出多次，最终改为了DCDC，因为低成本考虑，更换的DCDC电源芯片转换效率比LDO略高一点，但【静态电流】很高，达到了50uA以上。当你吭哧吭哧在其他方面调低了10uA后沾沾自喜时，这个漏电让你【气的牙痒痒】

电源转换漏电：1.8V 到 3.3V 有通信，为了降低成本，采用分立器件而不是电平转换IC来实现，造成漏电大于500uA。

后期解决的思路是更换为电平转换芯片，软件需要控制这个电平转换芯片的开关逻辑，保证不工作时不漏电。

软件部分

开始软件部分的优化吧，搭建PM管理框架，功耗管理复杂的话，可能需要对PM框架优化一波，保证管理的高效性，如低功耗定时器的管理。

如果普通定时器在深睡眠时可以唤醒，就会造成一旦系统有一个定时器周期比较的短，那么系统频繁的进出低功耗，造成整体功耗很高，电源模式的功耗开销也很大。所以需要【定时器】管理，需要做的只有部分定时器可以在【深睡眠】时可以唤醒，其他的定时器【深睡眠】时冻结。带来的问题：深睡眠唤醒后，时钟补偿后，会导致软定时器链表上的大部分定时器，【一窝蜂】的超时并队列执行操作...

PM框架提供好几个电源模式，IDLE、LIGHT、DEEP、Standby、Shutdown，真正评估下来，就IDLE与StandBy吧。

这里StandBy模式与这款MCU挂钩，实现了睡眠前寄存器、RAM等数据的保存，然后关机，唤醒重启恢复寄存器与RAM数据，然后跳转到之前的运行位置。这算是一项【新技能】，也做到了待机的超低功耗，当然唤醒需要使用唤醒引脚，进出【睡眠模式】都需要一顿【骚操作】，比较耗时。

排查了各个引脚，解决了漏电，解决了关机下唤醒后漏电的问题，完事了？

定期器唤醒功耗太高了，需要优化。
传感器频繁采集数据，需要优化
部分业务需要不断的唤醒，需要优化
电池电量没有使用库仑计，如何保证放电
电池采样的低成本充电IC，如何保证电池充满电？

这时才是真正需要配合团队一起解决【功耗问题】的时候，过程有点漫长与曲折。

续航目标

上面说了，我入项时没问清楚功耗调到什么程度才能【交卷】，这个不问清楚，导致后期卡【项目量产】，虽然经过大家协助又优化了一波，保证产品量产，但是，不得不说，这个【目标问题】，最好还是提前确认清楚，理由如下：

功耗与硬件与软件业务相关，如果定的续航目标极高，需要硬件超低功耗设计，保证【待机】与【运行】功耗都可以将至最低。
MCU平台的功耗模式如果不合理，如各个电源模式功耗本身很高，如MCU深睡眠时的功耗大于整机功耗的目标，那么【必开】的外设开启后，业务的部分定时唤醒开启后，功耗怎么可能达标，此时需要考虑更换【成本】合理的低功耗MCU。
部分器件的漏电，如DCDC静态电流漏电，TI的可以做到1uA一下，但部分低成本的，可能50uA左右，这也影响待机电流与续航
MCU中断唤醒不合理，如运行时无法进入LIGHT模式，造成运行的功耗下不来，做不到【间歇性】工作，就无法进一步控制与降低【运行功耗】

做功耗流程

1、入项需要尽早，硬件设计时（前），产品功耗的目标需要明确，防止后期的【高代价】改版，只扣功耗损失性能或用户体验，不是好的解决问题的方法，超低功耗首先保证【硬件超低功耗设计】，功耗入项前，就要对系统的MCU选型、功耗目标、时钟配置与优化、硬件电源路径的管理等了解，并配合硬件做好【硬件功耗设计】，包括前期设计【功耗大板】

2、平台PM框架的开启：开启PM，有【钱力】的可以自行设计一套自己专属PM管理框架，当然建议使用RT-Thread的PM框架，这套框架在不断的完善与易用，是个便捷的选择。

3、平台PM适配：需要适配MCU各个电源模式，一般为 IDLE、LIGHT、DEEP，当然了解了MCU本身的电源模式，不等于解决了功耗问题，需要进一步的熟悉整个硬件，各个外设的耗电情况，需要知道要调什么，哪些功耗较大，哪些功耗可以调优。

4、了解硬件原理：功耗管理的本质就是管理硬件的开关逻辑，熟悉整个电源、各个分支电源控制、各个外设的控制与工作流程，设计低功耗运行逻辑与策略，如果硬件设计不合理，需要提出【优化】或【改版】的方案来，还要【尽快提出】，不要等到项目接近量产时，前期的修改代价会相对低一点。

5、功耗拆解（功耗大板）：使用假电池，通过拆解MCU 在待机、运行、各个电源模式的功耗、通过拆解各个外设与之路电源的功耗，了解整机功耗构成、优化方向，清楚了各个外设、MCU的功耗，遇到问题，思路明确，下手快狠准。

6、业务流程梳理：哪些线程一直工作、哪些定时器可以在待机时关闭、哪些业务功耗很高，保证业务正常工作的情况下，降低功耗，超低功耗不能影响业务，但是还是要熟悉业务，让部分业务也【低功耗】运行。

7、功耗日志：周期性记录电池电量的数值，用于统计功耗的变化、下一步的功耗调优方向，当然也需要配合系统的LOG进行分析，如大电流重启的次数、亮灭屏的次数、唤醒的业务的工作时长，可以优化部分不需要的业务唤醒。

8、续航优化：根据实际整机的续航时间，统计下一步功耗的调优方向