Three routes, and you only need one of them
Interface work starts from one of three positions. Find yours and take the links in that card; the other two will not be useful to you yet.
- 37 engineering articles on this page, each answering one question
- Covering RGB, SPI, LVDS, MIPI DSI, eDP, HDMI, GMSL and touch
- Every article linked at the point where you would need it
Choose the interface
The panel is chosen and the question is which bus carries it: bandwidth, cable length, controller support and how much of the picture you are willing to give up.
- How to select a TFT LCD module interface
- RGB, SPI, MCU, LVDS, MIPI DSI, eDP and HDMI compared
- Selecting by resolution and refresh rate
- Why eDP beats LVDS at 2K and 4K
- eDP at 2K and 4K: bandwidth and design
- LVDS versus MIPI DSI
- MIPI DSI for small and medium displays
- When RGB parallel is still the right answer
- HDMI in embedded applications
- Custom HDMI integration and plug-and-play screens
Drive it and debug it
The interface is wired and the work moves to the controller, the timing and the first power-up, where most designs lose their first two weeks.
- Choosing an MCU to drive a TFT
- Display controllers: GRAM, refresh and timing
- Timing parameters: pixel clock, blanking and sync
- SPI versus I2C for small displays
- SPI versus RGB
- Driving unusual resolutions: timing, EDID and scalers
- Linux DRM/KMS panel integration
- GMSL and FPD-Link for long cable runs
- eDP link training and AUX troubleshooting
Add touch, and keep the signal clean
Touch changes the stack: it adds a sensor layer, a controller, another bus, and a new set of ways for the assembly to fail in the field.
- PCAP versus resistive: the complete comparison
- What 10-point multi-touch actually buys you
- Projected capacitive touch panel design
- How to choose a touch controller
- Touch interfaces: I2C, USB or SPI
- Integrating a touch sensor with a display stack
- Touch through gloves and rain
- Touch calibration
- IK10 vandal-proof glass that still responds
- Custom touch panel manufacturing
When the screen does not come up
A display that works on the bench and fails in the enclosure is almost always one of four things: timing, grounding, ESD or the connector.
Bring-up debugging, in the order that finds faults
No picture, wrong colours, a rolling image and flicker have different causes and a fixed check order. Working through them in sequence is faster than swapping parts, and it leaves a record of what the design actually is.
Grounding is a design decision, not a layout detail
The return path decides the noise floor. A display that behaves in a quiet cabinet and misbehaves next to a drive usually has a grounding problem rather than an interface one.
Touch has its own immunity problem
Capacitive sensing is a measurement of very small charge changes, which makes it a radio receiver you did not design. EMC immunity for touch is specified, not hoped for.
Testing that finds faults, and the connector underneath
A touch test that only checks “does it respond” passes units that fail in the field. And the least glamorous part of the assembly is the one most likely to cause an intermittent fault.
What actually decides whether an interface works
Four things decide the outcome, and none of them is the maximum data rate in the datasheet.
Bandwidth with margin, not bandwidth on paper
A link running at 95 % of its theoretical capacity has no room for the timing tolerance, temperature spread or cable variation of a production build. The headroom you leave at design freeze is what stops a marginal unit reaching the field.
The return path, not just the signal pair
Almost every “interface” fault in a finished product is a grounding or shielding problem. Differential pairs get attention; the return path usually does not, and it is the one that decides whether the picture is stable.
Who owns the timing
Panel timing, controller configuration, EDID and the device tree all describe the same numbers in different places. When they disagree, the symptom looks like hardware and the cause is a settings file.
The touch stack, which is a second product
A touchscreen is a sensor, a controller, a bonding layer and a firmware configuration, and it is specified, qualified and can fail independently of the display underneath it.
Where to go from here
If your question is not really about the interface, one of these is closer to it.
Interface and touch questions
The five questions that arrive most often before a display interface is fixed.
Which interface should I choose for a 10-inch industrial display?
When does eDP become worth the extra design work?
Can I run a display over a long cable?
Why does my touchscreen work in the lab and fail in the field?
Does the touch controller or the sensor decide performance?
Send us your display requirement
Give us the resolution and refresh you need, the controller or processor already on the board, the cable length from board to panel, whether the unit is touch-enabled, and the environment it runs in. With those five we can narrow the interface before you commit to a layout.
Request an interface review