FreeRTOS Version 9
See the change history for full information
on the differences between the final FreeRTOS V9.0.0 release and its preceding
release candidates – especially relating to the prototype of the new
xTaskCreateStatic() API function.
FreeRTOS V9 Highlights
FreeRTOS V9.x.x is a drop-in compatible replacement for FreeRTOS V8.x.x that contains
new features, enhancements, and new ports.
Completely Statically Allocated Systems
Two new configuration constants that allow FreeRTOS to optionally be used
without the necessity for any
dynamic memory allocation have been introduced.
See the description of the
configSUPPORT_DYNAMIC_ALLOCATION constants for more information – noting in
particular the two callback functions that need to be provided by the application
writer when configSUPPORT_STATIC_ALLOCATION is set to 1.
The Win32 demo located in the /FreeRTOS/demo/WIN32-MSVC-Static-Allocation-Only
directory is provided as a reference of how to create a project that does not
include a FreeRTOS heap at all, and therefore
guarantee no dynamic memory allocation is being performed.
Creating Tasks and Other RTOS Objects Using Statically Allocated RAM
[Also see the Static Vs Dynamic
Memory Allocation page]
Each [object]Create() RTOS API function now has a new [object]CreateStatic()
equivalent. The simpler Create() function will use dynamic
memory allocation, and the more powerful CreateStatic() function will
use memory passed into the function by the application writer. This allows
tasks, queues, semaphores, software timers, mutexes and event groups to be created
using either statically allocated or dynamically allocated memory.
configSUPPORT_DYNAMIC_ALLOCATION must be set to 1 in FreeRTOSConfig.h (or left
undefined, as it defaults to 1) for the “dynamic” versions of the create functions
to be available.
configSUPPORT_STATIC_ALLOCATION must be set to 1 in FreeRTOSConfig.h for the “static”
versions of the create functions to be available – also note the requirement for
the application writer to provide two callback functions when
is set to 1.
standard demo task is provided to demonstrate how the new CreateStatic() functions are used.
Forcing an RTOS Task To Leave the Blocked State
RTOS tasks enter the Blocked state to ensure they do not use any processing time
while they are waiting for a time to pass, or an event to occur. For example, if
a task calls vTaskDelay( 100 ) it will
enter the Blocked state for 100 ticks. As
another example, if a task calls xSemaphoreTake( xSemaphore, 50 )
then it will enter the Blocked state until either the semaphore becomes available,
or it times out because 50 ticks pass without the semaphore becoming available.
[Note: in a real application it is better to use the pdMS_TO_TICKS() macro to
specify time in millisconds rather than ticks].
The new xTaskAbortDelay() RTOS API function makes it possible for one task to
force another task out of the Blocked state immediately. This is desirable in
situations where an event occurring elsewhere in the system means the task in
the Blocked state should stop waiting for an event, or the task in the Blocked
state has something more urgent to do.
INCLUDE_xTaskAbortDelay must be set to 1 in FreeRTOSConfig.h for the
xTaskAbortDelay() function to be available.
standard demo task is provided to demonstrate how xTaskAbortDelay() is used.
In FreeRTOS versions prior to version 9, whenever a task was deleted, the memory
allocated by FreeRTOS to the task is freed by the Idle task. In FreeRTOS version 9,
if one task deletes another task, then the memory allocated by FreeRTOS to the
deleted task is freed immediately. However, if a task deletes itself, then the
memory allocated by FreeRTOS to the task is still freed by the Idle task.
Note that, in all cases, it is only the stack and task control block (TCB) allocated
to the task by the RTOS that get freed automatically.
Obtaining a Task Handle from the Task Name
The new xTaskGetHandle() API function
obtains a task handle from the task’s human readable text name.
xTaskGetHandle() uses multiple string compare operations, so it is
recommended that it is called only once per task. The handle returned by
xTaskGetHandle() can then be stored locally for later re-use.
See the change history for more detailed information.
Updates necessary to allow FreeRTOS to run on 64-bit architectures.
Enhancements to the GCC ARM Cortex-A port layer relating to how the port
uses the floating point unit.
Update the ARM Cortex-M RTOS ports that use the memory protection using
Added vApplicationDaemonTaskStartupHook() which executes when the RTOS
daemon task (which used to be called the timer service task) starts
running. This is useful if the application includes initialisation code
that would benefit from executing after the scheduler has been started.
Added the pcQueueGetName() API function, which obtains the name of
a queue from the queue’s handle.
Tickless idling (for low power applications) can now also be used when
configUSE_PREEMPTION is 0.
If a task notification is used to unblock a task from an ISR, but the
xHigherPriorityTaskWoken parameter is not used, then pend a context switch
that will then occur during the next tick interrupt.
Heap_1.c and Heap_2.c now use the configAPPLICATION_ALLOCATED_HEAP
settings, which previously was only used by heap_4.c.
configAPPLICATION_ALLOCATED_HEAP allows the application writer to declare
the array that will be used as the FreeRTOS heap, and in-so-doing,
place the heap at a specific memory location.
The TaskStatus_t structure, which is used to obtain details of
a task, now includes the base address of the task’s stack.
Added the vTaskGetInfo() API function, which returns a TaskStatus_t
structure that contains information about a single task. Previously this
information could only be obtained for all the tasks at once, as an array
of TaskStatus_t structures.
Added the uxSemaphoreGetCount() API function.
Replicate previous Cortex-M4F and Cortex-M7 optimisations in some
Cortex-M3 port layers.
Multiple additional devices supported.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.