Early beta · launching soon
Test your firmware without the hardware bench.
Benchless runs your real firmware binary on a simulated microcontroller. Drive the pins, feed the sensors, break the bus, and check what the code does. Run it on every commit, from your terminal, or from the AI agent that wrote the code.
- PASSboot banner on uart.tx within 100 ms40 ms
- FAILuart.tx says "sensor lost" within 200 msnothing sent after 900 ms
- FAILPA5 blinks at 2 Hz within 500 msPA5 held high
Firmware is still tested by hand, on a desk.
Someone flashes a dev board, watches an LED, reads a serial log and decides it looks right. That works for one engineer and one board. It stops working when a team pushes ten changes a day, when the board is in another city, or when an AI agent writes half the code and has no way to see what it does on real silicon.
So bugs get found late. These are cheap to fix on the day they are written and expensive a month later:
- a timing change that only shows up after a brown-out
- an I2C driver that hangs when the sensor stops answering
- a watchdog that never fires
What it does
Run the binary you would flash.
Benchless loads the same ELF file you put on the chip. You don't need a test build, mocks or rewritten drivers. Around it, you describe what the world does and what the firmware should do back.
# scenarios/sensor_timeout.yaml
chip: stm32f411
firmware: build/app.elf
world:
- at: 0ms i2c.0x48 replies temp=21.5
- at: 1200ms i2c.0x48 stops replying
expect:
- uart.tx says "sensor lost" within 200ms
- pin PA5 blinks 2Hz within 500ms
- no watchdog reset01
Script the world around the chip
Set sensor readings, hold a button, pull a line low, cut power for 20 ms, or let a peripheral stop responding. Each scenario is a short file you keep in the repo.
02
Assert on what the hardware sees
Check pin states, UART output, bus traffic and timing. When a test fails, it comes with the trace that shows why.
03
Watch it like a logic analyzer
Every run records pins and buses on one timeline, so you can scroll to the moment it went wrong and share the link.
04
Let your AI agent test its own code
The agent builds, runs the scenario and reads the result before it opens a pull request.
How it works
Four steps from a build to a verdict.
- 1
Point it at your build
Give Benchless your build output and pick the chip.
- 2
Write a scenario
What the world does, and what the firmware should do back.
- 3
Run it anywhere
From CI, the API or your agent. Each run starts from a clean reset.
- 4
Read the result
Pass or fail, the trace, and the first point where expected and observed differ.
Who it is for
Built for teams that ship firmware often.
- Embedded teams on a release schedule
- You would rather see a failing test than a failing board.
- Hardware startups
- Your dev boards are scarce, or spread across offices and time zones.
- Teams adding AI coding agents
- You need a way to check what the agent produced before a person flashes it.
You test your firmware.
We test the simulation first.
Each peripheral model is checked against a real dev board running the same code, and we publish what each model covers and what it does not. If a behavior is not modeled yet, the docs say so.
Beta status
What works today, and what we are building next.
In the beta today
- Cortex-M0 and M4 cores on common STM32 parts
- GPIO, UART, I2C and timers
- Scenario files and assertions
- Trace recording and shareable run links
- HTTP API and Python SDK
Next
- Command line tool
- MCP server for AI agents
- CI action
- SPI and ADC models
Later
- More chip families
- Several boards talking to each other in one run
- RTOS-aware traces
- A runner you host yourself
What early beta teams get
Free runs during the beta, a direct line to the founders, and a say in which chips and peripherals we build next.
What we ask in return
Try it on a real project, tell us where it broke, and take a short call every few weeks.
Access is by conversation. Write to us and tell us what you are building.
Questions
Before you write in.
Do I have to change my firmware?
No. Benchless is designed to run the same binary you would flash. If your code depends on something we do not model yet, we will tell you before you spend time on it.
Which chips are supported?
In the beta, common STM32 parts with Cortex-M0 and M4 cores. Send us your part number and we will tell you where it sits on the list.
Does this replace testing on real hardware?
No. It catches the bugs that can be caught before the bench, so your time on real boards goes to what only real boards can show you.
Where does my code run?
During the beta, runs happen on our servers. Ask us to delete your binaries and traces at any time and we will. A self-hosted runner is on the roadmap.
What does it cost?
Pricing is not set yet. Early beta teams use it free.
When does it launch?
When the supported chip list covers what our beta teams need. We would rather launch late than call a chip supported when it is not.
About
Firmware deserves the same test loop as software.
Firmware engineers have spent decades testing code by watching lights blink on a desk. Software teams moved to automated tests on every change a long time ago. Embedded work never got that, because the code needs a chip to run on and the chip sits on a board in one place.
We are building Benchless so firmware gets the same loop: write the change, run the tests, read the result, ship. AI agents are starting to write firmware too, and they need a way to see what their code does to hardware. A simulated chip is the only bench they can reach.
Founders
Founder name
Founder
Contact
We are in early beta. If you want in, write to the founder.
Tell us the chip you use and what you would test first. We read every message and reply ourselves.