uC-OS3: a preemptive real-time kernel with a commercial licensing wrinkle

What the repository actually contains

The uC-OS3 repository is the source distribution of Micrium's µC/OS-III kernel, and the top-level listing is the quickest way to understand its shape.

There are nine entries. `Source/` holds the kernel implementation, `Ports/` holds the architecture-specific porting layers, `Cfg/` the configuration files, `Template/` a project template, and `Trace/` the trace and instrumentation facilities. `TLS/` is the thread-local storage support, and `README.rst` and `LICENSE` and `NOTICE` are the documentation and legal files.

The separation of `Source/` and `Ports/` is the important structural fact. The kernel proper is architecture-independent and the porting layer is where the CPU-specific code lives, which is what makes the portability claim plausible. A preemptive real-time kernel that has to run on many CPU architectures can only stay portable if the architecture-dependent parts are quarantined, and the directory layout shows that they are.

The `Cfg/` and `Template/` directories point at the other half of the product, which is that an RTOS is as much a configuration exercise as a code exercise. The kernel's behaviour, tick rate, number of task priorities, memory pools, and the like are all decided by configuration files rather than by editing the source, and the template directory is there so a new project starts from a known-good configuration rather than from an empty one.

The `TLS/` directory is a newer addition by the look of it, and it matters for a preemptive kernel because thread-local storage is exactly the feature that a preemption-heavy design makes expensive. A separate directory for it suggests it is treated as a distinct, self-contained concern.

The primary language is C, the default branch is `develop`, and the last push was on 2026-07-15.

The licence story has two halves, and the second one matters

The repository records the licence as Apache-2.0, and the readme sets out the rest of the picture, which is not simply an open source kernel.

The µC/OS RTOS was originally developed by Micrium, and Weston Embedded Solutions is now the official custodian for the µC/OS RTOS and Stacks software repository, formed by a team of former Micrium employees, with the stated purpose of ensuring it remains the trusted choice for embedded engineers around the world.

That custodial framing explains a lot about the repository. It is not a hobby project that happened to accumulate a licence file, it is the maintained source of a commercial product with a long history, and the readme is careful to say so.

The readme also lists a Commercial Licensing Option, pointing at the vendor's Cesium product page. That is the part an evaluator has to be careful with. A repository under Apache-2.0 and a commercial product with its own terms are two different things, and the practical question is what the commercial licence buys and whether the repository licence covers the customer's use. This is a question for the vendor's own licensing terms and for whoever reviews licensing in your organisation, not something the LICENSE file answers on its own. The presence of a `NOTICE` file next to the `LICENSE` file is the usual signal that attribution requirements are part of the deal, so read both.

The other point worth taking from the readme is the certification and deployment history, because it is the reason a team would choose this kernel over writing one. Micrium's µC/OS-II kernel has been certified for use in safety-critical applications and remains a respected favourite in the medical, aerospace and industrial markets, and the software components have been deployed in thousands of products worldwide.

What the documentation situation tells you about the product

The readme is short, and the reason is not that there is little to say. It is that the documentation is elsewhere, and the links are grouped in a way that tells you what kind of reader each is for.

There is Product Documentation and Release Notes, pointing at an Atlassian site at micrium.atlassian.net, which is where the manuals and the release history live. There is Technical Support, pointing at the vendor's support page. There are Example Projects, and a Who to Contact page.

So this repository is the source and the porting layer, and the manuals, the release notes and the support relationship are all vendor-provided and mostly behind the vendor's own infrastructure. That is the normal arrangement for a commercial embedded product, and it is the opposite of what you get with a kernel whose documentation lives in the same repository as the code.

The practical consequence for an evaluation is that you cannot judge this kernel from the repository alone. The API, the porting guide, the certification details and the upgrade path between kernel versions are all in the documentation site, and a project that intends to use this in a product needs an account for them.

The release history in the repository metadata is also worth noting. The newest tagged release is v3.08.02 from 2022-12-02, with v3.08.01 from 2021-05-04, and the last push was on 2026-07-15 against the `develop` branch. So the work is continuing on the development line while the tags are old, which is a common shape for a product where releases are driven by the vendor's own cadence and its certification process rather than by the repository's tags.

