嵌入式业务软件设计介绍

　　业务软件设计

　　低功耗从硬件上能够解决一部分，但单纯依靠硬件肯定是不行的，需要软件的密切配合，才能达到最好的效果。以上是从硬件驱动层面的，一般情况下都比较关注，但实际上软件业务层的灵活性高，发掘低功耗的效果比硬件低功耗本身的效果更加显著，通俗地讲，底层硬件辛辛苦苦地优化设计节省的效果，远远不如软件设计得好的表现。

　　从软件的业务逻辑、产品需求方面的设计，在功耗方面更有意想不到的效果，软件功耗优化简单总结就是“能睡就睡”。

　　4.1 任务周期化

　　一个嵌入式产品包括很多子功能、子任务，一个应用是对若干服务的调用实现的。这里服务可以是硬件服务，比如AD电压采样、UART串口通讯，也可以是软件服务，比如TCP/IP网络通信等。简单的功能如CRC校验，纯软件实现，函数运行立即获得结果，对功耗无所谓影响；复杂的功能，尽量使用任务的方式来实现，并不是特指操作系统的task或者thread，可以理解为一个流程，即一个子功能运行的完整过程。一件事有始有终就可以根据需要循环反复，周期运行的任务，明确运行的起止时间点，区分运行与非运行状态就能更好的优化，比如减少运行持续时间或者其中大电流的时间段，在功耗方面效果比较明显。

　　4.2 休眠自理与协调

　　将整个嵌入式软件系统分成了很多周期性工作的小任务，它们可能是交错的或者毫无关系并行的。从本质上说，每个小任务只需关注自身的起止时间点。系统的功耗管理就是为每个任务的功耗进行管理，整体在一个有效的协调方式下才能做到功耗最小。基于任务的功耗管理实际上分成两个部分，微观角度单任务自身的功耗管理，和宏观角度多任务的休眠协调。

　　从微观角度来看，一个任务能独立完成自己的功能，任务中所有的步骤都是确定的，都是“自己说了算的”，对外界来说是“黑盒子”，对低功耗的要求，不外乎以下几种情形：

　　（1）、任务执行的过程中不允许休眠，因此任务的开头和结尾处要设置标志，告知协调系统，“只要我不同意，就不允许系统休眠”。 （2）、任务执行的过程中，某些阶段允许休眠，某些阶段不允许休眠；任务的执行过程中，不同阶段允许不同的休眠等级。 （3）、任务执行的过程中，不在乎是否休眠。

　　三类任务同时存在于系统中，第一类任务是相当霸道的，只要它在执行，根本不允许休眠；第二类任务既完成了任务，又兼顾了休眠；第三类任务基本上可当做空气无视。系统任务设计时应尽可能编写后两类任务，避免或者尝试拆分第一类任务。

　　从宏观角度来看，任意时刻可能有多个任务同时在执行，每个任务对休眠的需求都是不同的。如果要设立一个协调机制，该怎么办呢？每个任务按最低需求，随时来休眠协调机构签到投票，表明自身当前能够容忍的最低功耗对应的休眠等级，休眠协调机构的仲裁者定时或轮询检查所有任务的投票结果，找到最小的休眠等级，类似水桶的最矮一环作为“共识”，然后进入相应的休眠等级。

　　如果有人投了“不休眠”的票，仲裁就只能放弃休眠。所以，每一个任务都应该是一个负责的任务，都应该根据自己的不同步骤及时的更新自己对休眠的容忍度，从而保证投票能够达成有意义的结果。

　　这种机制实现也很容易，比如

　　//微信公众号：嵌入式系统

　　uint16_t sleep_enable = 0xFFFF; //0xFFFF表示可以进入休眠

　　uint16_t sleep_enable=0xFFFF，表示系统可以进入休眠，每个任务独立的操作相应的一位，禁止休眠时清0，允许休眠则置1。休眠协调机制即定时查询sleep_enable是否为0xFFFF，可以在main轮询或RTOS的待机任务查询，进行休眠的进出。

　　任务的划分合理，尽量允许休眠，通过这种协商机制可以解决“能睡就睡”的问题。

　　4.3 任务等待合并

　　设备运行中必然存在定时唤醒的任务，多个定时任务随机的在任意时刻唤醒工作，导致频繁退出休眠。这种情况下，在最大允许延迟的情况下，多个任务可以在一次唤醒全部执行。比如去超市买菜，肯定是一次把当天需要的菜都买了，而不是每餐前都去买，一天到晚跑超市。在4G物联网产品应用，比如设备每3分钟需要向服务器发送一个TCP/IP心跳包，同时传感器每10秒采集一个数据也需要上报服务器，可以实现为数据缓存，等到3分钟的定时器溢出上报时，将采集的多组传感器数据组合一并上报，减少无线网络模块唤醒的次数。

　　4.4 及时止损

　　因为环境或外设组合不同，可能在某些时间段无法实现需求，或者结合当前信息大概率无法实现，或者硬件部分故障，软件监测到这种异常后，需要及时止损，减少不必要的消耗。例如GNSS卫星定位，其属性就是必须在开阔区域才能定位，如果设备开启GNSS但发现信号很差，可初步判断当前位置可能在室内，即使继续工作也不能定位，可以立刻关闭GNSS节省电量；当然产品在需求层面需要考虑不定位的其他操作。或者通信中确认外设不存在或者损坏，就没必要继续供电定时交互，进行异常报警即可。

　　4.5 需求层面

　　在需求定义时，充分考虑某个任务或外设工作的起止要求，避免长时间进行无效工作。例如可以根据加速度传感器判断设备是否处于运动状态在开启监控，或者通过红外或声控判断有人接近才开启工作。这种都是通过产品定义，在需求层面组合，满足要求才唤醒工作，不满足则及时停止进入休眠，当然也可能增加硬件成本。部分设备也可以考虑使用场地增加太阳能充电板，开源节流。