RTOS Core Components

1. From Bare Metal to an Operating System

On a bare-metal system, you often have a while(1) super-loop that calls various functions. This becomes difficult to manage when functions have different timing requirements or when you need to respond to events with varying urgency. An RTOS solves this by creating an abstraction layer over the CPU.

Let's start with a clear definition of what an RTOS is and, crucially, how it differs from a general-purpose operating system (GPOS) like Windows or Linux.

This is a fundamental concept and a very common opening question in interviews. Let's frame it as such.

In essence, the core job of an RTOS is to provide determinism: the guarantee that tasks will execute within a predictable, bounded timeframe.

2. Core Component: Tasks

In an RTOS, the basic unit of execution is not a function call in a loop, but a task (some RTOSes, like CMSIS-RTOS, call them threads). Think of each task as its own independent mini-program with its own purpose and its own forever-loop.

For a clear definition, let's turn back to our interview prep resource.

Task Context and the Task Control Block (TCB)

The most important property of a task is its unique context. This is a snapshot of the processor's state that belongs exclusively to that task. When the RTOS switches from one task to another, it saves the context of the outgoing task and loads the context of the incoming one.

So, what is in this "context"? At its core, it's the CPU registers.

The RTOS needs a place to store this context, along with other information about the task, like its priority and current state. This is done using a fundamental kernel data structure called the Task Control Block (TCB). Every task you create in an RTOS has a corresponding TCB in memory. The TCB is arguably the most essential kernel object.

Task States

A task isn't always running. It can be in several states, and the RTOS scheduler is responsible for transitioning it between them. The main states are:

• Running: The task is currently executing on the CPU. On a single-core processor, only one task can ever be in the Running state.
• Ready: The task is ready to run but is waiting for the CPU because a higher-priority task (or another task of the same priority) is currently Running.
• Blocked: The task is waiting for an event, such as a time delay to expire (vTaskDelay), data to arrive in a queue, or a semaphore to become available. A task in the Blocked state does not consume any CPU time.
• Suspended: The task has been explicitly put to sleep and can only be woken up by an explicit resume call.

This next video provides a superb visual explanation of these states and the transitions between them.

3. Core Component: The Scheduler

If tasks are the actors, the scheduler is the director. It is the heart of the RTOS kernel, and its sole job is to decide which task should be in the Running state at any given moment.

Most RTOSes use a priority-based, preemptive scheduler.

• Priority-Based: Each task is assigned a priority. The scheduler will always choose to run the highest-priority task that is in the Ready state.
• Preemptive: If a high-priority task becomes Ready (e.g., its delay finishes) while a lower-priority task is Running, the scheduler will immediately stop (preempt) the low-priority task and switch to the high-priority one.

The scheduler is typically invoked by a periodic hardware timer interrupt, often called the tick. On ARM Cortex-M processors, this is usually the SysTick timer.

The process of the scheduler stopping one task, saving its context to its TCB, and starting another by loading its context from its TCB is called a context switch.

4. Core Component: Kernel Objects

We've already met the most fundamental kernel object: the TCB. In general, kernel objects are the primitives or tools that the RTOS provides for tasks to interact with each other and the system. They are the building blocks of a multitasking application.

Besides the TCB, other critical kernel objects, which we will implement in later lessons, include:

• Queues: For passing data safely from one task to another.
• Semaphores: For signaling between tasks or from an interrupt to a task.
• Mutexes (Mutual Exclusion): For protecting a shared resource (like a UART peripheral or a global variable) from being accessed by multiple tasks at the same time.

These objects are "kernel-aware," meaning the RTOS knows about them. If a task tries to get data from an empty queue, the scheduler can automatically put the task into the Blocked state and run another task, ensuring the CPU is never wasted waiting.

5. Interview Preparation

Let's consolidate this into answers for likely interview questions.

• Question: "What are the core components of an RTOS?"

  • Your Answer: "The core components are tasks, the scheduler, and kernel objects. Tasks are independent threads of execution, each with its own context stored in a Task Control Block (TCB). The scheduler is the engine that decides which task to run based on a scheduling algorithm, which is typically priority-based and preemptive. Kernel objects are RTOS-provided resources like queues, semaphores, and mutexes that tasks use to communicate and synchronize."

• Question: "What's the difference between a task being in the Ready state versus the Blocked state?"

  • Your Answer: "A task in the Ready state is able to run but is currently waiting for the CPU because another task of equal or higher priority is running. It's in the queue to be scheduled. A task in the Blocked state is waiting for a specific event—like a timer to expire or data to arrive in a queue. It is not eligible to be scheduled and consumes no CPU time until that event occurs."

• Question: "You have experience with AUTOSAR OS. How do its core concepts compare to a more general RTOS like FreeRTOS?"

  • Your Answer: "They share the fundamental principles. The AUTOSAR OS, based on the OSEK standard, is an RTOS with tasks, a priority-based preemptive scheduler, and resources for synchronization. The main difference lies in the philosophy. AUTOSAR OS is highly static; all tasks, priorities, and resources are defined and configured before compilation to ensure extreme predictability for functional safety. FreeRTOS is more dynamic, allowing tasks and other objects to be created and deleted at runtime, offering more flexibility. Both solve the same problem of managing concurrent execution, but AUTOSAR is tailored for the rigid, safety-critical certification needs of the automotive industry."

Conclusion

Today, we've established the foundational theory of Real-Time Operating Systems. You've learned how an RTOS uses tasks, a scheduler, and various kernel objects to create a structured, deterministic environment for running multiple software functions concurrently.

Key Takeaways:

• An RTOS prioritizes determinism and predictable timing over raw throughput.
• A task is an independent thread of execution with its own context (CPU registers, stack) stored in a Task Control Block (TCB).
• Tasks transition between states like Running, Ready, and Blocked.
• The scheduler is the kernel component that decides which task to run, typically using a priority-based, preemptive algorithm triggered by a periodic tick interrupt.
• Kernel objects (like queues, semaphores, mutexes) are the building blocks for inter-task communication and synchronization.

Next Lesson Preview:
Now that we've covered the "what," it's time to learn the "how." In the next lesson, we will move from theory to practice and implement and manage tasks in FreeRTOS, including their creation, deletion, and priority assignment. You'll write your first multi-tasking application and see these concepts come to life in code.