CMSIS-FreeRTOS: the CMSIS-RTOS2 face of the FreeRTOS kernel

An adaptation layer, not a fork of the kernel

CMSIS-FreeRTOS is the CMSIS-RTOS adoption of the FreeRTOS kernel, version 11.2.0, as it is released as a Software Pack on keil.com/pack. The primary language is C, and the documentation lives at arm-software.github.io/CMSIS-FreeRTOS.

The wording matters for how you use it. This is an adoption, which is to say the kernel sources are carried in the repository and an adaptation layer sits on top of them, exposing the kernel through the CMSIS-RTOS Version 2 interface. It is not a divergence of FreeRTOS with its own roadmap.

Why the CMSIS-RTOS2 interface is the point: it is a vendor-neutral abstraction for RTOS APIs, so application code written against it can move between RTOS implementations without rewriting every call site. For a team that already works in that world, an adaptation that maps CMSIS-RTOS2 thread, timer and synchronisation calls onto FreeRTOS primitives is exactly the missing piece, and taking it from Arm means it tracks the interface rather than a particular vendor's IDE.

The audience is therefore firmware developers on Cortex-M who want a portable RTOS API, plus the toolchain teams who package it.

The repository is hosted under Arm-Software on GitHub, with the main branch used for pull requests and Issues used for feedback and problem reports, as the README states.

A pack source tree, with the kernel and the adaptation kept apart

The directory structure in the README is the fastest way to understand what this repository is.

Source holds the FreeRTOS Kernel source code, CMSIS holds the CMSIS-FreeRTOS related files, and inside it CMSIS/RTOS2/FreeRTOS/Config holds the CMSIS-FreeRTOS configuration file, CMSIS/RTOS2/FreeRTOS/Source holds the CMSIS-FreeRTOS source code, and CMSIS/RTOS2/FreeRTOS/Examples holds the CMSIS-FreeRTOS example projects. Documentation is the source of the documentation, and there is an Overview directory at the root alongside the pack descriptor ARM.CMSIS-FreeRTOS.pdsc.

That separation is the architecture. The kernel is upstream code that changes on upstream's schedule, the adaptation is Arm's code, the configuration file is where you set the port and the kernel options, and the examples are working applications built against the whole thing. When you debug a problem in your application, knowing which of those four directories it lives in saves hours.

The .pdsc file is the pack descriptor, the metadata format the CMSIS pack system uses to describe components, dependencies and files. It is the reason the repository is not just a source tree, and the reason the build tooling at the root exists.

The kernel version question deserves care. The README states that the repository contains the adoption of FreeRTOS-Kernel Version 11.2.0, and the release list shows CMSIS-FreeRTOS 11.1.0, 11.2.0 and 11.3.0, the last dated 2026-05-18. The pack version and the kernel version it carries are separate numbers, so before you build anything, check which kernel tree is actually in the Source directory of the revision you take.

gen_pack.sh builds the artefact, gen_doc.sh builds the manual

The README describes this GitHub development repository as containing all the sources needed to successfully build the pack. That is the build model: you do not consume the repository directly, you generate an installable pack from it.

The entry point is a bash script named gen_pack.sh, and the README says it builds the complete pack for installation and also generates the documentation. The documentation can be produced on its own with a second bash script, gen_doc.sh, located in ./Documentation/Doxygen.

So the two commands a contributor needs are:

gen_pack.sh
gen_doc.sh

Doxygen being the tool behind the documentation is not a surprise given the directory name, and it explains why the documentation lives in a separate top-level directory with its own sources rather than inside the CMSIS tree.

The scripts sit at the root of the repository, next to the pack descriptor, and the .ci/ directory and the .github/ directory hold the automation. The build pack workflow is one of the CI jobs named in the badges at the top of the README, alongside Build Examples and RTOS2 Validation, which are the other two.

For a user, the practical step is the other one: install the pack from keil.com/pack into your toolchain, then pull in the CMSIS-FreeRTOS component and let the pack manager resolve the kernel sources and the adaptation for you.

Where the adaptation actually lives

If you are debugging or extending, the interesting files are in CMSIS/RTOS2/FreeRTOS/Source, and the first place to look for behaviour changes is CMSIS/RTOS2/FreeRTOS/Config, the configuration file.

The structure mirrors the CMSIS-RTOS2 layout rather than the kernel's, which is the point of the whole exercise. A CMSIS-RTOS2 application calls the RTOS2 interface, the adaptation in that Source directory translates those calls into FreeRTOS primitives, and the kernel in Source does the scheduling. The Config directory holds the settings that decide how the two halves are wired together for your part and your toolchain.

The Examples directory is where the arrangement is demonstrated. Example projects built against the pack are the best documentation for a CMSIS-RTOS2 user, because the API is only useful in a real project shape, with threads, timers and synchronisation objects started in a defined order.