Preemptive scheduling is the design choice everything else follows from

The project description calls µC/OS-III a preemptive, highly portable and scalable real-time kernel, designed for ease of use on a huge number of CPU architectures, and the word preemptive is the one that decides what this kernel is for.

A preemptive kernel can suspend a running task at any point and run a higher priority one. That is what makes a real-time system real time: the response to a deadline does not depend on the task happening to reach a cooperative yield point. The cost is the set of problems preemption creates. A shared resource now needs priority inheritance, or a low priority task holding a lock can starve a high priority task that needs it. A shared variable now needs critical sections, because the preemption can land between a read and a write. Timing becomes something the whole design has to account for rather than something that falls out of a simple loop.

This is why the directory layout matters so much more here than in an ordinary library. The `Cfg/` directory holds the configuration that decides the tick rate, the number of priorities and the timing behaviour, and in a preemptive kernel those are not incidental values. A tick rate that is too low means a task can be delayed by up to a tick period, which is a deadline you have to design around. The number of priorities determines the memory a task control block occupies, because the kernel keeps a list of ready tasks per priority level, and that is a real cost on a microcontroller with a few tens of kilobytes of RAM.

The `Trace/` directory exists because of the same reasoning. A preemptive kernel's behaviour is timing dependent, so a debugger that can show you what happened is not a convenience but a diagnostic necessity, and isolating the trace facility in its own directory suggests it is designed to be compiled in or out.

So the evaluation question for a team is not whether preemption is a good idea in the abstract. It is whether their deadlines are tight enough to need it, and if the answer is no, this kernel is carrying machinery they do not need, and the configuration work to tune it that they do.

The portability claim follows from the same structure. Because the architecture-dependent code is confined to `Ports/`, adding a CPU means writing a port rather than touching the kernel, and the `Template/` directory gives a new project a starting configuration so the porting effort is about the port.

Where uC-OS3 is the wrong choice

The first case is a team that wants a self-contained open source real-time kernel with its documentation alongside it. The manuals and release notes are not in the repository, the support path is a vendor relationship, and the commercial option means the terms of use for a product deployment are not settled by the LICENSE file. A project that needs everything in one place, with a permissive licence and no vendor dependency, is looking at a different kernel.

The second case is a project that only needs a small cooperative scheduler. µC/OS-III is preemptive, which is the right choice for a hard real-time system and the wrong choice for a simple firmware that would run fine on a round-robin loop with a timer interrupt. Preemption brings priority inversion handling, a timer tick and a scheduler to reason about, and the configuration work that goes with it.

The third case is a team with no existing Micrium toolchain and no appetite for one. The kernel ships with a configuration system and a template that assume the vendor's development environment, and a project that would rather use the Arm or RISC-V toolchain it already has, with a different debugging setup, will find the porting layer is a starting point rather than a finished port.

The fourth is a project that needs the full protocol stack rather than the kernel. The readme is clear that µC/OS features support for TCP/IP, USB-Device, USB-Host and Modbus, as well as a file system, but those are separate components in the wider µC/OS and Stacks offering, and this repository is the kernel. A project that needs TCP/IP is looking at the stacks, not at this tree.

One last practical point for anyone reading the tree. The `Ports/` directory is where the architecture support actually lives, so the first thing to check in an evaluation is which CPUs are present there and which versions of them are current, because a port for a specific silicon family ages in a way the kernel core does not.

Editorial conclusion

The repository fits an embedded engineer who already uses the Micrium toolchain and wants the kernel source, the porting layer and the example projects in one place under an Apache-2.0 licence, and it fits a team evaluating a certified real-time kernel. It does not fit a team that needs the product documentation, since the manuals and release notes sit behind the vendor's own site, and it does not fit an organisation that has to buy the commercial licence without knowing in advance what that costs. Before you plan around it, read the NOTICE file and the commercial licensing page, because the repository licence and the commercial product terms are two different things, and check which kernel version the porting layer in `Ports/` actually covers.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. weston-embedded/uC-OS3 on GitHub