The last two entries in PICSimLab’s board list are its most unusual. The uCboard is a generic board for three non-PIC, non-AVR architectures — C51, Z80 and STM8 — driven by the uCsim backend. The Remote TCP board is not a physical board at all: it is a virtual board through which an external simulator acts as the microcontroller, and it is the one board the official documentation explicitly labels experimental.

Overview

The uCboard gives PICSimLab a home for classic 8051 (C51) code, Z80 code and STM8 code, using the uCsim backend. The Remote TCP board is controlled through a single TCP connection and, per the official documentation, “currently only supports the Risc-V simulator Ripes”, with the remote backend providing experimental support for letting other simulators act as the microcontroller that drives PICSimLab’s board and spare parts.

Supported MCUs

Backend & debugging

The uCboard’s debugging is a remote console over telnet, provided by uCsim — there is no MPLAB X or GDB path for this board. Its project templates reflect its toolchains: the wizard and template list cover Arduino/SDCC projects for C51 and STM8S103 (SDCC templates were added in v0.9.3), and PlatformIO in VSCode is the stated prerequisite IDE for STM8/C51 boards.

Do not confuse the Remote TCP board with PICSimLab’s remote control interface (rcontrol): rcontrol is a text-command socket (default port 5000) for controlling PICSimLab itself, while the Remote TCP board is the channel through which an external simulator like Ripes plays the role of the microcontroller. They are separate features with separate purposes.

What you can do

• Run and telnet-debug C51, Z80 and STM8S103 programs on the uCboard, with spare parts attached as on any other board.
• Connect Ripes to the Remote TCP board and let a RISC-V simulation drive PICSimLab’s virtual circuit — the only RISC-V board path in PICSimLab (the ESP32-C3 board is a separate, QEMU-based riscv32 chip).
• Use both boards as teaching tools for architectures that the PIC/AVR/STM32 boards do not cover, inside the same spare-parts environment.

Real limits

• Remote TCP is experimental — the documentation says so outright. It currently supports only Ripes. It is not general RISC-V board support, not a range of RISC-V boards, and it should not be presented as a finished feature.
• uCboard scope is the three named architectures. The uCsim simulator upstream supports more core families, but PICSimLab’s board-level documentation names only C51, Z80 and STM8S103 for the uCboard — other uCsim families are not promised as working board configurations.
• Debugging on the uCboard is the telnet console only; if you need breakpoints in an IDE, the PIC, AVR, STM32 and ESP32 boards offer better tooling.
• New to PICSimLab itself? The general workflow on any board is: install from the download page, select board and chip, build outside PICSimLab (it has no code editor), load the firmware, run.

Both boards are built into PICSimLab — install it from the download page and select uCboard or Remote TCP from the board list.

PICSimLab has two ESP32 boards: the ESP32-DevKitC and the ESP32-C3-DevKitC-02, both running on the qemu-esp32 backend. They are genuinely useful for running ESP32 firmware without hardware — but wireless support is the most exaggerated topic in PICSimLab coverage, so this page states the official position precisely, including what is not supported.

Overview

Both boards are described officially as simple boards “only with reset, serial and crystal circuits” wrapped around the chip — the ESP32 on the DevKitC and the ESP32-C3 (a riscv32 part) on the C3-DevKitC-02. The qemu-esp32 backend is PICSimLab’s adapted QEMU build, itself based on a QEMU emulation of a TTGO TDisplay ESP32 board. You can program the simulated boards the way you program real ones: the official documentation explains flashing via the serial port using the Arduino IDE or the IDF’s esptool.py.

Supported MCUs

Backend & debugging

Debugging is remote esp32-gdb: enable debugging in the configuration window, launch the ESP32 GDB (xtensa-esp32-elf-gdb) with your .elf and connect to localhost:1234; PlatformIO in VSCode can be configured for graphical debugging with picsimlab_tool uploads. The Code Project Wizard generates VSCode + PlatformIO projects for ESP32 boards, with Arduino-framework and IDF templates for both boards.

What you can do

