OVMS3-idf/components/esp32/Kconfig
Wu Jian Gang 791daea835 Merge branch 'bugfix/xtal_freq_40' into 'master'
esp32: by default, set 40MHz crystal frequency

See merge request !1140
2017-08-24 20:40:22 +08:00

767 lines
28 KiB
Text

menu "ESP32-specific"
choice ESP32_DEFAULT_CPU_FREQ_MHZ
prompt "CPU frequency"
default ESP32_DEFAULT_CPU_FREQ_160
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
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
bool
default "n"
config MEMMAP_TRACEMEM_TWOBANKS
bool
default "n"
config ESP32_TRAX
bool "Use TRAX tracing feature"
default "n"
select MEMMAP_TRACEMEM
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.
config ESP32_TRAX_TWOBANKS
bool "Reserve memory for tracing both pro as well as app cpu execution"
default "n"
depends on ESP32_TRAX && MEMMAP_SMP
select MEMMAP_TRACEMEM_TWOBANKS
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.
# Memory to reverse for trace, used in linker script
config TRACEMEM_RESERVE_DRAM
hex
default 0x8000 if MEMMAP_TRACEMEM && MEMMAP_TRACEMEM_TWOBANKS
default 0x4000 if MEMMAP_TRACEMEM && !MEMMAP_TRACEMEM_TWOBANKS
default 0x0
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"
select ESP32_ENABLE_COREDUMP
config ESP32_ENABLE_COREDUMP_TO_UART
bool "UART"
select ESP32_ENABLE_COREDUMP
config ESP32_ENABLE_COREDUMP_TO_NONE
bool "None"
endchoice
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).
# Not implemented and/or needs new silicon rev to work
config MEMMAP_SPISRAM
bool "Use external SPI SRAM chip as main memory"
depends on ESP32_NEEDS_NEW_SILICON_REV
default "n"
help
The ESP32 can control an external SPI SRAM chip, adding the memory it contains to the
main memory map. Enable this if you have this hardware and want to use it in the same
way as on-chip RAM.
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
bool "Two"
config FOUR_UNIVERSAL_MAC_ADDRESS
bool "Four"
endchoice
config NUMBER_OF_UNIVERSAL_MAC_ADDRESS
int
default 2 if TWO_UNIVERSAL_MAC_ADDRESS
default 4 if FOUR_UNIVERSAL_MAC_ADDRESS
config SYSTEM_EVENT_QUEUE_SIZE
int "System event queue size"
default 32
help
Config system event queue size in different application.
config SYSTEM_EVENT_TASK_STACK_SIZE
int "Event loop task stack size"
default 4096
help
Config system event task stack size in different application.
config MAIN_TASK_STACK_SIZE
int "Main task stack size"
default 4096
help
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.
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.
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
LF: no modification is applied, input is sent to stdin as is
CR: each occurence of CR is replaced with LF
This option doesn't affect behavior of the UART driver (drivers/uart.h).
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
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
features, such as positional arguments.
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.
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).
- 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
prompt "UART peripheral to use for console output (0-1)"
depends on CONSOLE_UART_CUSTOM
default CONSOLE_UART_CUSTOM_NUM_0
help
Due of a ROM bug, UART2 is not supported for console output
via ets_printf.
config CONSOLE_UART_CUSTOM_NUM_0
bool "UART0"
config CONSOLE_UART_CUSTOM_NUM_1
bool "UART1"
endchoice
config CONSOLE_UART_NUM
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
config CONSOLE_UART_TX_GPIO
int "UART TX on GPIO#"
depends on CONSOLE_UART_CUSTOM
range 0 33
default 19
config CONSOLE_UART_RX_GPIO
int "UART RX on GPIO#"
depends on CONSOLE_UART_CUSTOM
range 0 39
default 21
config CONSOLE_UART_BAUDRATE
int "UART console baud rate"
depends on !CONSOLE_UART_NONE
default 115200
range 1200 4000000
config ULP_COPROC_ENABLED
bool "Enable Ultra Low Power (ULP) Coprocessor"
default "n"
help
Set to 'y' if you plan to load a firmware for the coprocessor.
If this option is enabled, further coprocessor configuration will appear in the Components menu.
config ULP_COPROC_RESERVE_MEM
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
help
Bytes of memory to reserve for ULP coprocessor firmware & data.
Data is reserved at the beginning of RTC slow memory.
choice ESP32_PANIC
prompt "Panic handler behaviour"
default ESP32_PANIC_PRINT_REBOOT
help
If FreeRTOS detects unexpected behaviour or an unhandled exception, the panic handler is
invoked. Configure the panic handlers action here.
config ESP32_PANIC_PRINT_HALT
bool "Print registers and halt"
help
Outputs the relevant registers over the serial port and halt the
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.
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
default 300
range 10 10000
help
The timeout of the watchdog, in miliseconds. Make this higher than the FreeRTOS tick rate.
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.
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
bool "Task watchdog watches CPU0 idle task"
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
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
watchdog will trigger if no tasks register themselves within the timeout value.
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.
#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.
config BROWNOUT_DET
bool "Hardware brownout detect & reset"
default y
help
The ESP32 has a built-in brownout detector which can detect if the voltage is lower than
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.
#The voltage levels here are estimates, more work needs to be done to figure out the exact voltages
#of the brownout threshold levels.
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
choice ESP32_TIME_SYSCALL
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.
- When RTC is used for timekeeping, two RTC_STORE registers are
used to keep time in deep sleep mode.
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
choice ESP32_RTC_CLOCK_SOURCE
prompt "RTC clock source"
default ESP32_RTC_CLOCK_SOURCE_INTERNAL_RC
help
Choose which clock is used as RTC clock source.
config ESP32_RTC_CLOCK_SOURCE_INTERNAL_RC
bool "Internal 150kHz RC oscillator"
config ESP32_RTC_CLOCK_SOURCE_EXTERNAL_CRYSTAL
bool "External 32kHz crystal"
endchoice
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:
- 150000 Hz if internal RC oscillator is used as clock source
- 32768 Hz if the 32k crystal oscillator is used
config ESP32_DEEP_SLEEP_WAKEUP_DELAY
int "Extra delay in deep sleep wake stub (in us)"
default 2000
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,
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.
If you are seeing "flash read err, 1000" message printed to the
console after deep sleep reset, try increasing this value.
choice ESP32_XTAL_FREQ_SEL
prompt "Main XTAL frequency"
default ESP32_XTAL_FREQ_40
help
ESP32 currently supports the following XTAL frequencies:
- 26 MHz
- 40 MHz
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
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.
endmenu
menu Wi-Fi
config SW_COEXIST_ENABLE
bool "Software controls WiFi/Bluetooth coexistence"
depends on BT_ENABLED
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.
config ESP32_WIFI_STATIC_RX_BUFFER_NUM
int "Max number of WiFi static RX buffers"
range 2 25
default 10
help
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"
range 0 128
default 32
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.
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.
config ESP32_WIFI_DYNAMIC_TX_BUFFER_NUM
int "Max number of WiFi dynamic TX buffers"
depends on ESP32_WIFI_DYNAMIC_TX_BUFFER
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
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.
config ESP32_WIFI_NVS_ENABLED
bool "WiFi NVS flash"
default y
help
Select this option to enable WiFi NVS flash
endmenu
menu Phy
config ESP32_PHY_CALIBRATION_AND_DATA_STORAGE
bool "Do phy calibration and store calibration data in NVS"
default y
help
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.
If unsure, choose 'y'.
config ESP32_PHY_INIT_DATA_IN_PARTITION
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'.
config ESP32_PHY_MAX_WIFI_TX_POWER
int "Max WiFi TX power (dBm)"
range 0 20
default 20
help
Set maximum transmit power for WiFi radio. Actual transmit power for high
data rates may be lower than this setting.
config ESP32_PHY_MAX_TX_POWER
int
default ESP32_PHY_MAX_WIFI_TX_POWER
endmenu