* Fix support for stepping maximum number of ticks
This commit fixes support for tickless implementations that call
vTaskStepTick() with the maximum number of allowed ticks to step.
vTaskStepTick()
---------------
Function vTaskStepTick() provides a way for the tickless idle
implementation to account for ticks that elapse during tickless idle.
The maximum number of stepped ticks allowed is the number passed to
portSUPPRESS_TICKS_AND_SLEEP(). It is the number of ticks between
xTickCount and xNextTaskUnblockTime.
vTaskStepTick() is specifically intended for use with tickless idle,
so it always executes with the scheduler disabled. For reference,
compare it with the more general function xTaskCatchUpTicks().
Without this Change
-------------------
Prior to this commit, if a task is supposed to wake at xTickCount ==
0xFFFFFFFF, then when tickless idle ends, function vTaskStepTick()
sets the tick to 0xFFFFFFFF but the task remains on the delayed list
because xTaskIncrementTick() does not execute. One tick later,
xTaskIncrementTick() executes because it's time to increment xTickCount
to 0x00000000. An assertion failure occurs in
taskSWITCH_DELAYED_LISTS() because the delayed task list is not
empty. Other examples of valling vTaskStepTick() with the maximum
allowed number of ticks merely result in a task waking one tick late.
Default Tickless Implementations
--------------------------------
Note that the default tickless implementations never pass the maximum
allowed value to vTaskStepTick(). The default implementations use the
tick interrupt to finish the sleep and allow that one tick to be
counted normally via the tick ISR and xTaskIncrementTick().
* Protect xPendedTicks with critical section
Function xTaskIncrementTick() increments xPendedTicks when the
scheduler is disabled. That function typically executes inside the tick
ISR. So code in xTaskCatchUpTicks() must mask interrupts when modifying
xPendedTicks.
* uncrustify tasks.c
* Update tasks.c
Style changes only - added comment and indentation to the two modified files.
* uncrustify
* Add test coverage for new conditional
* Add typecast
Co-authored-by: Cobus van Eeden <35851496+cobusve@users.noreply.github.com>
Co-authored-by: Joseph Julicher <jjulicher@mac.com>
Co-authored-by: RichardBarry <3073890+RichardBarry@users.noreply.github.com>
* uncrustify with github workflows
* Fix find expression
* Add uncrustify configuration file
* Uncrustify some files
* uncrustify some more files
* uncrustify more files
* Fix whitespace at end of lines
Co-authored-by: Cobus van Eeden <35851496+cobusve@users.noreply.github.com>
* Introduce configRUN_TIME_COUNTER_TYPE which enables developers to define the type used to hold run time statistic counters. Defaults to uint32_t for backward compatibility. #define configRUN_TIME_COUNTER_TYPE to a type (for example, uint64_t) in FreeRTOSConfig.h to override the default.
Introduce ulTaskGetIdleRunTimePercent() to complement the pre-existing ulTaskGetIdleRunTimeCounter(). Whereas the pre-existing function returns the raw run time counter value, the new function returns the percentage of the entire run time consumed by the idle task. Note the amount of idle time is only a good measure of the slack time in a system if there are no other tasks executing at the idle priority, tickless
idle is not used, and configIDLE_SHOULD_YIELD is set to 0.
* Add ultaskgetidleruntimepercent to lexicon.txt.
* Update History file.
Add the MPU version of ulTaskGetIdleRunTimePercent().
* Update include/FreeRTOS.h to correct comment as per aggarg@ suggestion.
* Fix alignment in mpu_wrappers.h.
Commit changes to mpu_prototypes.h which were missed from the original commit.
* updated history.txt for 10.4.4
* Update the release date in History.txt
* added link to SMP branch to History.txt
* Added comment explaining the + in the version string
* corrected typos in the + comment
Co-authored-by: alfred gedeon <28123637+alfred2g@users.noreply.github.com>
Co-authored-by: Paul Bartell <pbartell@amazon.com>
This PR:
Changes the INCLUDE_vTaskDelayUntil compile time constant to INCLUDE_xTaskDelayUntil.
Updates FreeRTOS.h to ensure backward compatibility for projects that already have INCLUDE_vTaskDelayUntil defined.
Updates the MPU prototypes, wrapper and implementation to use the updated xTaskDelayUntil() function.
Tests to be checked into the FreeRTOS/FreeRTOS repository after this PR.
* FreeRTOS Kernel Spelling Update
* Added spell check to kernel repository.
* Fixed small spelling errors in various kernel source files.
* Added documentation for spellcheck.
Note: Only kernel files are checked for spelling, and portable files are ignored.
* Style: make freertos.org = FreeRTOS.org also add https
* Style: Fix freertos into FreeRTOS
* Style: Fix freertos into FreeRTOS
Co-authored-by: Alfred Gedeon <gedeonag@amazon.com>
* Style: Change FreeRTOS websites in comments
* Style: Change freertos to FreeRTOS in comments
* Style: Remove broken link
Co-authored-by: Alfred Gedeon <gedeonag@amazon.com>
* Removing StackMacros.h
* Moving 4 Function Prototypes out of the C files into the headers
* Revert "Removing StackMacros.h"
This reverts commit cdd8307817.
Description
Before this change each task had a single direct to task notification value and state as described here: https://www.FreeRTOS.org/RTOS-task-notifications.html. After this change each task has an array of task notifications, so more than one task notification value and state per task. The new FreeRTOSConfig.h compile time constant configTASK_NOTIFICATION_ARRAY_ENTRIES sets the number of indexes in the array.
Each notification within the array operates independently - a task can only block on one notification within the array at a time and will not be unblocked by a notification sent to any other array index.
Task notifications were introduced as a light weight method for peripheral drivers to pass data and events to tasks without the need for an intermediary object such as a semaphore - for example, to unblock a task from an ISR when the operation of a peripheral completed. That use case only requires a single notification value. Their popularity and resultant expanded use cases have since made the single value a limitation - especially as FreeRTOS stream and message buffers themselves use the notification mechanism. This change resolves that limitation. Stream and message buffers still use the task notification at array index 0, but now application writers can avoid any conflict that might have with their own use of task notifications by using notifications at array indexes other than 0.
The pre-existing task notification API functions work in a backward compatible way by always using the task notification at array index 0. For each such function there is now an equivalent that is postfixed "Indexed" and takes an additional parameter to specify which index within the array it should operate upon. For example, xTaskNotify() is the original that only operates on array index 0. xTaskNotifyIndexed() is the new function that can operate on any array index.
Test Steps
The update is tested using the Win32 demo (PR to be created in the FreeRTOS/FreeRTOS github repo), which has been updated to build and run a new test file FreeRTOS/Demo/Common/Minimal/TaskNotifyArray.c. The tests in that file are in addition to, not a replacement for those in FreeRTOS/Demo/Common/Minimal/TaskNotify.c.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Move the prototype and documentation for xTaskCatchUpTicks() into the correct place in the task.h header file (in the public documentation from the private documentation).
Rename the variable that holds the return value in xTaskCatchUpTicks() to more accurately represent its meaning.
Gaurav-Aggarwal-AWS
Muneeb Ahmed
Jeff Tenney
Joseph Julicher
Pramith K V
prplz
Zim Kalinowski
alfred gedeon
Tobias Nießen
swaldhoer
RichardBarry
paulbartell
Paul Bartell
gomonovych
nazar01
Evgeny Ermakov
Cobus van Eeden
David Chalco
alfred gedeon
Spacefish
David Chalco
Ravishankar Bhagavandas
Carl Lundin
Alfred Gedeon
RichardBarry
Yuhui.Zheng