FreeRTOS

I. Learning Objectives

1. Understand basic FreeRTOS knowledge.
2. Use FreeRTOS to schedule RGB, serial port, LED, buzzer, and OLED peripherals.

II. FreeRTOS Introduction

FreeRTOS is a real-time operating system (RTOS) widely used in embedded systems, characterized by open source, lightweight, and scalable features, particularly suitable for resource-constrained microcontrollers (MCUs) and embedded devices. Its design core is to achieve efficient multi-task management and real-time response on resource-constrained hardware. It provides core functions such as task scheduling, memory management, synchronization and communication, helping developers build responsive and highly reliable real-time applications, widely used in smart home, industrial control, IoT devices and other fields.

Project address: https://github.com/FreeRTOS/FreeRTOS

Official website: https://www.freertos.org

I. FreeRTOS Principles

1. Task Management and Scheduling: Core Mechanism of Multi-tasking

The core of FreeRTOS is the task scheduler, which manages multiple independent tasks and decides when to run which task. A task is the smallest execution unit in the operating system, with independent stack space and execution logic, can be viewed as a "micro-program".

• Essence of Tasks: Each task is an infinite loop (while(1)), containing independent local variables and stack (for saving context, such as register status). Task creation requires specifying priority (0~configMAX_PRIORITIES-1, higher value means higher priority).

• Task Control Block (TCB): Each task corresponds to a TCB_t structure (task control block), used to store key information of the task, including: stack pointer (save task context), priority, status, delay time, belonging queue, etc. All task TCBs form a linked list for scheduler management.

• Task States and Transitions: Tasks have 4 core states, scheduler achieves task switching through state transitions:

  • Ready: Task is ready to run, waiting for CPU resources (only limited by priority).
  • Running: Task is currently occupying CPU execution.
  • Blocked: Task temporarily cannot run due to waiting for events (such as delay, semaphore, queue data), does not participate in scheduling.
  • Suspended: Task is forcibly paused, needs explicit recovery through vTaskResume(), does not participate in scheduling.

• Scheduler Working Mechanism:

  FreeRTOS uses preemptive scheduling as core (default mode), meaning when high-priority tasks are ready, they immediately preempt CPU resources of low-priority tasks, ensuring real-time response of high-priority tasks. Specific rules:

  • Only ready-state tasks participate in scheduling, scheduler always selects highest-priority ready task to run.
  • Same-priority tasks can enable time-slice round-robin (configured through configUSE_TIME_SLICING), each task takes turns occupying CPU (time slice determined by system tick period).
  • Cooperative scheduling (optional): Actively yield CPU through taskYIELD(), suitable for scenarios with low real-time requirements.

2. Inter-task Communication and Synchronization: Solving Multi-task Collaboration Problems

When multiple tasks run in parallel, specific mechanisms are needed to achieve data interaction and resource competition control. FreeRTOS provides rich synchronization and communication tools:

• Queue:

  Used for asynchronous data transfer between tasks (such as sensor data, commands), based on FIFO (First In First Out) principle, supports multi-task read/write. Queues can store fixed-size elements (such as integers, pointers), block when queue is full during write, block when queue is empty during read (blocking time configurable).

• Semaphore:

  Used for resource synchronization or counting, divided into two types:

  • Binary semaphore: Only two states (0/1), similar to "switch", often used for mutual exclusion (such as controlling single thread access to hardware resources) or synchronization (such as task A notifying task B after completion).
  • Counting semaphore: Supports counting (0~n), used to manage limited number of resources (such as 3 UART ports, count initial is 3, decrease by 1 when occupied, increase by 1 when released).

• Mutex:

  Special binary semaphore, used to solve priority inversion problem (when low-priority task occupies resources, high-priority task is blocked due to waiting for resources, causing medium-priority tasks to "jump the queue"). Mutex temporarily boosts low-priority task's priority through priority inheritance protocol, making it release resources faster.

• Event Group:

  Used for multiple tasks waiting for multiple events (such as "task waits for both sensor A and sensor B to be ready"). Each event is represented by a bit, tasks can wait for "any event satisfied" or "all events satisfied", suitable for complex condition trigger scenarios.

• Task Notification:

  More efficient mechanism than queues (no additional memory allocation), achieves communication by directly writing notification value to task's TCB. A task can be notified by multiple tasks, supports operations like overwrite, increment, set bit, suitable for lightweight interaction.

3. Memory Management: Adapting to Embedded Resource-constrained Scenarios

Embedded systems have limited memory, FreeRTOS provides 5 memory allocation schemes (selected through heap_x.c), balancing efficiency, determinism and flexibility:

• heap_1: Only supports memory allocation (pvPortMalloc()), does not support free (vPortFree()), suitable for scenarios without dynamic memory release (such as tasks not deleted after creation), advantages are simple, no fragmentation.
• heap_2: Supports allocation and free, but does not merge adjacent free blocks, prone to memory fragmentation after long-term use, suitable for scenarios with fixed memory block sizes.
• heap_3: Wraps standard library malloc() and free(), depends on compiler implementation, advantage is universal, disadvantage is poor real-time performance (allocation time uncertain).
• heap_4: Supports allocation, free and free block merging (reduces fragmentation), manages memory through linked list, suitable for scenarios needing dynamic release and sensitive to fragmentation.
• heap_5: Based on heap_4, supports non-contiguous memory regions (such as external RAM + internal RAM), defines memory blocks through vPortDefineHeapRegions(), suitable for hardware with scattered memory distribution.

