Chiprun

Supported boards

Every board Chiprun can run firmware on today. This page is generated from the same registry the service runs on, so it cannot advertise a board that isn't live — but chiprun_list_boards is still the authoritative source for your agent.

Board keyChipRust targetClockUSARTs
unoatmega328pavr-none16 MHzUSART0
nanoatmega328pavr-none16 MHzUSART0
pro-mini-16atmega328pavr-none16 MHzUSART0
pro-mini-8atmega328pavr-none8 MHzUSART0
duemilanoveatmega328pavr-none16 MHzUSART0
miniatmega328pavr-none16 MHzUSART0
lilypadatmega328pavr-none8 MHzUSART0
mega2560atmega2560avr-none16 MHzUSART0, USART1, USART2, USART3
mega-adkatmega2560avr-none16 MHzUSART0, USART1, USART2, USART3
diecimilaatmega168pavr-none16 MHzUSART0
nano-168atmega168pavr-none16 MHzUSART0

Virtual time is exact everywhere

A run's budget is a CPU cycle count and the run stops on the cycle, so where it ends does not move with host load and the same firmware produces the same trace on any machine. Boards used to differ here — one engine enforced the cap with a wall-clock kill — and they no longer do.

The clock comes from the fuses

Two boards can be the same chip at different speeds: a Pro Mini 3.3V and an Uno are both ATmega328P, but the Pro Mini's fuses select the internal 8 MHz oscillator where the Uno's select a 16 MHz crystal. Firmware that counts cycles for its delays runs at whatever the board selects — the same image blinks half as fast and prints at half the baud rate on an 8 MHz board. The crystal itself is drawn but not solved; the clock is the fuse bytes.

Build for the exact part. avr-gcc bakes register addresses in at compile time, so an ATmega328P image on an ATmega2560 does not fail loudly — it writes to the wrong addresses and drops characters. Match the board's chip in the table above.

Per-board notes

These are the chip-specific traps that cost the most debugging time. Your agent receives them from chiprun_help automatically.

Arduino Uno R3

uno

  • The reference board. 32 KB flash, 2 KB SRAM, 16 MHz crystal.
  • Both .hex and .elf load directly — the engine sniffs the format, and an ELF also brings symbols.
  • Rust on AVR is nightly-only and needs -Zbuild-std with -C target-cpu; avr-gcc or the Arduino toolchain is the better-trodden path here.
  • The clock comes from the fuse bytes, not from solving the crystal circuit. Firmware that counts cycles for its delays runs at whatever the board's fuses select — see this board's clock.
  • One USART. Print over USART0 (D0/D1) — that is the output captured in the run.

Default 10s of virtual time, up to 60s. Runs at 16 MHz on a atmega328p.

Fitted parts the engine does not fully model
  • C1 (capacitor) — decoupling — the rail is an ideal source, so this capacitor sees no source impedance and changes nothing
  • C2 (capacitor) — decoupling of the analog supply, for the same reason as C1
  • C3 (capacitor) — the ADC reference is not modelled at all, so nothing reads the node this sits on
  • Y1 (crystal) — the oscillator itself — the system clock comes from the fuse bytes, not from solving this circuit
  • R1 (resistor) — the reset pull-up is drawn, not applied — RESET is not a modelled input and nothing here holds it high
  • C4 (capacitor) — a crystal load capacitor, and no oscillator is solved for it to load
  • C5 (capacitor) — a crystal load capacitor, and no oscillator is solved for it to load
  • L1 (inductor) — the ferrite between the digital and analog supplies — both rails are ideal sources here, so it separates nothing
  • LED1 (diode) — the on-board LED. On an Uno it hangs off an op-amp buffer, not off the pin, so it draws nothing from PB5 — wiring it as a load here would take current the real board does not

Arduino Nano (ATmega328P)

nano

  • An Uno in a smaller package. The TQFP part brings out A6 and A7, which are analog-only — they are ADC channels with no digital port bit, so they cannot be used with digitalRead.
  • Both .hex and .elf load directly — the engine sniffs the format, and an ELF also brings symbols.
  • Rust on AVR is nightly-only and needs -Zbuild-std with -C target-cpu; avr-gcc or the Arduino toolchain is the better-trodden path here.
  • The clock comes from the fuse bytes, not from solving the crystal circuit. Firmware that counts cycles for its delays runs at whatever the board's fuses select — see this board's clock.
  • One USART. Print over USART0 (D0/D1) — that is the output captured in the run.

