FreeRTOS Task States and Switching: A Comprehensive Guide

EEWORLD

Electronic News Sharp Interpretation

Technical Dry Goods Updated Daily

Recommended by: cruelfox If you are also willing to become an EEWorld WeChat

Recommender, please participate: EEWorld WeChat is in your hands, recommend casually to earn red envelopes!

FreeRTOS tasks have the following states:

Running	Running
Ready	Ready
Blocked	Blocked
Suspended	Suspended

Except for the running state, all other states are collectively referred to as non-running states. Since FreeRTOS is designed for a single CPU system, at any moment, only one task can be in the running state, even if it seems that multiple tasks are running simultaneously—this is just the effect of multiple tasks switching continuously. When a task switches from the running state to a non-running state, the execution context—CPU registers are saved in the task’s private stack; upon returning to the running state, the saved registers are restored from the stack. This is the most fundamental function of task scheduling.

Ready Tasks

The ready state of a FreeRTOS task indicates that the task is currently not being executed but can be executed at any time. When the next task switch opportunity arises, FreeRTOS will select the task with the highest priority from the list of ready tasks and switch it to the running state.

The priority of a task is an attribute of the task, represented by an integer in FreeRTOS, with the lowest priority being 0, and the highest being the value defined by the configMAX_PRIORITIES macro minus 1. When creating a task, a priority must be specified, and it can also be changed later using the vTaskPrioritySet() function. The significance of the priority is that when a task is in the ready state, it will not get a chance to execute as long as there are tasks with higher priorities also in the ready state.

When two or more tasks with the same priority are in the ready state, they will take turns getting execution opportunities (but there is no guarantee that the execution time will be evenly distributed), and the system will not favor any one of them.

Task Switching Timing

Task switching in FreeRTOS will definitely occur in the following situations:(A) A running task calls vTaskSuspend() to suspend itself. (B) A running task calls a delay function, requesting to wait for a period of time before executing again. (C) A running task needs to wait for a synchronization event that has not yet occurred.

Because the current task actively pauses execution, FreeRTOS needs to switch it to a suspended or blocked state, and then select the highest priority task from the list of ready tasks to execute. If there are no other tasks to execute, it will also execute the system’s built-in Idle task with the lowest priority. There is also a special case: (D) A running task calls taskYIELD() to actively request a task switch.

At this point, if there are tasks in the ready list with the same or higher priority, a task switch will occur; otherwise, the current task will continue execution. If configUSE_PREEMPTION=1 is configured in FreeRTOS, then preemptive task scheduling will occur. The meaning of preemption is that when a newly added task (including new tasks, tasks restored from suspended state, and tasks exiting from blocked state) has a higher priority than the currently running task, it will immediately switch to that higher priority task for execution. The previously running task is unaware of when its execution was paused, hence it is called “preempted”.

Preemptive scheduling ensures that the highest priority task is immediately allocated processor resources once its running conditions are met. However, if there is more than one highest priority task, by default, they will not preempt each other unless configUSE_TIME_SLICING=1 is also configured, allowing FreeRTOS to manage time slicing. When time slicing is enabled, ready tasks of the same priority will execute in turns, with each task executing for a fixed period of time, essentially distributing processor resources evenly.

In summary, under preemptive scheduling, the timing for task switching includes:(E) A running task is preempted by a higher priority task. (F) A running task executes to the end of a time slice and is preempted by a task of the same priority.Using an example from the manual, without preemptive scheduling, it looks like this: Task3 does not block and will only switch to the already ready Task1 and Task2 if it voluntarily relinquishes control.

Whereas preemptive scheduling looks like this: it always immediately schedules to a higher priority ready task.

Enabling time-slice round-robin scheduling for tasks of the same priority: Task2 and Idle task are both of the lowest priority, executing in turns, switching at the end of time slices.

Implementation of Task Switching

Let’s analyze the implementation details, starting with a simple one: the vTaskSuspend() function, which adjusts a task’s state to suspended.

1. void vTaskSuspend( TaskHandle_t xTaskToSuspend )

