mirror of
https://github.com/espressif/esp-idf.git
synced 2025-11-03 00:21:44 +01:00
docs: update format issues left in EN docs
This commit is contained in:
caixinying-git
BOT
@@ -18,8 +18,8 @@ Application developers can open a terminal-based project configuration menu with
|
||||
|
||||
After being updated, this configuration is saved in the ``sdkconfig`` file under the project root directory. Based on ``sdkconfig``, application build targets will generate the ``sdkconfig.h`` file under the build directory, and will make the ``sdkconfig`` options available to the project build system and source files.
|
||||
|
||||
Using sdkconfig.defaults
|
||||
========================
|
||||
Using ``sdkconfig.defaults``
|
||||
============================
|
||||
|
||||
In some cases, for example, when the ``sdkconfig`` file is under revision control, it may be inconvenient for the build system to change the ``sdkconfig`` file. The build system offers a solution to prevent it from happening, which is to create the ``sdkconfig.defaults`` file. This file is never touched by the build system, and can be created manually or automatically. It contains all the options which matter to the given application and are different from the default ones. The format is the same as that of the ``sdkconfig`` file. ``sdkconfig.defaults`` can be created manually when one remembers all the changed configuration, or it can be generated automatically by running the ``idf.py save-defconfig`` command.
|
||||
|
||||
|
||||
@@ -76,7 +76,7 @@ The application can access the ESP-WIFI-MESH stack directly without having to go
|
||||
|
||||
.. _mesh-writing-mesh-application:
|
||||
|
||||
Writing an ESP-WIFI-MESH Application
|
||||
Writing an ESP-WIFI-MESH Application
|
||||
-------------------------------------------
|
||||
|
||||
The prerequisites for starting ESP-WIFI-MESH is to initialize LwIP and Wi-Fi, The following code snippet demonstrates the necessary prerequisite steps before ESP-WIFI-MESH itself can be initialized.
|
||||
@@ -126,22 +126,22 @@ Configuring an ESP-WIFI-MESH Network
|
||||
ESP-WIFI-MESH is configured via :cpp:func:`esp_mesh_set_config` which receives its arguments using the :cpp:type:`mesh_cfg_t` structure. The structure contains the following parameters used to configure ESP-WIFI-MESH:
|
||||
|
||||
|
||||
.. list-table::
|
||||
:header-rows: 1
|
||||
:widths: 15 25
|
||||
|
||||
* - Parameter
|
||||
.. list-table::
|
||||
:header-rows: 1
|
||||
:widths: 15 25
|
||||
|
||||
* - Parameter
|
||||
- Description
|
||||
|
||||
|
||||
* - Channel
|
||||
- Range from 1 to 14
|
||||
|
||||
|
||||
* - Mesh ID
|
||||
- ID of ESP-WIFI-MESH Network, see :cpp:type:`mesh_addr_t`
|
||||
|
||||
* - Router
|
||||
- Router Configuration, see :cpp:type:`mesh_router_t`
|
||||
|
||||
- ID of ESP-WIFI-MESH Network, see :cpp:type:`mesh_addr_t`
|
||||
|
||||
* - Router
|
||||
- Router Configuration, see :cpp:type:`mesh_router_t`
|
||||
|
||||
* - Mesh AP
|
||||
- Mesh AP Configuration, see :cpp:type:`mesh_ap_cfg_t`
|
||||
|
||||
@@ -236,7 +236,7 @@ ESP-WIFI-MESH will attempt to maintain the node's current Wi-Fi state when enabl
|
||||
| | | - Nodes previously scanning for a parent nodes will stop scanning. Call :cpp:func:`esp_mesh_connect` to restart. |
|
||||
| +--------------+------------------------------------------------------------------------------------------------------------------+
|
||||
| | Y | - A root node already connected to router will stay connected. |
|
||||
| | | - A root node disconnected from router will need to call :cpp:func:`esp_mesh_connect` to reconnect. |
|
||||
| | | - A root node disconnected from router will need to call :cpp:func:`esp_mesh_connect` to reconnect. |
|
||||
+---------------+--------------+------------------------------------------------------------------------------------------------------------------+
|
||||
| Y | N | - Nodes without a parent node will automatically select a preferred parent and connect. |
|
||||
| | | - Nodes already connected to a parent node will disconnect, reselect a preferred parent node, and connect. |
|
||||
@@ -273,7 +273,7 @@ Therefore, application calls to Wi-Fi APIs should be placed in between calls of
|
||||
|
||||
//Stop any scans already in progress
|
||||
esp_wifi_scan_stop();
|
||||
//Manually start scan. Will automatically stop when run to completion
|
||||
//Manually start scan. Will automatically stop when run to completion
|
||||
esp_wifi_scan_start();
|
||||
|
||||
//Process scan results
|
||||
@@ -304,9 +304,9 @@ Application Examples
|
||||
|
||||
ESP-IDF contains these ESP-WIFI-MESH example projects:
|
||||
|
||||
:example:`The Internal Communication Example<mesh/internal_communication>` demonstrates how to set up a ESP-WIFI-MESH network and have the root node send a data packet to every node within the network.
|
||||
:example:`The Internal Communication Example <mesh/internal_communication>` demonstrates how to set up a ESP-WIFI-MESH network and have the root node send a data packet to every node within the network.
|
||||
|
||||
:example:`The Manual Networking Example<mesh/manual_networking>` demonstrates how to use ESP-WIFI-MESH without the self-organizing features. This example shows how to program a node to manually scan for a list of potential parent nodes and select a parent node based on custom criteria.
|
||||
:example:`The Manual Networking Example <mesh/manual_networking>` demonstrates how to use ESP-WIFI-MESH without the self-organizing features. This example shows how to program a node to manually scan for a list of potential parent nodes and select a parent node based on custom criteria.
|
||||
|
||||
|
||||
.. ------------------------- ESP-WIFI-MESH API Reference ---------------------------
|
||||
|
||||
@@ -457,7 +457,7 @@ Custom PHY Driver
|
||||
|
||||
There are multiple PHY manufacturers with wide portfolios of chips available. The ESP-IDF already supports several PHY chips however one can easily get to a point where none of them satisfies the user's actual needs due to price, features, stock availability, etc.
|
||||
|
||||
Luckily, a management interface between EMAC and PHY is standardized by IEEE 802.3 in Section 22.2.4 Management Functions. It defines provisions of the so-called “MII Management Interface” to control the PHY and gather status from the PHY. A set of management registers is defined to control chip behavior, link properties, auto-negotiation configuration, etc. This basic management functionality is addressed by :component_file:`esp_eth/src/esp_eth_phy_802_3.c` in ESP-IDF and so it makes the creation of a new custom PHY chip driver quite a simple task.
|
||||
Luckily, a management interface between EMAC and PHY is standardized by IEEE 802.3 in Section 22.2.4 Management Functions. It defines provisions of the so-called "MII Management Interface" to control the PHY and gather status from the PHY. A set of management registers is defined to control chip behavior, link properties, auto-negotiation configuration, etc. This basic management functionality is addressed by :component_file:`esp_eth/src/esp_eth_phy_802_3.c` in ESP-IDF and so it makes the creation of a new custom PHY chip driver quite a simple task.
|
||||
|
||||
.. note::
|
||||
Always consult with PHY datasheet since some PHY chips may not comply with IEEE 802.3, Section 22.2.4. It does not mean you are not able to create a custom PHY driver, but it just requires more effort. You will have to define all PHY management functions.
|
||||
|
||||
@@ -162,7 +162,7 @@ To be able to use the ESP-NETIF L2 TAP interface, it needs to be enabled in Kcon
|
||||
|
||||
``open()``
|
||||
^^^^^^^^^^
|
||||
Once the ESP-NETIF L2 TAP is registered, it can be opened at path name “/dev/net/tap”. The same path name can be opened multiple times up to :ref:`CONFIG_ESP_NETIF_L2_TAP_MAX_FDS` and multiple file descriptors with a different configuration may access the Data Link Layer frames.
|
||||
Once the ESP-NETIF L2 TAP is registered, it can be opened at path name "/dev/net/tap". The same path name can be opened multiple times up to :ref:`CONFIG_ESP_NETIF_L2_TAP_MAX_FDS` and multiple file descriptors with a different configuration may access the Data Link Layer frames.
|
||||
|
||||
The ESP-NETIF L2 TAP can be opened with the ``O_NONBLOCK`` file status flag to make sure the ``read()`` does not block. Note that the ``write()`` may block in the current implementation when accessing a Network interface since it is a shared resource among multiple ESP-NETIF L2 TAP file descriptors and IP stack, and there is currently no queuing mechanism deployed. The file status flag can be retrieved and modified using ``fcntl()``.
|
||||
|
||||
@@ -231,7 +231,7 @@ A raw Data Link Layer frame can be sent to Network Interface via opened and conf
|
||||
* - 6 B
|
||||
- 6 B
|
||||
- 2 B
|
||||
- 0-1486 B
|
||||
- 0-1486 B
|
||||
|
||||
In other words, there is no additional frame processing performed by the ESP-NETIF L2 TAP interface. It only checks the Ethernet type of the frame is the same as the filter configured in the file descriptor. If the Ethernet type is different, an error is returned and the frame is not sent. Note that the ``write()`` may block in the current implementation when accessing a Network interface since it is a shared resource among multiple ESP-NETIF L2 TAP file descriptors and IP stack, and there is currently no queuing mechanism deployed.
|
||||
|
||||
@@ -328,7 +328,7 @@ Then we start the service normally with :cpp:func:`esp_netif_sntp_start()`.
|
||||
ESP-NETIF Programmer's Manual
|
||||
-----------------------------
|
||||
|
||||
Please refer to the following example to understand the initialization process of the default interface:
|
||||
Please refer to the following example to understand the initialization process of the default interface:
|
||||
|
||||
|
||||
.. only:: SOC_WIFI_SUPPORTED
|
||||
|
||||
@@ -15,7 +15,7 @@ As shown in the diagram, the following three API functions for the packet data p
|
||||
* :cpp:func:`esp_netif_free_rx_buffer()`
|
||||
* :cpp:func:`esp_netif_receive()`
|
||||
|
||||
The first two functions for transmitting and freeing the rx buffer are provided as callbacks, i.e.， they get called from esp-netif (and its underlying TCP/IP stack) and I/O driver provides their implementation.
|
||||
The first two functions for transmitting and freeing the rx buffer are provided as callbacks, i.e., they get called from esp-netif (and its underlying TCP/IP stack) and I/O driver provides their implementation.
|
||||
|
||||
The receiving function on the other hand gets called from the I/O driver, so that the driver's code simply calls :cpp:func:`esp_netif_receive()` on a new data received event.
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ Clock Tree
|
||||
|
||||
{IDF_TARGET_RC_FAST_ADJUSTED_FREQ: default="8.5", esp32c3="17.5", esp32s3="17.5", esp32c2="17.5", esp32c6="17.5"}
|
||||
|
||||
{IDF_TARGET_XTAL_FREQ: default="40", esp32="2~40", esp32c2="40/26", esp32h2="32"}
|
||||
{IDF_TARGET_XTAL_FREQ: default="40", esp32="2 ~ 40", esp32c2="40/26", esp32h2="32"}
|
||||
|
||||
{IDF_TARGET_RC_SLOW_VAGUE_FREQ: default="136", esp32="150", esp32s2="90"}
|
||||
|
||||
|
||||
@@ -187,7 +187,7 @@ To allocate a capture timer, you can call the :cpp:func:`mcpwm_new_capture_timer
|
||||
- :cpp:member:`mcpwm_capture_timer_config_t::clk_src` sets the clock source of the capture timer.
|
||||
- :cpp:member:`mcpwm_capture_timer_config_t::resolution_hz` The driver internally will set a proper divider based on the clock source and the resolution. If it is set to ``0``, the driver will pick an appropriate resolution on its own, and you can subsequently view the current timer resolution via :cpp:func:`mcpwm_capture_timer_get_resolution`.
|
||||
|
||||
.. only:: not SOC_MCPWM_CAPTURE_CLK_FROM_GROUP
|
||||
.. only:: not SOC_MCPWM_CAPTURE_CLK_FROM_GROUP
|
||||
|
||||
.. note::
|
||||
|
||||
@@ -209,7 +209,7 @@ The :cpp:func:`mcpwm_new_capture_channel` will return a pointer to the allocated
|
||||
|
||||
On the contrary, calling :cpp:func:`mcpwm_del_capture_channel` and :cpp:func:`mcpwm_del_capture_timer` will free the allocated capture channel and timer object accordingly.
|
||||
|
||||
MCPWM interrupt priority
|
||||
MCPWM Interrupt Priority
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
MCPWM allows configuring interrupts separately for timer, operator, comparator, fault, and capture events. The interrupt priority is determined by the respective ``config_t::intr_priority``. Additionally, events within the same MCPWM group share a common interrupt source. When registering multiple interrupt events, the interrupt priorities need to remain consistent.
|
||||
@@ -335,7 +335,7 @@ One generator can set action on fault based trigger events, by calling :cpp:func
|
||||
|
||||
When no free trigger slot is left in the operator to which the generator belongs, this function will return the :c:macro:`ESP_ERR_NOT_FOUND` error. [1]_
|
||||
|
||||
The trigger only support GPOI fault. when the input is not a GPIO fault, this function will return the :c:macro:`ESP_ERR_NOT_SUPPORTED` error.
|
||||
The trigger only support GPOI fault. when the input is not a GPIO fault, this function will return the :c:macro:`ESP_ERR_NOT_SUPPORTED` error.
|
||||
|
||||
There is a helper macro :c:macro:`MCPWM_GEN_FAULT_EVENT_ACTION` to simplify the construction of a trigger event action entry.
|
||||
|
||||
|
||||
@@ -48,14 +48,14 @@ Install PCNT Unit
|
||||
To install a PCNT unit, there is a configuration structure that needs to be given in advance: :cpp:type:`pcnt_unit_config_t`:
|
||||
|
||||
- :cpp:member:`pcnt_unit_config_t::low_limit` and :cpp:member:`pcnt_unit_config_t::high_limit` specify the range for the internal hardware counter. The counter will reset to zero automatically when it crosses either the high or low limit.
|
||||
- :cpp:member:`pcnt_unit_config_t::accum_count` sets whether to create an internal accumulator for the counter. This is helpful when you want to extend the counter's width, which by default is 16bit at most, defined in the hardware. See also :ref:`pcnt-compensate-overflow-loss` for how to use this feature to compensate the overflow loss.
|
||||
- :cpp:member:`pcnt_unit_config_t::accum_count` sets whether to create an internal accumulator for the counter. This is helpful when you want to extend the counter's width, which by default is 16 bit at most, defined in the hardware. See also :ref:`pcnt-compensate-overflow-loss` for how to use this feature to compensate the overflow loss.
|
||||
- :cpp:member:`pcnt_unit_config_t::intr_priority` sets the priority of the interrupt. If it is set to ``0``, the driver will allocate an interrupt with a default priority. Otherwise, the driver will use the given priority.
|
||||
|
||||
.. note::
|
||||
|
||||
Since all PCNT units share the same interrupt source, when installing multiple PCNT units make sure that the interrupt priority :cpp:member:`pcnt_unit_config_t::intr_priority` is the same for each unit.
|
||||
|
||||
Unit allocation and initialization is done by calling a function :cpp:func:`pcnt_new_unit` with :cpp:type:`pcnt_unit_config_t` as an input parameter. The function will return a PCNT unit handle only when it runs correctly. Specifically, when there are no more free PCNT units in the pool (i.e. unit resources have been used up), then this function will return :c:macro:`ESP_ERR_NOT_FOUND` error. The total number of available PCNT units is recorded by :c:macro:`SOC_PCNT_UNITS_PER_GROUP` for reference.
|
||||
Unit allocation and initialization is done by calling a function :cpp:func:`pcnt_new_unit` with :cpp:type:`pcnt_unit_config_t` as an input parameter. The function will return a PCNT unit handle only when it runs correctly. Specifically, when there are no more free PCNT units in the pool (i.e., unit resources have been used up), then this function will return :c:macro:`ESP_ERR_NOT_FOUND` error. The total number of available PCNT units is recorded by :c:macro:`SOC_PCNT_UNITS_PER_GROUP` for reference.
|
||||
|
||||
If a previously created PCNT unit is no longer needed, it is recommended to recycle the resource by calling :cpp:func:`pcnt_del_unit`. Which in return allows the underlying unit hardware to be used for other purposes. Before deleting a PCNT unit, one should ensure the following prerequisites:
|
||||
|
||||
@@ -192,7 +192,7 @@ This function should be called when the unit is in the init state. Otherwise, it
|
||||
|
||||
.. note::
|
||||
|
||||
The glitch filter is clocked from APB. For the counter not to miss any pulses, the maximum glitch width should be longer than one APB_CLK cycle (usually 12.5 ns if APB equals 80MHz). As the APB frequency would be changed after DFS (Dynamic Frequency Scaling) enabled, which means the filter does not work as expect in that case. So the driver installs a PM lock for PCNT unit during the first time you enable the glitch filter. For more information related to power management strategy used in PCNT driver, please see :ref:`pcnt-power-management`.
|
||||
The glitch filter is clocked from APB. For the counter not to miss any pulses, the maximum glitch width should be longer than one APB_CLK cycle (usually 12.5 ns if APB equals 80 MHz). As the APB frequency would be changed after DFS (Dynamic Frequency Scaling) enabled, which means the filter does not work as expect in that case. So the driver installs a PM lock for PCNT unit during the first time you enable the glitch filter. For more information related to power management strategy used in PCNT driver, please see :ref:`pcnt-power-management`.
|
||||
|
||||
.. code:: c
|
||||
|
||||
|
||||
@@ -127,7 +127,7 @@ Kconfig Options
|
||||
|
||||
.. _convert_to_analog_signal:
|
||||
|
||||
Convert to an analog signal (Optional)
|
||||
Convert to an Analog Signal (Optional)
|
||||
--------------------------------------
|
||||
|
||||
Typically, if a Sigma-Delta signal is connected to an LED to adjust the brightness, you do not have to add any filter between them, because our eyes have their own low-pass filters for changes in light intensity. However, if you want to check the real voltage or watch the analog waveform, you need to design an analog low-pass filter. Also, it is recommended to use an active filter instead of a passive filter to gain better isolation and not lose too much voltage.
|
||||
|
||||
@@ -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 (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).
|
||||
- **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.
|
||||
|
||||
|
||||
@@ -45,7 +45,7 @@ The host should initialize the {IDF_TARGET_NAME} SDIO slave according to the sta
|
||||
|
||||
1. SDIO reset
|
||||
|
||||
CMD52 (Write 0x6=0x8)
|
||||
CMD52 (Write 0x6 = 0x8)
|
||||
|
||||
2. SD reset
|
||||
|
||||
@@ -63,9 +63,9 @@ The host should initialize the {IDF_TARGET_NAME} SDIO slave according to the sta
|
||||
|
||||
**Example:**
|
||||
|
||||
Arg of R4 after first CMD5 (arg=0x00000000) is 0xXXFFFF00.
|
||||
Arg of R4 after first CMD5 (arg = 0x00000000) is 0xXXFFFF00.
|
||||
|
||||
Keep sending CMD5 with arg=0x00FFFF00 until the R4 shows card ready (arg bit 31=1).
|
||||
Keep sending CMD5 with arg = 0x00FFFF00 until the R4 shows card ready (arg bit 31 = 1).
|
||||
|
||||
5. Set address
|
||||
|
||||
@@ -83,35 +83,35 @@ The host should initialize the {IDF_TARGET_NAME} SDIO slave according to the sta
|
||||
|
||||
7. Select 4-bit mode (optional)
|
||||
|
||||
CMD52 (Write 0x07=0x02)
|
||||
CMD52 (Write 0x07 = 0x02)
|
||||
|
||||
8. Enable func1
|
||||
|
||||
CMD52 (Write 0x02=0x02)
|
||||
CMD52 (Write 0x02 = 0x02)
|
||||
|
||||
9. Enable SDIO interrupt (required if interrupt line (DAT1) is used)
|
||||
|
||||
CMD52 (Write 0x04=0x03)
|
||||
CMD52 (Write 0x04 = 0x03)
|
||||
|
||||
10. Set Func0 blocksize (optional, default value is 512 (0x200))
|
||||
|
||||
CMD52/53 (Read 0x10~0x11)
|
||||
CMD52/53 (Read 0x10 ~ 0x11)
|
||||
|
||||
CMD52/53 (Write 0x10=0x00)
|
||||
CMD52/53 (Write 0x10 = 0x00)
|
||||
|
||||
CMD52/53 (Write 0x11=0x02)
|
||||
CMD52/53 (Write 0x11 = 0x02)
|
||||
|
||||
CMD52/53 (Read 0x10~0x11, read to check the final value)
|
||||
CMD52/53 (Read 0x10 ~ 0x11, read to check the final value)
|
||||
|
||||
11. Set Func1 blocksize (optional, default value is 512 (0x200))
|
||||
|
||||
CMD52/53 (Read 0x110~0x111)
|
||||
CMD52/53 (Read 0x110 ~ 0x111)
|
||||
|
||||
CMD52/53 (Write 0x110=0x00)
|
||||
CMD52/53 (Write 0x110 = 0x00)
|
||||
|
||||
CMD52/53 (Write 0x111=0x02)
|
||||
CMD52/53 (Write 0x111 = 0x02)
|
||||
|
||||
CMD52/53 (Read 0x110~0x111, read to check the final value)
|
||||
CMD52/53 (Read 0x110 ~ 0x111, read to check the final value)
|
||||
|
||||
|
||||
.. _esp_slave_protocol_layer:
|
||||
@@ -177,8 +177,8 @@ The slave responds to data that has a length equal to the length field of CMD53.
|
||||
|
||||
In order to achieve higher efficiency when accessing the FIFO by an arbitrary length, the block and byte modes of CMD53 can be used in combination. For example, given that the block size is set to 512 by default, you can write or get 1031 bytes of data from the FIFO by doing the following:
|
||||
|
||||
1. Send CMD53 in block mode, block count = 2 (1024 bytes) to address 0x1F3F9=0x1F800-**1031**.
|
||||
2. Then send CMD53 in byte mode, byte count = 8 (or 7 if your controller supports that) to address 0x1F7F9=0x1F800-**7**.
|
||||
1. Send CMD53 in block mode, block count = 2 (1024 bytes) to address 0x1F3F9 = 0x1F800 - **1031**.
|
||||
2. Then send CMD53 in byte mode, byte count = 8 (or 7 if your controller supports that) to address 0x1F7F9 = 0x1F800 - **7**.
|
||||
|
||||
.. _esp_sdio_slave_interrupts:
|
||||
|
||||
|
||||
@@ -189,7 +189,7 @@ The following events may be posted by the MQTT client:
|
||||
* ``MQTT_EVENT_SUBSCRIBED``: The broker has acknowledged the client's subscribe request. The event data contains the message ID of the subscribe message.
|
||||
* ``MQTT_EVENT_UNSUBSCRIBED``: The broker has acknowledged the client's unsubscribe request. The event data contains the message ID of the unsubscribe message.
|
||||
* ``MQTT_EVENT_PUBLISHED``: The broker has acknowledged the client's publish message. This is only posted for QoS level 1 and 2, as level 0 does not use acknowledgements. The event data contains the message ID of the publish message.
|
||||
* ``MQTT_EVENT_DATA``: The client has received a publish message. The event data contains: message ID, name of the topic it was published to, received data and its length. For data that exceeds the internal buffer, multiple ``MQTT_EVENT_DATA`` events are posted and :cpp:member:`current_data_offset <esp_mqtt_event_t::current_data_offset>` and :cpp:member:`total_data_len<esp_mqtt_event_t::total_data_len>` from event data updated to keep track of the fragmented message.
|
||||
* ``MQTT_EVENT_DATA``: The client has received a publish message. The event data contains: message ID, name of the topic it was published to, received data and its length. For data that exceeds the internal buffer, multiple ``MQTT_EVENT_DATA`` events are posted and :cpp:member:`current_data_offset <esp_mqtt_event_t::current_data_offset>` and :cpp:member:`total_data_len <esp_mqtt_event_t::total_data_len>` from event data updated to keep track of the fragmented message.
|
||||
* ``MQTT_EVENT_ERROR``: The client has encountered an error. The field :cpp:type:`error_handle <esp_mqtt_error_codes_t>` in the event data contains :cpp:type:`error_type <esp_mqtt_error_type_t>` that can be used to identify the error. The type of error determines which parts of the :cpp:type:`error_handle <esp_mqtt_error_codes_t>` struct is filled.
|
||||
|
||||
API Reference
|
||||
|
||||
@@ -101,7 +101,7 @@ If you want to use :cpp:func:`select` with a file descriptor belonging to a non-
|
||||
:cpp:func:`end_select` is called to stop/deinitialize/free the environment which was setup by :cpp:func:`start_select`.
|
||||
|
||||
.. note::
|
||||
|
||||
|
||||
:cpp:func:`end_select` might be called without a previous :cpp:func:`start_select` call in some rare circumstances. :cpp:func:`end_select` should fail gracefully if this is the case (i.e., should not crash but return an error instead).
|
||||
|
||||
Please refer to the reference implementation for the UART peripheral in :component_file:`vfs/vfs_uart.c` and most particularly to the functions :cpp:func:`esp_vfs_dev_uart_register`, :cpp:func:`uart_start_select`, and :cpp:func:`uart_end_select` for more information.
|
||||
@@ -180,8 +180,8 @@ File Descriptors
|
||||
File descriptors are small positive integers from ``0`` to ``FD_SETSIZE - 1``, where ``FD_SETSIZE`` is defined in newlib's ``sys/types.h``. The largest file descriptors (configured by ``CONFIG_LWIP_MAX_SOCKETS``) are reserved for sockets. The VFS component contains a lookup-table called ``s_fd_table`` for mapping global file descriptors to VFS driver indexes registered in the ``s_vfs`` array.
|
||||
|
||||
|
||||
Standard IO Streams (stdin, stdout, stderr)
|
||||
-------------------------------------------
|
||||
Standard IO Streams (``stdin``, ``stdout``, ``stderr``)
|
||||
-------------------------------------------------------
|
||||
|
||||
If the menuconfig option ``UART for console output`` is not set to ``None``, then ``stdin``, ``stdout``, and ``stderr`` are configured to read from, and write to, a UART. It is possible to use UART0 or UART1 for standard IO. By default, UART0 is used with 115200 baud rate; TX pin is GPIO1; RX pin is GPIO3. These parameters can be changed in menuconfig.
|
||||
|
||||
@@ -216,8 +216,8 @@ Such a design has the following consequences:
|
||||
- Closing default ``stdin``, ``stdout``, or ``stderr`` using ``fclose`` closes the ``FILE`` stream object, which will affect all other tasks.
|
||||
- To change the default ``stdin``, ``stdout``, ``stderr`` streams for new tasks, modify ``_GLOBAL_REENT->_stdin`` (``_stdout``, ``_stderr``) before creating the task.
|
||||
|
||||
Event fds
|
||||
-------------------------------------------
|
||||
``eventfd()``
|
||||
-------------
|
||||
|
||||
``eventfd()`` call is a powerful tool to notify a ``select()`` based loop of custom events. The ``eventfd()`` implementation in ESP-IDF is generally the same as described in `man(2) eventfd <https://man7.org/linux/man-pages/man2/eventfd.2.html>`_ except for:
|
||||
|
||||
|
||||
@@ -90,8 +90,8 @@ Application Description
|
||||
The ``DROM`` segment of the application binary starts with the :cpp:type:`esp_app_desc_t` structure which carries specific fields describing the application:
|
||||
|
||||
* ``magic_word`` - the magic word for the esp_app_desc structure.
|
||||
* ``secure_version`` - see :doc:`Anti-rollback</api-reference/system/ota>`.
|
||||
* ``version`` - see :doc:`App version</api-reference/system/misc_system_api>`. ``*``
|
||||
* ``secure_version`` - see :doc:`Anti-rollback </api-reference/system/ota>`.
|
||||
* ``version`` - see :doc:`App version </api-reference/system/misc_system_api>`. ``*``
|
||||
* ``project_name`` is filled from ``PROJECT_NAME``. ``*``
|
||||
* ``time`` and ``date`` - compile time and date.
|
||||
* ``idf_ver`` - version of ESP-IDF. ``*``
|
||||
|
||||
@@ -51,12 +51,12 @@ To find the amount of statically allocated memory, use the :ref:`idf.py size <id
|
||||
|
||||
.. only:: esp32
|
||||
|
||||
.. note::
|
||||
|
||||
.. note::
|
||||
|
||||
See the :ref:`dram` section for more details about the DRAM usage limitations.
|
||||
|
||||
.. note::
|
||||
|
||||
.. note::
|
||||
|
||||
At runtime, the available heap DRAM may be less than calculated at compile time, because, at startup, some memory is allocated from the heap before the FreeRTOS scheduler is started (including memory for the stacks of initial FreeRTOS tasks).
|
||||
|
||||
IRAM
|
||||
@@ -126,7 +126,7 @@ Memory allocated with ``MALLOC_CAP_32BIT`` can **only** be accessed via 32-bit r
|
||||
|
||||
.. only:: esp32
|
||||
|
||||
To use the region above the 4 MiB limit, you can use the :doc:`himem API</api-reference/system/himem>`.
|
||||
To use the region above the 4 MiB limit, you can use the :doc:`himem API </api-reference/system/himem>`.
|
||||
|
||||
Thread Safety
|
||||
-------------
|
||||
|
||||
@@ -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:`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:
|
||||
|
||||
- read contents of otadata partition (read_otadata)
|
||||
- erase otadata partition, effectively resetting device to factory app (erase_otadata)
|
||||
|
||||
@@ -37,7 +37,7 @@ To re-enable the entropy source temporarily during app startup, or for an applic
|
||||
Secondary Entropy
|
||||
-----------------
|
||||
|
||||
{IDF_TARGET_NAME} RNG contains a secondary entropy source, based on sampling an asynchronous 8MHz internal oscillator (see the Technical Reference Manual for details). This entropy source is always enabled in ESP-IDF and continuously mixed into the RNG state by hardware. In testing, this secondary entropy source was sufficient to pass the `Dieharder`_ random number test suite without the main entropy source enabled (test input was created by concatenating short samples from a continuously resetting {IDF_TARGET_NAME}). However, it is currently only guaranteed that true random numbers are produced when the main entropy source is also enabled as described above.
|
||||
{IDF_TARGET_NAME} RNG contains a secondary entropy source, based on sampling an asynchronous 8 MHz internal oscillator (see the Technical Reference Manual for details). This entropy source is always enabled in ESP-IDF and continuously mixed into the RNG state by hardware. In testing, this secondary entropy source was sufficient to pass the `Dieharder`_ random number test suite without the main entropy source enabled (test input was created by concatenating short samples from a continuously resetting {IDF_TARGET_NAME}). However, it is currently only guaranteed that true random numbers are produced when the main entropy source is also enabled as described above.
|
||||
|
||||
API Reference
|
||||
-------------
|
||||
@@ -45,8 +45,8 @@ API Reference
|
||||
.. include-build-file:: inc/esp_random.inc
|
||||
.. include-build-file:: inc/bootloader_random.inc
|
||||
|
||||
Getrandom
|
||||
---------
|
||||
``getrandom()``
|
||||
---------------
|
||||
|
||||
A compatible version of the Linux ``getrandom()`` function is also provided for ease of porting:
|
||||
|
||||
@@ -62,8 +62,8 @@ The ``flags`` argument is ignored, this function is always non-blocking but the
|
||||
|
||||
Return value is -1 (with ``errno`` set to ``EFAULT``) if the ``buf`` argument is NULL, and equal to ``buflen`` otherwise.
|
||||
|
||||
getentropy
|
||||
----------
|
||||
``getentropy()``
|
||||
----------------
|
||||
|
||||
A compatible version of the Linux ``getentropy()`` function is also provided for ease of porting:
|
||||
|
||||
|
||||
@@ -131,7 +131,7 @@ The following config options control TWDT configuration. They are all enabled by
|
||||
Configuration
|
||||
"""""""""""""
|
||||
|
||||
- When the external 32KHz crystal or oscillator is selected (:ref:`CONFIG_RTC_CLK_SRC`) the XTWDT can be enabled via the :ref:`CONFIG_ESP_XT_WDT` configuration option.
|
||||
- When the external 32 KHz crystal or oscillator is selected (:ref:`CONFIG_RTC_CLK_SRC`) the XTWDT can be enabled via the :ref:`CONFIG_ESP_XT_WDT` configuration option.
|
||||
- The timeout is configured by setting the :ref:`CONFIG_ESP_XT_WDT_TIMEOUT` option.
|
||||
- The automatic backup clock functionality is enabled via the ref:`CONFIG_ESP_XT_WDT_BACKUP_CLK_ENABLE` configuration option.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user