Eclipse ThreadX: an MIT-licensed RTOS for deeply embedded targets

What Eclipse ThreadX is for, and who it is not for

Eclipse ThreadX is a real-time operating system written in C and aimed at deeply embedded applications. The README lists its services as advanced scheduling, message passing, interrupt management and messaging, with a picokernel architecture, preemption threshold and event chaining among the named features. That vocabulary points at a specific audience: firmware engineers working on microcontrollers where RAM and flash are measured in kilobytes and where a context switch has a bounded cost you have to be able to reason about.

It is not a general purpose operating system and it is not a Linux replacement on a Cortex-A application processor, even though the port list includes cortex_a5, cortex_a12, cortex_a15, cortex_a17, cortex_a34, cortex_a35, cortex_a53 and cortex_a55. Those ports exist because some designs run an RTOS on an application core alongside a larger system. If what you actually need is processes, virtual memory and a package manager, ThreadX is the wrong layer.

The licence is MIT, which matters for the adoption decision. There is no copyleft obligation on the kernel source you link into your firmware image, and no per-unit royalty structure described in the repository. That is a legal posture, not legal advice; if your product ships in a regulated market, your own counsel decides what the MIT text means for your combination of kernel, vendor SDK and application code.

Picokernel, preemption threshold and event chaining as concrete mechanisms

The README names three design choices rather than describing them in detail, so treat the names as the boundary of what the repository states. A picokernel architecture means the kernel services are not layered through a monolithic core; the practical consequence is that unused services do not have to be pulled into the image, which is how a kernel ends up small enough for a Cortex-M0 class part. Preemption threshold sits between strict priority preemption and no preemption at all: a thread can be given a threshold above which it will not be preempted, which reduces the number of context switches in a system where a high-priority task wakes often but holds a lock briefly. Event chaining lets a thread wait on a combination of events rather than a single semaphore or queue, which removes some of the hand-rolled state machines that appear in RTOS applications otherwise.

The repository is split so that the portable core and the machine-specific code are separate. common/ holds the core ThreadX files, common_smp/ holds the SMP variant, common_modules/ holds the module support, and ports/ holds architecture and compiler specific files. Inside a port directory the layout is consistent: for cortex_m7 there are iar, ac6 and gnu subdirectories, each with an inc/ containing tx_port.h for that architecture and a src/ with the source files, plus example build files. That structure is the real answer to "how do I port this": you do not port the kernel, you fill in the port, and the repository shows you a worked example per compiler.

The ports_arch/, ports_smp/ and ports_module/ directories at the top level mirror that split for the architecture-specific, SMP and module builds. If you are evaluating the SMP variant, read common_smp/ and ports_smp/ together; the core files are not the same set.

Getting ThreadX into a build and starting a first thread

The README does not give a standalone install command. It states that Eclipse ThreadX has been integrated into semiconductor SDKs and development environments from STMicroelectronics, NXP, Renesas and Microchip, and points at a separate getting-started repository and a samples repository with development boards you can build and test with. So the first step is not a package manager. It is either starting from a vendor SDK that already contains ThreadX, or working from this repository's CMake files.

The build entry point named in the repository layout is the CMakeLists.txt at the repository root, with further CMake files under cmake/. The README does not document a command line for it, so the toolchain is something you supply through your own CMake invocation rather than a flag printed in the README.

For a bare-metal target you also need a port, and the port directory tells you which files to add. For a Cortex-M7 build with the GNU toolchain, the relevant files live under ports/cortex_m7/gnu, with tx_port.h in inc/ and the source files in src/.

The application side starts with tx_application_define, which the kernel calls during startup. The repository ships samples/demo_threadx.c as the worked example, and the README's own code sample references _tx_initialize_kernel_enter as the ThreadX entry function that eventually reaches it. Threads are created there and then started by the scheduler. The function names and constants below are the ones the README's sample and the repository's header conventions use; check samples/demo_threadx.c for the version matching the tag you checked out.

#include "tx_api.h"

TX_THREAD my_thread;

VOID my_thread_entry(ULONG thread_input)
{
    while (1)
    {
        tx_thread_sleep(100);
    }
}

What you should see after flashing is the thread running and sleeping on a 100-tick interval. The kernel calls tx_application_define with the first unused memory address, and that is where the thread creation call belongs, so the entry function above is registered there rather than at file scope.

Where ThreadX gets in the way

