Why tasks are the building blocks in FreeRTOS - Visual Breakdown

Concept Flow - Why tasks are the building blocks

Start FreeRTOS Scheduler

↓

Create Tasks

↓

Each Task Runs Independently

↓

Scheduler Switches Between Tasks

↓

Tasks Communicate and Synchronize

↓

System Performs Multiple Jobs Concurrently

This flow shows how FreeRTOS starts by creating tasks, each running independently, and the scheduler switches between them to perform multiple jobs at once.

Execution Sample

FreeRTOS

void Task1(void *pvParameters) {
  while(1) {
    // Do Task1 work
  }
}

void Task2(void *pvParameters) {
  while(1) {
    // Do Task2 work
  }
}

Two tasks run infinite loops doing their own work independently under FreeRTOS scheduler.

Execution Table

Step	Action	Task1 State	Task2 State	Scheduler Behavior
1	Start Scheduler	Ready	Ready	Scheduler starts and prepares tasks
2	Run Task1	Running	Ready	Scheduler runs Task1 first
3	Task1 does work	Running	Ready	Task1 executes its code
4	Switch to Task2	Ready	Running	Scheduler switches to Task2
5	Task2 does work	Ready	Running	Task2 executes its code
6	Switch back to Task1	Running	Ready	Scheduler switches back to Task1
7	Repeat switching	Running/Ready	Running/Ready	Tasks run concurrently by switching
8	System runs multiple tasks	Running/Ready	Running/Ready	Tasks are building blocks for multitasking

💡 FreeRTOS scheduler runs indefinitely switching between tasks to perform multitasking.

Variable Tracker

Variable	Start	After Step 2	After Step 4	After Step 6	Final
Task1 State	Ready	Running	Ready	Running	Running/Ready
Task2 State	Ready	Ready	Running	Ready	Running/Ready
Scheduler Behavior	Idle	Runs Task1	Switches to Task2	Switches to Task1	Switches tasks continuously

Key Moments - 3 Insights

Why does the scheduler switch between tasks instead of running one task fully first?

Because tasks run infinite loops, the scheduler must switch to give each task time to run, as shown in steps 4 and 6 in the execution_table.

Are tasks running at the same time or one after another?

Tasks appear to run at the same time by the scheduler switching quickly between them, not truly simultaneously, as seen in the alternating 'Running' states in the execution_table.

Why are tasks called building blocks in FreeRTOS?

Because each task does a part of the system's job independently and the scheduler combines them to do many jobs together, as summarized in step 8 of the execution_table.

Visual Quiz - 3 Questions

Look at the execution_table, what is Task1 state at Step 4?

A Ready

B Running

C Blocked

D Suspended

💡 Hint

Check the 'Task1 State' column at Step 4 in the execution_table.

At which step does the scheduler switch from Task1 to Task2?

A Step 2

B Step 4

C Step 3

D Step 5

💡 Hint

Look at the 'Scheduler Behavior' column to find when switching happens.

If Task2 never yields, how would the scheduler behavior change in the table?

A Scheduler keeps switching tasks normally

B Scheduler stops running Task2

C Scheduler runs Task2 continuously, Task1 stays Ready

D Both tasks run simultaneously

💡 Hint

Think about what happens if one task never stops running in a multitasking system.

Concept Snapshot

FreeRTOS uses tasks as independent units of work.
Each task runs in a loop and the scheduler switches between them.
This switching creates multitasking on a single CPU.
Tasks are the building blocks because they let the system do many jobs.
Scheduler manages task states: Running, Ready, Blocked.
Without tasks, multitasking is not possible.

Full Transcript

In FreeRTOS, tasks are the basic units that do work. The scheduler starts and creates tasks, each running its own infinite loop. The scheduler switches between tasks to give each a chance to run. This switching is what creates multitasking. Tasks are called building blocks because each does part of the system's job independently. The execution table shows how Task1 and Task2 alternate running states as the scheduler switches between them. This switching continues indefinitely, allowing the system to perform multiple jobs at once. Beginners often wonder why the scheduler switches tasks instead of running one fully; the answer is tasks run forever, so switching is needed. Also, tasks don't run truly simultaneously but appear to by fast switching. If a task never yields, the scheduler runs it continuously, blocking others. Understanding tasks and scheduler behavior is key to mastering FreeRTOS multitasking.

Practice

1. Why are tasks considered the building blocks in FreeRTOS?

easy

A. Because tasks store data permanently in memory.

B. Because tasks allow the program to run multiple jobs independently and smoothly.

C. Because tasks handle hardware interrupts directly.

D. Because tasks compile the program faster.

Solution

1. Step 1: Understand the role of tasks in FreeRTOS

   Tasks divide a program into small, independent jobs that can run at the same time.

2. Step 2: Recognize the benefit of tasks

   This division helps the device perform many things smoothly without waiting for one job to finish.

3. Final Answer:

   Because tasks allow the program to run multiple jobs independently and smoothly. -> Option B

4. Quick Check:

   Tasks = Independent jobs running smoothly [OK]

