Search icon
Arrow left icon
All Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Newsletters
Free Learning
Arrow right icon
Mastering Embedded Linux Programming - Third Edition

You're reading from  Mastering Embedded Linux Programming - Third Edition

Product type Book
Published in May 2021
Publisher Packt
ISBN-13 9781789530384
Pages 758 pages
Edition 3rd Edition
Languages
Authors (2):
Frank Vasquez Frank Vasquez
Profile icon Frank Vasquez
Chris Simmonds Chris Simmonds
Profile icon Chris Simmonds
View More author details

Table of Contents (27) Chapters

Preface Section 1: Elements of Embedded Linux
Chapter 1: Starting Out Chapter 2: Learning about Toolchains Chapter 3: All about Bootloaders Chapter 4: Configuring and Building the Kernel Chapter 5: Building a Root Filesystem Chapter 6: Selecting a Build System Chapter 7: Developing with Yocto Chapter 8: Yocto Under the Hood Section 2: System Architecture and Design Decisions
Chapter 9: Creating a Storage Strategy Chapter 10: Updating Software in the Field Chapter 11: Interfacing with Device Drivers Chapter 12: Prototyping with Breakout Boards Chapter 13: Starting Up – The init Program Chapter 14: Starting with BusyBox runit Chapter 15: Managing Power Section 3: Writing Embedded Applications
Chapter 16: Packaging Python Chapter 17: Learning about Processes and Threads Chapter 18: Managing Memory Section 4: Debugging and Optimizing Performance
Chapter 19: Debugging with GDB Chapter 20: Profiling and Tracing Chapter 21: Real-Time Programming Other Books You May Enjoy

Chapter 15: Managing Power

For devices operating on battery power, power management is critical: anything we can do to reduce power usage will increase battery life. Even for devices running on mains power, reducing power usage has benefits in reducing the need for cooling and energy costs. In this chapter, I will introduce the four principles of power management:

  • Don't rush if you don't have to.
  • Don't be ashamed of being idle.
  • Turn off things you are not using.
  • Sleep when there is nothing else to do.

Putting these into more technical terms, the principles mean that the power management system should endeavor to reduce the CPU clock frequency. During idle periods, it should choose the deepest sleep state possible; it should reduce the load by powering down unused peripherals and it should be able to put the whole system into a suspended state while ensuring power state transitions are quick.

Linux has features that address each of these...

Technical requirements

To follow along with the examples, make sure you have the following:

  • A Linux-based system
  • Etcher for Linux
  • A microSD card reader and card
  • A USB to TTL 3.3V serial cable
  • A BeagleBone Black
  • A 5V 1A DC power supply
  • An Ethernet cable and port for network connectivity

All of the code for this chapter can be found in the Chapter15 folder from the book's GitHub repository: https://github.com/PacktPublishing/Mastering-Embedded-Linux-Programming-Third-Edition.

Measuring power usage

For the examples in this chapter, we need to use real hardware rather than virtual. This means that we need a BeagleBone Black with working power management. Unfortunately, the BSP for the BeagleBone that comes with the meta-yocto-bsp layer does not include the necessary firmware for the Power Management IC (PMIC), so we will use
a pre-built Debian image instead. The missing firmware might exist in the meta-ti layer, but I did not investigate that. The procedure for installing Debian on the BeagleBone Black is the same as what we covered in Chapter 12, Prototyping with Breakout Boards, except for the Debian version.

To download the Debian Stretch IoT microSD card image for the BeagleBone Black, issue the following command:

$ wget https://debian.beagleboard.org/images/bone-debian-9.9-iot-armhf-2019-08-03-4gb.img.xz

10.3 (aka Buster) was the latest Debian image for AM335x-based BeagleBones at the time of writing. We will use Debian 9.9 for the exercises...

Scaling the clock frequency

Running for a kilometer takes more energy than walking. In a similar way, maybe running the CPU at a lower frequency can save energy. Let's see.

