嵌入式低功耗开发嵌入式低功耗开发
不知从什么时候开始,随便做个什么电子产品,至少是电池供电的,都要求低功耗特性了。好在市面上随便什
么芯片都敢在自己的数据手册的页赫然写着低功耗。究竟怎样算低功耗?小于5mA?小于1ms?小于100uA?离
开了应用场合,似乎数值也失去了单纯的意义,总之越小越好。但感觉上,能用水果点亮的应用应该就是低功
耗了吧。 认真说来,有点怀念当年随便一个应用500mA,芯片微微发烫,用手一摸只要还能放得住就大手
一挥“没问题”的时代了。近总是和uA打交道,超过100uA,周围的人脸色就不好看了,好容易达到了传说中的
20uA以内,也会觉得沾沾自喜,哎……uA啊……情何以堪啊,伤不起啊……
不知从什么时候开始,随便做个什么电子产品,至少是电池供电的,都要求低功耗特性了。好在市面上随便什么芯片都敢
在自己的数据手册的页赫然写着低功耗。究竟怎样算低功耗?小于5mA?小于1ms?小于100uA?离开了应用场合,似乎数值
也失去了单纯的意义,总之越小越好。但感觉上,能用水果点亮的应用应该就是低功耗了吧。
认真说来,有点怀念当年随便一个应用500mA,芯片微微发烫,用手一摸只要还能放得住就大手一挥“没问题”的时代了。
近总是和uA打交道,超过100uA,周围的人脸色就不好看了,好容易达到了传说中的20uA以内,也会觉得沾沾自喜,哎……
uA啊……情何以堪啊,伤不起啊……
久病成医,渐渐的也就有了一些心得,似乎低功耗开发的过程也可以一板一眼,按部就班,似乎不单纯是一些零散的“看
情况而定”“只可意会”的东西了。于是忍不住,将这些似是而非的步骤记录下来,以箪初来者。
事半功倍还是事倍功半 事半功倍还是事倍功半——思路决定成败思路决定成败
“肚子饿的时候,睡着了也就不觉得饿了……于是乎,难得的双休日宅在家中补觉,往往也就一天只吃一餐饭了”——技术
宅人_大体如此。
应该没有人能在梦游的时候干活吧?所以,平常工作的时候,饭还是要吃的。休眠和干活应该是一对矛盾体。于是乎,芯
片数据手册上那些“小的出奇”的休眠功耗,似乎大部分时候只是用来摆设的;而工作功耗才是实实在在的东西。有时候,为了
体现所谓的低功耗,还要在应用中设计一种所谓的低功耗模式——当系统确认没有事情可做一段时间以后就干脆回家睡觉了
——这大体就是现在市面上常见的低功耗应用的某种程度上的现状吧。于是乎,降低工作频率这种“马儿跑,马儿不吃草”的逻
辑,就成为降低正常工作模式下系统功耗的常规选择。苦啊……多少人在工作频率和功耗间纠结……又有多少功能实现的本身
对对频率拥有要求……苦啊——我说的是写代码的程序员。
说起来,降低功耗似乎是一个软件和硬件协同工作才能解决的问题。比如AD采样时候的分压电阻,如果直接接了地,那
么就会一直消耗电流,如果通过一个IO口来控制其接地的方式,只在需要采样的时候接地,采样完成以后就悬浮或者拉高,
就可以将这部分开销降低的。
显然,将低功耗完全化作硬件设计的工作或者软件设计的工作都是不合适的。
从硬件角度来说,找到所有可能的消耗电流的回路,一一确定哪些是可以通过软件控制的方式来优化功耗的,哪些是不可
避免的,并给程序的编写人员提供一个所有IO口状态对功耗影响的关系(通常用简单的表格说明一下高电平会怎样,低电平
会怎样,悬浮会怎样就足够了,并不需要精细到具体的数值。)做到这一点,基本上硬件的工作就告完成,剩下的就是软件开
发人员的发挥空间。而基于软件的功耗降低策略,正是本文所要讨论的重点。
说到软件功耗优化,说简单也简单,说复杂也复杂。简单总结过来就是:应用模块化、功能任务化、任务周期化、功耗自
理化、休眠一票否决化。还不够简单?再浓缩就是:能休眠就休眠,怎么休眠投票选。呵呵……估计简单过头了,失去了信息
量,下面将这几个方面一一展开: