What an RTOS is

Three ways to structure embedded software, in increasing order of control:

• Bare-metal superloop — one while(1) polling everything. Simple, but coupled: one slow step delays all the others, and there's no notion of priority.
• General-purpose OS (Linux, Windows) — optimizes average throughput and fairness. Excellent average latency, but the worst-case tail is unbounded.
• RTOS — independent tasks with priorities and a scheduler that guarantees the highest-priority ready task runs within a computable worst case. Kilobytes of footprint, often no MMU.

Everything below is the machinery that makes that guarantee possible.

Task

You hand the kernel a function, a stack size, and a priority number. The kernel gives that task its own stack (its own local variables and call history) and a control block that tracks its state. From then on it's one of possibly many tasks competing for the single CPU.

FreeRTOS · a task and its creation

void vBlinkTask(void *pv) {   // the task body
  for (;;) {                  // MUST loop forever — a task never returns
    gpio_toggle(LED);
    vTaskDelay(pdMS_TO_TICKS(500));  // block 500ms → yield the CPU
  }
}

xTaskCreate(vBlinkTask, "blink", 128, NULL, 2, NULL);

The task function itself

• Returns void and takes one void * argument. This signature is fixed — the kernel needs every task to look the same so it can call any of them the same way.
• The for(;;) is mandatory. A task must never fall off the end of its function. If it has nothing to do, it blocks (here, vTaskDelay) — it doesn't return. Returning from a task is a bug; to actually end one you call vTaskDelete.

Every argument to xTaskCreate

One function body, many configured instances

The void *pv argument (param 4) exists so you can write the task's logic once and start it several times, each with different data — instead of copy-pasting a near-identical function per instance. Each call to xTaskCreate below launches an independent task with its own stack, but all three share the exact same blinkTask code; only the config passed in differs.

typedef struct { int pin; int delay_ms; } BlinkCfg;  // per-instance config

void blinkTask(void *pv) {
  BlinkCfg *cfg = (BlinkCfg *)pv;     // cast the void* back to the real type
  for (;;) {
    toggle(cfg->pin);
    vTaskDelay(pdMS_TO_TICKS(cfg->delay_ms));
  }
}

// three configs, each a different "personality"
static BlinkCfg red   = { RED,   200 };
static BlinkCfg green = { GREEN, 500 };
static BlinkCfg blue  = { BLUE,  900 };

// SAME function, started three times, each with its own config:
xTaskCreate(blinkTask, "red",   128, &red,   2, NULL);
xTaskCreate(blinkTask, "green", 128, &green, 2, NULL);
xTaskCreate(blinkTask, "blue",  128, &blue,  2, NULL);

The static on each config isn't optional here — it keeps that BlinkCfg alive in .data for the program's whole lifetime. A local variable would go out of scope and become a dangling pointer the moment the surrounding function returned, while the task keeps running and reading through cfg forever.

Getting a handle back — an out-parameter, like scanf

xTaskCreate already uses its return value for success/fail, so it can't also hand back the task's handle that way. Instead you give it an empty box and its address, and it writes the handle into that box for you — exactly how scanf("%d", &x) writes a number into x through &x. Without the handle you have no way to refer to this specific task afterward — no name to suspend, resume, or delete it by.

// the familiar pattern first:
int x;
scanf("%d", &x);              // scanf WRITES into x, via its address

// xTaskCreate's 6th param works the same way:
TaskHandle_t myHandle;             // an empty box for the handle
xTaskCreate(vBlinkTask, "blink", 128, NULL, 2, &myHandle);
//                                              ^^^^^^^^^^ "write the handle in HERE"

// myHandle now NAMES that exact task:
vTaskSuspend(myHandle);       // pause it
vTaskResume(myHandle);        // resume it
vTaskDelete(myHandle);        // destroy it

// passing NULL instead just means "skip it, I'll never need to refer to
// this task again" -- the original xTaskCreate(vBlinkTask, ..., NULL) call.

Task states

• Running — currently executing on the CPU. Only one task per core is ever running.
• Ready — able to run, but a higher-priority task holds the CPU. Waiting its turn.
• Blocked — waiting for an event (a delay to expire, a queue item, a semaphore). Uses zero CPU while blocked.
• Suspended — explicitly parked; the scheduler ignores it until resumed.

Scheduler

• Fixed-priority preemptive is the common policy: always run the highest-priority task that is ready. No exceptions, no aging.
• The tick is a periodic timer interrupt (often 1 kHz). It expires delays, moves blocked tasks to ready, and may trigger a switch.
• Equal priority → optional time-sliced round-robin between them.

Below: the logger (low) runs only as filler. The control task (medium) wakes on a period and preempts it. The sensor task (high) is normally blocked, and the instant it's ready it takes the CPU from everyone.

Preemption & context switch

• Because the full register set and stack pointer are saved, a preempted task later resumes exactly where it stopped — it never knows it was paused.
• A switch costs real time (a few microseconds on an MCU). It isn't free, so thrashing between tasks has a cost you budget for.
• Preemption is what makes the timing guarantee real: a time-critical task doesn't wait politely for a lower one to finish.

Timing & delays

Blocking vs. spinning, first

A task that has nothing to do right now has two options. It can spin — sit in a tight loop repeatedly checking a condition, which keeps it RUNNING and burning 100% CPU on nothing, starving every lower-priority task the whole time. Or it can block — tell the kernel "wake me later," which drops it out of the ready list entirely at 0% CPU until that time (or event) arrives. Every delay call below is the second kind.

vTaskDelay(n) — counts from right now

This is the simple one: "block for n ticks, starting from this exact instant." The catch is that "this exact instant" is after your task's body already ran — so whatever time the body took gets added on top of n, every single lap. If the body's duration varies lap to lap (it almost always does — sensor noise, branch conditions, cache effects), the total period varies too. That's the drift.

void vGaitTask(void *pv) {
  for (;;) {
    read_joint_angles_update_servos();  // takes ~3-6ms, NOT fixed
    vTaskDelay(pdMS_TO_TICKS(5));       // +5ms from NOW, whenever "now" is
  }
}
// real period = body time + 5ms -- different every lap, legs drift out of sync

xTaskCreate(vGaitTask, "gait", 256, NULL, 3, NULL);

vTaskDelayUntil(&last, n) — counts from the schedule, not from now

Two parameters. n is the easy one — it's just the fixed period you want between wake-ups, in ticks (5ms in the gait loop, converted with pdMS_TO_TICKS(5)). It never changes call to call; it's the constant "every 5ms" part of the sentence. last is the harder one, and the one that actually does the work — it's not a duration at all, it's a single point in time.

Think of a school's bell schedule. Period 2 starts at 9:45 — always, on the dot — regardless of whether period 1's teacher dismissed students exactly on time or ran two minutes over. The bell doesn't say "45 minutes after whenever period 1 actually ends"; it rings against a fixed master timetable that was set at the start of the day. In that analogy, the class length is n (a constant, "45 minutes," set once) and 9:45 itself is last — the specific clock time the previous bell was scheduled for. vTaskDelayUntil is that timetable.

What last actually is

last is a variable that holds one thing: the tick count of the most recent scheduled wake-up — not "how long ago the task last ran," not a duration at all, just a single point on the clock. Every call to vTaskDelayUntil does three things, in order:

1. Compute the next target: target = last + n — the next slot on the fixed timetable.
2. Block the task until the clock actually reaches target.
3. Write target back into last, through the pointer you passed — so next lap's calculation starts from this lap's target, not from whatever time it happened to actually wake up at.

This is exactly why it takes &last and not last: the function needs to update your variable in place so the next call sees the new target — the same out-parameter pattern as scanf and the task-handle example above. do_work() genuinely has nothing to do with computing the next wake time at all — it only has to finish before that time arrives, or the deadline is missed.