The power consumption of a CPU when executing code is the sum of a static component, caused by gate leakage current, among other things, and a dynamic component, caused by the switching of the gates:

Pcpu = Pstatic + Pdyn

The dynamic power component is dependent on the total capacitance of the logic gates being switched, the clock frequency, and the square of the voltage:

Pdyn = CfV2

From this, we can see that changing the frequency by itself is not going to save any power because the same number of CPU cycles have to be completed in order to execute a given subroutine. If we reduce the frequency by half, it will take twice as long to complete the calculation, but the total power consumed due to the dynamic power component will be the same. In fact, reducing the frequency may actually increase...

Selecting the best idle state

When a processor has no more work to do, it executes a halt instruction and enters
an idle state. While idle, the CPU uses less power. It exits the idle state when an event
such as a hardware interrupt occurs. Most CPUs have multiple idle states that use
varying amounts of power. Usually, there is a trade-off between the power usage and the latency, or the length of time, it takes to exit the state. In the ACPI specification, they are called C-states.

In the deeper C-states, more circuitry is turned off at the expense of losing some state, and so it takes longer to return to normal operation. For example, in some C-states the CPU caches may be powered off, and so when the CPU runs again, it may have to reload some information from the main memory. This is expensive, and so you only want to do this if there is a good chance that the CPU will remain in this state for some time. The number of states varies from one system to another. Each takes some time...

Powering down peripherals

The discussion up to now has been about CPUs and how to reduce power consumption when they are running or idling. Now it is time to focus on other parts of the system peripherals and see whether we can achieve power savings here.

In the Linux kernel, this is managed by the runtime power management system or runtime pm for short. It works with drivers that support runtime pm, shutting down those that are not in use and waking them again when they are next needed. It is dynamic and should be transparent to user space. It is up to the device driver to implement the management of the hardware, but typically, it would include turning off the clock to the subsystem, also known as clock gating, and turning off core circuitry where possible.

The runtime power management is exposed via a sysfs interface. Each device has
a subdirectory named power, in which you will find these files:

  • control: This allows user space to determine whether runtime pm is used...

Putting the system to sleep

There is one more power management technique to consider: putting the whole system into sleep mode with the expectation that it will not be used again for a while. In the Linux kernel, this is known as system sleep. It is usually user-initiated: the user decides that the device should be shut down for a while. For example, I shut the lid of my laptop and put it in my bag when it is time to go home. Much of the support for system sleep in Linux comes from the support for laptops. In the laptop world, there are usually two options:

  • Suspend
  • Hibernate

The first, also known as suspend to RAM, shuts everything down except the system memory, so the machine is still consuming a little power. When the system wakes up, the memory retains all the previous state, and my laptop is operational within a few seconds.

If I select the hibernate option, the contents of the memory are saved to the hard drive. The system consumes no power at all, and...

Summary

Linux has sophisticated power management functions. I have described four
main components:

  • CPUFreq changes the OPP of each processor core to reduce power on those that are busy but have some bandwidth to spare, and so allow the opportunity to scale the frequency back. OPPs are known as P-States in the ACPI specification.
  • CPUIdle selects deeper idle states when the CPU is not expected to be woken up for a while. Idle states are known as C-States in the ACPI specification.
  • Runtime pm will shut down peripherals that are not needed.
  • System sleep modes will put the whole system into a low power state. They are usually under end user control, for example, by pressing a standby button. System sleep states are known as S-States in the ACPI specification.

Most of the power management is done for you by the BSP. Your main task is to make sure that it is configured correctly for your intended use cases. Only the last component, selecting a system sleep state...

Further reading

lock icon The rest of the chapter is locked
You have been reading a chapter from
Mastering Embedded Linux Programming - Third Edition
Published in: May 2021 Publisher: Packt ISBN-13: 9781789530384
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $15.99/month. Cancel anytime}