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

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.
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:
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.
| Real ESP32-DevKitC V4 | This library in Proteus | |
|---|---|---|
| Processor | ESP32-D0WD-V3, two Xtensa LX6 cores, up to 240 MHz | Proteus's ATmega2560 model at 16 MHz, inside the board |
| Memory | 520 KB SRAM, 4 MB flash | 8 KB of RAM, 256 KB of flash |
| Wi-Fi | 802.11 b/g/n, 2.4 GHz | a virtual router, DHCP, TCP, UDP, mDNS, NTP, an internet host |
| Bluetooth | v4.2 and BLE | no |
| Pins | 38 (26 usable GPIOs, 6 flash pins), 3.3 V | the same 38 pins with their GPIO numbers |
| LEDs | red power LED only | the same red PWR LED |
| Programming | Arduino-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
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.
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:
The two buttons work with the mouse. We held each one for a picture:
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) andTEPESP32V1.LIBfrom 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
- Close Proteus and extract the whole zip file, for example to your Desktop.
- 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). - Copy
TEPNET.DLLfrom Proteus Model Files into the MODELS folder - it replaces the TEPNET.DLL of our ESP32 DevKit V1 package (the new one runs both boards). - Delete
TEPESP32DEVKITC.IDXandTEPESP32V1.IDXfrom the LIBRARY folder if they are there. - 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.
- 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.
- Copy the folder
Arduino Code\TEP Boards for Proteus\hardwareinto your sketchbook folder, normallyDocuments\Arduino, so thatDocuments\Arduino\hardware\tep\avr\boards.txtexists - replace an older copy. - Restart the IDE and select Tools > Board > TEP Boards for Proteus > ESP32-DevKitC V4 (TEP Proteus).
- 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:
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:
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.
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:
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:
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:
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:
Demo 2: ESP32 Wi-Fi Dimmer with a Touch Pad
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:
Tap 75 %: the phone sends GET /set?level=75, the sketch calls ledcWrite() and the page comes back with the new level:
The Pins page shows the PWM itself - the duty, the frequency and the voltage the LED gets:
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 %:
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:
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.
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:
Then we typed 100, BLINK and 60 in U1's monitor:
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 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:
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
| Pins | What 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, 27 | GPIO, PWM, touch, ADC2 - on a real ESP32 ADC2 fails while the Wi-Fi is on; use ADC1 |
| 32, 33, 34, 35, VP, VN | ADC1 (0 - 4095 for 0 - 3.3 V); 34, 35, VP, VN input only; 32, 33 touch |
| 25, 26 | DAC (dacWrite()), PWM |
| 5, 18, 19, 23 | SPI (SS, SCK, MISO, MOSI), GPIO, PWM (digital parts) |
| 21, 22 | Wire (SDA, SCL), GPIO, PWM (digital parts) |
| RX / TX | Serial - the built-in monitor |
| 16 / 17 | Serial2 (RX2 / TX2) |
| CLK, SD0 - SD3, CMD | the module's flash (GPIO6 - 11): not usable |
| EN | reset (the EN button) |
| 3V3, 5V, GND | 3.3 V out, 5 V, ground |
Properties of the Board
| Property | What it does |
|---|---|
| PROGRAM | the sketch's HEX from TEP Boards for Proteus |
| WIFISSID / WIFIPASS | the router in range (TEP-WiFi / 12345678); another name or password in the sketch fails as on the bench |
| MONITOR | YES: the built-in serial monitor on TX / RX |
| BAUD | the monitor's speed (115200, or AUTO) |
| AUTOOPEN | YES: the monitor opens at Run (the demos) |
| TIME | the 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_Remotedoes. - printf shows -1 or odd numbers:
intis 16 bits here - cast 32-bit values tointor 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;
intis 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