alex/esp-idf
1
0
Fork 0
mirror of https://github.com/espressif/esp-idf.git synced 2025-12-07 09:02:08 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'doc/update_esp32p4_pm_programming_guide_docs_v5.3' into 'release/v5.3'

Browse Source 
docs(pm): update power management related docs for esp32p4 (v5.3)

See merge request espressif/esp-idf!32629
This commit is contained in:
Jiang Jiang Jian
2024-09-04 17:58:13 +08:00
parent 2d850169c0 5e403bb7c6
commit 0d1227c06f
17 changed files with 148 additions and 111 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
docs/en/api-reference/system/inc/power_management_esp32p4.rst
View File

@@ -1 +1,13 @@
TO BE UPDATED IDF-7672
+---------------+---------------------------------------+-------------------------------------+
| Max CPU | Lock Acquisition | CPU and APB Frequencies |
| Frequency Set | | |
+---------------+---------------------------------------+-------------------------------------+
| 360 | ``ESP_PM_CPU_FREQ_MAX`` acquired | | CPU: 360 MHz |
| | | | APB: 90 MHz |
+ +---------------------------------------+-------------------------------------+
| | ``ESP_PM_APB_FREQ_MAX`` acquired, | | CPU: 90 MHz |
| | ``ESP_PM_CPU_FREQ_MAX`` not acquired | | APB: 90 MHz |
+ +---------------------------------------+-------------------------------------+
| | None | Min values for both frequencies set |
| | | with :cpp:func:`esp_pm_configure` |
+---------------+---------------------------------------+-------------------------------------+

75
docs/en/api-reference/system/power_management.rst
View File

