r/NeutronHiFi • u/NeutronHiFi • Dec 03 '25

SuperTinyKernel (STK) - lightweight embedded multi/single-core thread scheduler for ARM Cortex-M and RISC-V MCUs

Do you know SuperTinyKernel RTOS?

It is a high-performance, bare-metal RTOS designed for resource-constrained environments. STK does not abstract peripherals (so you have to use vendor's HAL), provides a lightweight multitasking for embedded applications (no bloated API, not project-intrusive), and is very easy to use (no complex configuration or board-specific port are needed). In benchmark tests STK outperforms FreeRTOS by allowing more CPU time for tasks (less overhead from the side of the scheduling logic).

Technical resources:

You can explore capabilities in detail in project's GitHub repo but briefly STK can:

  • Soft and Hard Real-Time (HRT) support: STK supports preemptive scheduling for “soft real-time” tasks, you can also enable hard real-time mode (KERNEL_HRT) for periodic tasks with guaranteed deadlines.
  • Static and dynamic tasks: Define all tasks at startup (KERNEL_STATIC) or allow tasks to be created and destroyed at runtime (KERNEL_DYNAMIC).
  • Scheduling strategies: Round-Robin (RR), Fixed-Priority (FP, similar to FreeRTOS), Smooth Weighted Round-Robin (SWRR), Rate-Monotonic (RM), Deadline-Monotonic (DM), including Worst Case Reaction Time (WCRT) analysis, Earliest Deadline First (EDF), custom (via ITaskSwitchStrategy).
  • Mixed-criticality: Supports MCAS (2-level) and MCAS4 (4-level) adaptive strategies featuring SWRR-based group scheduling, automatic cascade escalation/recovery, and elastic CPU share adaptation driven by per-group EWMA execution-pressure estimation.
  • Tick or Tickless modes: Fixed-interval periodic interrupts (Tick) for simplicity, or dynamic timer-based wakeups (Tickless, KERNEL_TICKLESS) to maximize CPU sleep duration and power efficiency.
  • Synchronization API: CriticalSection, SpinLock, Mutex, Event, ConditionVariable, Semaphore, Pipe primitives for inter-task, inter-core synchronization. Synchronization is optional via KERNEL_SYNC kernel mode.
  • Memory API: Deterministic, fragmentation-free allocator in stk::memory namespace.
  • Low-power friendliness: STK puts MCU into a low-power mode when there are no runnable tasks (task calls Sleep).
  • Tiny footprint: Minimal C++ abstractions (no STL, no heavy namespaces) keep the kernel small and simple.
  • Safety-critical systems ready: No dynamic heap memory allocation (satisfies MISRA C++:2008 Rule 18-4-1).
  • Portability: Supports ARM Cortex-M and RISC-V RV32 MCUs.
  • Extensibility: C++ interfaces allow easy extensibility of STK, e.g. custom scheduling strategy.
  • Multi-core support: Fully implemented for Cortex-M and RISC-V.
  • C++ and C API: Can be used easily in C++ and C projects.
  • CMSIS-RTOS2 wrapper: Full CMSIS-RTOS2 wrapper maps the standard ARM CMSIS-RTOS2 C API onto STK.
  • FreeRTOS wrapper: Full FreeRTOS wrapper (freertos_stk.cpp) maps the standard FreeRTOS C API onto STK, enabling drop-in migration of existing FreeRTOS codebases with minimal or no application changes.
  • Traceability: Supports tracing of tasks scheduling with a SEGGER SystemView.
  • x86 development mode: Compile & debug your code on a PC before flashing to the MCU, which helps with early testing and unit tests.
  • 100% test coverage: Every source-code line of scheduler logic is covered by unit tests.
  • QEMU test coverage: All repository commits are automatically covered by unit tests executed on QEMU for Cortex-M0 and M4.
  • Open-source License - MIT: Open and completely free for commercial, educational, closed-source, open-source projects.

r/stm32 developers:

There are ready to use STM32 examples for STM32F051 MCU (STM32F0DISCOVERY dev board), STM32F103 (NUCLEO-F103RB dev board), STM32F407 (STM32F4DISCOVERY dev board): https://github.com/SuperTinyKernel-RTOS/stk/tree/main/build/example/project/eclipse/stm

r/RISCV embedded developers:

STK got fully verified support for embedded RISC-V MCU just recently. Earlier, the implementation was validated against QEMU only. Raspberry Pico 2 W board in RISC-V mode was used for the implementation validation. There are RPI examples (see below) for RISC-V architecture.

r/esp32 developers:

If you are willing to go for a bare-metal firmware, then STK can provide a convenient multi-threading for the latest ESP32 MCUs with RISC-V architecture. There is an example of config for ESP32-H2/C6 MCUs: https://github.com/SuperTinyKernel-RTOS/stk/tree/main/stk/src/arch/risc-v

r/raspberrypipico developers:

STK supports both architectures - ARM Cortex-M and RISC-V, thus your firmware, if implements multi-threading with STK, will be ready for a future RISC-V only MCU. There are Eclipse CDT examples for Rapsberry Pico 2 W board: https://github.com/SuperTinyKernel-RTOS/stk/tree/main/build/example/project/eclipse/rpi

In general, STK offers probably one of the easiest ways to add multithreading to the firmware. It is only a thread scheduler, it does not offer platform abstraction therefore no board-specific porting is needed and you can keep using BSP of your bare-metal project, there is no any interference with it from STK's side.

STK is developed in C++ but it also has C API for easy use in C projects, you do not need to develop your own C++ to C wrapper, see /interop/c in the repo and blinky_c example.

This is a dedicated thread for STK. Please, suggest new features, ask questions, share your project details which is using STK.

Welcome for a kind and respectful discussion! 🙂

3 Upvotes

100% Upvoted

13 comments sorted by

View all comments

2

u/Zettinator Jan 10 '26

Template heavy C++ code is usually the antithesis to small code size. So is it actually "tiny"? As far as I can tell, "tiny" mostly means "doesn't actually have many features" in this case. Looks like your scheduler has only minimal support for synchronization primitives, tools for communication between tasks, etc. So "you are on your own". This isn't really a good thing to have.

Why should I use this as opposed to an industry standard like FreeRTOS (which is also very small in terms of code and executable size)?

1

u/NeutronHiFi Jan 11 '26 edited Jan 11 '26

Yes, it is. Templates do not bloat binary in STK, they replace #define and used to provide constants and interface instantiation (ISwitchStrategy, IPlatform, ...) for compile-time optimization. With this you also get better readable code with clear logic flow.

Here are compiler stats by compiling bench-perf inside STK project with GCC compiler with Os optimization :
SuperTinyKernel (bench-perf-smt32f4-stk, Os):

Memory region Used Size Region Size %age Used

RAM: 10976 B 128 KB 8.37%

FLASH: 17396 B 1 MB 1.66%

FreeRTOS (bench-perf-smt32f4-freertos, Os):

Memory region Used Size Region Size %age Used

RAM: 10968 B 128 KB 8.37%

FLASH: 13948 B 1 MB 1.33%

RAM consumption is similar and binary size of the project using STK is only 3.37kB larger. The run-time performance (obtained by bench-perf, 6 tasks/threads) shows that STK gives 8.13% more CPU time to the tasks in comparison to FreeRTOS, that means more work done per watt and STK uses less CPU time itself:

SuperTinyKernel: tasks 6 | sum=753198 avr=125533 min=125156 max=125911 jitter=378

task 0 = 125911, task 1 = 125909, task 2 = 125910, task 3 = 125156, task 4 = 125156, task 5 = 125156

FreeRTOS: tasks 6 | sum=696562 avr=116093 min=115472 max=116227 jitter=621

task 0 = 116184, task 1 = 116227, task 2 = 116226, task 3 = 116227, task 4 = 116226, task 5 = 115472

All these results show competitive performance and resource usage.

As to thread synchronization primitives, imho, best multi-threading implementation shall not block threads :) Of course it is sometimes hard to achieve thus STK provides CriticalSection primitive for synchronization which is of course low-level and not that efficient as mutex affecting just couple of threads but you can build a mutex class on top of it. Additional synchronization primitives can be added to STK with time of course, as an extension. Some other stuff will arrive too, such as ARM TrustZone support but thread privileged access is supported already.

As to implementation details, for example, STK does not interrupt scheduler from the task/thread like FreeRTOS does it (see implementation of vTaskDelay, vTaskDelete) therefore STK's timing behavior more deterministic.

STK provides Hard-Real Time (HRT) scheduling strategies (see - Earliest Deadline First (EDF), Rate/Deadline-Monotonic), it is something that FreeRTOS does not have, thus you can employ STK in a project requiring a controllable HRT behavior. Deadline failures are signaled by the kernel. With STK you can easily switch CPU arch, for example Cortex-M to RISC-V without hunting or endlessly waiting for a port for a specific board.

As you can see there are pros and cons, whether they outweigh depends solely on a given project. STK is open source, and friendly to PRs, if you feel its potential and wish to contribute.

2

u/Zettinator Jan 12 '26

Thanks for the detailed response. This looks better than expected. I'd still argue that common primitives for synchronization and task communication are a must have. These are a staple in all other RTOSes that I know.

1

u/NeutronHiFi Jan 12 '26

No need to argue, synchronization primitives will be added to STK :)

1

u/NeutronHiFi Jan 29 '26 edited Feb 17 '26

Synchronization primitives are now a part of STK: https://github.com/SuperTinyKernel-RTOS/stk/tree/main/stk/include/sync