Home FreeRTOS
Category:

FreeRTOS

FreeRTOS

Task Priorities Explained with Real Examples in FreeRTOS

by shedboy71
written by shedboy71

Task priorities are one of the first FreeRTOS concepts that seem simple at a glance but become much more important once you start building real applications. At the most basic level, a priority tells the scheduler which task should run first when more than one task is ready to execute. But in practice, priorities shape the entire behavior of a system. They affect responsiveness, timing, CPU usage, fairness, and even whether some tasks get enough time to run at all.

Beginners often assume priorities are just a way to label tasks as “important” or “not important.” That is only partly true. A priority is not a human description. It is a scheduling decision. If two ready tasks compete for CPU time, the scheduler uses priority to decide which one gets to run. That means a poor priority choice can make a system feel unstable even when the code itself is otherwise correct.

This article explains task priorities in a practical way, using clear examples to show how they affect real FreeRTOS behavior. The goal is not just to define priority levels, but to help you understand how to choose them sensibly.

What a task priority means

In FreeRTOS, each task has a numeric priority. Higher numbers represent higher priorities. When several tasks are ready to run, the scheduler chooses the highest-priority ready task.

That one rule explains a lot of RTOS behavior.

If a task with priority 3 is ready and a task with priority 1 is also ready, the priority 3 task runs first. The lower-priority task only runs when the higher-priority task blocks, delays, suspends itself, or otherwise stops being ready.

This means priority is directly tied to CPU access. A higher-priority task does not just get “more attention.” It can completely prevent a lower-priority task from running if it stays ready all the time.

That is why priorities must be assigned with care.

Ready, blocked, and running

To understand priorities, you also need to understand task states.

A task that is ready can run if the scheduler selects it.

A task that is blocked is waiting for something, such as time to pass, data to arrive in a queue, or a semaphore to become available.

A task that is running is the task currently using the CPU.

Priorities only matter among tasks that are ready. A blocked high-priority task does not compete with a ready low-priority task because the blocked task is not eligible to run yet.

This is an important point because many beginner misunderstandings come from imagining that higher-priority tasks always dominate. They dominate only when they are ready.

A very simple example

Imagine a system with two tasks:

  • LedTask at priority 1
  • SerialTask at priority 2

If both tasks are ready at the same time, SerialTask runs first because it has the higher priority.

A simple version might look like this:

void LedTask(void *pvParameters)
{
    for (;;)
    {
        toggle_led();
        vTaskDelay(pdMS_TO_TICKS(500));
    }
}

