如何在基于ARM的嵌入式Linux系统上实现省电？
我计划开发一个漂亮的小应用程序，它将在基于 ARM 的嵌入式 Linux 平台上运行；但是，由于该平台将由电池供电，因此我正在寻找有关如何处理省电的相关信息。
获得适当的电池使用时间非常重要。
我认为 Linux 内核对此实现了一些支持，但我找不到有关此主题的任何文档。
欢迎任何有关如何设计我的程序和系统的意见。
也欢迎任何有关 Linux 内核如何尝试解决此类问题的意见。
其他问题：
用户空间的程序需要做多少事情？
需要修改内核吗？
哪些内核系统调用或 API 值得了解？
更新：
“自由电子”网站的相关人员似乎已经就这个主题制作了一些不错的演示文稿。
- http://free-electrons.com/services/power-management/
- http://free-electrons.com/docs/power
- http://free-electrons.com/docs/optimizations
但也许其他人有关于这个主题的更多信息？
更新：
Adam Shiemke 去看看 MeeGo 项目的想法似乎是迄今为止最好的建议。
它可能是目前最好的电池供电嵌入式 Linux 项目。
诺基亚通常擅长这类事情。
更新：
人们必须小心 Android，因为它的底层有一个“修改过的”Linux 内核，而 Google 人员所做的一些事情并不使用基线/普通 Linux 内核。我认为他们的一些电源管理思想在其他项目中重用可能会很麻烦。
I plan to develop a nice little application that will run on an arm-based embedded Linux platform; however, since that platform will be battery-powered, I'm searching for relevant information on how to handle power save.
It is kind of important to get decent battery time.
I think the Linux kernel implemented some support for this, but I can't find any documentation on this subject.
Any input on how to design my program and the system is welcome.
Any input on how the Linux kernel tries to solves this type of problem is also welcome.
Other questions:
How much does the program in user space need to do?
And do you need to modify the kernel?
What kernel system calls or APIs are good to know about?
Update:
It seems like the folks involved with the "Free Electrons" site have produced some nice presentations on this subject.
- http://free-electrons.com/services/power-management/
- http://free-electrons.com/docs/power
- http://free-electrons.com/docs/optimizations
But maybe someone else has even more information on this subject?
Update:
It seems like Adam Shiemke's idea to go look at the MeeGo project may be the best tip so far.
It may be the best battery powered Embedded Linux project out there at this moment.
And Nokia is usually kind of good at this type of thing.
Update:
One has to be careful about Android since it has a "modified" Linux kernel in the bottom, and some of the things the folks at Google have done do not use baseline/normal Linux kernels. I think that some of their power management ideas could be troublesome to reuse for other projects.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我实际上并没有这样做，但我对两者（Linux 和嵌入式电源管理）有经验。在考虑电源管理时，我们会想到两个主要的 Linux 发行版：Android 和 MeeGo。 MeeGo 使用（据我所知）未经修改的 2.6 内核，并保留了一些附加功能。我无法找到很多关于他们的电源管理策略的信息，尽管我怀疑随着产品接近成熟，在不久的将来会出现更多关于它的信息。
然而，Android 上还有更多信息。他们运行经过大量修改的 2.6 内核。您可以在 http://elinux.org/Android_Power_Management（以及内核剧）。其他一些链接：
https:// /groups.google.com/group/android-kernel/browse_thread/thread/ee356c298276ad00/472613d15af746ea?lnk=raot&pli=1
http://www.ok-labs.com/blog/entry/context-switching-in-context/
我确定您可以找到更多此类性质的链接。由于这两个项目都是开源的，因此您可以获取内核代码，并且可能从真正了解自己在表单和小组中谈论的内容的人们那里获得更多信息。
在驱动程序级别，您需要确保您的驱动程序可以正确处理挂起并关闭不使用的设备。大多数针对移动市场的设备都提供非常细粒度的支持，以关闭各个组件并调整时钟设置（请记住，功率与时钟^2成正比）。
希望这有帮助。
I haven't actually done this, but I have experience with the two apart (Linux and embedded power management). There are two main Linux distributions that come to mind when thinking about power management, Android and MeeGo. MeeGo uses (as far as I can tell) an unmodified 2.6 kernel with some extras hanging on. I wasn't able to find a lot on exactly what their power management strategy is, although I suspect more will be coming out about it in the near future as the product approaches maturity.
There is much more information available on Android, however. They run a fairly heavily modified 2.6 kernel. You can see a good bit on the different strategies implemented in http://elinux.org/Android_Power_Management (as well as kernel drama). Some other links:
https://groups.google.com/group/android-kernel/browse_thread/thread/ee356c298276ad00/472613d15af746ea?lnk=raot&pli=1
http://www.ok-labs.com/blog/entry/context-switching-in-context/
I'm sure that you can find more links of this nature. Since both projects are open source, you can grab the kernel code, and probably get further information from people who actually know what they are talking about in forms and groups.
At the driver level, you need to make sure that your drivers can properly handle suspend and shut devices off that are not in use. Most devices aimed at the mobile market offer very fine-grained support to turn individual components off, and to tweak clock settings (remember, power is proportional to clock^2).
Hope this helps.
假设您正在编写（或至少拥有其源代码）应用程序和驱动程序，您可以在不需要操作系统任何特殊支持的情况下实现相当多的节能。
您的驱动程序需要能够禁用其关联的设备并将其恢复，而无需重新启动或引入系统不稳定。如果您的设备连接到 PCI/PCIe 总线，请研究它们支持哪些电源状态 (D0 - D3) 以及您的驱动程序需要执行哪些操作才能在这些低功耗模式之间进行转换。如果您正在选择要使用的硬件设备，请寻找符合 PCI 电源管理规范或具有类似功能（例如睡眠模式和“唤醒”中断信号）的设备。
当您的设备启动时，每个能够检测其是否连接到任何设备的设备都需要这样做。如果任何端口或总线检测到它们未被使用，请将其关闭或使其进入睡眠状态。以全功率运行但未使用的端口会浪费比您想象的更多的电量。根据您的特定硬件和使用案例，拥有一个后台应用程序来监视设备使用情况、识别未使用/空闲的资源并采取适当的操作（就像您的硬件的“屏幕保护程序”）也可能很有用。
您的应用程序软件应确保在尝试使用硬件设备之前检测它们是否已通电。如果您需要访问可能处于低功耗模式的设备，您的应用程序需要能够处理等待设备唤醒和响应时可能出现的长时间延迟。您的应用程序还应该考虑设备的睡眠需求。如果您需要向硬件设备发送一系列命令，请尝试将它们缓冲起来并一次全部发送出去，而不是将它们间隔开并需要多个唤醒->发送->睡眠周期。
不要害怕稍微降低系统组件的时钟频率。除了节省电力之外，这还可以帮助它们以更低的温度运行（这需要更少的冷却电力）。我见过一些设计，其使用的 CPU 功能比所需的功能要强大很多，然后降频高达 40%（将性能降低到原始水平，但功耗仅为其一小部分） 。另外，不要害怕花费电力来节省电力。也就是说，不要害怕使用 CPU 时间监控硬件设备来禁用/休眠它们（即使这会导致您的 CPU 使用更多电量）。大多数时候，这种权衡会带来净功率节省。
You can do quite a bit of power-saving without requiring any special support from the OS, assuming you are writing (or at least have the source code for) your application and drivers.
Your drivers need to be able to disable their associated devices and bring them back up without requiring a restart or introducing system instability. If your devices are connected to a PCI/PCIe bus, research which power states they support (D0 - D3) and what your driver needs to do to transition between these low-power modes. If you are selecting hardware devices to use, look for devices that adhere to the PCI Power Management Specification or have similar functionality (such as a sleep mode and a "wake up" interrupt signal).
When your device boots up, every device that has the ability to detect whether it is connected to anything needs to do so. If any ports or buses detect that they are not being used, power them down or put them to sleep. A port running at full power but sitting unused can waste more power than you might think it would. Depending on your particular hardware and use case, it might also be useful to have a background app that monitors device usage, identifies unused/idle resources, and acts appropriately (like a "screen saver" for your hardware).
Your application software should make sure to detect whether hardware devices are powered up before attempting to use them. If you need to access a device that might be placed in a low-power mode, your application needs to be able to handle a potentially lengthy delay in waiting for the device to wake up and respond. Your applications should also be considerate of a device's need to sleep. If you need to send a series of commands to a hardware device, try to buffer them up and send them out all at once instead of spacing them out and requiring multiple wakeup->send->sleep cycles.
Don't be afraid to under-clock your system components slightly. Besides saving power, this can help them run cooler (which requires less power for cooling). I have seen some designs that use a CPU that is more powerful than necessary by a decent margin, which is then under-clocked by as much as 40% (bringing the performance down to the original level but at a fraction of the power cost). Also, don't be afraid to spend power to save power. That is, don't be afraid to use CPU time monitoring hardware devices for opportunities to disable/hibernate them (even if it will cause your CPU to use a bit more power). Most of the time, this tradeoff results in a net power savings.
作为具有功耗意识的应用程序开发人员，要考虑的最重要的事情之一是避免不必要的计时器。如果可能，请使用中断驱动解决方案而不是轮询解决方案。如果必须使用计时器，则使用尽可能长的轮询间隔。
例如，如果需要在某个室温下执行某些特殊操作，则无需每 100 毫秒检查一次温度，因为房间内的温度变化缓慢。更合理的轮询间隔可以是 60 秒。
这会以多种方式影响功耗。在 Linux 中，CPUIDLE 子系统根据预测下一次唤醒发生的时间，将 CPU (SOC) 置于尽可能深度的省电状态。系统中拥有大量计时器会使睡眠变得碎片化，从而无法长时间进入更深的睡眠状态。 CPUIDLE 的典型深度睡眠状态会关闭 CPU，但保持 RAM 自刷新。当定时器触发时，CPU 将启动并为应用程序的定时器提供服务。
One of the most important things to think of as a power aware application developer is to avoid unnecessary timers. If possible use interrupt driven solutions instead of polled solutions. If a timer must be used then use as long poll interval as is possible.
For example if something special should be done at a certain room temperature it is unnecessary to check the temperature every 100 ms since temperature in a room changes slowly. A more reasonable polling interval is could be 60 s.
This affects the power consumption in several ways. In Linux the CPUIDLE subsystem takes the CPU (SOC) to as deep power saving state as possible depending on when it predicts the next wakeup to occur. Having a lot of timers in a system will fragment the sleep making it impossible to go to the deeper sleep states for longer periods. A typical deep sleep state for CPUIDLE turns the CPU off but keeps the RAM in self refresh. When a timer triggers the CPU will boot and serve the timer of the application.
这实际上不是您的主题，但它可能会派上用场来记录您的进度：我正在寻找测试/测量我的嵌入式 Linux 系统。这个论坛的 chris desjardins 向我推荐了这个：
我过去曾成功使用过 bootchart：
http://elinux.org/Bootchart
以下是可能也有帮助的其他内容的列表：
http://elinux.org/Boot_Time
It's not actually your topic, but it might come in handy to log your progress: i was looking for testing / measuring my embedded linux system. chris desjardins from this forum recommended me this:
I have successfully used bootchart in the past:
http://elinux.org/Bootchart
Here is a list of other things that may also help:
http://elinux.org/Boot_Time