If CONFIG_FREERTOS_LEGACY_HOOKS is kept enabled then defining
idle/tick hooks will be applications responsibility as was the
case earlier.
Signed-off-by: Mahavir Jain <mahavir@espressif.com>
This commit makes the configQUEUE_REGISTRY_SIZE and
configGENERATE_RUN_TIME_STATS configurable in menuconfig.
- configQUEUE_REGISTRY_SIZE can now be set in menuconfig.
- The functions vQueueAddToRegistry() and vQueueUnregisterQueue() were made
SMP compatbile
- pcQueueGetName() was backported from FreeRTOS v9.0.0
- Added test case for Queue Registry functions
- configGENERATE_RUN_TIME_STATS can now be enabled in menuconfig. CCOUNT or
esp_timer can be selected as the FreeRTOS run time clock in menuconfig as
well, although CCOUNT will overflow quickly.
- Run time stats collection (in vTaskSwitchContext) and generation (in
uxTaskGetSystemState) have been made SMP compatible. Therefore
vTaskGetRunTimeStats() now displays the run time usage of each task as a
percentage of total runtime of both CPUs
Squash
This commit makes configUSE_TRACE_FACILITY and
configUSE_STATS_FORMATTING_FUNCTIONS configurable in kconfig. Test cases fro the
functions enabled by the two configurations above have also been added.
Test cases for the following functions have been added...
- uxTaskGetSystemState()
- uxTaskGetTaskNumber()
- vTaskSetTaskNumber()
- xEventGroupClearBitsFromISR()
- xEventGroupSetBitsFromISR()
- uxEventGroupGetNumber()
- uxQueueGetQueueNumber()
- vQueueSetQueueNumber()
- ucQueueGetQueueType()
Test cases for the following functions were not required...
- prvListTaskWithinSingleList()
- prvWriteNameToBuffer()
- vTaskList()
Implements support for system level traces compatible with SEGGER
SystemView tool on top of ESP32 application tracing module.
That kind of traces can help to analyse program's behaviour.
SystemView can show timeline of tasks/ISRs execution, context switches,
statistics related to the CPUs' load distribution etc.
Also this commit adds useful feature to ESP32 application tracing module:
- Trace data buffering is implemented to handle temporary peaks of events load
The following issues mentioned during MR!341 review were fixed:
1) Core dump test application description
2) Usage of CONFIG_ESP32_ENABLE_COREDUMP_TO_FLASH and CONFIG_ESP32_ENABLE_COREDUMP_TO_UART
3) FLASH_GUARD_START macro usage is fixed in flash API
4) Core dump module logging facility
5) cache util functions doc updated
6) interactive delay before print core dump to uart
7) core dump partion support in build system
Complimentary changes:
1) Partition table definitions files with core dump partition
2) Special sub-type for core dump partition
3) Special version of spi_flash_xxx
4) espcoredump.py is script to get core dump from flash and print useful info
5) FreeRTOS API was extended to get tasks snapshots
Refs:
http://esp32.com/viewtopic.php?f=13&t=550http://esp32.com/viewtopic.php?f=13&t=551
rmt.c should include stdlib.h for malloc, esp_bignum,c &
https_request_main.c for abort().
FreeRTOSConfig.h is only including stdlib if
CONFIG_FREERTOS_ASSERT_ON_UNTESTED_FUNCTION is set. However, it is
included for abort() so needs to be included whenever
CONFIG_FREERTOS_ASSERT_FAIL_ABORT is set.
This change includes unconditionally in FreeRTOSConfig.h. This is to
avoid this kind of bug where compiler errors are dependent on config. I
suggest we don't change this to be more selective until we have 'make
randomconfig' style tests in CI.
Add cross-core int to accelerate task being awoken from another CPU.
This adds a per-CPU interrupt that can be used to poke the CPU to go do something. In this case all that is implemented is a request to yield the current task, used in case a CPU unblocks a task that runs on another CPU. This gets rid of the limitation that inter-CPU communication using queues, muxes etc can take up to a FreeRTOS tick to happen.
Specs!
Sending an in in a queue of length 1 (essentially a semaphore) as quickly as possible (just a small delay in the sender, to make sure the receiver task gets swapped out) for 10 seconds. Number indicates the amount of ints transferred
Old code:
CPU0->CPU0: 42986
CPU0->CPU1,: 2999
New code:
CPU0->CPU0: 42868
CPU0->CPU1: 62073
See merge request !155
Feature/wdts
This adds two watchdogs to esp-idf:
- An interrupt watchdog. Kicks in if the FreeRTOS timer interupt on either the PRO_CPU or (when configured) the APP CPU isn't called for a configurable time. Panics, displaying which CPU caused the problem and the registers that may lead to the offending code.
- A task watchdog. A task has to feed it every once in a while. If not, it will print the name of the offending tasks, as well as the tasks currently running on both CPUs, and optionally panic.
Also adds a panic reason to the panic call, as well as fixes the panic code a bit.
See merge request !148
* master: (117 commits)
build system: Add -fno-rtti when compiling C++ code
FreeRTOS KConfig: Limit tick rate to 1000Hz
bootloader: Fix accidental tabs introduced in !78
build system: Print a WARNING if any submodule is out of date
Fix stack overflow message format
'make flash' targets: Print serial port when flashing
lwip/esp32: support iperf
Add data memory for RMT peripheral
syscall write: Should return number of bytes written
Also push relevant tags over
esp32: add libsmartconfig.a to link libs
esp32: not link wps
esp32/lib: update wifi lib to a1e5f8b9
esp32: remove esp_wps.h
add smartconfig header files(merge this after updating libsmartconfig.a version v2.6.2)
esp32/lib: update wifi lib to 3853d7ae
Add Comments
Modify spinlock error in periph_ctrl.c
Define xcoreid offset, add warning in tcb struct wrt the need to also change that define when struct changes
components/tcpip_adapter: add some comments
...
# Conflicts:
# components/freertos/queue.c
# components/freertos/tasks.c
This feature allows to use static buffers (or from a pool of memory which is not
controlled by FreeRTOS).
In order to reduce the impact of the changes, the static feature has only been added
to the queus (and in consequence to the semaphores and the mutexes) and the tasks.
The Timer task is always dynamically allocated and also the idle task(s), which in the
case of the ESP-IDF is ok, since we always need to have dynamic allocation enabled.
* master: (57 commits)
components/lwip: fix grammar
components/lwip: make SO_REUSE configurable via menuconfig
bootloader: remove trailing newlines from log messages
components/freertos: override per-task __cleanup handler to close stdin, stdout, stderr
components/esp32: move peripheral symbols to separate ld script
components/log: regroup macros for better readability
gitlab-ci: allow running tests for branches, triggered via API
components/log: fix timestamp calculation
components/log: set default runtime log level to ESP_LOG_VERBOSE
components/log: fix error when using ESP_LOGx from C++ code
components/log: fix bugs, add options to override log level for files, components, and bootloader
fix ledc and spi typo
remove prefix and postfix
Enable SO_REUSEADDR in LWIP
freertos: fix memory debug macro issue Define configENABLE_MEMORY_DEBUG according to CONFIG_ENABLE_MEMORY_DEBUG
peripheral structure headers: move volatile keyword from members to typedef
Adding -fstrict-volatile-bitfields to the CFLAGS/CXXFLAGS. Without this, gcc tries to access bitfields using the smallest possible methods (eg l8i to grab an 8-bit field from a 32-bit). Our hardware does not like that. This flag tells gcc that if a bitfield is volatile, it should always use the type the field is defined at (uint32_t in our case) to size its access to the field. This fixes accessing the hardware through the xxx_struct.h headers.
add peripheral module struct headers
build system docs: Add note about no spaces in component names
Docs: Add note about unusual submodule messages when cloning on Windows
...
# Conflicts:
# components/esp32/cpu_start.c
# components/esp32/include/soc/cpu.h
Note that with WiFi stack enabled, system_init will reset frequency to 240MHz.
To make this setting useful, esp32-wifi-libs submodule needs to be updated.
1. This is just a temporary solution, it will be removed when umm_malloc is ready
2. Support memory canaries mechanism
2. Add debug code to show allocated memory info
The thread-local-storage feature in FreeRTOS attaches an application-usable array of pointers to a thread control block. These pointers usually point to a structure the thread allocates. When a thread gets (voluntarily or involuntarily) destroyed, this memory can leak. This merge adds a matching second array of user-settable pointers to destructor routines. As soon as the task gets cleaned up (which happens in the idle thread), the destructors get called and the memory can be freed.
See merge request !19
