What the Display Controller Does: Storage, Timing, Conversion

A display controller performs three jobs:

• Storage — it holds the image data the host has written, usually in a memory block called GRAM (graphics RAM).
• Timing — it generates the signals that scan the panel line by line at the panel’s refresh rate, independent of when the host writes.
• Conversion — it translates the host’s interface (SPI, RGB, MIPI, and so on) into the panel’s internal data path.

Because the controller refreshes from its own memory and timing, the host does not need to stream pixels continuously for every panel type. That separation between host writes and panel refresh is the core idea behind buffered displays.

GRAM and Frame Buffers: Sizing the Image Memory

GRAM holds the current frame that the panel scans out. Sizing it is arithmetic:

GRAM size ≈ active pixels × bits per pixel

• An 800×480 panel at 24 bits per pixel needs about 800 × 480 × 3 bytes ≈ 1.15 MB of image memory.
• Smaller color depths or lower resolutions shrink the requirement; some controllers use one GRAM per color channel.
• Controllers with no GRAM use direct-drive architectures where the host must keep feeding pixels—the RGB parallel case, covered in the RGB interface guide.

GRAM size also affects partial updates: with the full frame in memory, the host can rewrite only a region and let the controller refresh the rest from the unchanged memory.

Refresh and Flicker: Frame Rate and Dimming

The controller refreshes the panel continuously, typically at 60 Hz or another rate set by its timing registers. Refresh serves two purposes: it keeps the image from fading (liquid crystal pixels hold charge only briefly) and it sets the frame rate the user perceives. When people talk about “flicker” in a display, the cause is usually not the refresh itself but how the backlight is dimmed: pulse-width modulation at low frequency reads as flicker. That mechanism belongs to the backlight dimming topic, not to the controller’s refresh logic. Timing-related tearing or rolling, by contrast, comes from a mismatch between the host’s writes and the panel’s refresh—which is what TE (tearing effect) sync signals exist to prevent: the panel signals the host when a frame boundary is safe to write.

Timing Parameters: Why They Live in the Controller

Timing parameters—pixel clock, blanking, porch values, and sync polarity—are stored and generated inside the controller because the controller is what turns a stream of data into correctly scanned lines. The host provides data and a clock; the controller’s registers define how many pixels per line, how many lines per frame, and where the sync pulses sit. Two consequences follow:

• Misconfigured timing registers produce the shifted or rolling images that a display timing guide helps you debug.
• Interface choice changes where timing is generated: a direct-drive RGB panel relies on the host’s timing source, while a GRAM-based controller owns the scan timing internally.

Understanding the parameter definitions is a separate, dedicated topic; this article explains why those parameters are the controller’s responsibility.

Interface Conversion Inside the Controller: RGB, SPI and MIPI Bridge Mechanisms

Controllers often accept one host interface and drive the panel with another. The conversion happens inside the controller:

• SPI in, panel out — the controller receives pixels over SPI, stores them in GRAM, and scans the panel from GRAM.
• RGB in, GRAM out — some controllers buffer a parallel RGB stream into memory and then scan it out, letting a host with a parallel output drive a panel that expects a different internal format.
• MIPI or LVDS bridging — bridge functions convert between serial interfaces inside the controller or a companion chip, letting a MIPI-only host drive an LVDS panel or the reverse.

Whether to use a bridge at all—and which interface to choose for your product—is the interface selection decision, covered in the LVDS vs MIPI guide and the individual interface articles. Here, the point is that conversion is an internal mechanism with its own latency and cost; it does not make interfaces freely interchangeable.

Common Controller Families: ILI, ST, and EK

Small TFTs are commonly built around controller families such as ILI, ST, and EK parts. In practice, the family matters for three reasons:

• Command sets — initialization sequences and register maps differ between families, so driver code is not portable without changes.
• Documentation and community support — popular families have abundant examples, which shortens bring-up.
• Availability — controller supply changes over time; a family with multiple vendors is easier to second-source.

The exact part number and its datasheet define what the panel supports; the family only tells you which documentation ecosystem you are in.

Frequently Asked Questions