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.

PICSimLab has no source-code editor — by design, it emulates hardware, and you write code with the same tools you would use for a real board. For PIC microcontrollers that tool chain is MPLAB X IDE with the XC8 compiler, and PICSimLab’s Code Project Wizard is built around it: for boards based on PIC16F and PIC18F microcontrollers, the wizard generates projects that use MPLAB X. This guide walks the whole path from wizard to a debuggable simulation.

Prerequisite: install MPLAB X and XC8 first

The wizard’s PIC path assumes its tools already exist. Per the official software requirements, boards based on PIC16F and PIC18F need MPLAB X IDE and the XC8 compiler installed beforehand. Install both from Microchip before you generate a project; without XC8, the generated project opens but cannot build. (The AVR, STM32 and ESP32 boards use a different wizard path — VSCode + PlatformIO — covered in the PlatformIO / Arduino IDE workflow.)

Step 1: Select the board and chip in PICSimLab

Select your board and microcontroller first — for example McLab2 with a PIC16F877A, or the same board with a PIC18F4550. The wizard generates the project for the current selection, so changing the chip afterwards means regenerating. Board pages on this site list exactly which chips each board supports: see McLab2 and PICGenios.

Step 2: Generate the project with the Code Project Wizard

Run the Code Project Wizard for the selected board. For PIC16F/PIC18F boards it creates an MPLAB X project using XC8, with the official code templates as the starting point — the template list includes Blink examples (including a Blink FreeRTOS template) for the PIC boards. Save the generated project in your own working folder.

Step 3: Write code and build in MPLAB X

Edit the code in MPLAB X, not in PICSimLab. Two habits save debugging time later:

• Set the clock define your code relies on (for example _XTAL_FREQ in XC8 delay calls) to the clock configured for the board in PICSimLab.
• Build until the project compiles cleanly. A successful build produces the .hex file you will load — if the build fails, fix it here; PICSimLab can only run firmware that actually built.

Step 4: Load the .hex and run

Back in PICSimLab, with the same board and chip selected, load the built .hex and run. The full loading order and the mismatch checks are in the hex loading guide; the PIC16F877A blink tutorial and the PIC18F4550 first project show this exact workflow with complete example code.

Step 5 (optional): Debug from MPLAB X

The desktop version can be debugged from inside MPLAB X, the way you would debug a real board: install the PICSimLab plugin file com-picsim-picsimlab.nbm in MPLAB X, and MPLAB X connects to PICSimLab through a TCP socket on port 1234 (allow it through your firewall). The complete setup is in the MPLAB X plugin guide; if the connection fails, work through plugin connection fixes. Note this is a desktop-only feature — the online version has no debugging support.

Where does this fit in the bigger picture? This workflow is Step 4 material on the getting started path: install, first simulation, board choice, then your own compiled projects.

PICSimLab does not run source code. It runs compiled firmware — the .hex file (or, on some paths, a .bin file) that your compiler produced. Loading sounds trivial, and it is, provided one rule is respected: the board and microcontroller selected in PICSimLab must match the chip the firmware was built for. Most “it loads but does nothing” reports trace back to that single mismatch.

Where the file comes from

• PIC (PIC16F / PIC18F): build the project in MPLAB X with the XC8 compiler; the build output folder contains the .hex. See the MPLAB X + XC8 workflow.
• AVR, STM32, ESP32: the Code Project Wizard generates VSCode + PlatformIO projects for these boards; PlatformIO builds produce the firmware file to load. The command-line helper picsimlab_tool can also upload a file directly — its documented form is picsimlab_tool file [.hex or .bin] — and it integrates with PlatformIO. See the PlatformIO / Arduino IDE workflow.
• Online version: files are loaded by drag and drop or the Load button in the browser, as .hex, .pzw (workspace) or .pcf (spare-parts configuration). See PICSimLab Online.

The loading order that works

1. Select the board first. Pick the board your project targets (for example McLab2 for a PIC16F877A project).
2. Select the exact microcontroller. Set the chip to the one the firmware was compiled for — PIC16F877A firmware on a PIC18F4550 selection is a mismatch even though both sit on the same board list.
3. Load the file. Use the load/open control to point PICSimLab at the freshly built .hex (or .bin where that is the build output). If you rebuilt after a code change, reload — the simulator keeps running the old file until you do.
4. Run. Start the simulation and check for the expected behaviour: an LED state change, output on a spare part, characters in the terminal.

