Project Nayuki

Pervasive Displays e-paper panel hardware driver


This project contains the following C++ code by Nayuki:

  • A library for controlling e-paper panels manufactured by Pervasive Displays. The hardware driver logic is based on knowledge from Pervasive Displays’ document.

  • Demo programs (Arduino sketches) to illustrate how the library is used. This set includes different genres of artwork (text, photo, gradient, etc.). The majority of the logic in these programs are not specifically tied to e-paper hardware.

Source code repository at GitHub:

Usage pseudocode

#include <cstdint>
#include "EpaperDriver.hpp"

EpaperDriver epd(Size::EPD_2_71_INCH);
epd.panelOnPin = (...);
(... assign other pins ...)
epd.dischargePin = (...);

// Memory must be initialized to avoid undefined behavior when reading
uint8_t prevImage[264 / 8 * 176] = {};
epd.previousPixels = prevImage;

const uint8_t *image = (...);  // The image we want to draw
Status st = epd.changeImage(image);  // The main functionality
if (st != Status::OK)
    print(st);  // Diagnostic info

Software features

Supported features:

  • Drawing a full image from a pointer to a raster bitmap array (in RAM or flash).

  • Changing precisely the pixels that differ from one full image to the next (fast partial update), without clearing and redrawing all pixels.

  • Automatically saving the image and painting the negative previous image.

  • Specifying the frame draw repeat behavior by number of iterations, time duration, or temperature.

  • Specifying arbitrary pin assignments for input and output signal lines.

  • Managing the drawing commands to maximize image quality (reduce ghosting, noise, and other artifacts).

  • Supporting multiple e-paper panel sizes from one family of products.

  • Powering the device on and off properly.

Unsupported features:

  • Keeping the device on after an image is drawn (reduces latency).

  • Painting individual lines, in arbitrary order, without necessarily painting the entire screen.

  • Low-level drawing control for pixel polarity, unequal number of frame repeats, border byte, etc.

  • Reading PROGMEM data using special functions (for microcontrollers that can’t use ordinary pointers to read constant data).

Included demo programs:

  • bitmap_epd: Arbitrary monochrome bitmap images, along with a Java converter program.

  • cellular_automaton_epd: Elementary cellular automata rules showing interesting patterns.

  • checkerboard_epd: Black-and-white checkerboard at 1×1, 2×2, 3×3, etc.

  • game_of_life_epd: Conway’s Game of Life on a grid, with partial screen updates to increase speed and reduce flickering

  • gradient_epd: Horizontal, vertical, and radial gradients with Floyd–Steinberg error diffusion dithering.

  • mandelbrot_epd: Sections of the Mandelbrot set computed using 64-bit fixed-point integer arithmetic.

Hardware support

These combinations of hardware are tested to work:

Unsupported hardware:

  • Microcontrollers: Any microcontroller whose digital output pins are 5 V instead of 3.3 V, any microcontroller without a 3.3 V power output pin.

  • E-paper panels by Pervasive Displays with any of: Aurora Ma film (V230), first generation chip-on-glass (G1 COG), internal timing controller (iTC).

  • E-paper panels made by other manufacturers.


  • My list of supported hardware is not exhaustive. The choice of microcontroller is especially flexible. Essentially any microcontroller that has enough digital I/O pins will work. Even though the SPI protocol is used, native SPI support on the microcontroller is optional; it can be emulated via bit-banging. Of course, a microcontroller with more storage, RAM, and CPU makes it easier to store and render large images.

  • The extension board and e-paper display take a 3.3 V supply voltage, not 5 V. This is not easy to find in the technical documentation, as the actual voltage of the VCC pin is almost never explained.

  • E-paper display driver code written by other people: RePaper Gratis, Pervasive Displays.