Power Management

Power management is usually something very dependent on the target MCU however ChibiOS/RT can be optimized for power usage.

The HAL drivers

The HAL component abstracts some mechanisms related to power management. Most high level drivers in the HAL component follows a common pattern for some important APIs, two functions appear on most drivers: xxxStart() and xxxStop().
The function xxxStart() activates and configure a driver, the function xxxStop() deactivates the driver. The exact behavior of those functions is implementation-dependent but usually you may expect the following actions.

Starting a Driver

Starting a driver involves the following logical steps:

  1. Activate the peripheral clock.
  2. Activate the related resources clocks, for example the DMA.
  3. Initialize the peripheral cell with the specified parameters.
  4. Activate the required peripheral interrupt sources.
  5. Move the whole driver in the ready/active state.

Stopping a Driver

Steps performed when stopping a driver:

  1. Disable the peripheral interrupt sources.
  2. De-initialize the peripheral cell to its reset state.
  3. Deactivate the peripheral clock.
  4. Deactivate the related resources clocks, for example the DMA.
  5. Move the whole driver in the stopped state.

Taking advantage of the start/stop functionality

Stopping a peripheral clock can save a significant amount of power, an intelligent use of the start/stop functions can help reduce the overall consumption. Some suggestions:

  • Do not start a driver until you really need the service.
  • Stop drivers after using them unless you really need continuous operations.
  • Consider implementing a “low power” mode in your application where you stop non essential threads or drivers. You may activate such a mode when the battery level falls below a programmed threshold or if the device is left unused for some time.

HAL related optimizations

There are several optimizations you can implement in the HAL usage:

  1. Minimize the interrupts from peripherals by setting more conservative parameters to the various device drivers, for example.
    • Slower communication rates, do you really need 115kbauds on that UART?
    • Disable callbacks you do not really need, for example in the PWM driver, often device drivers do not enable the related ISR in such cases and that helps the kernel keeping the CPU sleeping.
    • Slowing down ADC continuous conversions.
  2. Use the CAN driver sleep mode if supported.

Kernel related optimizations

The kernel automatically puts the CPU in an architecture-dependent lower power “wait for interrupts” state when there is no code to execute but there are two considerations:

  1. The system tick and the device driver interrupts often wake the CPU from the low power state. This could be addressed in several ways:
    • Minimize your system tick rate, do you really need a 1mS resolution? you may consider 10mS, 100mS or even slower rates.
    • Set the kernel option CH_TIME_QUANTUM to zero, see the article ”Round Robin scheduling explained”, this reduces the kernel-related overhead and thus power consumption.
    • Reduce the use of virtual timers or slow down their rate down where possible.
  2. Most architectures implement even lower power states that the kernel cannot activate by itself. This could be done by stopping the OS, see the article ”How to cleanly stop the OS”, and then enter the special low power mode. Exiting from a low power mode may involve a reset or a restart, it is architecture dependent.

Other kernel related optimizations

  1. Disable the unused kernel modules, not just for space but also in order to make the kernel consume less cycles handling unused stuff.

Other optimizations

  1. You don't have to use the maximum MCU clock frequency, use the value you really need for your application. Changing frequency, on some platforms, is no more complicated than changing an HAL setting.
  2. Optimize the code for speed rather than for size, wasted cycles are usually also wasted power. Of course also optimizing the application code helps.
  3. Unused pins should be programmed as inputs with pull up resistors or outputs, never leave floating hi-Z pins.
chibios/kb/power.txt · Last modified: 2011/10/03 20:53 by giovanni
Except where otherwise noted, content on this wiki is licensed under the following license:GNU Free Documentation License 1.3