Designing a product means making a series of architectural and implementation trade-offs about the functionality it should have, how that functionality should be achieved, and where the work of achieving it should be done.
For example, an IoT product could be architected to work as a simple data-gathering device that passes raw information back to a cloud-based computing system for analysis, or as a highly functional network node that handles data processing locally and only passes the results of its analysis back to the cloud host. The first approach might work best where the battery life of the IoT device was the key constraint, the second where the constraint was network bandwidth instead.
Adding a display to a product design seems like a simple enough task, but designers still have to make these sorts of trade-offs to do so successfully. What sort of display do I need? Should it have a touchscreen? What kind of interface do I want to use to connect to it? How should the display be controlled: by an off-board controller acting over a relatively high-bandwidth interface, or by an integrated controller that can be instructed over a lower-bandwidth link?
Some simple displays can be driven directly by a microcontroller, usually over parallel or serial interfaces. Parallel interfaces may be simpler to drive, because there’s less need to repack the display data-stream than would be necessary to fit it onto a narrow serial bus. The cost of using this approach, though, is that it absorbs a lot of I/Os and so may demand a slightly more capable (and expensive) microcontroller than the use of a serial interface strategy.
For example, the Riverdi 5in TFT LCD panel (RVT50AQTNWN000) has a resolution of 800 x 480pixel. This version of the panel has an RGB interface to a host microcontroller, with an 8bit-wide data bus for each of R, G and B, enabling 24bit colour depth at each pixel for a choice of 16.7 million colours. The interface also demands a dot clock signal from the host, as well as a data-enable and horizontal and vertical sync signals. In other words, the host is called on to do a lot of the work of delivering the data and its related timing signals to drive the display.
The Riverdi 7in TFT LCD panel (the RVT70AQSFWC36) demonstrates a different approach to connecting with a host. This variant of panel is available with a 16bit parallel data interface modelled on the way the venerable 8080 interfaces with devices, so it has a chip select signal, read and write signals, and supports up to a 16bit-wide parallel data bus. Signals on this data bus are not dedicated to specific R, G and B data. Instead the physical bus width can be implemented as 8, 9, 12 or 16bit wide. Different packings of the RGB data for the implemented bus width then enable, for example, up to 24bit colour support over an 8bit bus by sending 8bit R, G and B data in three successive bus writes.
The panel is also available with a choice of display controllers, the [The touch overlay is accessed through an I2C bus.] The SSD1963 display controller has a 1215Kbyte frame buffer so it can support up to 864 x 480 x 24bit graphics. The controller also supports programmable brightness, contrast and saturation control, and can offer dynamic backlight control using a PWM signal. Four GPIO pins provide for a built-in clock generator, deep-sleep mode for power saving, and separate power supply inputs for the core and the interfaces.
Each of these approaches represents a slightly different partitioning of the work of connecting to and controlling a display. The choice you make will depend on how the display will be used in the end application, the cost constraints for your design, whether the interface needs to be protected against electromagnetic interference (some panels are available with LVDS interfaces to tackle this), and the facilities of the host microcontroller. Making the right choice will mean making the right trade-offs for your application and its operating environment.