|
|
@@ -1,1354 +1,1365 @@
|
|
|
menu "ESP32-specific"
|
|
|
|
|
|
-# Hidden option to support checking for this specific target in C code and Kconfig files
|
|
|
-config IDF_TARGET_ESP32
|
|
|
- bool
|
|
|
- default "y" if IDF_TARGET="esp32"
|
|
|
- default "n"
|
|
|
-
|
|
|
-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 SPIRAM_SUPPORT
|
|
|
- bool "Support for external, SPI-connected RAM"
|
|
|
- default "n"
|
|
|
- help
|
|
|
- This enables support for an external SPI RAM chip, connected in parallel with the
|
|
|
- main SPI flash chip.
|
|
|
-
|
|
|
-menu "SPI RAM config"
|
|
|
- depends on SPIRAM_SUPPORT
|
|
|
-
|
|
|
-config SPIRAM_BOOT_INIT
|
|
|
- bool "Initialize SPI RAM when booting the ESP32"
|
|
|
- default "y"
|
|
|
- help
|
|
|
- If this is enabled, the SPI RAM will be enabled during initial boot. Unless you
|
|
|
- have specific requirements, you'll want to leave this enabled so memory allocated
|
|
|
- during boot-up can also be placed in SPI RAM.
|
|
|
-
|
|
|
-config SPIRAM_IGNORE_NOTFOUND
|
|
|
- bool "Ignore PSRAM when not found"
|
|
|
- default "n"
|
|
|
- depends on SPIRAM_BOOT_INIT && !SPIRAM_ALLOW_BSS_SEG_EXTERNAL_MEMORY
|
|
|
- help
|
|
|
- Normally, if psram initialization is enabled during compile time but not found at runtime, it
|
|
|
- is seen as an error making the ESP32 panic. If this is enabled, the ESP32 will keep on
|
|
|
- running but will not add the (non-existing) RAM to any allocator.
|
|
|
-
|
|
|
-choice SPIRAM_USE
|
|
|
- prompt "SPI RAM access method"
|
|
|
- default SPIRAM_USE_MALLOC
|
|
|
- help
|
|
|
- The SPI RAM can be accessed in multiple methods: by just having it available as an unmanaged
|
|
|
- memory region in the ESP32 memory map, by integrating it in the ESP32s heap as 'special' memory
|
|
|
- needing heap_caps_malloc to allocate, or by fully integrating it making malloc() also able to
|
|
|
- return SPI RAM pointers.
|
|
|
-
|
|
|
-config SPIRAM_USE_MEMMAP
|
|
|
- bool "Integrate RAM into ESP32 memory map"
|
|
|
-config SPIRAM_USE_CAPS_ALLOC
|
|
|
- bool "Make RAM allocatable using heap_caps_malloc(..., MALLOC_CAP_SPIRAM)"
|
|
|
-config SPIRAM_USE_MALLOC
|
|
|
- bool "Make RAM allocatable using malloc() as well"
|
|
|
- select SUPPORT_STATIC_ALLOCATION
|
|
|
-endchoice
|
|
|
-
|
|
|
-choice SPIRAM_TYPE
|
|
|
- prompt "Type of SPI RAM chip in use"
|
|
|
- default SPIRAM_TYPE_AUTO
|
|
|
-
|
|
|
-config SPIRAM_TYPE_AUTO
|
|
|
- bool "Auto-detect"
|
|
|
-
|
|
|
-config SPIRAM_TYPE_ESPPSRAM32
|
|
|
- bool "ESP-PSRAM32 or IS25WP032"
|
|
|
-
|
|
|
-config SPIRAM_TYPE_ESPPSRAM64
|
|
|
- bool "ESP-PSRAM64 or LY68L6400"
|
|
|
-
|
|
|
-endchoice
|
|
|
-
|
|
|
-config SPIRAM_SIZE
|
|
|
- int
|
|
|
- default -1 if SPIRAM_TYPE_AUTO
|
|
|
- default 4194304 if SPIRAM_TYPE_ESPPSRAM32
|
|
|
- default 8388608 if SPIRAM_TYPE_ESPPSRAM64
|
|
|
- default 0
|
|
|
-
|
|
|
-choice SPIRAM_SPEED
|
|
|
- prompt "Set RAM clock speed"
|
|
|
- default SPIRAM_CACHE_SPEED_40M
|
|
|
- help
|
|
|
- Select the speed for the SPI RAM chip.
|
|
|
- If SPI RAM is enabled, we only support three combinations of SPI speed mode we supported now:
|
|
|
-
|
|
|
- 1. Flash SPI running at 40Mhz and RAM SPI running at 40Mhz
|
|
|
- 2. Flash SPI running at 80Mhz and RAM SPI running at 40Mhz
|
|
|
- 3. Flash SPI running at 80Mhz and RAM SPI running at 80Mhz
|
|
|
-
|
|
|
- Note: If the third mode(80Mhz+80Mhz) is enabled for SPI RAM of type 32MBit, one of the HSPI/VSPI host will
|
|
|
- be occupied by the system. Which SPI host to use can be selected by the config item SPIRAM_OCCUPY_SPI_HOST.
|
|
|
- Application code should never touch HSPI/VSPI hardware in this case. The option to select
|
|
|
- 80MHz will only be visible if the flash SPI speed is also 80MHz. (ESPTOOLPY_FLASHFREQ_80M is true)
|
|
|
-
|
|
|
-config SPIRAM_SPEED_40M
|
|
|
- bool "40MHz clock speed"
|
|
|
-config SPIRAM_SPEED_80M
|
|
|
- depends on ESPTOOLPY_FLASHFREQ_80M
|
|
|
- bool "80MHz clock speed"
|
|
|
-endchoice
|
|
|
-
|
|
|
-config SPIRAM_MEMTEST
|
|
|
- bool "Run memory test on SPI RAM initialization"
|
|
|
- default "y"
|
|
|
- depends on SPIRAM_BOOT_INIT
|
|
|
- help
|
|
|
- Runs a rudimentary memory test on initialization. Aborts when memory test fails. Disable this for
|
|
|
- slightly faster startop.
|
|
|
-
|
|
|
-config SPIRAM_CACHE_WORKAROUND
|
|
|
- bool "Enable workaround for bug in SPI RAM cache for Rev1 ESP32s"
|
|
|
- depends on SPIRAM_USE_MEMMAP || SPIRAM_USE_CAPS_ALLOC || SPIRAM_USE_MALLOC
|
|
|
- default "y"
|
|
|
- help
|
|
|
- Revision 1 of the ESP32 has a bug that can cause a write to PSRAM not to take place in some situations
|
|
|
- when the cache line needs to be fetched from external RAM and an interrupt occurs. This enables a
|
|
|
- fix in the compiler that makes sure the specific code that is vulnerable to this will not be emitted.
|
|
|
-
|
|
|
- This will also not use any bits of newlib that are located in ROM, opting for a version that is compiled
|
|
|
- with the workaround and located in flash instead.
|
|
|
-
|
|
|
-config SPIRAM_BANKSWITCH_ENABLE
|
|
|
- bool "Enable bank switching for >4MiB external RAM"
|
|
|
- default y
|
|
|
- depends on SPIRAM_USE_MEMMAP || SPIRAM_USE_CAPS_ALLOC || SPIRAM_USE_MALLOC
|
|
|
- help
|
|
|
- The ESP32 only supports 4MiB of external RAM in its address space. The hardware does support larger
|
|
|
- memories, but these have to be bank-switched in and out of this address space. Enabling this allows you
|
|
|
- to reserve some MMU pages for this, which allows the use of the esp_himem api to manage these banks.
|
|
|
-
|
|
|
-#Note that this is limited to 62 banks, as esp_spiram_writeback_cache needs some kind of mapping of some banks
|
|
|
-#below that mark to work. We cannot at this moment guarantee this to exist when himem is enabled.
|
|
|
-config SPIRAM_BANKSWITCH_RESERVE
|
|
|
- int "Amount of 32K pages to reserve for bank switching"
|
|
|
- depends on SPIRAM_BANKSWITCH_ENABLE
|
|
|
- default 8
|
|
|
- range 1 62
|
|
|
- help
|
|
|
- Select the amount of banks reserved for bank switching. Note that the amount of RAM allocatable with
|
|
|
- malloc/esp_heap_alloc_caps will decrease by 32K for each page reserved here.
|
|
|
-
|
|
|
- Note that this reservation is only actually done if your program actually uses the himem API. Without
|
|
|
- any himem calls, the reservation is not done and the original amount of memory will be available
|
|
|
- to malloc/esp_heap_alloc_caps.
|
|
|
-
|
|
|
-config SPIRAM_MALLOC_ALWAYSINTERNAL
|
|
|
- int "Maximum malloc() size, in bytes, to always put in internal memory"
|
|
|
- depends on SPIRAM_USE_MALLOC
|
|
|
- default 16384
|
|
|
- range 0 131072
|
|
|
- help
|
|
|
- If malloc() is capable of also allocating SPI-connected ram, its allocation strategy will prefer to allocate chunks less
|
|
|
- than this size in internal memory, while allocations larger than this will be done from external RAM.
|
|
|
- If allocation from the preferred region fails, an attempt is made to allocate from the non-preferred
|
|
|
- region instead, so malloc() will not suddenly fail when either internal or external memory is full.
|
|
|
-
|
|
|
-config WIFI_LWIP_ALLOCATION_FROM_SPIRAM_FIRST
|
|
|
- bool "Try to allocate memories of WiFi and LWIP in SPIRAM firstly. If failed, allocate internal memory"
|
|
|
- depends on SPIRAM_USE_CAPS_ALLOC || SPIRAM_USE_MALLOC
|
|
|
- default "n"
|
|
|
- help
|
|
|
- Try to allocate memories of WiFi and LWIP in SPIRAM firstly. If failed, try to allocate internal memory then.
|
|
|
-
|
|
|
-config SPIRAM_MALLOC_RESERVE_INTERNAL
|
|
|
- int "Reserve this amount of bytes for data that specifically needs to be in DMA or internal memory"
|
|
|
- depends on SPIRAM_USE_MALLOC
|
|
|
- default 32768
|
|
|
- range 0 262144
|
|
|
- help
|
|
|
- Because the external/internal RAM allocation strategy is not always perfect, it sometimes may happen
|
|
|
- that the internal memory is entirely filled up. This causes allocations that are specifically done in
|
|
|
- internal memory, for example the stack for new tasks or memory to service DMA or have memory that's
|
|
|
- also available when SPI cache is down, to fail. This option reserves a pool specifically for requests
|
|
|
- like that; the memory in this pool is not given out when a normal malloc() is called.
|
|
|
-
|
|
|
- Set this to 0 to disable this feature.
|
|
|
-
|
|
|
- Note that because FreeRTOS stacks are forced to internal memory, they will also use this memory pool;
|
|
|
- be sure to keep this in mind when adjusting this value.
|
|
|
-
|
|
|
- Note also that the DMA reserved pool may not be one single contiguous memory region, depending on the
|
|
|
- configured size and the static memory usage of the app.
|
|
|
-
|
|
|
-
|
|
|
-config SPIRAM_ALLOW_STACK_EXTERNAL_MEMORY
|
|
|
- bool "Allow external memory as an argument to xTaskCreateStatic"
|
|
|
- default n
|
|
|
- depends on SPIRAM_USE_MALLOC
|
|
|
- help
|
|
|
- Because some bits of the ESP32 code environment cannot be recompiled with the cache workaround, normally
|
|
|
- tasks cannot be safely run with their stack residing in external memory; for this reason xTaskCreate and
|
|
|
- friends always allocate stack in internal memory and xTaskCreateStatic will check if the memory passed
|
|
|
- to it is in internal memory. If you have a task that needs a large amount of stack and does not call on
|
|
|
- ROM code in any way (no direct calls, but also no Bluetooth/WiFi), you can try to disable this and use
|
|
|
- xTaskCreateStatic to create the tasks stack in external memory.
|
|
|
-
|
|
|
-config SPIRAM_ALLOW_BSS_SEG_EXTERNAL_MEMORY
|
|
|
- bool "Allow .bss segment placed in external memory"
|
|
|
- default n
|
|
|
- depends on SPIRAM_SUPPORT
|
|
|
- help
|
|
|
- If enabled the option,and add EXT_RAM_ATTR defined your variable,then your variable will be placed
|
|
|
- in PSRAM instead of internal memory, and placed most of variables of lwip,net802.11,pp,bluedroid library
|
|
|
- to external memory defaultly.
|
|
|
-
|
|
|
-choice SPIRAM_OCCUPY_SPI_HOST
|
|
|
- prompt "SPI host to use for 32MBit PSRAM"
|
|
|
- default SPIRAM_OCCUPY_VSPI_HOST
|
|
|
- depends on SPIRAM_SPEED_80M
|
|
|
- help
|
|
|
- When both flash and PSRAM is working under 80MHz, and the PSRAM is of type 32MBit, one of the HSPI/VSPI
|
|
|
- host will be used to output the clock. Select which one to use here.
|
|
|
-
|
|
|
-config SPIRAM_OCCUPY_HSPI_HOST
|
|
|
- bool "HSPI host (SPI2)"
|
|
|
-config SPIRAM_OCCUPY_VSPI_HOST
|
|
|
- bool "VSPI host (SPI3)"
|
|
|
-endchoice
|
|
|
-
|
|
|
-config PICO_PSRAM_CS_IO
|
|
|
- int "PSRAM CS IO for ESP32-PICO chip"
|
|
|
- depends on SPIRAM_SUPPORT
|
|
|
- range 0 33
|
|
|
- default 10
|
|
|
- help
|
|
|
- When ESP32-PICO chip connect a external psram, the clock IO and data IO is fixed, but the CS IO can be
|
|
|
- any unused GPIO, user can config it based on hardware design.
|
|
|
-
|
|
|
-endmenu
|
|
|
-
|
|
|
-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 && !FREERTOS_UNICORE
|
|
|
- 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
|
|
|
-
|
|
|
-menu "Core dump"
|
|
|
-
|
|
|
-choice ESP32_COREDUMP_TO_FLASH_OR_UART
|
|
|
- prompt "Data 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_MAX_TASKS_NUM
|
|
|
- int "Maximum number of tasks"
|
|
|
- depends on ESP32_ENABLE_COREDUMP
|
|
|
- default 64
|
|
|
- help
|
|
|
- Maximum number of tasks snapshots in core dump.
|
|
|
-
|
|
|
-config ESP32_CORE_DUMP_UART_DELAY
|
|
|
- int "Delay before print to UART"
|
|
|
- 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.
|
|
|
-
|
|
|
-endmenu
|
|
|
-
|
|
|
-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 2304
|
|
|
- help
|
|
|
- Config system event task stack size in different application.
|
|
|
-
|
|
|
-config MAIN_TASK_STACK_SIZE
|
|
|
- int "Main task stack size"
|
|
|
- default 3584
|
|
|
- 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.
|
|
|
-
|
|
|
-config TIMER_TASK_STACK_SIZE
|
|
|
- int "High-resolution timer task stack size"
|
|
|
- default 3584
|
|
|
- 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.
|
|
|
-
|
|
|
-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 ESP32_DEBUG_STUBS_ENABLE
|
|
|
- bool "OpenOCD debug stubs"
|
|
|
- default OPTIMIZATION_LEVEL_DEBUG
|
|
|
- depends on !ESP32_TRAX
|
|
|
- help
|
|
|
- Debug stubs are used by OpenOCD to execute pre-compiled onboard code which does some useful debugging,
|
|
|
- e.g. GCOV data dump.
|
|
|
-
|
|
|
-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 if !SPIRAM_SUPPORT
|
|
|
- default 800 if SPIRAM_SUPPORT
|
|
|
- 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 "Initialize Task Watchdog Timer on startup"
|
|
|
- default y
|
|
|
- help
|
|
|
- The Task Watchdog Timer can be used to make sure individual tasks are still
|
|
|
- running. Enabling this option will cause the Task Watchdog Timer to be
|
|
|
- initialized automatically at startup. The Task Watchdog timer can be
|
|
|
- initialized after startup as well (see Task Watchdog Timer API Reference)
|
|
|
-
|
|
|
-config TASK_WDT_PANIC
|
|
|
- bool "Invoke panic handler on Task Watchdog timeout"
|
|
|
- depends on TASK_WDT
|
|
|
- default n
|
|
|
- help
|
|
|
- If this option is enabled, the Task Watchdog Timer will be configured to
|
|
|
- trigger the panic handler when it times out. This can also be configured
|
|
|
- at run time (see Task Watchdog Timer API Reference)
|
|
|
-
|
|
|
-config TASK_WDT_TIMEOUT_S
|
|
|
- int "Task Watchdog timeout period (seconds)"
|
|
|
- depends on TASK_WDT
|
|
|
- range 1 60
|
|
|
- default 5
|
|
|
- help
|
|
|
- Timeout period configuration for the Task Watchdog Timer in seconds.
|
|
|
- This is also configurable at run time (see Task Watchdog Timer API Reference)
|
|
|
-
|
|
|
-config TASK_WDT_CHECK_IDLE_TASK_CPU0
|
|
|
- bool "Watch CPU0 Idle Task"
|
|
|
- depends on TASK_WDT
|
|
|
- default y
|
|
|
- help
|
|
|
- If this option is enabled, the Task Watchdog Timer will watch the CPU0
|
|
|
- Idle Task. Having the Task Watchdog watch the Idle Task allows for detection
|
|
|
- of CPU starvation as the Idle Task not being called is usually a symptom of
|
|
|
- CPU starvation. Starvation of the Idle Task is detrimental as FreeRTOS household
|
|
|
- tasks depend on the Idle Task getting some runtime every now and then.
|
|
|
-
|
|
|
-config TASK_WDT_CHECK_IDLE_TASK_CPU1
|
|
|
- bool "Watch CPU1 Idle Task"
|
|
|
- depends on TASK_WDT && !FREERTOS_UNICORE
|
|
|
- default y
|
|
|
- help
|
|
|
- If this option is enabled, the Task Wtachdog Timer will wach the CPU1
|
|
|
- Idle Task.
|
|
|
-
|
|
|
-#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 approximately
|
|
|
- below this level. Note that there may be some variation of brownout voltage level
|
|
|
- between each ESP32 chip.
|
|
|
-
|
|
|
-#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.43V +/- 0.05"
|
|
|
-config BROWNOUT_DET_LVL_SEL_1
|
|
|
- bool "2.48V +/- 0.05"
|
|
|
-config BROWNOUT_DET_LVL_SEL_2
|
|
|
- bool "2.58V +/- 0.05"
|
|
|
-config BROWNOUT_DET_LVL_SEL_3
|
|
|
- bool "2.62V +/- 0.05"
|
|
|
-config BROWNOUT_DET_LVL_SEL_4
|
|
|
- bool "2.67V +/- 0.05"
|
|
|
-config BROWNOUT_DET_LVL_SEL_5
|
|
|
- bool "2.70V +/- 0.05"
|
|
|
-config BROWNOUT_DET_LVL_SEL_6
|
|
|
- bool "2.77V +/- 0.05"
|
|
|
-config BROWNOUT_DET_LVL_SEL_7
|
|
|
- bool "2.80V +/- 0.05"
|
|
|
-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
|
|
|
-
|
|
|
-
|
|
|
-#Reduce PHY TX power when brownout reset
|
|
|
-config REDUCE_PHY_TX_POWER
|
|
|
- bool "Reduce PHY TX power when brownout reset"
|
|
|
- depends on BROWNOUT_DET
|
|
|
- default y
|
|
|
- help
|
|
|
- When brownout reset occurs, reduce PHY TX power to keep the code running
|
|
|
-
|
|
|
-# Note about the use of "FRC1" name: currently FRC1 timer is not used for
|
|
|
-# high resolution timekeeping anymore. Instead the esp_timer API, implemented
|
|
|
-# using FRC2 timer, is used.
|
|
|
-# FRC1 name in the option name is kept for compatibility.
|
|
|
-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 both high-resolution and RTC timers are used, timekeeping will
|
|
|
- continue in deep sleep. Time will be reported at 1 microsecond
|
|
|
- resolution. This is the default, and the recommended option.
|
|
|
- - If only high-resolution timer is used, gettimeofday will
|
|
|
- provide time at microsecond resolution.
|
|
|
- Time will not be preserved when going into deep sleep mode.
|
|
|
- - 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_FRC1
|
|
|
- bool "RTC and high-resolution timer"
|
|
|
-config ESP32_TIME_SYSCALL_USE_RTC
|
|
|
- bool "RTC"
|
|
|
-config ESP32_TIME_SYSCALL_USE_FRC1
|
|
|
- bool "High-resolution timer"
|
|
|
-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.
|
|
|
-
|
|
|
- - "Internal 150kHz oscillator" option provides lowest deep sleep current
|
|
|
- consumption, and does not require extra external components. However
|
|
|
- frequency stability with respect to temperature is poor, so time may
|
|
|
- drift in deep/light sleep modes.
|
|
|
- - "External 32kHz crystal" provides better frequency stability, at the
|
|
|
- expense of slightly higher (1uA) deep sleep current consumption.
|
|
|
- - "External 32kHz oscillator" allows using 32kHz clock generated by an
|
|
|
- external circuit. In this case, external clock signal must be connected
|
|
|
- to 32K_XP pin. Amplitude should be <1.2V in case of sine wave signal,
|
|
|
- and <1V in case of square wave signal. Common mode voltage should be
|
|
|
- 0.1 < Vcm < 0.5Vamp, where Vamp is the signal amplitude.
|
|
|
- Additionally, 1nF capacitor must be connected between 32K_XN pin and
|
|
|
- ground. 32K_XN pin can not be used as a GPIO in this case.
|
|
|
- - "Internal 8.5MHz oscillator divided by 256" option results in higher
|
|
|
- deep sleep current (by 5uA) but has better frequency stability than
|
|
|
- the internal 150kHz oscillator. It does not require external components.
|
|
|
-
|
|
|
-config ESP32_RTC_CLOCK_SOURCE_INTERNAL_RC
|
|
|
- bool "Internal 150kHz RC oscillator"
|
|
|
-config ESP32_RTC_CLOCK_SOURCE_EXTERNAL_CRYSTAL
|
|
|
- bool "External 32kHz crystal"
|
|
|
-config ESP32_RTC_CLOCK_SOURCE_EXTERNAL_OSC
|
|
|
- bool "External 32kHz oscillator at 32K_XP pin"
|
|
|
-config ESP32_RTC_CLOCK_SOURCE_INTERNAL_8MD256
|
|
|
- bool "Internal 8.5MHz oscillator, divided by 256 (~33kHz)"
|
|
|
-endchoice
|
|
|
-
|
|
|
-config ESP32_RTC_CLK_CAL_CYCLES
|
|
|
- int "Number of cycles for RTC_SLOW_CLK calibration"
|
|
|
- default 3000 if ESP32_RTC_CLOCK_SOURCE_EXTERNAL_CRYSTAL
|
|
|
- default 1024 if ESP32_RTC_CLOCK_SOURCE_INTERNAL_RC
|
|
|
- range 0 27000 if ESP32_RTC_CLOCK_SOURCE_EXTERNAL_CRYSTAL || ESP32_RTC_CLOCK_SOURCE_EXTERNAL_OSC || ESP32_RTC_CLOCK_SOURCE_INTERNAL_8MD256
|
|
|
- range 0 32766 if ESP32_RTC_CLOCK_SOURCE_INTERNAL_RC
|
|
|
- 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. For this use value 1024.
|
|
|
- - 32768 Hz if the 32k crystal oscillator is used. For this use value 3000 or more.
|
|
|
- In case more value will help improve the definition of the launch of the crystal.
|
|
|
- If the crystal could not start, it will be switched to internal RC.
|
|
|
-
|
|
|
-config ESP32_RTC_XTAL_BOOTSTRAP_CYCLES
|
|
|
- int "Bootstrap cycles for external 32kHz crystal"
|
|
|
- depends on ESP32_RTC_CLOCK_SOURCE_EXTERNAL_CRYSTAL
|
|
|
- default 5
|
|
|
- range 0 32768
|
|
|
- help
|
|
|
- To reduce the startup time of an external RTC crystal,
|
|
|
- we bootstrap it with a 32kHz square wave for a fixed number of cycles.
|
|
|
- Setting 0 will disable bootstrapping (if disabled, the crystal may take
|
|
|
- longer to start up or fail to oscillate under some conditions).
|
|
|
-
|
|
|
- If this value is too high, a faulty crystal may initially start and then fail.
|
|
|
- If this value is too low, an otherwise good crystal may not start.
|
|
|
-
|
|
|
- To accurately determine if the crystal has started,
|
|
|
- set a larger "Number of cycles for RTC_SLOW_CLK calibration" (about 3000).
|
|
|
-
|
|
|
-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 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.)
|
|
|
-
|
|
|
-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.
|
|
|
-
|
|
|
-config ESP_TIMER_PROFILING
|
|
|
- bool "Enable esp_timer profiling features"
|
|
|
- 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.
|
|
|
-
|
|
|
-config COMPATIBLE_PRE_V2_1_BOOTLOADERS
|
|
|
- bool "App compatible with bootloaders before IDF v2.1"
|
|
|
- default n
|
|
|
- help
|
|
|
- Bootloaders before IDF v2.1 did less initialisation of the
|
|
|
- system clock. This setting needs to be enabled to build an app
|
|
|
- which can be booted by these older bootloaders.
|
|
|
-
|
|
|
- If this setting is enabled, the app can be booted by any bootloader
|
|
|
- from IDF v1.0 up to the current version.
|
|
|
-
|
|
|
- If this setting is disabled, the app can only be booted by bootloaders
|
|
|
- from IDF v2.1 or newer.
|
|
|
-
|
|
|
- Enabling this setting adds approximately 1KB to the app's IRAM usage.
|
|
|
-
|
|
|
-config ESP_ERR_TO_NAME_LOOKUP
|
|
|
- bool "Enable lookup of error code strings"
|
|
|
- default "y"
|
|
|
- help
|
|
|
- Functions esp_err_to_name() and esp_err_to_name_r() return string
|
|
|
- representations of error codes from a pre-generated lookup table.
|
|
|
- This option can be used to turn off the use of the look-up table in
|
|
|
- order to save memory but this comes at the price of sacrificing
|
|
|
- distinguishable (meaningful) output string representations.
|
|
|
-
|
|
|
-config ESP32_RTCDATA_IN_FAST_MEM
|
|
|
- bool "Place RTC_DATA_ATTR and RTC_RODATA_ATTR variables into RTC fast memory segment"
|
|
|
- default n
|
|
|
- depends on FREERTOS_UNICORE
|
|
|
- help
|
|
|
- This option allows to place .rtc_data and .rtc_rodata sections into
|
|
|
- RTC fast memory segment to free the slow memory region for ULP programs.
|
|
|
- This option depends on the CONFIG_FREERTOS_UNICORE option because RTC fast memory
|
|
|
- can be accessed only by PRO_CPU core.
|
|
|
+ # Hidden option to support checking for this specific target in C code and Kconfig files
|
|
|
+ config IDF_TARGET_ESP32
|
|
|
+ bool
|
|
|
+ default "y" if IDF_TARGET="esp32"
|
|
|
+ default "n"
|
|
|
+
|
|
|
+ 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 SPIRAM_SUPPORT
|
|
|
+ bool "Support for external, SPI-connected RAM"
|
|
|
+ default "n"
|
|
|
+ help
|
|
|
+ This enables support for an external SPI RAM chip, connected in parallel with the
|
|
|
+ main SPI flash chip.
|
|
|
+
|
|
|
+ menu "SPI RAM config"
|
|
|
+ depends on SPIRAM_SUPPORT
|
|
|
+
|
|
|
+ config SPIRAM_BOOT_INIT
|
|
|
+ bool "Initialize SPI RAM when booting the ESP32"
|
|
|
+ default "y"
|
|
|
+ help
|
|
|
+ If this is enabled, the SPI RAM will be enabled during initial boot. Unless you
|
|
|
+ have specific requirements, you'll want to leave this enabled so memory allocated
|
|
|
+ during boot-up can also be placed in SPI RAM.
|
|
|
+
|
|
|
+ config SPIRAM_IGNORE_NOTFOUND
|
|
|
+ bool "Ignore PSRAM when not found"
|
|
|
+ default "n"
|
|
|
+ depends on SPIRAM_BOOT_INIT && !SPIRAM_ALLOW_BSS_SEG_EXTERNAL_MEMORY
|
|
|
+ help
|
|
|
+ Normally, if psram initialization is enabled during compile time but not found at runtime, it
|
|
|
+ is seen as an error making the ESP32 panic. If this is enabled, the ESP32 will keep on
|
|
|
+ running but will not add the (non-existing) RAM to any allocator.
|
|
|
+
|
|
|
+ choice SPIRAM_USE
|
|
|
+ prompt "SPI RAM access method"
|
|
|
+ default SPIRAM_USE_MALLOC
|
|
|
+ help
|
|
|
+ The SPI RAM can be accessed in multiple methods: by just having it available as an unmanaged
|
|
|
+ memory region in the ESP32 memory map, by integrating it in the ESP32s heap as 'special' memory
|
|
|
+ needing heap_caps_malloc to allocate, or by fully integrating it making malloc() also able to
|
|
|
+ return SPI RAM pointers.
|
|
|
+
|
|
|
+ config SPIRAM_USE_MEMMAP
|
|
|
+ bool "Integrate RAM into ESP32 memory map"
|
|
|
+ config SPIRAM_USE_CAPS_ALLOC
|
|
|
+ bool "Make RAM allocatable using heap_caps_malloc(..., MALLOC_CAP_SPIRAM)"
|
|
|
+ config SPIRAM_USE_MALLOC
|
|
|
+ bool "Make RAM allocatable using malloc() as well"
|
|
|
+ select SUPPORT_STATIC_ALLOCATION
|
|
|
+ endchoice
|
|
|
+
|
|
|
+ choice SPIRAM_TYPE
|
|
|
+ prompt "Type of SPI RAM chip in use"
|
|
|
+ default SPIRAM_TYPE_AUTO
|
|
|
+
|
|
|
+ config SPIRAM_TYPE_AUTO
|
|
|
+ bool "Auto-detect"
|
|
|
+
|
|
|
+ config SPIRAM_TYPE_ESPPSRAM32
|
|
|
+ bool "ESP-PSRAM32 or IS25WP032"
|
|
|
+
|
|
|
+ config SPIRAM_TYPE_ESPPSRAM64
|
|
|
+ bool "ESP-PSRAM64 or LY68L6400"
|
|
|
+
|
|
|
+ endchoice
|
|
|
+
|
|
|
+ config SPIRAM_SIZE
|
|
|
+ int
|
|
|
+ default -1 if SPIRAM_TYPE_AUTO
|
|
|
+ default 4194304 if SPIRAM_TYPE_ESPPSRAM32
|
|
|
+ default 8388608 if SPIRAM_TYPE_ESPPSRAM64
|
|
|
+ default 0
|
|
|
+
|
|
|
+ choice SPIRAM_SPEED
|
|
|
+ prompt "Set RAM clock speed"
|
|
|
+ default SPIRAM_CACHE_SPEED_40M
|
|
|
+ help
|
|
|
+ Select the speed for the SPI RAM chip.
|
|
|
+ If SPI RAM is enabled, we only support three combinations of SPI speed mode we supported now:
|
|
|
+
|
|
|
+ 1. Flash SPI running at 40Mhz and RAM SPI running at 40Mhz
|
|
|
+ 2. Flash SPI running at 80Mhz and RAM SPI running at 40Mhz
|
|
|
+ 3. Flash SPI running at 80Mhz and RAM SPI running at 80Mhz
|
|
|
+
|
|
|
+ Note: If the third mode(80Mhz+80Mhz) is enabled for SPI RAM of type 32MBit, one of the HSPI/VSPI host
|
|
|
+ will be occupied by the system. Which SPI host to use can be selected by the config item
|
|
|
+ SPIRAM_OCCUPY_SPI_HOST. Application code should never touch HSPI/VSPI hardware in this case. The
|
|
|
+ option to select 80MHz will only be visible if the flash SPI speed is also 80MHz.
|
|
|
+ (ESPTOOLPY_FLASHFREQ_80M is true)
|
|
|
+
|
|
|
+ config SPIRAM_SPEED_40M
|
|
|
+ bool "40MHz clock speed"
|
|
|
+ config SPIRAM_SPEED_80M
|
|
|
+ depends on ESPTOOLPY_FLASHFREQ_80M
|
|
|
+ bool "80MHz clock speed"
|
|
|
+ endchoice
|
|
|
+
|
|
|
+ config SPIRAM_MEMTEST
|
|
|
+ bool "Run memory test on SPI RAM initialization"
|
|
|
+ default "y"
|
|
|
+ depends on SPIRAM_BOOT_INIT
|
|
|
+ help
|
|
|
+ Runs a rudimentary memory test on initialization. Aborts when memory test fails. Disable this for
|
|
|
+ slightly faster startop.
|
|
|
+
|
|
|
+ config SPIRAM_CACHE_WORKAROUND
|
|
|
+ bool "Enable workaround for bug in SPI RAM cache for Rev1 ESP32s"
|
|
|
+ depends on SPIRAM_USE_MEMMAP || SPIRAM_USE_CAPS_ALLOC || SPIRAM_USE_MALLOC
|
|
|
+ default "y"
|
|
|
+ help
|
|
|
+ Revision 1 of the ESP32 has a bug that can cause a write to PSRAM not to take place in some situations
|
|
|
+ when the cache line needs to be fetched from external RAM and an interrupt occurs. This enables a
|
|
|
+ fix in the compiler that makes sure the specific code that is vulnerable to this will not be emitted.
|
|
|
+
|
|
|
+ This will also not use any bits of newlib that are located in ROM, opting for a version that is
|
|
|
+ compiled with the workaround and located in flash instead.
|
|
|
+
|
|
|
+ config SPIRAM_BANKSWITCH_ENABLE
|
|
|
+ bool "Enable bank switching for >4MiB external RAM"
|
|
|
+ default y
|
|
|
+ depends on SPIRAM_USE_MEMMAP || SPIRAM_USE_CAPS_ALLOC || SPIRAM_USE_MALLOC
|
|
|
+ help
|
|
|
+ The ESP32 only supports 4MiB of external RAM in its address space. The hardware does support larger
|
|
|
+ memories, but these have to be bank-switched in and out of this address space. Enabling this allows you
|
|
|
+ to reserve some MMU pages for this, which allows the use of the esp_himem api to manage these banks.
|
|
|
+
|
|
|
+ #Note that this is limited to 62 banks, as esp_spiram_writeback_cache needs some kind of mapping of
|
|
|
+ #some banks below that mark to work. We cannot at this moment guarantee this to exist when himem is
|
|
|
+ #enabled.
|
|
|
+ config SPIRAM_BANKSWITCH_RESERVE
|
|
|
+ int "Amount of 32K pages to reserve for bank switching"
|
|
|
+ depends on SPIRAM_BANKSWITCH_ENABLE
|
|
|
+ default 8
|
|
|
+ range 1 62
|
|
|
+ help
|
|
|
+ Select the amount of banks reserved for bank switching. Note that the amount of RAM allocatable with
|
|
|
+ malloc/esp_heap_alloc_caps will decrease by 32K for each page reserved here.
|
|
|
+
|
|
|
+ Note that this reservation is only actually done if your program actually uses the himem API. Without
|
|
|
+ any himem calls, the reservation is not done and the original amount of memory will be available
|
|
|
+ to malloc/esp_heap_alloc_caps.
|
|
|
+
|
|
|
+ config SPIRAM_MALLOC_ALWAYSINTERNAL
|
|
|
+ int "Maximum malloc() size, in bytes, to always put in internal memory"
|
|
|
+ depends on SPIRAM_USE_MALLOC
|
|
|
+ default 16384
|
|
|
+ range 0 131072
|
|
|
+ help
|
|
|
+ If malloc() is capable of also allocating SPI-connected ram, its allocation strategy will prefer to
|
|
|
+ allocate chunks less than this size in internal memory, while allocations larger than this will be
|
|
|
+ done from external RAM. If allocation from the preferred region fails, an attempt is made to allocate
|
|
|
+ from the non-preferred region instead, so malloc() will not suddenly fail when either internal or
|
|
|
+ external memory is full.
|
|
|
+
|
|
|
+ config WIFI_LWIP_ALLOCATION_FROM_SPIRAM_FIRST
|
|
|
+ bool "Try to allocate memories of WiFi and LWIP in SPIRAM firstly. If failed, allocate internal memory"
|
|
|
+ depends on SPIRAM_USE_CAPS_ALLOC || SPIRAM_USE_MALLOC
|
|
|
+ default "n"
|
|
|
+ help
|
|
|
+ Try to allocate memories of WiFi and LWIP in SPIRAM firstly. If failed, try to allocate internal
|
|
|
+ memory then.
|
|
|
+
|
|
|
+ config SPIRAM_MALLOC_RESERVE_INTERNAL
|
|
|
+ int "Reserve this amount of bytes for data that specifically needs to be in DMA or internal memory"
|
|
|
+ depends on SPIRAM_USE_MALLOC
|
|
|
+ default 32768
|
|
|
+ range 0 262144
|
|
|
+ help
|
|
|
+ Because the external/internal RAM allocation strategy is not always perfect, it sometimes may happen
|
|
|
+ that the internal memory is entirely filled up. This causes allocations that are specifically done in
|
|
|
+ internal memory, for example the stack for new tasks or memory to service DMA or have memory that's
|
|
|
+ also available when SPI cache is down, to fail. This option reserves a pool specifically for requests
|
|
|
+ like that; the memory in this pool is not given out when a normal malloc() is called.
|
|
|
+
|
|
|
+ Set this to 0 to disable this feature.
|
|
|
+
|
|
|
+ Note that because FreeRTOS stacks are forced to internal memory, they will also use this memory pool;
|
|
|
+ be sure to keep this in mind when adjusting this value.
|
|
|
+
|
|
|
+ Note also that the DMA reserved pool may not be one single contiguous memory region, depending on the
|
|
|
+ configured size and the static memory usage of the app.
|
|
|
+
|
|
|
+
|
|
|
+ config SPIRAM_ALLOW_STACK_EXTERNAL_MEMORY
|
|
|
+ bool "Allow external memory as an argument to xTaskCreateStatic"
|
|
|
+ default n
|
|
|
+ depends on SPIRAM_USE_MALLOC
|
|
|
+ help
|
|
|
+ Because some bits of the ESP32 code environment cannot be recompiled with the cache workaround,
|
|
|
+ normally tasks cannot be safely run with their stack residing in external memory; for this reason
|
|
|
+ xTaskCreate and friends always allocate stack in internal memory and xTaskCreateStatic will check if
|
|
|
+ the memory passed to it is in internal memory. If you have a task that needs a large amount of stack
|
|
|
+ and does not call on ROM code in any way (no direct calls, but also no Bluetooth/WiFi), you can try to
|
|
|
+ disable this and use xTaskCreateStatic to create the tasks stack in external memory.
|
|
|
+
|
|
|
+ config SPIRAM_ALLOW_BSS_SEG_EXTERNAL_MEMORY
|
|
|
+ bool "Allow .bss segment placed in external memory"
|
|
|
+ default n
|
|
|
+ depends on SPIRAM_SUPPORT
|
|
|
+ help
|
|
|
+ If enabled the option,and add EXT_RAM_ATTR defined your variable,then your variable will be placed in
|
|
|
+ PSRAM instead of internal memory, and placed most of variables of lwip,net802.11,pp,bluedroid library
|
|
|
+ to external memory defaultly.
|
|
|
+
|
|
|
+ choice SPIRAM_OCCUPY_SPI_HOST
|
|
|
+ prompt "SPI host to use for 32MBit PSRAM"
|
|
|
+ default SPIRAM_OCCUPY_VSPI_HOST
|
|
|
+ depends on SPIRAM_SPEED_80M
|
|
|
+ help
|
|
|
+ When both flash and PSRAM is working under 80MHz, and the PSRAM is of type 32MBit, one of the HSPI/VSPI
|
|
|
+ host will be used to output the clock. Select which one to use here.
|
|
|
+
|
|
|
+ config SPIRAM_OCCUPY_HSPI_HOST
|
|
|
+ bool "HSPI host (SPI2)"
|
|
|
+ config SPIRAM_OCCUPY_VSPI_HOST
|
|
|
+ bool "VSPI host (SPI3)"
|
|
|
+ endchoice
|
|
|
+
|
|
|
+ config PICO_PSRAM_CS_IO
|
|
|
+ int "PSRAM CS IO for ESP32-PICO chip"
|
|
|
+ depends on SPIRAM_SUPPORT
|
|
|
+ range 0 33
|
|
|
+ default 10
|
|
|
+ help
|
|
|
+ When ESP32-PICO chip connect a external psram, the clock IO and data IO is fixed, but the CS IO can be
|
|
|
+ any unused GPIO, user can config it based on hardware design.
|
|
|
+
|
|
|
+ endmenu
|
|
|
+
|
|
|
+ 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 && !FREERTOS_UNICORE
|
|
|
+ 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
|
|
|
+
|
|
|
+ menu "Core dump"
|
|
|
+
|
|
|
+ choice ESP32_COREDUMP_TO_FLASH_OR_UART
|
|
|
+ prompt "Data 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_MAX_TASKS_NUM
|
|
|
+ int "Maximum number of tasks"
|
|
|
+ depends on ESP32_ENABLE_COREDUMP
|
|
|
+ default 64
|
|
|
+ help
|
|
|
+ Maximum number of tasks snapshots in core dump.
|
|
|
+
|
|
|
+ config ESP32_CORE_DUMP_UART_DELAY
|
|
|
+ int "Delay before print to UART"
|
|
|
+ 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.
|
|
|
+
|
|
|
+ endmenu
|
|
|
+
|
|
|
+ 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 2304
|
|
|
+ help
|
|
|
+ Config system event task stack size in different application.
|
|
|
+
|
|
|
+ config MAIN_TASK_STACK_SIZE
|
|
|
+ int "Main task stack size"
|
|
|
+ default 3584
|
|
|
+ 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.
|
|
|
+
|
|
|
+ config TIMER_TASK_STACK_SIZE
|
|
|
+ int "High-resolution timer task stack size"
|
|
|
+ default 3584
|
|
|
+ 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.
|
|
|
+
|
|
|
+ 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 ESP32_DEBUG_STUBS_ENABLE
|
|
|
+ bool "OpenOCD debug stubs"
|
|
|
+ default OPTIMIZATION_LEVEL_DEBUG
|
|
|
+ depends on !ESP32_TRAX
|
|
|
+ help
|
|
|
+ Debug stubs are used by OpenOCD to execute pre-compiled onboard code which does some useful debugging,
|
|
|
+ e.g. GCOV data dump.
|
|
|
+
|
|
|
+ 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 if !SPIRAM_SUPPORT
|
|
|
+ default 800 if SPIRAM_SUPPORT
|
|
|
+ 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 "Initialize Task Watchdog Timer on startup"
|
|
|
+ default y
|
|
|
+ help
|
|
|
+ The Task Watchdog Timer can be used to make sure individual tasks are still
|
|
|
+ running. Enabling this option will cause the Task Watchdog Timer to be
|
|
|
+ initialized automatically at startup. The Task Watchdog timer can be
|
|
|
+ initialized after startup as well (see Task Watchdog Timer API Reference)
|
|
|
+
|
|
|
+ config TASK_WDT_PANIC
|
|
|
+ bool "Invoke panic handler on Task Watchdog timeout"
|
|
|
+ depends on TASK_WDT
|
|
|
+ default n
|
|
|
+ help
|
|
|
+ If this option is enabled, the Task Watchdog Timer will be configured to
|
|
|
+ trigger the panic handler when it times out. This can also be configured
|
|
|
+ at run time (see Task Watchdog Timer API Reference)
|
|
|
+
|
|
|
+ config TASK_WDT_TIMEOUT_S
|
|
|
+ int "Task Watchdog timeout period (seconds)"
|
|
|
+ depends on TASK_WDT
|
|
|
+ range 1 60
|
|
|
+ default 5
|
|
|
+ help
|
|
|
+ Timeout period configuration for the Task Watchdog Timer in seconds.
|
|
|
+ This is also configurable at run time (see Task Watchdog Timer API Reference)
|
|
|
+
|
|
|
+ config TASK_WDT_CHECK_IDLE_TASK_CPU0
|
|
|
+ bool "Watch CPU0 Idle Task"
|
|
|
+ depends on TASK_WDT
|
|
|
+ default y
|
|
|
+ help
|
|
|
+ If this option is enabled, the Task Watchdog Timer will watch the CPU0
|
|
|
+ Idle Task. Having the Task Watchdog watch the Idle Task allows for detection
|
|
|
+ of CPU starvation as the Idle Task not being called is usually a symptom of
|
|
|
+ CPU starvation. Starvation of the Idle Task is detrimental as FreeRTOS household
|
|
|
+ tasks depend on the Idle Task getting some runtime every now and then.
|
|
|
+
|
|
|
+ config TASK_WDT_CHECK_IDLE_TASK_CPU1
|
|
|
+ bool "Watch CPU1 Idle Task"
|
|
|
+ depends on TASK_WDT && !FREERTOS_UNICORE
|
|
|
+ default y
|
|
|
+ help
|
|
|
+ If this option is enabled, the Task Wtachdog Timer will wach the CPU1
|
|
|
+ Idle Task.
|
|
|
+
|
|
|
+ config BROWNOUT_DET
|
|
|
+ #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.
|
|
|
+ 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 approximately
|
|
|
+ below this level. Note that there may be some variation of brownout voltage level
|
|
|
+ between each ESP32 chip.
|
|
|
+
|
|
|
+ #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.43V +/- 0.05"
|
|
|
+ config BROWNOUT_DET_LVL_SEL_1
|
|
|
+ bool "2.48V +/- 0.05"
|
|
|
+ config BROWNOUT_DET_LVL_SEL_2
|
|
|
+ bool "2.58V +/- 0.05"
|
|
|
+ config BROWNOUT_DET_LVL_SEL_3
|
|
|
+ bool "2.62V +/- 0.05"
|
|
|
+ config BROWNOUT_DET_LVL_SEL_4
|
|
|
+ bool "2.67V +/- 0.05"
|
|
|
+ config BROWNOUT_DET_LVL_SEL_5
|
|
|
+ bool "2.70V +/- 0.05"
|
|
|
+ config BROWNOUT_DET_LVL_SEL_6
|
|
|
+ bool "2.77V +/- 0.05"
|
|
|
+ config BROWNOUT_DET_LVL_SEL_7
|
|
|
+ bool "2.80V +/- 0.05"
|
|
|
+ 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
|
|
|
+
|
|
|
+
|
|
|
+ #Reduce PHY TX power when brownout reset
|
|
|
+ config REDUCE_PHY_TX_POWER
|
|
|
+ bool "Reduce PHY TX power when brownout reset"
|
|
|
+ depends on BROWNOUT_DET
|
|
|
+ default y
|
|
|
+ help
|
|
|
+ When brownout reset occurs, reduce PHY TX power to keep the code running
|
|
|
+
|
|
|
+ # Note about the use of "FRC1" name: currently FRC1 timer is not used for
|
|
|
+ # high resolution timekeeping anymore. Instead the esp_timer API, implemented
|
|
|
+ # using FRC2 timer, is used.
|
|
|
+ # FRC1 name in the option name is kept for compatibility.
|
|
|
+ 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 both high-resolution and RTC timers are used, timekeeping will
|
|
|
+ continue in deep sleep. Time will be reported at 1 microsecond
|
|
|
+ resolution. This is the default, and the recommended option.
|
|
|
+ - If only high-resolution timer is used, gettimeofday will
|
|
|
+ provide time at microsecond resolution.
|
|
|
+ Time will not be preserved when going into deep sleep mode.
|
|
|
+ - 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_FRC1
|
|
|
+ bool "RTC and high-resolution timer"
|
|
|
+ config ESP32_TIME_SYSCALL_USE_RTC
|
|
|
+ bool "RTC"
|
|
|
+ config ESP32_TIME_SYSCALL_USE_FRC1
|
|
|
+ bool "High-resolution timer"
|
|
|
+ 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.
|
|
|
+
|
|
|
+ - "Internal 150kHz oscillator" option provides lowest deep sleep current
|
|
|
+ consumption, and does not require extra external components. However
|
|
|
+ frequency stability with respect to temperature is poor, so time may
|
|
|
+ drift in deep/light sleep modes.
|
|
|
+ - "External 32kHz crystal" provides better frequency stability, at the
|
|
|
+ expense of slightly higher (1uA) deep sleep current consumption.
|
|
|
+ - "External 32kHz oscillator" allows using 32kHz clock generated by an
|
|
|
+ external circuit. In this case, external clock signal must be connected
|
|
|
+ to 32K_XP pin. Amplitude should be <1.2V in case of sine wave signal,
|
|
|
+ and <1V in case of square wave signal. Common mode voltage should be
|
|
|
+ 0.1 < Vcm < 0.5Vamp, where Vamp is the signal amplitude.
|
|
|
+ Additionally, 1nF capacitor must be connected between 32K_XN pin and
|
|
|
+ ground. 32K_XN pin can not be used as a GPIO in this case.
|
|
|
+ - "Internal 8.5MHz oscillator divided by 256" option results in higher
|
|
|
+ deep sleep current (by 5uA) but has better frequency stability than
|
|
|
+ the internal 150kHz oscillator. It does not require external components.
|
|
|
+
|
|
|
+ config ESP32_RTC_CLOCK_SOURCE_INTERNAL_RC
|
|
|
+ bool "Internal 150kHz RC oscillator"
|
|
|
+ config ESP32_RTC_CLOCK_SOURCE_EXTERNAL_CRYSTAL
|
|
|
+ bool "External 32kHz crystal"
|
|
|
+ config ESP32_RTC_CLOCK_SOURCE_EXTERNAL_OSC
|
|
|
+ bool "External 32kHz oscillator at 32K_XP pin"
|
|
|
+ config ESP32_RTC_CLOCK_SOURCE_INTERNAL_8MD256
|
|
|
+ bool "Internal 8.5MHz oscillator, divided by 256 (~33kHz)"
|
|
|
+ endchoice
|
|
|
+
|
|
|
+ config ESP32_RTC_CLK_CAL_CYCLES
|
|
|
+ int "Number of cycles for RTC_SLOW_CLK calibration"
|
|
|
+ default 3000 if ESP32_RTC_CLOCK_SOURCE_EXTERNAL_CRYSTAL
|
|
|
+ default 1024 if ESP32_RTC_CLOCK_SOURCE_INTERNAL_RC
|
|
|
+ range 0 27000 if ESP32_RTC_CLOCK_SOURCE_EXTERNAL_CRYSTAL || ESP32_RTC_CLOCK_SOURCE_EXTERNAL_OSC \
|
|
|
+ || ESP32_RTC_CLOCK_SOURCE_INTERNAL_8MD256
|
|
|
+ range 0 32766 if ESP32_RTC_CLOCK_SOURCE_INTERNAL_RC
|
|
|
+ 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. For this use value 1024.
|
|
|
+ - 32768 Hz if the 32k crystal oscillator is used. For this use value 3000 or more.
|
|
|
+ In case more value will help improve the definition of the launch of the crystal.
|
|
|
+ If the crystal could not start, it will be switched to internal RC.
|
|
|
+
|
|
|
+ config ESP32_RTC_XTAL_BOOTSTRAP_CYCLES
|
|
|
+ int "Bootstrap cycles for external 32kHz crystal"
|
|
|
+ depends on ESP32_RTC_CLOCK_SOURCE_EXTERNAL_CRYSTAL
|
|
|
+ default 5
|
|
|
+ range 0 32768
|
|
|
+ help
|
|
|
+ To reduce the startup time of an external RTC crystal,
|
|
|
+ we bootstrap it with a 32kHz square wave for a fixed number of cycles.
|
|
|
+ Setting 0 will disable bootstrapping (if disabled, the crystal may take
|
|
|
+ longer to start up or fail to oscillate under some conditions).
|
|
|
+
|
|
|
+ If this value is too high, a faulty crystal may initially start and then fail.
|
|
|
+ If this value is too low, an otherwise good crystal may not start.
|
|
|
+
|
|
|
+ To accurately determine if the crystal has started,
|
|
|
+ set a larger "Number of cycles for RTC_SLOW_CLK calibration" (about 3000).
|
|
|
+
|
|
|
+ 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 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.)
|
|
|
+
|
|
|
+ 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.
|
|
|
+
|
|
|
+ config ESP_TIMER_PROFILING
|
|
|
+ bool "Enable esp_timer profiling features"
|
|
|
+ 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.
|
|
|
+
|
|
|
+ config COMPATIBLE_PRE_V2_1_BOOTLOADERS
|
|
|
+ bool "App compatible with bootloaders before IDF v2.1"
|
|
|
+ default n
|
|
|
+ help
|
|
|
+ Bootloaders before IDF v2.1 did less initialisation of the
|
|
|
+ system clock. This setting needs to be enabled to build an app
|
|
|
+ which can be booted by these older bootloaders.
|
|
|
+
|
|
|
+ If this setting is enabled, the app can be booted by any bootloader
|
|
|
+ from IDF v1.0 up to the current version.
|
|
|
+
|
|
|
+ If this setting is disabled, the app can only be booted by bootloaders
|
|
|
+ from IDF v2.1 or newer.
|
|
|
+
|
|
|
+ Enabling this setting adds approximately 1KB to the app's IRAM usage.
|
|
|
+
|
|
|
+ config ESP_ERR_TO_NAME_LOOKUP
|
|
|
+ bool "Enable lookup of error code strings"
|
|
|
+ default "y"
|
|
|
+ help
|
|
|
+ Functions esp_err_to_name() and esp_err_to_name_r() return string
|
|
|
+ representations of error codes from a pre-generated lookup table.
|
|
|
+ This option can be used to turn off the use of the look-up table in
|
|
|
+ order to save memory but this comes at the price of sacrificing
|
|
|
+ distinguishable (meaningful) output string representations.
|
|
|
+
|
|
|
+ config ESP32_RTCDATA_IN_FAST_MEM
|
|
|
+ bool "Place RTC_DATA_ATTR and RTC_RODATA_ATTR variables into RTC fast memory segment"
|
|
|
+ default n
|
|
|
+ depends on FREERTOS_UNICORE
|
|
|
+ help
|
|
|
+ This option allows to place .rtc_data and .rtc_rodata sections into
|
|
|
+ RTC fast memory segment to free the slow memory region for ULP programs.
|
|
|
+ This option depends on the CONFIG_FREERTOS_UNICORE option because RTC fast memory
|
|
|
+ can be accessed only by PRO_CPU core.
|
|
|
|
|
|
endmenu # ESP32-Specific
|
|
|
|
|
|
menu Wi-Fi
|
|
|
|
|
|
-config SW_COEXIST_ENABLE
|
|
|
- bool "Software controls WiFi/Bluetooth coexistence"
|
|
|
- depends on BT_ENABLED
|
|
|
- default y
|
|
|
- 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.
|
|
|
-
|
|
|
-choice SW_COEXIST_PREFERENCE
|
|
|
- prompt "WiFi/Bluetooth coexistence performance preference"
|
|
|
- depends on SW_COEXIST_ENABLE
|
|
|
- default SW_COEXIST_PREFERENCE_BALANCE
|
|
|
- help
|
|
|
- Choose Bluetooth/WiFi/Balance for different preference.
|
|
|
- If choose WiFi, it will make WiFi performance better. Such, keep WiFi Audio more fluent.
|
|
|
- If choose Bluetooth, it will make Bluetooth performance better. Such, keep Bluetooth(A2DP) Audio more fluent.
|
|
|
- If choose Balance, the performance of WiFi and bluetooth will be balance. It's default. Normally, just choose balance, the A2DP audio can play fluently, too.
|
|
|
- Except config preference in menuconfig, you can also call esp_coex_preference_set() dynamically.
|
|
|
-
|
|
|
-config SW_COEXIST_PREFERENCE_WIFI
|
|
|
- bool "WiFi"
|
|
|
-
|
|
|
-config SW_COEXIST_PREFERENCE_BT
|
|
|
- bool "Bluetooth(include BR/EDR and BLE)"
|
|
|
-
|
|
|
-config SW_COEXIST_PREFERENCE_BALANCE
|
|
|
- bool "Balance"
|
|
|
-
|
|
|
-endchoice
|
|
|
-
|
|
|
-config SW_COEXIST_PREFERENCE_VALUE
|
|
|
- int
|
|
|
- depends on SW_COEXIST_ENABLE
|
|
|
- default 0 if SW_COEXIST_PREFERENCE_WIFI
|
|
|
- default 1 if SW_COEXIST_PREFERENCE_BT
|
|
|
- default 2 if SW_COEXIST_PREFERENCE_BALANCE
|
|
|
-
|
|
|
-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 all 802.11 frames.
|
|
|
- A higher number may allow higher throughput but increases memory use.
|
|
|
-
|
|
|
-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 unlimited RX buffers will be allocated
|
|
|
- (provided sufficient free RAM). The size of each dynamic RX buffer depends on the size of
|
|
|
- the received data frame.
|
|
|
-
|
|
|
- For each received data frame, the WiFi driver makes a copy to an RX buffer and then delivers
|
|
|
- it to the high layer TCP/IP stack. The dynamic RX buffer is freed after the higher layer has
|
|
|
- successfully received the data frame.
|
|
|
-
|
|
|
- For some applications, WiFi data frames may be received faster than the application can
|
|
|
- process them. In these cases we may run out of memory if RX buffer number is unlimited (0).
|
|
|
-
|
|
|
- If a dynamic RX buffer limit is set, it should be at least the number of static RX buffers.
|
|
|
-
|
|
|
-choice ESP32_WIFI_TX_BUFFER
|
|
|
- prompt "Type of WiFi TX buffers"
|
|
|
- default ESP32_WIFI_DYNAMIC_TX_BUFFER
|
|
|
- help
|
|
|
- Select type of WiFi TX buffers:
|
|
|
-
|
|
|
- If "Static" is selected, WiFi TX buffers are allocated when WiFi is initialized and released
|
|
|
- when WiFi is de-initialized. The size of each static TX buffer is fixed to about 1.6KB.
|
|
|
-
|
|
|
- If "Dynamic" is selected, each WiFi TX buffer is allocated as needed when a data frame is
|
|
|
- delivered to the Wifi driver from the TCP/IP stack. The buffer is freed after the data frame
|
|
|
- has been sent by the WiFi driver. The size of each dynamic TX buffer depends on the length
|
|
|
- of each data frame sent by the TCP/IP layer.
|
|
|
-
|
|
|
- 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"
|
|
|
- depends on !SPIRAM_USE_MALLOC
|
|
|
-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 6 64
|
|
|
- default 16
|
|
|
- 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 transmitted data frame from the higher layer TCP/IP stack, the WiFi driver makes a
|
|
|
- copy of it in a TX buffer. For some applications especially UDP applications, the upper
|
|
|
- layer can deliver frames faster than WiFi layer can transmit. In these cases, we may run out
|
|
|
- of 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 128
|
|
|
- default 32
|
|
|
- help
|
|
|
- Set the number of WiFi dynamic TX buffers. The size of each dynamic TX buffer is not fixed,
|
|
|
- it depends on the size of each transmitted data frame.
|
|
|
-
|
|
|
- For each transmitted frame from the higher layer TCP/IP stack, the WiFi driver makes a copy
|
|
|
- of it in a TX buffer. For some applications, especially UDP applications, the upper layer
|
|
|
- can deliver frames faster than WiFi layer can transmit. In these cases, we may run out of TX
|
|
|
- buffers.
|
|
|
-
|
|
|
-config ESP32_WIFI_CSI_ENABLED
|
|
|
- bool "WiFi CSI(Channel State Information)"
|
|
|
- default n
|
|
|
- help
|
|
|
- Select this option to enable CSI(Channel State Information) feature. CSI takes about
|
|
|
- CONFIG_ESP32_WIFI_STATIC_RX_BUFFER_NUM KB of RAM. If CSI is not used, it is better to disable
|
|
|
- this feature in order to save memory.
|
|
|
-
|
|
|
-config ESP32_WIFI_AMPDU_TX_ENABLED
|
|
|
- bool "WiFi AMPDU TX"
|
|
|
- default y
|
|
|
- help
|
|
|
- Select this option to enable AMPDU TX feature
|
|
|
-
|
|
|
-
|
|
|
-config ESP32_WIFI_TX_BA_WIN
|
|
|
- int "WiFi AMPDU TX BA window size"
|
|
|
- depends on ESP32_WIFI_AMPDU_TX_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_AMPDU_RX_ENABLED
|
|
|
- bool "WiFi AMPDU RX"
|
|
|
- default y
|
|
|
- help
|
|
|
- Select this option to enable AMPDU RX feature
|
|
|
-
|
|
|
-config ESP32_WIFI_RX_BA_WIN
|
|
|
- int "WiFi AMPDU RX BA window size"
|
|
|
- depends on ESP32_WIFI_AMPDU_RX_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
|
|
|
-
|
|
|
-choice ESP32_WIFI_TASK_CORE_ID
|
|
|
- depends on !FREERTOS_UNICORE
|
|
|
- prompt "WiFi Task Core ID"
|
|
|
- default ESP32_WIFI_TASK_PINNED_TO_CORE_0
|
|
|
- help
|
|
|
- Pinned WiFi task to core 0 or core 1.
|
|
|
-
|
|
|
-config ESP32_WIFI_TASK_PINNED_TO_CORE_0
|
|
|
- bool "Core 0"
|
|
|
-config ESP32_WIFI_TASK_PINNED_TO_CORE_1
|
|
|
- bool "Core 1"
|
|
|
-endchoice
|
|
|
-
|
|
|
-config ESP32_WIFI_SOFTAP_BEACON_MAX_LEN
|
|
|
- int "Max length of WiFi SoftAP Beacon"
|
|
|
- range 752 1256
|
|
|
- default 752
|
|
|
- help
|
|
|
- ESP-MESH utilizes beacon frames to detect and resolve root node conflicts (see documentation). However the default
|
|
|
- length of a beacon frame can simultaneously hold only five root node identifier structures, meaning that a root node
|
|
|
- conflict of up to five nodes can be detected at one time. In the occurence of more root nodes conflict involving more
|
|
|
- than five root nodes, the conflict resolution process will detect five of the root nodes, resolve the conflict, and
|
|
|
- re-detect more root nodes. This process will repeat until all root node conflicts are resolved. However this process
|
|
|
- can generally take a very long time.
|
|
|
-
|
|
|
- To counter this situation, the beacon frame length can be increased such that more root nodes can be detected simultaneously.
|
|
|
- Each additional root node will require 36 bytes and should be added ontop of the default beacon frame length of
|
|
|
- 752 bytes. For example, if you want to detect 10 root nodes simultaneously, you need to set the beacon frame length as
|
|
|
- 932 (752+36*5).
|
|
|
-
|
|
|
- Setting a longer beacon length also assists with debugging as the conflicting root nodes can be identified more quickly.
|
|
|
-
|
|
|
-config ESP32_WIFI_DEBUG_LOG_ENABLE
|
|
|
- bool "Enable WiFi debug log"
|
|
|
- default n
|
|
|
- help
|
|
|
- Select this option to enable WiFi debug log
|
|
|
-
|
|
|
-choice ESP32_WIFI_DEBUG_LOG_LEVEL
|
|
|
- depends on ESP32_WIFI_DEBUG_LOG_ENABLE
|
|
|
- prompt "WiFi debug log level"
|
|
|
- default ESP32_WIFI_LOG_DEBUG
|
|
|
- help
|
|
|
- The WiFi log is divided into the following levels: ERROR,WARNING,INFO,DEBUG,VERBOSE.
|
|
|
- The ERROR,WARNING,INFO levels are enabled by default, and the DEBUG,VERBOSE levels can be enabled here.
|
|
|
-
|
|
|
-config ESP32_WIFI_DEBUG_LOG_DEBUG
|
|
|
- bool "WiFi Debug Log Debug"
|
|
|
-config ESP32_WIFI_DEBUG_LOG_VERBOSE
|
|
|
- bool "WiFi Debug Log Verbose"
|
|
|
-endchoice
|
|
|
-
|
|
|
-choice ESP32_WIFI_DEBUG_LOG_MODULE
|
|
|
- depends on ESP32_WIFI_DEBUG_LOG_ENABLE
|
|
|
- prompt "WiFi debug log module"
|
|
|
- default ESP32_WIFI_DEBUG_LOG_MODULE_WIFI
|
|
|
- help
|
|
|
- The WiFi log module contains three parts: WIFI,COEX,MESH.
|
|
|
- The WIFI module indicates the logs related to WiFi, the COEX module indicates the logs related to WiFi and BT(or BLE) coexist,
|
|
|
- the MESH module indicates the logs related to Mesh. When ESP32_WIFI_LOG_MODULE_ALL is enabled, all modules are selected.
|
|
|
-
|
|
|
-config ESP32_WIFI_DEBUG_LOG_MODULE_ALL
|
|
|
- bool "WiFi Debug Log Module All"
|
|
|
-config ESP32_WIFI_DEBUG_LOG_MODULE_WIFI
|
|
|
- bool "WiFi Debug Log Module WiFi"
|
|
|
-config ESP32_WIFI_DEBUG_LOG_MODULE_COEX
|
|
|
- bool "WiFi Debug Log Module Coex"
|
|
|
-config ESP32_WIFI_DEBUG_LOG_MODULE_MESH
|
|
|
- bool "WiFi Debug Log Module Mesh"
|
|
|
-endchoice
|
|
|
-
|
|
|
-config ESP32_WIFI_DEBUG_LOG_SUBMODULE
|
|
|
- depends on ESP32_WIFI_DEBUG_LOG_ENABLE
|
|
|
- bool "WiFi debug log submodule"
|
|
|
- default n
|
|
|
- help
|
|
|
- Enable this option to set the WiFi debug log submodule.
|
|
|
- Currently the log submodule contains the following parts: INIT,IOCTL,CONN,SCAN.
|
|
|
- The INIT submodule indicates the initialization process.The IOCTL submodule indicates the API calling process.
|
|
|
- The CONN submodule indicates the connecting process.The SCAN submodule indicates the scaning process.
|
|
|
-
|
|
|
-config ESP32_WIFI_DEBUG_LOG_SUBMODULE_ALL
|
|
|
- depends on ESP32_WIFI_DEBUG_LOG_SUBMODULE
|
|
|
- bool "WiFi Debug Log Submodule All"
|
|
|
- default n
|
|
|
- help
|
|
|
- When this option is enabled, all debug submodules are selected.
|
|
|
-
|
|
|
-config ESP32_WIFI_DEBUG_LOG_SUBMODULE_INIT
|
|
|
- depends on ESP32_WIFI_DEBUG_LOG_SUBMODULE && (!ESP32_WIFI_DEBUG_LOG_SUBMODULE_ALL)
|
|
|
- bool "WiFi Debug Log Submodule Init"
|
|
|
- default n
|
|
|
-
|
|
|
-config ESP32_WIFI_DEBUG_LOG_SUBMODULE_IOCTL
|
|
|
- depends on ESP32_WIFI_DEBUG_LOG_SUBMODULE && (!ESP32_WIFI_DEBUG_LOG_SUBMODULE_ALL)
|
|
|
- bool "WiFi Debug Log Submodule Ioctl"
|
|
|
- default n
|
|
|
-
|
|
|
-config ESP32_WIFI_DEBUG_LOG_SUBMODULE_CONN
|
|
|
- depends on ESP32_WIFI_DEBUG_LOG_SUBMODULE && (!ESP32_WIFI_DEBUG_LOG_SUBMODULE_ALL)
|
|
|
- bool "WiFi Debug Log Submodule Conn"
|
|
|
- default n
|
|
|
-
|
|
|
-config ESP32_WIFI_DEBUG_LOG_SUBMODULE_SCAN
|
|
|
- depends on ESP32_WIFI_DEBUG_LOG_SUBMODULE && (!ESP32_WIFI_DEBUG_LOG_SUBMODULE_ALL)
|
|
|
- bool "WiFi Debug Log Submodule Scan"
|
|
|
- default n
|
|
|
+ config SW_COEXIST_ENABLE
|
|
|
+ bool "Software controls WiFi/Bluetooth coexistence"
|
|
|
+ depends on BT_ENABLED
|
|
|
+ default y
|
|
|
+ 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.
|
|
|
+
|
|
|
+ choice SW_COEXIST_PREFERENCE
|
|
|
+ prompt "WiFi/Bluetooth coexistence performance preference"
|
|
|
+ depends on SW_COEXIST_ENABLE
|
|
|
+ default SW_COEXIST_PREFERENCE_BALANCE
|
|
|
+ help
|
|
|
+ Choose Bluetooth/WiFi/Balance for different preference.
|
|
|
+ If choose WiFi, it will make WiFi performance better. Such, keep WiFi Audio more fluent.
|
|
|
+ If choose Bluetooth, it will make Bluetooth performance better. Such, keep Bluetooth(A2DP) Audio more
|
|
|
+ fluent.
|
|
|
+ If choose Balance, the performance of WiFi and bluetooth will be balance. It's default. Normally, just
|
|
|
+ choose balance, the A2DP audio can play fluently, too.
|
|
|
+ Except config preference in menuconfig, you can also call esp_coex_preference_set() dynamically.
|
|
|
+
|
|
|
+ config SW_COEXIST_PREFERENCE_WIFI
|
|
|
+ bool "WiFi"
|
|
|
+
|
|
|
+ config SW_COEXIST_PREFERENCE_BT
|
|
|
+ bool "Bluetooth(include BR/EDR and BLE)"
|
|
|
+
|
|
|
+ config SW_COEXIST_PREFERENCE_BALANCE
|
|
|
+ bool "Balance"
|
|
|
+
|
|
|
+ endchoice
|
|
|
+
|
|
|
+ config SW_COEXIST_PREFERENCE_VALUE
|
|
|
+ int
|
|
|
+ depends on SW_COEXIST_ENABLE
|
|
|
+ default 0 if SW_COEXIST_PREFERENCE_WIFI
|
|
|
+ default 1 if SW_COEXIST_PREFERENCE_BT
|
|
|
+ default 2 if SW_COEXIST_PREFERENCE_BALANCE
|
|
|
+
|
|
|
+ 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 all 802.11 frames.
|
|
|
+ A higher number may allow higher throughput but increases memory use.
|
|
|
+
|
|
|
+ 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 unlimited RX buffers will be allocated
|
|
|
+ (provided sufficient free RAM). The size of each dynamic RX buffer depends on the size of
|
|
|
+ the received data frame.
|
|
|
+
|
|
|
+ For each received data frame, the WiFi driver makes a copy to an RX buffer and then delivers
|
|
|
+ it to the high layer TCP/IP stack. The dynamic RX buffer is freed after the higher layer has
|
|
|
+ successfully received the data frame.
|
|
|
+
|
|
|
+ For some applications, WiFi data frames may be received faster than the application can
|
|
|
+ process them. In these cases we may run out of memory if RX buffer number is unlimited (0).
|
|
|
+
|
|
|
+ If a dynamic RX buffer limit is set, it should be at least the number of static RX buffers.
|
|
|
+
|
|
|
+ choice ESP32_WIFI_TX_BUFFER
|
|
|
+ prompt "Type of WiFi TX buffers"
|
|
|
+ default ESP32_WIFI_DYNAMIC_TX_BUFFER
|
|
|
+ help
|
|
|
+ Select type of WiFi TX buffers:
|
|
|
+
|
|
|
+ If "Static" is selected, WiFi TX buffers are allocated when WiFi is initialized and released
|
|
|
+ when WiFi is de-initialized. The size of each static TX buffer is fixed to about 1.6KB.
|
|
|
+
|
|
|
+ If "Dynamic" is selected, each WiFi TX buffer is allocated as needed when a data frame is
|
|
|
+ delivered to the Wifi driver from the TCP/IP stack. The buffer is freed after the data frame
|
|
|
+ has been sent by the WiFi driver. The size of each dynamic TX buffer depends on the length
|
|
|
+ of each data frame sent by the TCP/IP layer.
|
|
|
+
|
|
|
+ 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"
|
|
|
+ depends on !SPIRAM_USE_MALLOC
|
|
|
+ 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 6 64
|
|
|
+ default 16
|
|
|
+ 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 transmitted data frame from the higher layer TCP/IP stack, the WiFi driver makes a
|
|
|
+ copy of it in a TX buffer. For some applications especially UDP applications, the upper
|
|
|
+ layer can deliver frames faster than WiFi layer can transmit. In these cases, we may run out
|
|
|
+ of 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 128
|
|
|
+ default 32
|
|
|
+ help
|
|
|
+ Set the number of WiFi dynamic TX buffers. The size of each dynamic TX buffer is not fixed,
|
|
|
+ it depends on the size of each transmitted data frame.
|
|
|
+
|
|
|
+ For each transmitted frame from the higher layer TCP/IP stack, the WiFi driver makes a copy
|
|
|
+ of it in a TX buffer. For some applications, especially UDP applications, the upper layer
|
|
|
+ can deliver frames faster than WiFi layer can transmit. In these cases, we may run out of TX
|
|
|
+ buffers.
|
|
|
+
|
|
|
+ config ESP32_WIFI_CSI_ENABLED
|
|
|
+ bool "WiFi CSI(Channel State Information)"
|
|
|
+ default n
|
|
|
+ help
|
|
|
+ Select this option to enable CSI(Channel State Information) feature. CSI takes about
|
|
|
+ CONFIG_ESP32_WIFI_STATIC_RX_BUFFER_NUM KB of RAM. If CSI is not used, it is better to disable
|
|
|
+ this feature in order to save memory.
|
|
|
+
|
|
|
+ config ESP32_WIFI_AMPDU_TX_ENABLED
|
|
|
+ bool "WiFi AMPDU TX"
|
|
|
+ default y
|
|
|
+ help
|
|
|
+ Select this option to enable AMPDU TX feature
|
|
|
+
|
|
|
+
|
|
|
+ config ESP32_WIFI_TX_BA_WIN
|
|
|
+ int "WiFi AMPDU TX BA window size"
|
|
|
+ depends on ESP32_WIFI_AMPDU_TX_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_AMPDU_RX_ENABLED
|
|
|
+ bool "WiFi AMPDU RX"
|
|
|
+ default y
|
|
|
+ help
|
|
|
+ Select this option to enable AMPDU RX feature
|
|
|
+
|
|
|
+ config ESP32_WIFI_RX_BA_WIN
|
|
|
+ int "WiFi AMPDU RX BA window size"
|
|
|
+ depends on ESP32_WIFI_AMPDU_RX_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
|
|
|
+
|
|
|
+ choice ESP32_WIFI_TASK_CORE_ID
|
|
|
+ depends on !FREERTOS_UNICORE
|
|
|
+ prompt "WiFi Task Core ID"
|
|
|
+ default ESP32_WIFI_TASK_PINNED_TO_CORE_0
|
|
|
+ help
|
|
|
+ Pinned WiFi task to core 0 or core 1.
|
|
|
+
|
|
|
+ config ESP32_WIFI_TASK_PINNED_TO_CORE_0
|
|
|
+ bool "Core 0"
|
|
|
+ config ESP32_WIFI_TASK_PINNED_TO_CORE_1
|
|
|
+ bool "Core 1"
|
|
|
+ endchoice
|
|
|
+
|
|
|
+ config ESP32_WIFI_SOFTAP_BEACON_MAX_LEN
|
|
|
+ int "Max length of WiFi SoftAP Beacon"
|
|
|
+ range 752 1256
|
|
|
+ default 752
|
|
|
+ help
|
|
|
+ ESP-MESH utilizes beacon frames to detect and resolve root node conflicts (see documentation). However the
|
|
|
+ default length of a beacon frame can simultaneously hold only five root node identifier structures,
|
|
|
+ meaning that a root node conflict of up to five nodes can be detected at one time. In the occurence of
|
|
|
+ more root nodes conflict involving more than five root nodes, the conflict resolution process will detect
|
|
|
+ five of the root nodes, resolve the conflict, and re-detect more root nodes. This process will repeat
|
|
|
+ until all root node conflicts are resolved. However this process can generally take a very long time.
|
|
|
+
|
|
|
+ To counter this situation, the beacon frame length can be increased such that more root nodes can be
|
|
|
+ detected simultaneously. Each additional root node will require 36 bytes and should be added ontop of the
|
|
|
+ default beacon frame length of
|
|
|
+ 752 bytes. For example, if you want to detect 10 root nodes simultaneously, you need to set the beacon
|
|
|
+ frame length as
|
|
|
+ 932 (752+36*5).
|
|
|
+
|
|
|
+ Setting a longer beacon length also assists with debugging as the conflicting root nodes can be identified
|
|
|
+ more quickly.
|
|
|
+
|
|
|
+ config ESP32_WIFI_DEBUG_LOG_ENABLE
|
|
|
+ bool "Enable WiFi debug log"
|
|
|
+ default n
|
|
|
+ help
|
|
|
+ Select this option to enable WiFi debug log
|
|
|
+
|
|
|
+ choice ESP32_WIFI_DEBUG_LOG_LEVEL
|
|
|
+ depends on ESP32_WIFI_DEBUG_LOG_ENABLE
|
|
|
+ prompt "WiFi debug log level"
|
|
|
+ default ESP32_WIFI_LOG_DEBUG
|
|
|
+ help
|
|
|
+ The WiFi log is divided into the following levels: ERROR,WARNING,INFO,DEBUG,VERBOSE.
|
|
|
+ The ERROR,WARNING,INFO levels are enabled by default, and the DEBUG,VERBOSE levels can be enabled here.
|
|
|
+
|
|
|
+ config ESP32_WIFI_DEBUG_LOG_DEBUG
|
|
|
+ bool "WiFi Debug Log Debug"
|
|
|
+ config ESP32_WIFI_DEBUG_LOG_VERBOSE
|
|
|
+ bool "WiFi Debug Log Verbose"
|
|
|
+ endchoice
|
|
|
+
|
|
|
+ choice ESP32_WIFI_DEBUG_LOG_MODULE
|
|
|
+ depends on ESP32_WIFI_DEBUG_LOG_ENABLE
|
|
|
+ prompt "WiFi debug log module"
|
|
|
+ default ESP32_WIFI_DEBUG_LOG_MODULE_WIFI
|
|
|
+ help
|
|
|
+ The WiFi log module contains three parts: WIFI,COEX,MESH. The WIFI module indicates the logs related to
|
|
|
+ WiFi, the COEX module indicates the logs related to WiFi and BT(or BLE) coexist, the MESH module indicates
|
|
|
+ the logs related to Mesh. When ESP32_WIFI_LOG_MODULE_ALL is enabled, all modules are selected.
|
|
|
+
|
|
|
+ config ESP32_WIFI_DEBUG_LOG_MODULE_ALL
|
|
|
+ bool "WiFi Debug Log Module All"
|
|
|
+ config ESP32_WIFI_DEBUG_LOG_MODULE_WIFI
|
|
|
+ bool "WiFi Debug Log Module WiFi"
|
|
|
+ config ESP32_WIFI_DEBUG_LOG_MODULE_COEX
|
|
|
+ bool "WiFi Debug Log Module Coex"
|
|
|
+ config ESP32_WIFI_DEBUG_LOG_MODULE_MESH
|
|
|
+ bool "WiFi Debug Log Module Mesh"
|
|
|
+ endchoice
|
|
|
+
|
|
|
+ config ESP32_WIFI_DEBUG_LOG_SUBMODULE
|
|
|
+ depends on ESP32_WIFI_DEBUG_LOG_ENABLE
|
|
|
+ bool "WiFi debug log submodule"
|
|
|
+ default n
|
|
|
+ help
|
|
|
+ Enable this option to set the WiFi debug log submodule.
|
|
|
+ Currently the log submodule contains the following parts: INIT,IOCTL,CONN,SCAN.
|
|
|
+ The INIT submodule indicates the initialization process.The IOCTL submodule indicates the API calling
|
|
|
+ process.
|
|
|
+ The CONN submodule indicates the connecting process.The SCAN submodule indicates the scaning process.
|
|
|
+
|
|
|
+ config ESP32_WIFI_DEBUG_LOG_SUBMODULE_ALL
|
|
|
+ depends on ESP32_WIFI_DEBUG_LOG_SUBMODULE
|
|
|
+ bool "WiFi Debug Log Submodule All"
|
|
|
+ default n
|
|
|
+ help
|
|
|
+ When this option is enabled, all debug submodules are selected.
|
|
|
+
|
|
|
+ config ESP32_WIFI_DEBUG_LOG_SUBMODULE_INIT
|
|
|
+ depends on ESP32_WIFI_DEBUG_LOG_SUBMODULE && (!ESP32_WIFI_DEBUG_LOG_SUBMODULE_ALL)
|
|
|
+ bool "WiFi Debug Log Submodule Init"
|
|
|
+ default n
|
|
|
+
|
|
|
+ config ESP32_WIFI_DEBUG_LOG_SUBMODULE_IOCTL
|
|
|
+ depends on ESP32_WIFI_DEBUG_LOG_SUBMODULE && (!ESP32_WIFI_DEBUG_LOG_SUBMODULE_ALL)
|
|
|
+ bool "WiFi Debug Log Submodule Ioctl"
|
|
|
+ default n
|
|
|
+
|
|
|
+ config ESP32_WIFI_DEBUG_LOG_SUBMODULE_CONN
|
|
|
+ depends on ESP32_WIFI_DEBUG_LOG_SUBMODULE && (!ESP32_WIFI_DEBUG_LOG_SUBMODULE_ALL)
|
|
|
+ bool "WiFi Debug Log Submodule Conn"
|
|
|
+ default n
|
|
|
+
|
|
|
+ config ESP32_WIFI_DEBUG_LOG_SUBMODULE_SCAN
|
|
|
+ depends on ESP32_WIFI_DEBUG_LOG_SUBMODULE && (!ESP32_WIFI_DEBUG_LOG_SUBMODULE_ALL)
|
|
|
+ bool "WiFi Debug Log Submodule Scan"
|
|
|
+ default n
|
|
|
|
|
|
endmenu # Wi-Fi
|
|
|
|
|
|
menu PHY
|
|
|
|
|
|
-config ESP32_PHY_CALIBRATION_AND_DATA_STORAGE
|
|
|
- bool "Store phy 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. Normally, only partial calibration will be performed.
|
|
|
- If this option is disabled, full calibration will be performed.
|
|
|
-
|
|
|
- If it's easy that your board calibrate bad data, choose 'n'.
|
|
|
- Two cases for example, you should choose 'n':
|
|
|
- 1.If your board is easy to be booted up with antenna disconnected.
|
|
|
- 2.Because of your board design, each time when you do calibration, the result are too unstable.
|
|
|
- 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
|
|
|
+ config ESP32_PHY_CALIBRATION_AND_DATA_STORAGE
|
|
|
+ bool "Store phy 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. Normally, only partial calibration will be performed.
|
|
|
+ If this option is disabled, full calibration will be performed.
|
|
|
+
|
|
|
+ If it's easy that your board calibrate bad data, choose 'n'.
|
|
|
+ Two cases for example, you should choose 'n':
|
|
|
+ 1.If your board is easy to be booted up with antenna disconnected.
|
|
|
+ 2.Because of your board design, each time when you do calibration, the result are too unstable.
|
|
|
+ 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 # PHY
|
|
|
|
|
|
|
|
|
menu "Power Management"
|
|
|
|
|
|
-config PM_ENABLE
|
|
|
- bool "Support for power management"
|
|
|
- default n
|
|
|
- help
|
|
|
- If enabled, application is compiled with support for power management.
|
|
|
- This option has run-time overhead (increased interrupt latency,
|
|
|
- longer time to enter idle state), and it also reduces accuracy of
|
|
|
- RTOS ticks and timers used for timekeeping.
|
|
|
- Enable this option if application uses power management APIs.
|
|
|
-
|
|
|
-config PM_DFS_INIT_AUTO
|
|
|
- bool "Enable dynamic frequency scaling (DFS) at startup"
|
|
|
- depends on PM_ENABLE
|
|
|
- default n
|
|
|
- help
|
|
|
- If enabled, startup code configures dynamic frequency scaling.
|
|
|
- Max CPU frequency is set to CONFIG_ESP32_DEFAULT_CPU_FREQ_MHZ setting,
|
|
|
- min frequency is set to XTAL frequency.
|
|
|
- If disabled, DFS will not be active until the application
|
|
|
- configures it using esp_pm_configure function.
|
|
|
-
|
|
|
-config PM_USE_RTC_TIMER_REF
|
|
|
- bool "Use RTC timer to prevent time drift (EXPERIMENTAL)"
|
|
|
- depends on PM_ENABLE && (ESP32_TIME_SYSCALL_USE_RTC || ESP32_TIME_SYSCALL_USE_RTC_FRC1)
|
|
|
- default n
|
|
|
- help
|
|
|
- When APB clock frequency changes, high-resolution timer (esp_timer)
|
|
|
- scale and base value need to be adjusted. Each adjustment may cause
|
|
|
- small error, and over time such small errors may cause time drift.
|
|
|
- If this option is enabled, RTC timer will be used as a reference to
|
|
|
- compensate for the drift.
|
|
|
- It is recommended that this option is only used if 32k XTAL is selected
|
|
|
- as RTC clock source.
|
|
|
-
|
|
|
-config PM_PROFILING
|
|
|
- bool "Enable profiling counters for PM locks"
|
|
|
- depends on PM_ENABLE
|
|
|
- default n
|
|
|
- help
|
|
|
- If enabled, esp_pm_* functions will keep track of the amount of time
|
|
|
- each of the power management locks has been held, and esp_pm_dump_locks
|
|
|
- function will print this information.
|
|
|
- This feature can be used to analyze which locks are preventing the chip
|
|
|
- from going into a lower power state, and see what time the chip spends
|
|
|
- in each power saving mode. This feature does incur some run-time
|
|
|
- overhead, so should typically be disabled in production builds.
|
|
|
-
|
|
|
-config PM_TRACE
|
|
|
- bool "Enable debug tracing of PM using GPIOs"
|
|
|
- depends on PM_ENABLE
|
|
|
- default n
|
|
|
- help
|
|
|
- If enabled, some GPIOs will be used to signal events such as RTOS ticks,
|
|
|
- frequency switching, entry/exit from idle state. Refer to pm_trace.c
|
|
|
- file for the list of GPIOs.
|
|
|
- This feature is intended to be used when analyzing/debugging behavior
|
|
|
- of power management implementation, and should be kept disabled in
|
|
|
- applications.
|
|
|
+ config PM_ENABLE
|
|
|
+ bool "Support for power management"
|
|
|
+ default n
|
|
|
+ help
|
|
|
+ If enabled, application is compiled with support for power management.
|
|
|
+ This option has run-time overhead (increased interrupt latency,
|
|
|
+ longer time to enter idle state), and it also reduces accuracy of
|
|
|
+ RTOS ticks and timers used for timekeeping.
|
|
|
+ Enable this option if application uses power management APIs.
|
|
|
+
|
|
|
+ config PM_DFS_INIT_AUTO
|
|
|
+ bool "Enable dynamic frequency scaling (DFS) at startup"
|
|
|
+ depends on PM_ENABLE
|
|
|
+ default n
|
|
|
+ help
|
|
|
+ If enabled, startup code configures dynamic frequency scaling.
|
|
|
+ Max CPU frequency is set to CONFIG_ESP32_DEFAULT_CPU_FREQ_MHZ setting,
|
|
|
+ min frequency is set to XTAL frequency.
|
|
|
+ If disabled, DFS will not be active until the application
|
|
|
+ configures it using esp_pm_configure function.
|
|
|
+
|
|
|
+ config PM_USE_RTC_TIMER_REF
|
|
|
+ bool "Use RTC timer to prevent time drift (EXPERIMENTAL)"
|
|
|
+ depends on PM_ENABLE && (ESP32_TIME_SYSCALL_USE_RTC || ESP32_TIME_SYSCALL_USE_RTC_FRC1)
|
|
|
+ default n
|
|
|
+ help
|
|
|
+ When APB clock frequency changes, high-resolution timer (esp_timer)
|
|
|
+ scale and base value need to be adjusted. Each adjustment may cause
|
|
|
+ small error, and over time such small errors may cause time drift.
|
|
|
+ If this option is enabled, RTC timer will be used as a reference to
|
|
|
+ compensate for the drift.
|
|
|
+ It is recommended that this option is only used if 32k XTAL is selected
|
|
|
+ as RTC clock source.
|
|
|
+
|
|
|
+ config PM_PROFILING
|
|
|
+ bool "Enable profiling counters for PM locks"
|
|
|
+ depends on PM_ENABLE
|
|
|
+ default n
|
|
|
+ help
|
|
|
+ If enabled, esp_pm_* functions will keep track of the amount of time
|
|
|
+ each of the power management locks has been held, and esp_pm_dump_locks
|
|
|
+ function will print this information.
|
|
|
+ This feature can be used to analyze which locks are preventing the chip
|
|
|
+ from going into a lower power state, and see what time the chip spends
|
|
|
+ in each power saving mode. This feature does incur some run-time
|
|
|
+ overhead, so should typically be disabled in production builds.
|
|
|
+
|
|
|
+ config PM_TRACE
|
|
|
+ bool "Enable debug tracing of PM using GPIOs"
|
|
|
+ depends on PM_ENABLE
|
|
|
+ default n
|
|
|
+ help
|
|
|
+ If enabled, some GPIOs will be used to signal events such as RTOS ticks,
|
|
|
+ frequency switching, entry/exit from idle state. Refer to pm_trace.c
|
|
|
+ file for the list of GPIOs.
|
|
|
+ This feature is intended to be used when analyzing/debugging behavior
|
|
|
+ of power management implementation, and should be kept disabled in
|
|
|
+ applications.
|
|
|
|
|
|
|
|
|
endmenu # "Power Management"
|