Select your cookie preferences

We use essential cookies and similar tools that are necessary to provide our site and services. We use performance cookies to collect anonymous statistics, so we can understand how customers use our site and make improvements. Essential cookies cannot be deactivated, but you can choose “Customize” or “Decline” to decline performance cookies.

If you agree, AWS and approved third parties will also use cookies to provide useful site features, remember your preferences, and display relevant content, including relevant advertising. To accept or decline all non-essential cookies, choose “Accept” or “Decline.” To make more detailed choices, choose “Customize.”

Updated May 2025

RTOS task notifications

Used As Light Weight Event Group

An event group is a set of binary flags (or bits), to each of which the application writer can assign a meaning. An RTOS task can enter the Blocked state to wait for one or more flags within the group to become active. The RTOS task does not consume any CPU time while it is in the Blocked state.

When a task notification is used in place of an event group the receiving task's notification value is used in place of the event group, bits within the receiving task's notification value are used as event flags, and the xTaskNotifyWait() API function is used in place of the event group's xEventGroupWaitBits() API function.

Likewise, bits are set using the xTaskNotify() and xTaskNotifyFromISR() API functions (with their eAction parameter set to eSetBits) in place of the xEventGroupSetBits() and xEventGroupSetBitsFromISR() functions respectively.

xTaskNotifyFromISR() has significant performance benefits when compared to xEventGroupSetBitsFromISR() because xTaskNotifyFromISR() executes entirely in the ISR, whereas xEventGroupSetBitsFromISR() must defer some processing to the RTOS daemon task.

Unlike when using an event group the receiving task cannot specify that it only wants to leave the Blocked state when a combination of bits are active at the same time. Instead the task is unblocked when any bit becomes active, and must test for bit combinations itself.

See the example below:

1/* This example demonstrates a single RTOS task being used to process
2 events that originate from two separate interrupt service routines -
3 a transmit interrupt and a receive interrupt. Many peripherals will
4 use the same handler for both, in which case the peripheral's
5 interrupt status register can simply be bitwise ORed with the
6 receiving task's notification value.
7
8 First, bits are defined to represent each interrupt source. */
9#define TX_BIT 0x01
10#define RX_BIT 0x02
11
12/* The handle of the task that will receive notifications from the
13 interrupts. The handle was obtained when the task was created. */
14static TaskHandle_t xHandlingTask;
15
16/*-----------------------------------------------------------*/
17
18/* The implementation of the transmit interrupt service routine. */
19void vTxISR( void )
20{
21BaseType_t xHigherPriorityTaskWoken = pdFALSE;
22
23 /* Clear the interrupt source. */
24 prvClearInterrupt();
25
26 /* Notify the task that the transmission is complete by setting the TX_BIT
27 in the task's notification value. */
28 xTaskNotifyFromISR( xHandlingTask,
29 TX_BIT,
30 eSetBits,
31 &xHigherPriorityTaskWoken );
32
33 /* If xHigherPriorityTaskWoken is now set to pdTRUE then a context switch
34 should be performed to ensure the interrupt returns directly to the highest
35 priority task. The macro used for this purpose is dependent on the port in
36 use and may be called portEND_SWITCHING_ISR(). */
37 portYIELD_FROM_ISR( xHigherPriorityTaskWoken );
38}
39/*-----------------------------------------------------------*/
40
41/* The implementation of the receive interrupt service routine is identical
42 except for the bit that gets set in the receiving task's notification value. */
43void vRxISR( void )
44{
45BaseType_t xHigherPriorityTaskWoken = pdFALSE;
46
47 /* Clear the interrupt source. */
48 prvClearInterrupt();
49
50 /* Notify the task that the reception is complete by setting the RX\_BIT
51 in the task's notification value. */
52 xTaskNotifyFromISR( xHandlingTask,
53 RX_BIT,
54 eSetBits,
55 &xHigherPriorityTaskWoken );
56
57 /* If xHigherPriorityTaskWoken is now set to pdTRUE then a context switch
58 should be performed to ensure the interrupt returns directly to the highest
59 priority task. The macro used for this purpose is dependent on the port in
60 use and may be called portEND_SWITCHING_ISR(). */
61 portYIELD_FROM_ISR( xHigherPriorityTaskWoken );
62}
63/*-----------------------------------------------------------*/
64
65/* The implementation of the task that is notified by the interrupt service
66 routines. */
67static void prvHandlingTask( void *pvParameter )
68{
69const TickType_t xMaxBlockTime = pdMS_TO_TICKS( 500 );
70BaseType_t xResult;
71
72 for( ;; )
73 {
74 /* Wait to be notified of an interrupt. */
75 xResult = xTaskNotifyWait( pdFALSE, /* Don't clear bits on entry. */
76 ULONG_MAX, /* Clear all bits on exit. */
77 &ulNotifiedValue, /* Stores the notified value. */
78 xMaxBlockTime );
79
80 if( xResult == pdPASS )
81 {
82 /* A notification was received. See which bits were set. */
83 if( ( ulNotifiedValue & TX_BIT ) != 0 )
84 {
85 /* The TX ISR has set a bit. */
86 prvProcessTx();
87 }
88
89 if( ( ulNotifiedValue & RX_BIT ) != 0 )
90 {
91 /* The RX ISR has set a bit. */
92 prvProcessRx();
93 }
94 }
95 else
96 {
97 /* Did not receive a notification within the expected time. */
98 prvCheckForErrors();
99 }
100 }
101}