SuperTinyKernel RTOS

STK operates in two fundamental modes. In soft real-time mode, tasks cooperate by voluntarily yielding execution time, with the kernel applying preemptive scheduling to prevent any task from starving others. In hard real-time (HRT) mode, tasks are periodic with guaranteed execution windows and strict deadlines enforced by the kernel; any deadline violation triggers a deterministic failure callback. Tasks may follow either a static model, in which all tasks are created once at startup, or a dynamic model, in which tasks may be created and exit at runtime. Tick and tickless modes STK supports two timer models for context switching. In the default tick-based mode a hardware timer fires at a fixed frequency and the scheduler is evaluated on every interrupt, providing simple and predictable behaviour suited to systems where timing granularity is fixed and power consumption is not a primary concern. In tickless mode, kernel suppresses the periodic interrupt and instead programs the hardware timer dynamically so that the next interrupt fires precisely at the nearest upcoming event, such as a task wakeup or deadline. This keeps the CPU in its sleep state for as long as possible, substantially reducing power draw in battery-powered or infrequently active systems while preserving full timing correctness. Scheduling strategies STK supports all major scheduling strategies, including round-robin scheduling (RR), smooth weighted round robin (SWRR), fixed-priority round-robin (FPRR), rate-monotonic scheduling (RM), deadline-monotonic scheduling (DM), and earliest deadline first scheduling (EDF). The EDF implementation selects the runnable task with the smallest remaining deadline and is provably optimal for single-processor systems. Both RM and DM implementations include worst-case response time (WCRT) schedulability analysis. Custom scheduling strategies can be provided by implementing a dedicated C++ interface. STK also provides two proprietary Mixed criticality scheduling strategies available under a commercial license. The two-level Mixed-Criticality Adaptive Scheduler (MCAS) partitions tasks into low- and high-criticality groups, distributes CPU time between them at a configurable ratio using a token-bucket mechanism, and automatically suspends low-criticality tasks when a high-criticality task overruns its execution budget, resuming normal operation after a configurable cooldown period. The four-level variant (MCAS4) generalises this model to four independent criticality levels with cascade escalation and recovery, and adds an elastic CPU share adaptation mechanism driven by a per-group exponential moving average (EMA), also termed an exponentially weighted moving average (EWMA), execution-pressure estimator, allowing groups under sustained load to borrow CPU share from lower-criticality neighbours without altering worst-case response time guarantees. ==Synchronization==

STK provides a rich synchronization API comprising mutexes (including a recursive variant and a reader-writer variant with a writer-preference policy to prevent writer starvation), counting semaphores with a direct-handover signalling policy, condition variables, binary event objects supporting manual-reset and auto-reset modes, 32-bit event flag groups allowing tasks to wait on any one or all of a set of flags, critical sections, spinlocks, a thread-safe typed FIFO pipe, and a fixed-capacity message queue suitable for heterogeneous payloads. Custom synchronization objects can be integrated directly with the kernel scheduler. Synchronization support is optional and can be omitted at compile time, causing the compiler to strip all related code and reduce flash and random-access memory (RAM) consumption. ==Memory==

STK includes a deterministic, fragmentation-free memory allocation module designed for systems where dynamic heap allocation is undesirable or prohibited by coding standards such as MISRA C++. It provides a fixed-size block allocator that manages a pool using an intrusive free-list structure, yielding O(1) allocation and deallocation with a minimal critical section and zero fragmentation over any run duration. ==Thread-local storage==

STK provides per-task thread-local storage (TLS) through a dedicated CPU register. This allows each task to maintain private state without any locking or dynamic allocation, with no runtime overhead beyond a register read or write. ==Task privilege separation==

On ARM Cortex-M cores implementing the memory protection unit (MPU) – Cortex-M3 and newer – STK supports hardware-enforced privilege separation between tasks. Trusted driver tasks run in privileged thread mode with full peripheral access, while application or untrusted tasks run in unprivileged mode where any direct peripheral register access triggers a hardware fault. This isolates potentially attacker-controlled code paths, such as tasks that parse network, USB, or firmware-update payloads, from safety-critical hardware state. All kernel services remain accessible to unprivileged tasks. ==Multi-core support==

