Render your Arduino e-paper firmware — without the board or the panel

Why e-paper development is slow

If you've written e-paper firmware, you know the loop. Move a label two pixels, rebuild, flash, wait through the panel's multi-second refresh, and squint at the glass. When the driver class is wrong, the panel reports success and renders blank anyway. And every iteration needs the display wired to the pins, on a board you can only flash one at a time.

The slow part isn't your drawing code; it's everything around it. This post sets up a loop where the same binary runs in a window on your laptop and paints the same pixels.

The sketch

There is no porting layer or mock. The sketch is a stock Arduino-ESP32 program driving GxEPD2, e-paper display lib, on an ESP32-WROOM-32 with a Waveshare 2.9″ tri-color panel:

#include <Arduino.h>
#include <GxEPD2_3C.h>
#include <Fonts/FreeSerifBold12pt7b.h>

// Waveshare 2.9" tri-color (C90c driver). CS=5 DC=17 RST=16 BUSY=4.
GxEPD2_3C<GxEPD2_290_C90c, GxEPD2_290_C90c::HEIGHT> display(
    GxEPD2_290_C90c(/*CS=*/5, /*DC=*/17, /*RST=*/16, /*BUSY=*/4));

void drawPage() {
  display.setFullWindow();
  display.firstPage();
  do {
    display.fillScreen(GxEPD_WHITE);
    display.setTextColor(GxEPD_BLACK);
    display.setFont(&FreeSerifBold12pt7b);
    display.setCursor(8, 24);
    display.print("LabWired Reader");
    display.setTextColor(GxEPD_RED);
    display.setCursor(230, 122);
    display.print("Page 1");
  } while (display.nextPage());
}

void setup() {
  Serial.begin(115200);
  display.init(115200);
  display.setRotation(1);
  drawPage();
  display.hibernate();
}

That's the full Arduino framework with FreeRTOS underneath, talking SPI to the panel's driver IC. Nothing in the sketch knows whether the other end of the bus is glass or a model.

Build it with PlatformIO

The build is the standard espressif32 / Arduino setup, with GxEPD2 pulled from the registry:

[env:esp32dev]
platform = espressif32
board = esp32dev
framework = arduino

lib_deps =
    zinggjm/GxEPD2@^1.6.0

pio run produces firmware.elf, the same image you'd flash to the board. The full sketch, platformio.ini, and a one-command headless run are in the runnable example.

Run it on the digital twin

Hand that ELF to the LabWired simulator. It boots the Arduino-ESP32 image on an instruction-level Xtensa core model, brings up FreeRTOS, runs your setup(), and the SPI bytes your firmware clocks out land in a simulated e-paper panel that decodes them and shows the page — the same "LabWired Reader" you'd see on glass.

flowchart LR
  A["GxEPD2 sketch"] -- "pio run" --> B["firmware.elf"]
  B --> C["LabWired sim<br/>Xtensa core + FreeRTOS"]
  C -- "SPI bytes" --> D["e-paper panel model"]
  D --> E(("rendered<br/>page"))
  classDef ok fill:#27c93f,stroke:#1a1a1a,stroke-width:2px,color:#0d2b12;
  class E ok;
      

From there, iterating feels like web development: change the sketch, run, look at the rendered page. A full cycle takes about a second, against the minute or more that a flash-and-refresh round trip costs on the bench.

Under the hood

• The ESP32's Xtensa LX6 core model runs the binary instruction by instruction, through the bootloader, the FreeRTOS scheduler, your task, and the GxEPD2 SPI sequence — the same code path it takes on silicon.
• The display model follows the controller's command/data state machine, so a wrong driver class or a botched window command renders wrong in the simulator too. That's the class of bug you currently need the physical panel to catch.
• The boot path was diffed against a physical ESP32-WROOM-32 over its UART, banner for banner, so a clean run in the simulator carries over to the bench.
• Runs are deterministic: one ELF, one output. A rendering regression can fail a CI build like any other test, without a board farm or flaky panel timing.

See an e-reader render in the Playground →

If you're building an embedded UI and want this loop for your panel, write to contact@labwired.com or book 30 minutes.