Start Building with
EmbeddedOS
No hardware required to get started. Every command on the simulator path was run as written before it was published.
The EmbeddedOS Ecosystem
8 tools that work together — understand what each one does before you start
Creates, builds and simulates EoS projects, analyzes KiCad schematics, and drives flash tools.
Registry of 150 platform descriptors and simulation engines. Cortex-M apps run on QEMU through ebuild sim.
The real-time OS kernel. Provides HAL, scheduler, IPC, drivers, and POSIX subset.
Secure bootloader with verified boot, OTA A/B updates, and hardware root of trust.
Drag-and-drop block editor that generates production C code. No assembly needed for common patterns.
On-device TFLite/ONNX inference and neural interface adapter for BCI devices.
60+ apps including eOffice Suite, eBrowser, eDB, and eBot AI assistant.
Universal IDE with AI tutor, 3D modeler, game editor, and UI designer.
Choose Your Path
Pick the option that matches where you are right now
See an EoS Program in Your Browser
~2 minutesThe /demo page is an interactive, illustrative visualisation of what a small EoS program does: GPIO pins toggle and a console prints. It runs in JavaScript in your browser. It does not compile or execute EoS. To run the real EoS kernel with no hardware, use the "Simulator on My Computer" path, which runs it under QEMU.
Open the Demo
Go to /demo. Pick a board and one of the example programs, then press Run.
- The board view and console are animated by the page itself
- Use it to see the shape of an EoS program: tasks, delays, GPIO, UART output
Run the Real Thing
To boot the actual EoS kernel and your own code without hardware, follow "Simulator on My Computer". It takes about 10 minutes on Linux or WSL2.
ebuild init my-blink --template rtos --target stm32f4
cd my-blink && ebuild simRun EoS on a Simulated Board (QEMU)
~10 minutesebuild creates an EoS project and `ebuild sim` builds it with the EoS kernel for QEMU's Arm Cortex-M3 machine, then boots it and shows the program's output. Every command and output on this page was run on Ubuntu 20.04 (WSL2) with Python 3.12, arm-none-eabi-gcc 9.2.1 and QEMU 4.2.1.
Install the Toolchain and QEMU
sudo apt install git python3-venv gcc-arm-none-eabi qemu-system-armInstall ebuild and EoSim
ebuild is the EmbeddedOS build tool. EoSim provides the platform registry that `ebuild platforms list` reads. Neither is on PyPI yet, so install them from GitHub. uv supplies Python 3.12 for the virtual environment, with no root needed, so this works on Ubuntu 20.04 too.
curl -LsSf https://astral.sh/uv/install.sh | sh && source $HOME/.local/bin/env
uv venv -p 3.12 .venv && . .venv/bin/activate
uv pip install "embeddedos-ebuild @ git+https://github.com/embeddedos-org/ebuild" \
"embeddedos-eosim @ git+https://github.com/embeddedos-org/EoSim"
ebuild --version
# ebuild, version 3.0.1Fetch the EoS Sources
ebuild builds your application against the EoS kernel and bootloader sources. It keeps them in ~/.ebuild/repos.
ebuild setup
# [ok] eos: ~/.ebuild/repos/eos
# [ok] eboot: ~/.ebuild/repos/eboot
# [ok] Setup complete. Repos are ready.
ebuild doctor # checks compilers, cmake, ninja and the reposCreate Your First Project
ebuild init my-blink --template rtos --target stm32f4
cd my-blink
# my-blink/
# src/main.c <- your application
# tests/test_main.c <- unit test target
# build.yaml <- ebuild build configuration
# eos.yaml <- EoS project configuration (board, kind)
# README.mdThe Generated main.c
The rtos template is a producer/consumer program. It uses an EoS queue, a mutex and two tasks:
static void producer_task(void *arg) {
uint32_t seq = 0;
while (1) {
message_t msg = { .id = seq++, .value = (int32_t)(seq * 10) };
eos_queue_send(g_queue, &msg, EOS_WAIT_FOREVER);
eos_task_delay_ms(500);
}
}
static void consumer_task(void *arg) {
message_t msg;
while (1) {
if (eos_queue_receive(g_queue, &msg, EOS_WAIT_FOREVER) == EOS_KERN_OK)
printf("[consumer] id=%lu value=%ld\n", msg.id, msg.value);
}
}Simulate It
ebuild sim compiles your sources and the EoS kernel for QEMU's lm3s6965evb (Cortex-M3), boots the image and prints its output. The kernel's SysTick and PendSV scheduling are real. The board's peripherals are not modelled.
ebuild sim --timeout 4
# Building stm32f4 application for qemu_cortex_m3 (lm3s6965evb)...
# [ok] Image: .../my-blink/_build/sim/firmware.elf
# Running on lm3s6965evb (timeout 4s)...
# [my-blink] Starting kernel...
# [consumer] id=0 value=10
# [consumer] id=1 value=20
# ...
# [consumer] id=8 value=90
# [ok] Simulation ran: 10 line(s) of output, stopped after 4sWhich Boards Can Be Simulated
ebuild sim runs Arm Cortex-M targets: stm32f4, stm32h7, stm32l4, nrf52, nrf52840, rp2040 and raspi-pico, all on the same QEMU Cortex-M3 machine. Other boards, such as esp32, are refused with a message instead of being faked.
ebuild platforms list
# 153 EoSim platforms (* = runnable with `ebuild sim`):
# adi-aducm4050 arm Analog Devices
# ...
ebuild sim --platform esp32
# Error: no simulation target for board 'esp32' yet. Boards ebuild sim can run: ...Debug with GDB
Run the image under QEMU's GDB stub yourself. ebuild does not wrap this step yet.
qemu-system-arm -M lm3s6965evb -nographic -semihosting \
-kernel _build/sim/firmware.elf -gdb unix:/tmp/eos.sock,server,nowait -S &
gdb-multiarch _build/sim/firmware.elf \
-ex "target remote /tmp/eos.sock" -ex "break consumer_task" -ex continue
# Breakpoint 1, consumer_task (arg=0x0) at src/main.c:39ESP32: Not Ready Yet
—ESP32 support is not usable end to end today, and this page will not pretend otherwise. You can create an ESP32 project. Building it needs the Xtensa toolchain, which ebuild does not bundle. ebuild sim cannot run ESP32 code. Producing a flashable MCU image from an ebuild project is tracked in ebuild#171.
What Works Today
ebuild init my-esp32-app --template rtos --target esp32 # creates the project
ebuild doctor
# warn xtensa-esp32-elf not installed — no esp32 buildsWhat Does Not Work Yet
- ebuild build does not yet cross-compile a board image (ebuild#171)
- ebuild sim --platform esp32 is refused; there is no ESP32 simulation target
- ebuild flash <image> --tool esptool calls esptool, but the maintainers have not verified it on hardware
STM32: Simulate Now, Hardware Images Next
—The EoS kernel cross-compiles for Cortex-M4 (STM32F4), and its Cortex-M scheduler is exercised in CI on QEMU. What is missing is an `ebuild build` that turns your project into a flashable STM32 image. Today it builds a host binary, and it does not say so (ebuild#171). Until that lands, simulate with ebuild sim and treat flashing as experimental.
Simulate Your STM32 Application
ebuild init my-stm32-app --template rtos --target stm32f4
cd my-stm32-app && ebuild simBuild the EoS Kernel for Cortex-M4
This is the same build CI runs. It produces the EoS libraries for an STM32F4-class core.
git clone https://github.com/embeddedos-org/eos.git && cd eos
cmake -B build/arm -DCMAKE_TOOLCHAIN_FILE=toolchains/arm-cortex-m4.cmake -DEOS_BUILD_TESTS=OFF
cmake --build build/arm -jFlashing (Experimental)
ebuild flash drives OpenOCD, pyOCD, st-flash, nrfjprog or esptool for an image you already have. The maintainers have not verified it on hardware for this guide.
ebuild flash firmware.bin --tool openocd --target stm32f4
ebuild monitor --baud 115200Build eApps (C + LVGL)
~10 minuteseApps is a collection of C applications on the LVGL graphics library. The native build of the app libraries was verified for this guide on Ubuntu 20.04. Running the apps on a desktop window needs SDL2. That step has not yet been re-verified for this guide.
Clone and Build
git clone --recursive https://github.com/embeddedos-org/eApps.git
cd eApps
cmake -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build -jDesktop Executables (needs SDL2)
With SDL2 installed, standalone executables per app are built when you ask for them. Without SDL2, CMake prints: Skipping eapps_port: SDL2 not found.
sudo apt install libsdl2-dev
cmake -B build -DEAPPS_BUILD_STANDALONE=ON
cmake --build build -jHardware Engineer Workflow
~20 minutesStart from a KiCad schematic. ebuild analyze identifies the MCU and peripherals and generates board, boot and build configuration, and you simulate application logic for that MCU family. The eCAD repository's V0–V4 validation gate checks a product's design data and refuses to call anything a pass without evidence. It is honest about the current state: the example product below does not pass yet.
Get the Designs and the Validator
git clone https://github.com/embeddedos-org/eCAD-Hardware-Products.git && cd eCAD-Hardware-Products
uv pip install jsonschema pyyaml
python tools/validate_products.py capabilities # which external tools are available hereAnalyze a Schematic
From inside eCAD-Hardware-Products, on the eRadar360 schematic:
ebuild analyze --file eRadar360_CAD_Design/hardware/eradar360.kicad_sch
# [info] MCU: STM32H7 (cortex-m7)
# [info] Peripherals: 2 detected
# - usb: J1_usb
# - audio: J2_audio
# [ok] board: _generated/board.yaml
# [ok] boot: _generated/boot.yaml
# [ok] build: _generated/build.yaml
# [ok] eos_config: _generated/eos_product_config.h
# [info] Validation: PASS (0 errors, 3 warnings)Validate the Product's Design Data
V0 schema, V1 sanity, V2 invariants, V3 golden and V4 corner checks. Anything that could not be executed is reported as BLOCKED, never as a pass. eRadar360 currently fails V0 (canonical BOM and datasheet contract) and is blocked at V1–V4 (no simulation model, CAD inputs, golden or corner evidence yet):
python tools/validate_products.py validate --product eRadar360_CAD_Design:hardware --output out/
# prints a JSON summary; its verdict_counts are FAIL 1, everything else 0
# bundle: out/bundle.json
# the per-gate verdicts are in the product's receipt:
python -c "import json; [print(g['gate'], g['verdict']) for g in json.load(open('out/products/eRadar360_CAD_Design__hardware/receipt.json'))['gates']]"
# V0 FAIL
# V1 BLOCKED
# V2 BLOCKED
# V3 BLOCKED
# V4 BLOCKEDSimulate Firmware for That MCU Family
cd .. && ebuild init radar-fw --template rtos --target stm32h7
cd radar-fw && ebuild simOnce it builds, where to look next
The pages that explain how the pieces fit together