void vGaitTask(void *pv) {
  TickType_t last = xTaskGetTickCount();   // seed with the CURRENT time, ONCE,
                                            // before the loop even starts
  for (;;) {
    read_joint_angles_update_servos();          // takes ~3-6ms, NOT fixed -- doesn't matter
    vTaskDelayUntil(&last, pdMS_TO_TICKS(5));  // last: READ old target, WRITE new target
  }
}
// real period = exactly 5ms, every lap, regardless of body time

xTaskCreate(vGaitTask, "gait", 256, NULL, 3, NULL);

Notice last is declared inside the task, but outside the for(;;) loop — so it's set once, when the task starts, using the real clock via xTaskGetTickCount(). After that, vTaskDelayUntil owns it entirely on every subsequent lap; you never touch it again yourself.

tracing three laps by hand

The body took a different amount of time every lap (3, then 6, then 1ms) — and it made zero difference to when the task woke up. It woke at 10, 20, 30: a clean, unbroken 10-tick cadence, because each target was computed from the previous target, never from "now."

See this animated, with randomized body times, on the delay.drift page →

Queue

Why not just a shared global variable?

It looks tempting: float distance; at file scope, sensor task writes it, navigation task reads it. The problem is a torn read — a float is 4 bytes, and there's no guarantee the write happens as one atomic step. If the navigation task reads distance at the exact instant the sensor task is halfway through writing a new value (2 bytes of the old number, 2 bytes of the new one), it reads garbage that was never a real distance at all — and on some architectures this is even more likely with structs than single floats. A queue sidesteps this entirely: the kernel copies the whole item in and the whole item out under its own internal lock, so the reader either sees the complete old value or the complete new value — never a mix.

Every argument, xQueueCreate

A queue can hold whole structs, not just a single number — pass sizeof(SensorReading) instead, and every send/receive copies the entire struct in one shot.

Every argument, xQueueSend / xQueueReceive

Blocking is the rendezvous

If the navigation task calls xQueueReceive while the queue is empty, it doesn't spin or poll — it blocks, using zero CPU, until the sensor task actually sends something. The instant a value arrives, the kernel wakes it up. This is the same BLOCKED state from section 02 — a queue is simply one of the things a task can block on.

FreeRTOS · the full producer/consumer, wrapped in real tasks

QueueHandle_t distQ;   // shared handle, visible to both tasks

void vSensorTask(void *pv) {
  for (;;) {
    float d = read_ultrasonic_cm();
    xQueueSend(distQ, &d, 0);      // don't block sensor loop -- drop if full
    vTaskDelay(pdMS_TO_TICKS(20));
  }
}

void vNavTask(void *pv) {
  float reading;
  for (;;) {
    xQueueReceive(distQ, &reading, portMAX_DELAY);  // block until data exists
    react_to_distance(reading);
  }
}

int main(void) {
  distQ = xQueueCreate(10, sizeof(float));
  xTaskCreate(vSensorTask, "sensor", 256, NULL, 2, NULL);
  xTaskCreate(vNavTask,    "nav",    256, NULL, 3, NULL);
  vTaskStartScheduler();
}

Semaphore

Binary semaphore — pure signaling

A binary semaphore holds one bit of state: 0 ("nothing pending") or 1 ("an event is waiting to be consumed"). An ISR (or another task) calls give to raise it to 1; a task calls take, which blocks while it's 0 and, the instant it becomes 1, wakes the task and drops it back to 0. There's no ownership concept here — unlike a mutex, anyone can give, anyone can take.

Why not just a volatile bool footDown flag instead? Mostly the same reasoning as queues vs. a shared global — but there's a sharper failure mode here: a bare flag can't distinguish "no event" from "event already consumed," and gives you no safe blocking primitive at all — your task would have to spin-check it, burning CPU. The semaphore gives you the blocking (0% CPU while waiting) for free, plus race-safety on the give/take pair itself.

Counting semaphore — N identical resources

Say an MCU has only 3 DMA channels available for peripheral transfers, shared across several independent tasks (e.g. one streaming to a display, one logging to flash, one pushing samples out over UART). Any of them may want to start a transfer at nearly the same instant, but only 3 DMA channels physically exist. A counting semaphore initialized to 3 models this directly: each take decrements the count (borrow a channel), each give increments it (release it once the transfer completes), and a take at count 0 blocks until someone gives one back.