• Compile ESP32 and ESP32-C3 firmware (Arduino or ESP-IDF), flash it to the simulated board over the serial workflow and watch it run and log.
• Debug with esp32-gdb breakpoints instead of print statements.
• On the ESP32-C3, the project CHANGELOG records concrete wireless increments: v0.9.1 “Add support to ESP32C3 WIFI and ESP-NOW protocol”, plus an option for ethernet support on the C3 board.
• On the original ESP32, the CHANGELOG records incremental support items such as https over WiFi, an option to enable ethernet support on the DevKitC board, and individual peripheral additions (I2C, SPI, ADC, LEDC/PWM, RMT TX and more, added release by release).

Real limits

• WiFi is incremental, not “full WiFi simulation”. The official documentation’s qemu-ESP32 page contains no WiFi chapter at all; support exists as CHANGELOG-level additions, strongest for the ESP32-C3 (WiFi + ESP-NOW). Anything claiming the DevKitC simulates complete WiFi projects “just like real hardware” is an exaggeration.
• No Bluetooth: neither the official documentation nor the CHANGELOG contains any ESP32 Bluetooth/BLE simulation entry. Treat Bluetooth as not supported.
• Flash modes: QEMU-ESP32 does not support the QIO and QOUT flash modes — use only DIO or DOUT, or flashing will fail.
• Only two chips: there is no ESP32-S2, S3, C2, C6 or H2 board anywhere in PICSimLab. The C3 is also the only RISC-V chip with a real board here — see the Remote TCP page for the separate, experimental Ripes path.
• The boards are simple reset/serial/crystal carriers; spare parts provide the rest of the circuit. (The separate ETH W5500 spare part is a wired-Ethernet part for other boards — it is not ESP32 WiFi.)

Install PICSimLab from the download page, pick ESP32-DevKitC or ESP32-C3-DevKitC-02, set your flash mode to DIO/DOUT, and keep the wireless expectations above in mind.

Let us start with the fact that matters most, because many pages get it wrong: PICSimLab supports exactly two STM32 microcontrollers — the STM32F103C8T6 on the Blue Pill board and the STM32F103RBT6 on the STM32 H103 board. There are no other STM32 boards, no other STM32 families, and no Nucleo or Discovery boards in PICSimLab. This page documents those two boards exactly as they are.

Overview

Both boards run on the qemu-stm32 backend — a PICSimLab-adapted QEMU build with an STM32 implementation. The boards themselves are deliberately minimal. The official description of the Blue Pill is a “generic board only with reset, serial and crystal circuits”, and the STM32 H103 is a “generic board only with reset, one push button, serial and crystal circuits”. They are simple carriers for the chip, not full replicas of feature-rich development boards.

Supported MCUs

Backend & debugging

Debugging is remote arm-gdb: enable debugging in PICSimLab’s configuration window, then connect arm-none-eabi-gdb (or gdb-multiarch) to the simulator with target extended-remote localhost:1234. The official documentation also shows how to configure STM32CubeIDE to connect for debugging, and a PlatformIO/VSCode setup using picsimlab_tool to upload firmware with a custom debug tool. For STM32 boards the Code Project Wizard generates VSCode + PlatformIO projects; the official templates cover both boards with the Arduino framework and with CMSIS.

What you can do

• Build, run and breakpoint-debug F103 firmware (Arduino-framework or CMSIS templates) without a physical Blue Pill or ST-Link.
• Exercise serial-based designs, using the virtual serial port setup on the desktop version.
• Attach spare parts to the pins and watch signals on the two-channel oscilloscope while the QEMU core runs your binary.

Real limits

• Only two F103 chips — full stop. There is no STM32F4, F7, H7 or L-series support and no other STM32 board in the official documentation or template list. Claims of “STM32 family simulation” go beyond what PICSimLab offers.
• The boards are simple/generic: reset, serial and crystal circuits (plus one push button on the H103). They are not pin- and peripheral-complete replicas of the retail boards.
• The official qemu-stm32 documentation is brief and publishes no peripheral coverage list or performance promises — peripheral behaviour is whatever the adapted QEMU implements, so verify the specific peripherals your project needs.
• PICSimLab has no source editor; code is written in VSCode + PlatformIO or STM32CubeIDE, as with real hardware.

