- Small-footprint (small as 2KB, automatic scaling)
- Fast execution (sub microsecond context switch)
- Supports all popular processors and tools (see below)
- TraceX system analysis support
- Advanced Technology:
- Event Chaining™
- Performance Metrics
- Execution Profiling
- Run-time and Static Stack Analysis
- Multicore Support (SMP and AMP)
- Downloadable Application Modules
- Memory Protection for Downloadable Application Modules
- Extensive ThreadX ecosystem
- Safety Certifications (DO-178B, FDA510(k), IEC61508, etc)
- Deployed in over 1,000,000,000 devices
- Full Source Code
- ARM DS-5
- Critical Link MityDSP/MityARM
- Energy Micro EFM32
- Fujitsu FM3
- Hitachi H8/300H
- Infineon XMC
- Microchip PIC24/dsPIC
- Microchip PIC32
- Nios II
- Power Architecture
- Renesas RX
- Renesas RZ
- Renesas SH
- Renesas V8xx
- ST Microelectronics STM32
- Synopsys ARC
- TI ARM
- TI MSP430
- Univers A2P
- Xilinx ARM
Downloadable Application Modules
Downloadable Application Modules
Downloadable application modules 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 Downloadable Application 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. Downloadable Application Modules for ThreadX 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 Application 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.