Frédéric Desbiens 1d3f3f8e4c Measured the cache benchmark at four alignments, because one is not enough (#631)
This benchmark was bimodal and reported a single number, which made it worse
than no benchmark. The same workload on the same silicon reports either 24%
cache benefit or none at all, decided only by where the loop falls inside a
64-byte line -- and therefore by any unrelated change that shifts code
ahead of it. Two nop instructions added to entry.S were enough to flip it.

That is not a hypothetical. A run of conclusions drawn from this probe turned
out to be measuring code layout: an interrupt-handler comparison, a claim that
enabling a second TCM bank costs all cache benefit, and a follow-up claim that
what mattered was when the TCM region register was written rather than what it
contained. The last of those was reported to NXP as a defect and has had to be
withdrawn. Enabling CTCM and adding two nops produce identical results, to the
digit, because the only measurable consequence of the enable was the eight
bytes of instructions it added.

Four copies of the loop are now generated at different offsets within a cache
line, all four are measured, and the low and high gains are both reported.
Pinning a single alignment was tried first and is not a fix: it silently picks
one of the two modes -- aligned to 64 the loop sits permanently in the low one.

Measured on the S32Z280-594EVB, reproducing exactly across runs:

    loop offset in line    cold      warm      gain
    0                      890,302   890,035   0%
    16                     890,208   889,976   0%
    32                     857,439   651,390   24.0%
    48                     857,631   651,571   24.0%

The cold pass differs between the modes as well, 890k against 857k, so the
loop is slower even with both caches off. The cold pass is instruction-fetch
bound out of code RAM at half the core frequency (S32Z2 RM 6.3.6), and how the
loop straddles lines decides how much of the data cache's contribution is
visible at all. This probe therefore measures both caches together and always
did; the sweep at least makes the variation visible instead of letting one
arbitrary placement stand in for the part.

C4 now passes if any alignment shows a 10% speedup, and says so explicitly
when the low mode does not, so the sensitivity appears in the log rather than
being discovered later.

Verified: with the sweep in place, adding 0, 8, 12 or 20 bytes of nops to
entry.S leaves the reported low and high gains unchanged. Before it, the same
shifts read 24.0%, 0%, 0% and 0%.

Also adds cache_disable_all, which the sweep needs: cache_enable was one-way,
so a second cold reading in one run was impossible.

Assisted-by: Claude Code (Opus 5) <noreply@anthropic.com>
2026-08-17 13:14:16 -04:00
…
2026-06-30 17:31:42 -04:00

Eclipse ThreadX RTOS

This advanced real-time operating system (RTOS) is designed specifically for deeply embedded applications. Among the multiple benefits it provides are advanced scheduling facilities, message passing, interrupt management, and messaging services. Eclipse ThreadX RTOS has many advanced features, including picokernel architecture, preemption threshold, event chaining, and a rich set of system services.

Here are the key features and modules of ThreadX:

ThreadX Key Features

Getting Started

Eclipse ThreadX has been integrated to the semiconductor's SDKs and development environment. You can develop using the tools of choice from STMicroelectronics, NXP, Renesas and Microchip.

We also provide getting started guide and samples using development boards from semiconductors you can build and test with.

See Overview of Eclipse ThreadX RTOS for the high-level overview.

Repository Structure and Usage

Directory layout

.
├── cmake                        # CMakelist files for building the project
├── common                       # Core ThreadX files
├── common_modules               # Core ThreadX module files
├── common_smp                   # Core ThreadX SMP files
├── docs                         # Documentation supplements
├── ports                        # Architecture and compiler specific files. See below for directory breakdown
│   ├── cortex_m7
│   │   ├── iar                  # Example IAR compiler sample project
│   │   │   ├── example build    # IAR workspace and sample project files
│   │   │   ├── inc              # tx_port.h for this architecture
│   │   │   └── src              # Source files for this architecture
│   │   ├── ac6                  # Example ac6/Keil sample project
│   │   ├── gnu                  # Example gnu sample project
│   │   └── ...
│   └── ...
├── ports_modules                # Architecture and compiler specific files for threadX modules
├── ports_smp                    # Architecture and compiler specific files for threadX SMP
├── samples                      # demo_threadx.c
└── utility                      # Test cases and utilities

Branches & Releases

The master branch has the most recent code with all new features and bug fixes. It does not represent the latest General Availability (GA) release of the library. Each official release (preview or GA) will be tagged to mark the commit and push it into the Github releases tab, e.g. v6.2-rel.

When you see xx-xx-xxxx, 6.x or x.x in function header, this means the file is not officially released yet. They will be updated in the next release. See example below.

/**************************************************************************/
/*                                                                        */
/*  FUNCTION                                               RELEASE        */
/*                                                                        */
/*    _tx_initialize_low_level                          Cortex-M23/GNU    */
/*                                                           6.x          */
/*  AUTHOR                                                                */
/*                                                                        */
/*    Scott Larson, Microsoft Corporation                                 */
/*                                                                        */
/*  DESCRIPTION                                                           */
/*                                                                        */
/*    This function is responsible for any low-level processor            */
/*    initialization, including setting up interrupt vectors, setting     */
/*    up a periodic timer interrupt source, saving the system stack       */
/*    pointer for use in ISR processing later, and finding the first      */
/*    available RAM memory address for tx_application_define.             */
/*                                                                        */
/*  INPUT                                                                 */
/*                                                                        */
/*    None                                                                */
/*                                                                        */
/*  OUTPUT                                                                */
/*                                                                        */
/*    None                                                                */
/*                                                                        */
/*  CALLS                                                                 */
/*                                                                        */
/*    None                                                                */
/*                                                                        */
/*  CALLED BY                                                             */
/*                                                                        */
/*    _tx_initialize_kernel_enter           ThreadX entry function        */
/*                                                                        */
/*  RELEASE HISTORY                                                       */
/*                                                                        */
/*    DATE              NAME                      DESCRIPTION             */
/*                                                                        */
/*  09-30-2020      Scott Larson            Initial Version 6.1           */
/*  xx-xx-xxxx      Scott Larson            Include tx_user.h,            */
/*                                            resulting in version 6.x    */
/*                                                                        */
/**************************************************************************/

Supported Architecture Ports

ThreadX

arc_em      cortex_a12        cortex_m0     cortex_r4
arc_hs      cortex_a15        cortex_m23    cortex_r5
arm11       cortex_a17        cortex_m3     cortex_r7
arm9        cortex_a34        cortex_m33
c667x       cortex_a35        cortex_m4
linux       cortex_a5         cortex_m55
risc-v32    cortex_a53        cortex_m7
rxv1        cortex_a55        cortex_m85
rxv2        cortex_a57
rxv3        cortex_a5x
win32       cortex_a65
xtensa      cortex_a65ae
            cortex_a7
            cortex_a72
            cortex_a73
            cortex_a75
            cortex_a76
            cortex_a76ae
            cortex_a77
            cortex_a8
            cortex_a9

ThreadX Modules

Eclipse ThreadX Modules component provides an infrastructure for applications to dynamically load modules that are built separately from the resident portion of the application.

cortex_a35
cortex_a35_smp
cortex_a7
cortex_m0+
cortex_m23
cortex_m3
cortex_m33
cortex_m4
cortex_m7
cortex_r4
rxv2

ThreadX SMP

Eclipse ThreadX SMP is a high-performance real-time SMP kernel designed specifically for embedded applications.

arc_hs_smp
cortex_a34_smp
cortex_a35_smp
cortex_a53_smp
cortex_a55_smp
cortex_a57_smp
cortex_a5x_smp
cortex_a5_smp
cortex_a65ae_smp
cortex_a65_smp
cortex_a72_smp
cortex_a73_smp
cortex_a75_smp
cortex_a76ae_smp
cortex_a76_smp
cortex_a77_smp
cortex_a78_smp
cortex_a7_smp
cortex_a9_smp
linux

Adaptation layer for ThreadX

ThreadX is an advanced real-time operating system (RTOS) designed specifically for deeply embedded applications. To help ease application migration to ThreadX RTOS, Eclipse ThreadX provides adaption layers for various legacy RTOS APIs (FreeRTOS, POSIX, OSEK, etc.).

Component dependencies

The main components of ThreadX RTOS are each provided in their own repository, but there are dependencies between them, as shown in the following graph. This is important to understand when setting up your builds.

dependency graph

You will have to take the dependency graph above into account when building anything other than ThreadX itself.

Building and using the library

Instruction for building the ThreadX as static library using Arm GNU Toolchain and CMake. If you are using toolchain and IDE from semiconductor, you might follow its own instructions to use ThreadX RTOS components as explained in the Getting Started section.

  1. Install the following tools:

  2. Cloning the repo

    $ git clone https://github.com/eclipse-threadx/threadx.git
    
  3. Define the features and addons you need in tx_user.h and build together with the component source code. You can refer to tx_user_sample.h as an example.

  4. Building as a static library

    Each component of ThreadX RTOS comes with a composable CMake-based build system that supports many different MCUs and host systems. Integrating any of these components into your device app code is as simple as adding a git submodule and then including it in your build using the CMake add_subdirectory().

    While the typical usage pattern is to include ThreadX into your device code source tree to be built & linked with your code, you can compile this project as a standalone static library to confirm your build is set up correctly.

    An example of building the library for Cortex-M4:

    $ cmake -Bbuild -GNinja -DCMAKE_TOOLCHAIN_FILE=cmake/cortex_m4.cmake .
    
    $ cmake --build ./build
    

Licensing

License terms for using Eclipse ThreadX are defined in the LICENSE.txt file of this repo. Please refer to this file for all definitive licensing information for all content, incl. the history of this repo.

Resources

The following are references to additional ThreadX RTOS resources:

You can also check previous questions or ask new ones on StackOverflow using the threadx-rtos and threadx tags.

Security

Eclipse ThreadX provides OEMs with components to secure communication and to create code and data isolation using underlying MCU/MPU hardware protection mechanisms. It is ultimately the responsibility of the device builder to ensure the device fully meets the evolving security requirements associated with its specific use case.

Contribution

Please follow the instructions provided in the CONTRIBUTING.md for the corresponding repository.

S
Description
Eclipse ThreadX is an advanced real-time operating system (RTOS) designed specifically for deeply embedded applications.
Readme
29 MiB
Languages
C 55.8%
Assembly 38.1%
Batchfile 2.5%
Shell 1.8%
Linker Script 0.7%
Other 0.9%