ESP32-DevKitC V4 Library for Proteus: the 38-pin board on Wi-Fi

ESP32-DevKitC V4 Library for Proteus: 38-Pin Wi-Fi Board

2.5K Views
40
700
60
25
60
PCBWay

Hello friends, I hope you all are doing great. Today, I am going to share the ESP32-DevKitC V4 Library for Proteus. This is the second board of our Wi-Fi series. The first was the ESP32 DevKit V1 Library for Proteus V2.0, the 30-pin DOIT board that runs your ESP32 sketch with Wi-Fi inside Proteus. Today it is the turn of Espressif's own development board, the 38-pin ESP32-DevKitC V4 - the board in Espressif's documentation, with every GPIO on its headers and the BOOT button on GPIO0.

Updates

ESP32-DevKitC V4 Library for Proteus

Latest version: V1.0 (October 2026, this tutorial)

Helping Tools

  • Laptop WiFi Monitor: a laptop on the Wi-Fi of your design: a browser, a TCP / UDP terminal and ping
  • Mobile WiFi Monitor: a smartphone that opens the pages of your ESP32 and sends it commands
  • Serial Monitor Advance: a serial terminal window for the UART of your board

Let us be clear from the first line: this is not a real ESP32 chip. Proteus 8 has no model of the ESP32's Xtensa processor, so our DevKitC V4 runs your sketch on a hidden ATmega2560 - Proteus's own AVR model - and our board model wraps it with the ESP32's pins, rules and Wi-Fi. You write a normal ESP32 Arduino sketch (GPIO numbers, analogRead() from 0 to 4095, ledcWrite(), attachInterrupt() on any pin, touchRead(), WiFi, WiFiUDP, WebServer, HTTPClient) and compile it with our free Arduino IDE add-on, TEP Boards for Proteus. The price is the AVR inside: 16 MHz, 8 KB of RAM, no FreeRTOS tasks and no Bluetooth - we list every limit below.

NOTICE: the DevKitC V4 shares its model with our DevKit V1, so the hard part - a board package for the Arduino IDE and a Wi-Fi network inside Proteus - was already there. For this board we drew Espressif's layout pin for pin, put GPIO0 on the header, and taught the model to drive an LED with PWM. Your feedback is the fuel that keeps us going, so please tell us what you think in the comments below or in the ESP32-DevKitC V4 board of our forum. And if our free libraries help you, you can buy us a coffee. So, let's get started with the ESP32-DevKitC V4 Library for Proteus:

ESP32-DevKitC V4 Library for Proteus: the 38-pin board on Wi-Fi
Figure: The ESP32-DevKitC V4 Library for Proteus: U1 on Wi-Fi - the red PWR LED, the EN and BOOT buttons and the PCB antenna of the ESP32-WROOM-32E in green.

What is the ESP32-DevKitC V4?

