QEMU vs Renode for embedded firmware

QEMU and Renode can both run embedded software without the physical target on your desk. But they were built around different problems.

If you are trying to boot Linux, emulate a standard machine, or run software built for another CPU architecture, QEMU is usually the more natural starting point.

If you are developing MCU firmware and care about interrupts, peripheral registers, buses, sensors, multiple devices, and repeatable firmware tests in CI, Renode is often the more natural fit.

The important question is not which emulator is “better.” It is whether the virtual hardware underneath your firmware resembles the hardware you are actually building.

The short version

That last row matters more than most comparison tables admit. Neither QEMU nor Renode magically knows what is on your schematic.

What QEMU is particularly good at

QEMU is a general-purpose machine emulator.

A QEMU machine contains CPUs, memory and emulated devices, and QEMU supports a large range of CPU architectures and machine types. That makes it extremely useful when the thing you want to execute looks like a computer or SoC platform that QEMU already understands.

For embedded development, that often means:

• booting an embedded Linux image;
• testing bootloaders;
• developing against a standard virtual machine;
• bringing up software for Arm, RISC-V or another supported architecture;
• running tests that primarily depend on CPU, memory, storage or network behavior;
• debugging through GDB;
• running software for one architecture on a different development machine.

QEMU also has a mature device model infrastructure. It is not merely a CPU emulator.

The catch appears when your firmware depends on a particular MCU peripheral or a particular component on your board.

Having a Cortex-M CPU model is not the same thing as having the exact STM32, NXP or Nordic peripheral set your firmware expects. And having the MCU does not mean your external IMU, flash, PMIC or ADC exists in the virtual machine.

You can implement missing hardware in QEMU. But at that point you are developing QEMU device models, not merely configuring an emulator.

For some teams, that is completely reasonable. For others, maintaining that virtual hardware becomes a project of its own.

What Renode does differently

Renode starts much closer to the embedded-device problem.

A Renode platform is assembled from CPUs, memories, buses and peripheral models. The layout of the platform can be described in a text-based .repl file, while the behavior of peripherals can be implemented separately.

That separation is useful. Changing a memory address, adding a peripheral or creating another board variant does not necessarily mean creating another monolithic machine implementation.

Renode can also model things outside the MCU itself: I²C and SPI devices, sensors, radios, wired networks and complete systems containing several simulated nodes. That makes it particularly useful when the code you want to test is firmware rather than an operating system.

For example, a test can boot the real firmware binary, provide an input to a simulated sensor, observe traffic on a bus and verify what the firmware does next.

Renode also has direct integration with Robot Framework for automated tests and was designed around a shared virtual time model. That makes scenarios repeatable enough to run as ordinary CI jobs rather than as somebody's bench setup.

The biggest practical difference: peripherals

For embedded firmware, CPU emulation is often the easy part. The difficult part is everything the CPU talks to.

Consider firmware that does this during startup:

• configures the pinmux;
• enables an I²C controller;
• probes address 0x18;
• reads a device ID;
• configures the sensor;
• waits for an interrupt;
• reads a measurement;
• stores it in external SPI flash.

Running the ARM instructions correctly is necessary. But it tells you very little about whether this sequence will work on the product.

To test it meaningfully, the simulator needs to understand the MCU's I²C controller, the interrupt path, the sensor's register behavior, the SPI controller and the external flash.

This is where Renode's architecture tends to be attractive for MCU projects. It has an explicit model for composing platforms and attaching behavioral peripherals. QEMU can model devices too, but extending the virtual hardware generally means working further inside QEMU's machine and device infrastructure.

There is an important caveat, though:

Renode is only as useful as the models you have.

If your MCU or peripheral is missing, simplified, or behaves differently from the real part in an area your firmware relies on, your simulation can still give you a false sense of confidence. The emulator does not remove the model problem.

What about custom PCBs?

This is where “QEMU vs Renode” becomes a slightly misleading question.

Imagine your product contains:

• an STM32 MCU;
• an SPI NOR flash;
• two I²C sensors;
• a GPIO expander;
• a PMIC;
• several interrupt lines;
• enable pins;
• reset pins;
• level shifters;
• and board-specific power sequencing.

Even if an emulator supports every individual component, it does not automatically know:

• which I²C bus the sensor is on;
• what address straps you selected;
• which MCU pin carries its interrupt;
• whether an enable signal is active-high;
• which SPI chip select goes to the flash;
• whether firmware configures the correct pinmux;
• what must power up before something else;
• or what happens when firmware accesses a device before it is ready.

