threadx Snapshot
  • Industry Leader
  • Over 5.4 Billion Deployments
  • Small-footprint
  • 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 IEC 61508 SIL 4, IEC 62304 Class C, ISO 26262 ASIL D, UL/IEC 60730, UL/IEC 60335, UL 1998, and EN 50128 SW-SIL 4
  • MISRA-C:2004 and MISRA C:2012 Compliant
  • Supports most popular architectures
    (see below)
  • Supports most popular tools
ThreadX Architecture Support
  • ARM
    • ARM7, ARM9, ARM11
    • Cortex-M, Cortex-R, Cortex-A
    • Cortex-Axx 64-bit
  • AndesCore
  • Analog Devices
    • Blackfin BF5xx, BF6xx, BF7xx
    • SHARC
  • Cadence
    • Xtensa
    • Diamond
  • CEVA
    • TeakLite-III
  • EnSilica
    • eSi-RISC
  • NXP
    • ARM (LPC, i.MX, Kinetis)
    • 68K
    • Coldfire
    • PowerPC
  • Imagination
    • MIPS32 4Kx, 24Kx, 34Kx, 1004K
    • microAptiv, interAptiv, proAptiv
    • M-Class
  • Intel
    • ARM (Cyclone SOC, Arria 10 SOC)
    • NIOSII
    • x86PM
  • Microchip
    • ARM (SAM)
    • AVR32
    • PIC24
    • PIC32
  • Renesas
    • ARM (Synergy, RZ)
    • H8/300H
    • RX
    • SH
    • V850
  • Silicon Labs
    • EFM32
  • ST
    • STM32
  • Synopsys
    • ARC 600, 700
    • ARC EM, ARC HS
  • Texas Instruments
    • ARM (Tiva-C, Sitara, OMAP)
    • C5xx
    • C6xx
  • Xilinx
    • ARM (Zynq)
    • MicroBlaze
    • PowerPC


Green Hills MULTI 2000

With ThreadX Aware Debugging

The MULTI Software Development Environment from Green Hills Software works seamlessly with the ThreadX embedded real-time kernel from Express Logic, Inc., and provides detailed, kernel-aware information to developers.

MULTI for ThreadX is fully aware of all seven ThreadX kernel components and includes live easy-to-understand summary lists and detailed individual views of all ThreadX component types: Threads, Message Queues, Semaphores, Mutexes, Event Flag Groups, Memory Block Pools, Memory Byte Pools, and Application Timers.

Thread-Specific Debugging

Debugging can be performed on a specific thread. Thread-specific breakpoints can be set so that all other threads will continue past the breakpoint. This capability allows a single thread to be debugged even when it uses code that is common to multiple threads. Also, any thread's register context can be shown with a single button click. For solicited stack frames that result from service calls that suspend, only certain registers are saved. The others are explicitly marked "N/A" to indicate that no useful register contents are available.

Memory Analysis

MULTI for ThreadX contains enhanced views of memory block pools and byte pools intended specifically to help developers find problems with dynamic memory allocation. A single click from a memory pool window brings up a view of all memory blocks or fragments together with their location in memory, their current state - either in use or available, and, for byte pool fragments, their size. Observing dynamic memory allocation and fragmentation has never been more straightforward and detecting the reasons for byte pool fragmentation has never been easier.

Advanced Stack Checking

Stack overflow is another common problem that MULTI helps diagnose. MULTI's enhanced stack checking and monitoring features provide unprecedented ease-of-use.

In all thread views, a stack use indicator shows how much stack is currently in use by that thread. This information identifies threads that are using more stack space than anticipated, ideally before problems occur. Then, stack sizes can be adjusted to guard against overflow.

MULTI for ThreadX provides optional stack checking to ensure that thread stack sizes are appropriate. A slight modification to a user's project enables maximum stack use checking. Users can check stack use for a single thread or for all threads. In either case, a window displays the peak stack usage as determined by the highest point in the stack that was changed since the thread was created. Furthermore, because this maximum stack use checking occurs on the target itself, there is no need to upload large parts of target memory simply to check maximum stack usage.