开门见山
对于低功耗管理,之前写了几篇文章,但是很多人看不到,或者看了也理解不了,这一点深有体会,因为很多项目,苦口婆心的讲解,反而营造了一种【王婆卖瓜】的感觉
功耗管理确实牵涉到很多专业与非专业的知识点,部分知识点只有在实际的操作中才能深入体会。
心路历程
最早搞功耗,之前主要在 OFO的小黄车上搞过,使用的非RT-Thread,也没有使用PM框架,但是大同小异,自己当时是【驱动工程师】,有硬件基础,所以搞完驱动,搞功耗,并没有太大的困难,因为硬件对自己是【白盒】,自己清楚哪些耗电,哪些不怎么耗电,结合【续航标准】,可以指定一些电源管理的策略
智能门锁、便携定位器、穿戴类产品如手表、手环,都是锂电池供电,对低功耗的重视程度会更高
常见问题
别人问我怎么做功耗?
我首先说,【功耗拆解】,威廉希尔官方网站
面不同的人员,如管理者与工程师,软件工程师与硬件工程师,对【功耗拆解】四个字的理解也是千差万别。
EMMC漏不漏电?
功耗拆解,漏不漏电,通过功耗拆解得到EMMC开启与关闭的功耗数据,就可以算出EMMC的功耗,器件本身的功耗,引脚是否漏电
SPI 是否漏电?
同上:功耗拆解
UART、I2C、PSRAM是否漏电?
同上:功耗拆解
功耗拆解
各个模块,片内、片外的,MCU本身的各个电源模式的,对功耗【白盒】,对【硬件】了如执掌,才能清楚下一步怎么降低功耗,打个比方,I2C引脚是开漏输出,虽然外部上拉10K、4.7K电阻,其实I2C总线待机时极低,如只有1uA左右,大部分场合下可能就不需要处理
有个功耗的数据,才能【对症下药】,功耗拆解,类似于看病的【拍个片,抽个血,做个B超】,获取【病情】
RT-Thread PM框架怎么用?
RT-Thread PM框架 建议使用最新版本,使用最新的管理方法,【被动睡眠】,PM管理模块化,也就是MCU是等大家都空闲了再去睡眠,而不是MCU要睡眠,通知大家去做好睡眠前的操作
【被动睡眠】这个思想或者管理策略,会对功耗管理造成【极大】的影响,【被动睡眠】让功耗管理模块化,简单化。
PM框架的作用是什么?
PM框架管理各个模块的开关逻辑,管理MCU的睡眠与唤醒,管理着操作系统(RT-Thread)的运行与否,用于管理功耗,空闲时进入深睡眠降低功耗,运行时唤醒工作
PM框架可以认为是【领导层】,下发指派工作,实际的开关实现,需要用户适配,如屏幕管理、定时或中断业务的执行,加入功耗管理后,大部分操作都改为:【打开】【工作】【关闭】的模式,也就是RT-Thread 操作系统本身,也处于【工作】【停止】的不断切换的过程
PM框架的使用心得
电源模块 ID 的划分
MCU电源模式划分【睡眠(深睡眠)DEEPSLEEP】:进入与退出
功耗拆解完,就有了功耗管理的思路了,哪些地方存在漏电(器件标称功耗之外),哪些睡眠时漏电(关闭了,但是引脚还漏电?)
【请求不睡眠】,如果没有任何请求,【默认会进入深睡眠】,这里是默认DEEPSLEEP模式,而不是StandBy模式
若果想进入StandBy模式而不是DEEPSLEEP模式,需要手动【请求StandBy模式】,释放掉【Standby】模式之前的请求的模式后,才会进入
PM电源模式请求的方向是:【向高功耗方向请求】,也就是有优先级的,一个请求【IDLE】,一个请求【LIGHT】,会执行【IDLE】
电源模式请求StandBy模式问题
有人反映:请求了DEEPSLEEP、Standby,进入了DEEPSLEEP,而不是Standby,这是为什么?
PM电源模式请求的方向是:【向高功耗方向请求】,DEEPSLEEP 优先级 高于 StandBy模式,想进入 StandBy模式,它之前的模式需要全部 release 掉
要不要做功耗板?
产品研发,为了加快速度,有些产品想绕过复杂的【功耗拆解】,设计的电路板,只留了程序烧写与调试接口,让工程师去调功耗,结果工程师不知道怎么下手调功耗
设计功耗板,大板子,只是方便功耗拆解,方便功能验证,尤其是嵌入式的产品,功耗板更利于加快功能的调试验证
功耗管理,管理的是硬件器件的功耗,非操作系统的功耗,所以如果对设计的产品硬件【胸有成竹】,可以不设计功耗板,直接软件开开关关就可以了,如果硬件设计较为复杂,并且对功耗的要求指标又很高,建议设计功耗板,利于功耗拆解分析,更利于功能的调试
小结
仅对功耗管理的一点浅薄的认识、经验分享,欢迎拍砖,共同成长
相信只要用心,每个搞功耗的人,都会掌握一套属于自己的功耗管理方法
万事开头难,我开始调功耗时,不是上来功耗拆解、不是上来PM框架,我在啃MCU的手册,我甚至不了解线程如何【suspend】,也就是对RT-Thread 都不熟悉,当时想着开关【线程】。。。
原作者:张世争