本帖最后由 Simon21ic 于 2015-11-6 17:48 编辑
是的，需求确实都不同的，不过软件上，确实有不同的实现方式。
之前说了我的一个朋友那边的实现方式，就是询问每个任务可以接受的休眠等级，然后综合计算出最优的修休眠等级。
比如，任务A开启了AD转换，那么任务A可以接收的休眠等级中，就不能关闭AD。其他任务，可以接受的休眠等级都不相同。
但是，问题是，任务A要知道哪个休眠等级是对于自己来说最适合的，这就会碰到一个问题。
任务需要知道自己是运行在哪个处理器上，因为不同的处理器，低功耗的设计部分可能都不同。
然后，他们的构架中，也具备芯片外设的抽象层，相当于stm32的库，当然，功能更强而已。
我自己的构架中，也同样具备芯片外设的驱动库，不同的芯片，SPI等这类标准外设都已经抽象为一个同一个的接口了。
这种好处就是换芯片就和换衣服一样（前提是目标芯片的驱动都已经开发好）
在这个基础上，我们软件中低功耗的实现，需要应用层介入的部分就很少了。
原理是，既然底层驱动是和芯片相关的，那么低功耗部分也是在底层驱动里，就可以知道芯片目前已经使用了那些资源。
这样，进入低功耗模式的时候，可以自动进入最优的低功耗模式。
比如前面那个例子，如果高层应用开启了ADC（通过调用底层的通用ADC接口来实现），那么底层代码就能够知道ADC已经开启，这样，就可以选择当前芯片在当前资源使用情况下的最优的休眠等级。
而应用层里的各个任务，完全不需要关心这些细节，只要在适合的时候使用资源，在适合的是否关闭资源就行。
这个的好处是，低功耗对于应用来说，几乎透明，开发的代码，自然就是符合低功耗要求的。
当然，这个也只是一种方法而已，欢迎大家介绍其他的方法。
|
楼主