@@ -55,7 +55,7 @@ Dynamic frequency scaling (DFS) and automatic Light-sleep can be enabled in an a
Power Management Locks
----------------------
{IDF_TARGET_MAX_CPU_FREQ: default="Not updated yet", esp32="80 MHz, 160 MHz, or 240 MHz", esp32s2="80 MHz, 160 MHz, or 240 MHz", esp32s3="80 MHz, 160 MHz, or 240 MHz", esp32c2="80 MHz or 120 MHz", esp32c3="80 MHz or 160 MHz", esp32c6="80 MHz or 160 MHz"}
{IDF_TARGET_MAX_CPU_FREQ: default="Not updated yet", esp32="80 MHz, 160 MHz, or 240 MHz", esp32s2="80 MHz, 160 MHz, or 240 MHz", esp32s3="80 MHz, 160 MHz, or 240 MHz", esp32c2="80 MHz or 120 MHz", esp32c3="80 MHz or 160 MHz", esp32c6="80 MHz or 160 MHz", esp32p4="360 MHz"}
Applications have the ability to acquire/release locks in order to control the power management algorithm. When an application acquires a lock, the power management algorithm operation is restricted in a way described below. When the lock is released, such restrictions are removed.
@@ -114,7 +114,7 @@ The following drivers hold the ``ESP_PM_APB_FREQ_MAX`` lock while the driver is
- **SPI slave**: between calls to :cpp:func:`spi_slave_initialize` and :cpp:func:`spi_slave_free`.
- **GPTimer**: between calls to :cpp:func:`gptimer_enable` and :cpp:func:`gptimer_disable`.
- **Ethernet**: between calls to :cpp:func:`esp_eth_driver_install` and :cpp:func:`esp_eth_driver_uninstall`.
- **WiFi**: between calls to :cpp:func:`esp_wifi_start` and :cpp:func:`esp_wifi_stop`. If modem sleep is enabled, the lock will be released for the periods of time when radio is disabled.
:SOC_WIFI_SUPPORTED: - **WiFi**: between calls to :cpp:func:`esp_wifi_start` and :cpp:func:`esp_wifi_stop`. If modem sleep is enabled, the lock will be released for the periods of time when radio is disabled.
:SOC_TWAI_SUPPORTED: - **TWAI**: between calls to :cpp:func:`twai_driver_install` and :cpp:func:`twai_driver_uninstall` (only when the clock source is set to :cpp:enumerator:`TWAI_CLK_SRC_APB`).
:SOC_BT_SUPPORTED and esp32: - **Bluetooth**: between calls to :cpp:func:`esp_bt_controller_enable` and :cpp:func:`esp_bt_controller_disable`. If Bluetooth Modem-sleep is enabled, the ``ESP_PM_APB_FREQ_MAX`` lock will be released for the periods of time when radio is disabled. However the ``ESP_PM_NO_LIGHT_SLEEP`` lock will still be held, unless :ref:`CONFIG_BTDM_CTRL_LOW_POWER_CLOCK` option is set to "External 32kHz crystal".
:SOC_BT_SUPPORTED and not esp32: - **Bluetooth**: between calls to :cpp:func:`esp_bt_controller_enable` and :cpp:func:`esp_bt_controller_disable`. If Bluetooth Modem-sleep is enabled, the ``ESP_PM_APB_FREQ_MAX`` lock will be released for the periods of time when radio is disabled. However the ``ESP_PM_NO_LIGHT_SLEEP`` lock will still be held.
@@ -129,46 +129,53 @@ The following peripheral drivers are not aware of DFS yet. Applications need to
:SOC_MCPWM_SUPPORTED: - MCPWM
Light-sleep Peripheral Power Down
---------------------------------
.. only:: SOC_PM_SUPPORT_TOP_PD and not esp32c5
.. only:: esp32c6 or esp32h2
Light-sleep Peripheral Power Down
---------------------------------
{IDF_TARGET_NAME} supports power-down peripherals during Light-sleep.
{IDF_TARGET_NAME} supports power-down peripherals during Light-sleep.
If :ref:`CONFIG_PM_POWER_DOWN_PERIPHERAL_IN_LIGHT_SLEEP` is enabled, when the driver initializes the peripheral, the driver will register the working register context of the peripheral to the sleep retention link. Before entering sleep, the ``REG_DMA`` peripheral reads the configuration in the sleep retention link, and back up the register context to memory according to the configuration. ``REG_DMA`` also restores context from memory to peripheral registers on wakeup.
If :ref:`CONFIG_PM_POWER_DOWN_PERIPHERAL_IN_LIGHT_SLEEP` is enabled, when the driver initializes the peripheral, the driver will register the working register context of the peripheral to the sleep retention link. Before entering sleep, the ``REG_DMA`` peripheral reads the configuration in the sleep retention link, and back up the register context to memory according to the configuration. ``REG_DMA`` also restores context from memory to peripheral registers on wakeup.
Currently ESP-IDF supports Light-sleep context retention for the following peripherals:
- INT_MTX
- TEE/APM
- IO_MUX / GPIO
- UART0/1
- GPTimer
- SPI0/1
- SYSTIMER
Currently ESP-IDF supports Light-sleep context retention for the following peripherals:
The following peripherals are not yet supported:
- ETM
- ASSIST_DEBUG
- Trace
- Crypto: AES/ECC/HMAC/RSA/SHA/DS/XTA_AES/ECDSA
- SPI2
- I2S
- PCNT
- USB-Serial-JTAG
- TWAI
- LEDC
- MCPWM
- RMT
- SARADC
- SDIO
- PARL_IO
.. list::
For peripherals that do not support Light-sleep context retention, if the Power management is enabled, the ``ESP_PM_NO_LIGHT_SLEEP`` lock should be held when the peripheral is working to avoid losing the working context of the peripheral when entering sleep.
- INT_MTX
- TEE/APM
- IO_MUX / GPIO
- Timer Group 0 & Timer Group 1
- SPI0/1
- SYSTIMER
:SOC_RMT_SUPPORT_SLEEP_RETENTION: - RMT
:SOC_I2C_SUPPORT_SLEEP_RETENTION: - I2C
:SOC_UART_SUPPORT_SLEEP_RETENTION: - All UARTs
.. note::
The following peripherals are not yet supported:
When the peripheral power domain is powered down during sleep, both the IO_MUX and GPIO modules are inactive, meaning the chip pins' state is not maintained by these modules. To preserve the state of an IO during sleep, it's essential to call :cpp:func:`gpio_hold_dis` and :cpp:func:`gpio_hold_en` before and after configuring the GPIO state. This action ensures that the IO configuration is latched and prevents the IO from becoming floating while in sleep mode.
.. list::
- ETM
- ASSIST_DEBUG
- Trace
- Crypto: AES/ECC/HMAC/RSA/SHA/DS/XTA_AES/ECDSA
- SPI2
- I2S
- PCNT
- USB-Serial-JTAG
- TWAI
- LEDC
- MCPWM
- SARADC
- SDIO
- PARL_IO
For peripherals that do not support Light-sleep context retention, if the Power management is enabled, the ``ESP_PM_NO_LIGHT_SLEEP`` lock should be held when the peripheral is working to avoid losing the working context of the peripheral when entering sleep.
.. note::
When the peripheral power domain is powered down during sleep, both the IO_MUX and GPIO modules are inactive, meaning the chip pins' state is not maintained by these modules. To preserve the state of an IO during sleep, it's essential to call :cpp:func:`gpio_hold_dis` and :cpp:func:`gpio_hold_en` before and after configuring the GPIO state. This action ensures that the IO configuration is latched and prevents the IO from becoming floating while in sleep mode.
API Reference

21
docs/en/api-reference/system/sleep_modes.rst
View File