Install PICSimLab from the download page, choose Blue Pill or STM32 H103, and keep expectations set to “two F103 chips, honestly simulated” — within that scope, it is genuinely useful.

PICSimLab’s AVR line-up has a big board and a tiny one. The Arduino Mega runs the ATmega2560 — the largest AVR in the simulator — while the Franzininho DIY runs the little ATtiny85 and brings a piece of Brazilian open-source hardware into the board list. Both run on the simavr backend.

Overview

The Mega is the board to pick when an Uno-class chip is too small for the project you are practising: more flash, more pins, the same Arduino workflow. The Franzininho DIY is the opposite end of the scale — a small ATtiny85 board from the Franzininho open-source hardware project (Brazil), made for simple, cheap, solder-it-yourself electronics education. PICSimLab models both so the projects can be rehearsed in simulation first.

Supported MCUs

Backend & debugging

Both boards use simavr, so both get its two debugging routes: MPLAB X Integrated Debug through the PICSimLab plugin, and remote avr-gdb debugging — enable debug in the configuration window, launch avr-gdb with your .elf and connect to localhost:1234. For AVR boards the Code Project Wizard generates VSCode + PlatformIO projects (Arduino framework templates exist for both the Mega and the Franzininho), and Arduino IDE programming is covered in the official documentation as well.

What you can do

• Practise Mega-sized Arduino projects — multi-serial, many-pin designs — before committing to hardware, with spare parts wired to the pins your design uses.
• Prototype Franzininho DIY lessons and tiny ATtiny85 projects (indicators, simple controls, classroom exercises) entirely in simulation.
• Step through code with avr-gdb or MPLAB X on either board, and inspect signals with the oscilloscope module.
• Use the virtual serial ports when a Mega sketch exchanges data with a program on your PC.

Real limits

• The Mega caveat is real: simavr’s upstream documentation describes its AVR core as stable for parts with up to 128 KB flash and only preliminary for bigger parts. The ATmega2560 is a 256 KB part, so it sits in that preliminary zone — expect the Uno/Nano-class support to be the most battle-tested, and verify Mega-specific behaviour carefully.
• The ATtiny85 is a small chip by design: Franzininho projects are intentionally simple, and the board does not turn it into something bigger.
• These are the only two boards of their kind in PICSimLab — there is no ATmega32U4 (Leonardo) or other Arduino variant in the official board list; the remaining AVR boards are the Uno and Nano and the dual-backend Breadboard.
• As everywhere in PICSimLab, there is no built-in source editor; editing happens in PlatformIO/VSCode, the Arduino IDE or MPLAB X.

Both boards are included in PICSimLab itself — grab it from the download page and select Mega or Franzininho DIY from the board list.

The Arduino Uno and Arduino Nano are the two ATmega328P boards in PICSimLab. Both run on the simavr backend, both can be programmed the Arduino way, and both offer something the PIC boards do not: two debugging paths instead of one. If you want to practise Arduino sketches and bare-metal AVR code without hardware, this is where to start.

Overview

PICSimLab’s Uno and Nano are simulations of the classic 328P-based Arduino boards. Under the hood sits simavr, the AVR simulator backend. PICSimLab itself has no code editor — for these boards the Code Project Wizard generates VSCode + PlatformIO projects, and the official documentation also covers programming through the Arduino IDE, with simavr-side example sources built using the Arduino IDE and avr-gcc.

Supported MCUs

One chip, two form factors: code written for the 328P runs on both boards, exactly as on real hardware.

Backend & debugging

simavr boards have the richest debugging story in PICSimLab: MPLAB X Integrated Debug (via the PICSimLab plugin — the plugin works for PICs and AVRs) plus remote avr-gdb debugging. For the GDB path, enable debugging in the configuration window, start avr-gdb with your .elf file and connect with target extended-remote localhost:1234. PlatformIO users can upload firmware with the picsimlab_tool command-line tool and a custom debug configuration.

What you can do

• Build and run Arduino-framework projects for the 328P generated by the project wizard (VSCode + PlatformIO), or program the board from the Arduino IDE.
• Debug with breakpoints in MPLAB X or avr-gdb instead of relying on Serial prints alone.
• Combine the boards with spare parts and the oscilloscope for complete bench-style experiments, and use the virtual serial port setup when a sketch talks to a PC application.
• Carry the same 328P code to the generic Breadboard, which also runs simavr chips.

