Real-Time Scheduling and Resource Sharing Protocols in FreeRTOS

ECE 5550G — Advanced Real-Time Systems · Virginia Tech · Spring 2025

A four-project sequence building real-time scheduling infrastructure inside FreeRTOS on STM32 hardware, working up from task primitives to resource-sharing protocols that bound priority inversion.

Why this matters

FreeRTOS gives you preemptive fixed-priority scheduling and mutexes. It does not give you periodic task abstractions, deadline tracking, or the protocols that make shared resources safe under hard real-time constraints. Those you build — and building them is how the theory stops being theory.

Project 1 — Task primitives

Periodic tasks with explicit periods and priorities, validated on hardware with LED timing and vTaskDelay. Establishes the basic timing model and the serial-port debugging workflow used throughout the sequence.

Project 2 — A periodic task framework

An extended task control block (xExtended_TCB) carrying the state that fixed-priority real-time analysis actually needs:

1TickType_t xReleaseTime;        /* release time */
2TickType_t xRelativeDeadline;   /* relative deadline */
3TickType_t xAbsoluteDeadline;   /* absolute deadline */
4TickType_t xPeriod;             /* task period */
5TickType_t xMaxExecTime;        /* worst-case execution time */
6TickType_t xExecTime;           /* current execution time */
7BaseType_t xWorkIsDone;         /* job completion flag */

Around it, a TCB array with allocation and lookup — prvInitTCBArray, prvFindEmptyElementIndexTCB, prvGetTCBIndexFromHandle, prvDeleteTCBFromArray — plus prvPeriodicTaskCode, the wrapper every periodic task runs. This is the substrate the scheduling algorithms sit on.

Project 3 — Rate-monotonic scheduling

Rate-monotonic (RM) priority assignment implemented on top of the periodic framework: shorter period means higher priority, assigned statically. Validated by observing task release and completion order over the serial port against the expected RM schedule.

Project 4 — Ceiling priority protocols

RM alone is unsafe once tasks share resources — a low-priority task holding a mutex can block a high-priority one indefinitely through a chain of medium-priority preemptions. Project 4 implements the two standard remedies on top of the RM scheduler:

RM-OCPP — the Original Ceiling Priority Protocol (priority ceiling protocol). Each resource carries a ceiling equal to the highest priority of any task that uses it; a task may lock a resource only if its priority exceeds every ceiling currently held by other tasks.

RM-ICPP — the Immediate Ceiling Priority Protocol (highest locker priority). A task's priority is raised to the resource ceiling immediately on acquisition rather than on contention.

Both bound priority inversion to at most one critical section. ICPP is simpler and avoids deadlock structurally; OCPP blocks less often in practice. Implementing both against the same workload makes the tradeoff concrete rather than abstract.

Takeaway

The sequence covers the path from "FreeRTOS can run tasks" to "this task set is schedulable and its blocking time is bounded." Priority inversion in particular is a failure mode that is obvious in a textbook and genuinely difficult to see on hardware — which is the point of validating each protocol on a real STM32 rather than in simulation.