Three checks before you blame the simulator

• Did the build actually succeed? A failed compile can leave a stale .hex from an earlier, different project in the output folder. Rebuild cleanly and confirm the file’s timestamp is new.
• Is the clock consistent? If your code uses delays based on a clock define such as _XTAL_FREQ, it must match the clock configured for the board in PICSimLab, or everything runs at the wrong speed.
• Are you loading the right file type? A .pzw is a saved workspace and a .pcf is a spare-parts configuration — neither is firmware. The firmware itself is the .hex / .bin.

Still stuck — the file will not load, or loads with no visible effect? Work through the dedicated troubleshooting guide: PICSimLab hex file not loading. If the file loads and the board is selected correctly but the simulation itself will not run, see simulation not running instead. And if you have not run anything yet, start with the first simulation walkthrough, which uses a built-in example so the firmware side is known-good.

This walkthrough takes you from a fresh install to a running simulation with a visible result: an LED switching on and off. It uses the best-documented combination in PICSimLab — a PIC16F877A on the McLab2 board — and the built-in example route, so you do not need to write or compile any code for your first run. Once this works, every other tutorial on this site follows the same flow.

What you need

• PICSimLab 0.9.3 installed — follow the Windows install guide (or the download page for Linux and macOS). No compiler is needed for this first run; compiling your own code comes in the workflow guides linked at the end.
• About ten minutes. Nothing else: the example firmware ships with PICSimLab.

No install possible right now? The online version runs the same simulator in a browser tab with documented limits (no debugging, no serial, about half desktop speed) — the steps below for selecting a board and loading an example are the same idea, with files loaded by drag and drop or the Load button.

Step 1: Start PICSimLab and select the board

Launch PICSimLab. Select the McLab2 board and set the microcontroller to PIC16F877A. Board selection comes first in every PICSimLab session: the board defines which microcontrollers you can pick and how the firmware you load will be interpreted. McLab2 officially supports the PIC16F877A (along with the PIC16F777, PIC18F452, PIC18F4520, PIC18F4550 and PIC18F4620); the PICGenios board supports the same set if you prefer it.

Step 2: Open a built-in example

Open the examples from the Help → Examples menu and choose an McLab2 example written for the PIC16F877A — a blink or LED example is ideal for a first run. The examples are the fastest way to reach a known-good simulation, because the firmware, board and microcontroller already match. Alternatively, if you have already compiled a project, load your own firmware instead — the hex loading guide covers that path.

Step 3: Run the simulation

Start the simulation with the run control. A working example shows immediate life: board LEDs change state, and the simulated clock starts counting. If absolutely nothing happens, do not guess — work through the simulation not running checklist (run state, reset, clock and workspace checks) before changing anything else.

Step 4: Add an LED spare part and watch a pin

Board LEDs are fixed to the board. To watch a pin of your choosing, add a spare part:

1. Open Modules → Spare parts.
2. From the Outputs category, add LEDs (a bank of 8 red LEDs).
3. Right-click the part, open Properties, and connect the first LED to the pin your example toggles (for a typical blink example, check which port pin the example drives — RB0 is a common choice).
4. Run the simulation again and watch the LED follow the pin. Right-clicking any spare part also gives you Move, Rotate, Delete and Help.

You have now used the three building blocks of every PICSimLab session: a board, a firmware file and spare parts wired in Properties. The dedicated LED and push button spare parts tutorial goes further, and the PIC16F877A LED blink tutorial shows the same blink written and compiled by you, end to end.

Step 5: Stop, reset, experiment

Stop the simulation, change one thing — a different example, a different LED pin in Properties, a push button part wired to an input pin — and run again. Small, reversible experiments are how the spare-parts system clicks. When you are ready to run your own code, continue with the workflow that matches your chip family: MPLAB X + XC8 for PIC or PlatformIO / Arduino IDE for AVR, STM32 and ESP32. The full beginner path is collected on the getting started page.

The parallel HD44780 LCD uses six or more pins. The I2C version of the display — an HD44780 with a PCF8574 I/O expander backpack — needs only two: SDA and SCL. PICSimLab models this directly with its LCD hd44780 I2C spare part, described in the documentation as a text display HD44780 connected to one PCF8574 I2C converter. This tutorial drives it from a PIC16F877A’s hardware I2C (MSSP).

