Power Manager Integration#
In this article, we describe what are the supported RAIL features in different energy modes, and how high energy efficiency can be achieved with appropriate software. Furthermore, we give a general overview of how RAIL leverages the Power Manager's services.
Introduction#
The radio must always run off of a High-Frequency Crystal Oscillator (HFXO) that drives the RAIL's internal timer for high accuracy protocol timing. It is essential to keep this clock running during any active radio operation such as active transmission and reception. As a result, the radio is active only in EM0 and EM1/EM1P as the HFXO clock is running only in these - highest - Energy Modes (EM).
The Power Manager is a platform-level software module that manages the system's energy modes. Its primary purpose is to transition the system to the lowest-energy mode, consequently reducing the overall current consumption, when the processor has nothing to execute and there is no peripheral requesting higher energy modes. Additionally, it ensures strict control of the power-intensive resources, just like the high-frequency external oscillator.
You can instruct the Power Manager to enable/disable energy mode transitions by specifying EM level requirements. You can also register listeners at any point of your software to get notification on the energy mode transitions via the Power Manager's notification mechanism.
For complete documentation on the Power Manager service, visit the platform documentation page.
Best Practices for using RAIL with Power Manager#
Benefits of Using Power Manager#
The Power Manager makes your application energy-friendly more effectively and it provides a neat API to interface with. As some of the Silicon Labs software modules might tightly integrate Power Manager (e.g., the Sleep Timer service and RAIL), your application's energy mode requirements can be managed in the same way as those do. That makes complex decisions on the energy mode requirements of the entire software much more coherent.
The Power Manager offers a notification system that keeps the "subscribers" informed on energy mode changes providing the perfect opportunity to react to the EM transitions as soon as possible.
Enabling Power Manager and Timer Synchronization in RAIL#
The RAIL_InitPowerManager() configures RAIL to use Power Manager. If it is initialized, RAIL automatically request the lowest energy mode sufficient for proper radio operation. To stop this feature, call RAIL_DeinitPowerManager(). However, removing the energy mode requirements is not done automatically as it is discussed in the following section.
If you have to schedule radio operations more precisely during the sleep
periods, you also need to call the
RAIL_ConfigSleep()
or
RAIL_ConfigSleepAlt()
APIs with the RAIL_SLEEP_CONFIG_TIMERSYNC_ENABLED parameter. If the
synchronization is not needed, use the RAIL_SLEEP_CONFIG_TIMERSYNC_DISABLED
option. Details on how this synchronization works are documented in a later
article.
Installing the Power Manager Integration component under RAIL-SDK configures RAIL to use Power Manager as well as enables timer synchronization.
Radio Yielding Practice#
When RAIL's Power Manager integration is enabled, any operation that requires the radio to be in Rx or Tx will request the power mode needed for that, usually EM1. RAIL_Idle(), which stops any of these operations, will release that power mode request.
In case the radio returns to idle automatically however, e.g., at Tx complete, the application must explicitly release the power mode by calling RAIL_Yield() or RAIL_Idle().
Timers also require EM1, at least before their callback is called, so calling RAIL_Yield() (or Idle) from a timer callback is also necessary.
To summarize, you will need to call
RAIL_Yield()
or RAIL_Idle() from
the rail timer callbacks and event handler to make sure RAIL releases the
requested power mode. In the event handler, Yielding is mainly necessary at Tx
completion and Rx completion, if automatic state transitions are set to idle.
There are other events however that reports that radio or timer is not needed
anymore, such as RAIL_EVENT_RSSI_AVERAGE_DONE and
RAIL_EVENT_TX_SCHEDULED_TX_MISSED.
Note that this could mean that you have to enable some events just to yield the
requested energy mode, typically the events in the groups
RAIL_EVENTS_RX_COMPLETION and RAIL_EVENTS_TX_COMPLETION.
EM4 Limitation#
Because waking up from the lowest - EM4 - energy mode resets the MCU entirely, this scenario does not fit into how the Power Manager operates. Therefore entering and leaving the lowest energy mode is not supported by the Power Manager. Still, this mode can be requested in the application as well as restoring previous states is also the application's duty. Keep in mind that entering EM4 aborts all ongoing and scheduled radio operations and makes time synchronization impossible.
RAIL without Power Manager#
If you've installed the Power Manager service in your application, but it is not initialized to be used by RAIL (or the Power Manager is temporarily deinitialized), you should manually manage the energy mode requirements matching the radio's needs.
As discussed above, any active radio operation requires EM1(P) or EM0 energy
mode. If RAIL does not initialize Power Manager, call
sl_power_manager_add_em_requirement() and
sl_power_manager_remove_em_requirement() with the required energy mode before
starting the radio operation and after the associated radio event has been
handled, respectively.
Synchronization requires EM2 because this is the highest energy mode with active low-frequency oscillators running. RAIL_Sleep() and RAIL_Wake() APIs must be called for performing time synchronization. Find more implementation details on docs.silabs.com.
Entering lower energy modes than required breaks the active radio operation or the synchronization mechanism.