Real limits

• simavr’s own scope note: upstream describes its AVR core as stable for parts with up to 128 KB of flash, with preliminary support for bigger parts. The ATmega328P (32 KB) sits comfortably inside the stable range — but do not generalise that to every AVR chip.
• Only the ATmega328P is offered on these two boards. Other Arduino boards are not in PICSimLab’s list, apart from the Arduino Mega.
• Desktop serial simulation needs a virtual null-modem pair (com0com / tty0tty), and the online version of PICSimLab has no debugging and no real serial support — use the desktop build for these boards’ debugging features.
• A simulation is not the physical board: electrical behaviour and precise timing still need real hardware for final validation.

Install PICSimLab from the download page, select Arduino Uno or Nano, and load your first 328P sketch.

This page pairs two of PICSimLab’s least typical PIC boards. The PQDB is an open-source hardware board adapted to a single PIC chip, while the gpboard is the only board in PICSimLab that runs on the gpsim backend instead of picsim — a difference that has one important consequence for debugging, stated plainly below.

Overview

The PQDB is an open hardware board that was originally designed for Arduino/freedom-style boards; in PICSimLab it is adapted to run the PIC18F4520 on the picsim backend. The gpboard is a generic board — only reset, serial and crystal circuits — backed by gpsim, the other PIC simulator PICSimLab can use.

Supported MCUs

Backend & debugging

The PQDB behaves like any other picsim board: MPLAB X Integrated Debug through the PICSimLab plugin (see the plugin guide), and MPLAB X + XC8 projects from the Code Project Wizard.

The gpboard is different, and this is the fact to remember: the official documentation lists the debugging support for the gpsim backend as “none yet”. You can run code on the gpboard, but there is currently no MPLAB X or GDB debugging path for it in PICSimLab. Any source that claims you can debug a gpboard project the way you debug a picsim board is wrong.

What you can do

• Run PIC18F4520 projects on the PQDB — the chip is also on the McLab2 and PICGenios lists, so general 18F workflow material such as the PIC18F4550 first project (project generation, XC8 build, hex loading) carries over.
• Use the gpboard when you specifically want gpsim’s simulation of a generic PIC circuit built from spare parts, accepting run-only operation.
• On either board, add displays, inputs and instruments from Modules → Spare parts and the oscilloscope module.

Real limits

• gpboard debugging: none yet. If stepping through code matters, choose a picsim board instead — that is the honest recommendation.
• The PQDB adaptation is a single-chip board in PICSimLab (PIC18F4520). Its open-hardware origins do not mean other chips from the original board family are selectable here.
• The gpboard is generic by design: reset, serial and crystal only — everything else is spare parts you add.
• picsim’s documented peripheral coverage (ADC, interrupts, WDT, TMR0–TMR2, USART, CCP, EEPROM, I/O ports) bounds what the PQDB can model.

Both boards ship with PICSimLab itself — install it from the download page and select PQDB or gpboard from the board list.

Three of PICSimLab’s PIC boards share the same one-line official description: “simple PIC microcontroller development board”. They are the Curiosity, the Curiosity HPC and the Xpress — lightweight boards on the picsim backend, aimed at straightforward PIC projects rather than at imitating one specific feature-rich commercial product in detail.

Overview

All three boards run on the picsim backend and follow the standard PIC workflow in PICSimLab: select the board and a PIC microcontroller, generate an MPLAB X project with the Code Project Wizard, build with XC8, load the hex file and run. They were once in PICSimLab’s experimental set and have since been moved to the stable board list — the current stable documentation lists them as normal boards, so do not treat them as experimental today.

Supported MCUs

Unlike McLab2 or PICGenios, the official board pages for these three do not pin the board to a fixed microcontroller list — the PIC chip is chosen when you set the board up in PICSimLab, within the PIC16F/PIC18F families that the picsim backend and the project wizard’s templates cover. If a fixed, documented chip list matters for your course or project, McLab2 and PICGenios publish theirs explicitly.