What you need

• PICSimLab 0.9.3 — see the download page.
• MPLAB X IDE and the XC8 compiler.
• Board: McLab2 or PICGenios, microcontroller PIC16F877A.
• One LCD hd44780 I2C spare part (Outputs category). PICSimLab also lists a standalone IO PCF8574 expander part if you want to model the chip separately.
• Helpful first: the parallel LCD tutorial — the HD44780 commands are identical, only the transport changes.

Wiring used in this tutorial (example)

• SCL → RC3, SDA → RC4 (the PIC16F877A MSSP I2C pins)
• PCF8574 address in the example code: 0x27 (write address 0x4E). This is the most common backpack address; if the part in your configuration uses a different address, change the define — the rest of the code is unaffected.

Steps

1. Generate the project and add the display

Create the MPLAB X project for the PIC16F877A. Open Modules → Spare parts, add Outputs → LCD hd44780 I2C and connect SCL and SDA in its Properties to RC3 and RC4.

2. Understand the PCF8574 pin mapping

The expander byte sent over I2C maps to the LCD like this in the standard backpack layout used by the example: bit 0 = RS, bit 1 = RW (kept 0, write only), bit 2 = EN, bit 3 = backlight (1 = on), bits 4–7 = data D4–D7. Each LCD nibble is written by setting the data bits and pulsing EN within the I2C bytes — no extra GPIO needed.

3. Initialise I2C, then the LCD

The example configures the MSSP as an I2C master at 100 kHz for a 20 MHz clock (SSPADD = 49), then performs the standard HD44780 4-bit initialisation through the backpack. After that, printing is the same lcd_puts() pattern as the parallel version.

4. Build, load and run

Build in MPLAB X, load the .hex and start the simulation. “I2C LCD OK” should appear on the first line, with the second line showing the backpack address the code used.

Example code (XC8)

// Example: HD44780 LCD via PCF8574 I2C backpack - PIC16F877A, XC8
// SCL=RC3, SDA=RC4. Backpack bits: P0=RS P1=RW P2=EN P3=BL P4-P7=D4-D7
#pragma config FOSC = HS
#pragma config WDTE = OFF
#pragma config PWRTE = ON
#pragma config BOREN = ON
#pragma config LVP = OFF
#pragma config CPD = OFF
#pragma config WRT = OFF
#pragma config CP = OFF

#include <xc.h>
#define _XTAL_FREQ 20000000     // Example: match the board clock
#define LCD_ADDR 0x4E           // Example: PCF8574 at 0x27, write address

void i2c_init(void) {
    TRISCbits.TRISC3 = 1;       // SCL input (MSSP controls it)
    TRISCbits.TRISC4 = 1;       // SDA input
    SSPCON = 0x28;              // I2C master mode, module on
    SSPCON2 = 0x00;
    SSPSTAT = 0x00;
    SSPADD = 49;                // 100 kHz at 20 MHz Fosc
}

void i2c_start(void) { SSPCON2bits.SEN = 1; while (SSPCON2bits.SEN) { } }
void i2c_stop(void)  { SSPCON2bits.PEN = 1; while (SSPCON2bits.PEN) { } }

void i2c_write(unsigned char b) {
    SSPBUF = b;
    while (!PIR1bits.SSPIF) { }
    PIR1bits.SSPIF = 0;
}

static void lcd_expander(unsigned char data) {
    i2c_start();
    i2c_write(LCD_ADDR);
    i2c_write(data);
    i2c_stop();
}

// Send one nibble with EN pulse; rs = 0 command, 1 data; backlight on
static void lcd_nibble(unsigned char nibble, unsigned char rs) {
    unsigned char base = (unsigned char)((nibble & 0xF0) | 0x08 | rs);
    lcd_expander((unsigned char)(base | 0x04));  // EN high
    __delay_us(2);
    lcd_expander(base);                          // EN low
    __delay_us(100);
}

static void lcd_byte(unsigned char b, unsigned char rs) {
    lcd_nibble(b & 0xF0, rs);
    lcd_nibble((unsigned char)(b << 4), rs);
    __delay_ms(2);
}

void lcd_cmd(unsigned char c) { lcd_byte(c, 0); }
void lcd_putc(char ch)        { lcd_byte((unsigned char)ch, 1); }
void lcd_puts(const char *s)  { while (*s) lcd_putc(*s++); }

