Describe a board in one .hector.yaml and Hector builds the platform,
runs it in simulation, and tests the firmware — locally or in your pipeline.
The CLI is free and open source. Hector CI adds the dashboard,
runner pool, audit logs — and Live View, a browser window into
the running simulation.
The engine. Define hardware in YAML, generate the Renode platform, run firmware and tests — on your machine, in any CI.
.hector.yaml → a complete Renode platformpip install hector-cli
Linux only for now (macOS & Windows planned).
View on GitLub →AGPL-3.0 · community supported
The team layer on top of the CLI: a dashboard, a runner pool, and the things you need to ship hardware as a team.
Simulated hardware is normally a black box: a pass/fail and a wall of logs.
Live View opens it. Boot your platform on a runner — the same
simulation hector run executes, real firmware and custom peripherals
included — then explore the resolved hardware, watch properties change as the
firmware runs, call peripheral methods, and drop into the real Renode console.
.save.
.hector.yaml for a quick look.Every peripheral Renode instantiated, with type, address range and GPIO/IRQ wiring — as a diagram or a tree. Not what the YAML said; what the emulator built.
Subscribe to any property and values arrive on change. No polling, no sampling gaps.
Each session is a job on your own runner pool, isolated per user and released when idle. Firmware and source never leave your network.
Full layout down to 390px — the peripheral tree, the controls, and firmware output as a bottom sheet.
Live View is the new part. Everything around it is a complete CI system.
.hector.yaml stays in sync both ways.Built for teams
Screenshots are the shipping interface, captured from the current build. The data in them — repos, runs and timings — is illustrative sample data, not benchmarks.
Open a running simulation in the browser: resolved platform, live watches, callable peripheral methods, the real Renode console and whole-machine snapshots.
Renode parses your platform; the dashboard renders the real peripherals, GPIO and wiring — not a guess.
Fan out across parameters and run them in parallel on the runner pool.
Stream step output and Robot/shell results as they happen.
Collect ELFs, logs, traces and reports from every run.
Who did what, when — filterable by user, action and time.
Runs entirely on your infrastructure. Your firmware never leaves your network.
Build the platform visually on a canvas — the .hector.yaml stays in sync both ways.
Run a .hector.yaml with no repo connected at all — paste it and go.
This is the platform diagram from Live View,
running right here — built from the stm32f103-full example that ships with the
CLI. Click the machine to open it, drag the blocks, drag the background to pan.
×N on a wire means that many individual pin or IRQ lines aggregated into one.
version: "0.1"
renode_version: "1.16.1"
arguments:
BIN: "https://dl.antmicro.com/projects/renode/zephyr-stm32f103-button.elf-..."
machines:
blackpill:
firmware: ${BIN}
peripherals:
# mcu — the complete STM32F103. An inert CombinedInput registered @ none:
# it groups the MCU peripherals without touching the bus.
mcu:
type: Miscellaneous.CombinedInput
at: none
numberOfInputs: 1
peripherals:
flash: { type: Memory.MappedMemory, at: sysbus 0x00000000, size: "0x20000000" }
sram: { type: Memory.MappedMemory, at: sysbus 0x20000000, size: "0x10000000" }
nvic: { type: IRQControllers.NVIC, at: sysbus 0xE000E000, priorityMask: "0xF0" }
cpu: { type: CPU.CortexM, at: sysbus, cpuType: cortex-m3, nvic: nvic }
exti: { type: IRQControllers.STM32F4_EXTI, at: sysbus 0x40010400, numberOfOutputLines: 19 }
gpioPortA: { type: GPIOPort.STM32F1GPIOPort, at: sysbus <0x40010800, +0x400> }
gpioPortC: { type: GPIOPort.STM32F1GPIOPort, at: sysbus <0x40011000, +0x400> }
usart1: { type: UART.STM32_UART, at: sysbus <0x40013800, +0x100> }
usart2: { type: UART.STM32_UART, at: sysbus <0x40004400, +0x100> }
i2c1: { type: I2C.STM32F4_I2C, at: sysbus 0x40005400 }
timer1: { type: Timers.STM32_Timer, at: sysbus 0x40012c00, frequency: 10000000 }
# … usart3-5, i2c2, timer2-14, gpioPortB/D/E/F/G, afio, nvicInput23/40
connections: |
nvic.IRQ -> cpu@0
usart1 -> nvic@37
usart2 -> nvic@38
i2c1.EventInterrupt -> nvic@31
i2c1.ErrorInterrupt -> nvic@32
# EXTI fan-out: lines 0-4 direct, 5-9 and 10-15 via combiners
exti[0-4] -> nvic@[6-10]
exti[5-9] -> nvicInput23@[0-4]
exti[10-15] -> nvicInput40@[0-5]
nvicInput23 -> nvic@23
nvicInput40 -> nvic@40
# every GPIO line into EXTI — this is where the ×16 wires come from
gpioPortA[0-15] -> exti@[0-15]
gpioPortC[0-15] -> exti@[0-15]
# … timer interrupts and alternate-function pin routing
# the board's user button, on PC13
button:
type: Miscellaneous.Button
at: gpioPortC 13
connections: |
button -> gpioPortC@13
init: |
ApplySVD @https://dl.antmicro.com/projects/renode/svd/STM32F103.svd.gz
Tag <0x40021000, 0x40021003> "RCC_CR" 0x0A020083
commands: |
showAnalyzer usart2This is a reproduction, not a live session. It's a faithful copy of the real component — same layout, same wiring, same resolved address ranges Renode reports — but the peripheral list is trimmed for legibility (the full board also carries usart3-5, timer4-14 and gpioPortF/G), and nothing here is connected to a backend. The real Live View does considerably more: it boots your firmware on a runner, then lets you watch properties update as it runs, call peripheral methods, attach a Renode console and snapshot the whole machine.
The CLI is free forever. Hector CI is licensed per deployment — talk to us and we'll size it to your team.
Let's talk
per deployment
Custom
SSO · SLA · on-site
Tell us a little about your team and we'll get you set up — including a live walkthrough of the dashboard and a hands-on look at Live View.