Those are board-level properties. They live in the schematic and BOM, not in the CPU architecture.

For firmware teams building custom hardware, this is usually the real modeling problem.

QEMU vs Renode for STM32 and other Cortex-M firmware

If your goal is simply to execute some Cortex-M code, either tool may work depending on the target.

If your firmware interacts heavily with MCU peripherals, Renode is often the more convenient starting point because embedded peripherals and board composition are central to its architecture.

But check support for your specific MCU and the peripherals you actually use before choosing either tool.

“Supports Cortex-M4” is not enough.

Firmware built for an STM32F4, nRF52 and SAM E70 may execute the same ARM instruction set while interacting with completely different memory maps, interrupt controllers and peripheral registers.

The closer your code gets to hardware, the less useful CPU-level compatibility becomes as a proxy for platform compatibility.

QEMU vs Renode for embedded Linux

The balance changes substantially for embedded Linux. QEMU has spent decades solving full-system emulation problems and supports a wide range of machine architectures, storage devices, networking devices and virtualization workflows.

If your task is something like:

“Boot this Linux image for an Arm machine and test the software stack”

QEMU should probably be the first tool you investigate.

If your task is:

“Run the production firmware for our microcontroller and inject sensor and bus behavior into automated tests”

Renode is much closer to that problem.

There are overlaps. The distinction is about the center of gravity, not an absolute technical boundary.

Testing and CI

Both tools can be automated. The difference is the level at which they expect you to build the test environment.

With QEMU, teams commonly wrap the emulator with their own scripts and test infrastructure.

Renode provides embedded-oriented testing facilities directly, including Robot Framework integration and APIs for inspecting simulation state, interacting with UARTs and networks, and controlling the virtual machine. Renode can also run several virtual embedded devices in one synchronized simulation.

That becomes useful for products involving gateways, sensor networks, robotics or protocols where testing one isolated MCU is not enough.

QEMU, meanwhile, has sophisticated capabilities that Renode users should not casually dismiss, including deterministic record/replay and reverse debugging.

These are different toolchains with significant overlap, not a simple old-tool/new-tool comparison.

Neither is real hardware

There is another distinction worth making because emulator comparisons frequently overpromise.

Neither QEMU nor Renode should automatically be treated as a cycle-accurate electrical simulation of your board.

A behavioral peripheral model can tell you:

firmware wrote the wrong register.

It cannot necessarily tell you:

this signal has an unacceptable rise time because of the pull-up resistance and bus capacitance.

Simulation is excellent for software-visible behavior. Physical hardware is still required for things such as:

• signal integrity;
• RF performance;
• analog accuracy;
• actual oscillator behavior;
• electrical margins;
• thermal behavior;
• physical power behavior;
• silicon errata that the model does not implement.

Use simulation to move firmware/hardware integration bugs earlier. Use real hardware to validate the physics.

Where HardLabs fits

HardLabs is not another CPU emulator competing with QEMU and Renode. We use Renode as an execution layer where it makes sense.

The problem we work on is the layer above it: turning an actual PCB design into a useful firmware-in-the-loop simulation.

Instead of starting with a generic development board and manually reconstructing your product around it, HardLabs takes the board design into account: components, connectivity and the behavioral models required by the firmware.

The goal is not just:

Can this binary execute?

It is:

Can this binary execute against the board we are about to manufacture?

That distinction lets the simulator catch a different class of problems: wrong addresses, wrong bus attachments, bad initialization sequences, missing pin configuration, incorrect assumptions about peripherals and other HW/FW integration mistakes.

If an existing QEMU machine already represents the hardware you need, use QEMU. If Renode already models your platform and peripherals, use Renode.

If the difficult part is turning your schematic and BOM into the simulation your firmware actually needs, that is the problem HardLabs is building for.

Positioning detail: HardLabs vs QEMU · HardLabs vs Renode

QEMU or Renode: a practical decision rule

Choose QEMU first when the main thing you need to reproduce is a computer or operating-system environment.

Choose Renode first when the main thing you need to reproduce is an embedded device and its interaction with peripherals.

Before investing heavily in either one, check the models for your actual target.

And if the target is a custom PCB, count the work required to create and maintain the virtual board—not just the work required to launch the emulator.

That is usually where the real cost is.

More: Why idealized peripherals hide bring-up bugs · All comparisons · Pilot