void lcd_init(void) {
    __delay_ms(50);
    lcd_nibble(0x30, 0); __delay_ms(5);
    lcd_nibble(0x30, 0); __delay_us(200);
    lcd_nibble(0x30, 0); __delay_us(200);
    lcd_nibble(0x20, 0);        // 4-bit mode
    lcd_cmd(0x28);              // 4-bit, 2 lines
    lcd_cmd(0x0C);              // display on
    lcd_cmd(0x06);              // entry mode
    lcd_cmd(0x01);              // clear
    __delay_ms(2);
}

void main(void) {
    i2c_init();
    lcd_init();
    lcd_puts("I2C LCD OK");
    lcd_cmd(0xC0);              // line 2
    lcd_puts("PCF8574 @0x27");
    while (1) { }
}

Try next

• Parallel HD44780 LCD — compare the two transports side by side.
• EEPROM tutorial — then try the MEM 24CXXX I2C EEPROM spare part with the same bus code.
• ETH W5500 spare part — the SPI counterpart to this I2C exercise.

Troubleshooting

The display never responds. Address first: a backpack at 0x27 needs write address 0x4E; at 0x3F it is 0x7E. Then check SDA and SCL are not swapped in the part’s Properties — I2C fails silently when they are.

Characters appear but the backlight stays off or text is garbled. The backlight is bit 3 of every expander byte (kept set in the example). Garbled text with a working backlight points at the nibble/EN pulse code — compare it against the parallel tutorial’s driver, which shares the same HD44780 command set.

Among PICSimLab’s spare parts, the ETH w5500 (in the Others category) is the one most often oversold in third-party tutorials. This page sticks to what the official documentation supports: the part adds a W5500 Ethernet shield model to your simulation. What it does not do is write your network firmware for you — and the documentation does not promise full network-stack emulation. Here is how to set the part up correctly and what to expect from it.

What you need

• PICSimLab 0.9.3 — see the download page.
• MPLAB X IDE and the XC8 compiler.
• Board: McLab2 or PICGenios with a PIC that has an MSSP SPI module — this tutorial uses the PIC16F877A as the example host.
• One ETH w5500 spare part, and a W5500 driver for your firmware project (see step 3 — PICSimLab does not supply application firmware).
• Recommended first: the UART tutorial, so you have serial logging while bringing up SPI devices.

Wiring used in this tutorial (example)

The W5500 is an SPI device. On the PIC16F877A the hardware SPI (MSSP) pins are:

• SCK → RC3, SDI (MISO) → RC4, SDO (MOSI) → RC5
• Chip select (example) → RB0 — a normal GPIO you drive yourself

Open the ETH w5500 part’s Properties (right-click the part after adding it) and connect its SPI lines to these pins. The chip-select pin is your choice; just keep the firmware and the Properties window in agreement.

Steps

1. Generate the project and add the part

Create the MPLAB X project for the PIC16F877A. Open Modules → Spare parts and add Others → ETH w5500. Set its connections in Properties as above, and save the spare-parts configuration (.pcf) from the window’s File menu so the wiring survives restarts.

2. Bring up SPI first, without the network stack

Before any Ethernet code, prove the SPI bus: initialise the MSSP as an SPI master and read a known W5500 register (the VERSIONR register, which a real W5500 answers with 0x04) in a tiny test program, logging the result over the UART from the earlier tutorial. If the version read fails in simulation, the problem is wiring or SPI mode — not your TCP code.

3. Add a W5500 driver to your firmware

PICSimLab simulates hardware; it does not include your application. A W5500 driver (the chip vendor’s ioLibrary is the usual starting point on real projects) must be ported to XC8 and to your SPI read/write functions, with realistic expectations about effort: small PICs have limited RAM for socket buffers, so keep the test program minimal — for example, initialise the chip, set a static IP configuration in code and open one socket.

4. Set honest expectations for the simulation

The official PICSimLab spare-parts documentation confirms the ETH w5500 part exists and how it is added; it does not publish a coverage matrix for network protocols. Treat the simulation as a way to develop and debug your SPI driver and program flow. Anything that depends on a real LAN — DHCP servers, real peers, internet services, throughput — belongs on real hardware with a real W5500. Tutorials that promise full Ethernet projects “just like real hardware” in the simulator are going beyond the documentation.

