What FreeRTOS Actually Is
FreeRTOS is a real-time kernel, not an operating system in the desktop sense. No filesystem, no shell, no drivers beyond what you bring. What it provides is the hard part: a preemptive priority scheduler, tasks, queues, semaphores, mutexes, and timers, in 4-9 KB of flash, portable across virtually every MCU architecture that matters. Created by Richard Barry in 2003, stewarded by AWS since 2017, MIT-licensed since the handover. Per the FreeRTOS documentation, the kernel itself is a handful of C files: tasks.c, queue.c, list.c, timers.c, plus one port file per architecture. You can read the whole thing in an afternoon. You should.
The reach is the story. It runs on an estimated 40% of RTOS-enabled MCUs, and if you've touched an ESP32, you've shipped FreeRTOS: Espressif's entire ESP-IDF framework sits on a dual-core port of it. Which chip to put it on is a separate decision, and our STM32 vs ESP32 vs RP2040 comparison walks that tree.
The Licensing History, Because It Still Confuses People
Three eras. Before 2017: a modified GPL with a linking exception, free for commercial use but with enough legal ambiguity that cautious teams bought the commercially-licensed OpenRTOS from Wittenstein instead. 2017 onward: AWS took stewardship and relicensed the kernel MIT, which ended the ambiguity, you can ship it in closed-source firmware, full stop. The third artifact is SafeRTOS, a separately developed, safety-certified derivative sold by Wittenstein: not a fork of the code you download, but a re-engineered implementation with IEC 61508 certification evidence. If a vendor tells you "FreeRTOS is GPL," they're quoting a decade-old fact.
The Mental Model: Tasks, Queues, and the Tick
A FreeRTOS application is a set of tasks, each an infinite loop with its own stack and priority. The scheduler runs the highest-priority ready task, always. Equal priorities round-robin on the tick, typically 1 kHz.
The idiomatic design pattern is embarrassingly simple: interrupts do almost nothing, tasks do the work, queues connect them. An ISR captures the event, posts to a queue with the FromISR variant, and returns; a task blocked on that queue wakes and processes. Blocked tasks cost zero CPU. The classic beginner mistake is polling with vTaskDelay(1) loops, which burns power and hides race conditions that a queue would have made structurally impossible.
Two decisions matter more than everything else. Stack sizing per task: too small corrupts memory in ways that crash somewhere unrelated hours later; use uxTaskGetStackHighWaterMark and stack overflow checking (configCHECK_FOR_STACK_OVERFLOW) during development, always. And mutex versus binary semaphore: mutexes implement priority inheritance, semaphores don't, so use a mutex for mutual exclusion, every time. The Mars Pathfinder lander demonstrated what happens otherwise, and that story is worth ten textbooks.
Memory Allocation: Pick Your Heap Deliberately
FreeRTOS ships five heap implementations, heap_1 through heap_5, and the choice is a real engineering decision. heap_1 only allocates, never frees: perfect for systems that create everything at boot and run forever, because it cannot fragment. heap_4 coalesces adjacent free blocks and is the general-purpose default. heap_5 spans multiple non-contiguous RAM regions, which matters on parts with split SRAM banks. The fully static alternative, configSUPPORT_STATIC_ALLOCATION, removes the heap entirely, and safety-certified projects use it because "cannot run out of memory at runtime" is a provable claim.
What FreeRTOS Is Not
It is not a networking stack, a filesystem, or a security boundary; those come from add-on libraries (coreMQTT, FreeRTOS+TCP, LittleFS) and grow the binary well past the 9 KB kernel. A full IoT stack with OTA and TLS lands closer to Zephyr's footprint, so compare complete builds, not kernel brochures. It is also not certified out of the box: the certification path is SafeRTOS money. And it is not the right tool below a certain simplicity floor, a superloop still beats a scheduler for single-task firmware.
Frequently Asked Questions
Is FreeRTOS actually free for commercial products? Yes, unambiguously, since the 2017 MIT relicense. Ship it closed-source, no fees, no copyleft. Attribution in your documentation is the only obligation.
FreeRTOS or Zephyr? FreeRTOS is a kernel you assemble a system around; Zephyr is an integrated OS with Devicetree, networking, and Bluetooth in-tree. Solo teams shipping one product on one chip usually move faster with FreeRTOS. Teams targeting many boards, or leaning on BLE/Thread/Matter, amortize Zephyr's steeper learning curve. Our RTOS selection matrix scores this properly.
What does AWS get out of it? A first-class path from MCUs into AWS IoT: the coreMQTT/Device Defender libraries make the cloud integration frictionless. The kernel stays genuinely open; the business model is gravity, not lock-in.
How big is a real FreeRTOS application? The kernel is 4-9 KB flash and under 1 KB RAM baseline, plus roughly 100-200 bytes of RAM per task for the TCB before your stacks. A practical sensor node with networking lands in the 100-300 KB range, dominated by everything that isn't the kernel.
