Open-source project
vroland/epdiy avatar
vroland/epdiy

EPDiy Hardware and Firmware for Repurposed E-Paper Panels

EPDiy is a driver board for affordable e-Paper (or E-ink) displays.

1,960 stars269 forksCLGPL-3.0

At a glance

What is it?
EPDiy turns inexpensive bare e-paper panels from replacement e-reader screens into network-connected displays. It is aimed at hardware builders who need ESP32 control, broad panel compatibility and low-power operation, but it requires assembly, connector matching and firmware integration.
Who is it for?
EPDiy fits makers who already expect to manufacture a board, match a panel connector and write or adapt firmware. It is a poor choice for buyers seeking a ready-made display or a plug-and-play library.
Can I use it commercially?
Yes, with conditions. LGPL-3.0 is a weak copyleft licence: you can use it inside commercial and closed-source software, but if you distribute changes to its own files, you must publish those changes under the same licence.
Is it still maintained?
Yes. The repository last received commits 61 days ago.
What is it written in?
Mainly C, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.

Editorial analysis

Why EPDiy Uses Bare E-Paper Panels

EPDiy addresses a specific hardware problem: inexpensive bare e-paper modules are commonly sold as replacement screens for e-readers, but those modules generally need a compatible controller board before they can become useful projects. The EPDiy board supplies that missing layer. It connects an ESP32-based controller to the display panel, manages the panel signals and timing, and provides connectivity that many passive e-paper screens do not include.

The intended users are hardware makers, firmware developers and DIY display projects that can tolerate more integration work than a ready-made module requires. The repository includes examples for weather stations, HTTP services, images, grayscale testing and display diagnosis. Separate projects referenced by the README add terminal access for a Raspberry Pi, a Music Player Daemon dashboard, an Immich image display and a general picture frame.

The choice of bare panels can reduce hardware cost. The README gives rough eBay prices of $20 for small modules and $30 for large ones. Those figures describe the panels, not a complete EPDiy system. A buyer must also account for the controller board, panel connector or adapter, fabrication, power hardware and assembly. E-paper retains its image without continuous power and remains readable in sunlight, but every visual update still requires controlled refresh behavior.

EPDiy V7, ESP32 Variants and Display Matching

The current V7 design is based on the ESP32S3, while versions V2 through V6 use the ESP32. WiFi and Bluetooth connectivity therefore sit alongside the e-paper controller rather than requiring a separate communications module. V7 is battery-oriented and includes a LiPo charger and low deep-sleep current, which matters for devices expected to remain deployed with infrequent screen changes.

The display table is the central compatibility boundary. EPDiy drives matrix-based e-ink panels through similar methods, but the physical connector, pin count and timing still matter. Listed examples include a 39-pin ED060SC4, 33-pin ED097OC4 and ED097TC2 panels, a 40-pin ED047TC1, and several 34-pin 6-inch panels. Some entries are marked tested, while others say they should work. That distinction deserves attention because the repository does not make every compatible model equivalent to a verified one.

V7 has three display connectors, according to the README. Panels that do not match those connectors need an adapter board. This is a manufacturing and integration constraint, not merely a software setting. The README also records panel-specific observations such as inexpensive contrast, better contrast at a higher price, changed flex shapes and dropped connectors in later board versions. Matching only resolution and diagonal size would miss these electrical and mechanical differences.

Waveform Headers, Caching and Refresh Data Flow

The repository layout shows the driver as C code with ESP-IDF and Arduino support. Its build system also reveals how panel behavior enters the firmware. Under `src/waveforms`, JSON descriptions are processed by `scripts/waveform_hdrgen.py` into generated C headers named for EPDiy or E-Ink waveform data. The resulting headers are consumed by the driver, allowing refresh behavior to be represented as compiled firmware data rather than as an unspecified runtime feature.

The Makefile lists supported displays and exports five modes by default: `1,2,5,16,17`. It also generates waveform data for a default temperature range of `15,35`. Those values are build-time defaults, so changing them would change what headers are generated. The source files also include update, diagnostic and special-waveform examples such as `fb_mode_test`, `grayscale_test`, `screen_diag`, `vcom-kickback`, `test`, `calibration_helper` and `demo`.

This architecture implies three main data paths. Application code requests drawing or screen behavior, the EPDiy library translates that request into panel operations, and generated waveform headers supply timing information for the physical refresh. Exact rendering APIs are not present in the README, so they should be checked in the linked getting-started documentation and examples rather than inferred.

V7 has a documented Arduino limitation: update speeds are significantly lower under Arduino because that environment does not allow changing the sub-optimal cache configuration. ESP-IDF therefore matters for a V7 project where refresh time is important. This is a concrete framework choice, not a claim that Arduino is unusable. The documentation only establishes the slower configuration path.

Fabricating EPDiy Before the First Firmware Build

EPDiy is not presented as a retail board that the README tells a new user to install with a package manager. The hardware page at `https://vroland.github.io/epdiy-hardware/` is the documented starting point for obtaining board information. It lists boards and variants, adapters and helpers, with manufacturing files associated with each design.

For a first build, first select the board revision rather than choosing a panel first. V7 uses an ESP32S3 and has different performance characteristics under Arduino. If an older V2 through V6 board is selected, confirm its processor and the panel support listed for the corresponding PCB version. Next, match the display's exact part number, connector type and pin count. If no on-board connector matches, include the appropriate adapter before submitting fabrication files.

