MCPcopy Index your code
hub / github.com/Modos-Labs/Glider

github.com/Modos-Labs/Glider @main

Chat with this repo
repository ↗ · DeepWiki ↗ · + Follow
5,113 symbols 8,849 edges 286 files 3,889 documented · 76%
What it actually does AI analysis from the code graph — generated when you open this
loading…
README

Glider

Open-source Eink monitor with an emphasis on low latency.

Note: This repo only contains the hardware design, the gateware running on the FPGA is my open-source Caster EPDC design. This README also contains information about the Caster as well.

Hardware Photo

This is a long document, containing not just information about this project, but also pretty much everything I know about Eink. Given it's a bit hard to gather information about Eink online, I think this is the right thing to do. Use the following table of contents to navigate around.

Eink is a registered trademark and brand of E Ink Corporation. All the contents provided in this repo are based on publicly available information online and original research. They are not endorsed by Eink in any way and they may contain errors and/ or inaccuracies.

If you're interested in attaining a board, checkout the product page for the Modos Paper Monitor on Crowd Supply.

If you are interested in Eink or any other display technologies, I have a Discord server for that. Feel free to join: https://discord.gg/rtT7euSHQS . (This Discord server is also not endorsed by Eink or any other company. It's not a customer support server.) For Modos product support or other inqueries about Modos products, use https://discord.gg/6ktE6VxSyh.

Table of Contents

Overview

Features

  • Complete solution for low-latency/ high-refresh-rate EPD monitor
  • Supports electrophoretic display panels with parallel I/F (Eink(R), OED and DES)
  • Supports both monochrome and color-filter-array (such as Kaleido(TM)) based color screen
  • Extremely low processing delay of \<20 us
  • Supports binary, 4-level grayscale, and 16-level grayscale output modes
  • Latency-optimized binary and 4-level grayscale driving modes
  • Hybrid automatic binary and 16-level grayscale driving mode
  • Host software runtime controllable regional update and mode switching
  • Hardware bayer dithering, blue-noise dithering, and error-diffusion dithering with no additional latency
  • Controller takes standard HVsync signal input
  • Board-level design supports USB-C (USB Type-C DisplayPort Alt Mode) and DVI input

Hardware

r0p7_mb

  • Xilinx(R) Spartan-6 LX16 FPGA running Caster
  • DDR3-800 framebuffer memory
  • Type-C DisplayPort Alt-Mode video input with onboard PTN3460 DP-LVDS bridge or
  • DVI (via microHDMI connector) video input with onboard ADV7611 decoder
  • Epaper power supply with up to 1A peak current on +/-15V rail supporting large panels
  • VCOM kick-back voltage measurement support
  • On-board STM32H750 microcontroller for USB communication and firmware upgrade
  • Up to 133MP/s processing rate with error-diffusion dithering enabled, >200MP/s when disabled

The board is designed with KiCad. You may need the latest stable version of KiCad to open the source file.

Components

This repo hosts the PCB design and firmware source code. The RTL code is in a separate repo: https://gitlab.com/zephray/Caster/.

Eink Screens

Eink is the brand of a family of paper-like electrophoretic displays. The underlying technology is invented in the MIT Media Lab between 1995 and 1997 by Barrett Comiskey, J.D. Albert, and Joseph Jacobson. They later founded the E Ink Corporation to commercialize this technology.

Nowadays they are commonly used on e-readers and electronic shelf labels. You’ve probably seen them on Kindle, in stores, or maybe in some train stations as well.

eReader/ Tablets Electronic Shelf Label Digital Signage
app_ereader app_esl app_signage

