Parallel RGB LCD Timing from Datasheet Values to Verified Signals

A parallel RGB configuration can have the correct pixel clock and still place the active image incorrectly. It can also reproduce the intended line and frame periods while presenting data on the wrong sampling edge. Treat interval counts, control-signal interpretation, and data capture as separate checks before changing more timing fields.

This guide is for engineers configuring progressive parallel RGB with one complete pixel transferred per clock. It focuses on converting datasheet timing into the host’s actual representation and checking the resulting signals. Serial RGB, command-oriented 8080 interfaces, interlaced timing, and protocol bridges with different transfer relationships need their own models.

Start with the mismatch you can observe

Use the observed discrepancy to choose the next check. The table below narrows the investigation; none of its observations proves a single cause. Establish the correct power, pinout, mode selection, and startup requirements for the actual assembly before probing or attempting configuration changes.

Begin with the row that matches available evidence. If nothing has been measured yet, build a timing worksheet before interpreting the visible symptom. A register name, a configuration file, and a measured interval can describe different representations of the same signal.

Separate panel mode from the raster generated by the host

DE and synchronization signals do not have one universal combination of required and unused pins. Establish the selected input mode from the panel documentation, then determine how the host must generate the associated raster. Avoid treating a software example’s omitted property as permission to leave a physical input undefined.

DE mode does not remove the need to understand blanking

In a DE-oriented input mode, the valid-data window identifies the pixels the panel should accept. The host may still require complete line and frame counts to generate those windows. A panel’s treatment of HSYNC and VSYNC therefore does not, by itself, determine whether the controller needs sync-width or porch fields.

For the exact mode, record which signals locate the active image, how mode selection is established, and the required state of inputs that are not used for synchronization. If the datasheet is ambiguous about a pin, obtain clarification before wiring it or deriving a configuration from a different module’s example.

A synchronization-oriented mode instead uses the specified line and frame reference relationships to place the raster. DE may still be part of that contract. The useful distinction is what the selected receiver does with each signal, not whether the connector happens to label a pin HSYNC.

Check the panel side of an intervening board

When a controller or scaler sits between the host source and the LCD, inspect the timing delivered to the panel. The source’s reported resolution or refresh rate can describe an earlier point in the path. KadiDisplay’s LCD controller board architecture guide explains why source-facing descriptors and panel-output configuration need separate review.

For a native parallel connection, keep the worksheet tied to the exact host, panel, cable, and software revision. For an intervening board, add its output profile and firmware. This identifies where a value is applied and prevents a source-mode change from being mistaken for a direct change to the raw-panel raster.

Translate intervals into the representation the host accepts

Choose an origin and write it down. The convention below begins a line at the start of the horizontal sync interval, then follows sync, back porch, active pixels, and front porch. The analogous vertical intervals are counted in lines. This is a counting convention, not a required electrical polarity.

Keep interval lengths and cumulative boundaries distinct

Let S be sync length, B back porch, A active length, and F front porch. These symbols describe one axis at a time. Horizontal quantities are pixel-clock periods; vertical quantities are lines. The total is S + B + A + F.

A boundary measured from the start of sync has a different value from the interval immediately before it. The active window begins at S + B and ends at S + B + A. If an API requests B, supplying S + B moves the intended window. Conversely, an accumulated-boundary field cannot be populated with the porch length alone.

Here the leading H or V identifies the axis, and the second letter retains the interval meaning. Treat each boundary as a coordinate; the active interval is start-inclusive and end-exclusive in this worksheet. Datasheets or controllers using another origin must be translated before their values are compared.

The figure separates interval lengths from the positions derived by adding them. No signal polarity is needed to understand that distinction.

Decode stored fields before judging their values

A controller may store a length, a cumulative position, or one of those values with an encoding offset. Read both the API definition and the register description where applicable. A driver can already apply an offset, making a second correction by its caller incorrect.

For a compact illustration only, take horizontal intervals 40, 88, 800, and 40. Their cumulative boundaries are 40, 128, 928, and 968. If a hypothetical field stores each boundary minus one, the stored numbers become 39, 127, 927, and 967. These are arithmetic examples, not settings for a named panel or controller.

Reverse the process before hardware evaluation: decode the stored values back to boundaries, then subtract adjacent boundaries. In this illustration, 128 minus 40 recovers the 88-clock back porch, and 928 minus 128 recovers the 800-clock active interval. A failure to recover the original intervals identifies a representation error without needing to guess from the image.

Build a reversible timing worksheet

Keep five columns for each parameter: panel interval, chosen coordinate convention, API or driver field, encoded register value, and decoded running value. Add units beside every column. The worksheet should reproduce the original sync, porch, and active lengths when decoded in reverse; if it cannot, stop before testing another offset.