Backend & debugging

Debugging is MPLAB X Integrated Debug, the standard for every picsim board: with the com-picsim-picsimlab.nbm plugin installed, MPLAB X talks to PICSimLab over a TCP socket (port 1234 by default) to debug and program the simulation. Setup details are in our MPLAB X plugin guide.

What you can do

• Bring simple PIC16F/PIC18F exercises onto a clean, uncluttered board and add only the spare parts your lesson needs.
• Reuse the standard workflow and code patterns from the PIC16F877A blink tutorial and the PIC18F4550 first project — project generation, XC8 build and hex loading are identical on every picsim board.
• Extend the board with displays, buttons and sensors from Modules → Spare parts as the project grows.

Real limits

• “Simple” is the operative word: the official documentation describes these as simple boards and does not document a fixed chip list or a rich onboard peripheral set for them. Any page that promises a specific Curiosity chip/peripheral combination in PICSimLab is going beyond the official documentation.
• All picsim caveats apply: the backend documents a specific peripheral set (ADC, interrupts, WDT, TMR0–TMR2, USART, CCP1–CCP3, EEPROM, I/O ports), not every module of every PIC.
• PICSimLab provides no source editing; MPLAB X + XC8 are required, as with the real boards.

Get PICSimLab from the download page and choose Curiosity, Curiosity HPC or Xpress when a simple PIC board is all your project needs.

Most PICSimLab boards imitate a specific commercial product. Two do not: the Breadboard and the X board are generic boards — minimal carriers with only the essentials — designed so you build the actual circuit yourself from spare parts. They are also the most flexible boards in the simulator: the Breadboard is the only board that works with two different simulator backends.

Overview

The Breadboard is a generic board with only reset, serial and crystal circuits, and it supports both the picsim and the simavr backends, so it can host PIC and AVR microcontrollers alike. The X board is the generic example board used by the official “Creating New Boards” tutorial; in PICSimLab it runs three popular PIC chips on picsim. On both boards, everything beyond the chip itself — LEDs, buttons, displays, sensors — comes from Modules → Spare parts.

Supported MCUs

Backend & debugging

Debugging follows whichever backend is active. On the picsim side (and always on the X board) debugging is MPLAB X Integrated Debug via the PICSimLab plugin. On the simavr side you get MPLAB X integration plus remote avr-gdb debugging. Project generation follows the same split: MPLAB X + XC8 projects for PIC16F/PIC18F boards, VSCode + PlatformIO projects for AVR boards.

What you can do

• Prototype a circuit from scratch: chip on the Breadboard, then wire up the LEDs and push buttons spare parts exactly where your design needs them.
• Run the standard PIC projects on the X board — the chip trio overlaps the McLab2 list, so the PIC16F877A blink tutorial and the PIC18F4550 first project apply directly.
• Probe any pin with the built-in two-channel oscilloscope while you experiment.
• Use the X board as the starting point if you want to learn how PICSimLab boards are defined, following the official board-creation tutorial it comes from.

Real limits

• “Generic” means minimal: both boards provide little more than reset, serial and crystal circuitry. There is no rich onboard peripheral set to lean on — if your project needs a display or a keypad, you add it as a spare part yourself.
• The Breadboard’s chip list is backend-dependent and is not a single fixed table; do not assume a specific PIC or AVR is available until you have selected the board and checked. It is a flexible carrier, not a promise that every picsim or simavr chip works on it.
• picsim and simavr keep their own documented limits (see the McLab2 and Arduino Uno/Nano pages) — the generic board does not remove them.

Download PICSimLab from the download page and pick the Breadboard or X board when your project does not match a commercial board.

Not every PIC course starts with a PIC16F877A. A large amount of classic teaching material — especially older books and entry-level courses — is built on the small PIC16F84, PIC16F628 and PIC16F648. PICSimLab covers those chips with two boards: the Labtools McLab1 and the K16F, a teaching board designed by the PICSimLab author himself.

Overview

The McLab1 is PICSimLab’s model of the Labtools McLab1 board. The K16F is the author’s own teaching board, and its official examples use MPLAB X with the XC8 compiler. Both boards run on the picsim backend and support the identical trio of small mid-range PICs, so code and exercises move freely between them.