tracing it with 4 tasks, only 3 channels

One thing worth being explicit about: the semaphore's count doesn't know or care which of the 3 physical channels is free — it only enforces the number "no more than 3 in use at once." In real code, something separate (often a small array of 3 channel IDs, or the DMA driver itself) hands out the actual channel number once a take succeeds. The semaphore's job is narrower than it sounds: it's purely the admission gate — "are you allowed through right now, and if not, wait here" — not a mechanism that identifies or reserves a specific resource for you.

Every argument

Notice xSemaphoreGive takes no second parameter — this is the concrete difference from a queue: a queue's xQueueSend needs an address because it copies a payload; a semaphore carries no payload, so there's nothing to point at.

FreeRTOS · ISR signals a binary semaphore, task blocks on it

SemaphoreHandle_t footSem;

void EXTI2_IRQHandler(void) {          // foot-contact interrupt
  BaseType_t woken = pdFALSE;
  xSemaphoreGiveFromISR(footSem, &woken);   // ISR-safe variant
  portYIELD_FROM_ISR(woken);
}

void vGaitEventTask(void *pv) {
  footSem = xSemaphoreCreateBinary();
  for (;;) {
    xSemaphoreTake(footSem, portMAX_DELAY);   // block until a foot touches down
    advance_gait_phase();
  }
}

Mutex & priority inversion

Ownership — the one new rule a mutex adds

A binary semaphore has no concept of "whose" it is — any task (or ISR) can `give` it, any task can `take` it, regardless of who did what before. A mutex adds exactly one extra invariant: only the task that successfully `take`s it is allowed to `give` it back. If a different task calls `give` on a mutex it never took, that's an error condition the kernel can detect and reject — this is precisely why a mutex, unlike a binary semaphore, is never given from an ISR (an ISR can't "own" anything in the task sense) and why FreeRTOS doesn't even provide a `xSemaphoreGiveFromISR`-style call for mutexes.

Every argument

FreeRTOS · four leg tasks serializing access to one I2C bus

SemaphoreHandle_t i2cBus;   // created once, in main(), before the scheduler starts

void vLegTask(void *pv) {
  LegConfig *cfg = (LegConfig *)pv;
  for (;;) {
    compute_next_joint_targets(cfg);

    xSemaphoreTake(i2cBus, portMAX_DELAY);   // lock the bus -- may block
    pca9685_write_channels(cfg->channels, cfg->targets);
    xSemaphoreGive(i2cBus);                 // unlock -- SAME task that locked it

    vTaskDelay(pdMS_TO_TICKS(5));
  }
}

Notice the critical section — everything between Take and Give — is kept as short as possible: just the actual I2C write, nothing else. compute_next_joint_targets runs before locking, so the bus isn't held hostage during unrelated computation.

Priority inversion — the Mars Pathfinder bug

July 1997: Pathfinder kept resetting on Mars. A high-priority task (H) needed a mutex held by a low-priority task (L). A medium task (M) — needing no lock — preempted L and ran long, so L never released the mutex, so H stayed blocked below M. The watchdog saw H miss its deadline and rebooted the craft.

Translate that directly onto your bus: suppose your high-priority balance-correction task (H) needs the I2C bus, currently locked by a low-priority telemetry-logging task (L). A medium-priority task (M) — say, reading the ultrasonic sensor, no lock needed — preempts L and runs long. L can't finish and release the bus. H sits blocked, indirectly stuck behind M, even though H outranks M. That's priority inversion: a low-priority task, through a lock, is effectively capping how long a high-priority task can be delayed by a completely unrelated medium-priority one.

