ePaper GUI Development Using Microchip Graphics Suite (MGS)
Introduction
Electrophoretic displays (EPDs), also known as ePaper displays, are ideal for devices that need persistent content, excellent visibility, and minimal power use. Because they only consume power when updating, they are well-suited to battery-powered products, IoT devices, digital labels, dashboards and industrial interfaces.
This guide helps developers use Microchip Graphics Suite (MGS) with monochrome ePaper displays to build low-power, readable and reliable display solutions.
MGS Harmony provides the software layer for managing display content, refresh behavior, and hardware communication. With MGS, you can configure supported displays, render text and graphics, control updates, and optimize performance for your device.
ePaper Display Fundamentals
This section explains the basic operating principles of ePaper displays and describes their key characteristics, including image retention, low power consumption, slower refresh rates and limited color or grayscale capability. It also compares full and partial refresh behavior and introduces important design considerations for ePaper-based interfaces.
See the "ePaper Display Fundamentals" page for more information.
Microchip Graphics Suite Overview
MGS provides key features that make it well-suited for monochrome ePaper GUI development.
MGS supports native monochrome color mode in both MGS Composer and the MGS graphics library, allowing developers to design, preview and render interfaces directly for 1-bit-per-pixel displays. This helps ensure that text, icons, widget and layouts are optimized for the contrast and visual limitations of monochrome ePaper panels.
In Monochrome mode, MGS stores and processes graphics assets as 1 bpp monochrome data, reducing Flash and RAM usage while improving rendering efficiency. This is especially important for memory-constrained embedded systems and ePaper displays that use packed 1-bit frame buffers. The MGS graphics library also automatically aligns update areas so the render buffer is byte-aligned, simplifying partial-update handling and improving compatibility with monochrome display buffer formats.
The MGS Simulator supports Monochrome mode, enabling early validation of layout, readability, contrast and widget appearance before testing on hardware.
In the recommended workflow, MGS Composer is used to design and generate the GUI, while VS Code with MPLAB Extensions is used to edit application code, build, program and debug the embedded project.
To learn more about MGS, refer to the following user guides:
System Requirements and Development Environment
An ePaper GUI project requires a supported Microchip MCU or MPU, an ePaper display module and a compatible display interface. The target device should provide enough Flash and RAM for the application, graphics library, fonts, images and render buffers. For monochrome ePaper displays, memory requirements are typically lower because display data and assets can use 1 bpp formats. The display interface depends on the ePaper module and controller, but commonly includes SPI, GPIO control lines, reset, busy/status signals and optional power-control circuitry.
A typical project setup begins by creating or opening the embedded application in VS Code with MPLAB Extensions, configuring the target device, board support, peripherals, and display driver, and then using MGS Composer to create the ePaper GUI. The GUI should be configured for the target display resolution, orientation and monochrome color mode where applicable. After generating the graphics code and assets from MGS, the developer integrates application logic, display refresh handling, and power-management behavior, then builds, programs and debugs the project from VS Code.
Application Examples
Example MGS projects using ePaper displays are available in the MGS GitHub repository.
MGS Quickstart applications provide a good starting point for monochrome ePaper GUI development with MGS Harmony. Refer to the repository README.md file for more information.
Designing an ePaper GUI
This section describes the basic workflow for creating a new ePaper GUI project.
It includes selecting the target device and display configuration, defining display properties such as resolution and orientation, importing fonts and graphics assets, and building screens, widgets and navigation flows.
Implementing Application Logic
For additional guidance on connecting your monochrome GUI to the rest of your application, refer to the "Designing an Application with Microchip Graphics Suite (MGS)" page of the MGS Harmony guide.
This resource explains how the GUI fits into the broader application structure, including how to manage application logic, update screen content and respond to external events such as touch input, buttons, sensors, timers, or other I/O signals. Use this page when you are ready to move beyond the visual layout and integrate the monochrome interface with the functional behavior of your embedded system.
Event handling in MGS is the same irrespective of the color mode. Follow the same procedure for enabling event handling in widgets, screens and custom widget event filters.
Refer to the "Custom Input Event Handling" page for further information on event handling.
Performance and Memory Optimization
Unlike color displays, monochrome ePaper displays can significantly reduce the memory and processing requirements of a GUI because graphics assets and frame buffers can be stored and rendered at 1 bit per pixel. The MGS library takes advantage of this by supporting 1-bit-per-pixel storage and rendering for monochrome graphics and GUI elements.
However, ePaper displays are most often used in low-power and battery-powered applications, where the host MCU typically has much less memory and processing capability than MCUs used in color GUI systems. As a result, even though monochrome rendering is inherently more efficient, further optimization of the GUI’s memory footprint and processing requirements remains an important priority.
Refer to the user guide on "Designing a Monochrome GUI Using MGS Composer" page for guidelines to design and develop the GUI with these optimizations in mind.
For information on how to optimize the memory buffers used by the MGS library, refer to the following guides:
Optimizing the Scratch Buffer Size
When calculating the scratch buffer size, make sure that the frame buffer is in 1 bit/pixel format.
For information on how to optimize the display interface transfer speed, refer to the "Microchip Graphics Suite (MGS) ePaper Driver User Guide" page.
Ghosting and ePaper Refresh Modes
Ghosting is a faint remnant of a previous image that remains visible after an ePaper display update. It occurs when the charged pigment particles in the display do not move completely or uniformly during a refresh.
Ghosting is more likely to occur after repeated partial refreshes, frequent updates without a full refresh, temperature changes, display aging, or poorly tuned drive waveforms.
ePaper displays typically support two refresh types, full refresh and partial refresh.
- Full refresh redraws the entire display using a complete waveform sequence. It provides the cleanest image and helps reduce ghosting, but it is slower, may use more energy and can cause visible flashing. Use full refresh for initialization, major screen changes, navigation to a new screen, or ghosting cleanup.
- Partial refresh updates only a selected region of the display. It is faster and more power-efficient for small changes such as values, icons, timestamps, indicators, or notifications. Repeated partial refreshes can accumulate ghosting, so periodic full refreshes may be required.
For best results, keep frequently updated content in small, well-defined regions and perform a full refresh when changing screens or after repeated partial updates.
Refer to the "Microchip Graphics Suite (MGS) ePaper Driver User Guide" for information about configuring refresh modes and how to manage ghosting with ePaper displays.