forked from espressif/esp-idf
docs(sphinx-lint): Fix issues reported by sphinx-lint before adding it to pre-commit
This commit is contained in:
kirill.chalov
@@ -120,15 +120,15 @@ The RF resource allocation mechanism is based on priority. As shown below, both
|
||||
default_group_color = none;
|
||||
|
||||
# node labels
|
||||
Wi-Fi [shape = box];
|
||||
Bluetooth [shape = box];
|
||||
Coexistence [shape = box, label = 'Coexistence module'];
|
||||
RF [shape = box, label = 'RF module'];
|
||||
Wi-Fi [shape = box];
|
||||
Bluetooth [shape = box];
|
||||
Coexistence [shape = box, label = 'Coexistence module'];
|
||||
RF [shape = box, label = 'RF module'];
|
||||
|
||||
# node connections
|
||||
Wi-Fi -> Coexistence;
|
||||
Bluetooth -> Coexistence;
|
||||
Coexistence -> RF;
|
||||
Wi-Fi -> Coexistence;
|
||||
Bluetooth -> Coexistence;
|
||||
Coexistence -> RF;
|
||||
}
|
||||
|
||||
|
||||
|
||||
@@ -221,7 +221,7 @@ If :doc:`IDF Monitor <tools/idf-monitor>` is used, Program Counter values will b
|
||||
Backtrace:
|
||||
|
||||
0x42006686 in bar (ptr=ptr@entry=0x0) at ../main/hello_world_main.c:18
|
||||
18 *ptr = 0x42424242;
|
||||
18 *ptr = 0x42424242;
|
||||
#0 0x42006686 in bar (ptr=ptr@entry=0x0) at ../main/hello_world_main.c:18
|
||||
#1 0x42006692 in foo () at ../main/hello_world_main.c:22
|
||||
#2 0x420066ac in app_main () at ../main/hello_world_main.c:28
|
||||
|
||||
@@ -600,6 +600,6 @@ Then the corresponding excerpt from the generated linker script will be as follo
|
||||
|
||||
``*(.iram1 .iram1.*)``
|
||||
|
||||
Rule generated from the default scheme entry ``iram -> iram0_text``. Since the default scheme specifies an ``iram -> iram0_text`` entry, it too is placed wherever ``iram0_text`` is referenced by a marker. Since it is a rule generated from the default scheme, it comes first among all other rules collected under the same target name.
|
||||
Rule generated from the default scheme entry ``iram -> iram0_text``. Since the default scheme specifies an ``iram -> iram0_text`` entry, it too is placed wherever ``iram0_text`` is referenced by a marker. Since it is a rule generated from the default scheme, it comes first among all other rules collected under the same target name.
|
||||
|
||||
The linker script template currently used is :component_file:`esp_system/ld/{IDF_TARGET_PATH_NAME}/sections.ld.in`; the generated output script ``sections.ld`` is put under its build directory.
|
||||
|
||||
@@ -92,12 +92,12 @@ If some specific application code needs to be placed into IRAM, it can be done b
|
||||
|
||||
Alternatively, it is possible to specify IRAM placement in the source code using the ``IRAM_ATTR`` macro::
|
||||
|
||||
#include "esp_attr.h"
|
||||
#include "esp_attr.h"
|
||||
|
||||
void IRAM_ATTR gpio_isr_handler(void* arg)
|
||||
{
|
||||
// ...
|
||||
}
|
||||
void IRAM_ATTR gpio_isr_handler(void* arg)
|
||||
{
|
||||
// ...
|
||||
}
|
||||
|
||||
There are some possible issues with placement in IRAM, that may cause problems with IRAM-safe interrupt handlers:
|
||||
|
||||
|
||||
@@ -167,7 +167,7 @@ Whenever the chip outputs a hexadecimal address that points to executable code,
|
||||
|
||||
Backtrace:
|
||||
panic_abort (details=details@entry=0x3fc9a37c "abort() was called at PC 0x42067cd5 on core 0") at /home/marius/esp-idf_2/components/esp_system/panic.c:367
|
||||
367 *((int *) 0) = 0; // NOLINT(clang-analyzer-core.NullDereference) should be an invalid operation on targets
|
||||
367 *((int *) 0) = 0; // NOLINT(clang-analyzer-core.NullDereference) should be an invalid operation on targets
|
||||
#0 panic_abort (details=details@entry=0x3fc9a37c "abort() was called at PC 0x42067cd5 on core 0") at /home/marius/esp-idf_2/components/esp_system/panic.c:367
|
||||
#1 0x40386b02 in esp_system_abort (details=details@entry=0x3fc9a37c "abort() was called at PC 0x42067cd5 on core 0") at /home/marius/esp-idf_2/components/esp_system/system_api.c:108
|
||||
#2 0x403906cc in abort () at /home/marius/esp-idf_2/components/newlib/abort.c:46
|
||||
|
||||
@@ -64,28 +64,28 @@ If an IO pin is routed to a peripheral signal through the GPIO matrix, the signa
|
||||
GPIO Glitch Filter
|
||||
------------------
|
||||
|
||||
The {IDF_TARGET_NAME} chip features hardware filters to remove unwanted glitch pulses from the input GPIO, which can help reduce false triggering of the interrupt and prevent a noise being routed to the peripheral side.
|
||||
The {IDF_TARGET_NAME} chip features hardware filters to remove unwanted glitch pulses from the input GPIO, which can help reduce false triggering of the interrupt and prevent a noise being routed to the peripheral side.
|
||||
|
||||
.. only:: SOC_GPIO_SUPPORT_PIN_GLITCH_FILTER
|
||||
.. only:: SOC_GPIO_SUPPORT_PIN_GLITCH_FILTER
|
||||
|
||||
Each GPIO can be configured with a glitch filter, which can be used to filter out pulses shorter than **two** sample clock cycles. The duration of the filter is not configurable. The sample clock is the clock source of the IO_MUX. In the driver, we call this kind of filter as ``pin glitch filter``. You can create the filter handle by calling :cpp:func:`gpio_new_pin_glitch_filter`. All the configurations for a pin glitch filter are listed in the :cpp:type:`gpio_pin_glitch_filter_config_t` structure.
|
||||
Each GPIO can be configured with a glitch filter, which can be used to filter out pulses shorter than **two** sample clock cycles. The duration of the filter is not configurable. The sample clock is the clock source of the IO_MUX. In the driver, we call this kind of filter as ``pin glitch filter``. You can create the filter handle by calling :cpp:func:`gpio_new_pin_glitch_filter`. All the configurations for a pin glitch filter are listed in the :cpp:type:`gpio_pin_glitch_filter_config_t` structure.
|
||||
|
||||
- :cpp:member:`gpio_pin_glitch_filter_config_t::gpio_num` sets the GPIO number to enable the glitch filter.
|
||||
- :cpp:member:`gpio_pin_glitch_filter_config_t::gpio_num` sets the GPIO number to enable the glitch filter.
|
||||
|
||||
.. only:: SOC_GPIO_FLEX_GLITCH_FILTER_NUM
|
||||
.. only:: SOC_GPIO_FLEX_GLITCH_FILTER_NUM
|
||||
|
||||
{IDF_TARGET_FLEX_GLITCH_FILTER_NUM:default="8"}
|
||||
{IDF_TARGET_FLEX_GLITCH_FILTER_NUM:default="8"}
|
||||
|
||||
{IDF_TARGET_NAME} provides {IDF_TARGET_FLEX_GLITCH_FILTER_NUM} flexible glitch filters, whose duration is configurable. We refer to this kind of filter as ``flex flitch filter``. Each of them can be applied to any input GPIO. However, applying multiple filters to the same GPIO does not make difference from one. You can create the filter handle by calling :cpp:func:`gpio_new_flex_glitch_filter`. All the configurations for a flexible glitch filter are listed in the :cpp:type:`gpio_flex_glitch_filter_config_t` structure.
|
||||
{IDF_TARGET_NAME} provides {IDF_TARGET_FLEX_GLITCH_FILTER_NUM} flexible glitch filters, whose duration is configurable. We refer to this kind of filter as ``flex flitch filter``. Each of them can be applied to any input GPIO. However, applying multiple filters to the same GPIO does not make difference from one. You can create the filter handle by calling :cpp:func:`gpio_new_flex_glitch_filter`. All the configurations for a flexible glitch filter are listed in the :cpp:type:`gpio_flex_glitch_filter_config_t` structure.
|
||||
|
||||
- :cpp:member:`gpio_flex_glitch_filter_config_t::gpio_num` sets the GPIO that will be applied to the flex glitch filter.
|
||||
- :cpp:member:`gpio_flex_glitch_filter_config_t::window_width_ns` and :cpp:member:`gpio_flex_glitch_filter_config_t::window_thres_ns` are the key parameters of the glitch filter. During :cpp:member:`gpio_flex_glitch_filter_config_t::window_width_ns`, any pulse whose width is shorter than :cpp:member:`gpio_flex_glitch_filter_config_t::window_thres_ns` will be discarded. Please note that, you can not set :cpp:member:`gpio_flex_glitch_filter_config_t::window_thres_ns` bigger than :cpp:member:`gpio_flex_glitch_filter_config_t::window_width_ns`.
|
||||
- :cpp:member:`gpio_flex_glitch_filter_config_t::gpio_num` sets the GPIO that will be applied to the flex glitch filter.
|
||||
- :cpp:member:`gpio_flex_glitch_filter_config_t::window_width_ns` and :cpp:member:`gpio_flex_glitch_filter_config_t::window_thres_ns` are the key parameters of the glitch filter. During :cpp:member:`gpio_flex_glitch_filter_config_t::window_width_ns`, any pulse whose width is shorter than :cpp:member:`gpio_flex_glitch_filter_config_t::window_thres_ns` will be discarded. Please note that, you can not set :cpp:member:`gpio_flex_glitch_filter_config_t::window_thres_ns` bigger than :cpp:member:`gpio_flex_glitch_filter_config_t::window_width_ns`.
|
||||
|
||||
.. only:: SOC_GPIO_SUPPORT_PIN_GLITCH_FILTER and SOC_GPIO_FLEX_GLITCH_FILTER_NUM
|
||||
.. only:: SOC_GPIO_SUPPORT_PIN_GLITCH_FILTER and SOC_GPIO_FLEX_GLITCH_FILTER_NUM
|
||||
|
||||
Please note, the ``pin glitch filter`` and ``flex glitch filter`` are independent. You can enable both of them for the same GPIO.
|
||||
Please note, the ``pin glitch filter`` and ``flex glitch filter`` are independent. You can enable both of them for the same GPIO.
|
||||
|
||||
The glitch filter is disabled by default, and can be enabled by calling :cpp:func:`gpio_glitch_filter_enable`. To recycle the filter, you can call :cpp:func:`gpio_del_glitch_filter`. Please note, before deleting the filter, you should disable it first by calling :cpp:func:`gpio_glitch_filter_disable`.
|
||||
The glitch filter is disabled by default, and can be enabled by calling :cpp:func:`gpio_glitch_filter_enable`. To recycle the filter, you can call :cpp:func:`gpio_del_glitch_filter`. Please note, before deleting the filter, you should disable it first by calling :cpp:func:`gpio_glitch_filter_disable`.
|
||||
|
||||
|
||||
.. only:: SOC_GPIO_SUPPORT_PIN_HYS_FILTER
|
||||
|
||||
@@ -26,7 +26,7 @@ Most applications use the following workflow when working with ``esp_vfs_fat_``
|
||||
|
||||
#. Call :cpp:func:`ff_diskio_register` to register the disk I/O driver for the drive number used in Step 1.
|
||||
|
||||
#. To mount the filesystem using the same drive number which was passed to :cpp:func:`esp_vfs_fat_register`, call the FatFs function :cpp:func:`f_mount`. If the filesystem is not present on the target logical drive, :cpp:func:`f_mount` will fail with the ``FR_NO_FILESYSTEM`` error. In such case, call :cpp:func:`f_mkfs` to create a fresh FatFS structure on the drive first, and then call:cpp:func:`f_mount` again. Note that SD cards need to be partitioned with :cpp:func:`f_fdisk` prior to previously described steps. For more information, see `FatFs documentation <http://elm-chan.org/fsw/ff/doc/mount.html>`_.
|
||||
#. To mount the filesystem using the same drive number which was passed to :cpp:func:`esp_vfs_fat_register`, call the FatFs function :cpp:func:`f_mount`. If the filesystem is not present on the target logical drive, :cpp:func:`f_mount` will fail with the ``FR_NO_FILESYSTEM`` error. In such case, call :cpp:func:`f_mkfs` to create a fresh FatFS structure on the drive first, and then call :cpp:func:`f_mount` again. Note that SD cards need to be partitioned with :cpp:func:`f_fdisk` prior to previously described steps. For more information, see `FatFs documentation <http://elm-chan.org/fsw/ff/doc/mount.html>`_.
|
||||
|
||||
#. Call the C standard library and POSIX API functions to perform such actions on files as open, read, write, erase, copy, etc. Use paths starting with the path prefix passed to :cpp:func:`esp_vfs_register` (for example, ``"/sdcard/hello.txt"``). The filesystem uses `8.3 filenames <https://en.wikipedia.org/wiki/8.3_filename>`_ format (SFN) by default. If you need to use long filenames (LFN), enable the :ref:`CONFIG_FATFS_LONG_FILENAMES` option. Please refer to `FatFs filenames <http://elm-chan.org/fsw/ff/doc/filename.html>`_ for more details.
|
||||
|
||||
|
||||
@@ -81,9 +81,9 @@ However, in an SMP system, tasks need to be assigned a particular affinity. Ther
|
||||
|
||||
The ``...PinnedToCore()`` versions of the task creation function API differ from their vanilla counterparts by having an extra ``xCoreID`` parameter that is used to specify the created task's core affinity. The valid values for core affinity are:
|
||||
|
||||
- ``0``, which pins the created task to Core 0
|
||||
- ``1``, which pins the created task to Core 1
|
||||
- ``tskNO_AFFINITY``, which allows the task to be run on both cores
|
||||
- ``0``, which pins the created task to Core 0
|
||||
- ``1``, which pins the created task to Core 1
|
||||
- ``tskNO_AFFINITY``, which allows the task to be run on both cores
|
||||
|
||||
Note that IDF FreeRTOS still supports the vanilla versions of the task creation functions. However, these standard functions have been modified to essentially invoke their respective ``...PinnedToCore()`` counterparts while setting the core affinity to ``tskNO_AFFINITY``.
|
||||
|
||||
|
||||
@@ -153,9 +153,9 @@ If you want to avoid the download/erase overhead in case of the app from the ser
|
||||
if (data_read > sizeof(esp_image_header_t) + sizeof(esp_image_segment_header_t) + sizeof(esp_app_desc_t)) {
|
||||
// check current version with downloading
|
||||
if (esp_efuse_check_secure_version(new_app_info.secure_version) == false) {
|
||||
ESP_LOGE(TAG, "This a new app can not be downloaded due to a secure version is lower than stored in efuse.");
|
||||
http_cleanup(client);
|
||||
task_fatal_error();
|
||||
ESP_LOGE(TAG, "This a new app can not be downloaded due to a secure version is lower than stored in efuse.");
|
||||
http_cleanup(client);
|
||||
task_fatal_error();
|
||||
}
|
||||
|
||||
image_header_was_checked = true;
|
||||
@@ -322,4 +322,3 @@ Debugging OTA Failure
|
||||
:figclass: align-center
|
||||
|
||||
How to Debug When OTA Fails (click to enlarge)
|
||||
|
||||
|
||||
@@ -401,7 +401,7 @@ Some {IDF_TARGET_NAME} IOs have internal pullups or pulldowns, which are enabled
|
||||
|
||||
Add the following code before :cpp:func:`esp_deep_sleep_start` to remove such extra current::
|
||||
|
||||
rtc_gpio_isolate(GPIO_NUM_12);
|
||||
rtc_gpio_isolate(GPIO_NUM_12);
|
||||
|
||||
.. only:: esp32c2 or esp32c3
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ Peripherals
|
||||
Drivers
|
||||
-------
|
||||
|
||||
In order to control the dependence of other components on drivers at a smaller granularity, the original peripheral drivers under the `driver`` component were split into separate components:
|
||||
In order to control the dependence of other components on drivers at a smaller granularity, the original peripheral drivers under the ``driver`` component were split into separate components:
|
||||
|
||||
- `esp_driver_gptimer` - Driver for general purpose timers
|
||||
- `esp_driver_pcnt` - Driver for pulse counter
|
||||
@@ -28,7 +28,7 @@ In order to control the dependence of other components on drivers at a smaller g
|
||||
- `esp_driver_parlio` - Driver for Parallel IO
|
||||
- `esp_driver_usb_serial_jtag` - Driver for USB_SERIAL_JTAG
|
||||
|
||||
For compatibility, the original `driver`` component is still treated as an all-in-one component by registering these `esp_driver_xyz`` components as its public dependencies. In other words, you do not need to modify the CMake file of an existing project, but you now have a way to specify the specific peripheral driver that your project depends on.
|
||||
For compatibility, the original ``driver`` component is still treated as an all-in-one component by registering these `esp_driver_xyz` components as its public dependencies. In other words, you do not need to modify the CMake file of an existing project, but you now have a way to specify the specific peripheral driver that your project depends on.
|
||||
|
||||
Originally, you may have used **linker.lf** to specify the link location of some driver functions in memory space, but now, because the location of the driver files have been moved, you need to make changes your **linker.lf** file accordingly. For example, a linker.lf file with the following entries:
|
||||
|
||||
|
||||
@@ -607,5 +607,3 @@ Secure Boot V2 Guidelines
|
||||
.. only:: SOC_EFUSE_REVOKE_BOOT_KEY_DIGESTS
|
||||
|
||||
* It is recommended to use all the available digest slots to reduce dependency on a single private key.
|
||||
|
||||
|
||||
|
||||
@@ -5,9 +5,9 @@
|
||||
|
||||
.. only:: esp32
|
||||
|
||||
本指南为 `乐鑫 <https://espressif.com>`_ 公司 `{IDF_TARGET_NAME} <https://www.espressif.com/en/products/socs/esp32>`_ 官方应用开发框架 `ESP-IDF <https://github.com/espressif/esp-idf>`_ 的配套文档。
|
||||
本指南为 `乐鑫 <https://espressif.com>`_ 公司 `{IDF_TARGET_NAME} <https://www.espressif.com/en/products/socs/esp32>`_ 官方应用开发框架 `ESP-IDF <https://github.com/espressif/esp-idf>`_ 的配套文档。
|
||||
|
||||
{IDF_TARGET_NAME} 芯片是一款 2.4 GHz Wi-Fi 和蓝牙双模芯片，内置 1 或 2 个 Xtensa® 32 位 LX6 处理器，运算能力最高可达 600 DMIPS。
|
||||
{IDF_TARGET_NAME} 芯片是一款 2.4 GHz Wi-Fi 和蓝牙双模芯片，内置 1 或 2 个 Xtensa® 32 位 LX6 处理器，运算能力最高可达 600 DMIPS。
|
||||
|
||||
|
||||
.. only:: esp32s2
|
||||
|
||||
@@ -221,41 +221,41 @@ Start 子命令的语法：
|
||||
|
||||
.. highlight:: none
|
||||
|
||||
1. 将 2048 个字节的跟踪数据收集到 ``trace.log`` 文件中，该文件将保存在 ``openocd-esp32`` 目录中。
|
||||
1. 将 2048 个字节的跟踪数据收集到 ``trace.log`` 文件中，该文件将保存在 ``openocd-esp32`` 目录中。
|
||||
|
||||
::
|
||||
::
|
||||
|
||||
esp apptrace start file://trace.log 1 2048 5 0 0
|
||||
esp apptrace start file://trace.log 1 2048 5 0 0
|
||||
|
||||
跟踪数据会被检索并以非阻塞的模式保存到文件中，如果收集满 2048 字节的数据或者在 5 秒内都没有新的数据，那么该过程就会停止。
|
||||
跟踪数据会被检索并以非阻塞的模式保存到文件中，如果收集满 2048 字节的数据或者在 5 秒内都没有新的数据，那么该过程就会停止。
|
||||
|
||||
.. note::
|
||||
.. note::
|
||||
|
||||
在将数据提供给 OpenOCD 之前，会对其进行缓冲。如果看到 “Data timeout!” 的消息，则表示目标可能在超时之前没有向 OpenOCD 发送足够的数据以清空缓冲区。要解决这个问题，可以增加超时时间或者使用函数 ``esp_apptrace_flush()`` 以特定间隔刷新数据。
|
||||
在将数据提供给 OpenOCD 之前，会对其进行缓冲。如果看到 “Data timeout!” 的消息，则表示目标可能在超时之前没有向 OpenOCD 发送足够的数据以清空缓冲区。要解决这个问题，可以增加超时时间或者使用函数 ``esp_apptrace_flush()`` 以特定间隔刷新数据。
|
||||
|
||||
2. 在非阻塞模式下无限地检索跟踪数据。
|
||||
2. 在非阻塞模式下无限地检索跟踪数据。
|
||||
|
||||
::
|
||||
::
|
||||
|
||||
esp apptrace start file://trace.log 1 -1 -1 0 0
|
||||
esp apptrace start file://trace.log 1 -1 -1 0 0
|
||||
|
||||
对收集数据的大小没有限制，也不设置超时时间。要停止此过程，可以在 OpenOCD 的 telnet 会话窗口中发送 ``esp apptrace stop`` 命令，或者在 OpenOCD 窗口中使用快捷键 Ctrl+C。
|
||||
对收集数据的大小没有限制，也不设置超时时间。要停止此过程，可以在 OpenOCD 的 telnet 会话窗口中发送 ``esp apptrace stop`` 命令，或者在 OpenOCD 窗口中使用快捷键 Ctrl+C。
|
||||
|
||||
3. 检索跟踪数据并无限期保存。
|
||||
3. 检索跟踪数据并无限期保存。
|
||||
|
||||
::
|
||||
::
|
||||
|
||||
esp apptrace start file://trace.log 0 -1 -1 0 0
|
||||
esp apptrace start file://trace.log 0 -1 -1 0 0
|
||||
|
||||
在跟踪停止之前，OpenOCD 的 telnet 会话窗口将不可用。要停止跟踪，请在 OpenOCD 的窗口中使用快捷键 Ctrl+C。
|
||||
在跟踪停止之前，OpenOCD 的 telnet 会话窗口将不可用。要停止跟踪，请在 OpenOCD 的窗口中使用快捷键 Ctrl+C。
|
||||
|
||||
4. 等待目标停止，然后恢复目标的操作并开始检索数据。当收集满 2048 字节的数据后就停止：
|
||||
4. 等待目标停止，然后恢复目标的操作并开始检索数据。当收集满 2048 字节的数据后就停止：
|
||||
|
||||
::
|
||||
::
|
||||
|
||||
esp apptrace start file://trace.log 0 2048 -1 1 0
|
||||
esp apptrace start file://trace.log 0 2048 -1 1 0
|
||||
|
||||
想要复位后立即开始跟踪，请使用 OpenOCD 的 ``reset halt`` 命令。
|
||||
想要复位后立即开始跟踪，请使用 OpenOCD 的 ``reset halt`` 命令。
|
||||
|
||||
|
||||
.. _app_trace-logging-to-host:
|
||||
@@ -398,21 +398,21 @@ Start 子命令语法：
|
||||
|
||||
.. highlight:: none
|
||||
|
||||
1. 将 SystemView 跟踪数据收集到文件 ``pro-cpu.SVDat`` 和 ``pro-cpu.SVDat`` 中。这些文件会被保存在 ``openocd-esp32`` 目录中。
|
||||
1. 将 SystemView 跟踪数据收集到文件 ``pro-cpu.SVDat`` 和 ``pro-cpu.SVDat`` 中。这些文件会被保存在 ``openocd-esp32`` 目录中。
|
||||
|
||||
::
|
||||
::
|
||||
|
||||
esp sysview start file://pro-cpu.SVDat file://app-cpu.SVDat
|
||||
esp sysview start file://pro-cpu.SVDat file://app-cpu.SVDat
|
||||
|
||||
跟踪数据被检索并以非阻塞的方式保存。要停止此过程，需要在 OpenOCD 的 telnet 会话窗口输入 ``esp sysview stop`` 命令，也可以在 OpenOCD 窗口中按下快捷键 Ctrl+C。
|
||||
跟踪数据被检索并以非阻塞的方式保存。要停止此过程，需要在 OpenOCD 的 telnet 会话窗口输入 ``esp sysview stop`` 命令，也可以在 OpenOCD 窗口中按下快捷键 Ctrl+C。
|
||||
|
||||
2. 检索跟踪数据并无限保存。
|
||||
2. 检索跟踪数据并无限保存。
|
||||
|
||||
::
|
||||
::
|
||||
|
||||
esp32 sysview start file://pro-cpu.SVDat file://app-cpu.SVDat 0 -1 -1
|
||||
esp32 sysview start file://pro-cpu.SVDat file://app-cpu.SVDat 0 -1 -1
|
||||
|
||||
OpenOCD 的 telnet 命令行在跟踪停止前会无法使用，要停止跟踪，请在 OpenOCD 窗口使用 Ctrl+C 快捷键。
|
||||
OpenOCD 的 telnet 命令行在跟踪停止前会无法使用，要停止跟踪，请在 OpenOCD 窗口使用 Ctrl+C 快捷键。
|
||||
|
||||
|
||||
数据可视化
|
||||
|
||||
@@ -32,12 +32,12 @@ ESP-IDF 软件引导加载程序 (Bootloader) 主要执行以下任务：
|
||||
ESP-IDF V2.1 之前的版本
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
与新版本相比，ESP-IDF V2.1 之前的版本构建的引导加载程序对硬件的配置更少。使用这些早期 ESP-IDF 版本的引导加载程序并构建新应用程序时，请启用配置选项 :ref:`CONFIG_APP_COMPATIBLE_PRE_V2_1_BOOTLOADERS`。
|
||||
与新版本相比，ESP-IDF V2.1 之前的版本构建的引导加载程序对硬件的配置更少。使用这些早期 ESP-IDF 版本的引导加载程序并构建新应用程序时，请启用配置选项 :ref:`CONFIG_APP_COMPATIBLE_PRE_V2_1_BOOTLOADERS`。
|
||||
|
||||
ESP-IDF V3.1 之前的版本
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
ESP-IDF V3.1 之前的版本构建的引导加载程序不支持分区表二进制文件中的 MD5 校验。使用这些 ESP-IDF 版本的引导加载程序并构建新应用程序时，请启用配置选项 :ref:`CONFIG_APP_COMPATIBLE_PRE_V3_1_BOOTLOADERS`。
|
||||
ESP-IDF V3.1 之前的版本构建的引导加载程序不支持分区表二进制文件中的 MD5 校验。使用这些 ESP-IDF 版本的引导加载程序并构建新应用程序时，请启用配置选项 :ref:`CONFIG_APP_COMPATIBLE_PRE_V3_1_BOOTLOADERS`。
|
||||
|
||||
ESP-IDF V5.1 之前的版本
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
@@ -694,7 +694,7 @@ project_include.cmake
|
||||
|
||||
``project_include.cmake`` 文件在 ESP-IDF 内部使用，以定义项目范围内的构建功能，比如 ``esptool.py`` 的命令行参数和 ``bootloader`` 这个特殊的应用程序。
|
||||
|
||||
与组件 ``CMakeLists.txt`` 文件有所不同，在导入``project_include.cmake`` 文件的时候，当前源文件目录（即 ``CMAKE_CURRENT_SOURCE_DIR``和工作目录）为项目目录。如果想获得当前组件的绝对路径，可以使用 ``COMPONENT_PATH`` 变量。
|
||||
与组件 ``CMakeLists.txt`` 文件有所不同，在导入 ``project_include.cmake`` 文件的时候，当前源文件目录（即 ``CMAKE_CURRENT_SOURCE_DIR`` 和工作目录）为项目目录。如果想获得当前组件的绝对路径，可以使用 ``COMPONENT_PATH`` 变量。
|
||||
|
||||
请注意，``project_include.cmake`` 对于大多数常见的组件并不是必需的。例如给项目添加 include 搜索目录，给最终的链接步骤添加 ``LDFLAGS`` 选项等等都可以通过 ``CMakeLists.txt`` 文件来自定义。详细信息请参考 :ref:`optional_project_variable`。
|
||||
|
||||
@@ -1311,7 +1311,7 @@ ESP-IDF 构建属性
|
||||
- DEPENDENCIES_LOCK - 组件管理器使用的依赖关系锁定文件的路径。默认值为项目路径下的 `dependencies.lock`。
|
||||
- EXECUTABLE_NAME - 不含扩展名的项目可执行文件的名称；通过调用 ``idf_build_executable`` 设置。
|
||||
- EXECUTABLE_DIR - 输出的可执行文件的路径
|
||||
- IDF_COMPONENT_MANAGER - 默认启用组件管理器，但如果设置这个属性为`0``，则会被 IDF_COMPONENT_MANAGER 环境变量禁用。
|
||||
- IDF_COMPONENT_MANAGER - 默认启用组件管理器，但如果设置这个属性为 ``0``，则会被 IDF_COMPONENT_MANAGER 环境变量禁用。
|
||||
- IDF_PATH - ESP-IDF 路径；由 IDF_PATH 环境变量设置，或者从 ``idf.cmake`` 的位置推断。
|
||||
- IDF_TARGET - 构建的目标芯片；由 ``idf_build_process`` 的目标参数设置。
|
||||
- IDF_VER - ESP-IDF 版本；由版本文件或 IDF_PATH 仓库的 Git 版本设置。
|
||||
@@ -1414,7 +1414,7 @@ ESP-IDF 组件属性
|
||||
- KCONFIG - 组件 Kconfig 文件；由 ``idf_build_component`` 设置。
|
||||
- KCONFIG_PROJBUILD - 组件 Kconfig.projbuild；由 ``idf_build_component`` 设置。
|
||||
- LDFRAGMENTS - 组件链接器片段文件列表；由 ``idf_component_register`` LDFRAGMENTS 参数设置。
|
||||
- MANAGED_PRIV_REQUIRES - IDF 组件管理器从``idf_component.yml``清单文件中的依赖关系中添加的私有组件依赖关系列表。
|
||||
- MANAGED_PRIV_REQUIRES - IDF 组件管理器从 ``idf_component.yml`` 清单文件中的依赖关系中添加的私有组件依赖关系列表。
|
||||
- MANAGED_REQUIRES - IDF 组件管理器从 ``idf_component.yml`` 清单文件的依赖关系中添加的公共组件依赖关系列表。
|
||||
- PRIV_INCLUDE_DIRS - 组件私有 include 目录列表；在 LIBRARY 类型的组件 ``idf_component_register`` PRIV_INCLUDE_DIRS 参数中设置。
|
||||
- PRIV_REQUIRES - 私有组件依赖关系列表；根据 ``idf_component_register`` PRIV_REQUIRES 参数的值以及 ``idf_component.yml`` 清单文件中的依赖关系设置。
|
||||
@@ -1500,7 +1500,7 @@ ESP-IDF 构建系统的列表文件位于 :idf:`/tools/cmake` 中。实现构建
|
||||
除了这些文件，还有两个重要的 CMake 脚本在 :idf:`/tools/cmake` 中：
|
||||
|
||||
- idf.cmake - 设置构建参数并导入上面列出的核心模块。之所以包括在 CMake 项目中，是为了方便访问 ESP-IDF 构建系统功能。
|
||||
- project.cmake - 导入 ``idf.cmake``，并提供了一个自定义的``project()``命令，该命令负责处理建立可执行文件时所有的繁重工作。包含在标准 ESP-IDF 项目的顶层 CMakeLists.txt 中。
|
||||
- project.cmake - 导入 ``idf.cmake``，并提供了一个自定义的 ``project()`` 命令，该命令负责处理建立可执行文件时所有的繁重工作。包含在标准 ESP-IDF 项目的顶层 CMakeLists.txt 中。
|
||||
|
||||
:idf:`/tools/cmake` 中的其它文件都是构建过程中的支持性文件或第三方脚本。
|
||||
|
||||
@@ -1535,9 +1535,9 @@ ESP-IDF 构建系统的列表文件位于 :idf:`/tools/cmake` 中。实现构建
|
||||
- 设置全局构建参数，即编译选项、编译定义、包括所有组件的 include 目录。
|
||||
- 将 :idf:`components` 中的组件添加到构建中。
|
||||
- 自定义 ``project()`` 命令的初始部分执行以下步骤：
|
||||
- 在环境变量或 CMake 缓存中设置 ``IDF_TARGET`` 以及设置相应要使用的``CMAKE_TOOLCHAIN_FILE``。
|
||||
- 在环境变量或 CMake 缓存中设置 ``IDF_TARGET`` 以及设置相应要使用的 ``CMAKE_TOOLCHAIN_FILE``。
|
||||
- 添加 ``EXTRA_COMPONENT_DIRS`` 中的组件至构建中
|
||||
- 从 ``COMPONENTS``/``EXCLUDE_COMPONENTS``、``SDKCONFIG``、``SDKCONFIG_DEFAULTS`` 等变量中为调用命令 ``idf_build_process()`` 准备参数。
|
||||
- 从 ``COMPONENTS``/ ``EXCLUDE_COMPONENTS``、``SDKCONFIG``、``SDKCONFIG_DEFAULTS`` 等变量中为调用命令 ``idf_build_process()`` 准备参数。
|
||||
|
||||
调用 ``idf_build_process()`` 命令标志着这个阶段的结束。
|
||||
|
||||
|
||||
@@ -121,15 +121,15 @@ ESP系列芯片最多支持三种射频收发模块: Bluetooth（BT 和 BLE）,
|
||||
default_group_color = none;
|
||||
|
||||
# node labels
|
||||
Wi-Fi [shape = box];
|
||||
Bluetooth [shape = box];
|
||||
Coexistence [shape = box, label = 'Coexistence module'];
|
||||
RF [shape = box, label = 'RF module'];
|
||||
Wi-Fi [shape = box];
|
||||
Bluetooth [shape = box];
|
||||
Coexistence [shape = box, label = 'Coexistence module'];
|
||||
RF [shape = box, label = 'RF module'];
|
||||
|
||||
# node connections
|
||||
Wi-Fi -> Coexistence;
|
||||
Bluetooth -> Coexistence;
|
||||
Coexistence -> RF;
|
||||
Wi-Fi -> Coexistence;
|
||||
Bluetooth -> Coexistence;
|
||||
Coexistence -> RF;
|
||||
}
|
||||
|
||||
|
||||
|
||||
@@ -98,7 +98,7 @@ USB 连接
|
||||
Udev 规则（仅限 Linux）
|
||||
--------------------------------
|
||||
|
||||
Udev 是 Linux 内核的设备管理器，允许用户在没有 ``sudo`` 的情况下运行 ``dfu-util``（和 ``idf.py dfu-flash``）从而访问芯片。
|
||||
Udev 是 Linux 内核的设备管理器，允许用户在没有 ``sudo`` 的情况下运行 ``dfu-util`` （和 ``idf.py dfu-flash``）从而访问芯片。
|
||||
|
||||
创建文件 ``/etc/udev/rules.d/40-dfuse.rules``，并在文件中添加如下内容::
|
||||
|
||||
|
||||
@@ -149,9 +149,9 @@ ESP-IDF 中大多数函数会返回 :cpp:type:`esp_err_t` 类型的错误码，
|
||||
|
||||
1. 尝试恢复。根据具体情况不同，我们具体可以：
|
||||
|
||||
- 在一段时间后，重新调用该函数；
|
||||
- 尝试删除该驱动，然后重新进行“初始化”；
|
||||
- 采用其他带外机制，修改导致错误发生的条件（例如，对一直没有响应的外设进行复位等）。
|
||||
- 在一段时间后，重新调用该函数；
|
||||
- 尝试删除该驱动，然后重新进行“初始化”；
|
||||
- 采用其他带外机制，修改导致错误发生的条件（例如，对一直没有响应的外设进行复位等）。
|
||||
|
||||
示例::
|
||||
|
||||
|
||||
@@ -204,7 +204,7 @@ ESP-BLE-MESH 架构主要由以下 5 大部分组成：
|
||||
|
||||
``API /事件`` 与 ESP-BLE-MESH 协议栈的交互
|
||||
|
||||
- 用户使用的 API 主要调用``Mesh Networking``、``Mesh Provisioning`` 和 ``Mesh Models`` 提供的函数。
|
||||
- 用户使用的 API 主要调用 ``Mesh Networking``、 ``Mesh Provisioning`` 和 ``Mesh Models`` 提供的函数。
|
||||
|
||||
- ``API /事件`` 和协议栈的交互不会跨越协议栈的层级进行操作。比如 API 不会调用 ``Network Layer`` 相关的函数。
|
||||
|
||||
|
||||
@@ -221,7 +221,7 @@
|
||||
Backtrace:
|
||||
|
||||
0x42006686 in bar (ptr=ptr@entry=0x0) at ../main/hello_world_main.c:18
|
||||
18 *ptr = 0x42424242;
|
||||
18 *ptr = 0x42424242;
|
||||
#0 0x42006686 in bar (ptr=ptr@entry=0x0) at ../main/hello_world_main.c:18
|
||||
#1 0x42006692 in foo () at ../main/hello_world_main.c:22
|
||||
#2 0x420066ac in app_main () at ../main/hello_world_main.c:28
|
||||
@@ -533,7 +533,7 @@ FreeRTOS 堆栈检查
|
||||
- 移位基数或指数错误（如移位超过 32 位）
|
||||
- 整数转换错误
|
||||
|
||||
请参考 `GCC 文档 <https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html>`_ 中的``-fsanitize=undefined`` 选项，查看支持检查的完整列表。
|
||||
请参考 `GCC 文档 <https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html>`_ 中的 ``-fsanitize=undefined`` 选项，查看支持检查的完整列表。
|
||||
|
||||
使能 UBSAN
|
||||
""""""""""""""
|
||||
|
||||
@@ -24,7 +24,7 @@ MacOS 环境下从源码编译 OpenOCD
|
||||
|
||||
使用 Homebrew 安装编译 OpenOCD 所需的软件包::
|
||||
|
||||
brew install automake libtool libusb wget gcc@4.9 pkg-config
|
||||
brew install automake libtool libusb wget gcc@4.9 pkg-config
|
||||
|
||||
|
||||
构建 OpenOCD
|
||||
|
||||
@@ -232,9 +232,9 @@
|
||||
|
||||
请检查你的目标板是否已经准备好，并加载了 :example:`get-started/blink` 示例代码，然后按照 :ref:`jtag-debugging-using-debugger-command-line` 中介绍的步骤配置和启动调试器，最后选择让应用程序在 ``app_main()`` 建立的断点处停止运行 ::
|
||||
|
||||
Temporary breakpoint 1, app_main () at /home/user-name/esp/blink/main/./blink.c:43
|
||||
43 xTaskCreate(&blink_task, "blink_task", configMINIMAL_STACK_SIZE, NULL, 5, NULL);
|
||||
(gdb)
|
||||
Temporary breakpoint 1, app_main () at /home/user-name/esp/blink/main/./blink.c:43
|
||||
43 xTaskCreate(&blink_task, "blink_task", configMINIMAL_STACK_SIZE, NULL, 5, NULL);
|
||||
(gdb)
|
||||
|
||||
|
||||
本小节的示例
|
||||
@@ -259,112 +259,112 @@
|
||||
|
||||
要找到代码暂停的位置，输入 ``l`` 或者 ``list`` 命令，调试器会打印出暂停点（``blink.c`` 代码文件的第 43 行）附近的几行代码 ::
|
||||
|
||||
(gdb) l
|
||||
38 }
|
||||
39 }
|
||||
40
|
||||
41 void app_main()
|
||||
42 {
|
||||
43 xTaskCreate(&blink_task, "blink_task", configMINIMAL_STACK_SIZE, NULL, 5, NULL);
|
||||
44 }
|
||||
(gdb)
|
||||
(gdb) l
|
||||
38 }
|
||||
39 }
|
||||
40
|
||||
41 void app_main()
|
||||
42 {
|
||||
43 xTaskCreate(&blink_task, "blink_task", configMINIMAL_STACK_SIZE, NULL, 5, NULL);
|
||||
44 }
|
||||
(gdb)
|
||||
|
||||
|
||||
也可以通过输入 ``l 30, 40`` 等命令来查看特定行号范围内的代码。
|
||||
|
||||
使用 ``bt`` 或者 ``backtrace`` 来查看哪些函数最终导致了此代码被调用::
|
||||
|
||||
(gdb) bt
|
||||
#0 app_main () at /home/user-name/esp/blink/main/./blink.c:43
|
||||
#1 0x400d057e in main_task (args=0x0) at /home/user-name/esp/esp-idf/components/{IDF_TARGET_PATH_NAME}/./cpu_start.c:339
|
||||
(gdb)
|
||||
(gdb) bt
|
||||
#0 app_main () at /home/user-name/esp/blink/main/./blink.c:43
|
||||
#1 0x400d057e in main_task (args=0x0) at /home/user-name/esp/esp-idf/components/{IDF_TARGET_PATH_NAME}/./cpu_start.c:339
|
||||
(gdb)
|
||||
|
||||
输出的第 0 行表示应用程序暂停之前调用的最后一个函数，即我们之前列出的 ``app_main ()``。``app_main ()`` 又被位于 ``cpu_start.c`` 文件第 339 行的 ``main_task`` 函数调用。
|
||||
|
||||
想查看 ``cpu_start.c`` 文件中 ``main_task`` 函数的上下文，需要输入 ``frame N``，其中 N = 1，因为根据前面的输出，``main_task`` 位于 #1 下::
|
||||
|
||||
(gdb) frame 1
|
||||
#1 0x400d057e in main_task (args=0x0) at /home/user-name/esp/esp-idf/components/{IDF_TARGET_PATH_NAME}/./cpu_start.c:339
|
||||
339 app_main();
|
||||
(gdb)
|
||||
(gdb) frame 1
|
||||
#1 0x400d057e in main_task (args=0x0) at /home/user-name/esp/esp-idf/components/{IDF_TARGET_PATH_NAME}/./cpu_start.c:339
|
||||
339 app_main();
|
||||
(gdb)
|
||||
|
||||
输入 ``l`` 将显示一段名为 ``app_main()`` 的代码（在第 339 行）::
|
||||
|
||||
(gdb) l
|
||||
334 ;
|
||||
335 }
|
||||
336 #endif
|
||||
337 //Enable allocation in region where the startup stacks were located.
|
||||
338 heap_caps_enable_nonos_stack_heaps();
|
||||
339 app_main();
|
||||
340 vTaskDelete(NULL);
|
||||
341 }
|
||||
342
|
||||
(gdb)
|
||||
(gdb) l
|
||||
334 ;
|
||||
335 }
|
||||
336 #endif
|
||||
337 //Enable allocation in region where the startup stacks were located.
|
||||
338 heap_caps_enable_nonos_stack_heaps();
|
||||
339 app_main();
|
||||
340 vTaskDelete(NULL);
|
||||
341 }
|
||||
342
|
||||
(gdb)
|
||||
|
||||
通过打印前面的一些行，你会看到我们一直在寻找的 ``main_task`` 函数::
|
||||
|
||||
(gdb) l 326, 341
|
||||
326 static void main_task(void* args)
|
||||
327 {
|
||||
328 // Now that the application is about to start, disable boot watchdogs
|
||||
329 REG_CLR_BIT(TIMG_WDTCONFIG0_REG(0), TIMG_WDT_FLASHBOOT_MOD_EN_S);
|
||||
330 REG_CLR_BIT(RTC_CNTL_WDTCONFIG0_REG, RTC_CNTL_WDT_FLASHBOOT_MOD_EN);
|
||||
331 #if !CONFIG_FREERTOS_UNICORE
|
||||
332 // Wait for FreeRTOS initialization to finish on APP CPU, before replacing its startup stack
|
||||
333 while (port_xSchedulerRunning[1] == 0) {
|
||||
334 ;
|
||||
335 }
|
||||
336 #endif
|
||||
337 //Enable allocation in region where the startup stacks were located.
|
||||
338 heap_caps_enable_nonos_stack_heaps();
|
||||
339 app_main();
|
||||
340 vTaskDelete(NULL);
|
||||
341 }
|
||||
(gdb)
|
||||
(gdb) l 326, 341
|
||||
326 static void main_task(void* args)
|
||||
327 {
|
||||
328 // Now that the application is about to start, disable boot watchdogs
|
||||
329 REG_CLR_BIT(TIMG_WDTCONFIG0_REG(0), TIMG_WDT_FLASHBOOT_MOD_EN_S);
|
||||
330 REG_CLR_BIT(RTC_CNTL_WDTCONFIG0_REG, RTC_CNTL_WDT_FLASHBOOT_MOD_EN);
|
||||
331 #if !CONFIG_FREERTOS_UNICORE
|
||||
332 // Wait for FreeRTOS initialization to finish on APP CPU, before replacing its startup stack
|
||||
333 while (port_xSchedulerRunning[1] == 0) {
|
||||
334 ;
|
||||
335 }
|
||||
336 #endif
|
||||
337 //Enable allocation in region where the startup stacks were located.
|
||||
338 heap_caps_enable_nonos_stack_heaps();
|
||||
339 app_main();
|
||||
340 vTaskDelete(NULL);
|
||||
341 }
|
||||
(gdb)
|
||||
|
||||
如果要查看其他代码，可以输入 ``i threads`` 命令，则会输出目标板上运行的线程列表::
|
||||
|
||||
(gdb) i threads
|
||||
Id Target Id Frame
|
||||
8 Thread 1073411336 (dport) 0x400d0848 in dport_access_init_core (arg=<optimized out>)
|
||||
at /home/user-name/esp/esp-idf/components/{IDF_TARGET_PATH_NAME}/./dport_access.c:170
|
||||
7 Thread 1073408744 (ipc0) xQueueGenericReceive (xQueue=0x3ffae694, pvBuffer=0x0, xTicksToWait=1644638200,
|
||||
xJustPeeking=0) at /home/user-name/esp/esp-idf/components/freertos/./queue.c:1452
|
||||
6 Thread 1073431096 (Tmr Svc) prvTimerTask (pvParameters=0x0)
|
||||
at /home/user-name/esp/esp-idf/components/freertos/./timers.c:445
|
||||
5 Thread 1073410208 (ipc1 : Running) 0x4000bfea in ?? ()
|
||||
4 Thread 1073432224 (dport) dport_access_init_core (arg=0x0)
|
||||
at /home/user-name/esp/esp-idf/components/{IDF_TARGET_PATH_NAME}/./dport_access.c:150
|
||||
3 Thread 1073413156 (IDLE) prvIdleTask (pvParameters=0x0)
|
||||
at /home/user-name/esp/esp-idf/components/freertos/./tasks.c:3282
|
||||
2 Thread 1073413512 (IDLE) prvIdleTask (pvParameters=0x0)
|
||||
at /home/user-name/esp/esp-idf/components/freertos/./tasks.c:3282
|
||||
* 1 Thread 1073411772 (main : Running) app_main () at /home/user-name/esp/blink/main/./blink.c:43
|
||||
(gdb)
|
||||
(gdb) i threads
|
||||
Id Target Id Frame
|
||||
8 Thread 1073411336 (dport) 0x400d0848 in dport_access_init_core (arg=<optimized out>)
|
||||
at /home/user-name/esp/esp-idf/components/{IDF_TARGET_PATH_NAME}/./dport_access.c:170
|
||||
7 Thread 1073408744 (ipc0) xQueueGenericReceive (xQueue=0x3ffae694, pvBuffer=0x0, xTicksToWait=1644638200,
|
||||
xJustPeeking=0) at /home/user-name/esp/esp-idf/components/freertos/./queue.c:1452
|
||||
6 Thread 1073431096 (Tmr Svc) prvTimerTask (pvParameters=0x0)
|
||||
at /home/user-name/esp/esp-idf/components/freertos/./timers.c:445
|
||||
5 Thread 1073410208 (ipc1 : Running) 0x4000bfea in ?? ()
|
||||
4 Thread 1073432224 (dport) dport_access_init_core (arg=0x0)
|
||||
at /home/user-name/esp/esp-idf/components/{IDF_TARGET_PATH_NAME}/./dport_access.c:150
|
||||
3 Thread 1073413156 (IDLE) prvIdleTask (pvParameters=0x0)
|
||||
at /home/user-name/esp/esp-idf/components/freertos/./tasks.c:3282
|
||||
2 Thread 1073413512 (IDLE) prvIdleTask (pvParameters=0x0)
|
||||
at /home/user-name/esp/esp-idf/components/freertos/./tasks.c:3282
|
||||
* 1 Thread 1073411772 (main : Running) app_main () at /home/user-name/esp/blink/main/./blink.c:43
|
||||
(gdb)
|
||||
|
||||
线程列表显示了每个线程最后一个被调用的函数以及所在的 C 源文件名（如果存在的话）。
|
||||
|
||||
你可以通过输入 ``thread N`` 进入特定的线程，其中 ``N`` 是线程 ID。我们进入 5 号线程来看一下它是如何工作的::
|
||||
|
||||
(gdb) thread 5
|
||||
[Switching to thread 5 (Thread 1073410208)]
|
||||
#0 0x4000bfea in ?? ()
|
||||
(gdb)
|
||||
(gdb) thread 5
|
||||
[Switching to thread 5 (Thread 1073410208)]
|
||||
#0 0x4000bfea in ?? ()
|
||||
(gdb)
|
||||
|
||||
然后查看回溯::
|
||||
|
||||
(gdb) bt
|
||||
#0 0x4000bfea in ?? ()
|
||||
#1 0x40083a85 in vPortCPUReleaseMutex (mux=<optimized out>) at /home/user-name/esp/esp-idf/components/freertos/./port.c:415
|
||||
#2 0x40083fc8 in vTaskSwitchContext () at /home/user-name/esp/esp-idf/components/freertos/./tasks.c:2846
|
||||
#3 0x4008532b in _frxt_dispatch ()
|
||||
#4 0x4008395c in xPortStartScheduler () at /home/user-name/esp/esp-idf/components/freertos/./port.c:222
|
||||
#5 0x4000000c in ?? ()
|
||||
#6 0x4000000c in ?? ()
|
||||
#7 0x4000000c in ?? ()
|
||||
#8 0x4000000c in ?? ()
|
||||
(gdb)
|
||||
(gdb) bt
|
||||
#0 0x4000bfea in ?? ()
|
||||
#1 0x40083a85 in vPortCPUReleaseMutex (mux=<optimized out>) at /home/user-name/esp/esp-idf/components/freertos/./port.c:415
|
||||
#2 0x40083fc8 in vTaskSwitchContext () at /home/user-name/esp/esp-idf/components/freertos/./tasks.c:2846
|
||||
#3 0x4008532b in _frxt_dispatch ()
|
||||
#4 0x4008395c in xPortStartScheduler () at /home/user-name/esp/esp-idf/components/freertos/./port.c:222
|
||||
#5 0x4000000c in ?? ()
|
||||
#6 0x4000000c in ?? ()
|
||||
#7 0x4000000c in ?? ()
|
||||
#8 0x4000000c in ?? ()
|
||||
(gdb)
|
||||
|
||||
如上所示，回溯可能会包含多个条目，方便查看直至目标停止运行的函数调用顺序。如果找不到某个函数的源码文件，将会使用问号 ``??`` 替代，这表示该函数是以二进制格式提供的。像 ``0x4000bfea`` 这样的值是被调用函数所在的内存地址。
|
||||
|
||||
@@ -435,16 +435,16 @@
|
||||
|
||||
在此之前，请删除所有的断点，然后输入 ``c`` 恢复程序运行。接着输入 Ctrl+C，应用程序会停止在某个随机的位置，此时 LED 也将停止闪烁。调试器会打印如下信息::
|
||||
|
||||
(gdb) c
|
||||
Continuing.
|
||||
^CTarget halted. PRO_CPU: PC=0x400D0C00 APP_CPU: PC=0x400D0C00 (active)
|
||||
[New Thread 1073433352]
|
||||
(gdb) c
|
||||
Continuing.
|
||||
^CTarget halted. PRO_CPU: PC=0x400D0C00 APP_CPU: PC=0x400D0C00 (active)
|
||||
[New Thread 1073433352]
|
||||
|
||||
Program received signal SIGINT, Interrupt.
|
||||
[Switching to Thread 1073413512]
|
||||
0x400d0c00 in esp_vApplicationIdleHook () at /home/user-name/esp/esp-idf/components/{IDF_TARGET_PATH_NAME}/./freertos_hooks.c:52
|
||||
52 asm("waiti 0");
|
||||
(gdb)
|
||||
Program received signal SIGINT, Interrupt.
|
||||
[Switching to Thread 1073413512]
|
||||
0x400d0c00 in esp_vApplicationIdleHook () at /home/user-name/esp/esp-idf/components/{IDF_TARGET_PATH_NAME}/./freertos_hooks.c:52
|
||||
52 asm("waiti 0");
|
||||
(gdb)
|
||||
|
||||
在上图所示的情况下，应用程序已经在 ``freertos_hooks.c`` 文件的第 52 行暂停运行，现在你可以通过输入 ``c`` 再次将其恢复运行或者进行如下所述的一些调试工作。
|
||||
|
||||
|
||||
@@ -145,7 +145,7 @@
|
||||
else:
|
||||
* (default)
|
||||
|
||||
来看一种更复杂的情况。假设``CONFIG_PERFORMANCE_LEVEL == 1`` 时，只有 ``object1.o`` 存放到 RAM 中；``CONFIG_PERFORMANCE_LEVEL == 2`` 时，``object1.o`` 和 ``object2.o`` 会存放到 RAM 中；``CONFIG_PERFORMANCE_LEVEL == 3`` 时，库中的所有目标文件都会存放到 RAM 中。以上三个条件为假时，整个库会存放到 RTC 存储器中。虽然这种使用场景很罕见，不过，还是可以通过以下方式实现：
|
||||
来看一种更复杂的情况。假设 ``CONFIG_PERFORMANCE_LEVEL == 1`` 时，只有 ``object1.o`` 存放到 RAM 中； ``CONFIG_PERFORMANCE_LEVEL == 2`` 时，``object1.o`` 和 ``object2.o`` 会存放到 RAM 中； ``CONFIG_PERFORMANCE_LEVEL == 3`` 时，库中的所有目标文件都会存放到 RAM 中。以上三个条件为假时，整个库会存放到 RTC 存储器中。虽然这种使用场景很罕见，不过，还是可以通过以下方式实现：
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
|
||||
@@ -731,5 +731,3 @@ Deep-sleep 有如下可配置选项：
|
||||
.. only:: esp32c2
|
||||
|
||||
平均电流约 4.9 μA
|
||||
|
||||
|
||||
|
||||
@@ -92,12 +92,12 @@ IRAM（指令 RAM）
|
||||
|
||||
或者，也可以通过使用 ``IRAM_ATTR`` 宏在源代码中指定需要放入 IRAM 的代码::
|
||||
|
||||
#include "esp_attr.h"
|
||||
#include "esp_attr.h"
|
||||
|
||||
void IRAM_ATTR gpio_isr_handler(void* arg)
|
||||
{
|
||||
// ...
|
||||
}
|
||||
void IRAM_ATTR gpio_isr_handler(void* arg)
|
||||
{
|
||||
// ...
|
||||
}
|
||||
|
||||
放入 IRAM 后可能会导致 IRAM 安全中断处理程序出现问题：
|
||||
|
||||
|
||||
@@ -162,7 +162,7 @@ ESP-IDF 应用程序的入口是 :idf_file:`components/esp_system/port/cpu_start
|
||||
|
||||
主任务的内核亲和性也是可以配置的，请参考 :ref:`CONFIG_ESP_MAIN_TASK_AFFINITY`。
|
||||
|
||||
与普通的 FreeRTOS 任务（或嵌入式 C 的 ``main`` 函数）不同，``app_main`` 任务可以返回。如果``app_main`` 函数返回，那么主任务将会被删除。系统将继续运行其他的 RTOS 任务。因此可以将 ``app_main`` 实现为一个创建其他应用任务然后返回的函数，或主应用任务本身。
|
||||
与普通的 FreeRTOS 任务（或嵌入式 C 的 ``main`` 函数）不同，``app_main`` 任务可以返回。如果 ``app_main`` 函数返回，那么主任务将会被删除。系统将继续运行其他的 RTOS 任务。因此可以将 ``app_main`` 实现为一个创建其他应用任务然后返回的函数，或主应用任务本身。
|
||||
|
||||
.. only:: SOC_HP_CPU_HAS_MULTIPLE_CORES
|
||||
|
||||
|
||||
@@ -229,7 +229,7 @@ DUT2 (slave) 终端::
|
||||
- 方括号中的模块名字，运行指定模块所有的测试用例。
|
||||
- 星号，运行所有测试用例。
|
||||
|
||||
``[multi_device]`` 和 ``[multi_stage]``标签告诉测试运行者该用例是多设备测试还是多阶段测试。这些标签由 ``TEST_CASE_MULTIPLE_STAGES`` 和 ``TEST_CASE_MULTIPLE_DEVICES`` 宏自动生成。
|
||||
``[multi_device]`` 和 ``[multi_stage]`` 标签告诉测试运行者该用例是多设备测试还是多阶段测试。这些标签由 ``TEST_CASE_MULTIPLE_STAGES`` 和 ``TEST_CASE_MULTIPLE_DEVICES`` 宏自动生成。
|
||||
|
||||
一旦选择了多设备测试用例，它会打印一个子菜单::
|
||||
|
||||
|
||||
@@ -64,28 +64,28 @@ GPIO 驱动提供了一个函数 :cpp:func:`gpio_dump_io_configuration` 用来
|
||||
GPIO 毛刺过滤器
|
||||
---------------
|
||||
|
||||
{IDF_TARGET_NAME} 内置硬件的过滤器可以过滤掉 GPIO 输入端口上的毛刺信号，在一定程度上避免错误触发中断或者是错把噪声当成有效的外设信号。
|
||||
{IDF_TARGET_NAME} 内置硬件的过滤器可以过滤掉 GPIO 输入端口上的毛刺信号，在一定程度上避免错误触发中断或者是错把噪声当成有效的外设信号。
|
||||
|
||||
.. only:: SOC_GPIO_SUPPORT_PIN_GLITCH_FILTER
|
||||
.. only:: SOC_GPIO_SUPPORT_PIN_GLITCH_FILTER
|
||||
|
||||
每个 GPIO 都可以使用独立的毛刺过滤器，该过滤器可以将那些脉冲宽度窄于 **2** 个采样时钟的信号剔除掉，该宽度无法配置。GPIO 对输入信号的采样时钟通常是 IO_MUX 的时钟源。在驱动中，此类过滤器称为 ``管脚毛刺过滤器``。可以调用 :cpp:func:`gpio_new_pin_glitch_filter` 函数创建一个过滤器句柄。过滤器的相关配置保存在 :cpp:type:`gpio_pin_glitch_filter_config_t` 结构体中。
|
||||
每个 GPIO 都可以使用独立的毛刺过滤器，该过滤器可以将那些脉冲宽度窄于 **2** 个采样时钟的信号剔除掉，该宽度无法配置。GPIO 对输入信号的采样时钟通常是 IO_MUX 的时钟源。在驱动中，此类过滤器称为 ``管脚毛刺过滤器``。可以调用 :cpp:func:`gpio_new_pin_glitch_filter` 函数创建一个过滤器句柄。过滤器的相关配置保存在 :cpp:type:`gpio_pin_glitch_filter_config_t` 结构体中。
|
||||
|
||||
- :cpp:member:`gpio_pin_glitch_filter_config_t::gpio_num` 设置启用毛刺过滤器的 GPIO 编号。
|
||||
- :cpp:member:`gpio_pin_glitch_filter_config_t::gpio_num` 设置启用毛刺过滤器的 GPIO 编号。
|
||||
|
||||
.. only:: SOC_GPIO_FLEX_GLITCH_FILTER_NUM
|
||||
.. only:: SOC_GPIO_FLEX_GLITCH_FILTER_NUM
|
||||
|
||||
{IDF_TARGET_FLEX_GLITCH_FILTER_NUM:default="8"}
|
||||
{IDF_TARGET_FLEX_GLITCH_FILTER_NUM:default="8"}
|
||||
|
||||
{IDF_TARGET_NAME} 提供了 {IDF_TARGET_FLEX_GLITCH_FILTER_NUM} 个灵活的毛刺过滤器，被过滤信号的脉冲宽度可以由软件进行配置。此类过滤器则称为 ``灵活毛刺过滤器``。每个过滤器都可以应用于任意 GPIO 输入，然而，将多个过滤器应用于同一 GPIO 上效果并不会叠加。可以调用 :cpp:func:`gpio_new_flex_glitch_filter` 函数来创建一个过滤器句柄。过滤器的相关配置保存在 :cpp:type:`gpio_flex_glitch_filter_config_t` 结构体中。
|
||||
{IDF_TARGET_NAME} 提供了 {IDF_TARGET_FLEX_GLITCH_FILTER_NUM} 个灵活的毛刺过滤器，被过滤信号的脉冲宽度可以由软件进行配置。此类过滤器则称为 ``灵活毛刺过滤器``。每个过滤器都可以应用于任意 GPIO 输入，然而，将多个过滤器应用于同一 GPIO 上效果并不会叠加。可以调用 :cpp:func:`gpio_new_flex_glitch_filter` 函数来创建一个过滤器句柄。过滤器的相关配置保存在 :cpp:type:`gpio_flex_glitch_filter_config_t` 结构体中。
|
||||
|
||||
- :cpp:member:`gpio_flex_glitch_filter_config_t::gpio_num` 设置启用毛刺过滤器的 GPIO 编号。
|
||||
- :cpp:member:`gpio_flex_glitch_filter_config_t::window_width_ns` 和 :cpp:member:`gpio_flex_glitch_filter_config_t::window_thres_ns` 是毛刺过滤器的关键参数。在:cpp:member:`gpio_flex_glitch_filter_config_t::window_width_ns` 时间内，任何脉冲信号，如果它的宽度小于 :cpp:member:`gpio_flex_glitch_filter_config_t::window_thres_ns` ，那么该脉冲信号就会被滤除掉。:cpp:member:`gpio_flex_glitch_filter_config_t::window_thres_ns` 的值不能大于 :cpp:member:`gpio_flex_glitch_filter_config_t::window_width_ns`。
|
||||
- :cpp:member:`gpio_flex_glitch_filter_config_t::gpio_num` 设置启用毛刺过滤器的 GPIO 编号。
|
||||
- :cpp:member:`gpio_flex_glitch_filter_config_t::window_width_ns` 和 :cpp:member:`gpio_flex_glitch_filter_config_t::window_thres_ns` 是毛刺过滤器的关键参数。在:cpp:member:`gpio_flex_glitch_filter_config_t::window_width_ns` 时间内，任何脉冲信号，如果它的宽度小于 :cpp:member:`gpio_flex_glitch_filter_config_t::window_thres_ns` ，那么该脉冲信号就会被滤除掉。:cpp:member:`gpio_flex_glitch_filter_config_t::window_thres_ns` 的值不能大于 :cpp:member:`gpio_flex_glitch_filter_config_t::window_width_ns`。
|
||||
|
||||
.. only:: SOC_GPIO_SUPPORT_PIN_GLITCH_FILTER and SOC_GPIO_FLEX_GLITCH_FILTER_NUM
|
||||
.. only:: SOC_GPIO_SUPPORT_PIN_GLITCH_FILTER and SOC_GPIO_FLEX_GLITCH_FILTER_NUM
|
||||
|
||||
请注意，``管脚毛刺过滤器`` 和 ``灵活毛刺过滤器`` 是各自独立的，支持为同一 GPIO 同时启用这两种过滤器。
|
||||
请注意，``管脚毛刺过滤器`` 和 ``灵活毛刺过滤器`` 是各自独立的，支持为同一 GPIO 同时启用这两种过滤器。
|
||||
|
||||
毛刺过滤器默认关闭，可调用 :cpp:func:`gpio_glitch_filter_enable` 使能过滤器。如需回收这个过滤器，可以调用 :cpp:func:`gpio_del_glitch_filter` 函数。在回收句柄前，请确保过滤器处于关闭状态，否则需调用 :cpp:func:`gpio_glitch_filter_disable`。
|
||||
毛刺过滤器默认关闭，可调用 :cpp:func:`gpio_glitch_filter_enable` 使能过滤器。如需回收这个过滤器，可以调用 :cpp:func:`gpio_del_glitch_filter` 函数。在回收句柄前，请确保过滤器处于关闭状态，否则需调用 :cpp:func:`gpio_glitch_filter_disable`。
|
||||
|
||||
|
||||
.. only:: SOC_GPIO_SUPPORT_PIN_HYS_FILTER
|
||||
|
||||
@@ -72,7 +72,7 @@ SPI 传输事务
|
||||
使用驱动程序
|
||||
------------
|
||||
|
||||
- 调用函数 cpp:func:`spi_slave_initialize`，将 SPI 外设初始化为从机设备。请确保在 `bus_config` 中设置正确的 I/O 管脚，并将未使用的信号设置为 ``-1``。
|
||||
- 调用函数 :cpp:func:`spi_slave_initialize`，将 SPI 外设初始化为从机设备。请确保在 `bus_config` 中设置正确的 I/O 管脚，并将未使用的信号设置为 ``-1``。
|
||||
|
||||
.. only:: esp32
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@
|
||||
|
||||
.. only:: esp32
|
||||
|
||||
如果想评估触摸传感器的多种应用场景，请查看 `ESP32 触摸功能开发套件 <https://docs.espressif.com/projects/espressif-esp-dev-kits/en/latest/esp32/esp32-sense-kit/user_guide.html>`_。
|
||||
如果想评估触摸传感器的多种应用场景，请查看 `ESP32 触摸功能开发套件 <https://docs.espressif.com/projects/espressif-esp-dev-kits/en/latest/esp32/esp32-sense-kit/user_guide.html>`_。
|
||||
|
||||
功能介绍
|
||||
----------------------
|
||||
|
||||
@@ -15,7 +15,7 @@ SPIFFS 是一个用于 SPI NOR flash 设备的嵌入式文件系统，支持磨
|
||||
- SPIFFS 并非实时栈，每次写操作耗时不等；
|
||||
- 目前，SPIFFS 尚不支持检测或处理已损坏的块。
|
||||
- SPIFFS 只能稳定地使用约 75% 的指定分区容量。
|
||||
- 当文件系统空间不足时，垃圾收集器会尝试多次扫描文件系统来寻找可用空间。根据所需空间的不同，写操作会被调用多次，每次函数调用将花费几秒。同一操作可能会花费不同时长的问题缘于 SPIFFS 的设计，且已在官方的 `SPIFFS github 仓库 <https://github.com/pellepl/spiffs/issues/>`_ 或是 <https://github.com/espressif/esp-idf/issues/1737>`_ 中被多次报告。这个问题可以通过 `SPIFFS 配置 <https://github.com/pellepl/spiffs/wiki/Configure-spiffs>`_ 部分缓解。
|
||||
- 当文件系统空间不足时，垃圾收集器会尝试多次扫描文件系统来寻找可用空间。根据所需空间的不同，写操作会被调用多次，每次函数调用将花费几秒。同一操作可能会花费不同时长的问题缘于 SPIFFS 的设计，且已在官方的 `SPIFFS github 仓库 <https://github.com/pellepl/spiffs/issues/>`_ 或是 `<https://github.com/espressif/esp-idf/issues/1737>`_ 中被多次报告。这个问题可以通过 `SPIFFS 配置 <https://github.com/pellepl/spiffs/wiki/Configure-spiffs>`_ 部分缓解。
|
||||
- 被删除文件通常不会被完全清除，会在文件系统中遗留下无法使用的部分。
|
||||
- 如果 {IDF_TARGET_NAME} 在文件系统操作期间断电，可能会导致 SPIFFS 损坏。但是仍可通过 ``esp_spiffs_check`` 函数恢复文件系统。详情请参阅官方 SPIFFS `FAQ <https://github.com/pellepl/spiffs/wiki/FAQ>`_。
|
||||
|
||||
@@ -25,7 +25,7 @@ SPIFFS 是一个用于 SPI NOR flash 设备的嵌入式文件系统，支持磨
|
||||
``spiffsgen.py``
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
:component_file:`spiffsgen.py<spiffs/spiffsgen.py>`（只写）是 SPIFFS 的一种 Python 实现，可用于从主机文件夹内容生成文件系统镜像。打开终端并运行以下命令即可使用 ``spiffsgen.py``::
|
||||
:component_file:`spiffsgen.py<spiffs/spiffsgen.py>` （只写）是 SPIFFS 的一种 Python 实现，可用于从主机文件夹内容生成文件系统镜像。打开终端并运行以下命令即可使用 ``spiffsgen.py``::
|
||||
|
||||
python spiffsgen.py <image_size> <base_dir> <output_file>
|
||||
|
||||
|
||||
@@ -81,9 +81,9 @@ Vanilla FreeRTOS 提供以下用于创建任务的函数：
|
||||
|
||||
不同于普通的任务创建函数 API，``...PinnedToCore()`` 版本的任务创建函数 API 有额外的 ``xCoreID`` 参数，用于指定所创建任务的核亲和性。核亲和性的有效值包括：
|
||||
|
||||
- ``0``：将创建的任务分配给核 0
|
||||
- ``1``：将创建的任务分配给核 1
|
||||
- ``tskNO_AFFINITY``：支持任务在两个核上运行
|
||||
- ``0``：将创建的任务分配给核 0
|
||||
- ``1``：将创建的任务分配给核 1
|
||||
- ``tskNO_AFFINITY``：支持任务在两个核上运行
|
||||
|
||||
注意，IDF FreeRTOS 仍支持普通的任务创建函数，但这些标准函数已经过调整，会内部调用其 ``...PinnedToCore()`` 版本，同时将核亲和性设置为 ``tskNO_AFFINITY``。
|
||||
|
||||
|
||||
@@ -1,2 +1 @@
|
||||
.. include:: ../../../en/api-reference/system/inc/espefuse_summary_ESP32-C2.rst
|
||||
|
||||
@@ -55,7 +55,7 @@
|
||||
|
||||
.. note::
|
||||
|
||||
在关键部分中断被禁用，因此只能使用 ``ESP_DRAM_LOGx``（首选）或 ``ESP_EARLY_LOGx`` 宏。尽管这样可以输出日志，但最好可以调整程序使其不用输出日志。
|
||||
在关键部分中断被禁用，因此只能使用 ``ESP_DRAM_LOGx`` （首选）或 ``ESP_EARLY_LOGx`` 宏。尽管这样可以输出日志，但最好可以调整程序使其不用输出日志。
|
||||
|
||||
如需在文件或组件范围内覆盖默认的日志级别，请定义 ``LOG_LOCAL_LEVEL`` 宏。
|
||||
|
||||
|
||||
@@ -56,7 +56,7 @@ OTA 数据分区的容量是 2 个 flash 扇区的大小（0x2000 字节），
|
||||
则仅会选取一次。在引导加载程序中，状态立即变为
|
||||
``ESP_OTA_IMG_PENDING_VERIFY``。
|
||||
ESP_OTA_IMG_PENDING_VERIFY 如使能 :ref:`CONFIG_BOOTLOADER_APP_ROLLBACK_ENABLE`，
|
||||
则不会选取，状态变为``ESP_OTA_IMG_ABORTED``。
|
||||
则不会选取，状态变为 ``ESP_OTA_IMG_ABORTED``。
|
||||
============================= ========================================================
|
||||
|
||||
如果 :ref:`CONFIG_BOOTLOADER_APP_ROLLBACK_ENABLE` 没有使能（默认情况），则 :cpp:func:`esp_ota_mark_app_valid_cancel_rollback` 和 :cpp:func:`esp_ota_mark_app_invalid_rollback_and_reboot` 为可选功能，``ESP_OTA_IMG_NEW`` 和 ``ESP_OTA_IMG_PENDING_VERIFY`` 不会使用。
|
||||
@@ -153,9 +153,9 @@ Kconfig 中的 :ref:`CONFIG_BOOTLOADER_APP_ROLLBACK_ENABLE` 可以帮助用户
|
||||
if (data_read > sizeof(esp_image_header_t) + sizeof(esp_image_segment_header_t) + sizeof(esp_app_desc_t)) {
|
||||
// check current version with downloading
|
||||
if (esp_efuse_check_secure_version(new_app_info.secure_version) == false) {
|
||||
ESP_LOGE(TAG, "This a new app can not be downloaded due to a secure version is lower than stored in efuse.");
|
||||
http_cleanup(client);
|
||||
task_fatal_error();
|
||||
ESP_LOGE(TAG, "This a new app can not be downloaded due to a secure version is lower than stored in efuse.");
|
||||
http_cleanup(client);
|
||||
task_fatal_error();
|
||||
}
|
||||
|
||||
image_header_was_checked = true;
|
||||
@@ -322,4 +322,3 @@ OTA 升级失败排查
|
||||
:figclass: align-center
|
||||
|
||||
OTA 升级失败时如何排查（点击放大）
|
||||
|
||||
|
||||
@@ -401,7 +401,7 @@ flash 断电
|
||||
|
||||
在函数 :cpp:func:`esp_deep_sleep_start` 前增加以下代码即可避免额外电流消耗::
|
||||
|
||||
rtc_gpio_isolate(GPIO_NUM_12);
|
||||
rtc_gpio_isolate(GPIO_NUM_12);
|
||||
|
||||
.. only:: esp32c2 or esp32c3
|
||||
|
||||
|
||||
@@ -142,9 +142,9 @@
|
||||
|
||||
.. 重要::
|
||||
|
||||
一些示例程序不支持 {IDF_TARGET_NAME}，因为 {IDF_TARGET_NAME} 中不包含所需的硬件。
|
||||
一些示例程序不支持 {IDF_TARGET_NAME}，因为 {IDF_TARGET_NAME} 中不包含所需的硬件。
|
||||
|
||||
在编译示例程序前请查看 README 文件中 ``Supported Targets`` 表格。如果表格中包含 {IDF_TARGET_NAME}， 或者不存在这个表格，那么即表示 {IDF_TARGET_NAME} 支持这个示例程序。
|
||||
在编译示例程序前请查看 README 文件中 ``Supported Targets`` 表格。如果表格中包含 {IDF_TARGET_NAME}， 或者不存在这个表格，那么即表示 {IDF_TARGET_NAME} 支持这个示例程序。
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -11,11 +11,11 @@
|
||||
|
||||
请从 Windows“命令提示符”窗口，切换至 ESP-IDF 的安装目录。然后运行::
|
||||
|
||||
install.bat
|
||||
install.bat
|
||||
|
||||
对于 Powershell，请切换至 ESP-IDF 的安装目录。然后运行::
|
||||
|
||||
install.ps1
|
||||
install.ps1
|
||||
|
||||
该命令可下载并安装 ESP-IDF 所需的工具。如已经安装了某个版本的工具，则该命令将无效。该工具的下载安装位置由 ESP-IDF 工具安装器的设置决定，默认情况下为： ``C:\Users\username\.espressif``。
|
||||
|
||||
|
||||
@@ -88,7 +88,7 @@ ESP32-DevKitC V4 开发板的主要组件、接口及控制方式见下。
|
||||
|
||||
.. warning::
|
||||
|
||||
上述供电模式 **不可同时连接**，否则可能会损坏开发板和/或电源。
|
||||
上述供电模式 **不可同时连接**，否则可能会损坏开发板和/或电源。
|
||||
|
||||
|
||||
排针
|
||||
@@ -220,6 +220,6 @@ ESP32-DevKitC V4 上电前，请首先确认开发板完好无损。
|
||||
|
||||
|
||||
.. toctree::
|
||||
:hidden:
|
||||
:hidden:
|
||||
|
||||
get-started-devkitc-v2
|
||||
get-started-devkitc-v2
|
||||
|
||||
@@ -393,4 +393,3 @@ ESP32-S2-Kaluga-1 Kit v1.2
|
||||
有关本开发板的更多设计文档，请联系我们的商务部门 sales@espressif.com。
|
||||
|
||||
|
||||
|
||||
@@ -43,7 +43,7 @@ Trax API（即以 ``trax_`` 为前缀的函数、类型或宏）已更新为私
|
||||
ROM
|
||||
---
|
||||
|
||||
``components/esp32/rom/`` 路径下存放的已弃用的 ROM 相关头文件已移除（原包含路径为 ``rom/*.h``）。请使用新的特定目标的路径 ``components/esp_rom/include/{IDF_TARGET_NAME}/``（新的包含路径为 ``{IDF_TARGET_NAME}/rom/*.h``）。
|
||||
``components/esp32/rom/`` 路径下存放的已弃用的 ROM 相关头文件已移除（原包含路径为 ``rom/*.h``）。请使用新的特定目标的路径 ``components/esp_rom/include/{IDF_TARGET_NAME}/`` （新的包含路径为 ``{IDF_TARGET_NAME}/rom/*.h``）。
|
||||
|
||||
``esp_hw_support``
|
||||
---------------------
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
驱动程序
|
||||
---------------
|
||||
|
||||
为了细粒度地控制其他组件对外设驱动的依赖，原先位于 `driver` 组件下的驱动程序被拆分到了各自独立的组件中。这些组件包括：
|
||||
为了细粒度地控制其他组件对外设驱动的依赖，原先位于 ``driver`` 组件下的驱动程序被拆分到了各自独立的组件中。这些组件包括：
|
||||
|
||||
- `esp_driver_gptimer` - 通用定时器驱动
|
||||
- `esp_driver_pcnt` - 脉冲计数器驱动
|
||||
@@ -28,7 +28,7 @@
|
||||
- `esp_driver_parlio` - 并行 IO 驱动
|
||||
- `esp_driver_usb_serial_jtag` - USB_SERIAL_JTAG 驱动
|
||||
|
||||
为了兼容性，原来的 `driver` 组件仍然存在，并作为一个 “all-in-one" 的组件，将以上这些 `esp_driver_xyz` 组件注册成自己的公共依赖。换句话说，你无需修改既有项目的 CMake 文件，但是你现在多了一个途径去指定你项目依赖的具体的外设驱动。
|
||||
为了兼容性，原来的 ``driver`` 组件仍然存在，并作为一个 “all-in-one" 的组件，将以上这些 `esp_driver_xyz` 组件注册成自己的公共依赖。换句话说，你无需修改既有项目的 CMake 文件，但是你现在多了一个途径去指定你项目依赖的具体的外设驱动。
|
||||
|
||||
原来你可能使用 **linker.lf** 指定了一些驱动函数在内存空间的链接位置，但是现在，因为驱动文件的位置发生了挪动，就需要你对 **linker.lf** 文件做出相应的改动的。假如，你的 linker.lf 文件里面有以下的条目：
|
||||
|
||||
|
||||
@@ -829,7 +829,7 @@ flash 加密的要点
|
||||
|
||||
- 通过 {IDF_TARGET_NAME} 的 flash 缓存映射功能，flash 可支持透明访问——任何映射到地址空间的 flash 区域在读取时都将被透明地解密。
|
||||
|
||||
为便于访问，某些数据分区最好保持未加密状态，或者也可使用对已加密数据无效的 flash 友好型更新算法。由于 NVS 库无法与 flash 加密直接兼容，因此无法加密非易失性存储器的 NVS 分区。详情可参见 :ref:`NVS 加密 <nvs_encryption>`。
|
||||
为便于访问，某些数据分区最好保持未加密状态，或者也可使用对已加密数据无效的 flash 友好型更新算法。由于 NVS 库无法与 flash 加密直接兼容，因此无法加密非易失性存储器的 NVS 分区。详情可参见 :ref:`NVS 加密 <nvs_encryption>`。
|
||||
|
||||
- 如果以后可能需要启用 flash 加密，则编程人员在编写 :ref:`使用加密 flash <reading-writing-content>` 代码时需小心谨慎。
|
||||
|
||||
|
||||
Reference in New Issue
Block a user