Priority inheritance is the fix: while H waits on the mutex, the kernel temporarily boosts the holder L to H's priority, so M can't preempt it. L finishes its critical section fast and drops back down. In FreeRTOS this is automatic for a mutex (and absent from a plain semaphore — which is exactly why you don't guard data with one).

FreeRTOS · mutex with inheritance

SemaphoreHandle_t m = xSemaphoreCreateMutex();  /* inheritance ON */

xSemaphoreTake(m, portMAX_DELAY);
touch_shared_bus();     /* keep the critical section short */
xSemaphoreGive(m);

Interrupts (ISRs)

Why "above every task" isn't an exaggeration

Task priorities (1, 2, 3...) only rank tasks against each other. An ISR isn't a task at all, and it sits in a separate tier entirely — when an interrupt fires, it runs immediately, ahead of literally every task in the system, including your highest-priority one. This is exactly why an ISR must be kept short: while it's running, nothing else — not even your most time-critical task — gets a chance to run. A slow ISR doesn't just delay low-priority background work; it can delay everything.

Why an ISR can't block

Every blocking call you've seen so far (xQueueReceive, xSemaphoreTake with a real timeout) works by putting the calling task to sleep and letting the scheduler run something else. But an ISR isn't a task — it has no task control block, no priority in the scheduler's list, nothing for the kernel to "put to sleep." There's no meaningful answer to "which task should run instead" from inside an ISR, because the whole concept of blocking is task-shaped, and an ISR simply isn't one. That's the real reason xQueueReceive/xSemaphoreTake are illegal inside an ISR, and why every ISR-safe call ends in FromISR and never takes a timeout parameter at all — it's not a stylistic choice, it's structurally impossible for an ISR to wait for anything.

Deferred interrupt processing

The fix is the pattern you've now seen a few times: the ISR does the bare minimum — grab the raw data, hand it off — and a normal task, back in the regular scheduler's world, does the actual work of interpreting it. The ISR defers the real processing to a task that can safely take its time, block, and be pre-empted normally.

Every piece of the handoff, explained

Without that last line, the unblocked task would still eventually run — but only whenever the scheduler next happened to check, which could be a full tick period later. For a balance-control task reacting to fresh IMU data, that delay could be the difference between correcting a stumble and not.

FreeRTOS · ISR hands off to a task

void IMU_DATA_READY_IRQHandler(void) {
  BaseType_t woken = pdFALSE;
  float sample = read_imu_register();       /* quick HW read, no blocking */

  xQueueSendFromISR(imuQ, &sample, &woken);  /* FromISR variant */
  portYIELD_FROM_ISR(woken);                    /* switch NOW if needed */
}

void vBalanceTask(void *pv) {
  float orientation;
  for (;;) {
    xQueueReceive(imuQ, &orientation, portMAX_DELAY);  /* safe here -- this IS a task */
    correct_balance(orientation);
  }
}

Determinism

The formula

Because scheduling is fixed-priority and preemptive (section 03) and blocking time is bounded by priority inheritance (section 08), the worst-case response time (WCRT) of a task is just three numbers added together:

WCRT = C + I + B. If that sum fits inside the task's deadline, you've mathematically proven it holds — every time, not just in your test runs. This technique is called rate-monotonic analysis.

worked numbers — the balance task's WCRT

H is the highest-priority task, so nothing can preempt it — I = 0. The only thing that can delay it is L holding a mutex H also needs, and priority inheritance caps that at L's critical section length — B = 1ms. H's own body — C = 1ms.

WCRT = C + I + B = 1 + 0 + 1 = 2ms

If H's actual deadline is 5ms, 2ms < 5ms — proven, not hoped for. This is exactly why section 08's fix mattered: without priority inheritance, B wouldn't be bounded by "one critical section" at all — it could be however long M happened to run, unbounded, and this whole calculation would fall apart.

Why a general-purpose OS gives you no such number

A GPOS scheduler optimizes for fairness and throughput, not analyzability — it can reschedule based on dynamic priority adjustments, background daemons, page faults, disk I/O, network stacks, none of which have a knowable worst case. There's no formula like the one above you could even attempt to write for Linux's default scheduler; "the terms in the sum are themselves unbounded" is the whole reason a GPOS can't make this promise, no matter how fast it usually is.

RTOS in the wild