Default 10s of virtual time, up to 60s. Runs at 16 MHz on a atmega328p.

Fitted parts the engine does not fully model
  • C1 (capacitor) — decoupling — the rail is an ideal source, so this capacitor sees no source impedance and changes nothing
  • C2 (capacitor) — decoupling of the analog supply, for the same reason as C1
  • C3 (capacitor) — the ADC reference is not modelled at all, so nothing reads the node this sits on
  • Y1 (crystal) — the oscillator itself — the system clock comes from the fuse bytes, not from solving this circuit
  • R1 (resistor) — the reset pull-up is drawn, not applied — RESET is not a modelled input and nothing here holds it high
  • C4 (capacitor) — a crystal load capacitor, and no oscillator is solved for it to load
  • C5 (capacitor) — a crystal load capacitor, and no oscillator is solved for it to load
  • L1 (inductor) — the ferrite between the digital and analog supplies — both rails are ideal sources here, so it separates nothing
  • LED1 (diode) — the on-board LED. On an Uno it hangs off an op-amp buffer, not off the pin, so it draws nothing from PB5 — wiring it as a load here would take current the real board does not

Arduino Pro Mini 5V/16MHz

pro-mini-16

  • Both .hex and .elf load directly — the engine sniffs the format, and an ELF also brings symbols.
  • Rust on AVR is nightly-only and needs -Zbuild-std with -C target-cpu; avr-gcc or the Arduino toolchain is the better-trodden path here.
  • The clock comes from the fuse bytes, not from solving the crystal circuit. Firmware that counts cycles for its delays runs at whatever the board's fuses select — see this board's clock.
  • One USART. Print over USART0 (D0/D1) — that is the output captured in the run.

Default 10s of virtual time, up to 60s. Runs at 16 MHz on a atmega328p.

Fitted parts the engine does not fully model
  • C1 (capacitor) — decoupling — the rail is an ideal source, so this capacitor sees no source impedance and changes nothing
  • C2 (capacitor) — decoupling of the analog supply, for the same reason as C1
  • C3 (capacitor) — the ADC reference is not modelled at all, so nothing reads the node this sits on
  • Y1 (crystal) — the oscillator itself — the system clock comes from the fuse bytes, not from solving this circuit
  • R1 (resistor) — the reset pull-up is drawn, not applied — RESET is not a modelled input and nothing here holds it high
  • C4 (capacitor) — a crystal load capacitor, and no oscillator is solved for it to load
  • C5 (capacitor) — a crystal load capacitor, and no oscillator is solved for it to load
  • L1 (inductor) — the ferrite between the digital and analog supplies — both rails are ideal sources here, so it separates nothing
  • LED1 (diode) — the on-board LED. On an Uno it hangs off an op-amp buffer, not off the pin, so it draws nothing from PB5 — wiring it as a load here would take current the real board does not

Arduino Pro Mini 3.3V/8MHz

pro-mini-8

  • Half the clock of the 5 V board, and the single most common cause of firmware that runs at the wrong speed: the same sketch, the same part, twice the delay.
  • Both .hex and .elf load directly — the engine sniffs the format, and an ELF also brings symbols.
  • Rust on AVR is nightly-only and needs -Zbuild-std with -C target-cpu; avr-gcc or the Arduino toolchain is the better-trodden path here.
  • The clock comes from the fuse bytes, not from solving the crystal circuit. Firmware that counts cycles for its delays runs at whatever the board's fuses select — see this board's clock.
  • One USART. Print over USART0 (D0/D1) — that is the output captured in the run.

Default 10s of virtual time, up to 60s. Runs at 8 MHz on a atmega328p.

Fitted parts the engine does not fully model
  • C1 (capacitor) — decoupling — the rail is an ideal source, so this capacitor sees no source impedance and changes nothing
  • C2 (capacitor) — decoupling of the analog supply, for the same reason as C1
  • C3 (capacitor) — the ADC reference is not modelled at all, so nothing reads the node this sits on
  • R1 (resistor) — the reset pull-up is drawn, not applied — RESET is not a modelled input and nothing here holds it high
  • L1 (inductor) — the ferrite between the digital and analog supplies — both rails are ideal sources here, so it separates nothing
  • LED1 (diode) — the on-board LED. On an Uno it hangs off an op-amp buffer, not off the pin, so it draws nothing from PB5 — wiring it as a load here would take current the real board does not