@@ -32,7 +32,7 @@ In Deep-sleep mode, the CPUs, most of the RAM, and all digital peripherals that
:SOC_RTC_FAST_MEM_SUPPORTED: - RTC FAST memory
:SOC_RTC_SLOW_MEM_SUPPORTED: - RTC SLOW memory
.. only:: SOC_BT_SUPPORTED
.. only:: SOC_WIFI_SUPPORTED and SOC_BT_SUPPORTED
Wi-Fi/Bluetooth and Sleep Modes
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -41,7 +41,7 @@ In Deep-sleep mode, the CPUs, most of the RAM, and all digital peripherals that
If Wi-Fi/Bluetooth connections need to be maintained, enable Wi-Fi/Bluetooth Modem-sleep mode and automatic Light-sleep feature (see :doc:`Power Management APIs <power_management>`). This allows the system to wake up from sleep automatically when required by the Wi-Fi/Bluetooth driver, thereby maintaining the connection.
.. only:: not SOC_BT_SUPPORTED
.. only:: SOC_WIFI_SUPPORTED and not SOC_BT_SUPPORTED
Wi-Fi and Sleep Modes
^^^^^^^^^^^^^^^^^^^^^^^
@@ -227,7 +227,7 @@ RTC peripherals or RTC memories do not need to be powered on during sleep in thi
- wake up if any of the selected pins is high (``ESP_EXT1_WAKEUP_ANY_HIGH``)
- wake up if all the selected pins are low (``ESP_EXT1_WAKEUP_ALL_LOW``)
.. only:: esp32s2 or esp32s3 or esp32c6 or esp32h2
.. only:: not esp32
- wake up if any of the selected pins is high (``ESP_EXT1_WAKEUP_ANY_HIGH``)
- wake up if any of the selected pins is low (``ESP_EXT1_WAKEUP_ANY_LOW``)
@@ -344,7 +344,7 @@ When {IDF_TARGET_NAME} receives UART input from external devices, it is often ne
After waking-up from UART, you should send some extra data through the UART port in Active mode, so that the internal wakeup indication signal can be cleared. Otherwises, the next UART wake-up would trigger with two less rising edges than the configured threshold value.
.. only:: esp32c6 or esp32h2
.. only:: SOC_PM_SUPPORT_TOP_PD and not esp32c5
.. note::
@@ -471,13 +471,12 @@ Application Example
.. list::
- :example:`protocols/sntp`: the implementation of basic functionality of Deep-sleep, where ESP module is periodically waken up to retrieve time from NTP server.
- :example:`wifi/power_save`: the usage of Wi-Fi Modem-sleep mode and automatic Light-sleep feature to maintain Wi-Fi connections.
:SOC_BT_SUPPORTED: - :example:`bluetooth/nimble/power_save`: the usage of Bluetooth Modem-sleep mode and automatic Light-sleep feature to maintain Bluetooth connections.
:SOC_ULP_SUPPORTED: - :example:`system/deep_sleep`: the usage of various Deep-sleep wakeup triggers and ULP coprocessor programming.
:not SOC_ULP_SUPPORTED: - :example:`system/deep_sleep`: the usage of Deep-sleep wakeup triggered by various sources supported by the chip (RTC Timer, GPIO, EXT0, EXT1, Touch Sensor, etc.).
- :example:`system/light_sleep`: the usage of Light-sleep wakeup triggered by various sources supported by the chip (Timer, GPIO, Touch Sensor, etc.).
- :example:`protocols/sntp` demonstrates the implementation of basic functionality of Deep-sleep, where ESP module is periodically waken up to retrieve time from NTP server.
:SOC_WIFI_SUPPORTED: - :example:`wifi/power_save` demonstrates the usage of Wi-Fi Modem-sleep mode and automatic Light-sleep feature to maintain Wi-Fi connections.
:SOC_BT_SUPPORTED: - :example:`bluetooth/nimble/power_save` demonstrates the usage of Bluetooth Modem-sleep mode and automatic Light-sleep feature to maintain Bluetooth connections.
:SOC_ULP_SUPPORTED: - :example:`system/deep_sleep` demonstrates the usage of various Deep-sleep wakeup triggers and ULP coprocessor programming.
:not SOC_ULP_SUPPORTED: - :example:`system/deep_sleep` demonstrates the usage of Deep-sleep wakeup triggered by various sources, such as the RTC timer, GPIOs, EXT0, EXT1, the touch sensor, supported by {IDF_TARGET_NAME}.
- :example:`system/light_sleep` demonstrates the usage of Light-sleep wakeup triggered by various sources, such as the timer, GPIOs, the touch sensor, supported by {IDF_TARGET_NAME}.
API Reference
-------------