The RTOS2 Validation workflow in the CI badges is the other half of the story. A CMSIS-RTOS2 adaptation is only useful if it actually implements the interface as specified, so a validation job that checks the implementation against the RTOS2 tests is the mechanism that keeps the adaptation honest. That job is named in the README badges, along with the examples build and the pack build.

For a team, the practical consequence is that this project is maintained as a port with conformance in mind, not as a patched kernel.

The licence changes depending on which directory you ship

The README describes a split licence, and it is a real one rather than a formality.

The FreeRTOS kernel source files are released under the MIT open source license, with the details in Source/LICENSE.md. The rest of the repository content is covered by the Apache 2.0 license, in the LICENSE file at the root.

The two badges at the top of the README, one for Apache-2.0 and one for MIT, point at that same root LICENSE file, so the split is recorded in one place as well as in the two referenced files.

In practice this is a clean arrangement. The kernel is MIT, which is the licence the upstream FreeRTOS project uses and the one most firmware vendors are already comfortable with, and the Arm-authored parts are Apache-2.0, which includes the patent grant that some commercial teams look for in a vendor contribution. What you must not do is assume the whole tree is one or the other without reading which directory a file comes from.

This is not legal advice, just a note that the answer to the question depends on the file, and that the repository gives you a pointer to the right licence in each case.

Maintenance: pack releases and a recent push

The release history shows a steady annual cadence with a long gap in the middle. CMSIS-FreeRTOS 11.1.0 is dated 2024-04-24, 11.2.0 is dated 2025-04-25, and 11.3.0 is dated 2026-05-18. The last push to the repository was on 2026-09-01.

Two observations. The numbering is annual, one major version per year, and the two most recent releases are close to a year apart, so this is a slow-moving artefact by design rather than a project that patches weekly. And the last push comes after the 11.3.0 tag, so the branch contains work that is not in a tagged pack release yet.

Because the artefact is a pack, the release cycle is tied to the pack ecosystem rather than to a library version number. A pack release has to be published, indexed and made available for installation, and downstream users pick it up through the pack manager rather than by pointing a build system at a commit. That is convenient for users and inconvenient for anyone who wants the newest source immediately.

The kernel version inside the pack moves separately, since the kernel upstream and the adaptation here are maintained by different parties on different schedules. If a specific FreeRTOS kernel fix matters to you, check the Source tree in the revision you plan to use rather than assuming the pack version tells you.

When the pack is the wrong shape for your build

The honest limitation of this project is its delivery model, and it is worth being concrete about it.

The primary artefact is a Software Pack, consumed through the CMSIS pack tooling that Keil and other toolchains provide. If your build is a Makefile or CMake project outside that world, there is no documented path in this repository for consuming it directly, because the README only describes generating the pack and the pack is what gets installed. You can still vendor the sources, since they are in the tree, but the pack metadata, the component dependencies and the update story are all part of what the pack manager gives you, and you would be rebuilding that yourself.

Second, the scope is FreeRTOS on CMSIS-RTOS2, not RTOS generally. If your goal is a portable RTOS abstraction with several vendors behind it, this project is one of the implementations, and the value is in the interface being standard rather than in the kernel being special. If your goal is the newest FreeRTOS features, the upstream kernel project is the place to look, and this adaptation follows it with a delay of a release cycle.

Third, the documentation is generated rather than hand written, which suits reference documentation and less well suits tutorials. The site at arm-software.github.io/CMSIS-FreeRTOS is where the generated output lands, and the example projects in CMSIS/RTOS2/FreeRTOS/Examples are the more useful learning content when you are new to the CMSIS-RTOS2 API.

Editorial conclusion

CMSIS-FreeRTOS suits firmware teams that want FreeRTOS behind the CMSIS-RTOS2 API, particularly anyone already consuming software packs in a Keil or CMSIS pack toolchain, because it is delivered and updated as a pack with matching examples and validation jobs. It does not suit a team that wants a plain library to drop into a Makefile or CMake project, since the primary artefact is a pack and the build scripts exist to generate that pack, and it does not suit you if you need a kernel version other than the one this adaptation is built on. Check three things before you adopt it: which FreeRTOS kernel version the adaptation in the tree is based on, since the README describes the adoption of kernel 11.2.0 while the release list shows CMSIS-FreeRTOS 11.3.0, whether your toolchain can consume the pack, and which licence applies to the files you actually ship, since the kernel sources are MIT and the rest of the repository is Apache-2.0. The last push to the repository was on 2026-09-01.

Frequently asked questions

Official sources

1. ARM-software/CMSIS-FreeRTOS on GitHub
2. Issues
3. Project website
4. README
5. Releases