嵌入式低功耗开发.docxVIP

【Word版本下载可任意编辑】 PAGE 1 - / NUMPAGES 1 嵌入式低功耗开发 不知从什么时候开始，随便做个什么电子产品，至少是电池供电的，都要求低功耗特性了。好在市面上随便什么芯片都敢在自己的数据手册的页赫然写着低功耗。终究怎样算低功耗？小于5mA？小于1ms？小于100uA？离开了应用场合，似乎数值也失去了单纯的意义，总之越小越好。但感觉上，能用水果点亮的应用应该就是低功耗了吧。  认真说来，有点怀念当年随便一个应用500mA，芯片微微发烫，用手一摸只要还能放得住就大手一挥“没问题”的时代了。近总是和uA打交道，超过100uA，周围的人脸色就不好看了，好容易到达了传说中的20uA以内，也会觉得沾沾自喜，哎……uA啊……情何以堪啊，伤不起啊……  久病成医，渐渐的也就有了一些心得，似乎低功耗开发的过程也可以一板一眼，按部就班，似乎不单纯是一些零散的“看情况而定”“只可意会”的东西了。于是忍不住，将这些似是而非的步骤记录下来，以箪初来者。  事半功倍还是事倍功半——思路决定成败  “肚子饿的时候，睡着了也就不觉得饿了……于是乎，难得的双休日宅在家中补觉，往往也就一天只吃一餐饭了”——技术宅人_大体如此。  应该没有人能在梦游的时候干活吧？所以，平常工作的时候，饭还是要吃的。休眠和干活应该是一对矛盾体。于是乎，芯片数据手册上那些“小的出奇”的休眠功耗，似乎大部分时候只是用来摆设的；而工作功耗才是实实在在的东西。有时候，为了表达所谓的低功耗，还要在应用中设计一种所谓的低功耗模式——当系统确认没有事情可做一段时间以后就干脆回家睡觉了——这大体就是现在市面上常见的低功耗应用的某种程度上的现状吧。于是乎，降低工作频率这种“马儿跑，马儿不吃草”的逻辑，就成为降低正常工作模式下系统功耗的常规选择。苦啊……多少人在工作频率和功耗间纠结……又有多少功能实现的本身对对频率拥有要求……苦啊——我说的是写代码的程序员。  说起来，降低功耗似乎是一个软件和硬件协同工作才能解决的问题。比方AD采样时候的分压电阻，如果直接接了地，那么就会一直消耗电流，如果通过一个IO口来控制其接地的方式，只在需要采样的时候接地，采样完成以后就悬浮或者拉高，就可以将这部分开销降低的。  显然，将低功耗完全化作硬件设计的工作或者软件设计的工作都是不合适的。  从硬件角度来说，找到所有可能的消耗电流的回路，一一确定哪些是可以通过软件控制的方式来优化功耗的，哪些是不可防止的，并给程序的编写人员提供一个所有IO口状态对功耗影响的关系（通常用简单的表格说明一下高电平会怎样，低电平会怎样，悬浮会怎样就足够了，并不需要精细到具体的数值。）做到这一点，基本上硬件的工作就告完成，剩下的就是软件开发人员的发挥空间。而基于软件的功耗降低策略，正是本文所要讨论的重点。  说到软件功耗优化，说简单也简单，说复杂也复杂。简单总结过来就是：应用模块化、功能任务化、任务周期化、功耗自理化、休眠一票否决化。还不够简单？再浓缩就是：能休眠就休眠，怎么休眠投票选。呵呵……估计简单过头了，失去了信息量，下面将这几个方面一一展开：  1、应用模块化、功能任务化、任务周期化  一个具体的应用，通常由很多子功能，子任务组成。对嵌入式系统软件构架有所了解的人更能理解：一个应用是由对若干服务（servie）的调用实现的。这里服务可以是硬件服务，比方AD采样，比方串口通讯，比方外中断触发，比方定时器服务；也可以是软件服务，比方各种通讯协议栈，FAT文件系统，队列，软件滤波等等。一个服务通常实现一个或多个功能（好的任务划分不会让一个服务包含多于2种以上不相关的功能）。简单的功能，比方CRC校验这样函数进去函数出来基本上可以立即获得结果的，我就不说了；复杂的功能都使用任务的方式来实现。说到任务，就要牵涉到操作系统、调度器或者干脆是简单的状态机了。总之，可以将任务的实现理解为一个流程。既然是流程，那么任务所要做的工作就是周期性的。举例来说，AD采样任务由至少3个步骤组成：通道选择和启动采样，采样以及等待采样完成，数据的处理。这样三个步骤共同组成了一个任务周期，当三个步骤完成以后，我们可以认为一个周期结束了。再举一个例子，I2C通讯，一个完整的数据包的发送通常包含了若干的状态，这一系列状态构成了一个任务，当一个状态（或者某些异常退出状态）结束后，一个任务周期就结束了。  总结来说，应用模块化，功能任务化，任务周期化的终目的就是任务周期化。只有实现了周期化，一件事情才有始有终。有始有终，就可以根据需要发放“工资”，防止浪费。而做到任务周期化的常见方法就是通过模块化的服务将功能独立出来从而便于管理，便