Example code: SPI version check (XC8)

// Example: MSSP SPI master + W5500 version register read
// PIC16F877A, XC8. SCK=RC3, SDI=RC4, SDO=RC5, CS=RB0 (example)
#pragma config FOSC = HS
#pragma config WDTE = OFF
#pragma config PWRTE = ON
#pragma config BOREN = ON
#pragma config LVP = OFF
#pragma config CPD = OFF
#pragma config WRT = OFF
#pragma config CP = OFF

#include <xc.h>
#define _XTAL_FREQ 20000000     // Example: match the board clock

#define W5500_CS PORTBbits.RB0

void spi_init(void) {
    TRISCbits.TRISC3 = 0;       // SCK output
    TRISCbits.TRISC4 = 1;       // SDI input
    TRISCbits.TRISC5 = 0;       // SDO output
    TRISBbits.TRISB0 = 0;       // CS output
    W5500_CS = 1;               // deselected
    SSPSTAT = 0x40;             // CKE=1, sample at middle
    SSPCON = 0x21;              // SPI master, Fosc/16, idle low
}

unsigned char spi_transfer(unsigned char b) {
    SSPBUF = b;
    while (!SSPSTATbits.BF) { }
    return SSPBUF;
}

// W5500 VERSIONR is at block 0, address 0x0039; value should be 0x04
unsigned char w5500_read_version(void) {
    W5500_CS = 0;
    spi_transfer(0x00);         // address high byte
    spi_transfer(0x39);         // address low byte
    spi_transfer(0x00);         // read, block 0
    unsigned char v = spi_transfer(0xFF);
    W5500_CS = 1;
    return v;
}

Use w5500_read_version() from your test main with the result sent to the UART or shown on LEDs — it separates “SPI works” from “network stack works”, which saves hours.

Try next

• UART serial — the debug channel every network bring-up needs.
• LCD over I2C (PCF8574) — another bus peripheral, with a gentler learning curve than Ethernet.
• Oscilloscope basics — sanity-check SCK and chip-select timing.

Troubleshooting

The version register does not read 0x04. Work the SPI checklist: CS actually toggling, SDI/SDO not swapped in Properties, CKE/CKP settings, and the correct three-byte header before the data byte. Change one thing at a time and retest.

The driver compiles but nothing network-related happens. That is the expected boundary of the simulation if your code depends on a live network. Keep driver and SPI debugging in PICSimLab; schedule protocol testing on real hardware.

Stepper motors move in discrete steps driven by a repeating coil pattern, which makes them a clean simulation subject: if the sequence and timing are right, the motor turns; if not, it jitters. PICSimLab’s Step Motor spare part lets a PIC16F877A drive a virtual stepper so you can learn full-step sequencing without a motor, a driver board or a power supply.

What you need

• PICSimLab 0.9.3 — see the download page.
• MPLAB X IDE and the XC8 compiler.
• Board: McLab2 or PICGenios, microcontroller PIC16F877A.
• One Step Motor spare part (Outputs category).

Wiring used in this tutorial (example)

• Step Motor control inputs 1–4 → RD0–RD3

Connect the four control lines in the part’s Properties window (right-click the part → Properties). A note for real hardware: a microcontroller pin cannot drive motor coils directly — a real build needs a driver stage (a transistor array or H-bridge module) between the PIC and the motor. The spare part models the motor side in simulation, which is precisely why it is handy for learning the sequence logic first.

Steps

1. Generate the project and add the part

Create the MPLAB X project for the PIC16F877A with the Code Project Wizard. Open Modules → Spare parts, add Outputs → Step Motor and wire its four inputs to RD0–RD3 in Properties.

2. Learn the full-step sequence

Two-phase-on full stepping energises two coils at a time in this repeating pattern on RD3–RD0: 1001, 1100, 0110, 0011 (0x09, 0x0C, 0x06, 0x03). Stepping forward through the table turns the motor one way; stepping backward reverses it. The delay between steps sets the speed — too short and a real motor would skip steps, which is a habit worth building even in simulation.

3. Build, load and run

Build in MPLAB X, load the .hex and run. The example rotates forward for 48 steps, pauses, then rotates back — watch the motor part respond, and probe RD0–RD3 with Modules → Oscilloscope if you want to see the four phase signals shift along.

Example code (XC8)

