Crate esp_idf_sys
source ·Expand description
Raw Rust bindings for the ESP-IDF SDK.
Build Prerequisites
Follow the Prerequisites section in the esp-idf-template
crate.
Customizing the Build
Table of contents
- Rust configuration flags
- Features
- sdkconfig
- ESP-IDF configuration
- Extra ESP-IDF components
- Conditional compilation
- ESP32-C6/ESP32-P4 preliminary support
- More info
Rust configuration flags
The following are flags passed to rustc
that influence the build.
--cfg espidf_time64
This is a flag for the libc crate that uses 64-bits (instead of 32-bits) for
time_t
. This must be set for ESP-IDF 5.0 and above and must be unset for lesser versions.-Zbuild-std=std,panic_abort
Required for
std
support. Rust does not providestd
libraries for ESP32 targets since they are tier-2/-3.
Features
native
This is the default feature for downloading all tools and building the ESP-IDF framework using the framework’s “native” (own) tooling. It relies on build and installation utilities available in the embuild crate.
The
native
builder installs all needed tools to compile this crate as well as the ESP-IDF framework itself.pio
This is a backup feature for installing all build tools and building the ESP-IDF framework. It uses PlatformIO via the embuild crate.
Similarly to the
native
builder, thepio
builder also automatically installs all needed tools (PlatformIO packages and frameworks in this case) to compile this crate as well as the ESP-IDF framework itself.[!WARNING] The
pio
builder is less flexible than the defaultnative
builder in that it can work with only one, specific version of ESP-IDF. At the time of writing, this is V4.3.2.binstart
Defines the esp-idf entry-point for when the root crate is a binary crate that defines a
main
function.libstart
Defines the esp-idf entry-point for when the root crate is a library crate. the root crate is expected to provide a
#[no_mangle] fn main() {}
function.
uart0_driver_init
Enables UART0 to be driven by the driver code, adding buffering support required to read
std::io::stdin()
from UART0. This is enabled by default.
sdkconfig
The esp-idf makes use of an sdkconfig
file for its
compile-time component configuration (see the esp-idf
docs
for more information). This config is separate from the build configuration.
(native builder only) Using cargo-idf to interactively modify ESP-IDF’s sdkconfig
file
TBD: Upcoming
(pio builder only) Using cargo-pio to interactively modify ESP-IDF’s sdkconfig
file
To enable Bluetooth, or do other configurations to the ESP-IDF sdkconfig you might take advantage of the cargo-pio Cargo subcommand:
- To install it, issue
cargo install cargo-pio --git https://github.com/ivmarkov/cargo-pio
- To open the ESP-IDF interactive menuconfig system, issue
cargo pio espidf menuconfig
in the root of your binary crate project - To use the generated/updated
sdkconfig
file, follow the steps described in the “Bluetooth Support” section
ESP-IDF configuration
There are two ways to configure how the ESP-IDF framework is compiled:
-
Environment variables, denoted by
$VARIABLE
;The environment variables can be passed on the command line, or put into the
[env]
section of a.cargo/config.toml
file (see cargo reference). -
The
[package.metadata.esp-idf-sys]
section of theCargo.toml
, denoted byfield
.[!NOTE] Configuration can only come from the root crate’s
Cargo.toml
. The root crate is the package in the workspace directory. If there is not root crate in case of a virtual workspace, its name can be specified with theESP_IDF_SYS_ROOT_CRATE
environment variable.[!WARNING] Environment variables always take precedence over
Cargo.toml
metadata.
[!NOTE] workspace directory
The workspace directory mentioned here is always the directory containing the
Cargo.lock
file and thetarget
directory (unless configured otherwise, see the note below aboutCARGO_TARGET_DIR
) where the build artifacts are stored. It can be overridden with theCARGO_WORKSPACE_DIR
environment variable, should this not be the right directory.
(Seeembuild::cargo::workspace_dir
for more information).There is no need to explicitly add a
[workspace]
section to theCargo.toml
of the workspace directory.Please note that if you have set
CARGO_TARGET_DIR
and moved yourtarget
directory out of the crate root, then embuild is not able to locate the crate root. This will result in it among other things ignoring your localsdkconfig.defaults
. In this case you must declare:[env] CARGO_WORKSPACE_DIR = { value = "", relative = true }
in the
.cargo/config.toml
file, to force it to look in the current directory.
The following configuration options are available:
esp_idf_sdkconfig_defaults
,$ESP_IDF_SDKCONFIG_DEFAULTS
A single path or a list of paths to
sdkconfig.defaults
files to be used as base values for thesdkconfig
. If such a path is relative, it will be relative to the workspace directory.Defaults to
sdkconfig.defaults
.In case of the environment variable, multiple elements should be
;
-separated.[!NOTE] For each defaults file in this list, a more specific file will also be searched and used. This happens with the following patterns and order (least to most specific):
<path>
<path>.<profile>
<path>.<mcu>
<path>.<profile>.<mcu>
where
<profile>
is the current cargo profile used (debug
/release
) and<mcu>
specifies the mcu for which this is currently compiled for (see themcu
configuration option below).[!WARNING] A setting contained in a more specific defaults file will override the same setting specified in a less specific one. For example, in a debug build, flags in
sdkconfig.debug
override those insdkconfig.defaults
.esp_idf_sdkconfig
,$ESP_IDF_SDKCONFIG
The
sdkconfig
file used to configure theesp-idf
. If this is a relative path, it is relative to the workspace directory.Defaults to
sdkconfig
.[!NOTE] Similar to the
sdkconfig.defaults
-file a more specificsdkconfig
-file will be selected if available. This happens with the following patterns and precedence:<path>.<profile>.<mcu>
<path>.<mcu>
<path>.<profile>
<path>
[!NOTE] native builder only:
The cargo optimization options (debug
andopt-level
) are used by default to determine the compiler optimizations of theesp-idf
, however if the compiler optimization options are already set in thesdkconfig
they will be used instead.esp_idf_tools_install_dir
,$ESP_IDF_TOOLS_INSTALL_DIR
The install location for the ESP-IDF framework tooling.
[!NOTE] The framework tooling is either PlatformIO when the
pio
builder is used, or the ESP-IDF native toolset when thenative
builder is used (default).This option can take one of the following values:
-
workspace
(default) - the tooling will be installed or used in<crate-workspace-dir>/.embuild/platformio
forpio
, and<crate-workspace-dir>/.embuild/espressif
for thenative
builder; -
out
- the tooling will be installed or used inside esp-idf-sys’s build output directory, and will be deleted whencargo clean
is invoked; -
global
- the tooling will be installed or used in its standard directory (~/.platformio
for PlatformIO, and~/.espressif
for the native ESP-IDF toolset); -
custom:<dir>
- the tooling will be installed or used in the directory specified by<dir>
. If this directory is a relative location, it is assumed to be relative to the workspace directory; -
fromenv
- use the build framework from the environment- native builder: use activated esp-idf environment (see esp-idf docs unix / windows)
- pio builder: use
platformio
from the environment (i.e.$PATH
)
and error if this is not possible.
[!WARNING] Please be extra careful with the
custom:<dir>
setting when switching frompio
tonative
and the other way around, because the builder will install the tooling in<dir>
without using any additionalplatformio
orespressif
subdirectories, so if you are not careful, you might end up with both PlatformIO, as well as the ESP-IDF native tooling intermingled together in a single folder.[!WARNING] The ESP-IDF git repository will be cloned inside the tooling directory. The native builder will use the esp-idf at
idf_path
of available.-
idf_path
,$IDF_PATH
(native builder only)A path to a user-provided local clone of the esp-idf, that will be used instead of the one downloaded by the build script.
esp_idf_version
,$ESP_IDF_VERSION
(native builder only)The version used for the
esp-idf
, can be one of the following:commit:<hash>
: Uses the commit<hash>
of theesp-idf
repository. Note that this will clone the wholeesp-idf
not just one commit.tag:<tag>
: Uses the tag<tag>
of theesp-idf
repository.branch:<branch>
: Uses the branch<branch>
of theesp-idf
repository.v<major>.<minor>
or<major>.<minor>
: Uses the tagv<major>.<minor>
of theesp-idf
repository.<branch>
: Uses the branch<branch>
of theesp-idf
repository.
Defaults to
v4.4.1
.esp_idf_repository
,$ESP_IDF_REPOSITORY
(native builder only)The URL to the git repository of the
esp-idf
, defaults to https://github.com/espressif/esp-idf.git.[!NOTE] When the
pio
builder is used, it is possible to achieve something similar toESP_IDF_VERSION
andESP_IDF_REPOSITORY
by using theplatform_packages
PlatformIO option as follows:ESP_IDF_PIO_CONF="platform_packages = framework-espidf @ <git-url> [@ <git-branch>]"
The above approach however has the restriction that PlatformIO will always use the ESP-IDF build tooling from its own ESP-IDF distribution, so the user-provided ESP-IDF branch may or may not compile. The current PlatformIO tooling is suitable for compiling ESP-IDF branches derived from versions 4.3.X and 4.4.X.
$ESP_IDF_GLOB[_XXX]_BASE
and$ESP_IDF_GLOB[_XXX]_YYY
A pair of environment variable prefixes that enable copying files and directory trees that match a certain glob mask into the native C project used for building the ESP-IDF framework:
-
ESP_IDF_GLOB[_XXX]_BASE
specifies the base directory which will be glob-ed for resources to be copied -
ESP_IDF_GLOB[_XXX]_BASE_YYY
specifies one or more environment variables that represent the glob masks of resources to be searched for and copied, using the directory designated by theESP_IDF_GLOB[_XXX]_BASE
environment variable as the root. For example, if the following variables are specified:ESP_IDF_GLOB_HOMEDIR_BASE=/home/someuser
ESP_IDF_GLOB_HOMEDIR_FOO=foo*
ESP_IDF_GLOB_HOMEDIR_BAR=bar*
… then all files and directories matching ‘foo*’ or ‘bar*’ from the home directory of the user will be copied into the ESP-IDF C project.
Note also that
_HOMEDIR
in the above example is optional, and is just a mechanism allowing the user to specify more than one base directory and its glob patterns.
-
$ESP_IDF_PIO_CONF_XXX
(pio builder only)A PlatformIO setting (or multiple settings separated by a newline) that will be passed as-is to the
platformio.ini
file of the C project that compiles the ESP-IDF.Check the PlatformIO documentation for more information as to what settings you can pass via this variable.
[!NOTE] This is not one variable, but rather a family of variables all starting with
ESP_IDF_PIO_CONF_
. For example, passingESP_IDF_PIO_CONF_1
as well asESP_IDF_PIO_CONF_FOO
is valid and all such variables will be honored.esp_idf_cmake_generator
,$ESP_IDF_CMAKE_GENERATOR
(native builder only)The CMake generator to be used when building the ESP-IDF.
If not specified or set to
default
, Ninja will be used on all platforms except Linux/aarch64, where (for now) the Unix Makefiles generator will be used, as there are no Ninja builds for that platform provided by Espressif yet.Possible values for this environment variable are the names of all command-line generators that CMake supports with spaces and hyphens removed.
mcu
,$MCU
The MCU name (i.e.
esp32
,esp32s2
,esp32s3
esp32c3
,esp32c2
,esp32h2
,esp32c5
,esp32c6
,esp32p4
).If not set this will be automatically detected from the cargo target.
[!WARNING] Older ESP-IDF versions might not support all MCUs from above.
esp_idf_components
,$ESP_IDF_COMPONENTS
(native builder only)The (
;
-separated for the environment variable) list of esp-idf component names that should be built. This list is used to trim the esp-idf build. Any component that is a dependency of a component in this list will also automatically be built.Defaults to all components being built.
[!NOTE]
Some components must be explicitly enabled in the sdkconfig.
Extra components must also be added to this list if they are to be built.
Example
An example of the [package.metadata.esp-idf-sys]
section of the Cargo.toml
.
[package.metadata.esp-idf-sys]
esp_idf_tools_install_dir = "global"
esp_idf_sdkconfig = "sdkconfig"
esp_idf_sdkconfig_defaults = ["sdkconfig.defaults", "sdkconfig.defaults.ble"]
# native builder only
esp_idf_version = "branch:release/v4.4"
esp_idf_components = ["pthread"]
Extra ESP-IDF components
It is possible to let esp-idf-sys compile extra ESP-IDF components and generate bindings for them.
This is possible by adding an object to the
package.metadata.esp-idf-sys.extra_components
array of the Cargo.toml
. esp-idf-sys
will honor all such extra components in the root crate‘s and all direct
dependencies’ Cargo.toml
.
[!NOTE] By only specifying the
bindings_header
field, one can extend the set of esp-idf bindings that were generated from src/include/esp-idf/bindings.h. To do this you need to create a*.h
header file in your project source, and reference that in thebindings_header
variable. You can then include extra esp-idf header files from there.
An extra component can be specified like this:
[[package.metadata.esp-idf-sys.extra_components]]
# A single path or a list of paths to a component directory or directory
# containing components.
#
# Each path can be absolute or relative. Relative paths will be relative to the
# folder containing the defining `Cargo.toml`.
#
# **This field is optional.** No component will be built if this field is absent, though
# the bindings of the `[Self::bindings_header]` will still be generated.
component_dirs = ["dir1", "dir2"] # or "dir"
# The path to the C header to generate the bindings with. If this option is absent,
# **no** bindings will be generated.
#
# The path can be absolute or relative. A relative path will be relative to the
# folder containing the defining `Cargo.toml`.
#
# This field is optional.
bindings_header = "bindings.h"
# If this field is present, the component bindings will be generated separately from
# the `esp-idf` bindings and put into their own module inside the `esp-idf-sys` crate.
# Otherwise, if absent, the component bindings will be added to the existing
# `esp-idf` bindings (which are available in the crate root).
#
# To put the bindings into its own module, a separate bindgen instance will generate
# the bindings. Note that this will result in duplicate `esp-idf` bindings if the
# same `esp-idf` headers that were already processed for the `esp-idf` bindings are
# included by the component(s).
#
# This field is optional.
bindings_module = "name"
and is equivalent to
[package.metadata.esp-idf-sys]
extra_components = [
{ component_dirs = [ "dir1", "dir2" ], bindings_header = "bindings.h", bindings_module = "name" }
]
Conditional compilation
The esp-idf-sys build script will set rustc cfgs available for its sources.
[!IMPORTANT] If an upstream crate also wants to have access to the cfgs it must:
have
esp-idf-sys
as a dependency, andpropagate the cfgs in its build script with
embuild::build::CfgArgs::output_propagated("ESP_IDF").expect("no esp-idf-sys cfgs");
using the embuild crate.
The list of available cfgs:
-
esp_idf_comp_{component}_enabled
for each component -
esp_idf_version="{major}.{minor}"
-
esp_idf_version_full="{major}.{minor}.{patch}"
-
esp_idf_version_major="{major}"
-
esp_idf_version_minor="{minor}"
-
esp_idf_version_patch="{patch}"
-
esp_idf_{sdkconfig_option}
Each sdkconfig setting where
{sdkconfig_option}
corresponds to the option set in the sdkconfig lowercased and without theCONFIG_
prefix. Only options set toy
will get a cfg. -
{mcu}
Corresponds to the mcu for which the esp-idf is compiled for.
More info
If you are interested in how it all works under the hood, check the build.rs build script of this crate.
ESP32-C6/ESP32-P4 preliminary support
The ESP32-C6 and the upcoming ESP32-P4 are the first Espressif chips that support the “A” (atomic) extension of the RISCV specification.
As such, they do not work with the existing riscv32imc-esp-espidf
target, and instead need a new one (to be upstreamed to Rust)
called riscv32imac-esp-espidf
.
Until the target is upstreamed, you can use the following custom target:
{
"arch": "riscv32",
"cpu": "generic-rv32",
"data-layout": "e-m:e-p:32:32-i64:64-n32-S128",
"eh-frame-header": false,
"emit-debug-gdb-scripts": false,
"env": "newlib",
"features": "+m,+a,+c",
"is-builtin": false,
"linker": "riscv32-esp-elf-gcc",
"llvm-target": "riscv32",
"max-atomic-width": 64,
"os": "espidf",
"panic-strategy": "abort",
"relocation-model": "static",
"target-family": [
"unix"
],
"target-pointer-width": "32",
"vendor": "espressif"
}
Save the target somewhere (perhaps in the root of your binary crate) under the name riscv32imac-esp-espidf.json
and when building with cargo, pass it with --target riscv32imac-esp-espidf.json
.
Macros
- Convert an
esp_err_t
into aResult<(), EspError>
. - Panic with an error-specific message if
err
is notESP_OK
. - Convert an
esp_err_t
into aResult<T, EspError>
.
Structs
- @brief Opaque directory structure
- A wrapped
esp_err_t
to check if an error occurred. - Type by which queues are referenced. For example, a call to xQueueCreate() returns an QueueHandle_t variable that can then be used as a parameter to xQueueSend(), xQueueReceive(), etc.
- @brief IP address
- @brief ADC arbiter work mode and priority setting.
- @brief ADC digital controller settings
- @brief ADC digital controller (DMA mode) filter configuration.
- @brief ADC DMA driver configuration
- @brief ADC digital controller (DMA mode) monitor configuration.
- @brief ADC digital controller (DMA mode) output data format. Used to analyze the acquired ADC (DMA) data.
- @brief ADC digital controller pattern configuration
- @brief Directory entry structure
- @brief Structure storing characteristics of an ADC
- \brief AES context structure
- \brief The AES XTS context-type definition.
- @brief Description about application.
- @brief The structure represents information about the chip
- @brief Console command description
- @brief Parameters for console initialization
- @brief Parameters for console device: UART
- @brief Parameters for console device: USB CDC
- @brief Parameters for console REPL (Read Eval Print Loop)
- @brief Console REPL base structure
- @brief Type definition for an eFuse field
- @brief Configuration of Ethernet driver
- @brief Ethernet MAC
- @brief Ethernet mediator
- @brief Ethernet PHY
- Configuration for creating event loops
- @brief OS-level integration hooks for accessing flash chips inside a running OS
- @brief Structure for describing a region of flash
- @brief Structure to describe a SPI flash chip connected to the system.
- @brief HTTP configuration
- @brief HTTP Client events data
- @brief Main header of binary image
- @brief Header of binary image segment
- @brief IPv4 address
- @brief IPv6 address
- @brief Mesh PS duties
- MQTT client configuration structure
- @brief MQTT error code structure to be passed as a contextual information into ERROR event
- MQTT event configuration structure
- @brief Generic esp_netif configuration
- @brief DNS server info
- @brief ESP-netif driver base handle
- @brief Specific IO driver configuration
- @brief ESP-netif inherent config parameters
- @brief IPV6 IP address information
- Event structure for IP_EVENT_STA_GOT_IP, IP_EVENT_ETH_GOT_IP events
- @brief Type of esp_netif_object server
- @brief station list info element
- @brief station list structure
- @brief ESPNOW peer information parameters.
- @brief Number of ESPNOW peers which exist currently.
- @brief partition information structure
- @brief Type of “ping” callback functions
- @brief Type of “ping” configuration
- @brief Power management config for ESP32C3
- pthread configuration structure that influences pthread creation
- @brief Timer configuration passed to esp_timer_create
- @brief ESP-TLS Connection Handle
- @brief ESP-TLS configuration parameters
- @brief Error structure containing relevant errors in case tls error occurred
- @brief Keep alive parameters structure
- WS transport configuration structure
- @brief Eventfd vfs initialization settings
- @brief Configuration arguments for esp_vfs_fat_sdmmc_mount and esp_vfs_fat_spiflash_mount functions
- @brief VFS semaphore type for select()
- @brief Configuration structure for esp_vfs_spiffs_register
- @brief VFS definition structure
- @brief Websocket client setup configuration
- @brief Websocket event data
- Configuration for the ESSL SDIO device
- @brief Configuration of Ethernet MAC object
- @brief Ethernet PHY configuration
- Structure of pointers to disk IO driver functions.
- @brief Configuration parameters of GPIO pad for gpio_config function
- @brief HTTP Server Configuration Structure
- @brief HTTP Request Data Structure
- @brief Structure for URI handler
- @brief I2C initialization parameters
- @brief I2S driver configuration parameters
- @brief Event structure used in I2S event queue
- @brief I2S PCM configuration
- @brief I2S PDM up-sample rate configuration @note TX PDM can only be set to the following two upsampling rate configurations: 1: fp = 960, fs = sample_rate / 100, in this case, Fpdm = 12848000 2: fp = 960, fs = 480, in this case, Fpdm = 128Fpcm = 128sample_rate If the pdm receiver do not care the pdm serial clock, it’s recommended set Fpdm = 12848000. Otherwise, the second configuration should be applied.
- @brief I2S pin number for i2s_set_pin
- This is the aligned version of ip4_addr_t, used as local variable, on the stack, etc.
- This is the aligned version of ip6_addr_t, used as local variable, on the stack, etc.
- @ingroup ipaddr A union struct for both IP version’s addresses. ATTENTION: watch out for its size when adding IPv6 address scope!
- Event structure for ADD_IP6 event
- Event structure for IP_EVENT_AP_STAIPASSIGNED event
- Event structure for IP_EVENT_GOT_IP6 event
- @brief Event structure for IP_EVENT_GOT_IP event
- @brief LEDC callback parameter
- @brief Group of supported LEDC callbacks @note The callbacks are all running under ISR environment
- @brief Configuration parameters of LEDC channel for ledc_channel_config function
- @brief Configuration parameters of LEDC Timer timer for ledc_timer_config function
- Container for ASN1 bit strings.
- Type-length-value structure that allows for ASN1 using DER.
- Container for a sequence or list of ‘named’ ASN.1 data items
- Container for a sequence of ASN.1 items
- Generic cipher context.
- Cipher information. Allows calling cipher functions in a generic way.
- \brief The CTR_DRBG context structure.
- \brief The DHM context structure.
- \warning Performing multiple operations concurrently on the same ECDSA context is not supported; objects of this type should not be shared between multiple threads. \brief The ECDH context structure.
- Curve information, for use by other modules.
- \brief The ECP group structure.
- \brief The ECP key-pair structure.
- \brief The ECP point structure, in Jacobian coordinates.
- \brief Entropy context structure
- \brief Entropy source state
- The generic message-digest context.
- \brief MPI structure
- Wrapper type for sockets.
- \brief Public key container
- \brief Item to send to the debug module
- \brief Options for RSASSA-PSS signature verification. See \c mbedtls_rsa_rsassa_pss_verify_ext()
- \brief The platform context structure.
- \brief The RSA context structure.
- \brief The SHA-512 context structure.
- \brief This structure is used for storing ciphersuite information
- SSL/TLS configuration to be shared between mbedtls_ssl_context structures.
- Certificate revocation list structure. Every CRL may have multiple entries.
- Certificate revocation list entry. Contains the CA-specific serial numbers and revocation dates.
- Container for an X.509 certificate. The certificate may be chained.
- Security profile for certificate verification.
- Verification chain as built by \c mbedtls_crt_verify_chain()
- Item in a verification chain: cert and flags for it
- From RFC 5280 section 4.2.1.6: OtherName ::= SEQUENCE { type-id OBJECT IDENTIFIER, value [0] EXPLICIT ANY DEFINED BY type-id }
- From RFC 4108 section 5: HardwareModuleName ::= SEQUENCE { hwType OBJECT IDENTIFIER, hwSerialNum OCTET STRING }
- A structure for holding the parsed Subject Alternative Name, according to type
- Container for date and time (precision in seconds).
- Container for writing a certificate (CRT)
- @brief mDNS query linked list IP item
- @brief mDNS query result structure
- @brief mDNS basic text item structure Used in mdns_service_add()
- Memory pool descriptor
- @brief Mesh softAP configuration
- @brief Mesh networking IE
- Structures
- @brief Mesh initialization configuration
- @brief The crypto callback function structure used in mesh vendor IE encryption. The structure can be set as software crypto or the crypto optimized by ESP32 hardware.
- @brief Mesh data for esp_mesh_send() and esp_mesh_recv()
- @brief Channel switch information
- @brief Parent connected information
- @brief find a mesh network that this device can join
- @brief Layer change information
- @brief Network state information
- @brief No parent found information
- @brief PS duty information
- @brief Other powerful root address
- @brief Root fixed
- @brief Root switch request information
- @brief Routing table change
- @brief Scan done event information
- @brief vote started information
- @brief Mesh option
- @brief Router configuration
- @brief The number of packets available in the queue waiting to be received by applications
- @brief The number of packets pending in the queue waiting to be sent by the mesh stack
- @brief Vote
- @brief Structure to access heap metadata via multi_heap_get_info
- @brief This structure maps handler required by protocomm layer to UUIDs which are used to uniquely identify BLE characteristics from a smartphone or a similar client device.
- Generic data structure used for all lwIP network interfaces. The following fields should be filled in by the initialization function for the device driver: hwaddr_len, hwaddr[], mtu, flags
- Args to LWIP_NSC_IPV4_ADDRESS_CHANGED|LWIP_NSC_IPV4_GATEWAY_CHANGED|LWIP_NSC_IPV4_NETMASK_CHANGED|LWIP_NSC_IPV4_SETTINGS_CHANGED callback
- Args to LWIP_NSC_IPV6_ADDR_STATE_CHANGED callback
- Args to LWIP_NSC_IPV6_SET callback
- Args to LWIP_NSC_LINK_CHANGED callback
- Args to LWIP_NSC_STATUS_CHANGED callback
- @brief information about entry obtained from nvs_entry_info function
- @brief Key for encryption and decryption
- @note Info about storage space NVS.
- Main packet buffer struct
- A custom pbuf: like a pbuf, but following a function pointer to free it.
- Helper struct for const-correctness only. The only meaning of this one is to provide a const payload pointer for PBUF_ROM type.
- @brief Spinlock object Owner:
- @brief Config parameters for protocomm BLE service
- @brief Config parameters for protocomm HTTP server
- @brief Config parameters for protocomm HTTP server
- @brief Protocomm security object structure.
- @brief Proof Of Possession for authenticating a secure session
- @brief ESP-TLS preshared key and hint structure
- @brief Data struct of RMT channel status
- @brief Data struct of RMT configure parameters
- @brief Data struct of RMT RX configure parameters
- @brief Data struct of RMT TX configure parameters
- @brief Structure encapsulating a RMT TX end callback
- Initialization parameters for rtc_clk_init
- RTC power and clock control initialization settings
- @brief CPU clock configuration structure
- @brief sleep configuration for rtc_sleep_init function
- @brief Power down flags for rtc_sleep_pd function
- Structure describing vddsdio configuration
- SD/MMC card information structure
- Decoded values from SD card Card IDentification register
- SD/MMC command information
- Decoded values from SD card Card Specific Data register
- Decoded values of Extended Card Specific Data
- SD/MMC Host description
- Decoded values from SD Configuration Register
- SD SWITCH_FUNC response buffer
- Extra configuration for SD SPI device.
- Extra configuration for SPI host.
- @brief Sigma-delta configure struct
- Argument structure for SC_EVENT_GOT_SSID_PSWD event
- Configure structure for esp_smartconfig_start
- @brief This is a configuration structure for a SPI bus.
- @brief This is a configuration for a SPI slave device that is connected to one of the SPI buses.
- Structure for flash encryption operations.
- Structure holding SPI flash access critical sections management functions.
- Host driver configuration and context structure.
- SPI Flash Host driver instance
- Configuration structure for the flash chip suspend feature.
- Definition of a common transaction. Also holds the return value.
- @brief Line mode of SPI transaction phases: CMD, ADDR, DOUT/DIN.
- @brief This is a configuration for a SPI host acting as a slave device.
- This structure describes one SPI transaction
- This struct is for SPI transactions which may change their address and command length. Please do set the flags in base to
SPI_TRANS_VARIABLE_CMD_ADR
to use the bit length here. - This structure describes one SPI transaction. The descriptor should not be modified until the transaction finishes.
- Event, as a tagged enum
- @brief legacy ip_info type
- @brief Data structure with timer’s configuration settings
- @brief Keep alive parameters structure
- Touch sensor filter configuration
- Touch sensor denoise configuration
- Touch sensor channel sleep configuration
- Touch sensor waterproof configuration
- task. h
- @brief Structure for acceptance filter configuration of the TWAI driver (see documentation)
- @brief Structure for general configuration of the TWAI driver
- @brief Structure to store a TWAI message
- @brief Structure to store status information of TWAI driver
- @brief Structure for bit timing configuration of the TWAI driver
- @brief UART AT cmd char configuration parameters Note that this function may different on different chip. Please refer to the TRM at confirguration.
- @brief UART configuration parameters for uart_param_config function
- @brief Event structure used in UART event queue
- @brief UART interrupt configuration parameters for uart_intr_config function
- @brief UART software flow control configuration parameters
- @brief Vendor Information Element header
- @brief Action Frame Tx Request
- @brief Range of active scan times per channel
- @brief WiFi antenna configuration
- @brief WiFi GPIOs configuration for antenna selection
- @brief WiFi GPIO configuration for antenna selection
- @brief Soft-AP configuration settings for the ESP32
- @brief Description of a WiFi AP
- @brief Structure describing WiFi country-based regional restrictions.
- @brief Channel state information(CSI) configuration type
- @brief CSI data type
- Argument structure for WIFI_EVENT_ACTION_TX_STATUS event
- Argument structure for WIFI_EVENT_AP_PROBEREQRECVED event
- Argument structure for WIFI_EVENT_AP_STACONNECTED event
- Argument structure for WIFI_EVENT_AP_STADISCONNECTED event
- Argument structure for WIFI_EVENT_STA_BSS_RSSI_LOW event
- Argument structure for WIFI_EVENT_FTM_REPORT event
- Argument structure for WIFI_EVENT_ROC_DONE event
- Argument structure for WIFI_EVENT_STA_AUTHMODE_CHANGE event
- Argument structure for WIFI_EVENT_STA_CONNECTED event
- Argument structure for WIFI_EVENT_STA_DISCONNECTED event
- Argument structure for WIFI_EVENT_SCAN_DONE event
- Argument structure for WIFI_EVENT_STA_WPS_ER_PIN event
- Argument structure for WIFI_EVENT_STA_WPS_ER_SUCCESS event
- @brief FTM Initiator configuration
- Argument structure for
- @brief Configuration for STA’s HT2040 coexist management
- @brief WiFi stack configuration parameters passed to esp_wifi_init call.
- @brief Configuration for WiFi ioctl
- @brief Received packet radio metadata header, this is the common header at the beginning of all promiscuous mode RX callback buffers
- Configuration structure for Protected Management Frame
- @brief Mask for filtering different packet types in promiscuous mode.
- @brief Payload passed to ‘buf’ parameter of promiscuous mode RX callback.
- @brief WiFi status data to be sent in response to
get_status
request from master - @brief Internal handlers for receiving and responding to protocomm requests from master
- @brief WiFi config data received by slave during
set_config
request from master - @brief Event handler that is used by the manager while provisioning service is active
- @brief Structure for specifying the manager configuration
- @brief Structure for specifying the provisioning scheme to be followed by the manager
- @brief WiFi STA connected status information
- @brief Parameters for an SSID scan.
- @brief Structure describing parameters for a WiFi fast scan
- @brief Aggregate of active & passive scan time per channel
- @brief STA configuration settings for the ESP32
- @brief Description of STA associated with AP
- @brief List of stations associated with the ESP32 Soft-AP
- @brief The crypto callback function structure used when do station security connect. The structure can be set as software crypto or the crypto optimized by ESP32 hardware.
- Defines the memory ranges allocated to the task when an MPU is used.
- Used with the uxTaskGetSnapshotAll() function to save memory snapshot of each task in the system. We need this struct because TCB_t is defined (hidden) in tasks.c.
- @cond !DOC_EXCLUDE_HEADER_SECTION / /* Used internally only.
Constants
- < Chip did not respond to the command, or timed out.
- < The chip doesn’t have enough space for the current partition table
- < return failed in ets
- < return successful in ets