Simplifying Authenticated Cloud Connectivity for Any Device.
How Wi-Fi and Cellular connectivity modules with ExpressLink can help create secure cloud connected devices. See the blog post.
Designing an energy efficient and cloud-connected IoT solution with CoAP.
A client/server, request/response, UDP-based protocol for efficiency and cloud compatibility. See the blog post.
Introducing FreeRTOS Kernel version 11.0.0:
A Major Release with Symmetric Multiprocessing (SMP) Support. See the blog post.
FreeRTOS Roadmap and Code Contribution process.
The FreeRTOS roadmap and code contribution process are now published here and on GitHub. See the blog post.
OPC-UA over TSN with FreeRTOS.
A development project to give applications consistent access to hardware TSN capabilities. See the blog post.
FreeRTOS Version 9
Preamble
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
Backward Compatibility
FreeRTOS V9.x.x is a drop-in compatible replacement for FreeRTOS V8.x.x that contains
new features, enhancements, and new ports.
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.
For example:
xTaskCreate() will
dynamically allocate the memory necessary to
create a task. xTaskCreateStatic()
will not perform any dynamic memory allocation, and will instead use the
memory passed into the function using the function's parameters.
xQueueCreate() will dynamically allocate the
memory necessary to create a queue. xQueueCreateStatic()
will not perform any dynamic memory allocation, and will instead use the
memory passed into the function using the function's parameters.
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
configSUPPORT_STATIC_ALLOCATION
is set to 1.
The StaticAllocation.c
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.
The AbortDelay.c
standard demo task is provided to demonstrate how xTaskAbortDelay() is used.
Deleting Tasks
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.
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
(MPU).
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.
General refactoring.
Multiple additional devices supported.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.