OVMS3-idf/components/freertos/Kconfig

menu "FreeRTOS"

# This is actually also handled in the ESP32 startup code, not only in FreeRTOS.
config FREERTOS_UNICORE
    bool "Run FreeRTOS only on first core"
    default n
    help
        This version of FreeRTOS normally takes control of all cores of 
        the CPU. Select this if you only want to start it on the first core.
        This is needed when e.g. another process needs complete control
        over the second core.


choice FREERTOS_CORETIMER
    prompt "Xtensa timer to use as the FreeRTOS tick source"
    default CONFIG_FREERTOS_CORETIMER_0
    help
        FreeRTOS needs a timer with an associated interrupt to use as
        the main tick source to increase counters, run timers and do
        pre-emptive multitasking with. There are multiple timers available
        to do this, with different interrupt priorities. Check 

config FREERTOS_CORETIMER_0
    bool "Timer 0 (int 6, level 1)"
    help
        Select this to use timer 0

config FREERTOS_CORETIMER_1
    bool "Timer 1 (int 15, level 3)"
    help
        Select this to use timer 1

endchoice

config FREERTOS_HZ
    int "Tick rate (Hz)"
    range 1 1000
    default 100
    help
        Select the tick rate at which FreeRTOS does pre-emptive context switching.

config FREERTOS_ASSERT_ON_UNTESTED_FUNCTION
	bool "Halt when an SMP-untested function is called"
	default y
	help
		Some functions in FreeRTOS have not been thoroughly tested yet when moving to
		the SMP implementation of FreeRTOS. When this option is enabled, these fuctions
		will throw an assert().

choice FREERTOS_CHECK_STACKOVERFLOW
    prompt "Check for stack overflow"
    default FREERTOS_CHECK_STACKOVERFLOW_CANARY
    help
        FreeRTOS can check for stack overflows in threads and trigger an user function
        called vApplicationStackOverflowHook when this happens.

config FREERTOS_CHECK_STACKOVERFLOW_NONE
    bool "No checking"
    help
        Do not check for stack overflows (configCHECK_FOR_STACK_OVERFLOW=0)

config FREERTOS_CHECK_STACKOVERFLOW_PTRVAL
    bool "Check by stack pointer value"
    help
        Check for stack overflows on each context switch by checking if
        the stack pointer is in a valid range. Quick but does not detect
        stack overflows that happened between context switches
        (configCHECK_FOR_STACK_OVERFLOW=1)

config FREERTOS_CHECK_STACKOVERFLOW_CANARY
    bool "Check using canary bytes"
    help
        Places some magic bytes at the end of the stack area and on each 
        context switch, check if these bytes are still intact. More thorough
        than just checking the pointer, but also slightly slower.
        (configCHECK_FOR_STACK_OVERFLOW=2)
endchoice

