kopia lustrzana https://github.com/espressif/esp-idf
Merge branch 'docs/update_CN_trans_i2c_ledc' into 'master'
docs:update CN translation for bootloader, partition-tables, i2c, and ledc See merge request espressif/esp-idf!15118pull/7439/head^2
Darian
commit
23a03a3bdb
|
|
@ -10,7 +10,7 @@ The ESP-IDF Software Bootloader performs the following functions:
|
|||
1. Minimal initial configuration of internal modules;
|
||||
2. Initialize :doc:`/security/flash-encryption` and/or :doc:`Secure </security/secure-boot-v2>` features, if configured;
|
||||
3. Select the application partition to boot, based on the partition table and ota_data (if any);
|
||||
4. Load this image to RAM (IRAM & DRAM) and transfer management to it.
|
||||
4. Load this image to RAM (IRAM & DRAM) and transfer management to the image that was just loaded.
|
||||
|
||||
Bootloader is located at the address {IDF_TARGET_BOOTLOADER_OFFSET} in the flash.
|
||||
|
||||
|
|
@ -46,7 +46,7 @@ SPI Flash Configuration
|
|||
|
||||
Each ESP-IDF application or bootloader .bin file contains a header with :ref:`CONFIG_ESPTOOLPY_FLASHMODE`, :ref:`CONFIG_ESPTOOLPY_FLASHFREQ`, :ref:`CONFIG_ESPTOOLPY_FLASHSIZE` embedded in it. These are used to configure the SPI flash during boot.
|
||||
|
||||
The :ref:`first-stage-bootloader` in ROM reads the :ref:`second-stage-bootloader` header from flash and uses these settings to load it. However, at this time the system clock speed is lower than configured and not all flash modes are supported. When the :ref:`second-stage-bootloader` then runs and re-configures the flash, it reads values from the currently selected app binary header not the bootloader header. This allows an OTA update to change the SPI flash settings in use.
|
||||
The :ref:`first-stage-bootloader` in ROM reads the :ref:`second-stage-bootloader` header information from flash and uses this infomation to load the rest of the :ref:`second-stage-bootloader` from flash. However, at this time the system clock speed is lower than configured and not all flash modes are supported. When the :ref:`second-stage-bootloader` then runs, it will reconfigure the flash using values read from the currently selected app binary's header (and NOT from the :ref:`second-stage-bootloader` header). This allows an OTA update to change the SPI flash settings in use.
|
||||
|
||||
.. only:: esp32
|
||||
|
||||
|
|
@ -66,21 +66,21 @@ Sometimes it is desirable to have a way for the device to fall back to a known-g
|
|||
|
||||
To roll back to the original "factory" device configuration and clear any user settings, configure the config item :ref:`CONFIG_BOOTLOADER_FACTORY_RESET` in the bootloader.
|
||||
|
||||
The factory reset mechanism allows to reset the device to factory settings in two ways:
|
||||
The factory reset mechanism allows the device to be factory reset in two ways:
|
||||
|
||||
- Clear one or more data partitions. :ref:`CONFIG_BOOTLOADER_DATA_FACTORY_RESET` allows customers to select which data partitions will be erased when the factory reset is executed.
|
||||
- Clear one or more data partitions. The :ref:`CONFIG_BOOTLOADER_DATA_FACTORY_RESET` option allows users to specify which data partitions will be erased when the factory reset is executed.
|
||||
|
||||
Can specify the names of partitions as a comma-delimited list with optional spaces for readability. (Like this: ``nvs, phy_init, nvs_custom``).
|
||||
Users can specify the names of partitions as a comma-delimited list with optional spaces for readability. (Like this: ``nvs, phy_init, nvs_custom``).
|
||||
|
||||
Make sure that the names of partitions specified in the partition table and here are the same. Partitions of type "app" cannot be specified here.
|
||||
Make sure that the names of partitions specified in the option are the same as those found in the partition table. Partitions of type "app" cannot be specified here.
|
||||
|
||||
- Boot from "factory" app partition. :ref:`CONFIG_BOOTLOADER_OTA_DATA_ERASE` - the device will boot from the default "factory" app partition (or if there is no factory app partition in the partition table then the default ota app partition) after a factory reset. This is done by erasing the OTA data partition which holds the currently selected OTA partition slot. The "factory" app partition slot (if it exists) is never updated via OTA, so resetting to this allows reverting to a "known good" firmware application.
|
||||
- Boot from "factory" app partition. Enabling the :ref:`CONFIG_BOOTLOADER_OTA_DATA_ERASE` option will cause the device to boot from the default "factory" app partition after a factory reset (or if there is no factory app partition in the partition table then the default ota app partition is selected instead). This reset process involves erasing the OTA data partition which holds the currently selected OTA partition slot. The "factory" app partition slot (if it exists) is never updated via OTA, so resetting to this allows reverting to a "known good" firmware application.
|
||||
|
||||
Either or both of these configuration options can be enabled independently.
|
||||
|
||||
In addition, the following configuration options control the reset condition:
|
||||
|
||||
- :ref:`CONFIG_BOOTLOADER_NUM_PIN_FACTORY_RESET`- number of the GPIO input for factory reset uses to trigger a factory reset, this GPIO must be pulled low or high (configurable) on reset to trigger this.
|
||||
- :ref:`CONFIG_BOOTLOADER_NUM_PIN_FACTORY_RESET`- The input GPIO number used to trigger a factory reset. This GPIO must be pulled low or high (configurable) on reset to trigger this.
|
||||
|
||||
- :ref:`CONFIG_BOOTLOADER_HOLD_TIME_GPIO`- this is hold time of GPIO for reset/test mode (by default 5 seconds). The GPIO must be held continuously for this period of time after reset before a factory reset or test partition boot (as applicable) is performed.
|
||||
|
||||
|
|
@ -90,6 +90,7 @@ In addition, the following configuration options control the reset condition:
|
|||
|
||||
Boot from Test Firmware
|
||||
------------------------
|
||||
|
||||
It's possible to write a special firmware app for testing in production, and boot this firmware when needed. The project partition table will need a dedicated app partition entry for this testing app, type ``app`` and subtype ``test`` (see :doc:`/api-guides/partition-tables`).
|
||||
|
||||
Implementing a dedicated test app firmware requires creating a totally separate ESP-IDF project for the test app (each project in ESP-IDF only builds one app). The test app can be developed and tested independently of the main project, and then integrated at production testing time as a pre-compiled .bin file which is flashed to the address of the main project's test app partition.
|
||||
|
|
@ -98,7 +99,7 @@ To support this functionality in the main project's bootloader, set the configur
|
|||
|
||||
- :ref:`CONFIG_BOOTLOADER_NUM_PIN_APP_TEST` - GPIO number to boot TEST partition. The selected GPIO will be configured as an input with internal pull-up enabled. To trigger a test app, this GPIO must be pulled low on reset.
|
||||
|
||||
After the GPIO input is deactivated and the device reboots, the normally configured application will boot (factory or any OTA app partition slot).
|
||||
Once the GPIO input is released (allowing it to be pulled up) and the device has been reboot, the normally configured application will boot (factory or any OTA app partition slot).
|
||||
|
||||
- :ref:`CONFIG_BOOTLOADER_HOLD_TIME_GPIO` - this is hold time of GPIO for reset/test mode (by default 5 seconds). The GPIO must be held low continuously for this period of time after reset before a factory reset or test partition boot (as applicable) is performed.
|
||||
|
||||
|
|
@ -115,7 +116,7 @@ Watchdog
|
|||
By default, the hardware RTC Watchdog timer remains running while the bootloader is running and will automatically reset the chip if no app has successfully started after 9 seconds.
|
||||
|
||||
- The timeout period can be adjusted by setting :ref:`CONFIG_BOOTLOADER_WDT_TIME_MS` and recompiling the bootloader.
|
||||
- The app's behaviour can be adjusted so the RTC Watchdog remains enabled after app startup. The Watchdog would need to be explicitly reset or "fed" by the app to avoid a reset. To do this, set the :ref:`CONFIG_BOOTLOADER_WDT_DISABLE_IN_USER_CODE` option, modify the app as needed, and then recompile the app.
|
||||
- The app's behaviour can be adjusted so the RTC Watchdog remains enabled after app startup. The Watchdog would need to be explicitly reset (i.e., fed) by the app to avoid a reset. To do this, set the :ref:`CONFIG_BOOTLOADER_WDT_DISABLE_IN_USER_CODE` option, modify the app as needed, and then recompile the app.
|
||||
- The RTC Watchdog can be disabled in the bootloader by disabling the :ref:`CONFIG_BOOTLOADER_WDT_ENABLE` setting and recompiling the bootloader. This is not recommended.
|
||||
|
||||
.. _bootloader-size:
|
||||
|
|
@ -144,18 +145,17 @@ Options to work around this are:
|
|||
- Reduce :ref:`bootloader log level <CONFIG_BOOTLOADER_LOG_LEVEL>`. Setting log level to Warning, Error or None all significantly reduce the final binary size (but may make it harder to debug).
|
||||
- Set :ref:`CONFIG_PARTITION_TABLE_OFFSET` to a higher value than 0x8000, to place the partition table later in the flash. This increases the space available for the bootloader. If the :doc:`partition table </api-guides/partition-tables>` CSV file contains explicit partition offsets, they will need changing so no partition has an offset lower than ``CONFIG_PARTITION_TABLE_OFFSET + 0x1000``. (This includes the default partition CSV files supplied with ESP-IDF.)
|
||||
|
||||
When Secure Boot V2 is enabled, there is also an absolute binary size limit of {IDF_TARGET_MAX_BOOTLOADER_SIZE} (excluding the 4KB signature), because the bootloader is first loaded into a fixed size buffer for verification.
|
||||
When Secure Boot V2 is enabled, there is also an absolute binary size limit of {IDF_TARGET_MAX_BOOTLOADER_SIZE} (excluding the 4 KB signature), because the bootloader is first loaded into a fixed size buffer for verification.
|
||||
|
||||
Fast boot from Deep Sleep
|
||||
-------------------------
|
||||
|
||||
The bootloader has the :ref:`CONFIG_BOOTLOADER_SKIP_VALIDATE_IN_DEEP_SLEEP` option which allows to reduce the wake-up time (useful to reduce consumption). This option is available when :ref:`CONFIG_SECURE_BOOT` option is disabled. Reduction of time is achieved due to the lack of image verification. During the first boot, the bootloader stores the address of the application being launched in the RTC FAST memory. And during the awakening, this address is used for booting without any checks, thus fast loading is achieved.
|
||||
The bootloader has the :ref:`CONFIG_BOOTLOADER_SKIP_VALIDATE_IN_DEEP_SLEEP` option which allows the wake-up time from deep sleep to be reduced (useful for reducing power consumption). This option is available when :ref:`CONFIG_SECURE_BOOT` option is disabled. Reduction of time is achieved due to the lack of image verification. During the first boot, the bootloader stores the address of the application being launched in the RTC FAST memory. And during the awakening, this address is used for booting without any checks, thus fast loading is achieved.
|
||||
|
||||
Custom bootloader
|
||||
-----------------
|
||||
|
||||
The current bootloader implementation allows a project to extend it or modify it. There are two ways of doing it: by implementing hooks or by overriding it.
|
||||
Both ways are presented in :example:`custom_bootloader` folder in ESP-IDF examples:
|
||||
The current bootloader implementation allows a project to extend it or modify it. There are two ways of doing it: by implementing hooks or by overriding it. Both ways are presented in :example:`custom_bootloader` folder in ESP-IDF examples:
|
||||
|
||||
* `bootloader_hooks` which presents how to connect some hooks to the bootloader initialization
|
||||
* `bootloader_override` which presents how to override the bootloader implementation
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ Here is the summary printed for the "Single factory app, no OTA" configuration::
|
|||
phy_init, data, phy, 0xf000, 0x1000,
|
||||
factory, app, factory, 0x10000, 1M,
|
||||
|
||||
* At a 0x10000 (64KB) offset in the flash is the app labelled "factory". The bootloader will run this app by default.
|
||||
* At a 0x10000 (64 KB) offset in the flash is the app labelled "factory". The bootloader will run this app by default.
|
||||
* There are also two data regions defined in the partition table for storing NVS library partition and PHY init data.
|
||||
|
||||
Here is the summary printed for the "Factory app, two OTA definitions" configuration::
|
||||
|
|
@ -99,7 +99,7 @@ See enum :cpp:type:`esp_partition_subtype_t` for the full list of subtypes defin
|
|||
|
||||
- OTA never updates the factory partition.
|
||||
- If you want to conserve flash usage in an OTA project, you can remove the factory partition and use ``ota_0`` instead.
|
||||
|
||||
|
||||
- ``ota_0`` (0x10) ... ``ota_15`` (0x1F) are the OTA app slots. When :doc:`OTA <../api-reference/system/ota>` is in use, the OTA data partition configures which app slot the bootloader should boot. When using OTA, an application should have at least two OTA application slots (``ota_0`` & ``ota_1``). Refer to the :doc:`OTA documentation <../api-reference/system/ota>` for more details.
|
||||
- ``test`` (0x20) is a reserved subtype for factory test procedures. It will be used as the fallback boot partition if no other valid app partition is found. It is also possible to configure the bootloader to read a GPIO input during each boot, and boot this partition if the GPIO is held low, see :ref:`bootloader_boot_from_test_firmware`.
|
||||
|
||||
|
|
@ -176,7 +176,7 @@ The ESP-IDF build system will automatically check if generated binaries fit in t
|
|||
|
||||
Currently these checks are performed for the following binaries:
|
||||
|
||||
* Bootloader binary must fit in space before partition table (see :ref:`bootloader-size`)
|
||||
* Bootloader binary must fit in space before partition table (see :ref:`bootloader-size`).
|
||||
* App binary should fit in at least one partition of type "app". If the app binary doesn't fit in any app partition, the build will fail. If it only fits in some of the app partitions, a warning is printed about this.
|
||||
|
||||
.. note::
|
||||
|
|
|
|||
|
|
@ -201,4 +201,3 @@ API Reference
|
|||
|
||||
.. include-build-file:: inc/ledc.inc
|
||||
.. include-build-file:: inc/ledc_types.inc
|
||||
|
||||
|
|
|
|||
|
|
@ -1,14 +1,20 @@
|
|||
引导加载程序（Bootloader）
|
||||
引导加载程序 (Bootloader)
|
||||
==========================
|
||||
|
||||
:link_to_translation:`en:[English]`
|
||||
|
||||
引导加载程序（Bootloader）主要执行以下任务：
|
||||
{IDF_TARGET_BOOTLOADER_OFFSET:default="0x0", esp32="0x1000", esp32s2="0x1000"}
|
||||
|
||||
ESP-IDF 软件引导加载程序 (Bootloader) 主要执行以下任务：
|
||||
|
||||
1. 内部模块的最小化初始配置；
|
||||
2. 根据分区表和 ota_data（如果存在）选择需要引导的应用程序（app）分区；
|
||||
3. 将此应用程序映像加载到 RAM（IRAM 和 DRAM）中，最后把控制权转交给应用程序。
|
||||
2. 如果配置了 :doc:`/security/flash-encryption` 和/或 :doc:`Secure </security/secure-boot-v2>`，则对其进行初始化。
|
||||
3. 根据分区表和 ota_data（如果存在）选择需要引导的应用程序 (app) 分区；
|
||||
4. 将此应用程序镜像加载到 RAM（IRAM 和 DRAM）中，最后把控制权转交给此应用程序。
|
||||
|
||||
引导加载程序位于 Flash 的 `0x1000` 偏移地址处。
|
||||
引导加载程序位于 flash 的 {IDF_TARGET_BOOTLOADER_OFFSET} 偏移地址处。
|
||||
|
||||
关于启动过程以及 ESP-IDF 引导加载程序的更多信息，请参考 :doc:`startup`。
|
||||
|
||||
.. _bootloader-compatibility:
|
||||
|
||||
|
|
@ -19,87 +25,143 @@
|
|||
|
||||
但不支持引导从 ESP-IDF 旧版本中构建的程序。如果现有产品可能需要将应用程序降级到旧版本，那么在手动更新 ESP-IDF 时，请继续使用旧版本 ESP-IDF 引导加载程序的二进制文件。
|
||||
|
||||
.. note::
|
||||
|
||||
如果在生产中测试现有产品的 OTA 更新，请确保测试中使用的 ESP-IDF 引导加载程序二进制文件与生产中部署的相同。
|
||||
|
||||
.. only:: esp32
|
||||
|
||||
ESP-IDF V2.1 之前的版本
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
与新版本相比，ESP-IDF V2.1 之前的版本构建的引导加载程序对硬件的配置更少。使用这些早期 ESP-IDF 版本的引导加载程序并构建新应用程序时，请启用配置选项 :ref:`CONFIG_ESP32_COMPATIBLE_PRE_V2_1_BOOTLOADERS`。
|
||||
|
||||
ESP-IDF V3.1 之前的版本
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
ESP-IDF V3.1 之前的版本构建的引导加载程序不支持分区表二进制文件中的 MD5 校验。使用这些 ESP-IDF 版本的引导加载程序并构建新应用程序时，请启用配置选项 :ref:`CONFIG_ESP32_COMPATIBLE_PRE_V3_1_BOOTLOADERS`。
|
||||
|
||||
配置 SPI Flash
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
每个 ESP-IDF 应用程序或引导加载程序的二进制文件中都包含一个文件头，其中内置了 :ref:`CONFIG_ESPTOOLPY_FLASHMODE`、:ref:`CONFIG_ESPTOOLPY_FLASHFREQ`、和 :ref:`CONFIG_ESPTOOLPY_FLASHSIZE`。这些是用于在启动时配置 SPI flash。
|
||||
|
||||
ROM 中的 :ref:`first-stage-bootloader` 从 flash 中读取 :ref:`second-stage-bootloader` 文件头中的配置信息，并使用这些信息来加载剩余的 :ref:`second-stage-bootloader`。然而，此时系统的时钟速度低于其被配置的速度，并且在这个阶段，只支持部分 flash 模式。因此，当 :ref:`second-stage-bootloader` 运行时，它会从当前应用程序的二进制文件头中读取数据（而不是从引导加载程序的文件头中读取数据），并使用这些数据重新配置 flash。这样的配置流程可让 OTA 更新去更改当前使用的 SPI flash 的配置。
|
||||
|
||||
.. only:: esp32
|
||||
|
||||
ESP-IDF V4.0 版本之前的引导加载程序使用其自身的文件头来配置 SPI flash，这意味着无法在 OTA 更新时更改 SPI flash 配置。为了与旧引导加载程序兼容，应用程序在其启动期间使用应用程序文件头中的配置信息重新初始化 flash 配置。
|
||||
|
||||
日志级别
|
||||
---------
|
||||
|
||||
引导加载程序日志的级别默认为 "Info"。通过设置 :ref:`CONFIG_BOOTLOADER_LOG_LEVEL` 选项，可以增加或减少这个等级。这个日志级别与应用程序中使用的日志级别是分开的（见 :doc:`/api-reference/system/log`）。
|
||||
|
||||
降低引导加载程序日志的详细程度可以稍微缩短整个项目的启动时间。
|
||||
|
||||
恢复出厂设置
|
||||
------------
|
||||
用户可以编写一个基本的工作固件，然后将其加载到工厂分区（factory）中。
|
||||
|
||||
接下来，通过 OTA（空中升级）更新固件，更新后的固件会被保存到某个 OTA app 分区中，OTA 数据分区也会做相应更新以指示从该分区引导应用程序。
|
||||
在更新出现问题时，最好能有一种方法让设备回到已知的正常状态，这时可选择恢复出厂设置。
|
||||
|
||||
如果你希望回滚到出厂固件并清除设置，则需要设置 :ref:`CONFIG_BOOTLOADER_FACTORY_RESET`。出厂重置机制允许将设备重置为出厂模式：
|
||||
要回到原始出厂设置并清除所有用户设置，请在引导加载程序中配置 :ref:`CONFIG_BOOTLOADER_FACTORY_RESET`。
|
||||
|
||||
- 清除一个或多个数据分区。
|
||||
- 从工厂分区启动。
|
||||
以下两种方式可以将设备恢复出厂设置。
|
||||
|
||||
:ref:`CONFIG_BOOTLOADER_DATA_FACTORY_RESET` - 允许用户选择在恢复出厂设置时需要擦除的数据分区。可以通过逗号来分隔多个分区的名字，并适当增加空格以便阅读（例如 "nvs, phy_init, nvs_custom, ..."）。请确保此处指定的名称和分区表中的名称相同，且不含有 “app” 类型的分区。
|
||||
- 清除一个或多个数据分区。:ref:`CONFIG_BOOTLOADER_DATA_FACTORY_RESET` 选项允许用户选择哪些数据分区在恢复出厂设置时需要被擦除。
|
||||
|
||||
:ref:`CONFIG_BOOTLOADER_OTA_DATA_ERASE` - 恢复出厂模式后，设备会从工厂分区启动，OTA 数据分区会被清除。
|
||||
用户可以使用以逗号分隔的列表形式指定分区的名称，为了提高可读性，可以选择添加空格（如：``nvs, phy_init, nvs_custom``）。
|
||||
|
||||
:ref:`CONFIG_BOOTLOADER_NUM_PIN_FACTORY_RESET`- 设置用于触发出厂重置的 GPIO 编号，必须在芯片复位时将此 GPIO 拉低才能触发出厂重置事件。
|
||||
请确保选项里指定的分区名称和分区表中的名称相同。此处不能指定 “app” 类型的分区。
|
||||
|
||||
:ref:`CONFIG_BOOTLOADER_HOLD_TIME_GPIO`- 设置进入重置或测试模式所需要的保持时间（默认为 5 秒）。设备复位后，GPIO 必须在这段时间内持续保持低电平，然后才会执行出厂重置或引导测试分区。
|
||||
- 从“工厂”应用分区启动。当启用 :ref:`CONFIG_BOOTLOADER_OTA_DATA_ERASE` 选项，恢复出厂设置后，设备将从默认的“工厂”应用分区启动（如果分区表中没有“工厂”应用分区，则从默认的 OTA 应用分区启动）。这个恢复过程是通过擦除 OTA 数据分区来完成的，OTA 数据分区中保存了当前选择的 OTA 分区槽。“工厂”应用分区槽（如果存在）永远不会通过 OTA 更新，因此重置为从“工厂”应用分区启动则意味着让固件应用程序恢复正常状态。
|
||||
|
||||
示例分区表如下::
|
||||
这两个配置选项都可以独立启用。
|
||||
|
||||
# Name, Type, SubType, Offset, Size, Flags
|
||||
# 注意，如果你增大了引导加载程序的大小，请确保更新偏移量，避免和其它分区发生重叠
|
||||
nvs, data, nvs, 0x9000, 0x4000
|
||||
otadata, data, ota, 0xd000, 0x2000
|
||||
phy_init, data, phy, 0xf000, 0x1000
|
||||
factory, 0, 0, 0x10000, 1M
|
||||
test, 0, test, , 512K
|
||||
ota_0, 0, ota_0, , 512K
|
||||
ota_1, 0, ota_1, , 512K
|
||||
此外，以下配置选项用于配置触发恢复出厂设置的条件：
|
||||
|
||||
- :ref:`CONFIG_BOOTLOADER_NUM_PIN_FACTORY_RESET`- 输入管脚 (GPIO) 的编号，该管脚用于触发恢复出厂设置。必须在重置时将此管脚拉低或拉高（可配置）才能触发出厂重置事件。
|
||||
|
||||
- :ref:`CONFIG_BOOTLOADER_HOLD_TIME_GPIO`- 管脚电平保持时间（默认为 5 秒）。设备重置后，管脚电平必须保持该设定的时间，才能执行恢复出厂设置或引导测试分区（如适用）。
|
||||
|
||||
- :ref:`CONFIG_BOOTLOADER_FACTORY_RESET_PIN_LEVEL` - 设置管脚电平高低。设备重置后，根据此设置将管脚拉高或拉低，才能触发出厂重置事件。如果管脚具有内部上拉，则上拉会在管脚采样前生效。有关管脚内部上拉的详细信息，请参考 {IDF_TARGET_NAME} 的技术规格书。
|
||||
|
||||
.. _bootloader_boot_from_test_firmware:
|
||||
|
||||
从测试应用程序分区启动
|
||||
------------------------
|
||||
用户可以编写特殊固件用于生产环境中测试，然后在需要的时候运行。此时需要在分区表中专门申请一块分区用于保存该测试固件（详情请参阅 :doc:`分区表 <partition-tables>`）。如果想要触发测试固件，还需要设置 :ref:`CONFIG_BOOTLOADER_APP_TEST`。
|
||||
从测试固件启动
|
||||
-------------------
|
||||
|
||||
:ref:`CONFIG_BOOTLOADER_NUM_PIN_APP_TEST` - 设置引导测试分区的 GPIO 管脚编号，该 GPIO 会被配置为输入模式，并且会使能内部上拉电阻。若想触发测试固件，该 GPIO 必须在芯片复位时拉低。设备重启时如果该 GPIO 没有被激活（即处于高电平状态），那么会加载常规配置的应用程序（可能位于工厂分区或者 OTA 分区）。
|
||||
用户可以编写特殊固件用于生产环境中测试，并在需要的时候运行。此时需要在项目分区表中专门申请一块分区用于保存该测试固件，其类型为 app，子类型为 test（详情请参考 :doc:`/api-guides/partition-tables`）。
|
||||
|
||||
:ref:`CONFIG_BOOTLOADER_HOLD_TIME_GPIO` - 设置进入重置或测试模式所需要的保持时间（默认为 5 秒）。设备复位后，GPIO 必须在这段时间内持续保持低电平，然后才会执行出厂重置或引导测试分区。
|
||||
实现该测试应用固件需要为测试应用创建一个完全独立的 ESP-IDF 项目（ESP-IDF 中的每个项目仅构建一个应用）。该测试应用可以独立于主项目进行开发和测试，然后在生成测试时作为一个预编译 .bin 文件集成到主项目的测试应用程序分区的地址。
|
||||
|
||||
为了使主项目的引导加载程序支持这个功能，请设置 :ref:`CONFIG_BOOTLOADER_APP_TEST` 并配置以下两个选项：
|
||||
|
||||
- :ref:`CONFIG_BOOTLOADER_NUM_PIN_APP_TEST` - 设置启动 TEST 分区的管脚编号。选中的管脚将被配置为启用了内部上拉的输入。要触发测试应用，必须在重置时将此管脚 拉低。
|
||||
|
||||
当管脚输入被释放（则被拉高）并将设备重新启动后，正常配置的应用程序将启动（工厂或任意 OTA 应用分区槽）。
|
||||
|
||||
- :ref:`CONFIG_BOOTLOADER_HOLD_TIME_GPIO` - 设置 GPIO 电平保持的时间（默认为 5 秒）。设备重置后，管脚在设定的时间内必须持续保持低电平，然后才会执行出厂重置或引导测试分区（如适用）。
|
||||
|
||||
回滚
|
||||
--------
|
||||
|
||||
回滚和反回滚功能也必须在引导程序中配置。
|
||||
|
||||
请参考 :doc:`OTA API 参考文档 </api-reference/system/ota>` 中的 :ref:`app_rollback` 和 :ref:`anti-rollback` 章节。
|
||||
|
||||
看门狗
|
||||
----------
|
||||
|
||||
默认情况下，硬件 RTC 看门狗定时器在引导加载程序运行时保持运行，如果 9 秒后没有应用程序成功启动，它将自动重置芯片。
|
||||
|
||||
- 可以通过设置 :ref:`CONFIG_BOOTLOADER_WDT_TIME_MS` 并重新编译引导加载程序来调整超时时间。
|
||||
- 可以通过调整应用程序的行为使 RTC 看门狗在应用程序启动后保持启用。看门狗需要由应用程序显示地重置（即“喂狗”），以避免重置。为此，请设置 :ref:`CONFIG_BOOTLOADER_WDT_DISABLE_IN_USER_CODE` 选项，根据需要修改应用程序，然后重新编译应用程序。
|
||||
- 通过禁用 :ref:`CONFIG_BOOTLOADER_WDT_ENABLE` 设置并重新编译引导加载程序，可以在引导加载程序中禁用 RTC 看门狗，但并不建议这样做。
|
||||
|
||||
.. _bootloader-size:
|
||||
|
||||
Bootloader Size
|
||||
---------------
|
||||
引导加载程序大小
|
||||
---------------------
|
||||
|
||||
{IDF_TARGET_DEFAULT_MAX_BOOTLOADER_SIZE:default = "0x8000 (32768)", esp32 = "0x7000 (28672)", esp32s2 = "0x7000 (28672)"}
|
||||
{IDF_TARGET_MAX_BOOTLOADER_SIZE:default = "64KB (0x10000 bytes)", esp32 = "48KB (0xC000 bytes)"}
|
||||
{IDF_TARGET_MAX_PARTITION_TABLE_OFFSET:default = "0x12000", esp32 = "0xE000"}
|
||||
.. Above is calculated as 0x1000 at start of flash + IDF_TARGET_MAX_BOOTLOADER_SIZE + 0x1000 signature sector
|
||||
|
||||
When enabling additional bootloader functions, including :doc:`/security/flash-encryption` or Secure Boot, and especially if setting a high :ref:`CONFIG_BOOTLOADER_LOG_LEVEL` level, then it is important to monitor the bootloader .bin file's size.
|
||||
当需要启用额外的引导加载程序功能，包括 :doc:`/security/flash-encryption` 或安全启动，尤其是设置高级别 :ref:`CONFIG_BOOTLOADER_LOG_LEVEL` 时，监控引导加载程序 .bin 文件的大小变得非常重要。
|
||||
|
||||
When using the default :ref:`CONFIG_PARTITION_TABLE_OFFSET` value 0x8000, the size limit is {IDF_TARGET_DEFAULT_MAX_BOOTLOADER_SIZE} bytes.
|
||||
当使用默认的 :ref:`CONFIG_PARTITION_TABLE_OFFSET` 值 0x8000 时，二进制文件最大可为 {IDF_TARGET_DEFAULT_MAX_BOOTLOADER_SIZE} 字节。
|
||||
|
||||
If the bootloader binary is too large, then the bootloader build will fail with an error "Bootloader binary size [..] is too large for partition table offset". If the bootloader binary is flashed anyhow then the {IDF_TARGET_NAME} will fail to boot - errors will be logged about either invalid partition table or invalid bootloader checksum.
|
||||
如果引导加载程序二进制文件过大，则引导加载程序会构建将失败并显示 "Bootloader binary size [..] is too large for partition table offset" 的错误。如果此二进制文件已经被烧录，那么 {IDF_TARGET_NAME} 将无法启动 - 日志中将记录无效分区表或无效引导加载程序校验和的错误。
|
||||
|
||||
.. note::
|
||||
|
||||
The bootloader size check only happens in the CMake Build System, when using the legacy GNU Make Build System the size is not checked but the {IDF_TARGET_NAME} will fail to boot if bootloader is too large.
|
||||
对引导加载程序大小检查仅发生在 CMake 构建系统中，若使用的是旧版 GNU Make 构建系统，则不会检查大小，但如果引导加载程序太大，{IDF_TARGET_NAME} 将无法启动。
|
||||
|
||||
Options to work around this are:
|
||||
可以使用如下方法解决此问题：
|
||||
|
||||
- Set :ref:`bootloader compiler optimization <CONFIG_BOOTLOADER_COMPILER_OPTIMIZATION>` back to "Size" if it has been changed from this default value.
|
||||
- Reduce :ref:`bootloader log level <CONFIG_BOOTLOADER_LOG_LEVEL>`. Setting log level to Warning, Error or None all significantly reduce the final binary size (but may make it harder to debug).
|
||||
- Set :ref:`CONFIG_PARTITION_TABLE_OFFSET` to a higher value than 0x8000, to place the partition table later in the flash. This increases the space available for the bootloader. If the :doc:`partition table </api-guides/partition-tables>` CSV file contains explicit partition offsets, they will need changing so no partition has an offset lower than ``CONFIG_PARTITION_TABLE_OFFSET + 0x1000``. (This includes the default partition CSV files supplied with ESP-IDF.)
|
||||
- 将 :ref:`bootloader 编译器优化 <CONFIG_BOOTLOADER_COMPILER_OPTIMIZATION>` 重新设置回默认值“Size”。
|
||||
- 降低 :ref:`引导加载程序日志级别 <CONFIG_BOOTLOADER_LOG_LEVEL>`。将日志级别设置为 Warning, Error 或 None 都会显著减少最终二进制文件的大小（但也可能会让调试变得更加困难）。
|
||||
- 将 :ref:`CONFIG_PARTITION_TABLE_OFFSET` 设置为高于 0x8000 的值，以便稍后将分区表放置在 flash 中，这样可以增加引导加载程序的可用空间。如果 :doc:`分区表 </api-guides/partition-tables>` 的 CSV 文件包含明确的分区偏移量，则需要修改这些偏移量，从而保证没有分区的偏移量低于 ``CONFIG_PARTITION_TABLE_OFFSET + 0x1000``。（这包括随 ESP-IDF 提供的默认分区 CSV 文件）
|
||||
|
||||
When Secure Boot V2 is enabled, there is also an absolute binary size limit of {IDF_TARGET_MAX_BOOTLOADER_SIZE} (excluding the 4KB signature), because the bootloader is first loaded into a fixed size buffer for verification.
|
||||
当启用 Secure Boot V2 时，由于引导加载程序最先加载到固定大小的缓冲区中进行验证，对二进制文件大小的绝对限制为 {IDF_TARGET_MAX_BOOTLOADER_SIZE}（不包括 4 KB 签名）。
|
||||
|
||||
从深度睡眠中快速启动
|
||||
----------------------
|
||||
引导加载程序有 :ref:`CONFIG_BOOTLOADER_SKIP_VALIDATE_IN_DEEP_SLEEP` 选项，可以减少唤醒时间（有利于降低消耗）。当 :ref:`CONFIG_SECURE_BOOT` 选项禁用时，该选项可用。由于无需固件校验，唤醒时间减少。在第一次启动时，引导加载程序将启动的应用程序的地址存储在 RTC FAST 存储器中。而在唤醒过程中，这个地址用于启动而无需任何检查，从而实现了快速加载。
|
||||
|
||||
自定义引导程序
|
||||
--------------
|
||||
用户可以重写当前的引导加载程序，具体做法是，复制 `/esp-idf/components/bootloader` 文件夹到项目组件目录中，然后编辑 ``/your_project/components/bootloader/subproject/main/bootloader_start.c`` 文件。
|
||||
引导加载程序有 :ref:`CONFIG_BOOTLOADER_SKIP_VALIDATE_IN_DEEP_SLEEP` 选项，可以减少从深度睡眠中唤醒的时间（有利于降低功耗）。当 :ref:`CONFIG_SECURE_BOOT` 选项禁用时，该选项可用。由于无需镜像校验，唤醒时间减少。在第一次启动时，引导加载程序将启动的应用程序的地址存储在 RTC FAST 存储器中。而在唤醒过程中，这个地址用于启动而无需任何检查，从而实现了快速加载。
|
||||
|
||||
在引导加载程序的代码中，用户不能使用其他组件提供的驱动和函数，如果确实需要，请将该功能的实现部分放在项目的 bootloader 目录中（注意，这会增加引导程序的大小）。
|
||||
自定义引导加载程序
|
||||
----------------------
|
||||
|
||||
如果引导程序过大，则可能与内存中的分区表重叠，分区表默认烧录在
|
||||
偏移量 0x8000 处。增加 :ref:`分区表偏移量值 <CONFIG_PARTITION_TABLE_OFFSET>` ，将分区表放在 flash 中靠后的区域，这样可以增加引导程序的可用空间。
|
||||
用户可以扩展或修改当前的引导加载程序，具体有两种方法：使用钩子实现或重写覆盖当前程序。这两种方法在 ESP-IDF 示例的 :example:`custom_bootloader` 文件夹中都有呈现。
|
||||
|
||||
.. note:: 初次将引导程序复制到现有项目中时，由于路径发生了意外变化，项目可能无法构建。对于这种情况，请运行 ``idf.py fullclean`` （或删除项目构建目录），然后重新构建。
|
||||
* `bootloader_hooks` 介绍了如何将钩子与引导加载程序初始化连接。
|
||||
* `bootloader_override` 介绍了如何覆盖引导加载程序的实现。
|
||||
|
||||
在引导加载程序的代码中，用户不能使用其他组件提供的驱动和函数，如果确实需要，请将该功能的实现部分放在项目的 `bootloader_components` 目录中（注意，这会增加引导加载程序的大小）。
|
||||
|
||||
如果引导加载程序过大，则可能与内存中的分区表重叠，分区表默认烧录在偏移量 0x8000 处。增加 :ref:`分区表偏移量 <CONFIG_PARTITION_TABLE_OFFSET>` ，将分区表放在 flash 中靠后的区域，这样可以增加引导程序的可用空间。
|
||||
|
||||
.. note:: 上述任意一种自定义引导程序的方法都需要使用 CMake 构建系统（即不支持传统的 Make 构建系统）。
|
||||
|
|
|
|||
|
|
@ -96,7 +96,7 @@ SubType 字段长度为 8 bit，内容与具体分区 Type 有关。目前，esp
|
|||
* 当 Type 定义为 ``app`` 时，SubType 字段可以指定为 ``factory`` (0x00)、 ``ota_0`` (0x10) … ``ota_15`` (0x1F) 或者 ``test`` (0x20)。
|
||||
|
||||
- ``factory`` (0x00) 是默认的 app 分区。启动加载器将默认加载该应用程序。但如果存在类型为 data/ota 分区，则启动加载器将加载 data/ota 分区中的数据，进而判断启动哪个 OTA 镜像文件。
|
||||
|
||||
|
||||
- OTA 升级永远都不会更新 factory 分区中的内容。
|
||||
- 如果您希望在 OTA 项目中预留更多 flash，可以删除 factory 分区，转而使用 ota_0 分区。
|
||||
|
||||
|
|
@ -169,12 +169,37 @@ Flags 字段
|
|||
|
||||
python gen_esp32part.py binary_partitions.bin
|
||||
|
||||
分区大小检查
|
||||
---------------------
|
||||
|
||||
ESP-IDF 构建系统将自动检查生成的二进制文件大小与可用的分区大小是否匹配，如果二进制文件太大，则会构建失败并报错。
|
||||
|
||||
目前会对以下二进制文件进行检查：
|
||||
|
||||
* 引导加载程序的二进制文件的大小要适合分区表前的区域大小（分区表前的区域都分配给了引导加载程序），具体请参考 :ref:`bootloader-size`。
|
||||
* 应用程序二进制文件应至少适合一个 “app" 类型的分区。如果不适合任何应用程序分区，则会构建失败。如果只适合某些应用程序分区，则会打印相关警告。
|
||||
|
||||
.. note::
|
||||
|
||||
即使分区大小检查返回错误并导致构建失败，仍然会生成可以烧录的二进制文件（它们对于可用空间来说过大，因此无法正常工作）。
|
||||
|
||||
.. note::
|
||||
|
||||
只有在使用 CMake 构建系统时才会对构建系统二进制文件大小进行检查。如果使用传统的 GNU Make 构建系统时，则可以手动检查文件大小，或在启动时会产生错误记录。
|
||||
|
||||
MD5 校验和
|
||||
~~~~~~~~~~
|
||||
|
||||
二进制格式的分区表中含有一个 MD5 校验和。这个 MD5 校验和是根据分区表内容计算的，可在设备启动阶段，用于验证分区表的完整性。
|
||||
|
||||
注意，一些版本较老的启动加载器无法支持 MD5 校验，如果发现 MD5 校验和则将报错 ``invalid magic number 0xebeb``。此时，用户可通过 ``gen_esp32part.py`` 的 ``--disable-md5sum`` 选项或者 :ref:`CONFIG_PARTITION_TABLE_MD5` 选项关闭 MD5 校验。
|
||||
.. only:: esp32
|
||||
|
||||
用户可通过 ``gen_esp32part.py`` 的 ``--disable-md5sum`` 选项或者 :ref:`CONFIG_PARTITION_TABLE_MD5` 选项关闭 MD5 校验。对于 :ref:`ESP-IDF v3.1 版本前的引导加载程序 <CONFIG_ESP32_COMPATIBLE_PRE_V3_1_BOOTLOADERS>`，因为它不支持 MD5 校验，所以无法正常启动并报错 ``invalid magic number 0xebeb``，此时用户可以使用此选项关闭 MD5 校验。
|
||||
|
||||
.. only:: not esp32
|
||||
|
||||
用户可通过 ``gen_esp32part.py`` 的 ``--disable-md5sum`` 选项或者 :ref:`CONFIG_PARTITION_TABLE_MD5` 选项关闭 MD5 校验。
|
||||
|
||||
|
||||
烧写分区表
|
||||
----------
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ I2C 具有简单且制造成本低廉等优点，主要用于低速外围设备
|
|||
驱动程序的功能
|
||||
---------------
|
||||
|
||||
I2C 驱动程序管理在 I2C 总线上设备的通信，该驱动程序具备以下功能：
|
||||
I2C 驱动程序管理在 I2C 总线上设备的通信，该驱动程序具备以下功能：
|
||||
|
||||
- 在主机模式下读写字节
|
||||
- 支持从机模式
|
||||
|
|
@ -37,7 +37,7 @@ I2C 驱动程序管理在 I2C 总线上设备的通信，该驱动程序具备
|
|||
2. :ref:`i2c-api-install-driver`- 激活一个 I2C 控制器的驱动，该控制器可为主机也可为从机
|
||||
3. 根据是为主机还是从机配置驱动程序，选择合适的项目
|
||||
|
||||
a) :ref:`i2c-api-master-mode` - 发起通信（主机模式）
|
||||
a) :ref:`i2c-api-master-mode` - 发起通信（主机模式）
|
||||
b) :ref:`i2c-api-slave-mode` - 响应主机消息（从机模式）
|
||||
|
||||
4. :ref:`i2c-api-interrupt-handling` - 配置 I2C 中断服务
|
||||
|
|
@ -148,6 +148,25 @@ I2C 驱动程序管理在 I2C 总线上设备的通信，该驱动程序具备
|
|||
1. :c:macro:`I2C_SCLK_SRC_FLAG_AWARE_DFS`：当 APB 时钟改变时，时钟的波特率不会改变。
|
||||
2. :c:macro:`I2C_SCLK_SRC_FLAG_LIGHT_SLEEP`：支持轻度睡眠模式，APB 时钟则不支持。
|
||||
|
||||
.. only:: esp32s3
|
||||
|
||||
.. list-table:: {IDF_TARGET_NAME} 时钟源特性
|
||||
:widths: 5 5 50 20
|
||||
:header-rows: 1
|
||||
|
||||
* - 时钟名称
|
||||
- 时钟频率
|
||||
- SCL 的最大频率
|
||||
- 时钟功能
|
||||
* - XTAL 时钟
|
||||
- 40 MHz
|
||||
- 2 MHz
|
||||
- /
|
||||
* - RTC 时钟
|
||||
- 20 MHz
|
||||
- 1 MHz
|
||||
- :c:macro:`I2C_SCLK_SRC_FLAG_AWARE_DFS`, :c:macro:`I2C_SCLK_SRC_FLAG_LIGHT_SLEEP`
|
||||
|
||||
.. only:: esp32c3
|
||||
|
||||
.. list-table:: {IDF_TARGET_NAME} 时钟源特性
|
||||
|
|
@ -185,9 +204,9 @@ I2C 驱动程序管理在 I2C 总线上设备的通信，该驱动程序具备
|
|||
配置好 I2C 驱动程序后，使用以下参数调用函数 :cpp:func:`i2c_driver_install` 安装驱动程序：
|
||||
|
||||
- 端口号，从 :cpp:type:`i2c_port_t` 中二选一
|
||||
- 主机或从机模式，从 :cpp:type:`i2c_mode_t` 中选择
|
||||
- （仅限从机模式）分配用于在从机模式下发送和接收数据的缓存区大小。I2C 是一个以主机为中心的总线，数据只能根据主机的请求从从机传输到主机。因此，从机通常有一个发送缓存区，供从应用程序写入数据使用。数据保留在发送缓存区中，由主机自行读取。
|
||||
- 用于分配中断的标志（请参考 ESP_INTR_FLAG_* values in :component_file:`esp_hw_support/include/esp_intr_alloc.h`）
|
||||
- 主机或从机模式，从 :cpp:type:`i2c_mode_t` 中选择
|
||||
- （仅限从机模式）分配用于在从机模式下发送和接收数据的缓存区大小。I2C 是一个以主机为中心的总线，数据只能根据主机的请求从从机传输到主机。因此，从机通常有一个发送缓存区，供从应用程序写入数据使用。数据保留在发送缓存区中，由主机自行读取。
|
||||
- 用于分配中断的标志（请参考 :component_file:`esp_hw_support/include/esp_intr_alloc.h` 中 ESP_INTR_FLAG_* 值）
|
||||
|
||||
.. _i2c-api-master-mode:
|
||||
|
||||
|
|
@ -225,7 +244,7 @@ I2C 驱动程序管理在 I2C 总线上设备的通信，该驱动程序具备
|
|||
|
||||
函数 :cpp:func:`i2c_master_write_byte` 和 :cpp:func:`i2c_master_write` 都有额外的实参，规定主机是否应确认其有无接受到 ACK 位。
|
||||
|
||||
2. 通过调用 :cpp:func:`i2c_master_cmd_begin` 来触发 I2C 控制器执行命令链接。一旦开始执行，就不能再修改命令链接。
|
||||
2. 通过调用 :cpp:func:`i2c_master_cmd_begin` 来触发 I2C 控制器执行命令链接。一旦开始执行，就不能再修改命令链接。
|
||||
3. 命令发送后，通过调用 :cpp:func:`i2c_cmd_link_delete` 释放命令链接使用的资源。
|
||||
|
||||
|
||||
|
|
@ -278,7 +297,7 @@ API 为从机提供以下功能：
|
|||
|
||||
- :cpp:func:`i2c_slave_write_buffer`
|
||||
|
||||
发送缓存区是用于存储从机要以 FIFO 顺序发送给主机的所有数据。在主机请求接收前，这些数据一直存储在发送缓存区。函数 :cpp:func:`i2c_slave_write_buffer` 有一个参数，用于指定发送缓存区已满时的块时间。这将允许从机应用程序在指定的超时设定内等待发送缓存区中足够的可用空间。
|
||||
发送缓存区是用于存储从机要以 FIFO 顺序发送给主机的所有数据。在主机请求接收前，这些数据一直存储在发送缓存区。函数 :cpp:func:`i2c_slave_write_buffer` 有一个参数，用于指定发送缓存区已满时的块时间。这将允许从机应用程序在指定的超时设定内等待发送缓存区中足够的可用空间。
|
||||
|
||||
在 :example:`peripherals/i2c` 中可找到介绍如何使用这些功能的代码示例。
|
||||
|
||||
|
|
@ -321,15 +340,15 @@ API 为从机提供以下功能：
|
|||
- :cpp:func:`i2c_set_data_mode`
|
||||
|
||||
|
||||
上述每个函数都有一个 *_get_* 对应项来检查当前设置的值。例如，调用 :cpp:func:`i2c_get_timeout` 来检查 I2C 超时值。
|
||||
上述每个函数都有一个 *_get_* 对应项来检查当前设置的值。例如，调用 :cpp:func:`i2c_get_timeout` 来检查 I2C 超时值。
|
||||
|
||||
要检查在驱动程序配置过程中设置的参数默认值，请参考文件 :component_file:`driver/i2c.c` 并查找带有后缀 ``_DEFAULT`` 的定义。
|
||||
要检查在驱动程序配置过程中设置的参数默认值，请参考文件 :component_file:`driver/i2c.c` 并查找带有后缀 ``_DEFAULT`` 的定义。
|
||||
|
||||
通过函数 :cpp:func:`i2c_set_pin` 可以为 SDA 和 SCL 信号选择不同的管脚并改变上拉配置。如果要修改已经输入的值，请使用函数 :cpp:func:`i2c_param_config`。
|
||||
|
||||
.. 注解 ::
|
||||
|
||||
{IDF_TARGET_NAME} 的内部上拉电阻范围为几万欧姆，因此在大多数情况下，它们本身不足以用作 I2C 上拉电阻。建议用户使用阻值在 `I2C 总线协议规范 <https://www.nxp.com/docs/en/user-guide/UM10204.pdf>`_ 规定范围内的上拉电阻。
|
||||
{IDF_TARGET_NAME} 的内部上拉电阻范围为几万欧姆，因此在大多数情况下，它们本身不足以用作 I2C 上拉电阻。建议用户使用阻值在 `I2C 总线协议规范 <https://www.nxp.com/docs/en/user-guide/UM10204.pdf>`_ 规定范围内的上拉电阻。
|
||||
|
||||
|
||||
.. _i2c-api-error-handling:
|
||||
|
|
@ -349,13 +368,14 @@ API 为从机提供以下功能：
|
|||
删除驱动程序
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
当使用 :cpp:func:`i2c_driver_install` 建立 I2C 通信，一段时间后不再需要 I2C 通信时，可以通过调用 :cpp:func:`i2c_driver_delete` 来移除驱动程序以释放分配的资源。
|
||||
当使用 :cpp:func:`i2c_driver_install` 建立 I2C 通信，一段时间后不再需要 I2C 通信时，可以通过调用 :cpp:func:`i2c_driver_delete` 来移除驱动程序以释放分配的资源。
|
||||
|
||||
由于函数 :cpp:func:`i2c_driver_delete` 无法保证线程安全性，请在调用该函数移除驱动程序前务必确保所有的线程都已停止使用驱动程序。
|
||||
|
||||
应用示例
|
||||
----------
|
||||
|
||||
I2C 主机和从机示例：:example:`peripherals/i2c`
|
||||
I2C 主机和从机示例：:example:`peripherals/i2c`。
|
||||
|
||||
|
||||
API 参考
|
||||
|
|
|
|||
|
|
@ -196,10 +196,8 @@ LED PWM 控制器 API 会在设定的频率和占空比分辨率超过 LED PWM
|
|||
|
||||
使用 LEDC 基本实例请参照 :example:`peripherals/ledc/ledc_basic`。
|
||||
|
||||
|
||||
API 参考
|
||||
-------------
|
||||
|
||||
.. include-build-file:: inc/ledc.inc
|
||||
.. include-build-file:: inc/ledc_types.inc
|
||||
|
||||
|
|
|
|||
Ładowanie…
Reference in New Issue