(Source: https://www.eink.com/application, image copyright Eink corporation)

This section gives an overview of the electrophoretic displays, including the screen panels available and underlying technology. Note this project doesn't and can't support all electrophoretic screens. This documentation also solely focuses on using existing off-the-shelf screen panels rather than the physics or manufacturing process of one.

Basic Theory of Operation

In the simplest form, you have charged particles with different colors, dispersed in some oil in some transparent container. By applying electric fields the particles can be moved up or down to produce either black or white, or a mixture of that.

eink-particle

(Source: https://www.eink.com/tech/detail/How_it_works , copyright Eink Corporation)

There are multiple technologies based on this basic concept, namely Eink’s micro-capsule display, SiPix (now acquired by Eink)’s micro-cup display, and WFT’s DES display. They differ in specific ways of confining the particles in containers, but otherwise very similar.

The pixels on the screen are typically arranged as a 2D array, driven with TFTs. The pixels are scanned/ driven periodically at a fixed refresh rate, typically ranging from 50Hz to 120Hz. Applying positive voltage on the pixel will typically drive the particles toward the white state while applying negative voltage will drive the particles towards the black state. This is similar to active matrix TN/IPS LCDs, which also use 2D TFT arrays and electrical fields for changing state. However, unlike LCDs, EPDs maintain their state after the electrical field is removed. So unlike LCDs which require continuous refreshing, the EPDs only need to be refreshed till the pixels are fully driven.

In terms of driving the screen panel, depending on the pixel value (1 or 0), each pixel would be driven either with a positive voltage or a negative voltage. A global counter can be used to count the frames elapsed and stop driving the pixels after a predefined period of time (for example, 100ms). Two framebuffers are typically used for determining if the pixel has changed color or not. If not, then the pixel does not need to be driven.

Advantages and Disadvantages

In terms of display quality, EPDs are no match for modern IPS LCDs. The following is a comparison table of key parameters. The specific number would vary depending on the screen used but should be within the same ballpark.

Monochrome EPD CFA-based Color EPD Transmissive TFT IPS LCD Reflective TFT TN LCD
Contrast Ratio ~17:1 ~14:1 ~1000:1 ~14:1
Colors 16 (Greyscale) 4096 16M 256
Color Gamut N/A ~1.5% sRGB ~99.9% sRGB N/A
Reflectivity ~45% ~25% N/A ~15%
Response Time ~150ms ~150ms ~10ms ~15ms

It has a few advantages. It reflects lights instead of emitting lights, so it generally consumes less power and can be used outdoors, etc. It’s also bistable, which means that it retains the image after the power has been removed. Personally, the biggest differentiating factor for me (author of this README) is that it looks like paper.

rlcd-vs-eink

The image above shows a comparison between reflective TFT LCD (SHARP memory LCD in this case) and Eink. The LCD has a mirror-like texture which changes reflectivity drastically in different angles, while the Eink is more paper-like.

ZBD LCD Ch LCD STN LCD
zbd chlcd stnlcd
Bistable, reflective, high contrast, no greyscale, ~10s refresh Bistable, reflective, lower contrast, up to 32 level greyscale, ~5s refresh Volatile, reflective, lower contrast, up to 32 level greyscale, ~100ms response

There are many other reflective or bistable display technologies. They are all interesting displays on their own, but none of them feels like paper (yet).

Overall, there is no single perfect display technology. Each has its own unique strength. Pick the right one for your project.

The Role of Eink Controller

The Eink controller is in some ways similar to the display controller (DC/ CRTC) + timing controller (TCON) in a typical LCD-based system. It takes the raw image data and converts it to signals required to drive the screen.

eink-controller

To understand the actual work of an eink controller, start from the basic concept. The color of a pixel can be changed by applying positive or negative voltage for a finite period of time. From the controller’s perspective, depending on the current state of the pixel and the desired state of the pixel, there are 4 possibilities.

Current State Target State Action
Black Black No operation
Black White Apply positive voltage
White Black Apply negative voltage
White White No operation

The controller needs to store and maintain the screen state inside of its own buffer memory, so it would typically have a large on-chip SRAM or an off-chip SDRAM controller. The controller should also have a timer to ensure the screen doesn't get overdriven or underdriven.

The controller often uses the so-called "waveform" to replace the action column of the previous table. Instead of hardcoding the action for state transition, the actions are stored into a look-up-table (LUT) which can be modified at runtime to allow higher flexibility.

Controllers may also offer more advanced features such as dithering acceleration, multiple region updates, automatic LUT selection, etc.

Screen Panel Types

As discussed in the previous section, an Eink screen needs to be coupled to an Eink controller to function. Aside from that, the screen also needs high-voltage drivers to drive the TFTs and the pixels. Virtually all E-paper panels use either COG (Chip-on-Glass) or TAB (Tape Auto Bonding) to integrate some chips onto the screen panel itself. Most of the screens available today can be divided into two categories based on whether or not the controller is integrated in:

screen-types

Here is a non-exhaustive list of the types based on their size: (the size or resolution is not related to or limited by the type, it is just for a certain size, and the vendors tend to make them the same type.)

  • Screens without controller: 4.3", 6.0", 7.8", 8.0", 9.7", 10.3", 13.3", 25.3", 31.2", 42"
  • Screens with controller: 1.02", 1.54", 2.13", 2.6", 2.9", 3.71", 4.2", 5.65", 5.83", 7.5", 12.48"

One may notice that almost all e-readers/ e-ink cellphones use screens without controllers, while almost all e-ink electronic shelf labels (ESL) use screens with controllers. This gives some hints about the advantages and disadvantages of two types:

Without Controller With Controller
System Cost High. A dedicated controller or SoC with an integrated controller is usually required. Needs a dedicated power supply. Low. Virtually any MCU could drive the screen directly, and the power supply is integrated in.
Greyscale Levels Generally 16 (4bpp), up to 32 (5bpp) Generally 2 (BW only) or 4 (2bpp), with some hack, up to 16 (4bpp)
Refresh Speed Generally fast (100ms~300ms) for BW. Depends on the screen used and the system architecture Generally fast (100ms~300ms) for BW if the partial refresh is enabled. Greyscales are much slower, BWR or BWY screens would be even slower.
Total Update Latency Generally the same as refresh time. Depends on the system architecture Slow. Ranging from 100ms to several seconds based on the resolution.

Please keep in mind the discussion is about off-the-shelf screens you can buy today. These tradeoffs do not necessarily come from the fact the controller is integrated or not.

Note that I mentioned the refresh speed and total update latency. They are different:

The refresh speed refers to the time it takes to start refreshing the screen: from starting to seeing screen changing, to the screen finish showing the new content.

The total update latency refers to the latency when the processor needs to update the screen, to the screen finish showing the new content. As you can see, this is the biggest issue for screens with controllers. This is the main reason why they are rarely used on e-readers cell phones or PC monitors.

screen-controller-diagram

This diagram illu

Core symbols most depended-on inside this repo

Shape

Function 4,903
Class 142
Enum 40
Method 28

Languages

C++53%
C46%
Python1%

Modules by API surface

fw/Drivers/STM32H7xx_HAL_Driver/Inc/stm32h7xx_ll_rcc.h323 symbols
fw/Drivers/STM32H7xx_HAL_Driver/Inc/stm32h7xx_ll_spi.h217 symbols
fw/Drivers/STM32H7xx_HAL_Driver/Inc/stm32h7xx_ll_adc.h206 symbols
fw/Drivers/STM32H7xx_HAL_Driver/Inc/stm32h7xx_ll_bus.h157 symbols
fw/Drivers/STM32H7xx_HAL_Driver/Inc/stm32h7xx_ll_pwr.h148 symbols
fw/Drivers/STM32H7xx_HAL_Driver/Inc/stm32h7xx_ll_dma.h147 symbols
fw/Drivers/STM32H7xx_HAL_Driver/Inc/stm32h7xx_ll_system.h138 symbols
fw/Drivers/CMSIS/Include/cmsis_gcc.h137 symbols
fw/Drivers/STM32H7xx_HAL_Driver/Inc/stm32h7xx_ll_i2c.h134 symbols
fw/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_tim.c124 symbols
fw/User/usbpd/usb_pd_protocol.c111 symbols
fw/Drivers/CMSIS/Include/cmsis_armclang_ltm.h110 symbols

For agents

$ claude mcp add Glider \
  -- python -m otcore.mcp_server <graph>

⬇ download graph artifact

Ask about this repo answers extend the page