Microcontrollers & firmware

The chips

• ATmega328P (the Nano and the Arduino Uno R3): 16 MHz AVR, 5 V logic. Runs bundled bare-metal examples or any Intel HEX you export from the Arduino IDE (Sketch → Export Compiled Binary), pasted or uploaded in the Inspector.
• ATmega2560 (Arduino Mega): 16 MHz AVR with 256 KB flash, 8 KB SRAM, 54 digital pins, 16 ADC channels, four hardware serial ports, and all six timers modeled.
• Arduino Uno R4: RA4M1 with 5 V header pins, a live 12×8 LED matrix, ADC inputs on A0–A5, DAC output on A0, and I²C through Wire on A4/A5 or Wire1 on the Qwiic connector. Upload firmware built for the R4; Uno R3 firmware is not interchangeable. Wi-Fi and BLE are not yet simulated on this board. Start with the Uno R4 blink example.
• Raspberry Pi Pico: RP2040, Cortex-M0+ at 125 MHz, 3.3 V logic with a real onboard regulator. The Pico 2 uses an RP2350 at 150 MHz and accepts both the default Arm MicroPython build and the RISC-V CPU mode variant. All four Pico boards take UF2 uploads; choose the image for your exact board, including the W suffix for wireless models.
• ESP32 (classic): dual-core Xtensa LX6. Boots unmodified ESP-IDF apps, MicroPython, and compiled Arduino-ESP32 sketches from .bin images, through the genuine Espressif boot ROM.
• ESP32-C3: RISC-V at 160 MHz. Same firmware formats as the classic ESP32, single RISC-V core.
• ESP32-S2: single-core Xtensa LX7 at 240 MHz with Wi-Fi only. Its native USB-OTG device controller enumerates real TinyUSB CDC firmware for bidirectional serial while preserving UART0; all four hardware pulse-counter units are modeled too.
• ESP32-S3: dual-core Xtensa LX7 at 240 MHz, validated instruction-by-instruction against Espressif's QEMU. Same firmware formats as the C3, with FreeRTOS scheduling across both cores.
• ESP32-C6: single RISC-V RV32IMAC core at 160 MHz with 512 KB SRAM. Same firmware formats as the C3, and the busiest radio bench of the family: Wi-Fi 6, Bluetooth LE, and an 802.15.4 radio that runs real Zigbee and OpenThread firmware. Its Inspector gets a tab per radio.
• ESP32-H2: single RISC-V RV32IMAC core at 96 MHz with 320 KB SRAM. It runs ESP-IDF and Arduino firmware with Bluetooth LE plus the same 802.15.4 Zigbee/OpenThread air as C6, but has no Wi-Fi and no official MicroPython port. USB-Serial-JTAG carries its console.
• ESP32-C5: single RISC-V RV32IMAC core at 240 MHz behind a CLIC interrupt controller, on the real DevKitC-1 v1.2 footprint. Same firmware formats as the C6 — including official MicroPython — and the only dual-band board on the bench: its Wi-Fi 6 station scans and joins 5 GHz networks as well as 2.4 GHz ones, and a 2.4 GHz-only board genuinely cannot see them — the “Dual-band Wi-Fi” example puts a C5 and a C6 side by side on one AP list so you can read the difference. It carries the same 802.15.4 radio as the C6; Bluetooth LE works in both roles, GATT included; and its digital pin I/O, I²C (g23/g24), hardware SPI, PCNT and ADC1 (g1–g6) all work, on this chip’s own re-laid GPIO register map rather than the C6 layout.

ESP32-P4: the J1 workbench

The Function EV Board v1.5.2 exposes its physical 40-position J1 header, including five NC contacts and GPIOs above 31. Wire 5V and GND, then an external LED through a resistor to GPIO6 for the bundled Arduino blink. The MicroPython example instead blinks GPIO54.

Two 400 MHz RISC-V cores run the pinned v1.29.0 source build for rev3 silicon with UART and USB Serial-JTAG. Select it in the Inspector, then use Code or the serial REPL. The official pre-rev3 binary is incompatible with this board’s rev300 ROM. Native and viper emitters work. Both I²C controllers and SPI2/3 follow explicit GPIO-matrix pins; the firmware’s default bus pins are not complete J1 pairs or triples. GPIO, ADC, static PWM and NeoPixel transmit work.