2. {

3. TCB_t *pxTCB;

4. taskENTER_CRITICAL();

5. pxTCB = prvGetTCBFromHandle( xTaskToSuspend );

6. if( uxListRemove( &( pxTCB->xStateListItem ) ) == ( UBaseType_t ) 0 )

7. {

8. taskRESET_READY_PRIORITY( pxTCB->uxPriority );

9. }

10. if( listLIST_ITEM_CONTAINER( &( pxTCB->xEventListItem ) ) != NULL )

11. {

12. ( void ) uxListRemove( &( pxTCB->xEventListItem ) );

13. }

14. vListInsertEnd( &xSuspendedTaskList, &( pxTCB->xStateListItem ) );

15. taskEXIT_CRITICAL();

16. if( xSchedulerRunning != pdFALSE )

17. {

18. taskENTER_CRITICAL();

19. prvResetNextTaskUnblockTime();

20. taskEXIT_CRITICAL();

21. }

22. if( pxTCB == pxCurrentTCB )

23. {

24. if( xSchedulerRunning != pdFALSE )

25. {

26. portYIELD_WITHIN_API();

27. }

28. else

29. {

30. if( listCURRENT_LIST_LENGTH( &xSuspendedTaskList ) == uxCurrentNumberOfTasks )

31. {

32. pxCurrentTCB = NULL;

33. }

34. else

35. {

36. vTaskSwitchContext();

37. }

38. }

39. }

40. }

This function has three main parts: the first part removes the task’s TCB structure member xStateListItem from its belonging state list, then inserts it into the suspended task list; and removes the xEventListItem member from its belonging list. The second part is to execute prvResetNextTaskUnblockTime() if the scheduler is running. The third part is to perform task scheduling: portYIELD_WITHIN_API() or vTaskSwitchContext() if the scheduler is not running to switch to a non-suspended task.

Ignoring the critical section operations taskENTER_CRITICAL() and taskEXIT_CRITICAL(), it is a bit strange that uxListRemove() only requires one parameter; this needs to be checked in list.c and list.h to understand that FreeRTOS’s list is implemented using a doubly linked list data structure: from the xStateListItem list member, the entire list can be indexed. When the task’s belonging state list is empty, taskRESET_READY_PRIORITY() needs to be executed to reset the ready state of that priority level? It is hard to understand, so we have to trace back the code… It turns out that each priority has its own ready task list, rather than all ready tasks using one list. The following lists are defined globally in tasks.c:

1. /* Lists for ready and blocked tasks. ——————–*/

2. PRIVILEGED_DATA static List_t pxReadyTasksLists[ configMAX_PRIORITIES ];

3. PRIVILEGED_DATA static List_t xDelayedTaskList1;

4. PRIVILEGED_DATA static List_t xDelayedTaskList2;

5. PRIVILEGED_DATA static List_t * volatile pxDelayedTaskList;

6. PRIVILEGED_DATA static List_t * volatile pxOverflowDelayedTaskList;

7. PRIVILEGED_DATA static List_t xPendingReadyList;

It can be inferred that FreeRTOS tasks must be in some list (running tasks are in the ready list); when task scheduling occurs, the list needs to be adjusted.

The second step of vTastSuspend() is to reset the global variable xNextTaskUnblockTime because the suspended task may be in a blocking state waiting for a delay, and its influence needs to be excluded.

The third step is to perform task scheduling, which is implemented by the portYIELD() function through the scheduler (otherwise, the scheduler is not running… this will be analyzed later). The portYIELD() function for ARM Cortex-m3 platform is implemented as follows in portmacro.h:

1. #define portYIELD() \

2. { \

3. portNVIC_INT_CTRL_REG = portNVIC_PENDSVSET_BIT; \

4. __asm volatile( “dsb” ); \

5. __asm volatile( “isb” ); \

6. }

This macro sets the PendSV state bit, which will trigger a PendSV exception, and then the task switch is implemented in the PendSV ISR handler. It can be boldly speculated that FreeRTOS uses PendSV exceptions to perform task switching. Continuing to analyze this handler, it is an assembly-implemented function in port.c:

1. void xPortPendSVHandler( void )