4. Time Management: Tick-based Timing Mechanism

FreeRTOS relies on system tick to achieve timing and scheduling, ticks are generated by hardware timer (such as SysTick), period (configTICK_RATE_HZ) usually 100~1000Hz (i.e., 1~10ms once).

• Scheduler's task switching, delay functions (such as vTaskDelay()) are all based on tick counting.
• vTaskDelay(x): Task blocks for x ticks then enters ready state (relative delay, calculated from call moment).
• vTaskDelayUntil(): Absolute delay, ensures task executes at fixed period (such as running every 10ms, not affected by task execution time).

II. FreeRTOS Features

1. Open Source and Free, Friendly License

Uses MIT license, allows free commercial use, source code completely open, no patent or commercial authorization restrictions, suitable for enterprise and personal projects.

2. Lightweight, Extremely Low Resource Usage

Core code only a few thousand lines, compiled size can be as low as 6KB (depending on feature trimming), RAM usage mainly depends on task stack size (each task stack can be as small as dozens of bytes), suitable for 8-bit/16-bit MCUs (such as STM8, PIC) and resource-constrained 32-bit MCUs (such as ARM Cortex-M0).

3. Highly Scalable, Configure on Demand

Through FreeRTOSConfig.h header file, functions can be enabled/disabled (such as queues, mutexes, time-slice round-robin), adjust priority count, stack size and other parameters, only keep necessary components, maximize resource savings.

4. Strong Real-time Performance, Deterministic Scheduling

Preemptive scheduling ensures high-priority tasks can respond at microsecond level (delay determined by task switching time, usually <10us), scheduling behavior is predictable (task switching time fixed under same conditions), meeting real-time scenario requirements such as industrial control, automotive electronics.

5. Broad Hardware and Architecture Support

Supports almost all mainstream embedded architectures, including ARM (Cortex-M/R/A), AVR, PIC, RISC-V, MIPS, etc., adapts to thousands of MCUs (such as STM32, ESP32, MSP430), official provides numerous porting examples.

6. Flexible Task Scheduling Strategies

Supports preemptive, cooperative scheduling, same-priority tasks can time-slice round-robin, priority range configurable (up to 256 levels), meeting task priority design needs of different scenarios.

7. Complete Synchronization and Communication Mechanisms

Provides queues, semaphores, mutexes, event groups, task notifications and other tools, covering single/multi-task data transfer, resource competition, condition triggering and other needs, with simple and easy-to-use interfaces.

8. Priority Inversion Protection

Mutex's priority inheritance protocol solves common priority inversion problems in real-time systems, avoiding high-priority tasks being blocked for long time due to waiting for resources held by low-priority tasks.

9. Strong Portability

Kernel is hardware-independent, adapts to different architectures through "port layer" (only need to implement hardware-related code such as context switching, interrupt handling), porting workload is small (usually a few hundred lines of code).

III. Hardware Setup

IV. Experiment Steps

This project is built based on the previously configured 80MHz crystal example. We click Manage RunTime Environment, check and add all components under RTOS. Here we select FreeRTOS as the RTOS version, and select Heap_4 as the memory management algorithm.

Add components as follows

Then we add peripheral configuration through sysconfig tool

RGB light configuration

Buzzer configuration

MCU indicator light configuration

Serial port configuration

Serial port configuration

OLED configuration

We focus on introducing some FreeRTOS configurations

CPU frequency setting

#define configCPU_CLOCK_HZ ( ( unsigned long ) 80000000 )

Systick interrupt frequency setting

#define configTICK_RATE_HZ 1000

//Software timer is turned off and not used. If enabled, need to implement vApplicationGetTimerTaskMemory vApplicationGetIdleTaskMemory #define configUSE_TIMERS 0

System call stack size

#define configSYSTEM_CALL_STACK_SIZE 128

Enable static memory allocation

#define configSUPPORT_STATIC_ALLOCATION 1

Enable dynamic memory allocation

#define configSUPPORT_DYNAMIC_ALLOCATION 1

Kernel automatically allocates memory, we allocate manually here

#define configKERNEL_PROVIDED_STATIC_MEMORY 0

Boot MPU M0 core does not support, turn off here

#define configENABLE_MPU 0

FreeRTOS heap size in bytes

#define configTOTAL_HEAP_SIZE 4096

V. Code Analysis

xTaskCreate

vTaskDelayUntil

xQueueSend

xQueueReceive

prvQueueSendTask

prvQueueReceiveTask

prvBuzzerTask

prvUartTask

prvRgbTask

prvOledTask

rgb_SetColor

rgb_SetRGB

VI. Experiment Phenomenon

After the program is flashed, connect Type-C to the car, open serial port assistant and configure as follows. LED executes one toggle every 1s, serial port counting task prints once every 1s, RGB, buzzer, OLED execute once every 2s.