We have a solution for graphic color LCD's (resolution up to 800×600) right now that we are not very happy with: Our ARM Cortex M3 drives the LCD over a 8080 bus and the LCD module must provide the LCD driver (currently SSD1963). This solution was recommended to us by consultants who's priority was optimizing the cost of the processor module. The problem with this is that it pretty much ties us up to one LCD vendor and even only a subset of that vendors displays. The 8080 bus is standard but the cabling (tail) to the LCD module seems to vary slightly from vendor to vendor. The signals is not always on the same pins etc. Another problem is that LCD displays seems to have a very limited market lifetime, I heard less than a year in some cases.
Now, we have chance to redesign the processor module and I want to do this RIGHT this time. I'm looking for a solution that is:
- Cheap both on the processor board and the LCD module
- Vendor agnostic
- Somewhat future proof
Various solutions have been suggested:
- Integrate the LCD driver on the processor board: Would this really help us become more vendior agnostic?
- Integrate an FPGA (programmed as a display driver) on the processor board and reprogram it when we need to switch LCD vendor: Sounds cool but somewhat backwards, surely there is a standard solution to the problem?
- Integrate an LCD driver on the processor that speaks DVI or HDMI to the LCD module: I like this because of the standards, but it sounds like both processor board and display module becomes MUCH more expensive
What do you guys think? Is there a standard way to do this that I have missed?
Best Answer
There are several different interfaces, but I recommend you implement the same solution as is used in laptops; LVDS, if I recall correctly. The interface is fairly standard, but the pin-out may vary. In theory, any GPU can interface with any panel, with a few exceptions. There's also the cost benefit; if you stick with the same panels laptop manufacturers use you can also benefit from economies of scale.