The Wemos D1 R32

A classic ESP32 on the Arduino Uno's outline, with the Uno's four headers, and a blue LED on GPIO 2 that lights when the pin is HIGH.

What it is

The same classic ESP32 as the ESP32 DevKit V1, as an ESP32-WROOM-32 module where the Uno's ATmega328P would be. The four headers are in the Uno's places, so a shield plugs in and a breadboard lines up the way it does beside an Uno. A micro-USB socket goes through a USB-to-serial chip to UART0, which is the serial monitor.

Like an Uno, it is too wide to push into a breadboard. It stands beside one and reaches it with jumpers.

The pins

The board prints the Uno's names, but a sketch writes the GPIO numbers. On this board D2 is GPIO 26, not GPIO 2, so digitalWrite(2, HIGH) lights the blue LED and does nothing at the hole marked D2. The catalog names each hole by its GPIO (IO26), and the drawing prints the Uno name beside it.

Printed	GPIO		Printed	GPIO
D0 (RX0)	3		A0	2 (the LED)
D1 (TX0)	1		A1	4
D2	26		A2	35
D3	25		A3	34
D4	17		A4	36
D5	16		A5	39
D6	27		SDA	21
D7	14		SCL	22
D8	12		IOREF	3.3 V
D9	13		3V3	3.3 V
D10	5		5V	5 V
D11	23		RESET
D12	19		VIN	open
D13	18		AREF	open

The firmware defines D0 to D13 and A0 to A5 as these GPIO numbers, as the Arduino IDE's d1_uno32 board does, so digitalWrite(D2, HIGH) drives GPIO 26 too. Writing the GPIO number is clearer.

A2 to A5 are GPIO 35, 34, 36 and 39, which are inputs only: there is no output driver on them and no internal pull-up. A0 and A1 are GPIO 2 and 4, which are on ADC2, and ADC2 is not modeled, so analogRead(A0) and analogRead(A1) read 0 here. Use A2 to A5 for analog. Wire uses SDA (GPIO 21) and SCL (GPIO 22), and SPI uses D13, D12, D11 and D10 for SCK, MISO, MOSI and SS, as on an Uno.

Some boards misprint two of the GPIO labels on the analog header: the white label IO36 beside A2 is really GPIO 35, and IO38 beside A4 is really GPIO 36. The catalog uses the real GPIOs.

The power pins

IOREF is 3.3 V, because the board's logic is 3.3 V. That is the thing a 5 V shield needs telling: the ESP32's pins are not 5 V tolerant. 3V3 and 5V are supplies for the breadboard. VIN is the barrel jack's side of the regulator, and AREF is not connected to anything on the R32, so both are open here. The board is always powered from USB.

The LED

The blue LED is on GPIO 2, which is also the A0 hole. It lights when the pin is HIGH. LED_BUILTIN is 2, so anything wired to A0 shares the pin with the LED.

Buttons

The board has one button, RESET. There is no BOOT button: on the real board the USB chip pulls GPIO 0 low to start the loader. The board's BOOT poke does the same here.

WiFi

It joins Mokxi's simulated network, with the network name and password as properties of the board. There is no radio, no 802.11 and no real internet: Simulated WiFi says what is faithful and what is not.

What is modeled

The DevKit V1 model's chip, whole: one Xtensa LX6 core, GPIO, UART0, the timers, ADC1 and LEDC PWM. The board carries its own program string, so it is offered its own examples, built for its LED and its Uno names. GPIO 34, 35, 36 and 39 refuse to be outputs, as on the chip.

What is not modeled

The second core, ADC2 (and the noise it picks up from the radio on a real board), the DAC, touch sensing, Bluetooth and a real radio. VIN and AREF are open, and the board's 5 V regulator is not modeled: the board runs from USB as long as the simulation does.

Starter project

D1 R32 button is the board beside a breadboard with a pushbutton on the hole printed D2, which is GPIO 26, lighting an LED on D3, which is GPIO 25, and the blue LED with it.