The ESP32-DevKitC V4 is the ESP32 development board made by Espressif itself. On a small black PCB it carries an ESP32-WROOM-32E module (its PCB antenna sticks out past the board's edge), a CP2102N USB-to-serial chip, an AMS1117 3.3 V regulator, the EN and BOOT buttons, a red power LED and two rows of 19 header pins. Unlike the DevKit V1, it brings out GPIO0 and the six flash pins, and it has no user LED - most projects wire their own.

The real board and the board in Proteus
Real ESP32-DevKitC V4This library in Proteus
ProcessorESP32-D0WD-V3, two Xtensa LX6 cores, up to 240 MHzProteus's ATmega2560 model at 16 MHz, inside the board
Memory520 KB SRAM, 4 MB flash8 KB of RAM, 256 KB of flash
Wi-Fi802.11 b/g/n, 2.4 GHza virtual router, DHCP, TCP, UDP, mDNS, NTP, an internet host
Bluetoothv4.2 and BLEno
Pins38 (26 usable GPIOs, 6 flash pins), 3.3 Vthe same 38 pins with their GPIO numbers
LEDsred power LED onlythe same red PWR LED
ProgrammingArduino-ESP32 core ("ESP32 Dev Module")TEP Boards for Proteus, the HEX file in the board's properties

How Can an ESP32 Sketch Run in Proteus?

The board you place is our part; inside it sits Proteus's own ATmega2560 model, which runs the HEX file of your sketch exactly as Proteus runs any AVR. The HEX comes from our Arduino IDE add-on TEP Boards for Proteus, now version 1.1.0 with the DevKitC V4 in its board list: it compiles your ESP32 sketch for that AVR with a core that speaks the ESP32's language and with the ESP32's WiFi, WebServer, HTTPClient, ESPmDNS and Preferences libraries.

Whatever the AVR cannot do itself - PWM and interrupts on any pin, the Wi-Fi radio, the touch pads - the core asks the board model (TEPNET.DLL) through a small mailbox in RAM, and the model answers in the same simulation step. It is the same model as our DevKit V1: one DLL knows both boards, so they share one Wi-Fi network - the third demo below uses exactly that.

Features of the ESP32-DevKitC V4 Library for Proteus

  • Espressif's 38-pin layout: 3V3, EN, VP, VN, 34 ... 5V on one side, GND, 23, 22, TX, RX ... CLK on the other, as printed on the real board; GPIO0 is a header pin and the BOOT button pulls it LOW.
  • Your ESP32 sketch runs: GPIO numbers, analogRead() 0 - 4095, ledc PWM on every output pin, attachInterrupt() on every pin, touchRead(), dacWrite(), Serial and Serial2, Wire and SPI.
  • PWM that an LED can see: a fast PWM into an LED gives it the PWM's average voltage, and the Pins page shows the duty and that voltage.
  • Wi-Fi in Proteus: a virtual router with DHCP, RSSI, a scan list, mDNS names, TCP and UDP, NTP time and an internet host that answers HTTP.
  • A phone in the panel: it opens your sketch's web page and taps its links; the ROUTER tab lists every board.
  • A real-looking board: the DevKitC V4 at its real proportions, a working PWR LED, the EN and BOOT buttons and a PCB antenna that changes colour with the Wi-Fi.
  • The panel and the built-in serial monitor of our ESP32 boards: Wi-Fi, Pins (26 GPIOs) and Test pages, a Board tab with every pin.
  • Three demo projects: the BOOT button and the cloud, a Wi-Fi LED dimmer with a touch pad, and the DevKitC V4 dimming the blue LED of an ESP32 DevKit V1 over UDP.
  • A compact package: about 1.69 MB, without the C++ source code of the models.

The ESP32-DevKitC V4 Part in Proteus

ESP32-DevKitC V4 in Proteus: the 38 pins, the ESP32-WROOM-32E module, EN and BOOT
Figure: The part as the library draws it: 5V CMD SD3 SD2 13 GND 12 14 27 26 25 33 32 35 34 VN VP EN 3V3 on top, CLK SD0 SD1 15 2 0 4 16 17 5 18 19 GND 21 RX TX 22 23 GND below; the micro-USB on the left, the module and its antenna on the right.

The part is the real board turned on its side, the USB end on the left, at its real proportions - smaller than the Arduino UNO. The top row of pins is the real board's left header J2, the bottom row its right header J3, with the same labels: 34 is GPIO34, VP GPIO36, TX GPIO1 and so on. CLK, SD0 - SD3 and CMD are the module's flash pins (GPIO6 - 11): they are on the header, but not usable - as on the real board. Search ESP32 in Pick Devices; the device is ESP32 DEVKITC V4 in TEPESP32DEVKITC.LIB.

ESP32-DevKitC V4 board placed in Proteus before the simulation
Figure: U1 placed on the sheet before Run: the EN and BOOT buttons, the CP2102N and the AMS1117, the PWR LED off, the PANEL pad and the gold PCB antenna.

Three parts of the board are made to click. The USB port opens the serial monitor, the PANEL pad (or the module) opens the board's panel, and EN and BOOT are buttons: EN holds the ESP32 in reset while you press it, BOOT pulls GPIO0 LOW - a part wired to pin 0 sees it too.

The PWR LED and the Antenna

The red PWR LED lights when the simulation runs. The gold PCB antenna shows the Wi-Fi: gold while the board is not on Wi-Fi, green once it joined, orange for a moment when it sends, cyan when it receives. We caught every state with the first demo's sketch, the simulation paused for each picture:

ESP32-DevKitC V4 in Proteus at Run: the PWR LED on, not on Wi-Fi yet
Figure: Just after Run: the PWR LED on, the antenna gold - the board is still scanning and joining.
ESP32-DevKitC V4 on Wi-Fi in Proteus: the PCB antenna green
Figure: On Wi-Fi: the antenna green - the board joined TEP-WiFi and got 192.168.1.101.
ESP32-DevKitC V4 in Proteus sending: the antenna orange
Figure: Sending: the antenna orange while the board sends its HTTP request to the internet host.
ESP32-DevKitC V4 in Proteus receiving: the antenna cyan
Figure: Receiving: the antenna cyan while the answer comes in.
ESP32-DevKitC V4 in Proteus out of range of the router: the antenna gold again
Figure: Out of range (OUT OF RANGE on the panel's phone): the board lost the Wi-Fi, the antenna is gold again.

The two buttons work with the mouse. We held each one for a picture:

ESP32-DevKitC V4 in Proteus with EN held: the board in reset
Figure: EN held: the button pressed, the board in reset - not on Wi-Fi, the antenna gold; it boots again on release.
ESP32-DevKitC V4 in Proteus with BOOT held: GPIO0 LOW
Figure: BOOT held: the button pressed and pin 0 LOW (the blue square under it) - the sketch counts the press with an interrupt.

Download ESP32-DevKitC V4 Library for Proteus

Click the button below to download ESP32-DevKitC-V4-Library-for-Proteus-v1.0.zip (about 1.69 MB, without the C++ source code of the models):

ESP32-DevKitC V4 Library for Proteus V1.0
  • README.txt: the device, installation, the three demos, the pins, the properties, troubleshooting and the limits.
  • Proteus Library Files: TEPESP32DEVKITC.LIB (the board) and TEPESP32V1.LIB from our ESP32 DevKit V1 library - used by the third demo.
  • Proteus Model Files: TEPNET.DLL - the ESP32 boards and the Wi-Fi network.
  • Proteus Simulation: the three demo projects, their four HEX files and a copy of the DLL.
  • Arduino Code: the four sketches and the TEP Boards for Proteus add-on 1.1.0 for the Arduino IDE.

No Proteus yet? Read How to Download and Install Proteus 7 and 8. New to libraries? Follow How to Install a New Library in Proteus.

How to Install ESP32-DevKitC V4 Library for Proteus

  1. Close Proteus and extract the whole zip file, for example to your Desktop.
  2. Copy the two files from Proteus Library Files into the LIBRARY folder of Proteus (usually C:\Program Files (x86)\Labcenter Electronics\Proteus 8 Professional\LIBRARY).
  3. Copy TEPNET.DLL from Proteus Model Files into the MODELS folder - it replaces the TEPNET.DLL of our ESP32 DevKit V1 package (the new one runs both boards).
  4. Delete TEPESP32DEVKITC.IDX and TEPESP32V1.IDX from the LIBRARY folder if they are there.
  5. Start Proteus, press P and search for ESP32.

Tip: one TEPNET.DLL serves the ESP32 DevKit V1, the DevKitC V4 and our ESP-01 Library for Proteus modules, so they all share one Wi-Fi network - keep only the newest copy in MODELS. The library is tested in Proteus 8.5; Proteus 7 is not supported.

Install TEP Boards for Proteus in the Arduino IDE

You only need this to compile your own sketches - the demos come with their HEX files.

  1. The Arduino AVR Boards platform must be installed: it comes with the Arduino IDE 1.8.x; in IDE 2.x install "Arduino AVR Boards" from the Boards Manager once. The add-on uses its compiler.
  2. Copy the folder Arduino Code\TEP Boards for Proteus\hardware into your sketchbook folder, normally Documents\Arduino, so that Documents\Arduino\hardware\tep\avr\boards.txt exists - replace an older copy.
  3. Restart the IDE and select Tools > Board > TEP Boards for Proteus > ESP32-DevKitC V4 (TEP Proteus).
  4. Write your sketch and use Sketch > Export Compiled Binary. Double-click the board in Proteus and set Program File to the exported HEX (see How to get the HEX file from Arduino).

The same sketch compiles for a real board with Espressif's "ESP32 Dev Module". One difference on purpose: the DevKitC V4 has no user LED, so our add-on does not define LED_BUILTIN for it - use the GPIO of your own LED.

Demo 1: The BOOT Button and the Cloud

Open ESP32-DevKitC-V4-Board.pdsprj: the board alone with ESP32C_Boot_Cloud.hex. The sketch scans for networks, joins TEP-WiFi, sets its clock from NTP and sends two values to an IoT channel - the number of BOOT presses and the chip temperature - every 20 seconds and after each BOOT press. BOOT is read with an interrupt on GPIO0:

void IRAM_ATTR onBoot() {
  bootPresses++;
}
  attachInterrupt(digitalPinToInterrupt(BOOT_PIN), onBoot, FALLING);

The scan prints every network with its signal and channel. Note the (int) casts: on the hidden AVR an int is 16 bits, so a 32-bit value printed with %d would come out wrong:

  int n = WiFi.scanNetworks();
  Serial.printf("Scan: %d network%s\n", n, n == 1 ? "" : "s");
  for (int i = 0; i < n; ++i) Serial.printf("  %s  %d dBm  channel %d\n", WiFi.SSID(i).c_str(), (int)WiFi.RSSI(i), (int)WiFi.channel(i));

The upload builds a ThingSpeak-style URL and calls HTTPClient, as on a real board:

  HTTPClient http;
  String url = "http://api.thingspeak.com/update?api_key=";
  url += apiKey;
  url += "&field1=";
  url += bootPresses;
  url += "&field2=";
  url += String(temperatureRead(), 1);
  http.begin(url);
  int code = http.GET();

Press Run. The serial monitor (115200 baud) and the board's panel open; move them aside. We let the board join and upload once, took the router away with the panel's OUT OF RANGE button and gave it back with GOOD, then held EN (the board restarted and scanned again) and pressed BOOT:

ESP32-DevKitC V4 serial monitor in Proteus: scan, NTP clock, uploads and the BOOT press
Figure: The built-in serial monitor: the clock from NTP, upload 1 stored (entry 1), the Wi-Fi lost and back; after EN the scan of 3 networks, entry 2, and BOOT pressed (1).
Clock 08:08:40  RSSI -45 dBm
Upload 1 (start): stored as entry 1
Clock 08:08:45  RSSI -47 dBm
Wi-Fi lost, joining again ...
Back on Wi-Fi: 192.168.1.101
Clock 08:08:55  RSSI -46 dBm
ESP32-DevKitC V4: BOOT button + cloud
Scan: 3 networks
  TEP-WiFi  -46 dBm  channel 6
  Neighbour_WiFi  -79 dBm  channel 1
  Guest_Network  -88 dBm  channel 11
Connecting to TEP-WiFi.....
IP address: 192.168.1.101
Clock 08:09:03  RSSI -47 dBm
Upload 1 (start): stored as entry 2
BOOT pressed (1)

The internet host answers every name you use - here api.thingspeak.com - and the panel's phone shows what arrived in its CLOUD tab:

ESP32-DevKitC V4 panel in Proteus: the CLOUD tab with the upload stored by the internet host
Figure: The panel, Wi-Fi page, CLOUD tab: "U1 /update stored"; on the right the BOARD (chip ESP32-D0WD-V3), WI-FI and TRAFFIC cards.

ThingSpeak takes one update every 15 seconds, so a BOOT press waits until 15 seconds have passed since the last upload. On a real board put your channel's Write API Key in apiKey.

The Board's Panel

The panel opens at Run, in the look of our TEP Serial Monitor Advance for Proteus. Its header shows the board, its address and three pages - Wi-Fi, Pins and Test - with Settings and Help on the right.

ESP32-DevKitC V4 panel in Proteus: the phone and the BOARD, WI-FI and TRAFFIC cards
Figure: The Wi-Fi page: the phone (BROWSER, ROUTER, CLOUD) and the WI-FI SIGNAL buttons; BOARD, WI-FI (TEP-WiFi, WPA2, channel 6, connected, RSSI) and TRAFFIC.

The phone is a second device on the same router: OPEN ESP32 PAGE makes it ask the sketch's web server for its page. WI-FI SIGNAL moves the router: GOOD, WEAK or OUT OF RANGE:

ESP32-DevKitC V4 panel in Proteus: the router out of range
Figure: OUT OF RANGE: the phone's card says NOT ON WI-FI and the WI-FI card shows the connection lost.

The Pins page shows all 26 GPIOs live, in six columns - driven HIGH or LOW, PWM with its duty, an interrupt and its mode, input with a pull-up or pull-down, analog with its voltage - and a TOUCH button on every touch pin. In the first demo, IO0 shows the sketch's interrupt:

ESP32-DevKitC V4 Pins page in Proteus: 26 GPIOs, IO0 with its FALLING interrupt
Figure: The Pins page: IO0 "interrupt FALLING" (the BOOT button), TX and RX the serial port, the other GPIOs inputs; TOUCH on the touch pins.

The serial monitor is built into the board - no Virtual Terminal to wire. Its Board tab shows the PWR LED, an EN (RESET) button, the BOOT button, every pin, the analog inputs, the supply pins and the speed of the simulation:

ESP32-DevKitC V4 serial monitor Board tab in Proteus: PWR, EN, BOOT, pins and supplies
Figure: The Board tab: PWR on, EN (RESET), BOOT (GPIO0) released; the 26 digital pins, the 16 analog pins (open: nothing wired), 3V3 3.30 V, 5V 5.00 V.

Settings holds the theme, the text size, "open the panel at Run" and the window size; Help has the links to this article, the forum, updates and Copy diagnostics for a bug report:

ESP32-DevKitC V4 panel settings in Proteus: theme, text size, open at Run, window size
Figure: Settings: TEP Dark or Light, the text size, open the panel at Run, the window size.
ESP32-DevKitC V4 panel help in Proteus: bug report, feature request, article, forum
Figure: Help: report a bug, suggest a feature, the article, the user guide, updates, donate, the website, the forum; Copy diagnostics.

Demo 2: ESP32 Wi-Fi Dimmer with a Touch Pad

ESP32-DevKitC V4 Wi-Fi dimmer Proteus simulation: an LED with 220 ohm on GPIO15
Figure: The dimmer demo running: the green LED D1 with R1 (220 ohm) on GPIO15 - lit at 100 %, set from the phone.

ESP32-DevKitC-V4-WiFi-Dimmer.pdsprj has one green LED with a 220 ohm resistor on GPIO15. The sketch, ESP32C_WiFi_Dimmer.ino, dims it with the ESP32's LEDC PWM at 5 kHz, serves a page with five brightness links, switches the LED with the touch pad T0 (GPIO4) and turns it off with BOOT. The PWM is the Arduino-ESP32 3.x API:

  ledcAttach(LED_PIN, 5000, 8);      // 5 kHz, 8 bits (Arduino-ESP32 3.x; 2.x: ledcSetup + ledcAttachPin)
void setLevel(int percent, const char *why) {
  level = constrain(percent, 0, 100);
  if (level > 0) lastOn = level;
  ledcWrite(LED_PIN, level * 255 / 100);
  Serial.printf("LED %d %% (%s)\n", level, why);
}

The touch pad is read every 100 ms; a value below 30 means a finger on the pad:

    bool touched = touchRead(TOUCH_PIN) < TOUCH_LIMIT;
    if (touched && !touchedWas) setLevel(level ? 0 : lastOn, "touch");
    touchedWas = touched;

Press Run, then OPEN ESP32 PAGE on the panel. The phone connects to 192.168.1.101 and shows the page:

ESP32-DevKitC V4 dimmer page on the phone of the Proteus panel
Figure: The phone with the sketch's page: LED on GPIO15: 0 %, the links OFF, 25 %, 50 %, 75 % and 100 %, the touch pad reading and the chip temperature.

Tap 75 %: the phone sends GET /set?level=75, the sketch calls ledcWrite() and the page comes back with the new level:

ESP32-DevKitC V4 dimmer in Proteus: 75 % tapped on the phone
Figure: After 75 %: "LED on GPIO15: 75 %", HTTP 200 - 440 bytes; TRAFFIC: the phone's GET /set?level=75 and the web server's answer 200.

The Pins page shows the PWM itself - the duty, the frequency and the voltage the LED gets:

ESP32-DevKitC V4 Pins page in Proteus: GPIO15 PWM 75 % at 5.0 kHz, 2.43 V
Figure: The Pins page at 75 %: IO15 at PWM 75 % and 5.0 kHz with 2.43 V, IO0 with its interrupt, TOUCH on IO4 and the other touch pins.

Now press TOUCH on IO4 - a finger on T0. touchRead() drops, the sketch switches the LED off, and the next touch brings it back to 75 %:

ESP32-DevKitC V4 Pins page in Proteus: the touch pad T0 touched, GPIO15 at 0 %
Figure: IO4 TOUCHED: the sketch switched the LED off - IO15 at PWM 0 % and 0.00 V.
ESP32-DevKitC V4 dimmer serial monitor in Proteus: the levels from the phone and the touch pad
Figure: The serial monitor: joined, mDNS dimmer.local, the server started, 75 % from the phone, 0 % and 75 % from the touch pad, the test's three pages, then 100 %.
LED 0 % (start)
ESP32-DevKitC V4 Wi-Fi dimmer
Connecting to TEP-WiFi.....
IP address: 192.168.1.101
mDNS: http://dimmer.local
HTTP server started: /  /set?level=0..100
GET / from 192.168.1.201
LED 75 % (phone)
LED 0 % (touch)
LED 75 % (touch)
GET / from 192.168.1.201
GET / from 192.168.1.201
GET / from 192.168.1.201
LED 100 % (phone)

How Proteus Shows a PWM LED

A real LED blinks 5000 times a second at 75 % and your eye sees it dimmer. Proteus cannot follow a 5 kHz PWM on an analog part, so our model gives the LED's net the PWM's average voltage - 75 % of 3.3 V, 2.43 V with the LED - and Proteus draws an LED only on or off: our green LED lights near full duty, as in the circuit picture at 100 %. This works on the 16 GPIOs that sit on the hidden AVR's analog pins (0, 2, 4, 12 - 15, 25 - 27, 32 - 36, 39); on the UART, I2C and SPI pins the PWM drives digital parts only - a servo, a logic analyser. The Pins page always shows the duty.

The Web Request Test

The Test page measures the running model. The web request test lets the phone open the page 3, 5 or 10 times and times the connection, the first byte and the full page:

ESP32-DevKitC V4 Test page in Proteus: the web request test
Figure: The web request test: 3 of 3 pages answered - 8.0 ms to connect, about 41 ms to the first byte, 56.2 ms for the full page of 440 bytes, HTTP 200.

The Wi-Fi re-join test below it takes the router away for 3 seconds and measures how long the board needs to join again.

Demo 3: DevKitC V4 and DevKit V1 Talking over UDP

A Wi-Fi library is more fun with a second board. In ESP32-DevKitC-and-DevKit-V1-UDP.pdsprj the DevKitC V4 (U1) is a remote control with a pot, and the ESP32 DevKit V1 (U2) of our ESP32 DevKit V1 Library for Proteus V2.0 - the previous library of this series - is the receiver: the pot sets the brightness of its blue on-board LED over Wi-Fi.

ESP32-DevKitC V4 and ESP32 DevKit V1 Proteus simulation: a pot on the DevKitC dims the DevKit V1 over UDP
Figure: The two boards: U1, the DevKitC V4, with the 10k pot RV1 on GPIO34 between its 3V3 and ground; U2, the ESP32 DevKit V1, alone - its blue D2 LED shows the level.

This time there is no web server: the boards send short UDP datagrams to port 4210. U1 reads the pot every 200 ms and sends DIM 0..100 when it moves; a level typed in U1's monitor is sent too:

void send(const String &msg) {
  if (msg.startsWith("DIM ")) { dimLevel = msg.substring(4).toInt(); answered = false; }
  udp.beginPacket(receiverIp, PORT);
  udp.print(msg);
  udp.endPacket();
  Serial.print("Sent: ");
  Serial.println(msg);
}

UDP does not repeat a lost datagram - and the first one is often lost, because U2 is still joining when U1 is ready. So the remote sends a DIM again with its PING every 5 seconds until it got the answer:

  if (millis() - lastPing >= 5000) {
    lastPing = millis();
    if (!answered && dimLevel >= 0) send("DIM " + String(dimLevel));     // no OK yet: again
    send("PING");
  }

U2 runs ESP32_UDP_Receiver.ino: it listens on the port, sets its blue LED's PWM and answers the sender:

  if (msg.startsWith("DIM ")) {
    setBlue(msg.substring(4).toInt());
    answer("OK DIM " + String(level));
  } else if (msg == "BLINK") {
    int was = level;
    for (int i = 0; i < 3; ++i) { setBlue(100); delay(150); setBlue(0); delay(150); }
    setBlue(was);
    answer("OK BLINK");
  } else if (msg == "PING") {
    answer("PONG up " + String(millis() / 1000) + " s, " + String(WiFi.RSSI()) + " dBm");
  } else {
    answer("? " + msg);

Press Run. U1 joins as 192.168.1.101, U2 as 192.168.1.102 - the address follows the part's number. The pot starts at 30 %, so U2's blue LED glows dim:

ESP32 DevKit V1 in Proteus: the blue D2 LED at 30 % from the DevKitC V4
Figure: U2 after "DIM 30": the blue D2 LED glows dim (our model draws the blue LED at the PWM's duty).

Then we typed 100, BLINK and 60 in U1's monitor:

ESP32 DevKit V1 in Proteus: the blue D2 LED at 100 %
Figure: U2 after "DIM 100": the blue LED fully lit.
ESP32 DevKit V1 in Proteus: the blue D2 LED at 60 %
Figure: U2 after "DIM 60": the blue LED between the two.
ESP32-DevKitC V4 serial monitor in Proteus: DIM, BLINK and PING sent by UDP, the answers of the DevKit V1
Figure: U1's monitor: PING / PONG every 5 s; 100, BLINK and 60 typed (TX), sent and answered at once by 192.168.1.102.
From 192.168.1.102: PONG up 5 s, -46 dBm
Sent: PING
From 192.168.1.102: PONG up 10 s, -47 dBm
Sent: PING
From 192.168.1.102: PONG up 15 s, -45 dBm
100
Sent: DIM 100
From 192.168.1.102: OK DIM 100
BLINK
Sent: BLINK
From 192.168.1.102: OK BLINK
60
Sent: DIM 60
From 192.168.1.102: OK DIM 60
Sent: PING
From 192.168.1.102: PONG up 20 s, -46 dBm

U2's monitor shows the other side - every datagram with the address it came from:

ESP32 DevKit V1 serial monitor in Proteus: the UDP datagrams from the DevKitC V4
Figure: U2's monitor: joined as 192.168.1.102, listening on port 4210; DIM 30, the PINGs, DIM 100, BLINK and DIM 60 from 192.168.1.101.
ESP32 DevKit V1 UDP receiver
Connecting to TEP-WiFi......
IP address: 192.168.1.102
Listening on UDP port 4210
From 192.168.1.101: DIM 30
From 192.168.1.101: PING
From 192.168.1.101: PING
From 192.168.1.101: PING
From 192.168.1.101: DIM 100
From 192.168.1.101: BLINK
From 192.168.1.101: DIM 60
From 192.168.1.101: PING

U2's own panel shows the PWM on its blue LED, and U1's ROUTER tab lists both boards and the two phones of the panels:

ESP32 DevKit V1 Pins page in Proteus: D2 PWM 30 percent at 5.0 kHz
Figure: U2's Pins page: D2 (the blue LED) at PWM 30 % and 5.0 kHz - set by the DevKitC V4 over UDP.
ESP32-DevKitC V4 panel ROUTER tab in Proteus: both ESP32 boards and the phones on TEP-WiFi
Figure: The ROUTER tab: 192.168.1.101 ESP32 U1, 192.168.1.201 Phone U1, 192.168.1.102 ESP32 U2, 192.168.1.202 Phone U2.

One board measures, the other acts, and neither needs a server: the same pattern links a remote and a lamp, or a sensor node and a display, in a real home-automation project.

Pins of the ESP32-DevKitC V4

The pins (the label on the board; attachInterrupt works on every pin)
PinsWhat they can do in the simulation
0 (GPIO0)the BOOT button (LOW while pressed, 10k pull-up), GPIO, touch, ADC2
2, 4, 15, 13, 12, 14, 27GPIO, PWM, touch, ADC2 - on a real ESP32 ADC2 fails while the Wi-Fi is on; use ADC1
32, 33, 34, 35, VP, VNADC1 (0 - 4095 for 0 - 3.3 V); 34, 35, VP, VN input only; 32, 33 touch
25, 26DAC (dacWrite()), PWM
5, 18, 19, 23SPI (SS, SCK, MISO, MOSI), GPIO, PWM (digital parts)
21, 22Wire (SDA, SCL), GPIO, PWM (digital parts)
RX / TXSerial - the built-in monitor
16 / 17Serial2 (RX2 / TX2)
CLK, SD0 - SD3, CMDthe module's flash (GPIO6 - 11): not usable
ENreset (the EN button)
3V3, 5V, GND3.3 V out, 5 V, ground

Properties of the Board

Double-click the board to change them; every run starts again from the properties
PropertyWhat it does
PROGRAMthe sketch's HEX from TEP Boards for Proteus
WIFISSID / WIFIPASSthe router in range (TEP-WiFi / 12345678); another name or password in the sketch fails as on the bench
MONITORYES: the built-in serial monitor on TX / RX
BAUDthe monitor's speed (115200, or AUTO)
AUTOOPENYES: the monitor opens at Run (the demos)
TIMEthe clock NTP gives: PC (the PC's clock) or a fixed start time in UTC

Troubleshooting

  • Nothing happens at Run: the HEX was not built with TEP Boards for Proteus - a plain Arduino Mega HEX or a real ESP32 binary does not run here. Select ESP32-DevKitC V4 (TEP Proteus) and export the binary again.
  • "LED_BUILTIN was not declared": the DevKitC V4 has no user LED - use your own LED's GPIO.
  • Stuck at "Connecting...": the SSID or password in the sketch differ from the WIFISSID / WIFIPASS properties, or the phone's WI-FI SIGNAL is OUT OF RANGE.
  • A UDP message lost at the start: the other board was not on Wi-Fi yet - let the sketch repeat it, as ESP32C_UDP_Remote does.
  • printf shows -1 or odd numbers: int is 16 bits here - cast 32-bit values to int or print them with %ld.
  • A PWM LED stays dark at a low duty: Proteus draws an LED on or off; the Pins page shows the duty and the voltage.
  • Two boards with the same address: they have the same part number - renumber one (U1, U2 ...).
  • No monitor or no panel: click the USB port or the PANEL pad; or turn "Open the panel at Run" back on in Settings.

Things to Know Before Moving to a Real ESP32

  • The board: select Espressif's "ESP32 Dev Module" - your sketch compiles unchanged (define your LED pin).
  • Memory: the real ESP32 has 520 KB of RAM - a sketch that fits in 8 KB here has room to grow there.
  • ADC2 pins (0, 2, 4, 12 - 15, 25 - 27) cannot read analog values while the Wi-Fi is on; the UDP demo reads its pot on GPIO34, an ADC1 pin.
  • The flash pins GPIO6 - 11 are connected to the module's flash - never use them.
  • Strapping pins: GPIO0, GPIO2, GPIO5, GPIO12 and GPIO15 decide the boot mode at reset - an LED on GPIO15 is fine, a pull-up on GPIO12 is not.
  • 3.3 V logic: the ESP32's pins are not 5 V tolerant - level shift signals from 5 V boards.

Limitations of the Simulation

  • It is not a real ESP32 chip: the sketch runs on Proteus's ATmega2560 model at 16 MHz with 8 KB of RAM and 256 KB of flash; int is 16 bits.
  • Not modelled: FreeRTOS tasks (xTaskCreate()), Bluetooth and BLE, ESP-IDF calls, the soft access point, real TLS, OTA updates, SPIFFS / LittleFS, the ESP32's ADC details, the radio itself - the join and network times are realistic values, not a radio simulation.
  • A fast PWM into an analog part is shown as its average voltage; the UART, I2C and SPI pins drive PWM into digital parts only.
  • The antenna colours, the PANEL pad, the panel, its phone, the router and the internet host are TEP additions.
  • TEP Boards for Proteus is based on the Arduino AVR core 1.8.6 (LGPL 2.1, the licence text is included); our libraries are MIT. The API follows Espressif's Arduino-ESP32 core - names only. This library is not made or endorsed by Espressif, Arduino or Labcenter.
  • Tested in Proteus 8.5 in October 2026 (the three demos as shipped, the board demo 33.1 s of simulation in 71 s with the panel and the monitor open, about 0.5 x real time; the two boards of the UDP demo 24.6 s in 76 s, about 0.3 x). Proteus 7 is not supported.

So, that was all about the ESP32-DevKitC V4 Library for Proteus. I hope you enjoy running your ESP32 sketches on Espressif's own board in Proteus, and linking it with our DevKit V1 over Wi-Fi. If you use the ESP32-DevKitC V4 Library for Proteus in a project, please share it in the comments or in our forum, and if you have any questions, ask in the comments and I will help you out. Till the next tutorial, take care and have fun!


Comments

0

Join the conversation