2. {

3. __asm volatile (

4. ” mrs r0, psp \n”

5. ” isb \n”

6. ” ldr r3, pxCurrentTCBConst \n”

7. ” ldr r2, [r3] \n”

8. ” stmdb r0!, {r4-r11} \n”

9. ” str r0, [r2] \n”

10. ” stmdb sp!, {r3, r14} \n”

11. ” mov r0, %0 \n”

12. ” msr basepri, r0 \n”

13. ” bl vTaskSwitchContext \n”

14. ” mov r0, #0 \n”

15. ” msr basepri, r0 \n”

16. ” ldmia sp!, {r3, r14} \n”

17. ” ldr r1, [r3] \n”

18. ” ldr r0, [r1] \n”

19. ” ldmia r0!, {r4-r11} \n”

20. ” msr psp, r0 \n”

21. ” isb \n”

22. ” bx r14 \n”

23. ” .align 4 \n”

24. “pxCurrentTCBConst: .word pxCurrentTCB \n”

25. ::”i”(configMAX_SYSCALL_INTERRUPT_PRIORITY) );

26. }

Since the PSP stack saved 8 registers before entering the interrupt: r0, r1, r2, r3, r12, LR, PC, xPSR, we can safely use r0 to r3. First, the current task’s TCB address is read into r2, the registers r4 to r11 are saved to the task’s stack, and then the new task stack top (which is the r0 register) is saved in the TCB (the first member of the TCB is the stack top). Next, the vTaskSwitchContext() function is called to switch context, and then the current task’s TCB address is read into r1, the task stack top is read from the TCB, the registers are popped from the stack, the PSP stack register is set, and finally, the exception handler exits.

Because the PSP register has been changed, the stack before entering the exception and the stack after exiting the exception belong to different tasks. For a task, calling the portYIELD() function and returning seems as if nothing has changed. If the vTaskSwitchContext() function does nothing, then the above exception handling has not performed any substantive operations and would still return the current task.

Let’s see how context switching is implemented: actually, the key operation is this:taskSELECT_HIGHEST_PRIORITY_TASK();This is also a macro, defined as follows:

1. {

2. UBaseType_t uxTopPriority = uxTopReadyPriority;

3. while( listLIST_IS_EMPTY( &( pxReadyTasksLists[ uxTopPriority ] ) ) )

4. {

5. –uxTopPriority;

6. }

7. listGET_OWNER_OF_NEXT_ENTRY( pxCurrentTCB, &( pxReadyTasksLists[ uxTopPriority ] ) );

8. uxTopReadyPriority = uxTopPriority;

9. }

It is not difficult to understand that it starts searching from the highest priority down until it finds a ready task list that is not empty, selects a task from it, sets the current TCB address to its TCB address, and then saves the global ready state priority. Therefore, the vTaskSwitchContext() function mainly selects the task to be executed and sets the current global variable pxCurrentTCB.　　

How Does Time Slicing Work?

Since time slicing is needed, hardware timer interrupt support must be available. FreeRTOS calls this interrupt the tick interrupt, which is implemented with a timer that is platform-dependent. After checking the source code, I confirmed that both ARM Cortex-m0/m3 use the Systick Timer, which is a timer provided by the ARM core rather than a timer device on the APB bus, thus fully utilizing hardware while being compatible with different manufacturers’ MCUs.

The timer interrupt function is relatively simple

1. void xPortSysTickHandler( void )

2. {

3. portDISABLE_INTERRUPTS();

4. {

5. if( xTaskIncrementTick() != pdFALSE )

6. {

7. portNVIC_INT_CTRL_REG = portNVIC_PENDSVSET_BIT;

8. }

9. }

10. portENABLE_INTERRUPTS();

11. }

The main task is to call xTaskIncrementTick() for counting and determine whether a task switch is needed. The situations where a switch is needed include the round-robin execution of same-priority ready tasks, as well as when functions such as xTaskDelay() request a delay until expiration, and also when waiting for an event timeout. The details of the last two situations, which are in the DelayedTaskList list, I will not elaborate on here.

We sincerely invite you to recommend good articles for EEWorld WeChat, and welcome to participate in

EEWorld WeChat is in your hands, recommend casually to earn red envelopes activity

Recommended Reading

Dry Goods | FreeRTOS Study Notes — Application Scenarios

Dry Goods | FreeRTOS Study Notes — Stack (The Key to Task Switching)

Dry Goods | Analysis of the Causes and Solutions of Inductor Whining

Dry Goods | How to Draw Circuit Symbols Simply and Clearly?

Dry Goods | Discussion on Sine Oscillator Circuit (Part One)

Dry Goods | Discussion on Sine Oscillator Circuit (Part Two)

Dry Goods | Discussion on Sine Oscillator Circuit (Part Three)