espressif/esp-idf
1
0
Fork 1
mirror of https://github.com/espressif/esp-idf.git synced 2026-05-04 11:55:21 +02:00
Code Issues Packages Projects Releases Wiki Activity

docs: update format issues left in EN docs

Browse Source
This commit is contained in:
caixinying-git
2023-09-13 17:05:23 +08:00
committed by BOT
parent a9349f4ad4
commit b07ada6e94
35 changed files with 120 additions and 120 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/en/api-reference/network/esp-wifi-mesh.rst
+17 -17
View File
@@ -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 ---------------------------
docs/en/api-reference/network/esp_eth.rst
+1 -1
View File
@@ -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.
docs/en/api-reference/network/esp_netif.rst
+3 -3
View File
@@ -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
docs/en/api-reference/network/esp_netif_driver.rst
+1 -1
View File
@@ -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.