This console firmware profile has no networking. For the separately selected C6_WIFI companion profile and its limits, see the Component reference. USB-OTG transfers, the LP core, media, general SD cards, LEDC fades, RMT receive/carrier, I²C stretching/arbitration and SPI slave/multiline modes remain unsupported; unmodeled peripheral accesses fault. Arduino compilation uses a fixed rev3 profile when enabled on the server. Chromium WebSerial accepts its compiled artifacts for P4 revision 3.0/ECO5 boards with 16 MB flash through J19 USB Serial/JTAG or an external UART0 bridge. Other revisions, USB-OTG and secured chips are unsupported. J19 may stay silent after flashing because Arduino Serial uses UART0. Random bytes and SSL material repeat across identical runs and snapshots: the emulated TRNG is deterministic and is not cryptographic entropy.

Why upload MicroPython?

Breadboard emulates the chip and runs its real firmware. MicroPython is the program that lets that chip run Python; a script in the Code tab needs it on the simulated board first. A UF2 is the firmware file you upload to install it. The firmware is needed for Python; uploading it yourself is how Breadboard currently sets up these boards, rather than a requirement of emulation.

A newly placed Pico starts with a small blink demo, which does not run Python. Pico W, Pico 2 and Pico 2 W start without a program. Some ready-made examples include their own firmware; keep that program unless you intend to replace it. MicroPython is optional if you are using compiled C or Rust firmware instead.

For Pico W and Pico 2 W, the official images also include third-party radio firmware. We link to the official download rather than redistribute those images with Breadboard. You can upload your own copy into your project.

1. 1Select the board and use Download MicroPython in the Inspector. On a Pico with a program already loaded, open Change… first. The link opens the download page for that exact board.
2. 2Download a .uf2 file. For Pico 2 or Pico 2 W, choose the default Armbuild; the RISC-V variant is also supported.
3. 3Drop the file into the Inspector, then open Serial. With the board powered and the simulation running, wait for the Python prompt (>>>). You can then type Python there or run a script from the Code tab.

Save the project to keep the uploaded firmware with it; you do not need to upload it on every restart. This upload programs the simulated board, not a physical Pico connected to your computer.

MicroPython and dependency licence notices: Pico v1.25.0 · Pico 2 v1.29.0 (Arm).

On Pico and Pico W, uploaded firmware starts through Raspberry Pi's real RP2040 boot ROM. Breadboard downloads it as a separate file, licensed under the GNU GPL version 2, with its licence notices and complete source code.

Measured alternative firmware

An accepted file format is only the container. Toolchains can change their startup code and touch chip features the emulator does not model yet, so the table below names the exact versions and boundaries we have booted twice from a clean power-on.

Rust firmware is bring-your-own compiled firmware; Breadboard's cloud compiler does not build Rust. The verified Pico recipe uses rp2040-hal 0.12.0. The ESP32-C3 recipe uses esp-hal 1.1.2 with its default configuration, including the hardware abstraction layer's stack-guard watchpoint: the chip's trigger registers are modeled. No other ESP32 Rust target is claimed.

Uploaded Pico, Pico W, Pico 2 and Pico 2 W UF2 files are treated as possible USB serial consoles, so the workbench sends the harmless carriage-return wake nudge needed by MicroPython and CircuitPython. The nudge is armed only for an uploaded UF2; bundled raw Pico examples never receive a stray byte.

The serial monitor

The Serial panel opens itself the moment a board prints. Multi-board benches get a tab per board; the input row types to the active tab or to all boards (toggle next to it). This is a real UART (start bits, baud timing and all), so a MicroPython board gives you its actual REPL prompt to type at.

The Code tab: whole scripts

