Vanilla FreeRTOS expects applications to use one of the heap implementations
provided by FreeRTOS (i.e., heap_x.c), where functions such as pvPortMalloc()
and vPortFree() are defined in the heap implementation.
However, ESP-IDF already provides its own heap implementation
(i.e., esp_heap_caps.h). Thus, the pvPortMallc()/vPortFree() functions were
previously overriden by macro to call esp_heap functions directly.
This commit refactors the FreeRTOS port's heap as such:
- Added a heap_idf.c that implements all of the heap related functions required
by FreeRTOS source
- All dynamic memory allocated by FreeRTOS is from internal memory. Thus, the
FreeRTOS heap is the internal memory subset of the ESP-IDF heap.
- Removed some old macros to reduce diff from upstream source code.
This commit adds preprocessing time checks to ensure that
- configNUM_CORES is defined to 1 or 2
- Incompatible configurations are not set depending on configNUM_CORES
In IDF FreeRTOS, when building for SMP, there are numerous functions
which require different critical sections when compared to single-core. This
commit encapsulates those difference into a common set of macros whose
behavior depends on "configNUM_CORES > 1". As such...
- Vanilla behavior has been restored for some functions when building for
single core (i.e., used to call taskENTER_CRITICAL, now disables interrupts
mactching vanilla behavior).
- Reduces number of "#ifdef (configNUM_CORES > 1)" in functions
- Any SMP only critical sections are now wrapped by
"#ifdef (configNUM_CORES > 1)" and properly documented via comments.
This commit updates how configTHREAD_LOCAL_STORAGE_DELETE_CALLBACKS is defined
by default it to 0 if not defined elsewhere. Dependent code now check for
"configTHREAD_LOCAL_STORAGE_DELETE_CALLBACKS == 1" instead.
This commit synchronize the cosmetic differences of IDF FreeRTOS to upstream
Vanilla v10.4.3. Comsetic differences include:
- Out of date doxygen API descriptions
- Misnamed parameters
- Missing examples
- Fixed/added missing @cond/@code directives
- Extra/missing comments/lines
- Code formatting (uncrustify)
Other changes:
- Some ESP_PLATFORM directives were also removed
- xTaskIncrementTickOtherCores() now depends on "configNUM_CORES > 1"
- Updated some multi-core dummy variable names in FreeRTOS.h
This commit reverts the previous "taskENTER_CRTIICAL();" so that the argument
is now provided for better code readability. The names of the spinlocks have
also been updated.
Closes https://github.com/espressif/esp-idf/issues/7207
The description of how the xTaskGenericNotifyWait parameter is handled in the
xTaskGenericNotifyWait() function was inaccurate.
In this commit, the description was updated to match the implementation of xTaskGenericNotifyWait().
Previously, xTaskIncrementTick() would always trigger a yield (i.e., return pdTRUE)
when called on core 1. This would mean core 1 would call vTaskSwitchContext() on
every tick, leading to uneccesary CPU overhead.
This commit fixes xTaskIncrementTick() in the following ways:
- Clearly mark IDF additions in xTaskIncrementTick()
- Moved esp_vApplicationTickHook() to be called direclty in xPortSysTickHandler() in order to
simplify xTaskIncrementTick().
- Only core 0 calls xTaskIncrementTick() in order to simplify the function's logic. Core 0 is
solely responsible for managing xTickCount and xPendedTicks
- All other cores call xTaskIncrementTickOtherCores() instead which is a simplified version of
xTaskIncrementTick() and handles the following:
- Check if core 0 has unblocked a higher priority task to run
- Check if the current core requires time slicing
- Call vApplicationTickHook()
FreeRTOS synchronization primitives (e.g., queues, eventgroups) use various event lists (i.e., task lists) to track what
tasks are blocked on a current primitive. Usually these event lists are accessed via one of the event lists functions
(such as vTask[PlaceOn|RemoveFrom]UnorderedEventList()), which in turn ensure that the global task list spinlock
(xTaskQueueMutex) is taken when accessing these lists.
However, some functions in event_groups.c manually traverse their event lists. Thus if a tick interrupt occurs on
another core during traversal and that tick interrupt unblocks a task on the event list being traversed, the event list
will be corrupted.
This commit modifies the following event_groups.c functions so that they take the global task list lock before
traversing their event list.
- xEventGroupSetBits()
- vEventGroupDelete()
This commit refactors the FreeRTOS configuration headers as follows:
- Layout is now similar to FreeRTOSConfig.h found in other upstream demos
- Separate out Vanilla FreeRTOS configurations and ESP-IDF additions
- Move/remove some irrelevant/unused macros and configurations
This commit does the following:
- Adds SPDX license identifiers to FreeRTOS sources. Remove those FreeRTOS sources from
the copyright ignore list.
- Update xtensa port files to match FreeRTOS v10.4.3. Added SPDX license identifiers
to the port files.
- Fixed some improperly licensed files
- Removed portbenchmark.h from RISC-V port
This commit removes the portmacro.h include from task.h as portmacro.h
gets pulled in via FreeRTOS.h. This aligns with upstream FreeRTOS code.
Signed-off-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
This commit updates the handles for the timer, task and event_group
modules to struct type. This matches upstream freertos source.
Signed-off-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
The following changes have been made:
1. All FreeRTOS kernel source files are now placed in the
freertos/FreeRTOS-Kernel folder to match with the upstream folder structure.
2. All kernel include files are now placed in freertos/FreeRTOS-Kernel/include.
3. All port files are now placed in freertos/FreeRTOS-Kernel/portable.
4. All additions/customizations are placed in freertos/esp_additions.
5. All other miscellaneous files (README, License files etc.) are moved to
freertos/FreeRTOS-Kernel folder to match with the upstream.
6. Updated esp-cryptoauthlib to latest commit to resolve FreeRTOS
include dependencies.
Signed-off-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