// Example: full-step stepper drive on RD0-RD3 - PIC16F877A, XC8
#pragma config FOSC = HS
#pragma config WDTE = OFF
#pragma config PWRTE = ON
#pragma config BOREN = ON
#pragma config LVP = OFF
#pragma config CPD = OFF
#pragma config WRT = OFF
#pragma config CP = OFF

#include <xc.h>
#define _XTAL_FREQ 20000000     // Example: match the board clock

// Two-phase-on full-step sequence
static const unsigned char step_table[4] = {0x09, 0x0C, 0x06, 0x03};
static unsigned char step_index = 0;

void step_forward(void) {
    step_index = (step_index + 1) & 0x03;
    PORTD = step_table[step_index];
}

void step_reverse(void) {
    step_index = (step_index - 1) & 0x03;
    PORTD = step_table[step_index];
}

void main(void) {
    TRISD = 0x00;               // RD0-RD3 outputs to the Step Motor part
    PORTD = 0x00;
    while (1) {
        for (unsigned char i = 0; i < 48; i++) {  // forward 48 steps
            step_forward();
            __delay_ms(20);                       // step rate = speed
        }
        __delay_ms(500);
        for (unsigned char i = 0; i < 48; i++) {  // and back again
            step_reverse();
            __delay_ms(20);
        }
        __delay_ms(500);
    }
}

Try next

• Timers and interrupts — generate the step pulses from a timer for jitter-free speed.
• Oscilloscope basics — verify the spacing of the four phase outputs.
• ADC potentiometer — use a knob to set the motor speed.

Troubleshooting

The motor vibrates but does not turn. The phase order is wrong: one swapped control line in the part’s Properties (or in the step table) produces exactly this symptom. Check the RD0–RD3 mapping first.

It turns the wrong way. Not a bug — reverse the table order (or swap the forward/reverse functions). Direction is purely a matter of sequence order in a stepper.

PICSimLab includes a built-in oscilloscope, and learning it early makes every other tutorial easier: instead of guessing whether a pin toggles at the right speed, you measure it. Be clear about what it is, though — per the official documentation it is a basic two-channel oscilloscope for viewing the signal on any microcontroller pin, not a professional bench instrument. Within that scope, it is genuinely useful.

What you need

• PICSimLab 0.9.3 — see the download page.
• Any running simulation with a changing pin. The LED blink project (RB0 toggling every 500 ms) is the ideal first signal; the timer interrupt project works too.
• No spare parts are required — the oscilloscope is its own module, not a spare part.

Steps

1. Start a simulation with a known signal

Load the blink hex file, start the simulation and confirm the LED toggles. A measurement is only meaningful against a signal you can predict: RB0 should be a square wave with a period of about one second (500 ms high, 500 ms low).

2. Open the oscilloscope

Open Modules → Oscilloscope. The oscilloscope window shows two channels; assign the first channel to pin RB0 of the microcontroller. Adjust the time base until one or two full cycles fit on screen — for a 1 Hz signal you need a much slower sweep than the defaults used for kilohertz signals.

3. Add measurements

The oscilloscope supports up to 4 simultaneous measurements, chosen from: Vmax, Vmin, Vavg, Vrms, Frequency, Duty cycle, Pos. cycle, Neg. cycle and Full cycle. For the blink signal, add Frequency and Duty cycle: expect about 1 Hz and about 50%. Add Full cycle as a third measurement to see the period in time units.

4. Compare two pins on two channels

Assign the second channel to another live pin — for example the Timer0 interrupt LED project running alongside a delay-based blink on a second pin, or the TX pin from the UART tutorial while it sends a character. Two channels are enough to check which signal changes first and whether two outputs stay in step.

5. Measure a PWM-style signal

Generate a faster toggling signal (shorten the blink delays, or use a CCP PWM exercise) and re-measure: Frequency and Duty cycle now change with your code, which is exactly the feedback loop you want when tuning timers. Remember the simulation speed caveat from the documentation: signals are only as accurate as the simulated clock, so verify your _XTAL_FREQ assumption matches the board configuration.

What the oscilloscope is not

It does not turn PICSimLab into a logic analyser suite or a calibrated measurement instrument, and it shows simulated pin levels — idealised logic signals from the simulator core, not the analogue behaviour (ringing, rise times, loading) of a real circuit. Use it to verify timing, frequency, duty cycle and sequencing in your firmware; use real instruments on real hardware for signal integrity.

