Trampoline is a static RTOS with an OSEK/VDX and AUTOSAR shaped API

An RTOS whose API is shaped by two automotive standards

Trampoline describes itself as a static RTOS for small embedded systems, and the distinguishing clause is the second sentence: its API is aligned with OSEK/VDX OS and AUTOSAR OS 4.2. That is the whole reason to look at it. OSEK/VDX is the historic automotive task specification, and AUTOSAR OS 4.2 is the modern standardised operating system interface that automotive software expects. Code written against either shape should port across implementations that claim the same alignment, and Trampoline claims both. A static kernel, as opposed to a dynamic one with a memory allocation model, fits the automotive and safety-oriented world these specifications came from, where the memory map is fixed at build time. For a general embedded project with no such requirement, this alignment is a constraint rather than a benefit, since you accept a task, alarm and ISR model whether or not it is the one you would have chosen.

Eight architecture families, from an 8-bit AVR to a Cortex-R52

The port list is long and specific, and the support table is more useful than the family list because it names the board as well as the chip. The families are cortex, riscv, ppc, posix, avr, ARM, virt-v7, and rh850, with MSP430/CPUX described separately. Within cortex there are three variants, with Cortex-M covering M0+, M3 and M4 for now, Cortex-A at A7 marked as under heavy development, and Cortex-R at R52. The riscv entry names the PULPino with a 32-bit RISC-V instruction set, posix is a virtual platform for POSIX systems tested on Linux and OS X, and virt-v7 is a Cortex-A9 to Cortex-A7 virtualized instruction set used with the XVisor hypervisor. The table then pins each port to a concrete evaluation board, among them Arduino Uno and Mega, XPlainedPro, Raspberry Pi 2 Model B, Teensy31, ZedBoard, the STM32F4DISCOVERY and the Nucleo-32 boards, and the Renesas R-Car S4 Spider for both the CR52 and G4MH parts.

The examples are the documentation, and they are organised by board

What the README does document in detail is the example suite, and the examples directory mirrors the port list with directories for arm, avr, cortex-a-r, cortex-m, msp430x, posix, ppc, rh850, riscv and virt-v7. Each example is a small application rather than a synthetic test. The stm32f407 tree under cortex-m/armv7em/stm32f407/stf32f4discovery holds five: blink, which blinks a LED using an alarm and a task; readButton, which polls a button to start an alarm that activates a task; readButton_isr, the same with the button triggering an ISR; alarms, which tests the return value of SetRelAlarm for return parameters in kernel, or system call, mode; and timer, where ISR2 is triggered by timer TIM2. The reason to read these is that they show the idiomatic way to do each thing in this kernel, and the naming makes the concept differences explicit, a polled button and an interrupt-driven one being genuinely different programs.

Multicore, timing protection and code generation show up in the examples

The PowerPC examples are where the more advanced features become visible, and the ppc directory is listed with five examples for the MPC5643L, though the naming runs to seven entries including multicore variants. blink_1c is the single core blink, blink_1c_withOrti does the same and creates an orti file, which is an ORTI trace file for measurement. blink_2c blinks two LEDs on two synchronised cores with one task and one alarm per core, and blink_2c_arxml is the same two core example driven from an arxml configuration file, which is the AUTOSAR exchange format and therefore the clearest sign that the AUTOSAR alignment is real rather than a claim on a badge. blink_2c_opticks does the same but optimises ticks, and button_2c waits for a button input to light an LED, switches it off using the Timing Protection watchdog, and is described as a multicore example. spinlocks is a producer and consumer example. The ppc directory therefore covers core synchronisation, configuration interchange and watchdog timing protection in a single place.

Where the build and configuration path lives in the tree

The repository layout is where the missing documentation has to be reconstructed. The top level holds a LICENSE-GPLv2.txt, a _clang-format file, and directories with names that describe the pipeline: goil/ for the configuration compiler, com/ for the generated code, os/ for the kernel itself, machines/ for the architecture support, make/ for the build rules, ioc/ for the input and output configuration, autosar/ for the AUTOSAR-facing parts, libraries/ for the supporting code, tests/ for the test suite, debug/ for debugging support, extra/ for additions, viper/ for the visualisation tooling, documentation/ for the documents, and examples/ for the port-specific applications. The .gitmodules file and the .github directory sit alongside them. The goil and com directories are the pair to focus on: a configuration compiled by goil produces code placed in com, which is then linked with the kernel in os for the target described by the machine in machines. The README does not spell out that chain, so it is an inference from the directory names rather than a documented procedure.

The POSIX port is the cheapest way to see the kernel work

Among the ports, posix is the interesting one for evaluation because it needs no board. The README describes it as a virtual platform for POSIX systems, tested on Linux and OS X, and the examples directory carries a posix/ folder, so a developer can exercise the kernel on a workstation before touching hardware. The virt-v7 port is the other unusual case, since it is described as a Cortex-A9 to Cortex-A7 virtualized instruction set used with the XVisor hypervisor, and its single example is a firmware that can be used as a guest on XVisor. That is a testing arrangement in a different direction, where the kernel runs inside a hypervisor rather than on a bare board. The Arduino examples, by contrast, are three for the Uno and Mega chips: blink, serial, which improves blink by using the standard Arduino serial API, and extInterrupt, which adds two ISRs to change the alarm period. The AVR port is the one most likely to be reached for first, and it is the least demanding.

What the README does not tell you, and where that leaves you

Several gaps are worth naming before you commit. There is no build command anywhere in the README, no toolchain requirements per port, and no list of which compilers or cross-compilers are expected. There is no configuration file format documented, even though the arxml example implies AUTOSAR style input, and no explanation of how the generated code in com/ is produced from a configuration. The kernel configuration options are not enumerated, and the timing protection and ORTI mechanisms are shown only through example names. The Raspberry Pi 2 example is honest about its own state, saying a first runnable blink is available but that a bootloader and a console are still needed and that it runs on a single core for the moment. The strongest signal about the project's centre of gravity is the standards alignment and the board list. The weakest is the absence of any narrative documentation, which the documentation/ directory presumably holds but which the README does not point a newcomer at.

Editorial conclusion

Trampoline suits an embedded team that has to satisfy an OSEK/VDX or AUTOSAR OS 4.2 shaped interface on hardware where a full commercial stack is out of reach, and that has a board already listed in the support table. It does not suit a team that wants a documented one-command build, because the README gives no build instructions and the example trees are described rather than explained, and it does not suit a Cortex-A project, since that port is marked as under heavy development. Before adopting, pick a board from the support table, read the example directory for that target, and check the goil and com directories for the configuration and code generation path, since the last push to the repository was on 2026-10-19 and the project ships no GitHub releases.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. README
4. TrampolineRTOS/trampoline on GitHub