352 lines
15 KiB
Text
352 lines
15 KiB
Text
#
|
|
# For a description of the syntax of this configuration file,
|
|
# see kconfig/kconfig-language.txt.
|
|
#
|
|
mainmenu "Espressif IoT Development Framework Configuration"
|
|
|
|
config IDF_CMAKE
|
|
bool
|
|
option env="IDF_CMAKE"
|
|
|
|
config IDF_ENV_FPGA
|
|
# This option is for internal use only
|
|
bool
|
|
|
|
config IDF_TARGET
|
|
# This option records the IDF target when sdkconfig is generated the first time.
|
|
# It is not updated if environment variable $IDF_TARGET changes later, and
|
|
# the build system is responsible for detecting the mismatch between
|
|
# CONFIG_IDF_TARGET and $IDF_TARGET.
|
|
string
|
|
default "$IDF_TARGET"
|
|
|
|
config IDF_TARGET_ESP32
|
|
bool
|
|
default "y" if IDF_TARGET="esp32"
|
|
|
|
config IDF_TARGET_ESP32S2BETA
|
|
bool
|
|
default "y" if IDF_TARGET="esp32s2beta"
|
|
select FREERTOS_UNICORE
|
|
|
|
config IDF_FIRMWARE_CHIP_ID
|
|
hex
|
|
default 0x0000 if IDF_TARGET_ESP32
|
|
# note: S2 beta uses Chip ID 0 still, S2 will use 0x0002
|
|
default 0x0000 if IDF_TARGET_ESP32S2BETA
|
|
default 0xFFFF
|
|
|
|
menu "SDK tool configuration"
|
|
config SDK_TOOLPREFIX
|
|
string "Compiler toolchain path/prefix"
|
|
default "xtensa-esp32-elf-" if IDF_TARGET_ESP32
|
|
default "xtensa-esp32s2-elf-" if IDF_TARGET_ESP32S2BETA
|
|
help
|
|
The prefix/path that is used to call the toolchain. The default setting assumes
|
|
a crosstool-ng gcc setup that is in your PATH.
|
|
|
|
config SDK_PYTHON
|
|
string "Python interpreter"
|
|
depends on !IDF_CMAKE
|
|
default "python"
|
|
help
|
|
The executable name/path that is used to run python.
|
|
|
|
(Note: This option is used with the legacy GNU Make build system only.)
|
|
|
|
config SDK_MAKE_WARN_UNDEFINED_VARIABLES
|
|
bool "'make' warns on undefined variables"
|
|
depends on !IDF_CMAKE
|
|
default "y"
|
|
help
|
|
Adds --warn-undefined-variables to MAKEFLAGS. This causes make to
|
|
print a warning any time an undefined variable is referenced.
|
|
|
|
This option helps find places where a variable reference is misspelled
|
|
or otherwise missing, but it can be unwanted if you have Makefiles which
|
|
depend on undefined variables expanding to an empty string.
|
|
|
|
(Note: this option is used with the legacy GNU Make build system only.)
|
|
|
|
config SDK_TOOLCHAIN_SUPPORTS_TIME_WIDE_64_BITS
|
|
bool "Toolchain supports time_t wide 64-bits"
|
|
default n
|
|
help
|
|
Enable this option in case you have a custom toolchain which supports time_t wide 64-bits.
|
|
This option checks time_t is 64-bits and disables ROM time functions
|
|
to use the time functions from the toolchain instead.
|
|
This option allows resolving the Y2K38 problem.
|
|
See "Setup Linux Toolchain from Scratch" to build
|
|
a custom toolchain which supports 64-bits time_t.
|
|
|
|
Note: ESP-IDF does not currently come with any pre-compiled toolchain
|
|
that supports 64-bit wide time_t.
|
|
This will change in a future major release,
|
|
but currently 64-bit time_t requires a custom built toolchain.
|
|
|
|
endmenu # SDK tool configuration
|
|
|
|
menu "Build type"
|
|
|
|
choice APP_BUILD_TYPE
|
|
prompt "Application build type"
|
|
default APP_BUILD_TYPE_APP_2NDBOOT
|
|
help
|
|
Select the way the application is built.
|
|
|
|
By default, the application is built as a binary file in a format compatible with
|
|
the ESP32 bootloader. In addition to this application, 2nd stage bootloader is
|
|
also built. Application and bootloader binaries can be written into flash and
|
|
loaded/executed from there.
|
|
|
|
Another option, useful for only very small and limited applications, is to only link
|
|
the .elf file of the application, such that it can be loaded directly into RAM over
|
|
JTAG. Note that since IRAM and DRAM sizes are very limited, it is not possible to
|
|
build any complex application this way. However for kinds of testing and debugging,
|
|
this option may provide faster iterations, since the application does not need to be
|
|
written into flash.
|
|
Note that at the moment, ESP-IDF does not contain all the startup code required to
|
|
initialize the CPUs and ROM memory (data/bss). Therefore it is necessary to execute
|
|
a bit of ROM code prior to executing the application. A gdbinit file may look as follows:
|
|
|
|
# Connect to a running instance of OpenOCD
|
|
target remote :3333
|
|
# Reset and halt the target
|
|
mon reset halt
|
|
# Run to a specific point in ROM code,
|
|
# where most of initialization is complete.
|
|
thb *0x40007901
|
|
c
|
|
# Load the application into RAM
|
|
load
|
|
# Run till app_main
|
|
tb app_main
|
|
c
|
|
|
|
Execute this gdbinit file as follows:
|
|
|
|
xtensa-esp32-elf-gdb build/app-name.elf -x gdbinit
|
|
|
|
Recommended sdkconfig.defaults for building loadable ELF files is as follows.
|
|
CONFIG_APP_BUILD_TYPE_ELF_RAM is required, other options help reduce application
|
|
memory footprint.
|
|
|
|
CONFIG_APP_BUILD_TYPE_ELF_RAM=y
|
|
CONFIG_VFS_SUPPORT_TERMIOS=
|
|
CONFIG_NEWLIB_NANO_FORMAT=y
|
|
CONFIG_ESP32_PANIC_PRINT_HALT=y
|
|
CONFIG_ESP32_DEBUG_STUBS_ENABLE=
|
|
CONFIG_ESP_ERR_TO_NAME_LOOKUP=
|
|
|
|
|
|
config APP_BUILD_TYPE_APP_2NDBOOT
|
|
bool
|
|
prompt "Default (binary application + 2nd stage bootloader)"
|
|
select APP_BUILD_GENERATE_BINARIES
|
|
select APP_BUILD_BOOTLOADER
|
|
select APP_BUILD_USE_FLASH_SECTIONS
|
|
|
|
config APP_BUILD_TYPE_ELF_RAM
|
|
bool
|
|
prompt "ELF file, loadable into RAM (EXPERIMENTAL))"
|
|
endchoice # APP_BUILD_TYPE
|
|
|
|
# Hidden options, set according to the choice above
|
|
config APP_BUILD_GENERATE_BINARIES
|
|
bool # Whether to generate .bin files or not
|
|
|
|
config APP_BUILD_BOOTLOADER
|
|
bool # Whether to build the bootloader
|
|
|
|
config APP_BUILD_USE_FLASH_SECTIONS
|
|
bool # Whether to place code/data into memory-mapped flash sections
|
|
|
|
endmenu # Build type
|
|
|
|
source "$COMPONENT_KCONFIGS_PROJBUILD_SOURCE_FILE"
|
|
|
|
menu "Compiler options"
|
|
|
|
choice COMPILER_OPTIMIZATION
|
|
prompt "Optimization Level"
|
|
default COMPILER_OPTIMIZATION_DEFAULT
|
|
help
|
|
This option sets compiler optimization level (gcc -O argument).
|
|
|
|
- The "Default" setting will add the -0g flag to CFLAGS.
|
|
- The "Size" setting will add the -0s flag to CFLAGS.
|
|
- The "Performance" setting will add the -O2 flag to CFLAGS.
|
|
- The "None" setting will add the -O0 flag to CFLAGS.
|
|
|
|
The "Size" setting cause the compiled code to be smaller and faster, but
|
|
may lead to difficulties of correlating code addresses to source file
|
|
lines when debugging.
|
|
|
|
The "Performance" setting causes the compiled code to be larger and faster,
|
|
but will be easier to correlated code addresses to source file lines.
|
|
|
|
"None" with -O0 produces compiled code without optimization.
|
|
|
|
Note that custom optimization levels may be unsupported.
|
|
|
|
config COMPILER_OPTIMIZATION_DEFAULT
|
|
bool "Debug (-Og)"
|
|
config COMPILER_OPTIMIZATION_SIZE
|
|
bool "Optimize for size (-Os)"
|
|
config COMPILER_OPTIMIZATION_PERF
|
|
bool "Optimize for performance (-O2)"
|
|
config COMPILER_OPTIMIZATION_NONE
|
|
bool "Debug without optimization (-O0)"
|
|
|
|
endchoice
|
|
|
|
choice COMPILER_OPTIMIZATION_ASSERTION_LEVEL
|
|
prompt "Assertion level"
|
|
default COMPILER_OPTIMIZATION_ASSERTIONS_ENABLE
|
|
help
|
|
Assertions can be:
|
|
|
|
- Enabled. Failure will print verbose assertion details. This is the default.
|
|
|
|
- Set to "silent" to save code size (failed assertions will abort() but user
|
|
needs to use the aborting address to find the line number with the failed assertion.)
|
|
|
|
- Disabled entirely (not recommended for most configurations.) -DNDEBUG is added
|
|
to CPPFLAGS in this case.
|
|
|
|
config COMPILER_OPTIMIZATION_ASSERTIONS_ENABLE
|
|
prompt "Enabled"
|
|
bool
|
|
help
|
|
Enable assertions. Assertion content and line number will be printed on failure.
|
|
|
|
config COMPILER_OPTIMIZATION_ASSERTIONS_SILENT
|
|
prompt "Silent (saves code size)"
|
|
bool
|
|
help
|
|
Enable silent assertions. Failed assertions will abort(), user needs to
|
|
use the aborting address to find the line number with the failed assertion.
|
|
|
|
config COMPILER_OPTIMIZATION_ASSERTIONS_DISABLE
|
|
prompt "Disabled (sets -DNDEBUG)"
|
|
bool
|
|
help
|
|
If assertions are disabled, -DNDEBUG is added to CPPFLAGS.
|
|
|
|
endchoice # assertions
|
|
|
|
menuconfig COMPILER_CXX_EXCEPTIONS
|
|
bool "Enable C++ exceptions"
|
|
default n
|
|
help
|
|
Enabling this option compiles all IDF C++ files with exception support enabled.
|
|
|
|
Disabling this option disables C++ exception support in all compiled files, and any libstdc++ code
|
|
which throws an exception will abort instead.
|
|
|
|
Enabling this option currently adds an additional ~500 bytes of heap overhead
|
|
when an exception is thrown in user code for the first time.
|
|
|
|
config COMPILER_CXX_EXCEPTIONS_EMG_POOL_SIZE
|
|
int "Emergency Pool Size"
|
|
default 0
|
|
depends on COMPILER_CXX_EXCEPTIONS
|
|
help
|
|
Size (in bytes) of the emergency memory pool for C++ exceptions. This pool will be used to allocate
|
|
memory for thrown exceptions when there is not enough memory on the heap.
|
|
|
|
config COMPILER_CXX_RTTI
|
|
bool "Enable C++ run-time type info (RTTI)"
|
|
default n
|
|
help
|
|
Enabling this option compiles all C++ files with RTTI support enabled.
|
|
This increases binary size (typically by tens of kB) but allows using
|
|
dynamic_cast conversion and typeid operator.
|
|
|
|
choice COMPILER_STACK_CHECK_MODE
|
|
prompt "Stack smashing protection mode"
|
|
default COMPILER_STACK_CHECK_MODE_NONE
|
|
help
|
|
Stack smashing protection mode. Emit extra code to check for buffer overflows, such as stack
|
|
smashing attacks. This is done by adding a guard variable to functions with vulnerable objects.
|
|
The guards are initialized when a function is entered and then checked when the function exits.
|
|
If a guard check fails, program is halted. Protection has the following modes:
|
|
|
|
- In NORMAL mode (GCC flag: -fstack-protector) only functions that call alloca, and functions with
|
|
buffers larger than 8 bytes are protected.
|
|
|
|
- STRONG mode (GCC flag: -fstack-protector-strong) is like NORMAL, but includes additional functions
|
|
to be protected -- those that have local array definitions, or have references to local frame
|
|
addresses.
|
|
|
|
- In OVERALL mode (GCC flag: -fstack-protector-all) all functions are protected.
|
|
|
|
Modes have the following impact on code performance and coverage:
|
|
|
|
- performance: NORMAL > STRONG > OVERALL
|
|
|
|
- coverage: NORMAL < STRONG < OVERALL
|
|
|
|
|
|
config COMPILER_STACK_CHECK_MODE_NONE
|
|
bool "None"
|
|
config COMPILER_STACK_CHECK_MODE_NORM
|
|
bool "Normal"
|
|
config COMPILER_STACK_CHECK_MODE_STRONG
|
|
bool "Strong"
|
|
config COMPILER_STACK_CHECK_MODE_ALL
|
|
bool "Overall"
|
|
endchoice
|
|
|
|
config COMPILER_STACK_CHECK
|
|
bool
|
|
default !COMPILER_STACK_CHECK_MODE_NONE
|
|
help
|
|
Stack smashing protection.
|
|
|
|
config COMPILER_WARN_WRITE_STRINGS
|
|
bool "Enable -Wwrite-strings warning flag"
|
|
default "n"
|
|
help
|
|
Adds -Wwrite-strings flag for the C/C++ compilers.
|
|
|
|
For C, this gives string constants the type ``const char[]`` so that
|
|
copying the address of one into a non-const ``char *`` pointer
|
|
produces a warning. This warning helps to find at compile time code
|
|
that tries to write into a string constant.
|
|
|
|
For C++, this warns about the deprecated conversion from string
|
|
literals to ``char *``.
|
|
|
|
config COMPILER_DISABLE_GCC8_WARNINGS
|
|
bool "Disable new warnings introduced in GCC 6 - 8"
|
|
default "n"
|
|
help
|
|
Enable this option if using GCC 6 or newer, and wanting to disable warnings which don't appear with
|
|
GCC 5.
|
|
|
|
|
|
endmenu # Compiler Options
|
|
|
|
menu "Component config"
|
|
source "$COMPONENT_KCONFIGS_SOURCE_FILE"
|
|
endmenu
|
|
|
|
menu "Compatibility options"
|
|
config LEGACY_INCLUDE_COMMON_HEADERS
|
|
bool "Include headers across components as before IDF v4.0"
|
|
default n
|
|
help
|
|
Soc, esp32, and driver components, the most common
|
|
components. Some header of these components are included
|
|
implicitly by headers of other components before IDF v4.0.
|
|
It's not required for high-level components, but still
|
|
included through long header chain everywhere.
|
|
|
|
This is harmful to the modularity. So it's changed in IDF
|
|
v4.0.
|
|
|
|
You can still include these headers in a legacy way until it
|
|
is totally deprecated by enable this option.
|
|
|
|
endmenu #Compatibility options
|