Crates.io | esp-config |
lib.rs | esp-config |
version | 0.5.0 |
created_at | 2024-10-10 10:54:02.851455+00 |
updated_at | 2025-07-16 10:49:30.476378+00 |
description | Configure projects using esp-hal and related packages |
homepage | |
repository | https://github.com/esp-rs/esp-hal |
max_upload_size | |
id | 1403700 |
size | 147,322 |
esp-config
takes a prefix (usually the crate name) and a set of configuration keys and default values to produce a configuration system that supports:
0x
, 0o
and 0b
prefixes.The possible configuration values are output as a markdown table in the crates OUT_DIR
with the format {prefix}_config_table.md
, this can then be included into the crates top level documentation. Here is an example of the output:
Name | Description | Default value |
---|---|---|
ESP_HAL_PLACE_SPI_DRIVER_IN_RAM | Places the SPI driver in RAM for better performance | false |
For any available configuration option, the environment variable or cfg is always set based on the default value specified in the table. Users can override this by setting environment variables locally in their shell or the preferred option is to utilize cargo's env
section.
It's important to note that due to a bug in cargo, any modifications to the environment, local or otherwise will only get picked up on a full clean build of the project.
To see the final selected configuration another table is output to the OUT_DIR
with the format {prefix}_selected_config.md
.
For all supported data types, there are helper macros that emit const
code for parsing the configuration values.
esp_config_int!(integer_type, "ENV")
esp_config_str!("ENV")
esp_config_bool!("ENV")
In addition to environment variables, for boolean types rust cfg
's are emitted in snake case without the prefix.
Config options should be defined declaratively in a file called esp_config.yml
.
Such a file looks like this:
crate: esp-bootloader-esp-idf
options:
- name: mmu_page_size
description: ESP32-C2, ESP32-C6 and ESP32-H2 support configurable page sizes. This is currently only used to populate the app descriptor.
default:
- value: '"64k"'
stability: !Stable stable-since-version
constraints:
- if: true
type:
validator: enumeration
value:
- 8k
- 16k
- 32k
- 64k
- name: esp_idf_version
description: ESP-IDF version used in the application descriptor. Currently it's not checked by the bootloader.
default:
- if: 'chip == "esp32c6"'
value: '"esp32c6"'
- if: 'chip == "esp32"'
value: '"other"'
active: true
- name: partition-table-offset
description: "The address of partition table (by default 0x8000). Allows you to \
move the partition table, it gives more space for the bootloader. Note that the \
bootloader and app will both need to be compiled with the same \
PARTITION_TABLE_OFFSET value."
default:
- if: true
value: 32768
stability: Unstable
active: 'chip == "esp32c6"'
checks:
- 'ESP_BOOTLOADER_ESP_IDF_CONFIG_PARTITION_TABLE_OFFSET >= 32768'
if
and active
are evalexpr expressions returning a boolean.
The expression supports these custom functions:
Function | Description |
---|---|
feature(String) | true if the given chip feature is present |
cargo_feature(String) | true if the given Cargo feature is active |
ignore_feature_gates() | Usually false but tooling will set this to true to hint that the expression is evaluated by e.g. a TUI |
ignore_feature_gates()
is useful to enable otherwise disabled functionality - e.g. to offer all possible options regardless of any active / non-active features.
The chip
variable is populated with the name of the targeted chip (if the crate is using chip specific features).
The conditions for default
and constraints
are evaluated in order and the first match is taken no matter if there is more.
This way you could have a catch-all condition as the last item by just specifying true
.
checks
is a list of checks which needs to pass for a valid configuration and is checked after all config values for the current config are applied.
You can access the currently configured values to check them.
For more examples see the various esp_config.yml
files in this repository.
This crate is guaranteed to compile when using the latest stable Rust version at the time of the crate's release. It might compile with older versions, but that may change in any new release, including patches.
Licensed under either of:
at your option.
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.