AVR, STM32 and ESP32 in PICSimLab: VSCode + PlatformIO, and the Arduino IDE

For non-PIC boards, PICSimLab documentation names two distinct integration paths, and they are often confused. Keep them separate:

  • The Code Project Wizard path is VSCode + PlatformIO. For boards based on AVR, STM32 and ESP32, the wizard generates projects that use VSCode with PlatformIO — not Arduino IDE projects.
  • The Arduino IDE path is an integration, not the wizard. PICSimLab integrates with the Arduino IDE for programming — the simavr (AVR) board examples use the Arduino IDE with avr-gcc, and ESP32 firmware can be flashed from the Arduino IDE (or IDF) tooling via esptool.py over the serial link.

PICSimLab itself still edits no source code on either path; editing and compiling happen in VSCode/PlatformIO or in the Arduino IDE, exactly as with a real board.

Path A: VSCode + PlatformIO (the wizard path)

  1. Install the prerequisite first: the official requirements state that ESP32, STM32, Atmel (AVR) and STM8/C51 boards need PlatformIO IDE for VSCode installed before you use the wizard.
  2. Select the board and chip in PICSimLab — for example Arduino Uno (ATmega328P), Blue Pill (STM32F103C8T6) or ESP32-DevKitC.
  3. Generate the project with the Code Project Wizard. The official template list covers these boards under PlatformIO with the Arduino framework (Arduino Mega/Nano/Uno, Blue Pill, STM32 H103, ESP32, ESP32-C3, Franzininho DIY, uCboard/STM8S103), plus CMSIS templates for the two STM32 boards and IDF templates for the ESP32 boards.
  4. Build and load: build in VSCode, then load the resulting firmware into PICSimLab — the picsimlab_tool command-line helper (documented form: picsimlab_tool file [.hex or .bin]) exists precisely to upload firmware and integrates with PlatformIO. Board and chip must match the build, as the hex loading guide explains.
  5. Debug (desktop only): each QEMU/simavr backend has a GDB path — avr-gdb for AVR, arm-gdb for STM32, esp32-gdb for ESP32 — and PlatformIO can be configured with debug_tool = custom for graphical debugging. Connection failures are covered in GDB connection fixes.

Path B: The Arduino IDE integration

If your code already lives in the Arduino IDE, you do not have to move it to PlatformIO to use PICSimLab:

  • AVR / simavr boards: the official documentation’s serial chapter has a dedicated Arduino IDE Integration (simavr) section, and the simavr board example sources are used with the Arduino IDE + avr-gcc. Compile the sketch for the matching board chip (ATmega328P for Uno/Nano, ATmega2560 for Mega) and load the produced firmware — see the board notes in Arduino Uno and Nano in PICSimLab.
  • ESP32: the QEMU ESP32 documentation states you can use the Arduino IDE or IDF esptool.py to flash PICSimLab’s ESP32-DevKitC as if it were a real ESP32 board, following the serial-port setup. One hard rule from the same page: QEMU ESP32 does not support the QIO and QOUT flash modes — use only DIO or DOUT. Flash failures are covered in ESP32 flash mode fixes and board context in ESP32-DevKitC in PICSimLab.
  • Serial prerequisite: both flashing and serial sketches rely on the desktop serial setup — a virtual null-modem pair (com0com on Windows, tty0tty on Linux) at 8N1. Setup is in virtual serial ports for PICSimLab. The online version cannot do this: it has no serial communication beyond the IO Vterm terminal.

Which path should you pick?

New project on an AVR, STM32 or ESP32 board: use Path A — it is the wizard’s documented route, the templates are maintained for it, and debugging hooks are described for it. Existing Arduino IDE sketch you do not want to port: use Path B, accepting that it is an integration for programming/flashing rather than the project-generation path. PIC chips are a third, separate route entirely: MPLAB X + XC8. All three meet on the getting started path once your first simulation runs.

Similar Posts