Record minimum, typical, and maximum values only where the datasheet defines how combinations may be chosen. A range in one row is not permission to combine every minimum or maximum independently. Keep notes for relationships such as total, refresh, clock range, polarity, DE mode, and startup timing. Mark any value inferred from an example separately from a specified limit.

When software layers transform the same field more than once, identify ownership. A board file may supply a length, a driver may convert it to a boundary, and a hardware abstraction may subtract one before writing the register. Trace the deployed path or read back the final value; duplicating the documented conversion in two layers creates a configuration that can look plausibly close while being one interval wrong.

Map Linux properties within their documented scope

إن Linux panel-timing binding uses separate active dimensions, porch lengths, sync lengths, and a clock in hertz. Its hback-porch value represents HB, not HS + HB. The hactive and vactive fields represent visible dimensions rather than total raster counts.

That mapping does not provide a complete Device Tree configuration. The applicable panel binding, driver, and kernel or vendor BSP determine how the timing is supplied and which fields are used. Check the source matching the running software; do not assume that a property copied from another platform is recognized or that the requested value reached the hardware.

Calculate the clock and check the achievable raster

For progressive timing with one pixel per clock, the reusable relationships are:

Pixel clock = HT × VT × frame refresh rate.

Line rate = pixel clock ÷ HT. Frame refresh rate = pixel clock ÷ (HT × VT).

Use hertz for the clock and refresh rate; HT is clocks per line and VT is lines per frame. The active dimensions alone exclude the blanking periods. This follows from counting every clock in every line, regardless of whether that clock transfers a visible pixel.

Solve the timing limits together

Take the clock and each interval’s permitted values from the actual panel documentation, then check what the host can produce. A requested clock can differ from the achieved clock because of the available source and divider configuration. Recompute the resulting line and frame rates from the achieved value before evaluating acceptance.

The short horizontal illustration above would have HT = 968. If an illustrative vertical total were 517 and the target were 60 Hz, the calculated clock would be 30,027,360 Hz. With the same totals and an actual clock of exactly 30,000,000 Hz, refresh would instead be approximately 59.9453 Hz. This demonstrates the calculation only; neither number establishes compatibility with a real display.

Carry one candidate from datasheet intervals to predicted signals

For a project worksheet, enter horizontal and vertical intervals exactly as named by the panel documentation. Sum them to obtain HT and VT, then calculate the requested clock from the target refresh. Next, replace the requested clock with the host’s achievable clock and recalculate line rate, frame rate, line period, frame period, active DE width, and active-frame time.

Translate the same intervals into the controller’s field representation. If the controller stores cumulative boundaries, add the intervals from the chosen origin. If it stores minus-one counts, apply that encoding once at the documented layer. Decode the final register or driver state back to intervals and compare it with the worksheet before connecting the conclusion to the display.

Finally, write the expected observations beside the candidate: clock frequency, line frequency, frame frequency, DE pulse width, number of active lines, polarity or active-edge relationships, and test pattern geometry. This turns bring-up into comparisons with predictions. A disagreement identifies whether to revisit arithmetic, encoding, running configuration, or the physical signal rather than inviting another arbitrary porch edit.

Do not change a porch just to recover a round refresh rate without checking the permitted interval range. A frame rate within limits does not independently approve an out-of-range sync width, and individually permitted values may still need to satisfy documented relationships. Keep the chosen tuple of values together rather than selecting attractive minima or maxima independently.

Predict what the instruments should see

From the accepted candidate configuration, calculate the expected line period HT divided by pixel clock and frame period HT times VT divided by pixel clock. For an active horizontal interval HA, predict its duration as HA divided by pixel clock. These give independent comparisons for frequency, total length, and active-window width.

Use the relevant boundaries for the selected mode. A correct line period does not establish the active-window position, and a correct DE pulse width does not establish the number of active lines. Comparing several linked quantities is more informative than treating a single displayed frequency as proof that the whole timing is right.

A reversible trace should end where the hardware can be observed, then run backward to the same panel interval definitions. This makes an offset, unit or ownership error visible without guessing from the displayed image.

Check data capture at the panel connection

Once the raster counts agree, check when the receiving panel samples data and when the host changes it. Do not infer either action solely from a setting named positive, negative, or active clock. Such names can describe launch behavior, capture behavior, or an inversion within a particular implementation.

Match the launch and capture definitions

NXP’s AN4588 pixel-timing discussion, revision 0, section 3.2.2.3, illustrates why the receiver’s capture edge must be read explicitly: its examples discuss different latching-edge relationships. Those examples do not establish one universal edge for parallel RGB panels.

In the Linux binding, pixelclk-active describes driving and sampling behavior: value 0 specifies driving data on the falling edge and sampling on the rising edge; value 1 specifies the reverse. Interpret that definition alongside the actual driver and hardware behavior. Do not transfer the same numerical setting to another platform without checking its meaning.

