2017-01-18 07:05:26 -05:00
|
|
|
menu "ESP32-specific"
|
2016-08-17 11:08:22 -04:00
|
|
|
|
2016-09-13 06:10:58 -04:00
|
|
|
choice ESP32_DEFAULT_CPU_FREQ_MHZ
|
|
|
|
prompt "CPU frequency"
|
2017-04-11 03:44:43 -04:00
|
|
|
default ESP32_DEFAULT_CPU_FREQ_160
|
2016-09-13 06:10:58 -04:00
|
|
|
help
|
|
|
|
CPU frequency to be set on application startup.
|
|
|
|
|
|
|
|
config ESP32_DEFAULT_CPU_FREQ_80
|
|
|
|
bool "80 MHz"
|
|
|
|
config ESP32_DEFAULT_CPU_FREQ_160
|
|
|
|
bool "160 MHz"
|
|
|
|
config ESP32_DEFAULT_CPU_FREQ_240
|
|
|
|
bool "240 MHz"
|
|
|
|
endchoice
|
|
|
|
|
|
|
|
config ESP32_DEFAULT_CPU_FREQ_MHZ
|
|
|
|
int
|
|
|
|
default 80 if ESP32_DEFAULT_CPU_FREQ_80
|
|
|
|
default 160 if ESP32_DEFAULT_CPU_FREQ_160
|
|
|
|
default 240 if ESP32_DEFAULT_CPU_FREQ_240
|
|
|
|
|
2016-09-22 06:36:23 -04:00
|
|
|
config MEMMAP_SMP
|
|
|
|
bool "Reserve memory for two cores"
|
|
|
|
default "y"
|
|
|
|
help
|
|
|
|
The ESP32 contains two cores. If you plan to only use one, you can disable this item
|
|
|
|
to save some memory. (ToDo: Make this automatically depend on unicore support)
|
|
|
|
|
|
|
|
config MEMMAP_TRACEMEM
|
2017-01-17 09:58:11 -05:00
|
|
|
bool
|
|
|
|
default "n"
|
|
|
|
|
|
|
|
config MEMMAP_TRACEMEM_TWOBANKS
|
|
|
|
bool
|
|
|
|
default "n"
|
|
|
|
|
|
|
|
config ESP32_TRAX
|
2016-09-22 06:36:23 -04:00
|
|
|
bool "Use TRAX tracing feature"
|
|
|
|
default "n"
|
2017-01-17 09:58:11 -05:00
|
|
|
select MEMMAP_TRACEMEM
|
2016-09-22 06:36:23 -04:00
|
|
|
help
|
|
|
|
The ESP32 contains a feature which allows you to trace the execution path the processor
|
|
|
|
has taken through the program. This is stored in a chunk of 32K (16K for single-processor)
|
|
|
|
of memory that can't be used for general purposes anymore. Disable this if you do not know
|
|
|
|
what this is.
|
|
|
|
|
2017-01-17 09:58:11 -05:00
|
|
|
config ESP32_TRAX_TWOBANKS
|
2016-10-17 00:18:17 -04:00
|
|
|
bool "Reserve memory for tracing both pro as well as app cpu execution"
|
|
|
|
default "n"
|
2017-01-17 09:58:11 -05:00
|
|
|
depends on ESP32_TRAX && MEMMAP_SMP
|
|
|
|
select MEMMAP_TRACEMEM_TWOBANKS
|
2016-10-17 00:18:17 -04:00
|
|
|
help
|
|
|
|
The ESP32 contains a feature which allows you to trace the execution path the processor
|
|
|
|
has taken through the program. This is stored in a chunk of 32K (16K for single-processor)
|
|
|
|
of memory that can't be used for general purposes anymore. Disable this if you do not know
|
|
|
|
what this is.
|
|
|
|
|
2016-09-28 00:27:25 -04:00
|
|
|
# Memory to reverse for trace, used in linker script
|
|
|
|
config TRACEMEM_RESERVE_DRAM
|
|
|
|
hex
|
2016-10-17 00:18:17 -04:00
|
|
|
default 0x8000 if MEMMAP_TRACEMEM && MEMMAP_TRACEMEM_TWOBANKS
|
|
|
|
default 0x4000 if MEMMAP_TRACEMEM && !MEMMAP_TRACEMEM_TWOBANKS
|
2016-09-28 00:27:25 -04:00
|
|
|
default 0x0
|
|
|
|
|
2016-12-21 18:56:23 -05:00
|
|
|
choice ESP32_COREDUMP_TO_FLASH_OR_UART
|
|
|
|
prompt "Core dump destination"
|
|
|
|
default ESP32_ENABLE_COREDUMP_TO_NONE
|
|
|
|
help
|
|
|
|
Select place to store core dump: flash, uart or none (to disable core dumps generation).
|
|
|
|
|
|
|
|
If core dump is configured to be stored in flash and custom partition table is used add
|
|
|
|
corresponding entry to your CSV. For examples, please see predefined partition table CSV descriptions
|
|
|
|
in the components/partition_table directory.
|
|
|
|
|
|
|
|
config ESP32_ENABLE_COREDUMP_TO_FLASH
|
|
|
|
bool "Flash"
|
2017-01-10 06:48:47 -05:00
|
|
|
select ESP32_ENABLE_COREDUMP
|
2016-12-21 18:56:23 -05:00
|
|
|
config ESP32_ENABLE_COREDUMP_TO_UART
|
|
|
|
bool "UART"
|
2017-01-10 06:48:47 -05:00
|
|
|
select ESP32_ENABLE_COREDUMP
|
2016-12-21 18:56:23 -05:00
|
|
|
config ESP32_ENABLE_COREDUMP_TO_NONE
|
|
|
|
bool "None"
|
|
|
|
endchoice
|
|
|
|
|
2017-01-10 06:48:47 -05:00
|
|
|
config ESP32_ENABLE_COREDUMP
|
|
|
|
bool
|
|
|
|
default F
|
|
|
|
help
|
|
|
|
Enables/disable core dump module.
|
|
|
|
|
|
|
|
config ESP32_CORE_DUMP_UART_DELAY
|
|
|
|
int "Core dump print to UART delay"
|
|
|
|
depends on ESP32_ENABLE_COREDUMP_TO_UART
|
|
|
|
default 0
|
|
|
|
help
|
|
|
|
Config delay (in ms) before printing core dump to UART.
|
|
|
|
Delay can be interrupted by pressing Enter key.
|
|
|
|
|
|
|
|
config ESP32_CORE_DUMP_LOG_LEVEL
|
|
|
|
int "Core dump module logging level"
|
|
|
|
depends on ESP32_ENABLE_COREDUMP
|
|
|
|
default 1
|
|
|
|
help
|
|
|
|
Config core dump module logging level (0-5).
|
|
|
|
|
2016-10-26 00:23:01 -04:00
|
|
|
# Not implemented and/or needs new silicon rev to work
|
2016-09-22 06:36:23 -04:00
|
|
|
config MEMMAP_SPISRAM
|
|
|
|
bool "Use external SPI SRAM chip as main memory"
|
2016-10-26 00:23:01 -04:00
|
|
|
depends on ESP32_NEEDS_NEW_SILICON_REV
|
2016-09-22 06:36:23 -04:00
|
|
|
default "n"
|
|
|
|
help
|
2017-01-10 00:04:04 -05:00
|
|
|
The ESP32 can control an external SPI SRAM chip, adding the memory it contains to the
|
2016-09-22 06:36:23 -04:00
|
|
|
main memory map. Enable this if you have this hardware and want to use it in the same
|
|
|
|
way as on-chip RAM.
|
2017-04-17 09:16:16 -04:00
|
|
|
|
2017-05-05 10:24:56 -04:00
|
|
|
choice NUMBER_OF_UNIVERSAL_MAC_ADDRESS
|
|
|
|
bool "Number of universally administered (by IEEE) MAC address"
|
|
|
|
default FOUR_UNIVERSAL_MAC_ADDRESS
|
|
|
|
help
|
|
|
|
Configure the number of universally administered (by IEEE) MAC addresses.
|
|
|
|
During initialisation, MAC addresses for each network interface are generated or derived from a
|
|
|
|
single base MAC address.
|
|
|
|
If the number of universal MAC addresses is four, all four interfaces (WiFi station, WiFi softap,
|
|
|
|
Bluetooth and Ethernet) receive a universally administered MAC address. These are generated
|
|
|
|
sequentially by adding 0, 1, 2 and 3 (respectively) to the final octet of the base MAC address.
|
|
|
|
If the number of universal MAC addresses is two, only two interfaces (WiFi station and Bluetooth)
|
|
|
|
receive a universally administered MAC address. These are generated sequentially by adding 0
|
|
|
|
and 1 (respectively) to the base MAC address. The remaining two interfaces (WiFi softap and Ethernet)
|
|
|
|
receive local MAC addresses. These are derived from the universal WiFi station and Bluetooth MAC
|
|
|
|
addresses, respectively.
|
|
|
|
When using the default (Espressif-assigned) base MAC address, either setting can be used. When using
|
|
|
|
a custom universal MAC address range, the correct setting will depend on the allocation of MAC
|
|
|
|
addresses in this range (either 2 or 4 per device.)
|
|
|
|
|
|
|
|
config TWO_UNIVERSAL_MAC_ADDRESS
|
2017-03-02 01:57:45 -05:00
|
|
|
bool "Two"
|
2017-05-05 10:24:56 -04:00
|
|
|
config FOUR_UNIVERSAL_MAC_ADDRESS
|
2017-03-02 01:57:45 -05:00
|
|
|
bool "Four"
|
|
|
|
endchoice
|
|
|
|
|
2017-05-05 10:24:56 -04:00
|
|
|
config NUMBER_OF_UNIVERSAL_MAC_ADDRESS
|
2017-03-02 01:57:45 -05:00
|
|
|
int
|
2017-05-05 10:24:56 -04:00
|
|
|
default 2 if TWO_UNIVERSAL_MAC_ADDRESS
|
|
|
|
default 4 if FOUR_UNIVERSAL_MAC_ADDRESS
|
2017-03-02 01:57:45 -05:00
|
|
|
|
2016-09-14 01:26:17 -04:00
|
|
|
config SYSTEM_EVENT_QUEUE_SIZE
|
2016-09-25 12:50:57 -04:00
|
|
|
int "System event queue size"
|
2016-08-17 11:08:22 -04:00
|
|
|
default 32
|
|
|
|
help
|
2016-09-14 00:55:41 -04:00
|
|
|
Config system event queue size in different application.
|
2016-08-17 11:08:22 -04:00
|
|
|
|
2016-09-14 00:55:41 -04:00
|
|
|
config SYSTEM_EVENT_TASK_STACK_SIZE
|
2016-09-25 12:50:57 -04:00
|
|
|
int "Event loop task stack size"
|
2017-01-16 04:06:12 -05:00
|
|
|
default 4096
|
2016-09-25 12:50:57 -04:00
|
|
|
help
|
|
|
|
Config system event task stack size in different application.
|
|
|
|
|
|
|
|
config MAIN_TASK_STACK_SIZE
|
|
|
|
int "Main task stack size"
|
|
|
|
default 4096
|
2016-08-17 11:08:22 -04:00
|
|
|
help
|
2017-06-29 19:39:54 -04:00
|
|
|
Configure the "main task" stack size. This is the stack of the task
|
|
|
|
which calls app_main(). If app_main() returns then this task is deleted
|
|
|
|
and its stack memory is freed.
|
|
|
|
|
|
|
|
config IPC_TASK_STACK_SIZE
|
|
|
|
int "Inter-Processor Call (IPC) task stack size"
|
|
|
|
default 1024
|
|
|
|
range 512 65536 if !ESP32_APPTRACE_ENABLE
|
|
|
|
range 2048 65536 if ESP32_APPTRACE_ENABLE
|
|
|
|
help
|
|
|
|
Configure the IPC tasks stack size. One IPC task runs on each core
|
|
|
|
(in dual core mode), and allows for cross-core function calls.
|
|
|
|
|
|
|
|
See IPC documentation for more details.
|
2016-08-17 11:08:22 -04:00
|
|
|
|
2017-06-29 19:39:54 -04:00
|
|
|
The default stack size should be enough for most common use cases.
|
|
|
|
It can be shrunk if you are sure that you do not use any custom
|
|
|
|
IPC functionality.
|
2016-08-23 03:02:27 -04:00
|
|
|
|
2017-08-07 16:21:19 -04:00
|
|
|
config TIMER_TASK_STACK_SIZE
|
|
|
|
int "High-resolution timer task stack size"
|
|
|
|
default 4096
|
|
|
|
range 2048 65536
|
|
|
|
help
|
|
|
|
Configure the stack size of esp_timer/ets_timer task. This task is used
|
|
|
|
to dispatch callbacks of timers created using ets_timer and esp_timer
|
|
|
|
APIs. If you are seing stack overflow errors in timer task, increase
|
|
|
|
this value.
|
|
|
|
|
|
|
|
Note that this is not the same as FreeRTOS timer task. To configure
|
|
|
|
FreeRTOS timer task size, see "FreeRTOS timer task stack size" option
|
|
|
|
in "FreeRTOS" menu.
|
|
|
|
|
2017-08-15 04:23:23 -04:00
|
|
|
choice NEWLIB_STDOUT_LINE_ENDING
|
|
|
|
prompt "Line ending for UART output"
|
|
|
|
default NEWLIB_STDOUT_LINE_ENDING_CRLF
|
|
|
|
help
|
|
|
|
This option allows configuring the desired line endings sent to UART
|
|
|
|
when a newline ('\n', LF) appears on stdout.
|
|
|
|
Three options are possible:
|
|
|
|
|
|
|
|
CRLF: whenever LF is encountered, prepend it with CR
|
|
|
|
|
|
|
|
LF: no modification is applied, stdout is sent as is
|
|
|
|
|
|
|
|
CR: each occurence of LF is replaced with CR
|
|
|
|
|
|
|
|
This option doesn't affect behavior of the UART driver (drivers/uart.h).
|
|
|
|
|
|
|
|
config NEWLIB_STDOUT_LINE_ENDING_CRLF
|
|
|
|
bool "CRLF"
|
|
|
|
config NEWLIB_STDOUT_LINE_ENDING_LF
|
|
|
|
bool "LF"
|
|
|
|
config NEWLIB_STDOUT_LINE_ENDING_CR
|
|
|
|
bool "CR"
|
|
|
|
endchoice
|
|
|
|
|
|
|
|
choice NEWLIB_STDIN_LINE_ENDING
|
|
|
|
prompt "Line ending for UART input"
|
|
|
|
default NEWLIB_STDIN_LINE_ENDING_CR
|
|
|
|
help
|
|
|
|
This option allows configuring which input sequence on UART produces
|
|
|
|
a newline ('\n', LF) on stdin.
|
|
|
|
Three options are possible:
|
|
|
|
|
|
|
|
CRLF: CRLF is converted to LF
|
2017-01-09 09:50:42 -05:00
|
|
|
|
2017-08-15 04:23:23 -04:00
|
|
|
LF: no modification is applied, input is sent to stdin as is
|
|
|
|
|
|
|
|
CR: each occurence of CR is replaced with LF
|
2017-01-09 09:50:42 -05:00
|
|
|
|
|
|
|
This option doesn't affect behavior of the UART driver (drivers/uart.h).
|
2017-08-15 04:23:23 -04:00
|
|
|
|
|
|
|
config NEWLIB_STDIN_LINE_ENDING_CRLF
|
|
|
|
bool "CRLF"
|
|
|
|
config NEWLIB_STDIN_LINE_ENDING_LF
|
|
|
|
bool "LF"
|
|
|
|
config NEWLIB_STDIN_LINE_ENDING_CR
|
|
|
|
bool "CR"
|
|
|
|
endchoice
|
2016-08-23 03:02:27 -04:00
|
|
|
|
2016-11-07 05:43:29 -05:00
|
|
|
config NEWLIB_NANO_FORMAT
|
|
|
|
bool "Enable 'nano' formatting options for printf/scanf family"
|
|
|
|
default n
|
|
|
|
help
|
|
|
|
ESP32 ROM contains parts of newlib C library, including printf/scanf family
|
|
|
|
of functions. These functions have been compiled with so-called "nano"
|
|
|
|
formatting option. This option doesn't support 64-bit integer formats and C99
|
2017-01-10 00:04:04 -05:00
|
|
|
features, such as positional arguments.
|
2016-11-07 05:43:29 -05:00
|
|
|
|
|
|
|
For more details about "nano" formatting option, please see newlib readme file,
|
|
|
|
search for '--enable-newlib-nano-formatted-io':
|
|
|
|
https://sourceware.org/newlib/README
|
|
|
|
|
|
|
|
If this option is enabled, build system will use functions available in
|
|
|
|
ROM, reducing the application binary size. Functions available in ROM run
|
|
|
|
faster than functions which run from flash. Functions available in ROM can
|
|
|
|
also run when flash instruction cache is disabled.
|
|
|
|
|
|
|
|
If you need 64-bit integer formatting support or C99 features, keep this
|
|
|
|
option disabled.
|
|
|
|
|
2016-10-27 04:17:28 -04:00
|
|
|
choice CONSOLE_UART
|
|
|
|
prompt "UART for console output"
|
|
|
|
default CONSOLE_UART_DEFAULT
|
|
|
|
help
|
|
|
|
Select whether to use UART for console output (through stdout and stderr).
|
2017-08-20 12:01:03 -04:00
|
|
|
|
2016-10-27 04:17:28 -04:00
|
|
|
- Default is to use UART0 on pins GPIO1(TX) and GPIO3(RX).
|
|
|
|
- If "Custom" is selected, UART0 or UART1 can be chosen,
|
|
|
|
and any pins can be selected.
|
|
|
|
- If "None" is selected, there will be no console output on any UART, except
|
|
|
|
for initial output from ROM bootloader. This output can be further suppressed by
|
|
|
|
bootstrapping GPIO13 pin to low logic level.
|
|
|
|
|
|
|
|
config CONSOLE_UART_DEFAULT
|
|
|
|
bool "Default: UART0, TX=GPIO1, RX=GPIO3"
|
|
|
|
config CONSOLE_UART_CUSTOM
|
|
|
|
bool "Custom"
|
|
|
|
config CONSOLE_UART_NONE
|
|
|
|
bool "None"
|
|
|
|
endchoice
|
|
|
|
|
|
|
|
choice CONSOLE_UART_NUM
|
2017-01-10 00:04:04 -05:00
|
|
|
prompt "UART peripheral to use for console output (0-1)"
|
|
|
|
depends on CONSOLE_UART_CUSTOM
|
2016-10-27 04:17:28 -04:00
|
|
|
default CONSOLE_UART_CUSTOM_NUM_0
|
|
|
|
help
|
2017-01-10 00:04:04 -05:00
|
|
|
Due of a ROM bug, UART2 is not supported for console output
|
|
|
|
via ets_printf.
|
2016-10-27 04:17:28 -04:00
|
|
|
|
|
|
|
config CONSOLE_UART_CUSTOM_NUM_0
|
2017-01-10 00:04:04 -05:00
|
|
|
bool "UART0"
|
2016-10-27 04:17:28 -04:00
|
|
|
config CONSOLE_UART_CUSTOM_NUM_1
|
2017-01-10 00:04:04 -05:00
|
|
|
bool "UART1"
|
2016-10-27 04:17:28 -04:00
|
|
|
endchoice
|
|
|
|
|
|
|
|
config CONSOLE_UART_NUM
|
2017-01-10 00:04:04 -05:00
|
|
|
int
|
|
|
|
default 0 if CONSOLE_UART_DEFAULT || CONSOLE_UART_NONE
|
|
|
|
default 0 if CONSOLE_UART_CUSTOM_NUM_0
|
|
|
|
default 1 if CONSOLE_UART_CUSTOM_NUM_1
|
2016-10-27 04:17:28 -04:00
|
|
|
|
|
|
|
config CONSOLE_UART_TX_GPIO
|
2017-01-10 00:04:04 -05:00
|
|
|
int "UART TX on GPIO#"
|
|
|
|
depends on CONSOLE_UART_CUSTOM
|
|
|
|
range 0 33
|
|
|
|
default 19
|
2016-10-27 04:17:28 -04:00
|
|
|
|
|
|
|
config CONSOLE_UART_RX_GPIO
|
2017-01-10 00:04:04 -05:00
|
|
|
int "UART RX on GPIO#"
|
|
|
|
depends on CONSOLE_UART_CUSTOM
|
|
|
|
range 0 39
|
|
|
|
default 21
|
2016-10-27 04:17:28 -04:00
|
|
|
|
|
|
|
config CONSOLE_UART_BAUDRATE
|
2017-01-10 00:04:04 -05:00
|
|
|
int "UART console baud rate"
|
|
|
|
depends on !CONSOLE_UART_NONE
|
|
|
|
default 115200
|
|
|
|
range 1200 4000000
|
2016-10-27 04:17:28 -04:00
|
|
|
|
2016-09-20 21:24:02 -04:00
|
|
|
config ULP_COPROC_ENABLED
|
|
|
|
bool "Enable Ultra Low Power (ULP) Coprocessor"
|
|
|
|
default "n"
|
|
|
|
help
|
2016-09-28 01:24:58 -04:00
|
|
|
Set to 'y' if you plan to load a firmware for the coprocessor.
|
2016-09-20 21:24:02 -04:00
|
|
|
|
2016-09-28 01:24:58 -04:00
|
|
|
If this option is enabled, further coprocessor configuration will appear in the Components menu.
|
2016-09-20 21:24:02 -04:00
|
|
|
|
|
|
|
config ULP_COPROC_RESERVE_MEM
|
2017-08-20 12:01:03 -04:00
|
|
|
int
|
|
|
|
prompt "RTC slow memory reserved for coprocessor" if ULP_COPROC_ENABLED
|
|
|
|
default 512 if ULP_COPROC_ENABLED
|
|
|
|
range 32 8192 if ULP_COPROC_ENABLED
|
|
|
|
default 0 if !ULP_COPROC_ENABLED
|
|
|
|
range 0 0 if !ULP_COPROC_ENABLED
|
2016-09-28 01:24:58 -04:00
|
|
|
help
|
|
|
|
Bytes of memory to reserve for ULP coprocessor firmware & data.
|
2016-09-20 21:24:02 -04:00
|
|
|
|
2016-09-28 01:24:58 -04:00
|
|
|
Data is reserved at the beginning of RTC slow memory.
|
2016-09-20 21:24:02 -04:00
|
|
|
|
2016-10-26 00:23:01 -04:00
|
|
|
choice ESP32_PANIC
|
|
|
|
prompt "Panic handler behaviour"
|
2016-10-28 00:05:42 -04:00
|
|
|
default ESP32_PANIC_PRINT_REBOOT
|
2016-10-26 00:23:01 -04:00
|
|
|
help
|
2017-01-10 00:04:04 -05:00
|
|
|
If FreeRTOS detects unexpected behaviour or an unhandled exception, the panic handler is
|
2016-10-26 00:23:01 -04:00
|
|
|
invoked. Configure the panic handlers action here.
|
|
|
|
|
|
|
|
config ESP32_PANIC_PRINT_HALT
|
|
|
|
bool "Print registers and halt"
|
|
|
|
help
|
2017-01-10 00:04:04 -05:00
|
|
|
Outputs the relevant registers over the serial port and halt the
|
2016-10-26 00:23:01 -04:00
|
|
|
processor. Needs a manual reset to restart.
|
|
|
|
|
|
|
|
config ESP32_PANIC_PRINT_REBOOT
|
|
|
|
bool "Print registers and reboot"
|
|
|
|
help
|
|
|
|
Outputs the relevant registers over the serial port and immediately
|
|
|
|
reset the processor.
|
|
|
|
|
|
|
|
config ESP32_PANIC_SILENT_REBOOT
|
|
|
|
bool "Silent reboot"
|
|
|
|
help
|
|
|
|
Just resets the processor without outputting anything
|
|
|
|
|
|
|
|
config ESP32_PANIC_GDBSTUB
|
|
|
|
bool "Invoke GDBStub"
|
|
|
|
help
|
|
|
|
Invoke gdbstub on the serial port, allowing for gdb to attach to it to do a postmortem
|
|
|
|
of the crash.
|
|
|
|
endchoice
|
|
|
|
|
|
|
|
config ESP32_DEBUG_OCDAWARE
|
|
|
|
bool "Make exception and panic handlers JTAG/OCD aware"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
The FreeRTOS panic and unhandled exception handers can detect a JTAG OCD debugger and
|
|
|
|
instead of panicking, have the debugger stop on the offending instruction.
|
|
|
|
|
|
|
|
|
2016-10-21 05:59:57 -04:00
|
|
|
config INT_WDT
|
|
|
|
bool "Interrupt watchdog"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
This watchdog timer can detect if the FreeRTOS tick interrupt has not been called for a certain time,
|
|
|
|
either because a task turned off interrupts and did not turn them on for a long time, or because an
|
|
|
|
interrupt handler did not return. It will try to invoke the panic handler first and failing that
|
|
|
|
reset the SoC.
|
|
|
|
|
|
|
|
config INT_WDT_TIMEOUT_MS
|
|
|
|
int "Interrupt watchdog timeout (ms)"
|
|
|
|
depends on INT_WDT
|
2016-10-28 04:17:41 -04:00
|
|
|
default 300
|
2016-10-25 05:05:13 -04:00
|
|
|
range 10 10000
|
2016-10-21 05:59:57 -04:00
|
|
|
help
|
2016-10-21 07:30:29 -04:00
|
|
|
The timeout of the watchdog, in miliseconds. Make this higher than the FreeRTOS tick rate.
|
2016-10-21 05:59:57 -04:00
|
|
|
|
2016-10-25 06:08:55 -04:00
|
|
|
config INT_WDT_CHECK_CPU1
|
|
|
|
bool "Also watch CPU1 tick interrupt"
|
|
|
|
depends on INT_WDT && !FREERTOS_UNICORE
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Also detect if interrupts on CPU 1 are disabled for too long.
|
|
|
|
|
2016-10-21 05:59:57 -04:00
|
|
|
config TASK_WDT
|
|
|
|
bool "Task watchdog"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
This watchdog timer can be used to make sure individual tasks are still running.
|
|
|
|
|
|
|
|
config TASK_WDT_PANIC
|
|
|
|
bool "Invoke panic handler when Task Watchdog is triggered"
|
|
|
|
depends on TASK_WDT
|
|
|
|
default n
|
|
|
|
help
|
|
|
|
Normally, the Task Watchdog will only print out a warning if it detects it has not
|
|
|
|
been fed. If this is enabled, it will invoke the panic handler instead, which
|
|
|
|
can then halt or reboot the chip.
|
|
|
|
|
|
|
|
config TASK_WDT_TIMEOUT_S
|
|
|
|
int "Task watchdog timeout (seconds)"
|
|
|
|
depends on TASK_WDT
|
|
|
|
range 1 60
|
|
|
|
default 5
|
|
|
|
help
|
|
|
|
Timeout for the task WDT, in seconds.
|
|
|
|
|
|
|
|
config TASK_WDT_CHECK_IDLE_TASK
|
2016-10-25 06:08:55 -04:00
|
|
|
bool "Task watchdog watches CPU0 idle task"
|
2016-10-21 05:59:57 -04:00
|
|
|
depends on TASK_WDT
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
With this turned on, the task WDT can detect if the idle task is not called within the task
|
|
|
|
watchdog timeout period. The idle task not being called usually is a symptom of another
|
2017-01-10 00:04:04 -05:00
|
|
|
task hoarding the CPU. It is also a bad thing because FreeRTOS household tasks depend on the
|
|
|
|
idle task getting some runtime every now and then. Take Care: With this disabled, this
|
2016-10-25 05:05:13 -04:00
|
|
|
watchdog will trigger if no tasks register themselves within the timeout value.
|
2016-10-21 05:59:57 -04:00
|
|
|
|
2016-10-25 06:08:55 -04:00
|
|
|
config TASK_WDT_CHECK_IDLE_TASK_CPU1
|
|
|
|
bool "Task watchdog also watches CPU1 idle task"
|
|
|
|
depends on TASK_WDT_CHECK_IDLE_TASK && !FREERTOS_UNICORE
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Also check the idle task that runs on CPU1.
|
|
|
|
|
2016-10-25 05:05:13 -04:00
|
|
|
#The brownout detector code is disabled (by making it depend on a nonexisting symbol) because the current revision of ESP32
|
|
|
|
#silicon has a bug in the brown-out detector, rendering it unusable for resetting the CPU.
|
2016-10-21 05:59:57 -04:00
|
|
|
config BROWNOUT_DET
|
|
|
|
bool "Hardware brownout detect & reset"
|
|
|
|
default y
|
|
|
|
help
|
2017-01-10 00:04:04 -05:00
|
|
|
The ESP32 has a built-in brownout detector which can detect if the voltage is lower than
|
2016-10-21 05:59:57 -04:00
|
|
|
a specific value. If this happens, it will reset the chip in order to prevent unintended
|
|
|
|
behaviour.
|
|
|
|
|
|
|
|
choice BROWNOUT_DET_LVL_SEL
|
|
|
|
prompt "Brownout voltage level"
|
|
|
|
depends on BROWNOUT_DET
|
|
|
|
default BROWNOUT_DET_LVL_SEL_25
|
|
|
|
help
|
|
|
|
The brownout detector will reset the chip when the supply voltage is below this level.
|
|
|
|
|
2016-10-25 05:05:13 -04:00
|
|
|
#The voltage levels here are estimates, more work needs to be done to figure out the exact voltages
|
|
|
|
#of the brownout threshold levels.
|
2016-10-21 05:59:57 -04:00
|
|
|
config BROWNOUT_DET_LVL_SEL_0
|
|
|
|
bool "2.1V"
|
|
|
|
config BROWNOUT_DET_LVL_SEL_1
|
|
|
|
bool "2.2V"
|
|
|
|
config BROWNOUT_DET_LVL_SEL_2
|
|
|
|
bool "2.3V"
|
|
|
|
config BROWNOUT_DET_LVL_SEL_3
|
|
|
|
bool "2.4V"
|
|
|
|
config BROWNOUT_DET_LVL_SEL_4
|
|
|
|
bool "2.5V"
|
|
|
|
config BROWNOUT_DET_LVL_SEL_5
|
|
|
|
bool "2.6V"
|
|
|
|
config BROWNOUT_DET_LVL_SEL_6
|
|
|
|
bool "2.7V"
|
|
|
|
config BROWNOUT_DET_LVL_SEL_7
|
|
|
|
bool "2.8V"
|
|
|
|
endchoice
|
|
|
|
|
|
|
|
config BROWNOUT_DET_LVL
|
|
|
|
int
|
|
|
|
default 0 if BROWNOUT_DET_LVL_SEL_0
|
|
|
|
default 1 if BROWNOUT_DET_LVL_SEL_1
|
|
|
|
default 2 if BROWNOUT_DET_LVL_SEL_2
|
|
|
|
default 3 if BROWNOUT_DET_LVL_SEL_3
|
|
|
|
default 4 if BROWNOUT_DET_LVL_SEL_4
|
|
|
|
default 5 if BROWNOUT_DET_LVL_SEL_5
|
|
|
|
default 6 if BROWNOUT_DET_LVL_SEL_6
|
|
|
|
default 7 if BROWNOUT_DET_LVL_SEL_7
|
|
|
|
|
|
|
|
|
2016-11-02 05:17:28 -04:00
|
|
|
choice ESP32_TIME_SYSCALL
|
2017-01-10 00:04:04 -05:00
|
|
|
prompt "Timers used for gettimeofday function"
|
|
|
|
default ESP32_TIME_SYSCALL_USE_RTC_FRC1
|
|
|
|
help
|
|
|
|
This setting defines which hardware timers are used to
|
|
|
|
implement 'gettimeofday' and 'time' functions in C library.
|
|
|
|
|
|
|
|
- If only FRC1 timer is used, gettimeofday will provide time at
|
|
|
|
microsecond resolution. Time will not be preserved when going
|
|
|
|
into deep sleep mode.
|
|
|
|
- If both FRC1 and RTC timers are used, timekeeping will
|
|
|
|
continue in deep sleep. Time will be reported at 1 microsecond
|
|
|
|
resolution.
|
|
|
|
- If only RTC timer is used, timekeeping will continue in
|
|
|
|
deep sleep, but time will be measured at 6.(6) microsecond
|
|
|
|
resolution. Also the gettimeofday function itself may take
|
|
|
|
longer to run.
|
|
|
|
- If no timers are used, gettimeofday and time functions
|
|
|
|
return -1 and set errno to ENOSYS.
|
2017-01-11 04:28:09 -05:00
|
|
|
- When RTC is used for timekeeping, two RTC_STORE registers are
|
|
|
|
used to keep time in deep sleep mode.
|
2017-01-10 00:04:04 -05:00
|
|
|
|
2016-11-02 05:17:28 -04:00
|
|
|
config ESP32_TIME_SYSCALL_USE_RTC
|
|
|
|
bool "RTC"
|
|
|
|
config ESP32_TIME_SYSCALL_USE_RTC_FRC1
|
|
|
|
bool "RTC and FRC1"
|
|
|
|
config ESP32_TIME_SYSCALL_USE_FRC1
|
|
|
|
bool "FRC1"
|
|
|
|
config ESP32_TIME_SYSCALL_USE_NONE
|
|
|
|
bool "None"
|
|
|
|
endchoice
|
2016-10-21 05:59:57 -04:00
|
|
|
|
2016-11-03 02:49:05 -04:00
|
|
|
choice ESP32_RTC_CLOCK_SOURCE
|
2017-01-10 00:04:04 -05:00
|
|
|
prompt "RTC clock source"
|
|
|
|
default ESP32_RTC_CLOCK_SOURCE_INTERNAL_RC
|
|
|
|
help
|
|
|
|
Choose which clock is used as RTC clock source.
|
2016-11-03 02:49:05 -04:00
|
|
|
|
|
|
|
config ESP32_RTC_CLOCK_SOURCE_INTERNAL_RC
|
2017-04-11 03:44:43 -04:00
|
|
|
bool "Internal 150kHz RC oscillator"
|
2016-11-03 02:49:05 -04:00
|
|
|
config ESP32_RTC_CLOCK_SOURCE_EXTERNAL_CRYSTAL
|
2017-01-10 00:04:04 -05:00
|
|
|
bool "External 32kHz crystal"
|
2016-11-03 02:49:05 -04:00
|
|
|
endchoice
|
2016-10-21 05:59:57 -04:00
|
|
|
|
2017-04-24 06:36:47 -04:00
|
|
|
config ESP32_RTC_CLK_CAL_CYCLES
|
|
|
|
int "Number of cycles for RTC_SLOW_CLK calibration"
|
|
|
|
default 1024
|
|
|
|
range 0 125000
|
|
|
|
help
|
|
|
|
When the startup code initializes RTC_SLOW_CLK, it can perform
|
|
|
|
calibration by comparing the RTC_SLOW_CLK frequency with main XTAL
|
|
|
|
frequency. This option sets the number of RTC_SLOW_CLK cycles measured
|
|
|
|
by the calibration routine. Higher numbers increase calibration
|
|
|
|
precision, which may be important for applications which spend a lot of
|
|
|
|
time in deep sleep. Lower numbers reduce startup time.
|
|
|
|
|
|
|
|
When this option is set to 0, clock calibration will not be performed at
|
|
|
|
startup, and approximate clock frequencies will be assumed:
|
2017-08-20 12:01:03 -04:00
|
|
|
|
2017-04-24 06:36:47 -04:00
|
|
|
- 150000 Hz if internal RC oscillator is used as clock source
|
|
|
|
- 32768 Hz if the 32k crystal oscillator is used
|
|
|
|
|
2016-12-12 10:20:15 -05:00
|
|
|
config ESP32_DEEP_SLEEP_WAKEUP_DELAY
|
2017-01-10 00:04:04 -05:00
|
|
|
int "Extra delay in deep sleep wake stub (in us)"
|
2017-05-14 22:32:35 -04:00
|
|
|
default 2000
|
2017-01-10 00:04:04 -05:00
|
|
|
range 0 5000
|
|
|
|
help
|
|
|
|
When ESP32 exits deep sleep, the CPU and the flash chip are powered on
|
|
|
|
at the same time. CPU will run deep sleep stub first, and then
|
|
|
|
proceed to load code from flash. Some flash chips need sufficient
|
|
|
|
time to pass between power on and first read operation. By default,
|
2017-05-14 22:32:35 -04:00
|
|
|
without any extra delay, this time is approximately 900us, although
|
|
|
|
some flash chip types need more than that.
|
|
|
|
|
|
|
|
By default extra delay is set to 2000us. When optimizing startup time
|
|
|
|
for applications which require it, this value may be reduced.
|
2016-12-12 10:20:15 -05:00
|
|
|
|
2017-01-10 00:04:04 -05:00
|
|
|
If you are seeing "flash read err, 1000" message printed to the
|
|
|
|
console after deep sleep reset, try increasing this value.
|
|
|
|
|
2017-04-24 03:30:27 -04:00
|
|
|
choice ESP32_XTAL_FREQ_SEL
|
|
|
|
prompt "Main XTAL frequency"
|
2017-08-23 04:33:26 -04:00
|
|
|
default ESP32_XTAL_FREQ_40
|
2017-04-24 03:30:27 -04:00
|
|
|
help
|
|
|
|
ESP32 currently supports the following XTAL frequencies:
|
2017-08-20 12:01:03 -04:00
|
|
|
|
|
|
|
- 26 MHz
|
|
|
|
- 40 MHz
|
|
|
|
|
2017-04-24 03:30:27 -04:00
|
|
|
Startup code can automatically estimate XTAL frequency. This feature
|
|
|
|
uses the internal 8MHz oscillator as a reference. Because the internal
|
|
|
|
oscillator frequency is temperature dependent, it is not recommended
|
|
|
|
to use automatic XTAL frequency detection in applications which need
|
|
|
|
to work at high ambient temperatures and use high-temperature
|
|
|
|
qualified chips and modules.
|
|
|
|
config ESP32_XTAL_FREQ_40
|
|
|
|
bool "40 MHz"
|
|
|
|
config ESP32_XTAL_FREQ_26
|
|
|
|
bool "26 MHz"
|
|
|
|
config ESP32_XTAL_FREQ_AUTO
|
|
|
|
bool "Autodetect"
|
|
|
|
endchoice
|
|
|
|
|
|
|
|
# Keep these values in sync with rtc_xtal_freq_t enum in soc/rtc.h
|
|
|
|
config ESP32_XTAL_FREQ
|
|
|
|
int
|
|
|
|
default 0 if ESP32_XTAL_FREQ_AUTO
|
|
|
|
default 40 if ESP32_XTAL_FREQ_40
|
|
|
|
default 26 if ESP32_XTAL_FREQ_26
|
|
|
|
|
2017-08-22 00:55:23 -04:00
|
|
|
config DISABLE_BASIC_ROM_CONSOLE
|
|
|
|
bool "Permanently disable BASIC ROM Console"
|
|
|
|
default n
|
|
|
|
help
|
|
|
|
If set, the first time the app boots it will disable the BASIC ROM Console
|
|
|
|
permanently (by burning an efuse).
|
|
|
|
|
|
|
|
Otherwise, the BASIC ROM Console starts on reset if no valid bootloader is
|
|
|
|
read from the flash.
|
|
|
|
|
|
|
|
(Enabling secure boot also disables the BASIC ROM Console by default.)
|
|
|
|
|
2017-08-10 01:16:36 -04:00
|
|
|
config NO_BLOBS
|
|
|
|
bool "No Binary Blobs"
|
|
|
|
depends on !BT_ENABLED
|
|
|
|
default n
|
|
|
|
help
|
|
|
|
If enabled, this disables the linking of binary libraries in the application build. Note
|
|
|
|
that after enabling this Wi-Fi/Bluetooth will not work.
|
|
|
|
|
2017-08-07 16:21:19 -04:00
|
|
|
config ESP_TIMER_PROFILING
|
|
|
|
bool "Enable esp_timer profiling features"
|
|
|
|
depends on MAKING_ESP_TIMER_A_PUBLIC_API
|
|
|
|
default n
|
|
|
|
help
|
|
|
|
If enabled, esp_timer_dump will dump information such as number of times
|
|
|
|
the timer was started, number of times the timer has triggered, and the
|
|
|
|
total time it took for the callback to run.
|
|
|
|
This option has some effect on timer performance and the amount of memory
|
|
|
|
used for timer storage, and should only be used for debugging/testing
|
|
|
|
purposes.
|
|
|
|
|
2017-08-22 00:55:23 -04:00
|
|
|
endmenu # ESP32-Specific
|
2017-08-20 12:01:03 -04:00
|
|
|
|
2017-08-08 00:53:52 -04:00
|
|
|
menu Wi-Fi
|
2017-01-10 00:04:04 -05:00
|
|
|
|
|
|
|
config SW_COEXIST_ENABLE
|
|
|
|
bool "Software controls WiFi/Bluetooth coexistence"
|
2017-08-08 00:53:52 -04:00
|
|
|
depends on BT_ENABLED
|
2017-01-10 00:04:04 -05:00
|
|
|
default n
|
|
|
|
help
|
|
|
|
If enabled, WiFi & Bluetooth coexistence is controlled by software rather than hardware.
|
|
|
|
Recommended for heavy traffic scenarios. Both coexistence configuration options are
|
|
|
|
automatically managed, no user intervention is required.
|
2016-12-12 10:20:15 -05:00
|
|
|
|
2017-01-18 07:05:26 -05:00
|
|
|
|
2017-02-21 01:52:25 -05:00
|
|
|
config ESP32_WIFI_STATIC_RX_BUFFER_NUM
|
|
|
|
int "Max number of WiFi static RX buffers"
|
2017-01-18 07:05:26 -05:00
|
|
|
range 2 25
|
2017-02-09 21:28:03 -05:00
|
|
|
default 10
|
2017-01-18 07:05:26 -05:00
|
|
|
help
|
2017-02-21 01:52:25 -05:00
|
|
|
Set the number of WiFi static rx buffers. Each buffer takes approximately 1.6KB of RAM.
|
|
|
|
The static rx buffers are allocated when esp_wifi_init is called, they are not freed
|
|
|
|
until esp_wifi_deinit is called.
|
|
|
|
WiFi hardware use these buffers to receive packets, generally larger number for higher
|
|
|
|
throughput but more memory, smaller number for lower throughput but less memory.
|
|
|
|
|
|
|
|
config ESP32_WIFI_DYNAMIC_RX_BUFFER_NUM
|
|
|
|
int "Max number of WiFi dynamic RX buffers"
|
2017-04-20 03:01:59 -04:00
|
|
|
range 0 128
|
2017-05-09 10:15:08 -04:00
|
|
|
default 32
|
2017-02-21 01:52:25 -05:00
|
|
|
help
|
|
|
|
Set the number of WiFi dynamic rx buffers, 0 means no limitation for dynamic rx buffer
|
|
|
|
allocation. The size of dynamic rx buffers is not fixed.
|
|
|
|
For each received packet in static rx buffers, WiFi driver makes a copy
|
|
|
|
to dynamic rx buffers and then deliver it to high layer stack. The dynamic rx buffer
|
|
|
|
is freed when the application, such as socket, successfully received the packet.
|
|
|
|
For some applications, the WiFi driver receiving speed is faster than application
|
|
|
|
consuming speed, we may run out of memory if no limitation for the dynamic rx buffer
|
|
|
|
number. Generally the number of dynamic rx buffer should be no less than static
|
|
|
|
rx buffer number if it is not 0.
|
|
|
|
|
2017-03-14 09:03:41 -04:00
|
|
|
choice ESP32_WIFI_TX_BUFFER
|
|
|
|
prompt "Type of WiFi TX buffers"
|
|
|
|
default ESP32_WIFI_DYNAMIC_TX_BUFFER
|
|
|
|
help
|
|
|
|
Select type of WiFi tx buffers and show the submenu with the number of WiFi tx buffers choice.
|
|
|
|
If "STATIC" is selected, WiFi tx buffers are allocated when WiFi is initialized and released
|
|
|
|
when WiFi is de-initialized. If "DYNAMIC" is selected, WiFi tx buffer is allocated when tx
|
|
|
|
data is delivered from LWIP to WiFi and released when tx data is sent out by WiFi.
|
|
|
|
The size of each static tx buffers is fixed to about 1.6KB and the size of dynamic tx buffers is
|
|
|
|
depend on the length of the data delivered from LWIP.
|
|
|
|
If PSRAM is enabled, "STATIC" should be selected to guarantee enough WiFi tx buffers.
|
|
|
|
If PSRAM is disabled, "DYNAMIC" should be selected to improve the utilization of RAM.
|
|
|
|
|
|
|
|
config ESP32_WIFI_STATIC_TX_BUFFER
|
|
|
|
bool "STATIC"
|
|
|
|
config ESP32_WIFI_DYNAMIC_TX_BUFFER
|
|
|
|
bool "DYNAMIC"
|
|
|
|
endchoice
|
|
|
|
|
|
|
|
config ESP32_WIFI_TX_BUFFER_TYPE
|
|
|
|
int
|
|
|
|
default 0 if ESP32_WIFI_STATIC_TX_BUFFER
|
|
|
|
default 1 if ESP32_WIFI_DYNAMIC_TX_BUFFER
|
|
|
|
|
|
|
|
config ESP32_WIFI_STATIC_TX_BUFFER_NUM
|
|
|
|
int "Max number of WiFi static TX buffers"
|
|
|
|
depends on ESP32_WIFI_STATIC_TX_BUFFER
|
|
|
|
range 16 64
|
|
|
|
default 32
|
|
|
|
help
|
|
|
|
Set the number of WiFi static tx buffers. Each buffer takes approximately 1.6KB of RAM.
|
|
|
|
The static rx buffers are allocated when esp_wifi_init is called, they are not released
|
|
|
|
until esp_wifi_deinit is called.
|
|
|
|
For each tx packet from high layer stack, WiFi driver make a copy of it. For some applications,
|
|
|
|
especially the UDP application, the high layer deliver speed is faster than the WiFi tx
|
|
|
|
speed, we may run out of static tx buffers.
|
|
|
|
|
2017-02-21 01:52:25 -05:00
|
|
|
config ESP32_WIFI_DYNAMIC_TX_BUFFER_NUM
|
|
|
|
int "Max number of WiFi dynamic TX buffers"
|
2017-03-14 09:03:41 -04:00
|
|
|
depends on ESP32_WIFI_DYNAMIC_TX_BUFFER
|
2017-02-21 01:52:25 -05:00
|
|
|
range 16 64
|
|
|
|
default 32
|
|
|
|
help
|
|
|
|
Set the number of WiFi dynamic tx buffers, 0 means no limitation for dynamic tx buffer
|
|
|
|
allocation. The size of dynamic tx buffers is not fixed.
|
|
|
|
For each tx packet from high layer stack, WiFi driver make a copy of it. For some applications,
|
|
|
|
especially the UDP application, the high layer deliver speed is faster than the WiFi tx
|
|
|
|
speed, we may run out of memory if no limitation for the dynamic tx buffer number.
|
|
|
|
|
|
|
|
config ESP32_WIFI_AMPDU_ENABLED
|
|
|
|
bool "WiFi AMPDU"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Select this option to enable AMPDU feature
|
|
|
|
|
|
|
|
|
2017-06-23 10:46:10 -04:00
|
|
|
config ESP32_WIFI_TX_BA_WIN
|
|
|
|
int "WiFi AMPDU TX BA window size"
|
|
|
|
depends on ESP32_WIFI_AMPDU_ENABLED
|
|
|
|
range 2 32
|
|
|
|
default 6
|
|
|
|
help
|
|
|
|
Set the size of WiFi Block Ack TX window. Generally a bigger value means higher throughput but
|
|
|
|
more memory. Most of time we should NOT change the default value unless special reason, e.g.
|
|
|
|
test the maximum UDP TX throughput with iperf etc. For iperf test in shieldbox, the recommended
|
|
|
|
value is 9~12.
|
|
|
|
|
|
|
|
config ESP32_WIFI_RX_BA_WIN
|
|
|
|
int "WiFi AMPDU RX BA window size"
|
|
|
|
depends on ESP32_WIFI_AMPDU_ENABLED
|
|
|
|
range 2 32
|
|
|
|
default 6
|
|
|
|
help
|
|
|
|
Set the size of WiFi Block Ack RX window. Generally a bigger value means higher throughput but
|
|
|
|
more memory. Most of time we should NOT change the default value unless special reason, e.g.
|
|
|
|
test the maximum UDP RX throughput with iperf etc. For iperf test in shieldbox, the recommended
|
|
|
|
value is 9~12.
|
|
|
|
|
2017-02-21 01:52:25 -05:00
|
|
|
config ESP32_WIFI_NVS_ENABLED
|
|
|
|
bool "WiFi NVS flash"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Select this option to enable WiFi NVS flash
|
2017-01-18 07:05:26 -05:00
|
|
|
|
2017-08-22 00:55:23 -04:00
|
|
|
endmenu # Wi-Fi
|
2017-08-23 05:51:31 -04:00
|
|
|
|
|
|
|
menu Phy
|
2017-08-22 00:55:23 -04:00
|
|
|
|
2017-02-19 21:23:56 -05:00
|
|
|
config ESP32_PHY_CALIBRATION_AND_DATA_STORAGE
|
|
|
|
bool "Do phy calibration and store calibration data in NVS"
|
2017-02-16 09:06:02 -05:00
|
|
|
default y
|
|
|
|
help
|
2017-02-19 21:23:56 -05:00
|
|
|
If this option is enabled, NVS will be initialized and calibration data will be loaded from there.
|
|
|
|
PHY calibration will be skipped on deep sleep wakeup. If calibration data is not found, full calibration
|
|
|
|
will be performed and stored in NVS. In all other cases, only partial calibration will be performed.
|
2017-02-16 09:06:02 -05:00
|
|
|
|
|
|
|
If unsure, choose 'y'.
|
2017-01-18 07:05:26 -05:00
|
|
|
|
2016-11-15 05:36:18 -05:00
|
|
|
config ESP32_PHY_INIT_DATA_IN_PARTITION
|
2017-01-10 00:04:04 -05:00
|
|
|
bool "Use a partition to store PHY init data"
|
|
|
|
default n
|
|
|
|
help
|
|
|
|
If enabled, PHY init data will be loaded from a partition.
|
|
|
|
When using a custom partition table, make sure that PHY data
|
|
|
|
partition is included (type: 'data', subtype: 'phy').
|
|
|
|
With default partition tables, this is done automatically.
|
|
|
|
If PHY init data is stored in a partition, it has to be flashed there,
|
|
|
|
otherwise runtime error will occur.
|
|
|
|
|
|
|
|
If this option is not enabled, PHY init data will be embedded
|
|
|
|
into the application binary.
|
|
|
|
|
|
|
|
If unsure, choose 'n'.
|
2017-01-18 21:58:09 -05:00
|
|
|
|
|
|
|
config ESP32_PHY_MAX_WIFI_TX_POWER
|
2017-01-18 07:05:26 -05:00
|
|
|
int "Max WiFi TX power (dBm)"
|
2017-01-10 00:04:04 -05:00
|
|
|
range 0 20
|
|
|
|
default 20
|
|
|
|
help
|
2017-01-18 07:05:26 -05:00
|
|
|
Set maximum transmit power for WiFi radio. Actual transmit power for high
|
2017-01-10 00:04:04 -05:00
|
|
|
data rates may be lower than this setting.
|
2017-01-18 21:58:09 -05:00
|
|
|
|
|
|
|
config ESP32_PHY_MAX_TX_POWER
|
|
|
|
int
|
2017-08-08 00:53:52 -04:00
|
|
|
default ESP32_PHY_MAX_WIFI_TX_POWER
|
2017-01-18 21:58:09 -05:00
|
|
|
|
2017-08-22 00:55:23 -04:00
|
|
|
endmenu # PHY
|