STK supports multicore embedded microcontrollers through an asymmetric multiprocessing (AMP) model, with one independent kernel instance per physical core. This design eliminates cross-core synchronization overhead inside the kernel, keeps all kernel data structures in the local core's L1 cache, and allows each core to operate with its own scheduling policy and timing domain – for example, one core running hard real-time tasks while another handles soft real-time communication or logging. Cross-core communication is handled via the synchronization primitives described above, which are designed to be safe for use across multiple kernel instances. ==CMSIS-RTOS2 compatibility==

STK provides a complete CMSIS-RTOS2 compatibility layer that maps the standard ARM CMSIS-RTOS2 C API onto the STK C++ kernel. This allows STK to serve as a drop-in RTOS backend for any project targeting the CMSIS-RTOS2 interface, including code generated by STM32CubeMX, MCUXpresso, and other CMSIS-aware middleware stacks, without modification to application code. ==FreeRTOS compatibility==

STK provides a complete FreeRTOS compatibility layer that maps the standard FreeRTOS C API onto the STK C++ kernel. This allows STK to serve as a drop-in backend for any project that targets the FreeRTOS interface, enabling migration of existing FreeRTOS codebases to STK with minimal or no application-level changes. The wrapper covers approximately 99% of the FreeRTOS C API surface across all major API groups – heap and port, kernel control, task management, queues, queue sets, semaphores and mutexes, software timers, event groups, task notifications, thread-local storage, stream buffers, and message buffers. Internally, the wrapper uses STK's fixed-priority round-robin scheduling strategy to replicate FreeRTOS scheduling semantics exactly. Beyond API compatibility, the wrapper provides a migration path to STK-native capabilities. After integration, the scheduling strategy can be changed to EDF, SWRR, or a mixed-criticality variant by modifying a single template parameter, and hard real-time deadline enforcement, first-class MPU privilege separation, and the x86 development emulator become available without further changes to application code. ==Hardware support==

STK targets ARM Cortex-M processors spanning ARMv6-M through ARMv8.1-M (Cortex-M0 through M55) and RISC-V RV32I and RV32E cores, including very small RAM devices using the compact E base ISA. Both soft and hard floating-point are supported. Supported compilers include GCC and Clang/ARMCC 6 and later. The kernel depends only on CMSIS (for ARM targets) and a minimal surface of the MCU vendor BSP. STK requires only a supported CPU architecture and does not depend on any specific board. ==Development and testing==

STK includes an full-featured x86 scheduling emulator for Windows, allowing the same application code to be built, debugged using Visual Studio or Eclipse CDT, and unit-tested on a desktop PC without physical hardware, including the ability to mock or simulate peripherals. The scheduler logic carries 100% unit test coverage, and all commits are verified against QEMU targets for each supported architecture. Scheduling activity can be visualised with SEGGER SystemView. ==Performance==

Benchmarks conducted on an STM32F407G-DISC1 (STM32F407VG, Cortex-M4 at 168 MHz) in March 2026 using GCC 14.2.1, comparing STK v1.05.3 against FreeRTOS V11.2.0 across a CRC32-based synthetic multi-task workload at size-optimised and speed-optimised compiler settings, showed the following results: • Throughput: STK consistently outperforms FreeRTOS, delivering approximately 12% more computational work in direct comparisons. Throughput remains nearly flat as task count scales from 4 to 16, indicating near-zero context-switching overhead. Speed-optimised builds yield a 31% throughput boost over size-optimised builds for STK, a larger gain than seen in FreeRTOS under the same conditions. • Scheduling jitter: In high-task-count scenarios STK exhibits approximately 17% lower scheduling jitter than FreeRTOS, making it preferable for timing-sensitive workloads. • RAM: STK uses approximately 6.9 KB of RAM across all tested configurations, roughly 21% less than FreeRTOS (approximately 8.8 KB). • Flash: The C++ template architecture results in a larger flash footprint (approximately 14–23 KB depending on optimisation level) compared to FreeRTOS (approximately 12.6–14.5 KB), which is the principal trade-off of the design. ==License==

SuperTinyKernel is released under the MIT License, permitting free use in commercial, closed-source, open-source, and academic projects. Neutron Code Limited offers professional services including safety-certification assistance (IEC 61508, IEC 62304, ISO 26262, DO-178C), custom architecture porting, real-time performance tuning, peripheral integration, SLA-backed commercial support, long-term maintenance contracts, and training for engineering teams. Custom and enterprise license agreements are also available for organisations with strict open-source procurement policies. ==See also==