|
Description
Each RTOS task has a 32-bit notification value. An
RTOS task notification is an event sent
directly to a task that can unblock the receiving task, and
optionally update the receiving task's notification value.
Task notifications can update the receiving task's notification value in the
following ways:
-
Set the receiving task's notification value without overwriting a previous value
-
Overwrite the receiving task's notification value
-
Set one or more bits in the receiving task's notification value
-
Increment the receiving task's notification value
That flexibility allows task notifications to be used where previously it would
have been necessary to create a separate queue,
binary semaphore,
counting semaphore
or event group.
Unblocking an RTOS task with a direct notification is 45% faster
* and
uses less RAM than unblocking a task with a binary semaphore.
Notifications are sent using the xTaskNotify()
and xTaskNotifyGive() API functions (and their
interrupt safe equivalents),
and remain pending until the receiving RTOS task calls either of the
xTaskNotifyWait() or
ulTaskNotifyTake() API functions.
If the receiving RTOS task was already Blocked waiting for a notification when one
arrives the receiving RTOS task will be removed from the Blocked state and the
notification cleared.
RTOS task notification functionality is enabled by default, and can be excluded
from a build (saving 8 bytes per task) by setting configUSE_TASK_NOTIFICATIONS
to 0 in FreeRTOSConfig.h.
Performance Benefits and Usage Restrictions
Task notifications have both speed and RAM footprint advantages over other FreeRTOS
features that can be used to perform equivalent functionality. As would
be expected, these benefits require some use case limitations:
-
RTOS task notifications can only be used when there is only one task that
can be the recipient of the event. This condition is however met in the
majority of real world applications.
-
Only in the case where an RTOS task notification is used in place of
a queue; While a receiving task can wait for a notification in the
Blocked state (so not consuming any CPU time), a sending task cannot
wait in the Blocked state for a send to complete if the send cannot
complete immediately.
The related API is designed to allow RTOS task notifications to be used as a faster and
lighter weight alternative
to binary and
counting semaphores,
event groups and in some cases
queues (referred to in the documentation as a
mailbox as the queue length must equal 1). Links to documentation pages that
demonstrate how this is done can be found at the bottom of this page.
From this page:
*
Measured using the binary semaphore implementation from
FreeRTOS V8.1.2, compiled with GCC at -O2 optimisation, and without
configASSERT() defined. A 35% improvement can still be obtained using the improved
binary semaphore implementation found in FreeRTOS V8.2.0 and higher.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|