Arduino Duemilanove (ATmega328)

duemilanove

  • Both .hex and .elf load directly — the engine sniffs the format, and an ELF also brings symbols.
  • Rust on AVR is nightly-only and needs -Zbuild-std with -C target-cpu; avr-gcc or the Arduino toolchain is the better-trodden path here.
  • The clock comes from the fuse bytes, not from solving the crystal circuit. Firmware that counts cycles for its delays runs at whatever the board's fuses select — see this board's clock.
  • One USART. Print over USART0 (D0/D1) — that is the output captured in the run.

Default 10s of virtual time, up to 60s. Runs at 16 MHz on a atmega328p.

Fitted parts the engine does not fully model
  • C1 (capacitor) — decoupling — the rail is an ideal source, so this capacitor sees no source impedance and changes nothing
  • C2 (capacitor) — decoupling of the analog supply, for the same reason as C1
  • C3 (capacitor) — the ADC reference is not modelled at all, so nothing reads the node this sits on
  • Y1 (crystal) — the oscillator itself — the system clock comes from the fuse bytes, not from solving this circuit
  • R1 (resistor) — the reset pull-up is drawn, not applied — RESET is not a modelled input and nothing here holds it high
  • C4 (capacitor) — a crystal load capacitor, and no oscillator is solved for it to load
  • C5 (capacitor) — a crystal load capacitor, and no oscillator is solved for it to load
  • L1 (inductor) — the ferrite between the digital and analog supplies — both rails are ideal sources here, so it separates nothing
  • LED1 (diode) — the on-board LED. On an Uno it hangs off an op-amp buffer, not off the pin, so it draws nothing from PB5 — wiring it as a load here would take current the real board does not

Arduino Mini

mini

  • Both .hex and .elf load directly — the engine sniffs the format, and an ELF also brings symbols.
  • Rust on AVR is nightly-only and needs -Zbuild-std with -C target-cpu; avr-gcc or the Arduino toolchain is the better-trodden path here.
  • The clock comes from the fuse bytes, not from solving the crystal circuit. Firmware that counts cycles for its delays runs at whatever the board's fuses select — see this board's clock.
  • One USART. Print over USART0 (D0/D1) — that is the output captured in the run.

Default 10s of virtual time, up to 60s. Runs at 16 MHz on a atmega328p.

Fitted parts the engine does not fully model
  • C1 (capacitor) — decoupling — the rail is an ideal source, so this capacitor sees no source impedance and changes nothing
  • C2 (capacitor) — decoupling of the analog supply, for the same reason as C1
  • C3 (capacitor) — the ADC reference is not modelled at all, so nothing reads the node this sits on
  • Y1 (crystal) — the oscillator itself — the system clock comes from the fuse bytes, not from solving this circuit
  • R1 (resistor) — the reset pull-up is drawn, not applied — RESET is not a modelled input and nothing here holds it high
  • C4 (capacitor) — a crystal load capacitor, and no oscillator is solved for it to load
  • C5 (capacitor) — a crystal load capacitor, and no oscillator is solved for it to load
  • L1 (inductor) — the ferrite between the digital and analog supplies — both rails are ideal sources here, so it separates nothing
  • LED1 (diode) — the on-board LED. On an Uno it hangs off an op-amp buffer, not off the pin, so it draws nothing from PB5 — wiring it as a load here would take current the real board does not

LilyPad Arduino

lilypad

  • 8 MHz internal oscillator, no crystal.
  • Both .hex and .elf load directly — the engine sniffs the format, and an ELF also brings symbols.
  • Rust on AVR is nightly-only and needs -Zbuild-std with -C target-cpu; avr-gcc or the Arduino toolchain is the better-trodden path here.
  • The clock comes from the fuse bytes, not from solving the crystal circuit. Firmware that counts cycles for its delays runs at whatever the board's fuses select — see this board's clock.
  • One USART. Print over USART0 (D0/D1) — that is the output captured in the run.

Default 10s of virtual time, up to 60s. Runs at 8 MHz on a atmega328p.