The most honest limitation is in the README itself, in the Branches and Releases section. The master branch carries the most recent code with all new features and bug fixes, and it does not represent the latest General Availability release. Official releases are tagged, for example v6.2-rel, and pushed to the releases tab. If you build from master you are building code that has not been frozen against your board, and the README says so rather than hiding it. Pin a tag.

The second limitation is visible in the file headers. The README explains that when you see xx-xx-xxxx, 6.x or x.x in a function header, the file is not officially released yet and the header will be updated in the next release. That is a documentation convention, not a defect, but it means the source you are reading may describe behaviour that has not been frozen. Reading a header comment is not the same as reading a specification.

Third, the port list is long but not universal, and the list shown in the README is truncated. Before designing a board around ThreadX, confirm that ports/ contains a directory for your core and that it contains a subdirectory for your compiler. A port for cortex_m4 with gnu does not imply a port for cortex_m4 with your vendor's proprietary compiler.

Finally, ThreadX is a kernel. Message passing, scheduling and interrupt management are in scope; a filesystem, a TCP/IP stack, a USB stack and a POSIX layer are not, unless you add the corresponding modules. Teams that expect an out-of-box application platform will spend their first weeks assembling one.

ThreadX against FreeRTOS and Zephyr

The comparison people search for most is ThreadX versus FreeRTOS, and the difference that matters in this repository is packaging. ThreadX ships with a CMakeLists.txt at the root, a cmake/ directory, and a ports/ tree that carries example build files for IAR, ac6/Keil and GNU side by side for the same core. FreeRTOS distributes a smaller kernel with a different porting convention and a different set of vendor integrations; the two are not interchangeable at the build-system level, so switching costs sit in your build files and your port, not in your application logic.

Against Zephyr the split is architectural rather than stylistic. Zephyr is built around a configuration system and a device tree model that pulls a large set of subsystems into one build. ThreadX is a kernel with optional modules and a per-architecture port you fill in. If your product is a single-purpose device on a small MCU, ThreadX's model asks less of you. If your product needs a broad set of drivers and subsystems configured declaratively, Zephyr's model is doing work that ThreadX leaves to you.

A third comparison is historical. ThreadX was formerly Azure RTOS, and the search data still contains threadx vs azure rtos. The repository is now under the eclipse-threadx organisation with an MIT licence, and the README links to vendor pages that still carry the Azure RTOS name. Expect to see both names in SDK documentation for a while.

Maintenance, releases and upgrade cost

The repository is not archived. The last push was on 2026-09-23. The most recent tagged releases are v6.5.1.202602a_rel (Eclipse ThreadX v6.5.1.202602a) on 2026-06-08, v6.5.1.202602_rel (Eclipse ThreadX v6.5.1.202602) on the same day, and v6.5.0.202601_rel (Eclipse ThreadX v6.5.0.202601) on 2026-03-06. The CHANGELOG.md at the repository root is where the differences between those tags are recorded, and it is the file to read before moving a shipping product from one tag to the next.

The upgrade cost is dominated by the port, not the kernel. Core files under common/ change with releases, but the files under ports/<arch>/<toolchain>/ are the ones that touch your interrupt vectors, your periodic timer source and the system stack pointer. The README's own header example describes _tx_initialize_low_level as responsible for setting up interrupt vectors, setting up a periodic timer interrupt source, saving the system stack pointer for use in ISR processing, and finding the first available RAM address for tx_application_define. That is the file to diff first on any upgrade, because a change there is a change to your startup path.

On licensing, the MIT identifier means the kernel source carries no copyleft requirement. What the repository does not do is tell you how the licence interacts with the vendor SDK you are building against, since those SDKs are distributed under their own terms by STMicroelectronics, NXP, Renesas and Microchip. That combination is the question to put to your own counsel, not something this repository answers.

Editorial conclusion

Adopt Eclipse ThreadX if your board is already covered by a vendor SDK integration and you want an MIT-licensed kernel whose ports you can read as C source. Do not adopt it expecting a POSIX userspace or a bundled middleware stack; ThreadX is a kernel plus optional modules. Before committing, verify that ports/<your_arch>/<your_toolchain> exists for your exact core and compiler, check whether the CMakeLists.txt in the repository root covers your build, and read CHANGELOG.md against the tag you plan to pin.

Frequently asked questions

Official sources

1. eclipse-threadx/threadx on GitHub
2. License: MIT
3. Project website
4. README
5. Releases