This commit refactors some of the thread safety convenience macros by removing
some repeated definitions and keeping them all in "freertos_idf_additions_priv.h"
This commit removes the v10.4.3 kernel files in prepartion for upgrading to
v10.5.1.
- Portable files still remain
- Added as a separate commit to preserve commit history
- The following IDF API additions are moved to freertos_tasks_c_additions.h
(implementation) and freertos_idf_additions_priv.h (declaration) as APIs are
private. This reduces the source code difference from upstream.
- prvENTER_CRITICAL_OR_SUSPEND_ALL()
- prvEXIT_CRITICAL_OR_RESUME_ALL()
- prvENTER_CRITICAL_OR_MASK_ISR()
- prvEXIT_CRITICAL_OR_UNMASK_ISR()
- vTaskTakeKernelLock()
- vTaskReleaseKernelLock()
- Rename vTask[Take/Release]KernelLock() to prv[Take/Release]KernelLock() to
indicate that the this API is private.
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 removes the updates the usage of queue locks in IDF FreeRTOS
Queue locks are present in Vanilla FreeRTOS to ensure that queue functions
behave deterministicly in critical sections (i.e., no walking linked lists
while interrupts are disabled). However, currently in IDF FreeRTOS...
- When configNUM_CORES > 1, IDF FreeRTOS drops the determinism requirement.
Thus, queue functions could be simplified if queue locks were not used at all
(and have a queue function do everything inside the same critical section).
- When configNUM_CORES == 1, the current queue implementation in IDF FreeRTOS
does not meet the determinism requirements, as critical sections are used
(instead of scheduler suspension) when locking/unlocking the queues.
There, this commit updates multiple queue functions so that
- When configNUM_CORES > 1
- Queue locks are no longer used. All actions are done within the same
critical section.
- Affected queue functions now need 40% less CPU clock cycles when blocking
- When configNUM_CORES = 1
- Queue locks are still used.
- Vanilla behavior of suspending the scheduler is restored when locking
the queue. Thus queue fucntions are now deterministic and have the same
behavior as Vanilla FreeRTOS.
- Affected queue functions now takes 36% more CPU clock cycles when
blocking (due to the scheduler suspension/resumption).
This commit synchronizes multiple functions in queue.c with upstream v10.4.3.
Multi-core modifications are then reapplied to these functions. The following
functions were modified:
prvNotifyQueueSetContainer()
xQueueGenericCreateStatic()
xQueueGenericCreate()
xQueueGetMutexHolder()
xQueueCreateCountingSemaphoreStatic()
xQueueCreateCountingSemaphore()
xQueueGenericSend()
xQueueGenericSendFromISR()
xQueueReceiveFromISR()
uxQueueMessagesWaiting()
prvUnlockQueue()
prvIsQueueFull()
xQueueAddToSet()
xQueueRemoveFromSet()
prvNotifyQueueSetContainer()
Note: The SEGGER_SYSVIEW traceQUEUE_SEND() macro was updated as the
xCopyPosition argument is no longer available in scenarios where the
macro is called.
This commit synchronizes multiple functions in queue.c with upstream v10.4.3.
Multi-core modifications are then reapplied to these functions. The following
functions were modified:
prvNotifyQueueSetContainer()
xQueueGenericCreateStatic()
xQueueGenericCreate()
xQueueGetMutexHolder()
xQueueCreateCountingSemaphoreStatic()
xQueueCreateCountingSemaphore()
xQueueGenericSend()
xQueueGenericSendFromISR()
xQueueReceiveFromISR()
uxQueueMessagesWaiting()
prvUnlockQueue()
prvIsQueueFull()
xQueueAddToSet()
xQueueRemoveFromSet()
prvNotifyQueueSetContainer()
Note: The SEGGER_SYSVIEW traceQUEUE_SEND() macro was updated as the
xCopyPosition argument is no longer available in scenarios where the
macro is called.
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.
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
Add TRY_ENTRY_CRITICAL() API to all for timeouts when entering critical sections.
The following port API were added:
- portTRY_ENTER_CRITICAL()
- portTRY_ENTER_CRITICAL_ISR()
- portTRY_ENTER_CRITICAL_SAFE()
Deprecated legacy spinlock API in favor of spinlock.h. The following API were deprecated:
- vPortCPUInitializeMutex()
- vPortCPUAcquireMutex()
- vPortCPUAcquireMutexTimeout()
- vPortCPUReleaseMutex()
Other Changes:
- Added portMUX_INITIALIZE() to replace vPortCPUInitializeMutex()
- The assembly of the critical section functions ends up being about 50 instructions longer,
thus the spinlock test pass threshold had to be increased to account for the extra runtime.
Closes https://github.com/espressif/esp-idf/issues/5301
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>
