A capability-based operating system that keeps one abstraction across MPU microcontrollers, MMU application processors and many-core servers — instead of coercing one hardware model into another.
▶See the design One capability abstraction: 64 KB microcontrollers, MMU application processors, and many-core servers.
The same capability abstraction runs on a 64 KB ROM / 20 KB RAM Cortex-M0+ and is designed for servers with hundreds of cores. No separate "edge kernel" and "cloud kernel".
🛡️
Capabilities with bounded lookup
A two-level capability table keeps CSpace depth at 2, with uniformly sized capabilities aligned to an 8-word boundary and transactional multi-capability operations.
⚙️
User-level scheduling
The kernel makes fast FPRR preemption decisions; budget replenishment and arbitrary hierarchical policies live at user level. Mechanism stays in the kernel, policy moves out.
⚡
Lock-free, bounded kernel calls
Every one of the 34 kernel calls is a bounded-time transaction built on atomic operations, with quiescence-based reclamation (RT-SMR) instead of coarse locks.
🔁
Migration-based IPC
A synchronous invocation migrates the client thread into the server and runs on the client's own time budget. Asynchronous signal endpoints act as per-processor counting semaphores.
🧱
Virtualization in two threads
Each vCPU is a user thread plus a higher-priority vector thread, giving type-II paravirtualization with as little as 6% overhead when hosting an RTOS.
Microkernels have existed for decades. What has been missing is a single abstraction that is honest about both microcontrollers and servers — not a cloud kernel squeezed onto an MCU, and not an RTOS pretending to scale to a datacenter.
RME starts from the mechanisms every machine actually has — capabilities, threads, address spaces, interrupts — and exports policy to user level. The result is one kernel that can be configured down to the code lines you need, with no unused drivers, no function-pointer indirection when a single instance exists, and no concealment of the hardware's real protection model.
64K / 20Kminimum ROM / RAM on STM32L071CB (Cortex-M0+)
264cycles for an intra-process yield (STM32F767IG, Keil)
~3 µstypical interrupt latency measured on microcontrollers
6%lowest virtualization overhead when hosting an RTOS
The top layer is entirely user-level: page servers, schedulers, vCPU monitors and drivers are ordinary components holding capabilities. The kernel below it is mechanism only — capability tables, FPRR preemption, IPC, kernel-object memory and interrupt delivery. The same kernel image is configured for an MPU microcontroller, an MMU application processor, or a many-core machine.
Match cloud-native operating systems on application processors while matching RTOSes on microcontrollers — with the same kernel design and the same programming model.
HYPERREUSABILITY
Components, not a monolith
Drivers and middleware are decoupled packages usable with RME, with another OS, or with no OS at all. Unused code is stripped, not carried into the image.
HYPERDEPLOYABILITY
Engineering, not a demo
Microcontroller projects are generated through RVM with real toolchains and debuggers. Production concerns are part of the design, not an afterthought.
GCC builds, average CPU cycles; the STM32F767IG with Keil reaches 264 / 600 / 484 / 282. These are measured on hardware, not simulated. The performance page has the full table and the caveats.
Microcontrollers need an MPU and use RVM as the user-level library and project generator. Application processors need an MMU; their ports and the RMC container layer are work in progress. The platforms page states exactly what is delivered and what is not.
The R4T1 technical reference manual is 271 pages (English) and 205 pages (Chinese). It covers capabilities, memory, processes, IPC, kernel-call implementation, porting, and the MISRA-C deviations.
