# RT-Thread: an RTOS built around a package index > A Chinese-originated real-time operating system whose real weight is not the kernel but the software package platform and the board support packages behind it. **RT-Thread/rt-thread** — RT-Thread is an open source IoT Real-Time Operating System (RTOS). https://rt-thread.github.io/rt-thread/ - Repository: https://github.com/RT-Thread/rt-thread - Website: https://www.rt-thread.io - Stars: 12,258 · Forks: 5,469 - Language: C - License: Apache-2.0 - Published: 2026-10-07 · Updated: 2026-10-07 · Language: en - Canonical page: https://hysenlabs.com/projects/rt-thread-rt-thread ## Two editions, one 1.2KB kernel RT-Thread ships in two shapes, and the difference is the first thing to understand. There is a Standard version and a Nano version, and Nano is the one aimed at genuinely constrained parts: the README states it needs 3KB of Flash and 1.2KB of RAM. The feature list repeats the same figures as the minimum kernel requirement, so 1.2KB of RAM and 3KB of Flash is the floor for the kernel, not for a working system. For resource-rich devices, the README describes a different route entirely: on-line software package management plus system configuration tools, used to cut the system down module by module and pull in packages. The stated goal is functions like a graphical interface with touch, and voice interaction, on IoT devices. The language choice is C, and the README is direct about why: easy to understand, easy to port across mainstream MCUs and module chips. It also says RT-Thread applies object-oriented methods to real-time system design, which in practice means kernel objects with handles, like threads, semaphores, mailboxes and timers, rather than a C++ runtime you have to fit in flash. ## The three layers, from kernel to package The architecture section breaks the system into three layers, and the descriptions are more informative than the diagram. The kernel layer is the RT-Thread kernel itself plus `libcpu/` and the board support packages. The kernel implements the objects you would expect: multithreading and scheduling, semaphores, mailboxes, message queues, memory management and timers. `libcpu/` holds CPU porting code, which the README describes as ARM, MIPS and RISC-V among others, and the BSP layer holds peripheral drivers. Above it, the components and service layer holds virtual file systems, the FinSH command line, network frameworks and device frameworks. The README's stated design goal here is high cohesion inside a component and low coupling between them, which is the standard phrase for a component tree where you can enable one thing without dragging in four others. Above that is the software package platform, and this is where RT-Thread is unlike most RTOS projects. Packages are described as general purpose components made of description information, source or library files, contributed officially or by developers, and the README puts a number on it: 450+ supported software packages. The repository itself has no `components/` entries per package; the tree holds the built-in component set, and the index is a separate hosted platform at packages.rt-thread.org. The source layout follows the same split: ```text bsp/ components/ documentation/ examples/ include/ libcpu/ src/ tools/ ``` The README's own catalogue table describes `tools/` as the script files for the RT-Thread command build tool, and `examples/` as sample code, including `pm/` for package management and `ymodem/` for file transfer over serial. ## Nearly 200 boards, and how you actually build The README claims RT-Thread has been ported for nearly 200 development boards. It also says most BSPs support the MDK and IAR development environments plus GCC, and that default MDK and IAR projects are provided, so you can add application code straight onto a working project. That last point matters more than the board count. The claim is not that RT-Thread runs on 200 chips, it is that for most of those chips someone has already done the clock tree, the linker script and the startup code and left you a project file. The cost of that work, when it is done for you, collapses. Each BSP follows a similar directory structure and most carry a `README.md` introducing the board and how to start using it. The repository runs a static build check across BSPs in CI, visible as the BSP build check badge, which is the mechanism that keeps two hundred configurations from silently rotting. The architecture list in the README names Cortex-M0 and M0+ with ST, M3 with ST and others, M4 with ST, Infineon, Nuvoton, NXP, Nordic, GigaDevice, Realtek and Ambiq Micro, and M7 with ST and NXP. The repository topics also carry `cortex-a`, `risc-v`, `mips` and `aiot`. Note that the architecture section in the README ends partway through the Cortex-M7 entry, so treat the topic list, not that section, as the wider picture of where the ports reach. ## Standards, toolchains and the 2006 origin RT-Thread was born in 2006, according to the README, and it describes itself as open source, neutral and community-based. That age shows in the best way: the interfaces it follows are the established ones. The feature list names POSIX and CMSIS as standard interfaces, plus a C++ application environment. Compiler support is likewise unglamorous and broad: GCC, Keil and IAR, which is what a Chinese MCU vendor's own toolchain situation looks like in practice. Two facts are worth separating. The first is that RT-Thread Studio is the configuration and build environment the README points at, not something in this repository. The `tools/` directory holds the command build tool's scripts, so there is a command line path, but the interactive configuration flow described in the architecture section is a separate tool. If you want to understand the workflow before installing it, that documentation is the place to read. The second is where the project comes from. The README is translated into Chinese, Spanish and German, and the repository is mirrored on Gitee with its own star badge, which is a fair signal that the centre of gravity of the community is in China. For most Western teams that is a practical detail rather than a political one, but it decides which mailing lists, forums and vendor relationships you will find when a port does not work. ## Where the README ends and the ecosystem begins The README is structured as an overview with links, and it is honest about the division. The architecture diagram is a PNG. The package index is a separate website, packages.rt-thread.org, which is where the 450+ packages actually live. The supported architectures and chip list is a separate page on the project's own site, rt-thread.io, linked as board.html. The documentation directory in the tree holds coding style and doxygen output. There is also a `ChangeLog.md` at the root, a `MAINTAINERS` file, an `AGENTS.md`, and a `Kconfig`, which is the tell that configuration is done the Linux way, through a menu system rather than a project file. Getting a board to build means selecting options in that menu, then running the build tool in `tools/`. The release history supports the community claim rather than contradicting it. v5.3.0 was published on 2026-09-10, v5.2.2 on 2025-10-31 and v5.2.1 on 2025-05-30, and the last push to the master branch is dated 2026-09-21. That is a release cadence of a few months on a project that started in 2006, which for an RTOS is healthy rather than fast. The licence is Apache-2.0, which matters for commercial firmware and for the vendor-modified forks such projects accumulate. ## Picking RT-Thread over FreeRTOS The honest comparison is against FreeRTOS, and it comes down to what you are buying. FreeRTOS is a small kernel with a scheduler and queues, and you assemble the rest yourself: filesystem, network stack, device model. RT-Thread ships those as components, and then adds a package index on top with 450+ entries. If your product needs an MQTT client, a TLS stack and a filesystem, RT-Thread is likely to hand you all three as selectable packages. The cost is legible in the same place. A component tree and a package index are more layers between you and the metal, so debugging a scheduling problem means reading more code that is not the kernel you chose. The looseness that lets you cut the system down also means you have to decide what gets cut, and a configuration mistake shows up as a link error or a missing symbol rather than a clear diagnosis. Second, the porting story is the deciding factor and it is asymmetric. If you are on an STM32 and something mainstream already works, either choice is fine and the ecosystem size tips it. If you are on a domestic Chinese MCU and nobody has written a FreeRTOS port for the part you picked, RT-Thread is not merely better, it is the only one of the two with a chance. Third, community geography. RT-Thread's answer to a question will often be in Chinese, on Gitee, or in a vendor group chat. That is workable and it is not equivalent to what you get elsewhere. ## Conclusion RT-Thread is a serious choice when you are shipping a microcontroller product in a market where Chinese silicon dominates, because the board support packages and the package index are the asset, and no Western project will match that board coverage. It is the wrong choice when your team needs to read every line of the kernel, when a missing component means writing it yourself, or when you need a support community in your own timezone. Verify three things in this order. Check whether a BSP exists for the exact part you have, since that is the work you would otherwise do. Then count how many of the components you actually need are in the package index rather than in the tree. Finally, read the RT-Thread Studio documentation before committing, because the configuration tooling described in the README lives outside the repository and the tool you use to build is part of what you are adopting. ## FAQ ### What is RT-Thread? An open source real-time operating system written mainly in C, born in 2006 and aimed at microcontrollers and IoT devices. The README describes it as neutral and community based, with a Standard edition and a Nano edition where the kernel needs 1.2KB of RAM and 3KB of Flash. ### What is the difference between RT-Thread Standard and RT-Thread Nano? Nano is the constrained edition, described in the README as needing only 3KB of Flash and 1.2KB of RAM, tailored with configuration tools. Standard is for resource-rich IoT devices and adds on-line software package management so components can be assembled and extended. ### Does RT-Thread have board support for my microcontroller? The README says RT-Thread has been ported for nearly 200 development boards, and the repository topics list ARM Cortex-M, Cortex-A, MIPS and RISC-V. Each BSP directory normally carries a README.md and default MDK and IAR project files, and the full architecture and chip list lives on the project's own site rather than in the README. ## Sources - [License: Apache-2.0](https://github.com/RT-Thread/rt-thread/blob/master/LICENSE) - [Project website](https://www.rt-thread.io) - [README](https://github.com/RT-Thread/rt-thread/blob/master/README.md) - [Releases](https://github.com/RT-Thread/rt-thread/releases) - [RT-Thread/rt-thread on GitHub](https://github.com/RT-Thread/rt-thread) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rt-thread-rt-thread