- Industry Leader
- Over 5.4 Billion Deployments
- Fast, deterministic execution
- Simple, easy-to-use
- Advanced technology
- Multicore support (AMP & SMP)
- Memory Protection via ThreadX Modules
- Fastest Time-To-Market
- Royalty Free
- Full, highest-quality source code
- Pre-certified by TUV and UL to safety standards
- MISRA compliant
- Supports most popular architectures
- Supports most popular tools
- ARM7, ARM9, ARM11
- Cortex-M, Cortex-R, Cortex-A
- Cortex-Axx 64-bit
- Analog Devices
- Blackfin BF5xx, BF6xx, BF7xx
- ARM (LPC, i.MX, Kinetis)
- MIPS32 4Kx, 24Kx, 34Kx, 1004K
- microAptiv, interAptiv, proAptiv
- ARM (Cyclone)
- ARM (SAM)
- ARM (Synergy, RZ)
- Silicon Labs
- ARC 600, 700
- ARC EM, ARC HS
- Texas Instruments
- ARM (Tiva-C, Sitara, OMAP
- ARM (Zynq)
The ThreadX Module technology enable ThreadX-based applications to dynamically load and run additional application threads beyond those linked with the ThreadX kernel. Applications gain increased functionality without the cost of an increased footprint or additional memory. This technique also provides on-demand reconfiguration and application updates for deployed systems. The ThreadX Module technology ideally suits situations where application code size exceeds available memory, when new modules need to be added after a product is deployed, or when partial firmware updates are required.
In addition, each module may be protected from access by other modules, and/or prevented from accessing other modules or the kernel. This adds a powerful, yet efficient mechanism for protecting application threads, and their stacks, from corruption by other threads.
Most "small footprint" RTOSes employ an architecture based on a single executable image, where the application code is directly linked with the RTOS services it uses. This "monolithic" approach is efficient in both time and space, but it lack flexibility. Any changes to the application require re-linking with the RTOS and a new download of the entire image to the target.
In contrast, a 2-piece "OS/Application" structure is commonly found in desktop operating systems such as Windows and Linux, and in larger RTOSes, such as VxWorks and QNX. This approach also is used in mobile devices such as iPhone, iPad, where new "Apps" can be downloaded over the wireless network. Such architecture and functionality is not commonly found in small-footprint RTOSes like ThreadX. ThreadX Modules now provide a breakthrough for small-footprint applications, which require the reliability and responsiveness of ThreadX, but can now also use this new functionality to achieve an even greater range of features, maintainability, and modularity in their designs. Further, with Memory Protection, any desired level of granularity - from one thread to an unlimited number - can be protected and prevented from unintended access, eliminating a common cause of difficult to diagnose program crashes.
ThreadX Modules are collections of application threads, not linked with the ThreadX kernel, but instead loaded into target memory when needed. Such Modules use ThreadX kernel services via an interface with the Module Manager, an "agent," within the ThreadX kernel, that loads and initiates a module as well as fields and interfaces all module requests for ThreadX API services. Although there is only one copy of the Module Manager, there are no limits on the number of modules that can be loaded at the same time, and no limits on the number of threads in any one module. In this manner, the ThreadX kernel becomes a distinct execution entity, running continuously to serve Module requests.
If desired, for maximum efficiency, application threads can alternatively be linked with the ThreadX kernel and reside in target memory as part of its executable image. While this option avoids the need to reload the modules containing these threads, it increases the size of the resident kernel image, leaving less memory for use by Modules.