Try next

• Timers and interrupts — produce precise signals worth measuring.
• ADC potentiometer — probe the analog input pin while you turn the knob.
• Step Motor spare part — check the four step pulses stay evenly spaced.

Troubleshooting

The trace is a flat line. The simulation is stopped, the channel is assigned to the wrong pin, or the time base is so fast that a 1 Hz signal looks frozen. Confirm the LED itself toggles, then slow the sweep down.

Frequency reads about double or half the expected value. Your code’s timing assumption is off — most often _XTAL_FREQ not matching the board clock configured in PICSimLab. Fix the define, rebuild, reload and measure again.

“LED on RB0, LED on RC0, push button to control them” is one of the most searched PICSimLab exercises — and a perfect spare-parts workout. This tutorial wires an LED to RB0, a second LED to RC0 and a push button that drives them, using PICSimLab’s LEDs and Push Buttons spare parts with a PIC16F877A. If you can do this, you understand digital outputs, digital inputs and part wiring — the three skills every other tutorial here builds on.

What you need

• PICSimLab 0.9.3 — see the download page.
• MPLAB X IDE and the XC8 compiler.
• Board: McLab2 or PICGenios, microcontroller PIC16F877A (the Breadboard also works for this exercise).
• Two spare parts: LEDs (Outputs) and Push Buttons (Inputs).

Wiring: LED RB0, LED RC0, push button on RD0

• LEDs part, LED 1 → RB0
• LEDs part, LED 2 → RC0
• Push Buttons part, button 1 → RD0 (the input the code polls)

Add both parts from Modules → Spare parts, then right-click each part, open Properties and set these connections. The behaviour in the example: while the button is held, the RB0 LED follows the button and the RC0 LED lights too; a quick press-and-release toggles the RC0 LED state so you can also test edge detection. Adjust the button’s active level in Properties if your part defaults differ — the code comments mark where to invert the test.

Steps

1. Generate the project

Select the board and PIC16F877A, then generate the MPLAB X project with the Code Project Wizard.

2. Configure directions

RB0 and RC0 are outputs (TRISBbits.TRISB0 = 0, TRISCbits.TRISC0 = 0); RD0 is an input (TRISDbits.TRISD0 = 1). Ninety percent of “the LED does nothing” reports are a direction bit or a Properties connection — check those before suspecting the simulator.

3. Build, load and click

Build in MPLAB X, load the .hex and run. Click and hold the button in the spare-parts window: RB0 follows the button live. Release and click again to see RC0 change state per press.

Example code (XC8)

// Example: LED on RB0 + LED on RC0 + push button - PIC16F877A, XC8
// Button on RD0 (example: pressed = logic 1; invert the tests if
// your Push Buttons part is configured active-low)
#pragma config FOSC = HS
#pragma config WDTE = OFF
#pragma config PWRTE = ON
#pragma config BOREN = ON
#pragma config LVP = OFF
#pragma config CPD = OFF
#pragma config WRT = OFF
#pragma config CP = OFF

#include <xc.h>
#define _XTAL_FREQ 20000000     // Example: match the board clock

#define BUTTON PORTDbits.RD0

void main(void) {
    TRISBbits.TRISB0 = 0;       // RB0 output -> LED 1
    TRISCbits.TRISC0 = 0;       // RC0 output -> LED 2
    TRISDbits.TRISD0 = 1;       // RD0 input  -> push button
    PORTBbits.RB0 = 0;
    PORTCbits.RC0 = 0;
    unsigned char rc0_state = 0;
    unsigned char last_button = 0;
    while (1) {
        unsigned char pressed = BUTTON;
        PORTBbits.RB0 = pressed;              // RB0 LED follows the button
        if (pressed && !last_button) {        // rising edge: one toggle
            rc0_state = !rc0_state;
            PORTCbits.RC0 = rc0_state;        // RC0 LED toggles per press
            __delay_ms(30);                   // debounce
        }
        last_button = pressed;
    }
}

Try next

• Matrix keypad — from one button to sixteen keys on eight pins.
• EEPROM counter — count the button presses and keep the count across resets.
• Timers and interrupts — react to the button in an interrupt instead of polling.

Troubleshooting