Supported MCUs

Backend & debugging

Both boards use the picsim backend with MPLAB X Integrated Debug: install the com-picsim-picsimlab.nbm plugin and MPLAB X connects to PICSimLab over TCP (port 1234 by default) for debugging and programming, as described in our MPLAB X plugin guide. For PIC16F boards the Code Project Wizard generates MPLAB X projects using XC8, and the K16F’s official examples follow exactly that MPLAB X + XC8 path.

What you can do

• Work through classic 16F84/16F628 course exercises — port I/O, delays, timers and interrupts — without a programmer or a physical board.
• Use the general PICSimLab workflow from our PIC16F877A blink tutorial: generate the project, build in MPLAB X, load the hex, add spare parts, run.
• Practice register-level skills that transfer directly to bigger chips, such as the Timer0 interrupt pattern and data EEPROM reads and writes on the 628/648.
• Attach LEDs, push buttons and displays from Modules → Spare parts, as in the LED and push button tutorial.

Real limits

• Small chips, small scope: these three parts are entry-level mid-range PICs. There is no ADC on the PIC16F84, and none of the three offers the peripheral richness of a PIC16F877A or PIC18F part — that is a property of the real chips, faithfully reflected here.
• Only these three microcontrollers are selectable on McLab1 and K16F. For the 877A/4550 class of projects use McLab2 or PICGenios instead.
• picsim’s documented peripheral set (ADC, interrupts, WDT, TMR0–TMR2, USART, CCP, EEPROM, I/O ports) is the ceiling of what the backend claims to model.
• PICSimLab has no built-in code editor; MPLAB X + XC8 must be installed first.

Get PICSimLab from the download page, pick McLab1 or K16F, and bring your 16F84/628/648 exercises with you.

PICGenios is the second “full-size” PIC board in PICSimLab, and it is the board many Brazilian and Latin American PIC courses are built around. In the simulator it is interchangeable with the McLab2 for chip support — the official documentation gives both boards exactly the same microcontroller list — so most PIC16F877A and PIC18F4550 material works on either one.

Overview

PICGenios is PICSimLab’s model of the Microgenius PICGenios development board. It runs on the picsim backend. If your course, book or video series uses a PICGenios board, this is the simulated version to select in PICSimLab; the workflow is the same as on real hardware: write code in MPLAB X, compile with XC8, load the .hex file and run.

Supported MCUs

Six chips: PIC16F777 and PIC16F877A from the 16F family, plus PIC18F452, PIC18F4520, PIC18F4550 and PIC18F4620 from the 18F family — the same combination as the McLab2 board.

Backend & debugging

Like every picsim board, PICGenios uses MPLAB X Integrated Debug. With the com-picsim-picsimlab.nbm plugin installed, MPLAB X connects to PICSimLab over a TCP socket (port 1234 by default) and can debug and program the simulated board. The Code Project Wizard generates MPLAB X projects with the XC8 compiler for PIC16F and PIC18F boards. See the MPLAB X plugin guide for the connection steps.

What you can do

• Follow the PIC16F877A project series unchanged: LED blink, HD44780 LCD, matrix keypad, Timer0 interrupts and data EEPROM.
• Start 18F work with the PIC18F4550 first project.
• Add spare parts (displays, keypads, motors, sensors) from Modules → Spare parts to reproduce bench experiments without buying components.

Real limits

• Same backend, same caveats as McLab2: picsim describes itself as emulating some PIC microcontrollers and a specific peripheral set (ADC, interrupts, WDT, TMR0–TMR2, USART, CCP1–CCP3, EEPROM, I/O ports). Peripheral coverage beyond that list is not promised by the upstream project.
• Only the six chips in the table are supported on this board — no other PIC can be selected, and PICSimLab has no PIC32/dsPIC boards at all.
• PICSimLab does not edit source code; MPLAB X and XC8 are required, exactly as with the real PICGenios board.
• Simulation is not the physical board: treat successful runs as strong evidence, not proof, before flashing real hardware.

Install PICSimLab from the download page, select PICGenios, and start with the blink tutorial linked above.