Evaluate stability around the receiver edge

The required setup and hold intervals come from the exact receiver specification, while host output behavior and the assembled connection determine when valid data reaches it. Cable delay, clock-to-data skew, loading, and waveform quality can affect the relationship at the panel even when the programmed frequency is correct.

The diagram illustrates the relationship to examine, without inventing timing margins. It is not a measured trace.

Measure at a location appropriate to the question with probes, bandwidth, and grounding suitable for the bus. A frequency counter can establish clock rate but cannot establish data-to-clock setup and hold. Preserve the measurement reference and acknowledge uncertainty; a low-resolution trace is not evidence of adequate margin.

Verify the running configuration with controlled changes

Use a repeatable comparison between intended values, running state, and observed signals. Keep a recoverable known configuration, and change one relevant condition at a time. This separates a correction from an accidental combination that happens to produce an image.

Read back before editing another timing field

Check the active panel profile, clock source and divider, dimensions, decoded interval values, polarities, and output-enable state. If the running driver does not expose a value, identify another supported way to verify it or retain it as an unresolved item. The presence of a correct value in a source file does not demonstrate that the deployed configuration uses it.

When line rate is correct but frame rate is wrong, recheck vertical counts and how the instrument identifies a frame. When both rates agree but the picture is displaced, inspect active-window placement and count semantics. These are discriminating next checks, not automatic diagnoses.

Compare observation points on both sides of the controller

A software mode report describes the requested or accepted configuration, while a controller register shows the programmed representation and the panel pins show the delivered waveform. With a bridge, scaler, or serializer in between, each side can use a different timing. Label every capture by its physical node and clock domain so a correct source mode is not presented as proof of a correct panel raster.

Start with low-risk measurements: exposed test points, controller counters, status registers, or a supported debug interface. If physical probing is required, use equipment and access appropriate to the bus and assembly. Probe capacitance, ground inductance, bandwidth, and reference location can distort an edge or load a marginal link. Preserve the probe setup and uncertainty with the trace.

Cross-check linked quantities. From a measured pixel clock and horizontal total, predict line rate; from line rate and vertical total, predict frame rate. Measure DE width and compare it with active pixels divided by pixel clock. Agreement among independent observations provides stronger evidence than a single instrument’s automatically decoded label.

Use patterns that separate geometry from data behavior

A border and grid make cropping, missing lines, and displacement easier to observe. Full red, green, and blue fields support review of channel mapping; gradients help reveal unexpected quantization. Save the pattern definition alongside the configuration so observations remain comparable after a software change.

If corruption follows graphics or memory load while the raster remains stable, move to the data-supply branch. Espressif’s ESP32-S3 RGB LCD documentation describes platform-specific buffering and starvation considerations. Use the documentation matching the deployed ESP-IDF version; those mechanisms are not a universal diagnosis for all controllers.

A replacement panel also needs review beyond timing. The industrial LCD replacement checklist helps keep mechanical, power, interconnect, and software differences in the same integration assessment.

Questions beyond the timing worksheet

Does RGB565 in software mean the panel uses a 16 bit bus

Not necessarily. The framebuffer storage format and the physical output format are separate parts of the host pipeline. Determine whether and how the particular controller converts or maps stored pixels onto its data pins, then check the panel connection. A software format name does not identify the connector wiring or prove that the expected color bits reach the receiver. Use the host’s supported format and output-mapping documentation for the actual configuration.

Does a 60 Hz raster mean the application generates 60 new frames each second

No. The raster describes how the interface scans; rendering and buffer presentation determine when image content changes. A controller can scan unchanged data again. Measure application rendering and presentation behavior separately from pixel-clock and sync timing. If updates appear inconsistent, inspect the platform’s buffer ownership and synchronization behavior rather than assuming a porch adjustment will increase application throughput.

Timing Calculation and Register Mapping Basis

• Linux panel-timing binding — interval properties and driving/sampling-edge semantics; check the applicable kernel and driver.
• NXP AN4588 — revision 0, September 2012, section 3.2.2.3 on pixel capture timing; examples are platform-specific.
• NXP AN12302 — revision 0, December 2018, eLCDIF RGB operation and configuration context.
• ESP-IDF RGB LCD programming guide — ESP32-S3 output and buffer operation; select the project version.

Preserve the timing evidence for the next configuration

A useful timing record connects the original interval definitions to encoded settings, decoded running values, and observations at the relevant interface. Keep those relationships together with the exact panel, host, cable, and software identity. Repeat the relevant checks after supported startup, recovery, or configuration changes so the result can be reproduced rather than remembered as a working image.

If a remaining mismatch needs supplier review, send that timing record, the applicable datasheet revisions, and a controlled description of the symptom through KadiDisplay technical project contact. This gives the discussion a specific interface and evidence boundary.