The ESP32-C6-DevKitC-1

A second RISC-V board: the same core as the ESP32-C3 at 160 MHz, with thirty-one GPIOs, half a megabyte of SRAM and an addressable RGB LED on GPIO 8.

What it is

An ESP32-C6-WROOM-1 module on a 52.5 by 25.4 mm board, with two fifteen-pin headers 0.9 inch apart, so it straddles a breadboard's center channel with a free row on each side. The reference page is The ESP32-C6 model.

The high-performance core is the one Mokxi runs: RV32IMC at 160 MHz, one instruction per cycle, the same hart as the C3.

How it differs from the C3

Four things, and none of them is the instruction set.

• Thirty-one GPIOs rather than twenty-two, numbered 0 to 30. GPIO 24 and up are the SPI flash and are on neither header.
• 512 KB of SRAM in one window. On a C3 the same RAM appears twice, once for each bus; here both buses reach it at the same addresses, which is why the linker script is simpler and .data needs no copy at reset.
• An addressable RGB LED on GPIO 8, where a C3-DevKitM-1 has one too but a plain LED is what most sketches drive.
• Two USB-C sockets. One goes to a USB-to-UART bridge, which is what the serial monitor talks to; the other goes to the chip's own USB, which Mokxi does not model.

An ELF built for a C3 will not run here and the editor will not offer you one: same instruction set, different memory map.

The RGB LED

GPIO 8 is the board's own WS2812. It wants twenty-four bits, not a level, so the board part does not decode it: a WS2812 is a protocol. Wire the WS2812 part to GPIO 8 and the colors are real.

The built-in Rainbow program does exactly that, bit-banging the pulse widths from a counted loop. That is not a shortcut here: the RMT peripheral that would normally drive it is not modeled.

The analog pins

GPIO 0 to GPIO 6 are ADC1 channels 0 to 6, and analogRead() on one of them is a real conversion of the voltage on the pin: twelve bits, 0 to 4095, against a full scale the attenuation picks. The default is 11 dB, about the whole 3.3 V rail, so a potentiometer or a thumb stick across the supply spans the range; analogSetPinAttenuation() takes ADC_0db (1.1 V), ADC_2_5db (1.5 V), ADC_6db (2.2 V) or ADC_11db, and analogReadResolution() shifts the result if you want an Uno's ten bits back.

One read costs about five microseconds of simulated time, which is what the converter takes. A pin with nothing on it reads 0 rather than noise. Seven analog inputs and no more: any other pin reads 0 too.

PWM

analogWrite(pin, 0..255) works on any GPIO. The output comes from LEDC, the chip's LED PWM controller, and reaches the pin through the GPIO matrix, so there is no fixed set of ~ pins the way there is on an Uno.

The default is eight bits at 1 kHz. When the frequency matters (a servo wants fifty frames a second and a pulse width, not a duty), use the ESP32 spelling:

ledcAttach(4, 50, 14);        // fifty frames a second, 16384 counts each
ledcWrite(4, 1229);           // 1.5 ms of a 20 ms frame: the middle

There are six channels and four timers. Channels asking for the same frequency and resolution share a timer, so six pins fading together cost one of the four; ask for a fifth distinct pair and ledcAttach returns false rather than retuning a timer another pin is riding on. pinMode() and digitalWrite() take a pin back from LEDC, so a pin that was fading and is then written to is really written to.

A duty of 0 is a solid low and a duty of 255 a solid high, out of the hardware, with no edges at all, which also means the simulator has nothing to wake the board for.

WiFi, simulated

There is no radio. There never will be: an 802.11 MAC is not something this model could reproduce honestly.

What there is, since September 2026, is a simulated network. A block that is Mokxi's own rather than the chip's (a mailbox at 0x6FFF_E000, where a real C6 has nothing mapped at all) carries WiFi.h, HTTPClient.h and WebServer.h, so the Arduino code a tutorial gives you runs here: the board joins an access point whose name and password are properties of the board, WiFi.status() walks the same states in the same one to three seconds, DHCP leases it 192.168.4.2, and a sketch can fetch a page or serve one.

What is behind it is software, and nothing is hidden about that. There is no 802.11, no channel, no scan, no WPA2, no TCP, no TLS and no real internet: four made-up names under .mokxi resolve and no others, and nothing a sketch does can reach the network your browser is on. WiFiClientSecure compiles and then fails, saying TLS is not simulated. The Web and Cloud panels along the bottom of the editor open with that sentence and do not scroll it away.

Three examples ship for this board: WiFi: join the network, WiFi: fetch the weather and WiFi: a lamp on a web page.

WiFi, simulated is how to use it; Simulated WiFi is the contract, limit by limit.

What this model does not have

More than usual, and the contract says so rather than inventing register offsets it cannot stand behind.

• No radio. No 802.11, no Bluetooth LE, no Thread or Zigbee. The WiFi above it is simulated and says so.
• No low-power core. The C6's LP domain is half of what makes the chip interesting and none of it is here.
• No RMT, which is what would normally drive the RGB LED, and none of the SAR ADC beyond ADC1's one-shot path or of LEDC beyond its timers and channels.
• Five of the model's base addresses (GPIO, IO_MUX, SYSTIMER, LEDC and the SAR ADC) are its best account rather than something it can stand behind, and so are the GPIO matrix signal numbers LEDC's channels use. They are named in one header, so an image being taken to real silicon has a short list of #defines to check. Section 7 of the reference page is the list, and sections 3.6 and 3.7 mark the two newest blocks register by register.

The firmware

Nine built-in programs: Blink, Button (the BOOT button on GPIO 9), Serial, Fade, WiFi: join the network, WiFi: fetch the weather, WiFi: a lamp on a web page, Thumb stick and Rainbow.

Fade breathes an LED on GPIO 10 with analogWrite, so the waveform comes out of the hardware and the core sleeps between steps. Thumb stick reads a KY-023 on ADC1 channels 0 and 1, prints both axes, and lights the LED on the side you push towards as brightly as you push it: one sketch using both of the peripherals this board grew.

Serial is UART0 and goes to the serial monitor. delay() parks the core on a SYSTIMER alarm rather than spinning, so an idle sketch costs the simulator almost nothing.

Stock Arduino libraries

A tutorial that includes Servo.h, Wire.h, SPI.h, EEPROM.h, LiquidCrystal_I2C.h, Adafruit_GFX.h with Adafruit_SSD1306.h, Adafruit_NeoPixel.h, ESP32Servo.h and DHT.h compiles here as it stands. Each is Mokxi's own header under the upstream name, written on the drivers for the parts in the bin, and none of it is the upstream library's code.

• Wire.begin() puts the I2C bus on GPIO 23 (SDA) and GPIO 22 (SCL); Wire.begin(sda, scl) moves it.
• EEPROM.h works, but this board's model has no EEPROM or writable flash, so the bytes live in 4 KB of RAM: they read back within a Run and are gone at a reset.

The code editor and compiling lists what each one covers and how it differs from the upstream library.

Which board is this?

The ESP32-C6-DevKitC-1. Not the C6-DevKitM-1, not a bare module on a carrier of your own, and not the C6 Mini variants. The GPIO numbers are the chip's and would be the same, but the header order would not.