mirror of
https://github.com/espressif/esp-idf.git
synced 2024-10-05 20:47:46 -04:00
Merge branch 'docs/update_format_issues_wrongly_added_to_the_ingore_file' into 'master'
docs: update document format issues Closes DOC-6383 See merge request espressif/esp-idf!26096
This commit is contained in:
Dai Zi Yan
commit
9adb19fe53
@ -219,7 +219,7 @@ Start command syntax:
|
||||
|
||||
Command usage examples:
|
||||
|
||||
.. code-block:: none
|
||||
.. highlight:: none
|
||||
|
||||
1. Collect 2048 bytes of tracing data to the file ``trace.log``. The file will be saved in the ``openocd-esp32`` directory.
|
||||
|
||||
@ -336,7 +336,7 @@ Support for this feature is enabled by ``Component config`` > ``Application Leve
|
||||
|
||||
1. SytemView destination. Select the destination interface: JTAG or UART. In case of UART, it will be possible to connect SystemView application to the {IDF_TARGET_NAME} directly and receive data in real-time.
|
||||
|
||||
2. {IDF_TARGET_NAME} timer to use as SystemView timestamp source: (:ref:`CONFIG_APPTRACE_SV_TS_SOURCE`) selects the source of timestamps for SystemView events. In the single core mode, timestamps are generated using {IDF_TARGET_NAME} internal cycle counter running at maximum 240 Mhz (~4 ns granularity). In the dual-core mode, external timer working at 40 Mhz is used, so the timestamp granularity is 25 ns.
|
||||
2. {IDF_TARGET_NAME} timer to use as SystemView timestamp source: (:ref:`CONFIG_APPTRACE_SV_TS_SOURCE`) selects the source of timestamps for SystemView events. In the single core mode, timestamps are generated using {IDF_TARGET_NAME} internal cycle counter running at maximum 240 Mhz (about 4 ns granularity). In the dual-core mode, external timer working at 40 Mhz is used, so the timestamp granularity is 25 ns.
|
||||
|
||||
3. Individually enabled or disabled collection of SystemView events (``CONFIG_APPTRACE_SV_EVT_XXX``):
|
||||
|
||||
@ -396,7 +396,7 @@ Start command syntax:
|
||||
|
||||
Command usage examples:
|
||||
|
||||
.. code-block:: none
|
||||
.. highlight:: none
|
||||
|
||||
1. Collect SystemView tracing data to files ``pro-cpu.SVDat`` and ``app-cpu.SVDat``. The files will be saved in ``openocd-esp32`` directory.
|
||||
|
||||
|
||||
@ -64,7 +64,7 @@ Using CMake Directly
|
||||
|
||||
:ref:`idf.py` is a wrapper around CMake_ for convenience. However, you can also invoke CMake directly if you prefer.
|
||||
|
||||
.. code-block:: bash
|
||||
.. highlight:: bash
|
||||
|
||||
When ``idf.py`` does something, it prints each command that it runs for easy reference. For example, the ``idf.py build`` command is the same as running these commands in a bash shell (or similar commands for Windows Command Prompt)::
|
||||
|
||||
@ -147,7 +147,7 @@ To manage the Python version more generally via the command line, check out the
|
||||
Example Project
|
||||
===============
|
||||
|
||||
.. code-block:: none
|
||||
.. highlight:: none
|
||||
|
||||
An example project directory tree might look like this::
|
||||
|
||||
@ -198,7 +198,7 @@ Each project has a single top-level ``CMakeLists.txt`` file that contains build
|
||||
Minimal Example CMakeLists
|
||||
--------------------------
|
||||
|
||||
.. code-block:: cmake
|
||||
.. highlight:: cmake
|
||||
|
||||
Minimal project::
|
||||
|
||||
@ -256,7 +256,7 @@ Overriding Default Build Specifications
|
||||
|
||||
The build sets some global build specifications (compile flags, definitions, etc.) that gets used in compiling all sources from all components.
|
||||
|
||||
.. code-block:: cmake
|
||||
.. highlight:: cmake
|
||||
|
||||
For example, one of the default build specifications set is the compile option ``-Wextra``. Suppose a user wants to use override this with ``-Wno-extra``,
|
||||
it should be done after ``project()``::
|
||||
@ -306,7 +306,7 @@ When ESP-IDF is collecting all the components to compile, it will do this in the
|
||||
Minimal Component CMakeLists
|
||||
----------------------------
|
||||
|
||||
.. code-block:: cmake
|
||||
.. highlight:: cmake
|
||||
|
||||
The minimal component ``CMakeLists.txt`` file simply registers the component to the build system using ``idf_component_register``::
|
||||
|
||||
@ -373,7 +373,7 @@ Other build properties are listed :ref:`here <cmake-build-properties>`.
|
||||
Controlling Component Compilation
|
||||
---------------------------------
|
||||
|
||||
.. code-block:: cmake
|
||||
.. highlight:: cmake
|
||||
|
||||
To pass compiler options when compiling source files belonging to a particular component, use the `target_compile_options`_ function::
|
||||
|
||||
@ -475,7 +475,7 @@ Imagine there is a ``car`` component, which uses the ``engine`` component, which
|
||||
Car Component
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
.. code-block:: c
|
||||
.. highlight:: c
|
||||
|
||||
The ``car.h`` header file is the public interface for the ``car`` component. This header includes ``engine.h`` directly because it uses some declarations from this header::
|
||||
|
||||
@ -507,7 +507,7 @@ This means the ``car/CMakeLists.txt`` file needs to declare that ``car`` require
|
||||
Engine Component
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
.. code-block:: c
|
||||
.. highlight:: c
|
||||
|
||||
The ``engine`` component also has a public header file ``include/engine.h``, but this header is simpler::
|
||||
|
||||
@ -664,7 +664,7 @@ The order of components in the ``BUILD_COMPONENTS`` variable determines other or
|
||||
Adding Link-Time Dependencies
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. code-block:: cmake
|
||||
.. highlight:: cmake
|
||||
|
||||
The ESP-IDF CMake helper function ``idf_component_add_link_dependency`` adds a link-only dependency between one component and another. In almost all cases, it is better to use the ``PRIV_REQUIRES`` feature in ``idf_component_register`` to create a dependency. However, in some cases, it's necessary to add the link-time dependency of another component to this component, i.e., the reverse order to ``PRIV_REQUIRES`` (for example: :doc:`/api-reference/peripherals/spi_flash/spi_flash_override_driver`).
|
||||
|
||||
@ -816,7 +816,7 @@ Adding Conditional Configuration
|
||||
|
||||
The configuration system can be used to conditionally compile some files depending on the options selected in the project configuration.
|
||||
|
||||
.. code-block:: none
|
||||
.. highlight:: none
|
||||
|
||||
``Kconfig``::
|
||||
|
||||
@ -859,7 +859,7 @@ This can also be used to select or stub out an implementation, as such:
|
||||
help
|
||||
Select this to output temperature plots
|
||||
|
||||
.. code-block:: cmake
|
||||
.. highlight:: cmake
|
||||
|
||||
``CMakeLists.txt``::
|
||||
|
||||
@ -932,7 +932,7 @@ Or if the file is a string, you can use the variable ``EMBED_TXTFILES``. This wi
|
||||
idf_component_register(...
|
||||
EMBED_TXTFILES server_root_cert.pem)
|
||||
|
||||
.. code-block:: c
|
||||
.. highlight:: c
|
||||
|
||||
The file's contents will be added to the .rodata section in flash, and are available via symbol names as follows::
|
||||
|
||||
@ -941,7 +941,7 @@ The file's contents will be added to the .rodata section in flash, and are avail
|
||||
|
||||
The names are generated from the full name of the file, as given in ``EMBED_FILES``. Characters /, ., etc. are replaced with underscores. The _binary prefix in the symbol name is added by objcopy and is the same for both text and binary files.
|
||||
|
||||
.. code-block:: cmake
|
||||
.. highlight:: cmake
|
||||
|
||||
To embed a file into a project, rather than a component, you can call the function ``target_add_binary_data`` like this::
|
||||
|
||||
@ -951,7 +951,7 @@ Place this line after the ``project()`` line in your project CMakeLists.txt file
|
||||
|
||||
For an example of using this technique, see the "main" component of the file_serving example :example_file:`protocols/http_server/file_serving/main/CMakeLists.txt` - two files are loaded at build time and linked into the firmware.
|
||||
|
||||
.. code-block:: cmake
|
||||
.. highlight:: cmake
|
||||
|
||||
It is also possible to embed a generated file::
|
||||
|
||||
@ -980,7 +980,7 @@ ESP-IDF has a feature called linker script generation that enables components to
|
||||
Fully Overriding the Component Build Process
|
||||
--------------------------------------------
|
||||
|
||||
.. code-block:: cmake
|
||||
.. highlight:: cmake
|
||||
|
||||
Obviously, there are cases where all these recipes are insufficient for a certain component, for example when the component is basically a wrapper around another third-party component not originally intended to be compiled under this build system. In that case, it's possible to forego the ESP-IDF build system entirely by using a CMake feature called ExternalProject_. Example component CMakeLists::
|
||||
|
||||
@ -1077,7 +1077,7 @@ After running a project build, the build directory contains binary output files
|
||||
- ``flash_app_args`` contains arguments to flash only the app.
|
||||
- ``flash_bootloader_args`` contains arguments to flash only the bootloader.
|
||||
|
||||
.. code-block:: bash
|
||||
.. highlight:: bash
|
||||
|
||||
You can pass any of these flasher argument files to ``esptool.py`` as follows::
|
||||
|
||||
@ -1105,7 +1105,7 @@ The ESP-IDF build system "wraps" CMake with the concept of "components", and hel
|
||||
|
||||
However, underneath the concept of "components" is a full CMake build system. It is also possible to make a component which is pure CMake.
|
||||
|
||||
.. code-block:: cmake
|
||||
.. highlight:: cmake
|
||||
|
||||
Here is an example minimal "pure CMake" component CMakeLists file for a component named ``json``::
|
||||
|
||||
@ -1125,7 +1125,7 @@ Using Third-Party CMake Projects with Components
|
||||
|
||||
CMake is used for a lot of open-source C and C++ projects — code that users can tap into for their applications. One of the benefits of having a CMake build system is the ability to import these third-party projects, sometimes even without modification! This allows for users to be able to get functionality that may not yet be provided by a component, or use another library for the same functionality.
|
||||
|
||||
.. code-block:: cmake
|
||||
.. highlight:: cmake
|
||||
|
||||
Importing a library might look like this for a hypothetical library ``foo`` to be used in the ``main`` component::
|
||||
|
||||
@ -1167,7 +1167,7 @@ For example, in the ``foo/CMakeLists.txt`` file::
|
||||
Using Prebuilt Libraries with Components
|
||||
========================================
|
||||
|
||||
.. code-block:: cmake
|
||||
.. highlight:: cmake
|
||||
|
||||
Another possibility is that you have a prebuilt static library (``.a`` file), built by some other build process.
|
||||
|
||||
@ -1430,7 +1430,7 @@ These are properties that describe a component. Values of component properties c
|
||||
File Globbing & Incremental Builds
|
||||
==================================
|
||||
|
||||
.. code-block:: cmake
|
||||
.. highlight:: cmake
|
||||
|
||||
The preferred way to include source files in an ESP-IDF component is to list them manually via SRCS argument to ``idf_component_register``::
|
||||
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
.. code-block:: c
|
||||
.. highlight:: c
|
||||
|
||||
Error Handling
|
||||
==============
|
||||
|
||||
@ -7,7 +7,7 @@ Building OpenOCD from Sources for Linux
|
||||
The following instructions are alternative to downloading binary OpenOCD from `Espressif GitHub <https://github.com/espressif/openocd-esp32/releases>`_. To quickly setup the binary OpenOCD, instead of compiling it yourself, backup and proceed to section :ref:`jtag-debugging-setup-openocd`.
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
.. highlight:: bash
|
||||
|
||||
Download Sources of OpenOCD
|
||||
===========================
|
||||
|
||||
@ -6,7 +6,7 @@ Building OpenOCD from Sources for MacOS
|
||||
|
||||
The following instructions are alternative to downloading binary OpenOCD from `Espressif GitHub <https://github.com/espressif/openocd-esp32/releases>`_. To quickly setup the binary OpenOCD, instead of compiling it yourself, backup and proceed to section :ref:`jtag-debugging-setup-openocd`.
|
||||
|
||||
.. code-block:: bash
|
||||
.. highlight:: bash
|
||||
|
||||
Download Sources of OpenOCD
|
||||
===========================
|
||||
|
||||
@ -5,7 +5,7 @@ Debugging Examples
|
||||
|
||||
This section describes debugging with GDB from :ref:`jtag-debugging-examples-eclipse` as well as from :ref:`jtag-debugging-examples-command-line`.
|
||||
|
||||
.. code-block:: none
|
||||
.. highlight:: none
|
||||
|
||||
|
||||
.. _jtag-debugging-examples-eclipse:
|
||||
|
||||
@ -18,9 +18,9 @@ Protected Management Frames (PMF)
|
||||
Introduction
|
||||
++++++++++++
|
||||
|
||||
In Wi-Fi, management frames such as beacons, probes, (de)authentication, and (dis)association are used by non-AP stations to scan and connect to an AP. Unlike data frames, these frames are sent unencrypted.
|
||||
In Wi-Fi, management frames such as beacons, probes, authentication/deauthentication, and association/disassociation are used by non-AP stations to scan and connect to an AP. Unlike data frames, these frames are sent unencrypted.
|
||||
|
||||
An attacker can use eavesdropping and packet injection to send spoofed (de)authentication/(dis)association frames at the right time, leading to attacks such as Denial-of-Service (DOS) and man-in-the-middle.
|
||||
An attacker can use eavesdropping and packet injection to send spoofed authentication/deauthentication or association/disassociation frames at the right time, leading to attacks such as Denial-of-Service (DOS) and man-in-the-middle.
|
||||
|
||||
PMF provides protection against these attacks by encrypting unicast management frames and providing integrity checks for broadcast management frames. These include deauthentication, disassociation, and robust management frames. It also provides a Secure Association (SA) teardown mechanism to prevent spoofed association/authentication frames from disconnecting already connected clients.
|
||||
|
||||
|
||||
@ -22,7 +22,7 @@ ESP-NOW uses a vendor-specific action frame to transmit ESP-NOW data. The defaul
|
||||
------------------------------------------------------------------------------------------------------------
|
||||
| MAC Header | Category Code | Organization Identifier | Random Values | Vendor Specific Content | FCS |
|
||||
------------------------------------------------------------------------------------------------------------
|
||||
24 bytes 1 byte 3 bytes 4 bytes 7~257 bytes 4 bytes
|
||||
24 bytes 1 byte 3 bytes 4 bytes 7-257 bytes 4 bytes
|
||||
|
||||
- Category Code: The Category Code field is set to the value (127) indicating the vendor-specific category.
|
||||
- Organization Identifier: The Organization Identifier contains a unique identifier (0x18fe34), which is the first three bytes of MAC address applied by Espressif.
|
||||
@ -36,7 +36,7 @@ ESP-NOW uses a vendor-specific action frame to transmit ESP-NOW data. The defaul
|
||||
-------------------------------------------------------------------------------
|
||||
| Element ID | Length | Organization Identifier | Type | Version | Body |
|
||||
-------------------------------------------------------------------------------
|
||||
1 byte 1 byte 3 bytes 1 byte 1 byte 0~250 bytes
|
||||
1 byte 1 byte 3 bytes 1 byte 1 byte 0-250 bytes
|
||||
|
||||
- Element ID: The Element ID field is set to the value (221), indicating the vendor-specific element.
|
||||
- Length: The length is the total length of Organization Identifier, Type, Version and Body.
|
||||
|
||||
@ -96,7 +96,7 @@ Connections
|
||||
|
||||
Here is a list of modules/kits with 3.3 V flash:
|
||||
|
||||
- Modules: All modules except ESP32-WROVER、ESP32-WROVER-I、ESP32-S3-WROOM-2, and please check `模组概览 <https://www.espressif.com/zh-hans/products/modules>`__ for module list
|
||||
- Modules: All modules except ESP32-WROVER, ESP32-WROVER-I, ESP32-S3-WROOM-2, and please check `Modules Overview <https://www.espressif.com/en/products/modules>`__ for module list
|
||||
- Kits: ESP32-PICO-KIT, ESP32-DevKitC (up to v4), ESP32-WROVER-KIT (v4.1 [also known as ESP32-WROVER-KIT-VB], v2, v1 [also known as DevKitJ v1])
|
||||
|
||||
You can tell the version of your ESP23-WROVER-KIT version from the module on it: v4.1 are with ESP32-WROVER-B modules, v3 are with ESP32-WROVER modules, while v2 and v1 are with ESP32-WROOM-32 modules.
|
||||
@ -170,7 +170,7 @@ The host can trigger an interruption in the slave by writing a single bit to the
|
||||
|
||||
.. note::
|
||||
|
||||
The callback function is called in the ISR. Do not use any delay, loop or blocking function in the callback, e.g. mutex.
|
||||
The callback function is called in the ISR. Do not use any delay, loop or blocking function in the callback, e.g., mutex.
|
||||
|
||||
Similar to the previous information, there's an alternative set of functions available. You can call ``sdio_slave_wait_int`` to wait for an interrupt within a certain time, or call ``sdio_slave_clear_int`` to clear interrupts from host. The callback function can work with the wait functions perfectly.
|
||||
|
||||
|
||||
@ -32,7 +32,7 @@ Hardware USB Connection
|
||||
|
||||
- Any board with the {IDF_TARGET_NAME} chip with USB connectors or with exposed USB's D+ and D- (DATA+/DATA-) pins.
|
||||
|
||||
If the board has no USB connector but has the pins, connect pins directly to the host (e.g. with do-it-yourself cable from any USB connection cable).
|
||||
If the board has no USB connector but has the pins, connect pins directly to the host (e.g., with do-it-yourself cable from any USB connection cable).
|
||||
|
||||
On {IDF_TARGET_NAME}, connect GPIO {IDF_TARGET_USB_DP_GPIO_NUM} and {IDF_TARGET_USB_DM_GPIO_NUM} to D+/D- respectively:
|
||||
|
||||
@ -95,7 +95,7 @@ Install Driver
|
||||
|
||||
To initialize the driver, users should call :cpp:func:`tinyusb_driver_install`. The driver's configuration is specified in a :cpp:type:`tinyusb_config_t` structure that is passed as an argument to :cpp:func:`tinyusb_driver_install`.
|
||||
|
||||
Note that the :cpp:type:`tinyusb_config_t` structure can be zero initialized (e.g. ``const tinyusb_config_t tusb_cfg = { 0 };``) or partially (as shown below). For any member that is initialized to `0` or `NULL`, the driver will use its default configuration values for that member (see example below)
|
||||
Note that the :cpp:type:`tinyusb_config_t` structure can be zero initialized (e.g., ``const tinyusb_config_t tusb_cfg = { 0 };``) or partially (as shown below). For any member that is initialized to `0` or `NULL`, the driver will use its default configuration values for that member (see example below)
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
|
||||
@ -138,7 +138,7 @@ Control transfers are more complicated as they are bi-directional (i.e., each co
|
||||
Interrupt
|
||||
^^^^^^^^^
|
||||
|
||||
In accordance with the USB2.0 specification, interrupt transfers executes transactions at the endpoints specified service period (i.e., ``bInterval``). A particular interrupt endpoint may not execute more than one interrupt transaction within a service period. The service period is specified in number of (micro)frames, thus a particular interrupt endpoint will generally execute one transaction every Nth (micro)frame until the transfer is complete. For interrupt channels, the service period of a particular channel (i.e., ``bInterval``) is specified via the Host Frame List (see section 6.5 of programming guide for more details).
|
||||
In accordance with the USB2.0 specification, interrupt transfers executes transactions at the endpoints specified service period (i.e., ``bInterval``). A particular interrupt endpoint may not execute more than one interrupt transaction within a service period. The service period is specified in number of microframes/frames, thus a particular interrupt endpoint will generally execute one transaction every Nth microframe/frame until the transfer is complete. For interrupt channels, the service period of a particular channel (i.e., ``bInterval``) is specified via the Host Frame List (see section 6.5 of programming guide for more details).
|
||||
|
||||
.. note::
|
||||
|
||||
@ -161,7 +161,7 @@ Thus, interrupt transfers in Host Mode Scatter/Gather DMA have the following pec
|
||||
Isochronous
|
||||
^^^^^^^^^^^
|
||||
|
||||
In accordance with the USB2.0 specification, isochronous transfers executes transactions at the endpoints specified service period (i.e., ``bInterval``) in order to achieve a constant rate of data transfer. A particular isochronous endpoint may not execute more than one isochronous transaction within a service period. The service period is specified in number of (micro)frames, thus a particular isochronous endpoint will generally execute one transaction every Nth (micro)frame until the transfer is complete. For isochronous channels, the service period of a particular channel (i.e., ``bInterval``) is specified via the Host Frame List (see section 6.5 of programming guide for more details).
|
||||
In accordance with the USB2.0 specification, isochronous transfers executes transactions at the endpoints specified service period (i.e., ``bInterval``) in order to achieve a constant rate of data transfer. A particular isochronous endpoint may not execute more than one isochronous transaction within a service period. The service period is specified in number of microframes/frames, thus a particular isochronous endpoint will generally execute one transaction every Nth microframe/frame until the transfer is complete. For isochronous channels, the service period of a particular channel (i.e., ``bInterval``) is specified via the Host Frame List (see section 6.5 of programming guide for more details).
|
||||
|
||||
However, unlike interrupt transactions, isochronous transactions are not retried on failure (or NAK), due to the need to maintain the constant data rate.
|
||||
|
||||
@ -171,7 +171,7 @@ However, unlike interrupt transactions, isochronous transactions are not retried
|
||||
|
||||
Thus, isochronous transfers in Host Mode Scatter/Gather DMA have the following peculiarities:
|
||||
|
||||
- A QTD must be allocated for each (micro)frame. However, non-service service period QTDs should be left blank (i.e., only ever Nth QTD should be filled if the channel's service period is every Nth (micro)frame).
|
||||
- A QTD must be allocated for each microframe/frame. However, non-service service period QTDs should be left blank (i.e., only ever Nth QTD should be filled if the channel's service period is every Nth microframe/frame).
|
||||
- **Each filled QTD must represent a single transaction instead of a transfer**.
|
||||
- Because isochronous transactions are not retried on failure, the status each completed QTD must be checked.
|
||||
|
||||
|
||||
@ -41,7 +41,7 @@ The services provided by the SDIO Slave peripheral of the {IDF_TARGET_NAME} chip
|
||||
ESP SDIO Slave Initialization
|
||||
-----------------------------
|
||||
|
||||
The host should initialize the {IDF_TARGET_NAME} SDIO slave according to the standard SDIO initialization process (Section 3.1.2 of `SDIO Simplified Specification <https://www.sdcard.org/downloads/pls/>`_). In this specification as well as below, the SDIO slave is called an (SD)IO card. Here is a brief example of an ESP SDIO Slave initialization process:
|
||||
The host should initialize the {IDF_TARGET_NAME} SDIO slave according to the standard SDIO initialization process (Section 3.1.2 of `SDIO Simplified Specification <https://www.sdcard.org/downloads/pls/>`_). In this specification as well as below, the SDIO slave is called an SDIO/IO card. Here is a brief example of an ESP SDIO Slave initialization process:
|
||||
|
||||
1. SDIO reset
|
||||
|
||||
|
||||
@ -3,20 +3,20 @@ Storage API
|
||||
|
||||
:link_to_translation:`zh_CN:[中文]`
|
||||
|
||||
This section contains reference of the high-level storage APIs. They are based on low-level drivers such as SPI Flash, SD/MMC.
|
||||
This section contains reference of the high-level storage APIs. They are based on low-level drivers such as SPI flash, SD/MMC.
|
||||
|
||||
- :doc:`Partitions API <partition>` allow block based access to SPI Flash according to the :doc:`Partition Table </api-guides/partition-tables>`.
|
||||
- :doc:`Non-Volatile Storage library (NVS) <nvs_flash>` implements a fault-tolerant wear-levelled key-value storage in SPI NOR Flash.
|
||||
- :doc:`Partitions API <partition>` allow block based access to SPI flash according to the :doc:`/api-guides/partition-tables`.
|
||||
- :doc:`Non-Volatile Storage library (NVS) <nvs_flash>` implements a fault-tolerant wear-levelled key-value storage in SPI NOR flash.
|
||||
- :doc:`Virtual File System (VFS) <vfs>` library provides an interface for registration of file system drivers. SPIFFS, FAT and various other file system libraries are based on the VFS.
|
||||
- :doc:`SPIFFS <spiffs>` is a wear-levelled file system optimized for SPI NOR Flash, well suited for small partition sizes and low throughput
|
||||
- :doc:`FAT <fatfs>` is a standard file system which can be used in SPI Flash or on SD/MMC cards
|
||||
- :doc:`Wear Levelling <wear-levelling>` library implements a flash translation layer (FTL) suitable for SPI NOR Flash. It is used as a container for FAT partitions in Flash.
|
||||
- :doc:`SPIFFS <spiffs>` is a wear-levelled file system optimized for SPI NOR flash, well suited for small partition sizes and low throughput
|
||||
- :doc:`FAT <fatfs>` is a standard file system which can be used in SPI flash or on SD/MMC cards
|
||||
- :doc:`Wear Levelling <wear-levelling>` library implements a flash translation layer (FTL) suitable for SPI NOR flash. It is used as a container for FAT partitions in flash.
|
||||
|
||||
.. note::
|
||||
|
||||
It is suggested to use high-level APIs (``esp_partition`` or file system) instead of low-level driver APIs to access the SPI NOR Flash.
|
||||
It is suggested to use high-level APIs (``esp_partition`` or file system) instead of low-level driver APIs to access the SPI NOR flash.
|
||||
|
||||
Due to the restriction of NOR Flash and ESP hardware, accessing the main flash will affect the performance of the whole system. See :doc:`SPI Flash Documents </api-reference/peripherals/spi_flash/index>` to learn more about the limitations.
|
||||
Due to the restriction of NOR flash and ESP hardware, accessing the main flash will affect the performance of the whole system. See :doc:`/api-reference/peripherals/spi_flash/index` to learn more about the limitations.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
@ -6,14 +6,14 @@ Partitions API
|
||||
Overview
|
||||
--------
|
||||
|
||||
The ``esp_partition`` component has higher-level API functions which work with partitions defined in the :doc:`partition table </api-guides/partition-tables>`. These APIs are based on lower level API provided by :doc:`SPI Flash driver </api-reference/peripherals/spi_flash/index>`.
|
||||
The ``esp_partition`` component has higher-level API functions which work with partitions defined in the :doc:`/api-guides/partition-tables`. These APIs are based on lower level API provided by :doc:`/api-reference/peripherals/spi_flash/index`.
|
||||
|
||||
.. _flash-partition-apis:
|
||||
|
||||
Partition Table API
|
||||
-------------------
|
||||
|
||||
ESP-IDF projects use a partition table to maintain information about various regions of SPI flash memory (bootloader, various application binaries, data, filesystems). More information can be found in :doc:`Partition Tables </api-guides/partition-tables>`.
|
||||
ESP-IDF projects use a partition table to maintain information about various regions of SPI flash memory (bootloader, various application binaries, data, filesystems). More information can be found in :doc:`/api-guides/partition-tables`.
|
||||
|
||||
This component provides API functions to enumerate partitions found in the partition table and perform operations on them. These functions are declared in ``esp_partition.h``:
|
||||
|
||||
@ -28,9 +28,9 @@ This component provides API functions to enumerate partitions found in the parti
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`Partition Table documentation <../../api-guides/partition-tables>`
|
||||
- :doc:`Over The Air Update (OTA) API <../system/ota>` provides high-level API for updating applications stored in flash.
|
||||
- :doc:`Non-Volatile Storage (NVS) API <nvs_flash>` provides a structured API for storing small pieces of data in SPI flash.
|
||||
- :doc:`../../api-guides/partition-tables`
|
||||
- :doc:`../system/ota` provides high-level API for updating applications stored in flash.
|
||||
- :doc:`nvs_flash` provides a structured API for storing small pieces of data in SPI flash.
|
||||
|
||||
|
||||
.. _api-reference-partition-table:
|
||||
|
||||
@ -82,7 +82,7 @@ You can also see the information on segments in the ESP-IDF logs while your appl
|
||||
* version word (4 bytes)
|
||||
* signature data (64 bytes)
|
||||
|
||||
6. If the option :ref:`CONFIG_SECURE_SIGNED_APPS_SCHEME` is set to RSA or ECDSA (V2) then the application image will have an additional signature sector of that is 4K bytes in size. For more details on the format of this signature sector, please refer to :ref:`signature-block-format`.
|
||||
6. If the option :ref:`CONFIG_SECURE_SIGNED_APPS_SCHEME` is set to RSA or ECDSA (V2) then the application image will have an additional signature sector of 4 KB in size. For more details on the format of this signature sector, please refer to :ref:`signature-block-format`.
|
||||
|
||||
.. _app-image-format-application-description:
|
||||
|
||||
|
||||
@ -182,7 +182,7 @@ If the hypothetical event ``MY_OTHER_EVENT_BASE``, ``MY_OTHER_EVENT_ID`` is post
|
||||
Handler Un-Registering Itself
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
In general, an event handler run by an event loop is **not allowed to do any (un)registering activity on that event loop**. There is one exception, though: un-registering itself is allowed for the handler. E.g., it is possible to do the following:
|
||||
In general, an event handler run by an event loop is **not allowed to do any registering/unregistering activity on that event loop**. There is one exception, though: un-registering itself is allowed for the handler. E.g., it is possible to do the following:
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
|
||||
@ -48,7 +48,7 @@ To use the partial image download feature, enable ``partial_http_download`` conf
|
||||
|
||||
This option is useful while fetching image from a service like AWS S3, where mbedTLS Rx buffer size (:ref:`CONFIG_MBEDTLS_SSL_IN_CONTENT_LEN`) can be set to a lower value which is not possible without enabling this configuration.
|
||||
|
||||
Default value of mbedTLS Rx buffer size is set to 16 K. By using ``partial_http_download`` with ``max_http_request_size`` of 4 K, size of mbedTLS Rx buffer can be reduced to 4 K. With this configuration, memory saving of around 12 K is expected.
|
||||
Default value of mbedTLS Rx buffer size is set to 16 KB. By using ``partial_http_download`` with ``max_http_request_size`` of 4 KB, size of mbedTLS Rx buffer can be reduced to 4 KB. With this configuration, memory saving of around 12 KB is expected.
|
||||
|
||||
|
||||
Signature Verification
|
||||
|
||||
@ -8,7 +8,7 @@ OTA Process Overview
|
||||
|
||||
The OTA update mechanism allows a device to update itself based on data received while the normal firmware is running (for example, over Wi-Fi or Bluetooth.)
|
||||
|
||||
OTA requires configuring the :doc:`Partition Table <../../api-guides/partition-tables>` of the device with at least two OTA app slot partitions (i.e., ``ota_0`` and ``ota_1``) and an OTA Data Partition.
|
||||
OTA requires configuring the :doc:`../../api-guides/partition-tables` of the device with at least two OTA app slot partitions (i.e., ``ota_0`` and ``ota_1``) and an OTA Data Partition.
|
||||
|
||||
The OTA operation functions write a new app firmware image to whichever OTA app slot that is currently not selected for booting. Once the image is verified, the OTA Data partition is updated to specify that this image should be used for the next boot.
|
||||
|
||||
@ -17,7 +17,7 @@ The OTA operation functions write a new app firmware image to whichever OTA app
|
||||
OTA Data Partition
|
||||
------------------
|
||||
|
||||
An OTA data partition (type ``data``, subtype ``ota``) must be included in the :doc:`Partition Table <../../api-guides/partition-tables>` of any project which uses the OTA functions.
|
||||
An OTA data partition (type ``data``, subtype ``ota``) must be included in the :doc:`../../api-guides/partition-tables` of any project which uses the OTA functions.
|
||||
|
||||
For factory boot settings, the OTA data partition should contain no data (all bytes erased to 0xFF). In this case, the ESP-IDF software bootloader will boot the factory app if it is present in the partition table. If no factory app is included in the partition table, the first available OTA slot (usually ``ota_0``) is booted.
|
||||
|
||||
@ -201,7 +201,7 @@ The verification of signed OTA updates can be performed even without enabling ha
|
||||
OTA Tool ``otatool.py``
|
||||
-----------------------
|
||||
|
||||
The component ``app_update`` provides a tool :component_file:`otatool.py <app_update/otatool.py>` for performing OTA partition-related operations on a target device. The following operations can be performed using the tool:
|
||||
The component ``app_update`` provides a tool :component_file:`app_update/otatool.py` for performing OTA partition-related operations on a target device. The following operations can be performed using the tool:
|
||||
|
||||
- read contents of otadata partition (read_otadata)
|
||||
- erase otadata partition, effectively resetting device to factory app (erase_otadata)
|
||||
@ -297,10 +297,10 @@ More information can be obtained by specifying ``--help`` as argument:
|
||||
See Also
|
||||
--------
|
||||
|
||||
* :doc:`Partition Table documentation <../../api-guides/partition-tables>`
|
||||
* :doc:`Partition API <../storage/partition>`
|
||||
* :doc:`Lower-Level SPI Flash API <../peripherals/spi_flash/index>`
|
||||
* :doc:`ESP HTTPS OTA <esp_https_ota>`
|
||||
* :doc:`../../api-guides/partition-tables`
|
||||
* :doc:`../storage/partition`
|
||||
* :doc:`../peripherals/spi_flash/index`
|
||||
* :doc:`esp_https_ota`
|
||||
|
||||
Application Example
|
||||
-------------------
|
||||
|
||||
@ -92,7 +92,7 @@ Dynamic Frequency Scaling and Peripheral Drivers
|
||||
|
||||
When DFS is enabled, the APB frequency can be changed multiple times within a single RTOS tick. The APB frequency change does not affect the operation of some peripherals, while other peripherals may have issues. For example, Timer Group peripheral timers keeps counting, however, the speed at which they count changes proportionally to the APB frequency.
|
||||
|
||||
Peripheral clock sources such as ``REF_TICK``, ``XTAL``, ``RC_FAST`` (i.e. ``RTC_8M``), their frequencies will not be inflenced by APB frequency. And therefore, to ensure the peripheral behaves consistently during DFS, it is recommanded to select one of these clocks as the peripheral clock source. For more specific guidelines, please refer to the "Power Management" section of each peripheral's "API Reference > Peripherals API" page.
|
||||
Peripheral clock sources such as ``REF_TICK``, ``XTAL``, ``RC_FAST`` (i.e., ``RTC_8M``), their frequencies will not be inflenced by APB frequency. And therefore, to ensure the peripheral behaves consistently during DFS, it is recommanded to select one of these clocks as the peripheral clock source. For more specific guidelines, please refer to the "Power Management" section of each peripheral's "API Reference > Peripherals API" page.
|
||||
|
||||
Currently, the following peripheral drivers are aware of DFS and use the ``ESP_PM_APB_FREQ_MAX`` lock for the duration of the transaction:
|
||||
|
||||
|
||||
@ -5,7 +5,7 @@ System Time
|
||||
|
||||
{IDF_TARGET_RTC_CLK_FRE:default="Not updated", esp32="150 kHz", esp32s2="90 kHz", esp32s3="136 kHz", esp32c3="136 kHz", esp32c2="136 kHz", esp32c6="150 kHz", esp32h2="150 kHz"}
|
||||
{IDF_TARGET_INT_OSC_FRE:default="Not updated", esp32="8.5 MHz", esp32s2="8.5 MHz", esp32s3="17.5 MHz", esp32c3="17.5 MHz", esp32c2="17.5 MHz", esp32c6="20 MHz"}
|
||||
{IDF_TARGET_INT_OSC_FRE_DIVIDED:default="Not updated", esp32="~33 kHz", esp32s2="~33 kHz", esp32s3="~68 kHz", esp32c3="~68 kHz", esp32c2="~68 kHz"}
|
||||
{IDF_TARGET_INT_OSC_FRE_DIVIDED:default="Not updated", esp32="about 33 kHz", esp32s2="about 33 kHz", esp32s3="about 68 kHz", esp32c3="about 68 kHz", esp32c2="about 68 kHz"}
|
||||
{IDF_TARGET_EXT_CRYSTAL_PIN:default="Not updated", esp32="32K_XP and 32K_XN", esp32s2="XTAL_32K_P and XTAL_32K_N", esp32s3="XTAL_32K_P and XTAL_32K_N", esp32c3="XTAL_32K_P and XTAL_32K_N", esp32c6="XTAL_32K_P and XTAL_32K_N", esp32h2="XTAL_32K_P and XTAL_32K_N"}
|
||||
{IDF_TARGET_EXT_OSC_PIN:default="Not updated", esp32="32K_XN", esp32s2="XTAL_32K_P", esp32s3="XTAL_32K_P", esp32c3="XTAL_32K_P", esp32c2="GPIO0", esp32c6="XTAL_32K_P"}
|
||||
{IDF_TARGET_HARDWARE_DESIGN_URL:default="Not updated",esp32="`ESP32 Hardware Design Guidelines <https://www.espressif.com/sites/default/files/documentation/esp32_hardware_design_guidelines_en.pdf#page=11>`_", esp32s2="`ESP32-S2 Hardware Design Guidelines <https://www.espressif.com/sites/default/files/documentation/esp32-s2_hardware_design_guidelines_en.pdf#page=10>`_", esp32s3="`ESP32-S3 Hardware Design Guidelines <https://www.espressif.com/sites/default/files/documentation/esp32-s3_hardware_design_guidelines_en.pdf#page=11>`_", esp32c3="`ESP32-C3 Hardware Design Guidelines <https://www.espressif.com/sites/default/files/documentation/esp32-c3_hardware_design_guidelines_en.pdf#page=9>`_", esp32c6="`ESP32-C6 Hardware Design Guidelines <https://www.espressif.com/sites/default/files/documentation/esp32-c6_hardware_design_guidelines_en.pdf#page=12>`_", esp32c2="`ESP8684 Hardware Design Guidelines <https://www.espressif.com/sites/default/files/documentation/esp8684_hardware_design_guidelines_en.pdf#page=10>`_", esp32h2="`ESP32-H2 Hardware Design Guidelines <https://www.espressif.com/sites/default/files/documentation/esp32-h2_hardware_design_guidelines_en.pdf#page=11>`_"}
|
||||
|
||||
@ -67,7 +67,7 @@ You are using this menu to set up project specific variables, e.g., Wi-Fi networ
|
||||
|
||||
.. attention::
|
||||
|
||||
If you use ESP32-DevKitC board with the **ESP32-SOLO-1** module, or ESP32-DevKitM-1 board with the **ESP32-MIN1-1(1U)** module, please enable single core mode (:ref:`CONFIG_FREERTOS_UNICORE`) in menuconfig before flashing examples.
|
||||
If you use ESP32-DevKitC board with the **ESP32-SOLO-1** module, or ESP32-DevKitM-1 board with the **ESP32-MIN1-1/1U** module, please enable single core mode (:ref:`CONFIG_FREERTOS_UNICORE`) in menuconfig before flashing examples.
|
||||
|
||||
.. note::
|
||||
|
||||
|
||||
@ -67,7 +67,7 @@ You are using this menu to set up project specific variables, e.g., Wi-Fi networ
|
||||
|
||||
.. attention::
|
||||
|
||||
If you use ESP32-DevKitC board with the **ESP32-SOLO-1** module, or ESP32-DevKitM-1 board with the **ESP32-MIN1-1(1U)** module, please enable single core mode (:ref:`CONFIG_FREERTOS_UNICORE`) in menuconfig before flashing examples.
|
||||
If you use ESP32-DevKitC board with the **ESP32-SOLO-1** module, or ESP32-DevKitM-1 board with the **ESP32-MIN1-1/1U** module, please enable single core mode (:ref:`CONFIG_FREERTOS_UNICORE`) in menuconfig before flashing examples.
|
||||
|
||||
.. note::
|
||||
|
||||
|
||||
@ -8,9 +8,9 @@ Overview
|
||||
|
||||
ESP32-PICO-DevKitM-2 is an ESP32-based development board produced by `Espressif <https://espressif.com>`_.
|
||||
|
||||
The core of this board is `ESP32-PICO-MINI-02(02U) <https://www.espressif.com/en/products/modules>`_ module with complete Wi-Fi and Bluetooth® functionalities. The development board features a USB-to-UART Bridge circuit which allows developers to connect the board to a computer's USB port for flashing and debugging.
|
||||
The core of this board is `ESP32-PICO-MINI-02/02U <https://www.espressif.com/en/products/modules>`_ module with complete Wi-Fi and Bluetooth® functionalities. The development board features a USB-to-UART Bridge circuit which allows developers to connect the board to a computer's USB port for flashing and debugging.
|
||||
|
||||
All the IO signals and system power on ESP32-PICO-MINI-02(02U) are led out to two rows of 18 x 0.1" header pads on both sides of the development board for easy access. For compatibility with Dupont wires, all header pads are populated with two rows of male pin headers.
|
||||
All the IO signals and system power on ESP32-PICO-MINI-02/02U are led out to two rows of 18 x 0.1" header pads on both sides of the development board for easy access. For compatibility with Dupont wires, all header pads are populated with two rows of male pin headers.
|
||||
|
||||
.. note::
|
||||
|
||||
|
||||
@ -6,7 +6,7 @@ ESP32-DevKitM-1
|
||||
|
||||
This user guide will help you get started with ESP32-DevKitM-1 and will also provide more in-depth information.
|
||||
|
||||
ESP32-DevKitM-1 is an ESP32-MINI-1(1U)-based development board produced by Espressif. Most of the I/O pins are broken out to the pin headers on both sides for easy interfacing. Users can either connect peripherals with jumper wires or mount ESP32-DevKitM-1 on a breadboard.
|
||||
ESP32-DevKitM-1 is an ESP32-MINI-1/1U-based development board produced by Espressif. Most of the I/O pins are broken out to the pin headers on both sides for easy interfacing. Users can either connect peripherals with jumper wires or mount ESP32-DevKitM-1 on a breadboard.
|
||||
|
||||
|
||||
+---------------------------+-------------------------------+
|
||||
|
||||
@ -83,7 +83,7 @@ GPIO
|
||||
- The user callback of a GPIO interrupt should no longer read the GPIO interrupt status register to get the GPIO's pin number of triggering the interrupt. You should use the callback argument to determine the GPIO's pin number instead.
|
||||
|
||||
- Previously, when a GPIO interrupt occurs, the GPIO's interrupt status register is cleared after calling the user callbacks. Thus, it was possible for users to read the GPIO's interrupt status register inside the callback to determine which GPIO was used to trigger the interrupt.
|
||||
- However, clearing the interrupt status register after calling the user callbacks can potentially cause edge-triggered interrupts to be lost. For example, if an edge-triggered interrupt is (re)triggered while the user callbacks are being called, that interrupt will be cleared without its registered user callback being handled.
|
||||
- However, clearing the interrupt status register after calling the user callbacks can potentially cause edge-triggered interrupts to be lost. For example, if an edge-triggered interrupt is triggered/retriggered while the user callbacks are being called, that interrupt will be cleared without its registered user callback being handled.
|
||||
- Now, the GPIO's interrupt status register is cleared **before** invoking the user callbacks. Thus, users can no longer read the GPIO interrupt status register to determine which pin has triggered the interrupt. Instead, users should use the callback argument to pass the pin number.
|
||||
|
||||
.. only:: SOC_SDM_SUPPORTED
|
||||
|
||||
@ -4,7 +4,7 @@ WiFi
|
||||
:link_to_translation:`zh_CN:[中文]`
|
||||
|
||||
|
||||
WiFi Enterprise security
|
||||
WiFi Enterprise Security
|
||||
------------------------
|
||||
|
||||
APIs defined in `esp_wpa2.h` have been deprecated. Please use newer APIs from `esp_eap_client.h`.
|
||||
|
||||
@ -64,7 +64,7 @@ idf.py
|
||||
|
||||
为了方便，:ref:`idf.py` 已经封装了 CMake_ 命令，但是你愿意，也可以直接调用 CMake。
|
||||
|
||||
.. code-block:: bash
|
||||
.. highlight:: bash
|
||||
|
||||
当 ``idf.py`` 在执行某些操作时，它会打印出其运行的每条命令以便参考。例如运行 ``idf.py build`` 命令与在 bash shell（或者 Windows Command Prompt）中运行以下命令是相同的::
|
||||
|
||||
@ -147,7 +147,7 @@ ESP-IDF 适用于 Python 3.8 以上版本。
|
||||
示例项目
|
||||
========
|
||||
|
||||
.. code-block:: none
|
||||
.. highlight:: none
|
||||
|
||||
示例项目的目录树结构可能如下所示::
|
||||
|
||||
@ -198,7 +198,7 @@ ESP-IDF 适用于 Python 3.8 以上版本。
|
||||
最小 CMakeLists 文件示例
|
||||
------------------------
|
||||
|
||||
.. code-block:: cmake
|
||||
.. highlight:: cmake
|
||||
|
||||
最小项目::
|
||||
|
||||
@ -256,7 +256,7 @@ ESP-IDF 适用于 Python 3.8 以上版本。
|
||||
|
||||
构建系统设置了一些全局的构建规范（编译标志、定义等），这些规范可用于编译来自所有组件的所有源文件。
|
||||
|
||||
.. code-block:: cmake
|
||||
.. highlight:: cmake
|
||||
|
||||
例如，其中一个默认的构建规范是编译选项 ``Wextra``。假设一个用户想用 ``Wno-extra`` 来覆盖这个选项，
|
||||
应在 ``project()`` 之后进行::
|
||||
@ -306,7 +306,7 @@ ESP-IDF 在搜索所有待构建的组件时，会按照 ``COMPONENT_DIRS`` 指
|
||||
最小组件 CMakeLists 文件
|
||||
--------------------------
|
||||
|
||||
.. code-block:: cmake
|
||||
.. highlight:: cmake
|
||||
|
||||
最小组件 ``CMakeLists.txt`` 文件通过使用 ``idf_component_register`` 将组件添加到构建系统中。
|
||||
|
||||
@ -373,7 +373,7 @@ ESP-IDF 在搜索所有待构建的组件时，会按照 ``COMPONENT_DIRS`` 指
|
||||
组件编译控制
|
||||
------------------
|
||||
|
||||
.. code-block:: cmake
|
||||
.. highlight:: cmake
|
||||
|
||||
在编译特定组件的源文件时，可以使用 `target_compile_options`_ 函数来传递编译器选项::
|
||||
|
||||
@ -475,7 +475,7 @@ ESP-IDF 构建系统会在命令行中添加以下 C 预处理器定义：
|
||||
Car 组件
|
||||
^^^^^^^^^
|
||||
|
||||
.. code-block:: c
|
||||
.. highlight:: c
|
||||
|
||||
``car.h`` 头文件是 ``car`` 组件的公共接口。该头文件直接包含了 ``engine.h``，这是因为它需要使用 ``engine.h`` 中的一些声明::
|
||||
|
||||
@ -507,7 +507,7 @@ Car 组件
|
||||
Engine 组件
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
.. code-block:: c
|
||||
.. highlight:: c
|
||||
|
||||
``engine`` 组件也有一个公共头文件 ``include/engine.h``，但这个头文件更为简单::
|
||||
|
||||
@ -664,7 +664,7 @@ CMake 通常会在链接器命令行上重复两次组件库名称来自动处
|
||||
添加链接时依赖项
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. code-block:: cmake
|
||||
.. highlight:: cmake
|
||||
|
||||
ESP-IDF 的 CMake 辅助函数 ``idf_component_add_link_dependency`` 可以在组件之间添加仅作用于链接时的依赖关系。绝大多数情况下，我们都建议你使用 ``idf_component_register`` 中的 ``PRIV_REQUIRES`` 功能来构建依赖关系。然而在某些情况下，还是有必要添加另一个组件对当前组件的链接时依赖，即反转 ``PRIV_REQUIRES`` 中的依赖关系（参考示例：:doc:`/api-reference/peripherals/spi_flash/spi_flash_override_driver`）。
|
||||
|
||||
@ -816,7 +816,7 @@ CMake 调试
|
||||
|
||||
配置系统可用于根据项目配置中选择的选项有条件地编译某些文件。
|
||||
|
||||
.. code-block:: none
|
||||
.. highlight:: none
|
||||
|
||||
``Kconfig``::
|
||||
|
||||
@ -859,7 +859,7 @@ CMake 调试
|
||||
help
|
||||
Select this to output temperature plots
|
||||
|
||||
.. code-block:: cmake
|
||||
.. highlight:: cmake
|
||||
|
||||
``CMakeLists.txt``::
|
||||
|
||||
@ -932,7 +932,7 @@ CMake 文件可以使用 ``IDF_TARGET`` 变量来获取当前的硬件目标。
|
||||
idf_component_register(...
|
||||
EMBED_TXTFILES server_root_cert.pem)
|
||||
|
||||
.. code-block:: c
|
||||
.. highlight:: c
|
||||
|
||||
文件的内容会被添加到 flash 的 .rodata 段，用户可以通过符号名来访问，如下所示::
|
||||
|
||||
@ -941,7 +941,7 @@ CMake 文件可以使用 ``IDF_TARGET`` 变量来获取当前的硬件目标。
|
||||
|
||||
符号名会根据文件全名生成，如 ``EMBED_FILES`` 中所示，字符 ``/``、``.`` 等都会被下划线替代。符号名称中的 _binary 前缀由 objcopy 命令添加，对文本文件和二进制文件都是如此。
|
||||
|
||||
.. code-block:: cmake
|
||||
.. highlight:: cmake
|
||||
|
||||
如果要将文件嵌入到项目中，而非组件中，可以调用 ``target_add_binary_data`` 函数::
|
||||
|
||||
@ -951,7 +951,7 @@ CMake 文件可以使用 ``IDF_TARGET`` 变量来获取当前的硬件目标。
|
||||
|
||||
有关使用此技术的示例，请查看 file_serving 示例 :example_file:`protocols/http_server/file_serving/main/CMakeLists.txt` 中的 main 组件，两个文件会在编译时加载并链接到固件中。
|
||||
|
||||
.. code-block:: cmake
|
||||
.. highlight:: cmake
|
||||
|
||||
也可以嵌入生成的文件::
|
||||
|
||||
@ -980,7 +980,7 @@ ESP-IDF 还支持自动生成链接脚本，它允许组件通过链接片段文
|
||||
完全覆盖组件的构建过程
|
||||
----------------------
|
||||
|
||||
.. code-block:: cmake
|
||||
.. highlight:: cmake
|
||||
|
||||
当然，在有些情况下，上面提到的方法不一定够用。如果组件封装了另一个第三方组件，而这个第三方组件并不能直接在 ESP-IDF 的构建系统中工作，在这种情况下，就需要放弃 ESP-IDF 的构建系统，改为使用 CMake 的 ExternalProject_ 功能。组件 CMakeLists 示例如下::
|
||||
|
||||
@ -1077,7 +1077,7 @@ flash 参数
|
||||
- ``flash_app_args`` 只包含烧录应用程序的参数。
|
||||
- ``flash_bootloader_args`` 只包含烧录引导程序的参数。
|
||||
|
||||
.. code-block:: bash
|
||||
.. highlight:: bash
|
||||
|
||||
你可以参照如下命令将任意烧录参数文件传递给 ``esptool.py``::
|
||||
|
||||
@ -1105,7 +1105,7 @@ ESP-IDF 构建系统用“组件”的概念“封装”了 CMake，并提供了
|
||||
|
||||
然而，“组件”概念的背后是一个完整的 CMake 构建系统，因此可以制作纯 CMake 组件。
|
||||
|
||||
.. code-block:: cmake
|
||||
.. highlight:: cmake
|
||||
|
||||
下面是使用纯 CMake 语法为 ``json`` 组件编写的最小 CMakeLists 文件的示例::
|
||||
|
||||
@ -1125,7 +1125,7 @@ ESP-IDF 构建系统用“组件”的概念“封装”了 CMake，并提供了
|
||||
|
||||
CMake 在许多开源的 C/C++ 项目中广泛使用，用户可以在自己的应用程序中使用开源代码。CMake 构建系统的一大好处就是可以导入这些第三方的项目，有时候甚至不用做任何改动。这就允许用户使用当前 ESP-IDF 组件尚未提供的功能，或者使用其它库来实现相同的功能。
|
||||
|
||||
.. code-block:: cmake
|
||||
.. highlight:: cmake
|
||||
|
||||
假设 ``main`` 组件需要导入一个假想库 ``foo``，相应的组件 CMakeLists 文件如下所示::
|
||||
|
||||
@ -1167,7 +1167,7 @@ CMake 在许多开源的 C/C++ 项目中广泛使用，用户可以在自己的
|
||||
组件中使用预建库
|
||||
=================
|
||||
|
||||
.. code-block:: cmake
|
||||
.. highlight:: cmake
|
||||
|
||||
还有一种情况是你有一个由其它构建过程生成预建静态库（``.a`` 文件）。
|
||||
|
||||
@ -1430,7 +1430,7 @@ ESP-IDF 组件属性
|
||||
文件通配 & 增量构建
|
||||
=====================
|
||||
|
||||
.. code-block:: cmake
|
||||
.. highlight:: cmake
|
||||
|
||||
在 ESP-IDF 组件中添加源文件的首选方法是在 ``COMPONENT_SRCS`` 中手动列出它们::
|
||||
|
||||
|
||||
@ -223,9 +223,9 @@ ESP-BLE-MESH 示例
|
||||
|
||||
* :example_file:`Wi-Fi 和 BLE-Mesh 共存 <bluetooth/esp_ble_mesh/wifi_coexist/tutorial/BLE_Mesh_WiFi_Coexist_Example_Walkthrough.md>` - 该示例用于演示 Wi-Fi 和 ESP-BLE-MESH 共存的功能。简而言之，用户可在运行 ESP-BLE-MESH 时使用 Wi-Fi，示例请见 :example:`example code <bluetooth/esp_ble_mesh/wifi_coexist>`。
|
||||
|
||||
* 远程配网(v1.1 新增) - :example_file:`Client, Server and device <bluetooth/esp_ble_mesh/remote_provisioning/tutorial/BLE_Mesh_Remote_Provisioning_Example_Walkthrough.md>` - 该示例用于演示 mesh 协议 v1.1 中新增的远程配网功能, 示例请见： :example:`example client code <bluetooth/esp_ble_mesh/remote_provisioning/rpr_client>`, :example:`example server code <bluetooth/esp_ble_mesh/remote_provisioning/rpr_server>` and :example:`example device code <bluetooth/esp_ble_mesh/remote_provisioning/unprov_dev>`.
|
||||
* 远程配网（v1.1 新增）- :example_file:`Client, Server and device <bluetooth/esp_ble_mesh/remote_provisioning/tutorial/BLE_Mesh_Remote_Provisioning_Example_Walkthrough.md>` - 该示例用于演示 mesh 协议 v1.1 中新增的远程配网功能, 示例请见： :example:`example client code <bluetooth/esp_ble_mesh/remote_provisioning/rpr_client>`, :example:`example server code <bluetooth/esp_ble_mesh/remote_provisioning/rpr_server>` and :example:`example device code <bluetooth/esp_ble_mesh/remote_provisioning/unprov_dev>`.
|
||||
|
||||
* 定向转发(v1.1 新增) - :example_file:`Client and Server <bluetooth/esp_ble_mesh/directed_forwarding/tutorial/BLE_Mesh_Directed_Forwarding_Example_Walkthrough.md>` - 该示例用于演示 mesh 协议 v1.1 中新增的定向转发功能。只有路径上的节点才会对定向消息进行转发，而其他节点不参与转发, 示例请见 :example:`example client code <bluetooth/esp_ble_mesh/remote_provisioning/rpr_client>` and :example:`example server code <bluetooth/esp_ble_mesh/remote_provisioning/rpr_server>`.
|
||||
* 定向转发（v1.1 新增）- :example_file:`Client and Server <bluetooth/esp_ble_mesh/directed_forwarding/tutorial/BLE_Mesh_Directed_Forwarding_Example_Walkthrough.md>` - 该示例用于演示 mesh 协议 v1.1 中新增的定向转发功能。只有路径上的节点才会对定向消息进行转发，而其他节点不参与转发, 示例请见 :example:`example client code <bluetooth/esp_ble_mesh/remote_provisioning/rpr_client>` and :example:`example server code <bluetooth/esp_ble_mesh/remote_provisioning/rpr_server>`.
|
||||
|
||||
|
||||
.. _esp-ble-mesh-demo-videos:
|
||||
|
||||
@ -7,7 +7,7 @@ Linux 环境下从源码编译 OpenOCD
|
||||
除了从 `Espressif 官方 <https://github.com/espressif/openocd-esp32/releases>`_ 直接下载 OpenOCD 可执行文件，你还可以选择从源码编译得到 OpenOCD。如果想要快速设置 OpenOCD 而不是自行编译，请备份好当前文件，前往 :ref:`jtag-debugging-setup-openocd` 章节查阅。
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
.. highlight:: bash
|
||||
|
||||
下载 OpenOCD 源码
|
||||
=================
|
||||
|
||||
@ -6,7 +6,7 @@ MacOS 环境下从源码编译 OpenOCD
|
||||
|
||||
除了从 `Espressif 官方 <https://github.com/espressif/openocd-esp32/releases>`_ 直接下载 OpenOCD 可执行文件，你还可以选择从源码编译得到 OpenOCD。如果想要快速设置 OpenOCD 而不是自行编译，请备份好当前文件，前往 :ref:`jtag-debugging-setup-openocd` 章节查阅。
|
||||
|
||||
.. code-block:: bash
|
||||
.. highlight:: bash
|
||||
|
||||
下载 OpenOCD 源码
|
||||
=================
|
||||
|
||||
@ -5,7 +5,7 @@
|
||||
|
||||
本节将介绍如何在 :ref:`Eclipse <jtag-debugging-examples-eclipse>` 和 :ref:`命令行 <jtag-debugging-examples-command-line>` 中使用 GDB 进行调试的示例。
|
||||
|
||||
.. code-block:: none
|
||||
.. highlight:: none
|
||||
|
||||
|
||||
.. _jtag-debugging-examples-eclipse:
|
||||
|
||||
@ -22,7 +22,7 @@ ESP-NOW 使用各个供应商的动作帧传输数据，默认比特率为 1 Mbp
|
||||
-----------------------------------------------------------------------------------------
|
||||
| MAC 报头 | 分类代码 | 组织标识符 | 随机值 | 供应商特定内容 | FCS |
|
||||
-----------------------------------------------------------------------------------------
|
||||
24 字节 1 字节 3 字节 4 字节 7~257 字节 4 字节
|
||||
24 字节 1 字节 3 字节 4 字节 7-257 字节 4 字节
|
||||
|
||||
- 分类代码：分类代码字段可用于指示各个供应商的类别（比如 127）。
|
||||
- 组织标识符：组织标识符包含一个唯一标识符（比如 0x18fe34），为乐鑫指定的 MAC 地址的前三个字节。
|
||||
@ -36,7 +36,7 @@ ESP-NOW 使用各个供应商的动作帧传输数据，默认比特率为 1 Mbp
|
||||
----------------------------------------------------------------------------------------
|
||||
| 元素 ID | 长度 | 组织标识符 | 类型 | 版本 | 正文 |
|
||||
----------------------------------------------------------------------------------------
|
||||
1 字节 1 字节 3 字节 1 字节 1 字节 0～250 字节
|
||||
1 字节 1 字节 3 字节 1 字节 1 字节 0-250 字节
|
||||
|
||||
- 元素 ID：元素 ID 字段可用于指示特定于供应商的元素。
|
||||
- 长度：长度是组织标识符、类型、版本和正文的总长度。
|
||||
|
||||
@ -29,7 +29,7 @@ USB 主机库（以下简称主机库）是 USB 主机栈的最底层，提供
|
||||
- 支持四种传输类型，即控制传输、块传输、中断传输和同步传输。
|
||||
- 支持多个 Class 驱动程序同时运行，即主机的多个客户端同时运行。
|
||||
- 单个设备可以由多个客户端同时使用，如复合设备。
|
||||
- 主机库及其底层主机栈不会在内部自动创建操作系统任务，任务数量完全由主机库接口的使用方式决定。一般来说，任务数量为 ``(运行中的主机 Class 驱动程序数量 + 1)``。
|
||||
- 主机库及其底层主机栈不会在内部自动创建操作系统任务，任务数量完全由主机库接口的使用方式决定。一般来说，任务数量为 ``（运行中的主机 Class 驱动程序数量 + 1）``。
|
||||
|
||||
目前，主机库及其底层主机栈存在以下限制：
|
||||
|
||||
|
||||
@ -41,7 +41,7 @@ ESP SDIO 主从机通信
|
||||
初始化 ESP SDIO 从机
|
||||
-------------------------
|
||||
|
||||
主机需按照标准的 SDIO 初始化流程，对 {IDF_TARGET_NAME} SDIO 从机进行初始化（参考 `SDIO Simplified Specification <https://www.sdcard.org/downloads/pls/>`_ 3.1.2 章节）。下文将 SDIO 从机简称为 (SD)IO 卡。以下是 ESP SDIO 从机初始化流程的一个简单示例：
|
||||
主机需按照标准的 SDIO 初始化流程，对 {IDF_TARGET_NAME} SDIO 从机进行初始化（参考 `SDIO Simplified Specification <https://www.sdcard.org/downloads/pls/>`_ 3.1.2 章节）。下文将 SDIO 从机简称为 SD/SDIO 卡。以下是 ESP SDIO 从机初始化流程的一个简单示例：
|
||||
|
||||
1. SDIO 复位
|
||||
|
||||
|
||||
@ -41,7 +41,7 @@ ESP SPI 从机 HD（半双工）模式协议
|
||||
|
||||
- 地址阶段：8 位，主机到从机，可选
|
||||
|
||||
对于某些命令 (如 WRBUF、RDBUF)，此阶段指定要写入/读取的共享寄存器地址。对于其他包括此阶段的命令，这没有实际意义，但仍必须存在于事务中。
|
||||
对于某些命令（如 WRBUF、RDBUF），此阶段指定要写入/读取的共享寄存器地址。对于其他包括此阶段的命令，这没有实际意义，但仍必须存在于事务中。
|
||||
|
||||
- Dummy 阶段：8 位，浮动，可选
|
||||
|
||||
@ -56,7 +56,7 @@ ESP SPI 从机 HD（半双工）模式协议
|
||||
数据 IO 模式
|
||||
-------------
|
||||
|
||||
在某些 IO 模式下，可以使用更多数据线来发送数据。因此，与 1 位模式相比，发送相同数据量所需的 SPI 时钟周期更少。例如，在 QIO 模式下，地址和数据 (IN 和 OUT) 应发送到全部 4 条数据线上 (MOSI、MISO、WP 和 HD)。下表展示了 ESP32-S2 SPI 从机支持的模式，以及相应模式下使用的数据线数量。
|
||||
在某些 IO 模式下，可以使用更多数据线来发送数据。因此，与 1 位模式相比，发送相同数据量所需的 SPI 时钟周期更少。例如，在 QIO 模式下，地址和数据（IN 和 OUT）应发送到全部 4 条数据线上（MOSI、MISO、WP 和 HD）。下表展示了 ESP32-S2 SPI 从机支持的模式，以及相应模式下使用的数据线数量。
|
||||
|
||||
+-------+----------+----------+------------+----------+
|
||||
| Mode | 命令线数 | 地址线数 | dummy 次数 | 数据线数 |
|
||||
@ -115,7 +115,7 @@ QPI 模式是 SPI 从机的一种特殊状态。主机可发送 ENQPI 命令，
|
||||
| EXQPI | 退出 QPI 模式 | 0xDD | - | - |
|
||||
+----------+---------------+------+----------+------------------------------+
|
||||
|
||||
此外，WRBUF、RDBUF、WRDMA 和 RDDMA 命令都有 2 位和 4 位版本。要在 2 位或 4 位模式下操作，请用下表中的对应命令掩码与原始命令按位或（bit OR）后发送。例如，命令 0xA1 表示 QIO 模式下的 WRBUF。
|
||||
此外，WRBUF、RDBUF、WRDMA 和 RDDMA 命令都有 2 位和 4 位版本。要在 2 位或 4 位模式下操作，请用下表中的对应命令掩码与原始命令按位或 (bit OR) 后发送。例如，命令 0xA1 表示 QIO 模式下的 WRBUF。
|
||||
|
||||
+-------+------+
|
||||
| 模式 | 掩码 |
|
||||
|
||||
@ -3,20 +3,20 @@
|
||||
|
||||
:link_to_translation:`en:[English]`
|
||||
|
||||
本节提供高层次的存储 API 的参考文档。这些 API 基于如 SPI Flash、SD/MMC 等低层次驱动。
|
||||
本节提供高层次的存储 API 的参考文档。这些 API 基于如 SPI flash、SD/MMC 等低层次驱动。
|
||||
|
||||
- :doc:`分区表 API <partition>` 基于 :doc:`分区表 </api-guides/partition-tables>` ，允许以块为单位访问 SPI Flash。
|
||||
- :doc:`非易失性存储库 (NVS) <nvs_flash>` 在 SPI NOR Flash 上实现了一个有容错性，和磨损均衡功能的键值对存储。
|
||||
- :doc:`分区表 API <partition>` 基于 :doc:`/api-guides/partition-tables` ，允许以块为单位访问 SPI flash。
|
||||
- :doc:`非易失性存储库 (NVS) <nvs_flash>` 在 SPI NOR flash 上实现了一个有容错性，和磨损均衡功能的键值对存储。
|
||||
- :doc:`虚拟文件系统 (VFS) <vfs>` 库提供了一个用于注册文件系统驱动的接口。SPIFFS、FAT 以及多种其他的文件系统库都基于 VFS。
|
||||
- :doc:`SPIFFS <spiffs>` 是一个专为 SPI NOR Flash 优化的磨损均衡的文件系统，非常适用于小分区和低吞吐率的应用。
|
||||
- :doc:`FAT <fatfs>` 是一个可用于 SPI Flash 或者 SD/MMC 存储卡的标准文件系统。
|
||||
- :doc:`磨损均衡 <wear-levelling>` 库实现了一个适用于 SPI NOR Flash 的 flash 翻译层 (FTL)，用于 flash 中 FAT 分区的容器。
|
||||
- :doc:`SPIFFS <spiffs>` 是一个专为 SPI NOR flash 优化的磨损均衡的文件系统，非常适用于小分区和低吞吐率的应用。
|
||||
- :doc:`FAT <fatfs>` 是一个可用于 SPI flash 或者 SD/MMC 存储卡的标准文件系统。
|
||||
- :doc:`磨损均衡 <wear-levelling>` 库实现了一个适用于 SPI NOR flash 的 flash 翻译层 (FTL)，用于 flash 中 FAT 分区的容器。
|
||||
|
||||
.. note::
|
||||
|
||||
建议使用高层次的 API（``esp_partition`` 或者文件系统）而非低层次驱动 API 去访问 SPI NOR Flash。
|
||||
建议使用高层次的 API（``esp_partition`` 或者文件系统）而非低层次驱动 API 去访问 SPI NOR flash。
|
||||
|
||||
由于 NOR Flash 和乐鑫硬件的一些限制，访问主 flash 会影响各个系统的性能。关于这些限制的更多信息，参见 :doc:`SPI Flash Documents </api-reference/peripherals/spi_flash/index>`。
|
||||
由于 NOR flash 和乐鑫硬件的一些限制，访问主 flash 会影响各个系统的性能。关于这些限制的更多信息，参见 :doc:`/api-reference/peripherals/spi_flash/index`。
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
@ -6,14 +6,14 @@
|
||||
概述
|
||||
--------
|
||||
|
||||
``esp_partition`` 组件提供了高层次的 API 函数，用于访问定义在 :doc:`分区表 </api-guides/partition-tables>` 中的分区。这些 API 基于 :doc:`SPI Flash 驱动 </api-reference/peripherals/spi_flash/index>` 提供的低层次 API。
|
||||
``esp_partition`` 组件提供了高层次的 API 函数，用于访问定义在 :doc:`/api-guides/partition-tables` 中的分区。这些 API 基于 :doc:`/api-reference/peripherals/spi_flash/index` 提供的低层次 API。
|
||||
|
||||
.. _flash-partition-apis:
|
||||
|
||||
分区表 API
|
||||
-------------------
|
||||
|
||||
ESP-IDF 工程使用分区表保存 SPI flash 各区信息，包括引导程序、各种应用程序二进制文件、数据及文件系统等。请参阅 :doc:`分区表 </api-guides/partition-tables>`，查看详细信息。
|
||||
ESP-IDF 工程使用分区表保存 SPI flash 各区信息，包括引导程序、各种应用程序二进制文件、数据及文件系统等。请参阅 :doc:`/api-guides/partition-tables`，查看详细信息。
|
||||
|
||||
该组件在 ``esp_partition.h`` 中声明了一些 API 函数，用以枚举在分区表中找到的分区，并对这些分区执行操作：
|
||||
|
||||
@ -28,9 +28,9 @@ ESP-IDF 工程使用分区表保存 SPI flash 各区信息，包括引导程序
|
||||
另请参考
|
||||
------------
|
||||
|
||||
- :doc:`分区表 <../../api-guides/partition-tables>`
|
||||
- :doc:`OTA API <../system/ota>` 提供了高层 API 用于更新存储在 flash 中的 app 固件。
|
||||
- :doc:`NVS API <nvs_flash>` 提供了结构化 API 用于存储 SPI flash 中的碎片数据。
|
||||
- :doc:`../../api-guides/partition-tables`
|
||||
- :doc:`../system/ota` 提供了高层 API 用于更新存储在 flash 中的 app 固件。
|
||||
- :doc:`nvs_flash` 提供了结构化 API 用于存储 SPI flash 中的碎片数据。
|
||||
|
||||
|
||||
.. _api-reference-partition-table:
|
||||
|
||||
@ -48,7 +48,7 @@ ESP HTTPS OTA 升级
|
||||
|
||||
在从 AWS S3 等服务获取镜像时，这一选项非常有用。在启用该选项时， 可以将 mbedTLS Rx 的 buffer 大小（即 :ref:`CONFIG_MBEDTLS_SSL_IN_CONTENT_LEN`）设置为较小的值。不启用此配置时，无法将其设置为较小值。
|
||||
|
||||
mbedTLS Rx buffer 的默认大小为 16 K，但如果将 ``partial_http_download`` 的 ``max_http_request_size`` 设置为 4 K，便能将 mbedTLS Rx 的 buffer 减小到 4 K。使用这一配置方式预计可以节省约 12 K 内存。
|
||||
mbedTLS Rx buffer 的默认大小为 16 KB，但如果将 ``partial_http_download`` 的 ``max_http_request_size`` 设置为 4 KB，便能将 mbedTLS Rx 的 buffer 减小到 4 KB。使用这一配置方式预计可以节省约 12 KB 内存。
|
||||
|
||||
|
||||
签名验证
|
||||
|
||||
@ -8,7 +8,7 @@ OTA 流程概览
|
||||
|
||||
OTA 升级机制可以让设备在固件正常运行时根据接收数据（如通过 Wi-Fi 或蓝牙）进行自我更新。
|
||||
|
||||
要运行 OTA 机制，需配置设备的 :doc:`分区表 <../../api-guides/partition-tables>`，该分区表至少包括两个 OTA 应用程序分区（即 ``ota_0`` 和 ``ota_1``）和一个 OTA 数据分区。
|
||||
要运行 OTA 机制，需配置设备的 :doc:`../../api-guides/partition-tables`，该分区表至少包括两个 OTA 应用程序分区（即 ``ota_0`` 和 ``ota_1``）和一个 OTA 数据分区。
|
||||
|
||||
OTA 功能启动后，向当前未用于启动的 OTA 应用分区写入新的应用固件镜像。镜像验证后，OTA 数据分区更新，指定在下一次启动时使用该镜像。
|
||||
|
||||
@ -17,7 +17,7 @@ OTA 功能启动后，向当前未用于启动的 OTA 应用分区写入新的
|
||||
OTA 数据分区
|
||||
------------
|
||||
|
||||
所有使用 OTA 功能项目，其 :doc:`分区表 <../../api-guides/partition-tables>` 必须包含一个 OTA 数据分区（类型为 ``data``，子类型为 ``ota``）。
|
||||
所有使用 OTA 功能项目，其 :doc:`../../api-guides/partition-tables` 必须包含一个 OTA 数据分区（类型为 ``data``，子类型为 ``ota``）。
|
||||
|
||||
工厂启动设置下，OTA 数据分区中应没有数据（所有字节擦写成 0xFF）。如果分区表中有工厂应用程序，ESP-IDF 软件引导加载程序会启动工厂应用程序。如果分区表中没有工厂应用程序，则启动第一个可用的 OTA 分区（通常是 ``ota_0``）。
|
||||
|
||||
@ -201,7 +201,7 @@ Kconfig 中的 :ref:`CONFIG_BOOTLOADER_APP_ROLLBACK_ENABLE` 可以帮助用户
|
||||
OTA 工具 ``otatool.py``
|
||||
----------------------------
|
||||
|
||||
``app_update`` 组件中有 :component_file:`otatool.py<app_update/otatool.py>` 工具，用于在目标设备上完成下列 OTA 分区相关操作：
|
||||
``app_update`` 组件中有 :component_file:`app_update/otatool.py` 工具，用于在目标设备上完成下列 OTA 分区相关操作：
|
||||
|
||||
- 读取 otadata 分区 (read_otadata)
|
||||
- 擦除 otadata 分区，将设备复位至工厂应用程序 (erase_otadata)
|
||||
@ -297,10 +297,10 @@ Python API
|
||||
相关文档
|
||||
--------
|
||||
|
||||
* :doc:`分区表 <../../api-guides/partition-tables>`
|
||||
* :doc:`分区表 API <../storage/partition>`
|
||||
* :doc:`低层 SPI Flash API <../peripherals/spi_flash/index>`
|
||||
* :doc:`ESP HTTPS OTA <esp_https_ota>`
|
||||
* :doc:`../../api-guides/partition-tables`
|
||||
* :doc:`../storage/partition`
|
||||
* :doc:`../peripherals/spi_flash/index`
|
||||
* :doc:`esp_https_ota`
|
||||
|
||||
应用程序示例
|
||||
------------
|
||||
|
||||
@ -5,7 +5,7 @@
|
||||
|
||||
{IDF_TARGET_RTC_CLK_FRE:default="未更新", esp32="150 kHz", esp32s2="90 kHz", esp32s3="136 kHz", esp32c3="136 kHz", esp32c2="136 kHz", esp32c6="150 kHz", esp32h2="150 kHz"}
|
||||
{IDF_TARGET_INT_OSC_FRE:default="未更新", esp32="8.5 MHz", esp32s2="8.5 MHz", esp32s3="17.5 MHz", esp32c3="17.5 MHz", esp32c2="17.5 MHz", esp32c6="20 MHz"}
|
||||
{IDF_TARGET_INT_OSC_FRE_DIVIDED:default="未更新", esp32="~33 kHz", esp32s2="~33 kHz", esp32s3="~68 kHz", esp32c3="~68 kHz", esp32c2="~68 kHz"}
|
||||
{IDF_TARGET_INT_OSC_FRE_DIVIDED:default="未更新", esp32="约 33 kHz", esp32s2="约 33 kHz", esp32s3="约 68 kHz", esp32c3="约 68 kHz", esp32c2="约 68 kHz"}
|
||||
{IDF_TARGET_EXT_CRYSTAL_PIN:default="未更新", esp32="32K_XP 和 32K_XN", esp32s2="XTAL_32K_P 和 XTAL_32K_N", esp32s3="XTAL_32K_P 和 XTAL_32K_N", esp32c3="XTAL_32K_P 和 XTAL_32K_N", esp32c6="XTAL_32K_P 和 XTAL_32K_N", esp32h2="XTAL_32K_P 和 XTAL_32K_N"}
|
||||
{IDF_TARGET_EXT_OSC_PIN:default="未更新", esp32="32K_XN", esp32s2="XTAL_32K_P", esp32s3="XTAL_32K_P", esp32c3="XTAL_32K_P", esp32c2="GPIO0", esp32c6="XTAL_32K_P"}
|
||||
{IDF_TARGET_HARDWARE_DESIGN_URL:default="未更新", esp32="`ESP32 硬件设计指南 <https://www.espressif.com/sites/default/files/documentation/esp32_hardware_design_guidelines_cn.pdf#page=10>`_", esp32s2="`ESP32-S2 硬件设计指南 <https://www.espressif.com/sites/default/files/documentation/esp32-s2_hardware_design_guidelines_cn.pdf#page=10>`_", esp32s3="`ESP32-S3 硬件设计指南 <https://www.espressif.com/sites/default/files/documentation/esp32-s3_hardware_design_guidelines_cn.pdf#page=12>`_", esp32c3="`ESP32-C3 硬件设计指南 <https://www.espressif.com/sites/default/files/documentation/esp32-c3_hardware_design_guidelines_cn.pdf#page=9>`_", esp32c2="`ESP8684 硬件设计指南 <https://www.espressif.com/sites/default/files/documentation/esp8684_hardware_design_guidelines_cn.pdf#page=10>`_", esp32c6="`ESP32-C6 硬件设计指南 <https://www.espressif.com/sites/default/files/documentation/esp32-c6_hardware_design_guidelines_cn.pdf#page=12>`_", esp32h2="`ESP32-H2 硬件设计指南 <https://www.espressif.com/sites/default/files/documentation/esp32-h2_hardware_design_guidelines_cn.pdf#page=11>`_"}
|
||||
|
||||
@ -67,7 +67,7 @@
|
||||
|
||||
.. attention::
|
||||
|
||||
如果使用的是 ESP32-DevKitC（板载 ESP32-SOLO-1 模组）或 ESP32-DevKitM-1（板载 ESP32-MINI-1(1U) 模组），请在烧写示例程序前，前往 ``menuconfig`` 中使能单核模式 (:ref:`CONFIG_FREERTOS_UNICORE`)。
|
||||
如果使用的是 ESP32-DevKitC（板载 ESP32-SOLO-1 模组）或 ESP32-DevKitM-1（板载 ESP32-MINI-1/1U 模组），请在烧写示例程序前，前往 ``menuconfig`` 中使能单核模式 (:ref:`CONFIG_FREERTOS_UNICORE`)。
|
||||
|
||||
.. note::
|
||||
|
||||
|
||||
@ -67,7 +67,7 @@ Windows
|
||||
|
||||
.. attention::
|
||||
|
||||
如果使用的是 ESP32-DevKitC（板载 ESP32-SOLO-1 模组）或 ESP32-DevKitM-1（板载 ESP32-MINI-1(1U) 模组），请在烧写示例程序前，前往 ``menuconfig`` 中使能单核模式（:ref:`CONFIG_FREERTOS_UNICORE`）。
|
||||
如果使用的是 ESP32-DevKitC（板载 ESP32-SOLO-1 模组）或 ESP32-DevKitM-1（板载 ESP32-MINI-1/1U 模组），请在烧写示例程序前，前往 ``menuconfig`` 中使能单核模式（:ref:`CONFIG_FREERTOS_UNICORE`）。
|
||||
|
||||
.. note::
|
||||
|
||||
|
||||
@ -6,11 +6,11 @@ ESP32-PICO-DevKitM-2
|
||||
概述
|
||||
======
|
||||
|
||||
ESP32-PICO-DevKitM-2 是一款基于 `ESP32 <https://www.espressif.com/zh-hans/products/socs/esp32>`_ 的乐鑫开发板，板上搭载 `ESP32-PICO-MINI-02(02U) <https://www.espressif.com/zh-hans/products/modules>`_ 模组。ESP32-PICO-MINI-02(02U) 模组具备完整的 Wi-Fi 和蓝牙功能。
|
||||
ESP32-PICO-DevKitM-2 是一款基于 `ESP32 <https://www.espressif.com/zh-hans/products/socs/esp32>`_ 的乐鑫开发板，板上搭载 `ESP32-PICO-MINI-02/02U <https://www.espressif.com/zh-hans/products/modules>`_ 模组。ESP32-PICO-MINI-02/02U 模组具备完整的 Wi-Fi 和蓝牙功能。
|
||||
|
||||
ESP32-PICO-DevKitM-2 开发板同时集成了 USB-to-UART 桥接电路，方便开发人员直接通过 PC 的 USB 端口直接进行固件烧录和调试。
|
||||
|
||||
为方便硬件连接，ESP32-PICO-MINI-02(02U) 上的所有 IO 信号和系统电源管脚均引出至开发板两侧焊盘 (18 x 0.1")。上述 18 个焊盘也均引出至排针，可使用杜邦线连接。
|
||||
为方便硬件连接，ESP32-PICO-MINI-02/02U 上的所有 IO 信号和系统电源管脚均引出至开发板两侧焊盘 (18 x 0.1")。上述 18 个焊盘也均引出至排针，可使用杜邦线连接。
|
||||
|
||||
.. note::
|
||||
|
||||
|
||||
@ -6,7 +6,7 @@ ESP32-DevKitM-1
|
||||
|
||||
本指南将介绍如何使用 ESP32-DevKitM-1，并提供更多关于此开发板的信息。
|
||||
|
||||
ESP32-DevKitM-1 是乐鑫推出的一款基于 ESP32-MINI-1(1U) 模组的入门级开发板。板上模组大部分管脚均已引出至两侧排针，用户可根据实际需求，通过跳线轻松连接多种外围设备，同时也可将开发板插在面包板上使用。
|
||||
ESP32-DevKitM-1 是乐鑫推出的一款基于 ESP32-MINI-1/1U 模组的入门级开发板。板上模组大部分管脚均已引出至两侧排针，用户可根据实际需求，通过跳线轻松连接多种外围设备，同时也可将开发板插在面包板上使用。
|
||||
|
||||
|
||||
+------------------------+-------------------------+
|
||||
|
||||
@ -1,10 +1,10 @@
|
||||
WiFi
|
||||
====
|
||||
Wi-Fi
|
||||
=====
|
||||
|
||||
:link_to_translation:`en:[English]`
|
||||
|
||||
|
||||
WiFi企业级安全
|
||||
Wi-Fi 企业级安全
|
||||
------------------------
|
||||
|
||||
在 `esp_wpa2.h` 中定义的API已被弃用，请使用来自 `esp_eap_client.h` 的新API。
|
||||
在 `esp_wpa2.h` 中定义的 API 已弃用，请使用来自 `esp_eap_client.h` 的新 API。
|
||||
|
||||
Loading…
Reference in New Issue
Block a user