The RB0 LED is on when it should be off (or the reverse). The button part’s active level does not match the code’s assumption. Either flip the connection behaviour in the part’s Properties or invert the pressed test (pressed = !BUTTON) and rebuild.

RC0 flickers instead of toggling once per press. Contact bounce plus a held button: the edge-detect and debounce in the example handle the normal case — if it still flickers, increase the debounce delay and make sure you are not retriggering by holding the mouse button down.

The PIC18F4550 is one of the six microcontrollers officially supported by the McLab2 and PICGenios boards in PICSimLab, and moving from the PIC16F877A to it is a natural second step: the workflow is identical, only the chip family, configuration words and port registers change. This tutorial takes you from an empty project to a running LED blink on the PIC18F4550 — and is honest about where it stops.

What you need

• PICSimLab 0.9.3 — see the download page.
• MPLAB X IDE and the XC8 compiler. As with the PIC16F, the Code Project Wizard generates an MPLAB X project for PIC18F boards.
• Board: McLab2 or PICGenios, microcontroller PIC18F4550.
• One LEDs spare part connected to RB0.

What is different from the PIC16F877A

• LAT registers: on PIC18 you write outputs through LATB and read inputs through PORTB. Writing to PORTB directly (PIC16 style) causes read-modify-write surprises on loaded pins.
• Configuration words: PIC18F4550 uses several CONFIG registers; the example sets the essential ones (oscillator, watchdog off, low-voltage programming off). USB-related configuration is deliberately left at defaults because this tutorial does not use USB.
• Analog defaults: several pins power up as analog inputs; the example sets ADCON1 so PORTB pins behave as digital I/O.

Steps

1. Select the board and the PIC18F4550

Start PICSimLab, choose the McLab2 board (or PICGenios) and set the microcontroller to PIC18F4550. Generating the project after this selection is what makes the wizard target the right chip.

2. Generate and build the project

Use the Code Project Wizard to generate the MPLAB X project, paste in the example code, and build. MPLAB X produces the .hex file as usual. The official documentation also points to board example sources in MPLAB X + XC8 from Help → Examples if you want a larger starting point.

3. Add the LED and load the hex

Open Modules → Spare parts, add Outputs → LEDs and connect the first LED to RB0 in Properties. Load the hex file and start the simulation: the LED blinks once per second.

4. Know the scope: no USB in this tutorial

The PIC18F4550 is famous for its USB peripheral, so be precise about expectations: the official PICSimLab documentation for these boards describes the chip and the MPLAB X/XC8 example flow, and does not document USB simulation for it. This tutorial therefore covers the core digital I/O workflow only. If your goal is a real USB device, plan to develop and test that part on physical hardware; use PICSimLab for the surrounding logic (buttons, displays, ADC, serial-style state machines) where simulation genuinely helps.

Example code (XC8, PIC18F4550)

// Example: first PIC18F4550 project, blink on RB0 - XC8
#pragma config FOSC = HS        // High-speed oscillator (example)
#pragma config WDT = OFF        // Watchdog off
#pragma config PBADEN = OFF     // PORTB pins digital on reset
#pragma config MCLRE = ON       // MCLR enabled
#pragma config LVP = OFF        // Low-voltage programming off
#pragma config XINST = OFF      // Extended instruction set off

#include <xc.h>
#define _XTAL_FREQ 20000000     // Example: match the board clock

void main(void) {
    ADCON1 = 0x0F;              // all analog pins digital
    TRISBbits.TRISB0 = 0;       // RB0 output
    LATBbits.LATB0 = 0;         // LED off (write via LATB on PIC18)
    while (1) {
        LATBbits.LATB0 = 1;
        __delay_ms(500);
        LATBbits.LATB0 = 0;
        __delay_ms(500);
    }
}

Try next

• PIC16F877A blink — compare the same project across the two families.
• HD44780 LCD — port the LCD driver to LAT registers on the 4550.
• UART serial — the 4550 USART follows the same pattern as the 877A.

Troubleshooting

The project builds for the wrong chip. The device selected in MPLAB X must be PIC18F4550 and the hex must be loaded after selecting the PIC18F4550 on the board in PICSimLab. A PIC16F877A hex will not run correctly on the 4550 configuration.

RB0 does nothing. Check the two PIC18 traps first: pins left as analog inputs (fix with ADCON1/PBADEN as in the example) and output writes done to PORTB instead of LATB.