The fabrication handoff consists of Gerber files, a bill of materials, part placement files and 3D models, according to the README. For a service such as JLCPCB, the documented workflow is to download those files and upload them through the manufacturer's ordering process. The README does not give a universal manufacturing command or a complete assembly procedure, so fabrication tolerances, component substitution and enclosure design cannot be assumed.

After hardware assembly, the first real firmware task belongs in the linked getting-started documentation. For application work, the repository's `examples/weather` is a practical starting point because it maps directly to the e-paper use case. `examples/screen_diag` is the more cautious first project when panel matching is uncertain. The README does not provide the exact PlatformIO or ESP-IDF invocation for these examples, so this review does not invent a build or flash command.

Hardware and Firmware Boundaries of EPDiy

The main limitation is that EPDiy shifts work from buying a finished module to building a functioning display assembly. Connector mismatch is explicit, while panel compatibility is not perfectly uniform. A model marked tested has stronger repository support than one marked should work, but even that status does not eliminate the need to confirm the exact panel variant, flex-cable arrangement and electrical expectations.

Firmware integration is another constraint. EPDiy supports ESP-IDF and Arduino, but V7 updates are significantly slower in Arduino because the IDE path cannot change a sub-optimal cache configuration. Projects sensitive to refresh speed should evaluate ESP-IDF. Projects that need straightforward Arduino integration may accept slower updates, but the README does not publish device-specific timings, so it cannot support an estimate of the resulting delay.

The display table also mixes inexpensive and higher-quality panels with different contrast characteristics. ED097OC4 is described as inexpensive with inferior contrast, while ED097TC2 is described as slightly more expensive with better contrast. That makes panel choice an engineering decision involving visual output and cost, not just dimensions. Some 6-inch panels with different codes are expected to work like ED060XC3, but that expectation is not the same as a universal tested designation.

EPDiy is the wrong tool when a buyer needs a complete, factory-assembled display with a known connector and immediately available application behavior. It also offers little value to a project that only needs a simple static label or dashboard and does not justify panel integration. The framework mismatch is another boundary: do not select V7 on Arduino if significantly faster updates are a hard requirement and ESP-IDF is unacceptable.

EPDiy Compared with Ready-Made E-Paper Modules

The practical alternative is a ready-made e-paper module that already contains a display, controller and matching connector. Its approach minimizes electrical integration. The buyer selects a known module, connects it to a host board and follows that module's display API. This is easier for a small prototype and reduces uncertainty around bare-panel timing, flex cables and adapters.

EPDiy takes the opposite path. It exposes a reusable ESP32 controller platform, several board revisions and support for many panels that share a matrix-based driving method. That makes it relevant when a project already has a bare panel, needs ESP32 WiFi or Bluetooth, or wants a battery-oriented custom board with charging. The trade-off is responsibility for board fabrication, connector matching, generated waveform headers and firmware configuration.

A ready-made module can also impose its own controller, resolution and refresh constraints, but the repository does not provide evidence about named competing products, their APIs or their update rates. A direct product comparison would therefore exceed the README and repository files. The defensible comparison is architectural: packaged modules minimize assembly work, while EPDiy increases hardware freedom and integration effort.

EPDiy Release, License and Maintenance Load

The repository is not archived, and its last push was on 2026-08-23. Releases 2.1.1, 2.1.2 and 2.1.3 were published on 2026-08-01. These facts indicate recent repository activity, but they do not establish compatibility with every panel or board variant. Adoption should therefore follow release notes and the current hardware documentation rather than assuming every recent package changed runtime behavior.

EPDiy is distributed under LGPL-3.0. Projects that modify, redistribute or combine the licensed code must review the repository's `LICENSE` and determine which LGPL obligations apply to their specific distribution. That is not legal advice. Hardware ordering adds a separate maintenance cost because board revisions, adapters, panel availability and connector choices are not interchangeable. A design tied to V7 also needs attention when moving between ESP32S3 and earlier ESP32-based boards.

Firmware maintenance depends on the selected framework and examples. Arduino users should include the V7 cache limitation in planning, while ESP-IDF users must manage the external build setup described by the documentation. Panel support also spans tested and expected-to-work entries, so upgrade review should check both firmware release notes and the display table before replacing a working combination.

Editorial conclusion

EPDiy fits makers who already expect to manufacture a board, match a panel connector and write or adapt firmware. It is a poor choice for buyers seeking a ready-made display or a plug-and-play library. Before ordering hardware, verify the exact panel model, required connector or adapter, firmware framework and update-speed expectations against the hardware documentation and the EPDiy display table.

Frequently asked questions

Which e-paper displays can I use with EPDiy?

EPDiy lists several panels as tested and others as expected to work, including 6-inch, 9.7-inch and 13.3-inch models. Confirm the exact panel code, connector and pin count in the repository display table because entries do not all have the same support status.

Does EPDiy work with Arduino or ESP-IDF?

EPDiy supports drivers for both Arduino and ESP-IDF. The README warns that V7 update speeds are significantly lower with Arduino because its environment does not allow changing the sub-optimal cache configuration.

What does an EPDiy hardware build include?

The hardware page provides manufacturing files such as Gerber files, a bill of materials, part placement files and 3D models. A panel may also require an adapter board when its connector does not match the selected EPDiy board.

Official sources

  1. License: LGPL-3.0
  2. Project website
  3. README
  4. Releases
  5. vroland/epdiy on GitHub
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/vroland-epdiy.svg)](https://hysenlabs.com/projects/vroland-epdiy)

Was this useful?