Can I build hardware and firmware without physical breadboards?

Yes. LabWired provides pin-accurate MCU digital twins (ARM Cortex-M, RISC-V, Xtensa) that execute unmodified firmware in browser and CI environments, eliminating silicon wait times.

Which MCU architectures and RTOSes are supported for firmware execution?

LabWired supports ARM Cortex-M (STM32, NUCLEO, nRF52), RISC-V, ESP32-C3 (Xtensa/RISC-V), and RP2040. Compatible toolchains include Zephyr RTOS, ESP-IDF, FreeRTOS, Rust no_std, and Bare-Metal C/C++.

How do AI agents assist in building hardware and firmware?

AI coding assistants (Claude, Cursor, Codex) connect via LabWired's MCP server (https://api.labwired.com/mcp) to construct virtual circuits, step through instruction execution, analyze UART/I2C traces, and fix firmware bugs autonomously.

How accurate is LabWired compared to real physical hardware?

LabWired uses deterministic register-level MCU execution models and bus-accurate peripheral protocols (SPI, I2C, UART, CAN-FD), enabling 100% reproducible test runs.

Engineering Specification Guide

Building Hardware & Firmware in Software.

A deep-dive technical blueprint for embedded engineers, hardware architects, and AI agent developers. Learn how LabWired models MCU digital twins, memory-mapped peripherals, and cycle-accurate bus signals without physical breadboards.

Launch Playground Engine → View Declarative YAML & Code

Supported Microcontrollers: ARM Cortex-M33 / M4 ESP32-C3 (RISC-V / Xtensa) STM32H5 / STM32F1 RP2040 Pico

Declarative Hardware Definition

1. Virtual Circuit & Peripheral Declarative Schema

Instead of soldering physical headers and jumpers, define your MCU digital twin, peripheral memory maps, and pin connections in human-readable and agent-editable YAML manifests.

circuit-spec.yaml — Complete STM32H5 + CAN-FD + OLED System Model YAML

target:
  mcu: stm32h563zi
  arch: arm-cortex-m33
  clock_frequency_hz: 250_000_000

peripherals:
  - id: oled_display
    driver: ssd1306
    interface: i2c1
    i2c_address: 0x3C
    pins:
      sda: PB9
      scl: PB8

  - id: ecu_diagnostic_node
    driver: can_fd_transceiver
    interface: fdcan1
    bitrate_nominal: 500_000
    bitrate_data: 2_000_000
    pins:
      rx: PD0
      tx: PD1

tracing:
  vcd_output: signals.vcd
  uart_capture: usart1

Unmodified Firmware Compatibility

2. Executing C, C++, and Rust Binary ELFs

LabWired parses standard ELF/HEX binaries produced by GCC, Clang, or Rust no_std toolchains. The exact production code runs against simulated memory-mapped I/O registers.

main.c — Bare-Metal C (STM32 Register Access)

#include <stm32h5xx.h>

void init_gpio(void) {
    // Enable GPIOB peripheral clock
    RCC->AHB2ENR |= RCC_AHB2ENR_GPIOBEN;
    // Configure PB8/PB9 AF4 (I2C1)
    GPIOB->MODER |= (2 << GPIO_MODER_MODE8_Pos);
}

int main(void) {
    init_gpio();
    ssd1306_draw_string("LabWired Engine Active");
    while (1) {
        // Cycle-accurate execution
    }
}

main.rs — Rust no_std (Embedded HAL)

#![no_std]
#![no_main]

use panic_halt as _;
use stm32h5xx_hal::prelude::*;

#[entry]
fn main() -> ! {
    let dp = Peripherals::take().unwrap();
    let gpiob = dp.GPIOB.split();
    let sda = gpiob.pb9.into_alternate_open_drain();
    
    loop {
        // Deterministic execution in CI
    }
}

Automated CI Regression

3. Headless GitHub Actions Pipeline Blueprint

Run hundreds of virtual board configurations in parallel inside GitHub Actions or GitLab CI. Catch pin assertion failures, CAN-FD message corruptions, and memory leaks before merging code.

.github/workflows/firmware-ci.yml

name: Firmware Virtual CI Test Suite

on: [push, pull_request]

jobs:
  test-firmware-matrix:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Build Firmware Binary
        run: arm-none-eabi-gcc -mcpu=cortex-m33 -T stm32h5.ld main.c -o firmware.elf

      - name: Run LabWired Headless Simulation
        run: |
          npx -y @labwired/cli run \
            --board circuit-spec.yaml \
            --firmware firmware.elf \
            --timeout 5s \
            --export-vcd signals.vcd \
            --assert-uart "LabWired Engine Active"

Model Context Protocol

4. AI Agent (Claude & Codex) MCP Interaction Transcript

LabWired exposes a dedicated MCP server. Below is an authentic interaction transcript showing Claude inspecting MCU registers and resolving an I2C clock stretching deadlock.

🤖 USER → CLAUDE AGENT:

"The SSD1306 OLED display driver is hanging during I2C start condition on PB8/PB9. Read peripheral registers and debug the bus timing."

⚡ CLAUDE AGENT → LABWIRED MCP TOOL CALL:

{
  "tool": "labwired_read_registers",
  "mcu": "stm32h563zi",
  "base_address": "0x40005400", // I2C1 Peripheral Base
  "registers": ["CR1", "ISR", "TIMINGR"]
}

🔍 LABWIRED SIMULATION RESPONSE:

{
  "status": "success",
  "registers": {
    "I2C1_CR1": "0x00000001",   // Peripheral Enabled
    "I2C1_ISR": "0x00000001",   // TXE ready
    "I2C1_TIMINGR": "0x00000000" // BUG: Uninitialized timing register
  },
  "pin_voltages": { "PB8_SCL": 3.3, "PB9_SDA": 0.0 }
}

💡 CLAUDE AGENT RESOLUTION:

"Found the issue: I2C1->TIMINGR is 0x00000000, causing clock stretch timeout. Setting I2C1->TIMINGR = 0x00B0DCE1 for 400kHz fast mode resolved the bus lockup."

Architectural Matrix

Traditional Lab vs. LabWired Virtual Engine

Compare traditional physical hardware testing with deterministic software-based MCU simulation.

Capability	Traditional Physical Lab	LabWired Virtual Engine
Setup Lead Time	3-6 Weeks (PCB fab & shipping)	Instant (< 5 Seconds)
AI Agent Support	Requires complex physical rigs	Native MCP Protocol Endpoint
CI Reproducibility	Flaky jumper wires & noisy power	100% Deterministic Execution
Signal Inspection	Physical scopes & logic channels	Full VCD, RAM & Register Traces

Engine Specifications

Frequently Asked Questions

How does LabWired differ from QEMU or Renode?

While QEMU focuses on high-speed CPU instruction emulation, LabWired prioritizes pin-accurate peripheral behavior, bus timing (I2C, SPI, UART, CAN-FD), display frame buffers, and native browser/CI execution with zero container overhead.

Can I export VCD waveform traces for GTKWave or PulseView?

Yes. Every simulation run can generate a standard VCD (Value Change Dump) file capturing exact signal transitions across GPIO pins and serial buses.

Ready to run your firmware in software?

Launch the browser Playground engine now, or book a co-design session with our team to model your custom hardware device.

Launch Playground Now → Book Scoping Call