OVMS3-idf/components/esp32/Kconfig

menu "ESP32-specific"

choice ESP32_DEFAULT_CPU_FREQ_MHZ
    prompt "CPU frequency"
    default ESP32_DEFAULT_CPU_FREQ_160
    help
        CPU frequency to be set on application startup.

config ESP32_DEFAULT_CPU_FREQ_80
    bool "80 MHz"
config ESP32_DEFAULT_CPU_FREQ_160
    bool "160 MHz"
config ESP32_DEFAULT_CPU_FREQ_240
    bool "240 MHz"
endchoice

config ESP32_DEFAULT_CPU_FREQ_MHZ
    int
    default 80 if ESP32_DEFAULT_CPU_FREQ_80
    default 160 if ESP32_DEFAULT_CPU_FREQ_160
    default 240 if ESP32_DEFAULT_CPU_FREQ_240

config MEMMAP_SMP
    bool "Reserve memory for two cores"
    default "y"
    help
        The ESP32 contains two cores. If you plan to only use one, you can disable this item
        to save some memory. (ToDo: Make this automatically depend on unicore support)

config 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
    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"
endchoice

choice SPIRAM_TYPE
    prompt "Type of SPI RAM chip in use"
    default SPIRAM_TYPE_ESPPSRAM32

config SPIRAM_TYPE_ESPPSRAM32
    bool "ESP-PSRAM32 or IS25WP032"
endchoice

config SPIRAM_SIZE
    int
    default 4194304 if SPIRAM_TYPE_ESPPSRAM32
    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, the VSPI port will be occupied by the system.
                 Application code should never touch 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_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 131072
    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.

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.

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 && MEMMAP_SMP
    select MEMMAP_TRACEMEM_TWOBANKS
    help
        The ESP32 contains a feature which allows you to trace the execution path the processor
        has taken through the program. This is stored in a chunk of 32K (16K for single-processor)
        of memory that can't be used for general purposes anymore. Disable this if you do not know
        what this is.

# Memory to reverse for trace, used in linker script
config TRACEMEM_RESERVE_DRAM
    hex
    default 0x8000 if MEMMAP_TRACEMEM && MEMMAP_TRACEMEM_TWOBANKS
    default 0x4000 if MEMMAP_TRACEMEM && !MEMMAP_TRACEMEM_TWOBANKS
    default 0x0

choice ESP32_COREDUMP_TO_FLASH_OR_UART
    prompt "Core dump destination"
    default ESP32_ENABLE_COREDUMP_TO_NONE
    help
        Select place to store core dump: flash, uart or none (to disable core dumps generation).

        If core dump is configured to be stored in flash and custom partition table is used add 
        corresponding entry to your CSV. For examples, please see predefined partition table CSV descriptions 
        in the components/partition_table directory.

config ESP32_ENABLE_COREDUMP_TO_FLASH
    bool "Flash"
    select ESP32_ENABLE_COREDUMP
config ESP32_ENABLE_COREDUMP_TO_UART
    bool "UART"
    select ESP32_ENABLE_COREDUMP
config ESP32_ENABLE_COREDUMP_TO_NONE
    bool "None"
endchoice

config ESP32_ENABLE_COREDUMP
    bool
    default F
    help
        Enables/disable core dump module.

config ESP32_CORE_DUMP_UART_DELAY
    int "Core dump print to UART delay"
    depends on ESP32_ENABLE_COREDUMP_TO_UART
    default 0
    help
        Config delay (in ms) before printing core dump to UART.
        Delay can be interrupted by pressing Enter key.

config ESP32_CORE_DUMP_LOG_LEVEL
    int "Core dump module logging level"
    depends on ESP32_ENABLE_COREDUMP
    default 1
    help
        Config core dump module logging level (0-5).

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 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


# 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.

config ESP32_RTC_CLOCK_SOURCE_INTERNAL_RC
    bool "Internal 150kHz RC oscillator"
config ESP32_RTC_CLOCK_SOURCE_EXTERNAL_CRYSTAL
    bool "External 32kHz crystal"
endchoice

config ESP32_RTC_CLK_CAL_CYCLES
    int "Number of cycles for RTC_SLOW_CLK calibration"
    default 1024
    range 0 125000
    help
        When the startup code initializes RTC_SLOW_CLK, it can perform
        calibration by comparing the RTC_SLOW_CLK frequency with main XTAL
        frequency. This option sets the number of RTC_SLOW_CLK cycles measured
        by the calibration routine. Higher numbers increase calibration
        precision, which may be important for applications which spend a lot of
        time in deep sleep. Lower numbers reduce startup time.
        
        When this option is set to 0, clock calibration will not be performed at
        startup, and approximate clock frequencies will be assumed:

        - 150000 Hz if internal RC oscillator is used as clock source
        - 32768 Hz if the 32k crystal oscillator is used

config ESP32_DEEP_SLEEP_WAKEUP_DELAY
    int "Extra delay in deep sleep wake stub (in us)"
    default 2000
    range 0 5000
    help
        When ESP32 exits deep sleep, the CPU and the flash chip are powered on
        at the same time. CPU will run deep sleep stub first, and then
        proceed to load code from flash. Some flash chips need sufficient
        time to pass between power on and first read operation. By default,
        without any extra delay, this time is approximately 900us, although
        some flash chip types need more than that.
        
        By default extra delay is set to 2000us. When optimizing startup time
        for applications which require it, this value may be reduced. 

        If you are seeing "flash read err, 1000" message printed to the
        console after deep sleep reset, try increasing this value.

choice ESP32_XTAL_FREQ_SEL
    prompt "Main XTAL frequency"
    default ESP32_XTAL_FREQ_40
    help
        ESP32 currently supports the following XTAL frequencies:

        - 26 MHz
        - 40 MHz

        Startup code can automatically estimate XTAL frequency. This feature
        uses the internal 8MHz oscillator as a reference. Because the internal
        oscillator frequency is temperature dependent, it is not recommended
        to use automatic XTAL frequency detection in applications which need
        to work at high ambient temperatures and use high-temperature
        qualified chips and modules.
config ESP32_XTAL_FREQ_40
    bool "40 MHz"
config ESP32_XTAL_FREQ_26
    bool "26 MHz"
config ESP32_XTAL_FREQ_AUTO
    bool "Autodetect"
endchoice

# Keep these values in sync with rtc_xtal_freq_t enum in soc/rtc.h
config ESP32_XTAL_FREQ
    int
    default 0 if ESP32_XTAL_FREQ_AUTO
    default 40 if ESP32_XTAL_FREQ_40
    default 26 if ESP32_XTAL_FREQ_26

config 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.

endmenu  # ESP32-Specific

menu Wi-Fi

config SW_COEXIST_ENABLE
    bool "Software controls WiFi/Bluetooth coexistence"
    depends on BT_ENABLED
    default n
    help
        If enabled, WiFi & Bluetooth coexistence is controlled by software rather than hardware.
        Recommended for heavy traffic scenarios. Both coexistence configuration options are
        automatically managed, no user intervention is required.


config ESP32_WIFI_STATIC_RX_BUFFER_NUM
    int "Max number of WiFi static RX buffers"
    range 2 25
    default 10
    help
        Set the number of WiFi static RX buffers. Each buffer takes approximately 1.6KB of RAM.
        The static rx buffers are allocated when esp_wifi_init is called, they are not freed
        until esp_wifi_deinit is called.

        WiFi hardware use these buffers to receive 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_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

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

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.
	

endmenu # "Power Management"