Hint: Tasks run jobs independently for smooth multitasking [OK]

Common Mistakes:

• Thinking tasks store data permanently
• Confusing tasks with interrupt handlers
• Believing tasks speed up compilation

2. Which of the following is the correct way to create a task in FreeRTOS?

easy

A. xTaskCreate(TaskFunction, "TaskName", StackSize, NULL, Priority, &TaskHandle);

B. CreateTask(TaskFunction, Priority, StackSize);

C. task_create(TaskFunction, StackSize, Priority);

D. StartTask(TaskFunction, "TaskName", Priority);

Solution

1. Step 1: Recall the FreeRTOS task creation function

   The correct function to create a task is xTaskCreate with parameters: function, name, stack size, parameters, priority, and handle.

2. Step 2: Compare options with correct syntax

   Only xTaskCreate(TaskFunction, "TaskName", StackSize, NULL, Priority, &TaskHandle); matches the exact syntax and parameter order of xTaskCreate.

3. Final Answer:

   xTaskCreate(TaskFunction, "TaskName", StackSize, NULL, Priority, &TaskHandle); -> Option A

4. Quick Check:

   Correct function and parameters = xTaskCreate(TaskFunction, "TaskName", StackSize, NULL, Priority, &TaskHandle); [OK]

Hint: Remember xTaskCreate with 6 parameters for tasks [OK]

Common Mistakes:

• Using wrong function names like CreateTask
• Mixing parameter order
• Omitting task handle parameter

3. What will be the output of the following FreeRTOS task code snippet?

void Task1(void *pvParameters) {
  for (;;) {
    printf("Task1 running\n");
    vTaskDelay(pdMS_TO_TICKS(1000));
  }
}

void Task2(void *pvParameters) {
  for (;;) {
    printf("Task2 running\n");
    vTaskDelay(pdMS_TO_TICKS(500));
  }
}

medium

A. Only Task1 will print because Task2 is blocked.

B. Both tasks print at the same time without delay.

C. Task2 will print once, then stop.

D. Task1 running every 1 second, Task2 running every 0.5 seconds, both printing alternately.

Solution

1. Step 1: Analyze the delay times in each task

   Task1 delays 1000 ms (1 second) between prints; Task2 delays 500 ms (0.5 seconds).

2. Step 2: Understand task scheduling

   Both tasks run independently and print their messages at their own intervals, so Task2 prints twice as often as Task1.

3. Final Answer:

   Task1 running every 1 second, Task2 running every 0.5 seconds, both printing alternately. -> Option D

4. Quick Check:

   Delays control print frequency = Task1 running every 1 second, Task2 running every 0.5 seconds, both printing alternately. [OK]

Hint: Check vTaskDelay times to predict print frequency [OK]

Common Mistakes:

• Assuming tasks block each other
• Thinking Task2 stops after one print
• Ignoring delays causing print timing

4. Identify the error in this FreeRTOS task creation code:

void vTaskCode(void *pvParameters) {
  while(1) {
    // Task code
  }
}

int main() {
  xTaskCreate(vTaskCode, "Task", 1000, NULL, 1, NULL);
  vTaskStartScheduler();
  return 0;
}

medium

A. Task handle parameter is NULL, so task cannot be managed later.

B. The task function should not have an infinite loop.

C. Stack size is too large and causes memory overflow.

D. vTaskStartScheduler() is called before creating the task.

Solution

1. Step 1: Check task creation parameters

   The last parameter is the task handle pointer; passing NULL means the task handle is not stored.

2. Step 2: Understand implications of NULL task handle

   Without a task handle, the program cannot control or delete the task later, which is usually needed.

3. Final Answer:

   Task handle parameter is NULL, so task cannot be managed later. -> Option A

4. Quick Check:

   Task handle NULL means no task control [OK]

Hint: Always provide a task handle pointer to manage tasks [OK]

Common Mistakes:

• Thinking infinite loops are wrong in tasks
• Believing stack size is always too large
• Assuming scheduler starts before task creation

5. You want to design a FreeRTOS application that reads sensor data, processes it, and updates a display. Why should you use separate tasks for each job?

hard

A. To avoid using queues or synchronization mechanisms.

B. To reduce the total memory used by combining jobs in one task.

C. To ensure each job runs independently and can be scheduled without blocking others.

D. To make the program run faster by running all jobs in a single loop.

Solution

1. Step 1: Understand task separation benefits

   Separating jobs into tasks allows each to run independently and be scheduled by FreeRTOS efficiently.

2. Step 2: Recognize multitasking advantages

   This prevents one job from blocking others, improving responsiveness and reliability.

3. Final Answer:

   To ensure each job runs independently and can be scheduled without blocking others. -> Option C

4. Quick Check:

   Separate tasks = independent, non-blocking jobs [OK]

Hint: Use separate tasks to avoid blocking and improve multitasking [OK]

Common Mistakes:

• Thinking combining jobs saves memory always
• Believing single loop is faster for multitasking
• Ignoring need for synchronization with multiple tasks