Fitted parts the engine does not fully model
  • C1 (capacitor) — decoupling — the rail is an ideal source, so this capacitor sees no source impedance and changes nothing
  • C2 (capacitor) — decoupling of the analog supply, for the same reason as C1
  • C3 (capacitor) — the ADC reference is not modelled at all, so nothing reads the node this sits on
  • R1 (resistor) — the reset pull-up is drawn, not applied — RESET is not a modelled input and nothing here holds it high
  • L1 (inductor) — the ferrite between the digital and analog supplies — both rails are ideal sources here, so it separates nothing
  • LED1 (diode) — the on-board LED. On an Uno it hangs off an op-amp buffer, not off the pin, so it draws nothing from PB5 — wiring it as a load here would take current the real board does not

Arduino Mega 2560

mega2560

  • 256 KB flash, 8 KB SRAM, 54 digital pins and 16 analog inputs.
  • Both .hex and .elf load directly — the engine sniffs the format, and an ELF also brings symbols.
  • Rust on AVR is nightly-only and needs -Zbuild-std with -C target-cpu; avr-gcc or the Arduino toolchain is the better-trodden path here.
  • The clock comes from the fuse bytes, not from solving the crystal circuit. Firmware that counts cycles for its delays runs at whatever the board's fuses select — see this board's clock.
  • Four USARTs. Only USART0 (D0/D1) is captured as the run's output; the others are observable in the trace.
  • Flash is larger than 64 KB, so function pointers and jump tables need the far variants. avr-gcc handles this; hand-written asm may not.

Default 10s of virtual time, up to 60s. Runs at 16 MHz on a atmega2560.

Fitted parts the engine does not fully model
  • C1 (capacitor) — decoupling — the rail is an ideal source, so this capacitor sees no source impedance and changes nothing
  • C2 (capacitor) — decoupling of the analog supply, for the same reason as C1
  • C3 (capacitor) — the ADC reference is not modelled at all, so nothing reads the node this sits on
  • Y1 (crystal) — the oscillator itself — the system clock comes from the fuse bytes, not from solving this circuit
  • R1 (resistor) — the reset pull-up is drawn, not applied — RESET is not a modelled input and nothing here holds it high
  • C4 (capacitor) — a crystal load capacitor, and no oscillator is solved for it to load
  • C5 (capacitor) — a crystal load capacitor, and no oscillator is solved for it to load
  • L1 (inductor) — the ferrite between the digital and analog supplies — both rails are ideal sources here, so it separates nothing
  • LED1 (diode) — the on-board LED. On an Uno it hangs off an op-amp buffer, not off the pin, so it draws nothing from PB5 — wiring it as a load here would take current the real board does not

Arduino Mega ADK

mega-adk

  • A Mega 2560 with a USB host controller on SPI. The controller is a separate chip on the far side of the bus and is not modelled.
  • Both .hex and .elf load directly — the engine sniffs the format, and an ELF also brings symbols.
  • Rust on AVR is nightly-only and needs -Zbuild-std with -C target-cpu; avr-gcc or the Arduino toolchain is the better-trodden path here.
  • The clock comes from the fuse bytes, not from solving the crystal circuit. Firmware that counts cycles for its delays runs at whatever the board's fuses select — see this board's clock.
  • Four USARTs. Only USART0 (D0/D1) is captured as the run's output; the others are observable in the trace.
  • Flash is larger than 64 KB, so function pointers and jump tables need the far variants. avr-gcc handles this; hand-written asm may not.

Default 10s of virtual time, up to 60s. Runs at 16 MHz on a atmega2560.

Fitted parts the engine does not fully model
  • C1 (capacitor) — decoupling — the rail is an ideal source, so this capacitor sees no source impedance and changes nothing
  • C2 (capacitor) — decoupling of the analog supply, for the same reason as C1
  • C3 (capacitor) — the ADC reference is not modelled at all, so nothing reads the node this sits on
  • Y1 (crystal) — the oscillator itself — the system clock comes from the fuse bytes, not from solving this circuit
  • R1 (resistor) — the reset pull-up is drawn, not applied — RESET is not a modelled input and nothing here holds it high
  • C4 (capacitor) — a crystal load capacitor, and no oscillator is solved for it to load
  • C5 (capacitor) — a crystal load capacitor, and no oscillator is solved for it to load
  • L1 (inductor) — the ferrite between the digital and analog supplies — both rails are ideal sources here, so it separates nothing
  • LED1 (diode) — the on-board LED. On an Uno it hangs off an op-amp buffer, not off the pin, so it draws nothing from PB5 — wiring it as a load here would take current the real board does not

