Do display modules make sense?

4 mins read

Never before have embedded project specifications been more directly influenced by consumer experience. The attractiveness of the smartphone with its nifty, gesture based interface has translated directly to the desirability of a similar class of HMI on a wide universe of industrial, medical and other embedded products. At the same time, just as we are personally connected to the internet in many ways, we now have a parallel Internet of Things for the billions of embedded computers around us.

All of this means the most commonly specified incremental features for any embedded project being started today are a touchscreen based user interface and a modem. These requirements are sweeping away the simple 8 and 16bit systems which performed control and interface tasks in previous product generations. These are being replaced by solutions built around powerful processors running sophisticated operating systems (OS) capable of driving the displays and providing the communications services now needed, while offering the higher levels of abstraction needed to program such systems. Some of these needs are met by embedded PCs and the usually large and expensive panel PCs which represent the mechanical bundling of PC and a display. Starting with an ARM processor Embedded projects most frequently employ an ARM based system, often running Linux, sometimes Windows CE, maybe Android or, on occasions, a commercial RTOS. The ARM based SoC processors capable of running this class of OS must possess a memory management unit and so, in terms of ARM's legacy product families, this means at least an ARM9. In terms of current nomenclature, ARM Cortex-R or –A series processors are needed. ARM Cortex-A series based devices are, by a good margin, the most commonly used processor type in design starts with touchscreen applications, although ARM9 equipped SoCs are still quite popular. ARM Cortex-A is the processor core family responsible for the smartphone and tablet revolution, so embedded SoCs based on these cores not only incorporate high performance, integrated display controllers, but are also the ones to provide OpenGL capable graphics acceleration. Support for OpenGL ES and equivalent standards is the foundation for nearly all modern GUI paradigms which feature touch and gesture control and animation. What display? For some years, resistive touchscreens were the mainstay of embedded projects. Requiring physical pressure, they provided positivity and gloved hand friendliness and were generally inexpensive. Again, in this area, it is the smartphone that has moved the goalposts for embedded projects. Projected capacitive touchscreens are now the standard, offering multitouch and gesture, gloved hand support and affording extreme durability when we choose to put them behind specially designed protective materials, such as Corning's Gorilla Glass. High brightness, transreflective TFT displays, used with capacitive touch, have become the benchmark for embedded projects. As a result, many display manufacturers have made life easier for the developer by fusing the touch screen and LCD into a single assembly. This helps in obvious ways, both from an electronic and mechanical design perspective, and has become the standard approach. Unfortunately, the world of LCDs is still not particularly friendly to the embedded developer. Manufacture of these displays is concentrated in Taiwan and China, in companies whose focus is very much on consumer smartphones and tablets. This means that, while it is usually possible to source a display very cheaply, you will often find there is an unfeasibly high minimum order quantity or – worse still – that the product is discontinued after a few months. A lack of manageable longevity of supply in displays is one of the main challenges faced by embedded developers seeking to use touchscreens in their projects. Another problem encountered when designing in a touchscreen display is the lack of standardisation of connectors – even similar screens from the same manufacturer usually feature different physical plugs and cables. Compounding this, touchscreen data, while usually transmitted over an I2C bus, does not benefit from a standard protocol, meaning that a software driver must often be written for each screen. Putting display and processor together When selecting a display and touchscreen, it might be tempting to look for a solution which also has an embedded system bonded to the back and conclude 'the job is done'. While this might indeed prove to be the right solution, this is the wrong way to approach it. For an embedded system, being able to support a particular display and touchscreen is unlikely to form more than 10% of the relevant system specification. Which operating system? Which version of OS? How much processing power? What graphics acceleration? What video pipeline? Ethernet? USB? Modem? Wi-Fi? GPIO? Power consumption? These considerations are probably as important, if not more, and putting the choice of display, or display module, ahead of these will – at best – result in a solution which is a poor compromise. Systems using old processors and OS versions are obviously to be avoided. But display modules comprising LCD, capacitive touch screens and truly current ARM based embedded systems are gradually appearing in the market. Accepting that choice of processor and OS should be at the forefront, are these solutions worthwhile? What are the advantages and disadvantages of using these display modules? Some pros and cons are listed in Table 1. A good display module choice should make a good fist of harnessing the advantages, while offering innovative approaches to the need to mitigate the disadvantages. For example, if the project is Linux based – like the majority of touch screen embedded developments – it makes sense to choose a solution supporting current, mainline Linux (3.16 at the time of writing), rather than some frozen in time old version which will never support new middleware or applications. It is important that the processor has OpenGL graphics acceleration in hardware and demonstrates support for X11, Qt or other GUI systems. Restriction of processor choice and of available interfaces is, perhaps, the biggest potential disadvantage of choosing a display module. However, innovative workarounds exist. Direct Insight's TRITON-TXCT display module, for example, is powered by a range of tiny pin compatible system on modules, so that there is a wide choice of processors available. In addition, tiny daughterboards, or 'ears', are built into the structure and can be customised to adjust the build up of interfaces, adding such capabilities as Bluetooth and modems as required. Inevitably each project will be different, and the advantages of the more modular approach must be weighed. Hopefully the ideas raised in this article will aid that process. Advantages of display modules • Mechanical design. Easy to mount in front panel of device. No wiring to separate computer • Longevity. Displays have a short lifetime, but this now becomes the display module vendor's problem and we can look to them for guarantees • Regulatory. Some modules are pre-tested assemblies and are CE marked. Could save on EMI testing for approval Disadvantages of display modules • Restriction of choice of best embedded system for the job • Increased cost. Commercially does not scale so well to larger volumes • Lack of future flexibility. What if system requirements, or display requirements evolve? David Pashley is managing director of Direct Insight.