Order a TFT panel from a distributor and the box that arrives contains glass, two polarizers, a flex tail, and almost nothing else. No backlight. No connector you can plug into anything. No firmware. No document explaining what the forty pads on that FPC are for. What you bought is a light valve — a sheet of liquid crystal that can rotate polarization pixel by pixel — not a display.
The distance between that sheet of glass and the thing your product ships is the entire difference between a bare panel and a display module. It is also where a surprising number of hardware teams lose a quarter of a year.
The parts that are not in the box
A working display needs a source driver and gate drivers bonded to the glass (chip-on-glass), a timing controller to translate your pixel stream into panel-native signalling, a backlight with a constant-current boost driver, and — usually — a touch sensor with its own controller and an optical bond. Add a bezel, a bracket, a grounded shield, a stiffener behind the FPC, and a connector rated for the vibration of whatever the product rides on.
Then add the invisible part: initialization. A typical TFT needs a few hundred register writes before it shows a correct image — power rails in the right order, gamma curves, VCOM, porch timings, inversion scheme. The datasheet gives you a table and a promise that it works at 25 °C on the vendor's evaluation board.
The interface becomes your design decision
With a panel, the bus is not chosen for you. A small 320×240 part may take SPI at a few megabits. A 5-inch 800×480 panel usually wants 24-bit RGB parallel — 24 data lines plus PCLK, HSYNC, VSYNC and DE — or MIPI DSI. Do the arithmetic before you commit: 800 × 480 × 3 bytes × 60 frames is about 69 MB/s of continuous pixel traffic. That is not a bit-banged GPIO problem; it is an LTDC peripheral, an external SDRAM, and a memory bandwidth budget you now have to defend in every design review.
The same bus is also your EMC problem. A 24-bit RGB interface clocking at 33 MHz turns the FPC into an antenna. You will learn about series termination, ground stitching, spread-spectrum, and the real cost of a shielded flex — usually after the first pre-compliance scan.
Bring-up is a firmware project wearing a wiring-project costume
Power sequencing alone can hold you for a week:
Skip one delay and you get a white screen, a scrambled image, or a panel that behaves perfectly on your bench and fails at −10 °C. Then comes the optical tuning nobody schedules: flicker against VCOM, gamma against the tint of your enclosure, brightness uniformity against the backlight you picked.
What the module actually removes
A display module is that entire stack, pre-integrated and pre-tested: panel, driver, backlight, touch, controller, connector, firmware, and — on the better ones — a documented command set you talk to over UART, RS232, or USB instead of a pixel bus.
You stop owning the panel's timing and start owning screens. On our own industrial units we replaced a four-layer board, an external SDRAM, and roughly six weeks of bring-up with a two-wire serial link and a screen editor. The module cost more per unit. It cost far less per shipped product, and the firmware team went back to the features customers actually pay for.
None of that is free. A module arrives with its own constraints: a fixed outline, a menu of sizes and resolutions instead of any size you want, a controller whose quirks you inherit rather than choose, and a feature set gated by the vendor's roadmap. You are trading design freedom for calendar time — a good trade only when your differentiation lives above the glass, not inside it.
The honest decision rule
There is no universally correct answer, and anyone who tells you otherwise is selling something. But the failure mode is asymmetric: a panel that arrives without a bring-up plan does not fail cheaply. It fails in week thirty, in front of a customer, with a certification slot already booked and a tooling invoice already paid.
Top comments (0)