void SerialTask(void *pvParameters)
{
    for (;;)
    {
        printf("Status message\n");
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

In this example, both tasks spend most of their time blocked by vTaskDelay(). That means both get chances to run. The scheduler wakes them when their delays expire, and if both happen to become ready together, SerialTask will run first.

This is a healthy pattern. Each task does a bit of work, then blocks. Priorities matter, but they do not cause starvation because the tasks are cooperative in the sense that they regularly stop being ready.

Example: why a high-priority task can starve lower ones

Now consider a more dangerous design:

void HighTask(void *pvParameters)
{
    for (;;)
    {
        process_data();
    }
}

void LowTask(void *pvParameters)
{
    for (;;)
    {
        toggle_led();
        vTaskDelay(pdMS_TO_TICKS(500));
    }
}

Suppose HighTask has priority 3 and LowTask has priority 1.

HighTask never blocks, never delays, and never waits. It is always ready. That means the scheduler keeps choosing it. LowTask may never run at all.

This is one of the most important real lessons about priorities: a high-priority task that stays ready continuously can starve lower-priority tasks.

Beginners sometimes see this and think the scheduler is broken. It is not. It is doing exactly what the priorities say.

Equal-priority tasks

If two tasks have the same priority and both are ready, they can share CPU time according to the scheduler’s rules. In many FreeRTOS setups, equal-priority tasks can take turns through time slicing.

For example:

void TaskA(void *pvParameters)
{
    for (;;)
    {
        printf("A\n");
        vTaskDelay(pdMS_TO_TICKS(100));
    }
}

void TaskB(void *pvParameters)
{
    for (;;)
    {
        printf("B\n");
        vTaskDelay(pdMS_TO_TICKS(100));
    }
}

If both have the same priority, neither one automatically dominates the other just because of priority. Their timing and scheduler behavior determine how they alternate.

This is useful when tasks are of similar importance and you want them treated as peers.

But equal priority does not always mean equal real behavior. If one task blocks often and another stays ready longer, the task behavior will still differ. The scheduler can only choose among tasks that are actually ready.

Real example: sensor task, display task, and logger task

Consider a small embedded device with three jobs:

  • read a sensor every 50 milliseconds
  • update a display every 250 milliseconds
  • write debug logs over UART every 1 second

A sensible priority assignment might be:

  • SensorTask priority 3
  • DisplayTask priority 2
  • LoggerTask priority 1

Why?

The sensor task is most time-sensitive. If it is delayed too much, measurements may become inconsistent.

The display task matters, but a slight delay is usually acceptable.

The logger task is least important. If logs are delayed slightly, the system still works.

A sketch could look like this:

void SensorTask(void *pvParameters)
{
    for (;;)
    {
        read_sensor();
        vTaskDelay(pdMS_TO_TICKS(50));
    }
}

void DisplayTask(void *pvParameters)
{
    for (;;)
    {
        update_display();
        vTaskDelay(pdMS_TO_TICKS(250));
    }
}

void LoggerTask(void *pvParameters)
{
    for (;;)
    {
        write_log();
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

This is a good real-world example because it shows how priorities often reflect timing sensitivity, not just vague importance.

Real example: button response versus background processing

Imagine another system with two main functions:

  • respond immediately to a button press
  • calculate statistics in the background

You might use:

  • ButtonTask priority 4
  • StatsTask priority 1

Why?

If the button event must feel responsive to the user, the task handling it should be able to run quickly once the event occurs. Background statistics work can happen whenever CPU time is available.

Example:

void ButtonTask(void *pvParameters)
{
    for (;;)
    {
        if (xSemaphoreTake(buttonSemaphore, portMAX_DELAY) == pdTRUE)
        {
            handle_button_event();
        }
    }
}

void StatsTask(void *pvParameters)
{
    for (;;)
    {
        calculate_statistics();
        vTaskDelay(pdMS_TO_TICKS(200));
    }
}

This works well because ButtonTask is blocked most of the time, waiting on a semaphore. It only runs when needed, and when it does become ready, its higher priority allows a fast reaction.

That is a good use of high priority.

High priority should not mean heavy continuous work

A common mistake is assigning high priority to a large computational task because it feels “important.”

For example, suppose a developer writes:

void DataProcessingTask(void *pvParameters)
{
    for (;;)
    {
        run_large_algorithm();
    }
}

and gives it priority 5 because the algorithm seems critical.

This may be a bad design if the task never blocks. It can interfere with everything below it.

A better design might be:

  • keep the task at a more moderate priority
  • break the work into chunks
  • block on input data
  • yield CPU time naturally through queues, delays, or event waiting

In FreeRTOS, a task should often be high priority because it must respond quickly, not because it performs a lot of work.

That is an important distinction.

Priorities and blocking behavior work together

Priorities alone do not define a system. Blocking behavior matters just as much.

A low-priority task that is always ready may still use plenty of CPU if all higher-priority tasks spend most of their time blocked.

A high-priority task that only wakes briefly once per second may have very little overall CPU impact.

This means good RTOS design usually combines:

  • sensible priorities
  • tasks that block when idle
  • communication mechanisms like queues and semaphores
  • short bursts of work instead of endless busy loops

A system with well-chosen priorities but poor blocking behavior can still perform badly.

Example: queue-based design with priorities

Suppose you have a UART receive interrupt feeding bytes into a queue, and a task processes full commands. You also have a status LED task.

A sensible design might be:

  • CommandTask priority 3
  • LedTask priority 1
void CommandTask(void *pvParameters)
{
    char cmd;

    for (;;)
    {
        if (xQueueReceive(commandQueue, &cmd, portMAX_DELAY) == pdTRUE)
        {
            process_command(cmd);
        }
    }
}

void LedTask(void *pvParameters)
{
    for (;;)
    {
        toggle_led();
        vTaskDelay(pdMS_TO_TICKS(500));
    }
}

This is a nice example because the higher-priority command task is not wasteful. It blocks until data arrives. When a command comes in, it wakes quickly and handles it. The LED task fills spare time.

That is exactly the kind of behavior FreeRTOS priorities are good at supporting.

Priority inversion: an important real-world issue

Task priorities become more complicated when tasks share resources.

Imagine:

  • HighTask priority 3
  • MediumTask priority 2
  • LowTask priority 1

Now suppose LowTask holds a mutex protecting a shared UART. While it holds the mutex, HighTask becomes ready and tries to take the same mutex. It cannot, so it blocks.

At this moment, you might expect LowTask to run soon, finish its UART work, and release the mutex. But if MediumTask is ready and does not need that mutex, it can run before LowTask because it has higher priority than LowTask.

Now the high-priority task is effectively delayed by a low-priority task, with a medium-priority task making the delay worse.

That is priority inversion.

This is one reason mutexes are important in RTOS systems. Proper mutex behavior helps reduce this problem.

Even beginners should know this term because it explains why priorities alone do not solve everything.

Example: bad priority assignment in a user interface project

Suppose you build a device with these tasks:

  • TouchTask
  • ScreenTask
  • StorageTask

A beginner might assign:

  • StorageTask priority 4
  • ScreenTask priority 2
  • TouchTask priority 1

because saving data feels very important.

But this may create a poor user experience. If storage work keeps preempting the user interface tasks, touches may feel laggy and the screen may update unevenly.

A better choice might be:

  • TouchTask priority 4
  • ScreenTask priority 3
  • StorageTask priority 1 or 2

Why?

Because user interaction is time-sensitive. Storage is important, but often not urgent in the same immediate way.

This shows an important principle: priority should reflect urgency of response, not emotional importance.

Example: motor control versus telemetry

Consider a robotics system with:

  • MotorControlTask
  • TelemetryTask
  • DebugPrintTask

A reasonable priority pattern might be:

  • MotorControlTask priority 5
  • TelemetryTask priority 3
  • DebugPrintTask priority 1

The motor control loop affects physical behavior and may need tight timing.

Telemetry matters, but a small delay is acceptable.

Debug printing should never interfere with control.

This is a classic embedded priority structure. Control first, communication second, diagnostics last.

Why too many priority levels can be a problem

Beginners sometimes think every task needs a unique priority. That often leads to overcomplicated systems.

For example, assigning priorities 1, 2, 3, 4, 5, 6, and 7 to seven tasks may create a design that is harder to reason about than necessary.

In many systems, it is better to think in a few broad classes:

  • urgent real-time tasks
  • normal application tasks
  • background or maintenance tasks

That might mean several tasks share the same priority rather than each having their own special number.

This can make the design easier to understand and maintain.

A good practical way to choose priorities

A useful practical method is to ask these questions for each task:

How quickly must this task respond once it becomes ready?

What happens if this task is delayed?

Does this task spend most of its time blocked?

Does this task protect or affect time-sensitive hardware?

Is this task background work that can wait?

Tasks with strong timing requirements or urgent event handling usually deserve higher priorities.

Tasks doing periodic but less urgent work often fit in the middle.

Tasks for logging, diagnostics, statistics, or maintenance usually belong near the bottom.

This is much more reliable than assigning priorities based on guesswork.

Example of a balanced small system

Here is a simple balanced system:

  • ControlTask priority 4
  • CommsTask priority 3
  • UiTask priority 2
  • LogTask priority 1
void ControlTask(void *pvParameters)
{
    for (;;)
    {
        run_control_loop();
        vTaskDelay(pdMS_TO_TICKS(10));
    }
}

void CommsTask(void *pvParameters)
{
    for (;;)
    {
        if (xQueueReceive(commsQueue, &msg, portMAX_DELAY) == pdTRUE)
        {
            handle_message(msg);
        }
    }
}

void UiTask(void *pvParameters)
{
    for (;;)
    {
        update_ui();
        vTaskDelay(pdMS_TO_TICKS(100));
    }
}

void LogTask(void *pvParameters)
{
    for (;;)
    {
        flush_logs();
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

This is a realistic pattern. The fastest control loop gets top priority. Communications stay responsive. UI updates remain regular. Logging stays at the bottom.

The system is structured by urgency, not by arbitrary numbering.

Common beginner mistakes

One common mistake is giving a task high priority just because it seems important.

Another is creating a high-priority task that never blocks, starving the rest of the system.

Another is assuming low-priority tasks will always get time eventually. They will not if higher-priority ready tasks never stop running.

Another is using too many distinct priority levels without a clear reason.

Another is forgetting that blocking is healthy in RTOS design. A task waiting on a queue or semaphore is often behaving correctly, not “doing nothing.”

A final common mistake is trying to fix a design problem by only changing priorities. Sometimes the real issue is poor task structure, busy waiting, or bad resource sharing.

A simple mental model

A useful mental model is this:

  1. Priority answers the question, “If several tasks are ready right now, which one should run first?”
  2. It does not answer every scheduling question.
  3. It does not replace good blocking design.
  4. It does not automatically make code fast or efficient.
  5. It does not solve shared resource problems by itself.
  6. But it is one of the main tools that shapes responsiveness in an RTOS system.

Conclusion

Task priorities in FreeRTOS are not just labels. They are scheduling rules that determine which ready task gets CPU time first. A higher-priority ready task runs before a lower-priority ready task, which means bad priority choices can lead to starvation, poor responsiveness, or unstable-feeling behavior.

The best way to assign priorities is to think in terms of urgency and timing sensitivity. Tasks that must respond quickly or support time-critical behavior usually deserve higher priorities. Tasks doing less urgent work should be lower. Background logging and maintenance should generally stay near the bottom.

 

Share
0 comment
0 FacebookTwitterPinterestEmail
FreeRTOS

Anatomy of a Simple FreeRTOS Project: Beginner’s Guide

by shedboy71
written by shedboy71

A simple FreeRTOS project is easier to understand once you stop thinking of it as “just normal embedded code plus a few extra functions” and start seeing it as a system with clear layers. There is still startup code, hardware initialization, and application logic, but there is now also a kernel that creates tasks, schedules them, manages timing, and optionally provides queues, semaphores, and software timers.

FreeRTOS’s own beginner documentation describes the core flow very plainly: the application starts like a non-RTOS program until vTaskStartScheduler() is called, and only then does the scheduler take over task execution.

That one idea explains most of the anatomy. Before the scheduler starts, your code is still in ordinary startup territory. After the scheduler starts, the structure changes. Tasks, the idle task, and optionally the timer service task become part of the running system, and scheduling rules now decide what executes when. The idle task is created automatically when the scheduler starts, and the timer daemon task is also created if software timers are enabled.

This tutorial breaks a simple FreeRTOS project into its main parts so you can see what each part does and how they fit together.

The big picture

A simple FreeRTOS project usually has these main pieces:

The startup and hardware initialization layer.

The FreeRTOS kernel files and configuration.

The application code that creates tasks and other kernel objects.

The scheduler start point.

The task functions that do the real work.

Sometimes queues, semaphores, or software timers if the project is slightly more advanced.

At its smallest, a FreeRTOS project can be just one task and a scheduler. But even that tiny system still has a recognizable structure. It is not just a while(1) loop anymore. It is an application that hands control over to the RTOS kernel after setup.

The startup phase

A FreeRTOS project still begins like an ordinary embedded project. The processor resets, the startup code runs, memory sections are initialized, and eventually main() is reached. FreeRTOS does not replace this part. It sits above it.

That means your startup files, linker script, clock initialization, GPIO setup, UART setup, and board-specific initialization are still important. If the board clock is wrong, the tick timing may be wrong. If the interrupt setup is broken, the scheduler may not behave properly. If the heap or memory layout is incorrect, task creation may fail before the project even starts.

This is why beginners sometimes get confused. They think “I am writing a FreeRTOS project,” but the project is still also a normal embedded project underneath. FreeRTOS does not remove the need for correct low-level setup.

The kernel files

A simple FreeRTOS project includes the kernel itself. That usually means the core kernel source files plus the correct port files for the processor architecture and compiler. FreeRTOS also requires a configuration header called FreeRTOSConfig.h, which controls many core behaviors such as tick rate, maximum priorities, hooks, memory allocation options, and whether certain API features are enabled.

This is one of the most important files in the whole project. A simple FreeRTOS application may only have one or two user tasks, but FreeRTOSConfig.h still defines the environment those tasks run in.

For example, it affects things like:

The scheduler tick frequency.

Whether preemption is enabled.

Whether software timers are enabled.

How much heap is available.

Whether stack overflow hooks or malloc failure hooks are used.

This is why two projects with very similar application code can behave differently if their configuration files differ.

The memory management choice

A simple FreeRTOS project also has to choose how kernel-related dynamic memory is handled. FreeRTOS provides several heap management schemes, and its documentation describes these as different memory management options with different trade-offs. Task creation with xTaskCreate() uses RAM from the FreeRTOS heap, while static APIs such as xTaskCreateStatic() avoid that automatic allocation path.

That matters even in a beginner project. If you create tasks dynamically, their control blocks and stacks need memory from the FreeRTOS heap. If there is not enough heap available, task creation can fail, and if there is not enough memory even for the idle task, vTaskStartScheduler() can return instead of successfully starting the application.

So memory is part of the anatomy, not an afterthought. Even a tiny two-task demo depends on having the heap configured sensibly.

The main() function in a simple FreeRTOS project

In a simple FreeRTOS project, main() usually looks different from a bare-metal superloop design. Instead of performing all application work forever, it typically does setup, creates tasks, and then starts the scheduler.

A minimal pattern looks like this:

int main(void)
{
    hardware_init();

    xTaskCreate(Task1, "Task1", 256, NULL, 1, NULL);
    xTaskCreate(Task2, "Task2", 256, NULL, 1, NULL);

    vTaskStartScheduler();

    for (;;)
    {
    }
}

This small example reflects the standard project structure very well.

First, hardware is initialized.

Next, tasks are created.

Then vTaskStartScheduler() is called.

The infinite loop after that is usually only there as a fallback. In a correctly running system, execution should not normally continue past vTaskStartScheduler(), because once the scheduler starts, it takes control of task execution. FreeRTOS documents that after vTaskStartScheduler() the RTOS kernel controls which tasks execute and when.

This is one of the defining anatomical changes from bare-metal design. main() becomes a launch point rather than the long-term home of application logic.

The tasks

Tasks are the most visible part of a FreeRTOS project. Each task is a function, but not a normal one-shot function. A task is expected to run in a controlled infinite loop or otherwise remain alive for the scheduler to manage.

A typical task looks like this:

void LedTask(void *pvParameters)
{
    for (;;)
    {
        toggle_led();
        vTaskDelay(pdMS_TO_TICKS(500));
    }
}

This function is not called directly like an ordinary helper function. It is registered with the kernel, and the scheduler decides when it runs.

That difference matters a lot. A beginner may look at a task and think it is “just another function.” It is not. It is a schedulable execution context with its own stack, state, and priority.

Every task in the system has anatomy of its own:

A function body.

A stack.

A priority.

A task control block maintained by the kernel.

Possibly a handle if the application needs to refer to it later.

Once you understand that, a FreeRTOS project starts to look less like one program flow and more like several managed flows.

Task priorities

A simple FreeRTOS project often introduces priorities very early. Each task is created with a priority, and that priority influences which ready task gets CPU time. This is one of the biggest structural differences from a single-loop bare-metal application.

Even if a project has only two tasks, their priorities shape behavior. If both are ready and one has a higher priority, the higher-priority task will run first. If they share a priority, time slicing and scheduler behavior become relevant depending on the configuration.

This means that project anatomy is not only about files and functions. It is also about execution relationships. In FreeRTOS, how the pieces interact at runtime is part of the design.

The scheduler

The scheduler is the heart of the project. It is the component that turns a set of task functions into a multitasking system.

In a simple project, the scheduler decides things like:

Which ready task runs now.

When a delayed task becomes ready again.

When the idle task runs.

How time slicing works between equal-priority tasks.

How blocking operations affect execution flow.

FreeRTOS explicitly documents that vTaskStartScheduler() starts the scheduler and that after this call the kernel controls execution. It also notes that the idle task is created automatically when the scheduler starts.

That is why the scheduler is such a critical dividing line in project anatomy. Before it starts, you are still in plain initialization code. After it starts, the FreeRTOS world is active.

The tick interrupt

A simple FreeRTOS project also depends on the system tick. The tick interrupt is one of the main timing foundations of the kernel. It allows delayed tasks to wake up, time slicing to happen where configured, and time-based kernel services to operate.

You do not always see this directly in the application source, but it is part of the project’s anatomy. If the tick is misconfigured, task timing becomes wrong. If the port layer or interrupt priorities are incorrect, the scheduler may behave unpredictably.

This is why the port layer matters. A FreeRTOS project is not portable in the sense of being hardware-independent without any adjustment. It relies on the correct architecture-specific port.

The idle task

One detail beginners often miss is that the idle task is part of every normal FreeRTOS system. FreeRTOS documentation states that the idle task is created automatically when the scheduler starts.

The idle task is not something you usually create yourself, but it is an important structural piece. It runs when no other task is ready. In simple projects, this can be easy to overlook, but it matters for understanding scheduler behavior. If all your application tasks are blocked or delayed, the idle task runs.

This also explains why a project must have enough memory not just for your tasks, but for system tasks too.

Optional software timer support

A very simple FreeRTOS project may not use software timers, but once they are enabled they add another structural element. The FreeRTOS documentation notes that the timer daemon task is created when needed if software timers are used.

This means software timers are not just lightweight callback features floating independently. They depend on a service task in the background. That is useful to understand because timer callbacks do not execute in the same way as interrupts or ordinary direct function calls.

In anatomy terms, software timers add another subsystem inside the project.

Queues and communication

Many FreeRTOS tutorials quickly move beyond “two blinking tasks” into task communication. This is where the project anatomy starts to become richer.

A queue is not just a helper object. It is part of the structure that connects tasks. A sensor task may place data into a queue, and a display or logging task may remove that data from the queue. Once that happens, the project is no longer just a collection of parallel tasks. It becomes a coordinated system.

A small example might look like this:

QueueHandle_t sensorQueue;

void SensorTask(void *pvParameters)
{
    int value;

    for (;;)
    {
        value = read_sensor();
        xQueueSend(sensorQueue, &value, portMAX_DELAY);
        vTaskDelay(pdMS_TO_TICKS(100));
    }
}

void PrintTask(void *pvParameters)
{
    int received;

    for (;;)
    {
        if (xQueueReceive(sensorQueue, &received, portMAX_DELAY) == pdPASS)
        {
            print_value(received);
        }
    }
}

Now the anatomy includes not just tasks and scheduler behavior, but also a communication path between tasks.

Hooks and fault handling

A simple FreeRTOS project may also include hook functions depending on configuration. These can include things like malloc failure handling or stack overflow handling. This is important because real projects need a way to respond when something goes wrong.

FreeRTOS troubleshooting guidance highlights malloc failure and insufficient heap as common reasons a project may fail to start or behave unexpectedly.

This means defensive structure is part of project anatomy too. A simple project is not complete if it has tasks but no way to expose stack or memory failures during development.

A realistic simple FreeRTOS file structure

A beginner-friendly simple project often ends up with a structure roughly like this:

main.c for board setup, task creation, and scheduler start.

FreeRTOSConfig.h for kernel configuration.

One or more application source files for tasks.

The FreeRTOS kernel source files.

The architecture-specific port files.

A heap implementation file if dynamic allocation is used.

Even if the project is tiny, these files reflect a very important split between responsibilities:

Board and hardware initialization.

Kernel configuration.

Kernel implementation.

Application logic.

That separation is a big part of what makes RTOS-based projects easier to scale than giant bare-metal superloops.

How a simple FreeRTOS project differs from a bare-metal one

The clearest contrast is this:

A bare-metal project usually has one main control loop and interrupts.

A simple FreeRTOS project has startup code, task creation, scheduler startup, and multiple schedulable execution contexts.

In a bare-metal design, the main loop is the center.

In a FreeRTOS design, the scheduler is the center.

That is the biggest mental shift. The project anatomy changes because the system is no longer organized around one forever loop. It is organized around tasks and kernel services.

Common beginner misunderstandings

A common misunderstanding is thinking that main() keeps running normally after the scheduler starts. In a typical project, it does not. The scheduler takes over execution control.

Another is assuming task creation is free. It is not. Task creation consumes RAM for stacks and control structures, and dynamic creation depends on the FreeRTOS heap.

Another is assuming a simple RTOS project no longer needs normal embedded setup. It still does. Clocks, interrupts, board initialization, and memory layout all still matter.

Another is forgetting that system-created tasks such as the idle task also need resources.

These misunderstandings usually disappear once you see the project as a set of layers rather than a single code file.

A practical way to think about it

A good way to understand the anatomy is to imagine a simple FreeRTOS project as having three phases.

First, the normal embedded startup phase. This gets the chip and runtime ready.

Second, the application setup phase inside main(). This creates tasks, queues, and any other kernel objects.

Third, the scheduler-driven runtime phase. This is where tasks, delays, priorities, queues, and the idle task define actual behavior.

If you keep those three phases separate in your mind, FreeRTOS projects become much easier to reason about.

Conclusion

A simple FreeRTOS project is built from familiar embedded pieces, but arranged around a different execution model. Startup code and hardware initialization still come first. Then main() creates tasks and other kernel objects. Then vTaskStartScheduler() hands control to the kernel, which manages task execution, timing, and system behavior from that point onward.

The key structural pieces are the kernel files, FreeRTOSConfig.h, memory management choice, task definitions, scheduler start, and any communication objects such as queues. The idle task is automatically part of the system, and software timers add a timer service task when enabled.

Share
0 comment
0 FacebookTwitterPinterestEmail