config FREERTOS_WATCHPOINT_END_OF_STACK
    bool "Set a debug watchpoint as a stack overflow check"
    default n
    help
        FreeRTOS can check if a stack has overflown its bounds by checking either the value of
        the stack pointer or by checking the integrity of canary bytes. (See FREERTOS_CHECK_STACKOVERFLOW
        for more information.) These checks only happen on a context switch, and the situation that caused
        the stack overflow may already be long gone by then. This option will use the debug memory
        watchpoint 1 (the second one) to allow breaking into the debugger (or panic'ing) as soon as any
        of the last 32 bytes on the stack of a task are overwritten. The side effect is that using gdb, you
        effectively only have one watchpoint; the 2nd one is overwritten as soon as a task switch happens.

        This check only triggers if the stack overflow writes within 4 bytes of the end of the stack, rather than
        overshooting further, so it is worth combining this approach with one of the other stack overflow check methods.

        When this watchpoint is hit, gdb will stop with a SIGTRAP message. When no OCD is attached, esp-idf
        will panic on an unhandled debug exception.

config FREERTOS_THREAD_LOCAL_STORAGE_POINTERS
    int "Number of thread local storage pointers"
    range 0 256 if !(WIFI_ENABLED || ETHERNET)
    range 1 256 if WIFI_ENABLED || ETHERNET
    default 1
    help
        FreeRTOS has the ability to store per-thread pointers in the task
        control block. This controls the number of pointers available.

        Value 0 turns off this functionality.

        If using the LWIP TCP/IP stack (with WiFi or Ethernet), this value must be at least 1. See the
        LWIP_THREAD_LOCAL_STORAGE_INDEX config item in LWIP configuration to determine which thread-local-storage
        pointer is reserved for LWIP.

choice FREERTOS_ASSERT
    prompt "FreeRTOS assertions"
    default FREERTOS_ASSERT_FAIL_ABORT
    help
        Failed FreeRTOS configASSERT() assertions can be configured to
        behave in different ways.

config FREERTOS_ASSERT_FAIL_ABORT
    bool "abort() on failed assertions"
    help
        If a FreeRTOS configASSERT() fails, FreeRTOS will abort() and
        halt execution. The panic handler can be configured to handle
        the outcome of an abort() in different ways.

config FREERTOS_ASSERT_FAIL_PRINT_CONTINUE
    bool "Print and continue failed assertions"
    help
        If a FreeRTOS assertion fails, print it out and continue.

config FREERTOS_ASSERT_DISABLE
    bool "Disable FreeRTOS assertions"
    help
        FreeRTOS configASSERT() will not be compiled into the binary.

endchoice

config FREERTOS_BREAK_ON_SCHEDULER_START_JTAG
    bool "Stop program on scheduler start when JTAG/OCD is detected"
    depends on ESP32_DEBUG_OCDAWARE
    default y
    help
        If JTAG/OCD is connected, stop execution when the scheduler is started and the first
        task is executed.

menuconfig ENABLE_MEMORY_DEBUG
    bool "Enable heap memory debug"
    default n
    help
        Enable this option to show malloc heap block and memory crash detect

config FREERTOS_ISR_STACKSIZE
    int "ISR stack size"
    range 1536 32768
    default 1536
    help
        The interrupt handlers have their own stack. The size of the stack can be defined here. 
        Each processor has its own stack, so the total size occupied will be twice this.

config FREERTOS_LEGACY_HOOKS
    bool "Use FreeRTOS legacy hooks"
    default n
    help
        FreeRTOS offers a number of hooks/callback functions that are called when a timer
        tick happens, the idle thread runs etc. esp-idf replaces these by runtime registerable
        hooks using the esp_register_freertos_xxx_hook system, but for legacy reasons the old
        hooks can also still be enabled. Please enable this only if you have code that for some
        reason can't be migrated to the esp_register_freertos_xxx_hook system.

if FREERTOS_LEGACY_HOOKS

config FREERTOS_LEGACY_IDLE_HOOK
    bool "Enable legacy idle hook"
    default n
    help
        If enabled, FreeRTOS will call a function called vApplicationIdleHook when the idle thread
        on a CPU is running. Please make sure your code defines such a function.

config FREERTOS_LEGACY_TICK_HOOK
    bool "Enable legacy tick hook"
    default n
    help
        If enabled, FreeRTOS will call a function called vApplicationTickHook when a FreeRTOS
        tick is executed. Please make sure your code defines such a function.

endif #FREERTOS_LEGACY_HOOKS

config FREERTOS_MAX_TASK_NAME_LEN
    int "Maximum task name length"
    range 1 256
    default 16
    help
        Changes the maximum task name length. Each task allocated will
        include this many bytes for a task name. Using a shorter value
        saves a small amount of RAM, a longer value allows more complex
        names.

        For most uses, the default of 16 is OK.

config SUPPORT_STATIC_ALLOCATION
    bool "Enable FreeRTOS static allocation API"
    default n
    help
        FreeRTOS gives the application writer the ability to instead provide the memory
        themselves, allowing the following objects to optionally be created without any
        memory being allocated dynamically:

            - Tasks
            - Software Timers
            - Queues
            - Event Groups
            - Binary Semaphores
            - Counting Semaphores
            - Recursive Semaphores
            - Mutexes

        Whether it is preferable to use static or dynamic memory allocation is dependent on
        the application, and the preference of the application writer. Both methods have pros
        and cons, and both methods can be used within the same RTOS application.

        Creating RTOS objects using statically allocated RAM has the benefit of providing the
        application writer with more control: RTOS objects can be placed at specific memory locations.
        The maximum RAM footprint can be determined at link time, rather than run time.
        The application writer does not need to concern themselves with graceful handling of memory allocation failures.
        It allows the RTOS to be used in applications that simply don't allow any dynamic memory allocation
        (although FreeRTOS includes allocation schemes that can overcome most objections).

config ENABLE_STATIC_TASK_CLEAN_UP_HOOK
    bool "Enable static task clean up hook"
    depends on SUPPORT_STATIC_ALLOCATION
    default n
    help
        Enable this option to make FreeRTOS call the static task clean up hook when a task is deleted.

        Bear in mind that if this option is enabled you will need to implement the following function:

            void vPortCleanUpTCB ( void *pxTCB ) {
                // place clean up code here
            }

config TIMER_TASK_PRIORITY
    int "FreeRTOS timer task priority"
    range 1 25
    default 1
    help
        The timer service task (primarily) makes use of existing FreeRTOS features, allowing timer
        functionality to be added to an application with minimal impact on the size of the application's
        executable binary.

        Use this constant to define the priority that the timer task will run at.

config TIMER_TASK_STACK_DEPTH
    int "FreeRTOS timer task stack size"
    range 1536 32768
    default 2048
    help
        The timer service task (primarily) makes use of existing FreeRTOS features, allowing timer
        functionality to be added to an application with minimal impact on the size of the application's
        executable binary.

        Use this constant to define the size (in bytes) of the stack allocated for the timer task.

config TIMER_QUEUE_LENGTH
    int "FreeRTOS timer queue length"
    range 5 20
    default 10
    help
        FreeRTOS provides a set of timer related API functions. Many of these functions use a standard
        FreeRTOS queue to send commands to the timer service task. The queue used for this purpose is
        called the 'timer command queue'. The 'timer command queue' is private to the FreeRTOS timer
        implementation, and cannot be accessed directly.

        For most uses the default value of 10 is OK.

menuconfig FREERTOS_DEBUG_INTERNALS
    bool "Debug FreeRTOS internals"
    default n
    help
        Enable this option to show the menu with internal FreeRTOS debugging features.
        This option does not change any code by itself, it just shows/hides some options.

if FREERTOS_DEBUG_INTERNALS

config FREERTOS_PORTMUX_DEBUG
    bool "Debug portMUX portENTER_CRITICAL/portEXIT_CRITICAL"
    depends on FREERTOS_DEBUG_INTERNALS
    default n
    help
        If enabled, debug information (including integrity checks) will be printed
        to UART for the port-specific MUX implementation.

if !FREERTOS_UNICORE
config FREERTOS_PORTMUX_DEBUG_RECURSIVE
    bool "Debug portMUX Recursion"
    depends on FREERTOS_PORTMUX_DEBUG
    default n
    help
        If enabled, additional debug information will be printed for recursive
        portMUX usage.
endif #FREERTOS_UNICORE

endif # FREERTOS_DEBUG_INTERNALS

endmenu