Arduino Diecimila (ATmega168)

diecimila

  • The pre-2009 board. Half the flash and half the SRAM of an Uno, which is why a modern sketch often will not fit it.
  • Both .hex and .elf load directly — the engine sniffs the format, and an ELF also brings symbols.
  • Rust on AVR is nightly-only and needs -Zbuild-std with -C target-cpu; avr-gcc or the Arduino toolchain is the better-trodden path here.
  • The clock comes from the fuse bytes, not from solving the crystal circuit. Firmware that counts cycles for its delays runs at whatever the board's fuses select — see this board's clock.
  • One USART. Print over USART0 (D0/D1) — that is the output captured in the run.
  • 16 KB flash and 1 KB SRAM. Smaller than the 328P boards; a build that fits an Uno may not fit here.

Default 10s of virtual time, up to 60s. Runs at 16 MHz on a atmega168p.

Fitted parts the engine does not fully model
  • C1 (capacitor) — decoupling — the rail is an ideal source, so this capacitor sees no source impedance and changes nothing
  • C2 (capacitor) — decoupling of the analog supply, for the same reason as C1
  • C3 (capacitor) — the ADC reference is not modelled at all, so nothing reads the node this sits on
  • Y1 (crystal) — the oscillator itself — the system clock comes from the fuse bytes, not from solving this circuit
  • R1 (resistor) — the reset pull-up is drawn, not applied — RESET is not a modelled input and nothing here holds it high
  • C4 (capacitor) — a crystal load capacitor, and no oscillator is solved for it to load
  • C5 (capacitor) — a crystal load capacitor, and no oscillator is solved for it to load
  • L1 (inductor) — the ferrite between the digital and analog supplies — both rails are ideal sources here, so it separates nothing
  • LED1 (diode) — the on-board LED. On an Uno it hangs off an op-amp buffer, not off the pin, so it draws nothing from PB5 — wiring it as a load here would take current the real board does not

Arduino Nano (ATmega168)

nano-168

  • Both .hex and .elf load directly — the engine sniffs the format, and an ELF also brings symbols.
  • Rust on AVR is nightly-only and needs -Zbuild-std with -C target-cpu; avr-gcc or the Arduino toolchain is the better-trodden path here.
  • The clock comes from the fuse bytes, not from solving the crystal circuit. Firmware that counts cycles for its delays runs at whatever the board's fuses select — see this board's clock.
  • One USART. Print over USART0 (D0/D1) — that is the output captured in the run.
  • 16 KB flash and 1 KB SRAM. Smaller than the 328P boards; a build that fits an Uno may not fit here.

Default 10s of virtual time, up to 60s. Runs at 16 MHz on a atmega168p.

Fitted parts the engine does not fully model
  • C1 (capacitor) — decoupling — the rail is an ideal source, so this capacitor sees no source impedance and changes nothing
  • C2 (capacitor) — decoupling of the analog supply, for the same reason as C1
  • C3 (capacitor) — the ADC reference is not modelled at all, so nothing reads the node this sits on
  • Y1 (crystal) — the oscillator itself — the system clock comes from the fuse bytes, not from solving this circuit
  • R1 (resistor) — the reset pull-up is drawn, not applied — RESET is not a modelled input and nothing here holds it high
  • C4 (capacitor) — a crystal load capacitor, and no oscillator is solved for it to load
  • C5 (capacitor) — a crystal load capacitor, and no oscillator is solved for it to load
  • L1 (inductor) — the ferrite between the digital and analog supplies — both rails are ideal sources here, so it separates nothing
  • LED1 (diode) — the on-board LED. On an Uno it hangs off an op-amp buffer, not off the pin, so it draws nothing from PB5 — wiring it as a load here would take current the real board does not

Don't see your chip?

Board coverage is driven by what people actually ask for. Tell us your target MCU and use case — requests genuinely shape what gets added next. In the meantime, the limits page covers what a run can and can't do.