The Code tab runs complete MicroPython scripts on the board: write (or load an example's prefilled script), press Run on board, and the script is injected through the REPL. The run status tracks completion, and a traceback anywhere surfaces as an error banner with the offending line. Scripts re-run automatically on every boot: restart the sim and your program starts with it, exactly like flashed firmware.

from machine import Pin, I2C
import time

led = Pin(2, Pin.OUT)
for n in range(10):
    led.value(n % 2)
    print('blink', n)
    time.sleep_ms(250)

Arduino C++: compiled on the server

Switch the Code tab to Arduino C++ and the same editor holds a real sketch. Press Compile & upload (or Ctrl Enter) and the sketch is built by the cloud compile service and flashed onto the bench board seconds later; compile errors come back with the failing lines marked in the editor. Signed-in accounts only. The target board follows the bench automatically when a single MCU is present.

The compile targets are Arduino Uno R3, Mega and Nano (Intel HEX), plus classic ESP32, ESP32-C3, ESP32-S2, ESP32-S3, ESP32-C5, ESP32-C6 and ESP32-H2 (Espressif images). C6 uses its ordinary esp32c6 profile for OpenThread and adds fixed Zigbee coordinator/router and end-device roles. H2 exposes separate ordinary, OpenThread, Zigbee coordinator/router, and Zigbee end-device profiles. Those keys pin the role and partition menu values on the server; sketches cannot supply arbitrary FQBN flags.

Alongside the Arduino AVR and ESP32 cores (Wire, SPI, WiFi, Zigbee, OpenThread and friends), the compiler ships a curated set of popular libraries, each pinned to a known version and chosen because the bench actually has the hardware it drives.

• Adafruit PCF8574 1.1.2: PCF8574 quasi-bidirectional GPIO and active-low interrupt; PCF8575 is not modeled (Arduino AVR, Uno R4 and ESP32 targets; see part limitations)
• Adafruit INA219 1.2.3: INA219 shunt, bus voltage, calibrated current and power (Arduino AVR, Uno R4 and ESP32 targets; see part limitations)
• Adafruit TCS34725 1.4.4: TCS34725 ID, integration time, gain and RGB/clear readings (Arduino AVR, Uno R4 and ESP32 targets; see part limitations)
• Adafruit Thermal Printer Library 1.4.1: thermal printer text, feed and supported formatting over hardware UART; bitmap, barcode, status and DTR are not modeled (hardware UART on Arduino AVR and Uno R4; ESP32 printer routing is not modeled)
• I2C_EEPROM 1.9.4: AT24C32 external EEPROM with 4096 bytes, 32-byte pages and write-busy polling; construct I2C_eeprom(0x50, 4096) and call setExtraWriteCycleTime(5) for the modeled 10 ms write cycle (Arduino AVR, Uno R4 and ESP32 targets; see part limitations)
• LiquidCrystal_PCF8574 2.3.0: HD44780 LCD backpack driver; compile-only: AVR I2C byte timing can collapse PCF8574 E strobes (Arduino AVR, Uno R4 and ESP32 targets; see part limitations)
• RotaryEncoder 1.6.0: quadrature rotary encoder by polling tick() with pull-ups on both phases (Arduino AVR, Uno R4 and ESP32 targets; see part limitations)
• SevSeg 3.7.0: single-digit and multiplexed four-digit seven-segment displays; match common-pin polarity, use segment resistors and call refreshDisplay() on every loop pass (Arduino AVR, Uno R4 and ESP32 targets; see part limitations)
• TinyStepper_28BYJ_48 1.0.0: 28BYJ-48/ULN2003 stepper with speed and acceleration control; the image corrects only its Arduino.h include casing (Arduino AVR, Uno R4 and ESP32 targets; see part limitations)
• OneWire 2.3.8: externally powered DS18B20 ROM search, CRC and conversion protocol (Arduino AVR; Uno R4 generic fallback and ESP32/C3/S2/S3 require board checks; C5/C6/H2/P4 are not admitted)
• DallasTemperature 4.0.6: DS18B20 temperature readings through OneWire; external power only (Arduino AVR; Uno R4 generic fallback and ESP32/C3/S2/S3 require board checks; C5/C6/H2/P4 are not admitted)
• DS18B20 1.0.0: alternative DS18B20 temperature API through OneWire; external power only (Arduino AVR; Uno R4 generic fallback and ESP32/C3/S2/S3 require board checks; C5/C6/H2/P4 are not admitted)
• IRsmallDecoder 1.3.0: NEC infrared key/repeat reception; receive-only, one protocol per build (Arduino AVR, Uno R4 and ESP32 targets; see part limitations)
• MFRC522 1.4.12: MIFARE Classic 1K with four-byte UID, authentication and block I/O over fixed hardware SPI; other tag types are not modeled (Arduino AVR, Uno R4 and ESP32 targets; see part limitations)
• TM1637_RT 0.5.0: TM1637 four-digit display, colon, brightness and ACK; select four digits (Arduino AVR, Uno R4 and ESP32 targets; see part limitations)
• Encoder 1.4.4: quadrature rotary encoder through real contact transitions and pull-ups (Arduino AVR only; Uno R4 and ESP32 targets are not admitted)
• AccelStepper 1.64.0: 28BYJ-48/ULN2003 stepper; firmware using this library carries GPL-3.0 terms (Arduino AVR, Uno R4 and ESP32 targets; see part limitations) · source and licence
• CheapStepper 0.2.1: 28BYJ-48/ULN2003 stepper; firmware using this library carries GPL-3.0 terms (Arduino AVR and Uno R4 only; pinned source does not compile on ESP32 targets) · source and licence
• IRremote 4.7.1: NEC infrared key/repeat reception; GPL-3.0-or-later source headers are linked, and IR transmission is not modeled (Arduino AVR, Uno R4 and ESP32 targets; see part limitations) · source and licence
• Adafruit GFX Library 1.12.6: drawing primitives for the Adafruit display drivers
• Adafruit ADS1X15 2.6.2: ADS1115 conversion polling; comparator/ALERT and ADS1015 are not modeled (verified on Uno R3, Uno R4 and ESP32-C3)
• Adafruit MCP4725 2.0.2: MCP4725 DAC output and EEPROM writes with busy/NACK handling; pass the part’s address to begin() (bench default 0x60; library default 0x62) (verified on Uno R3, Uno R4 and ESP32-C3)
• BH1750 1.3.0: BH1750 measurement modes, integration delay and lux readings (verified on Uno R3, Uno R4 and ESP32-C3; upstream metadata omits Uno R4)
• Adafruit BusIO 1.17.4: I2C/SPI helper the Adafruit drivers build on
• Adafruit SSD1306 2.5.17: the 128x64 / 128x32 OLED panels
• Adafruit SH110X 2.1.14: the SH1106 and SH1107 OLED panels
• Adafruit ST7735 and ST7789 Library 1.11.0: the 1.8" color TFT
• U8g2 2.36.19: the monochrome OLEDs and LCD, alternative API
• LiquidCrystal 1.0.7: the HD44780 16x2 character LCD
• LedControl 1.0.6: MAX7219 LED matrices and 7-segment drivers (Arduino AVR only)
• MD_MAX72XX 3.5.1: MAX7219 matrix cascades
• MD_Parola 3.7.5: scrolling-text effects on MAX7219 cascades
• GxEPD2 1.6.9: the SSD1681 e-paper panels; firmware using this library carries GPL-3.0 terms · source and licence (heavyweight: needs a Pro build budget)
• Adafruit NeoPixel 1.15.5: WS2812 addressable LEDs
• FastLED 3.10.5: WS2812 addressable LEDs, effects-oriented API (heavyweight: needs a Pro build budget)
• DHT sensor library 1.4.7: the DHT11 climate sensor
• Adafruit Unified Sensor 1.1.15: shared sensor base for the Adafruit drivers
• Adafruit BME280 Library 2.3.0: the BME280 environment sensor
• Adafruit MPU6050 2.2.9: the MPU-6050 accelerometer/gyro
• RTClib 2.1.4: the DS3231 real-time clock
• NewPing 1.9.7: the HC-SR04 ultrasonic ranger
• Sensirion I2C SEN5X 0.3.0: the SEN55 air-quality sensor
• Sensirion Core 0.7.3: shared base for the Sensirion drivers
• Servo 1.3.0: hobby servos (Arduino Uno R3 and Uno R4)
• ESP32Servo 3.2.1: hobby servos via LEDC (ESP32 boards only)
• Keypad 3.1.1: the 4x4 matrix keypad; firmware using this library carries GPL-3.0 terms · source and licence
• ArduinoJson 7.4.3: JSON parsing for the Wi-Fi/HTTP examples
• Keyboard 1.0.7: USB keyboard reports (Uno R4)
• Mouse 1.0.1: USB mouse reports (Uno R4)
• ArduinoGraphics 1.1.5: text and drawing for the Uno R4 LED matrix (Uno R4)
• SD 1.3.0: the microSD card (FAT files); firmware built with this library carries GPL-3.0 terms. Builds combining SD 1.3.0 with NewPing 1.9.7 are refused; use SdFat (MIT) with NewPing instead (AVR and Uno R4; ESP32 uses its core SD library) · source and licence
• SdFat 2.3.0: the microSD card over hardware SPI (FAT files); MIT-licensed, recommended for closed-source firmware and the example default — use each board’s fixed hardware-SPI pins

SdFat software SPI (DigitalIO) (any board): its optional DigitalIO files (GPL-3.0) are not shipped. SdFat’s default hardware-SPI driver is unaffected.

Builds are metered in build minutes: each build costs its wall-clock time rounded up to whole minutes, so a quick Uno sketch costs 1 and a heavyweight library build costs a few. Free accounts get 15 minutes a day (100 a month) with up to 150 seconds per build; Pro raises that to 100 a day (250 a month) and 480 seconds per build, which is what the heavyweight libraries marked above need.

Sketches are not limited to one file: the Code tab's + file button adds .h/.cpp headers and sources (and extra .ino tabs) that compile together, exactly like tabs in the Arduino IDE. The same works for MicroPython — extra .py modules are importable from main.py. Files save, share, and export with the project.

Pro accounts can additionally attach up to four custom libraries from a .zip (the Libraries row in the Code tab): source-only Arduino libraries (headers plus .cpp, up to 40 files each) that are compiled with the sketch and carried inside the project document, so a shared project still builds for whoever opens it. A custom library with the same name as a built-in one takes priority.

Flashing real hardware

A compiled sketch doesn't have to stay in the simulator. ⚡ Flash device… next to the Compile button writes the exact same firmware onto a real board over USB — no toolchain install, no agent. This uses WebSerial, which only Chromium browsers support on desktop: Chrome, Edge, Opera and Brave work; Firefox, Safari and all mobile browsers don't (the button stays visible there, disabled, and says why).

Arduino Uno R3 / ATmega328P, classic ESP32, ESP32-C3, ESP32-S3, ESP32-C5, ESP32-C6 and ESP32-H2 compile artifacts can be flashed. The dialog validates the board-specific layout and image identity before it offers Connect, so an older, malformed or wrong-board compile cannot open the USB port. The ESP path requires a complete bootloader, partition-table and app image; it erases, writes, MD5-verifies and reboots the board. The Uno path strictly parses the hosted application Intel HEX, resets Optiboot through DTR at 115200 baud, requires the exact ATmega328P signature before writing, programs all 252 application pages without touching the bootloader, and reads all 32,256 application bytes back byte-for-byte. The signature proves the MCU, not the Uno form factor: another ATmega328P board with a compatible 115200-baud bootloader can identify the same way.

Deploying MicroPython files

In the MicroPython Code tab, Deploy to real board opens the initial ESP32-C3-DevKitM-1, 4 MB profile. Use its USB-to-UART connector in a desktop Chromium browser. Confirm the board markings; the ROM identifies the chip, not its pinout. Connecting interrupts the current program. Physical SEN55, OLED and power-cycle acceptance for this initial profile is still pending.

A compatible MicroPython 1.28.0 installation can be reused. Download and save the filesystem backup, then approve replacing main.py. The project files are written unchanged into a new folder and read back for SHA-256 verification before a startup launcher is committed. Missing Python package initializers are added; existing boot.py and unrelated files are preserved. Old project folders remain until you remove them, so repeated updates consume storage. This flow does not deploy a project's own root boot.py.

If the runtime is incompatible or absent, a separate confirmation permits erasing the entire 4 MB device and installing the pinned runtime. Unreadable files cannot be backed up here. The dialog distinguishes verified files, an observed startup launcher and actual serial output; inspect that output and the circuit before treating your project as working. The parts and wiring guide covers the featured air-quality station only.

Two serial ports, one console

A C3/C5/C6/H2 DevKit can expose two USB consoles: the native USB-Serial-JTAG port and, on dual-port boards, a USB-UART bridge. C3/C5/C6/H2 sketches are built with USB CDC on boot, so Serial is the native-port console — which is why prints show up in the flash boot tail even on native-USB-only boards like the C6-Zero. Serial0 is still UART0, on the bridge port. The simulator merges both into the one Serial panel, so a sketch shows the same output on the bench as on the desk.

The onboard RGB LED

C6 DevKits carry an addressable WS2812 on GPIO8, and the simulated board has it too: rgbLedWrite(8, r, g, b) lights it on the board sprite exactly as it lights the real one, without wiring anything up. Colours follow the WS2812 datasheet, so if a particular board renders them shifted (some Waveshare pixels read our red as green-ish), that is the board's own channel order, not the simulator's.

Powering a board

A newly placed Arduino, supported ESP32 DevKit or Pico board has a modeled USB cable connected. Its saved USB cable control in the Inspector supplies power; the board's USB badge shows cable presence. Unplug it to test external power or brownout. Old saved circuits and bundled examples keep their existing supply wiring; opening one does not connect a cable. Bare ATmega328P and S31 modules still need an external supply.

USB power does not install firmware. Pico W, Pico 2, Pico 2 W and Uno R4 start with an empty firmware slot and wait for a real upload. Other boards keep their bundled blink program. On Uno R4 the cable control changes power and data together; older documents can retain a separate data-only attachment.

Boards are electrical citizens: an ESP32 needs ~5 V on vin (its onboard LDO makes the 3.3 V rail, which can power your sensors), and the Pico wants vsys. On Uno/Nano/Mega with an explicit USB cable setting, vin feeds the onboard regulator: use at least 6.5 V (7–12 V typical). A 5 V supply goes to 5v. Undervolt a board and it browns out; the en pin really resets the chip.