Real boards, built from the datasheets

A RISC-V core at 160 MHz with GPIO, UART, the SYSTIMER, a twelve-bit ADC on GPIO 0 to 4 and LEDC PWM on any pin, on the real memory map.

Firmware for the modeled peripherals uses the board’s memory map. The contract also marks register addresses inside the SAR ADC and LEDC that are still unverified.

A complete ATmega328P, with three timers in every mode, USART0, the ADC, interrupts and sleep.

Blink, serial, a held button and a hardware PWM fade, at 16 MHz and real time.

The Uno's ATmega328P on a board 45 by 18 mm, so it pushes into the breadboard instead of standing beside it.

Two more analog inputs than an Uno, and the same firmware runs on both.

The big Arduino: fifty-four digital pins, sixteen analog inputs and four serial ports, on the ATmega2560.

Everything an Uno sketch knows how to do, with enough pins left over to do it to twelve things at once.

An Uno-shaped board whose USB goes to the chip itself: Serial is a USB CDC endpoint and Serial1 is pins 0 and 1.

The ATmega32U4 with its ten-bit timer, fourteen ADC channels and five external interrupts, at 16 MHz.

A second RISC-V board: thirty-one GPIOs, 512 KB of SRAM in one window, UART0, the SYSTIMER, a twelve-bit ADC on GPIO 0 to 6 and LEDC PWM on any pin.

The contract says plainly which addresses come from the manual, which are believed rather than verified, and what is not modeled at all.

The classic ESP32 on an Xtensa LX6 at 240 MHz: the GPIO matrix, UART0, timer group 0, a twelve-bit ADC1 and the eight LEDC PWM channels, on the real memory map.

One core where the chip has two, no radio and no FPU. Your own sketch compiles in the tab.

The ESP32-S3 on an Xtensa LX7 at 240 MHz: GPIO matrix, UART0, USB serial, ADC1, LEDC PWM and the RMT driving the RGB LED, on the real memory map.

One core where the chip has two, no radio and no FPU. Your own sketch compiles in the tab.

The Xtensa LX106 at 80 MHz in the call0 ABI, with D0 to D8 that are not GPIO numbers, two active-low LEDs, and PWM done in software because the chip has none.

WiFi uses a simulated network, with no radio or real internet. The ADC is the one block whose registers are this model’s own, because Espressif never published the chip’s.

RP2040 on our own ARMv6-M core, with SIO GPIO, the 1 MHz timer and alarms, UART0 and eight PWM slices.

Blink, a button, serial and a fade at real time, with sleep parked on WFI.

The same RP2040 and the same forty pins as the Pico, so the same ELF runs on it.

The CYW43439 is not modeled. WiFi uses a simulated network, and the on-board LED is driven through the board runtime rather than GP25.

A thumbnail-sized Cortex-M0+ at 48 MHz: eleven pads, every one of them an analog input, with PWM on ten of them.

Serial is the chip’s own USB, modeled as a byte pipe with no stack above it, and Serial1 is a real USART on D6 and D7.

The nRF52833 on our own Cortex-M4 core at 64 MHz, with GPIO, GPIOTE, three TIMERs, RTC0 and UARTE0 on the real register map.

The 5x5 LED matrix scanned as the hardware scans it, buttons A and B, the speaker and three rings on the edge connector.

A whole microcontroller in an 8-pin DIP, straight into the breadboard: six I/O, two timers, an ADC and a USI.

Blink, a button on INT0, a knob on the ADC and a serial port it bit-bangs for itself.

Cortex-M4 with Thumb-2, NVIC and SysTick at 84 MHz, with GPIO, TIM2 to TIM5 and USART1 on the real register map.

Blink on PC13, a button, serial and a PWM fade, all at real time.

Cortex-M3 at 72 MHz, with GPIO on the F1’s CRL and CRH, TIM1 to TIM4, USART1 and a twelve-bit ADC.

Blink on PC13, a button, serial with a live reading, and a PWM fade, all at real time.

Renesas RA4M1, Arm Cortex-M4 at 48 MHz, in an Uno’s shape and on an Uno’s 5 V pins. Modeled: the PFS port block, GPT PWM on the six tilde pins, SCI2 as Serial1 on D0 and D1, and a fourteen-bit ADC that analogRead reads ten bits of.

Not modeled: a USB stack (Serial is a byte pipe with no enumeration behind it), the ICU, so there is no attachInterrupt, and the AGT. The contract says plainly which addresses come from the manual and which are believed rather than verified.

The Uno’s ATmega328P on the smallest Arduino there is, with no USB on it, in both builds: 5 V at 16 MHz and 3.3 V at 8 MHz.

The 3.3 V board really runs at 8 MHz, so a sketch built for 16 MHz keeps half time on it, as it does on the bench.

The Leonardo’s ATmega32U4 on a board that pushes into a breadboard, with the L LED on pin 13 and the SPI pins on holes of their own.

Serial is the chip’s own USB and Serial1 is pins 0 and 1, and the Leonardo’s programs run on it unchanged.

The ATmega32U4 in a Pro Mini’s footprint with a USB socket on the end, running the Leonardo’s programs.

No LED on pin 13: its lamps are RX and TX, lit by pulling their pins low.

The NodeMCU’s ESP8266 on a board a third the size, with the same D0 to D8 names and only the holes that do something.

WiFi on a simulated network, and your own sketch compiles in the tab.

An ESP8266 with eight pins, four of them GPIO, and a blue LED that lights when its pin is low.

Wired with jumpers, because its two rows will not sit in a breadboard. WiFi is simulated.

The ESP32-C3 at 160 MHz on the XIAO’s thumbnail outline: fourteen pads, and D0 to D10 that are the XIAO’s numbers, not GPIOs.

No user LED to blink, WiFi on a simulated network, and sketches that compile in the tab.

The smallest ESP32-C3 board in common use, sixteen pins named by GPIO, at 160 MHz.

Its blue LED on GPIO 8 lights when the pin is LOW, the other way around from the DevKit’s.

The Uno R4’s RA4M1 with a 12 x 8 LED matrix to draw on through Arduino_LED_Matrix.h.

WiFi through WiFiS3.h on a simulated network: no radio, no ESP32-S3 in the model, no real internet.