Bar type displays are widely used to provide human machine interfaces (HMIs) in a variety of different industry sectors – being highly applicable to use case criteria where there is only limited space available, or where there are budgetary limitations to consider. They also consume markedly less power than squarer displays of the same width. This makes such displays appealing from an energy saving perspective, so battery operated portable equipment will often feature them. In addition, bar type display deployments suit the upgrading of existing equipment designs that are migrating from mechanical buttons and 7-segment displays to more sophisticated HMI arrangements, as no change to the layout is necessary.
Among the numerous places where they are regularly seen is in domestic appliances, smart home controls, sporting equipment, healthcare monitoring systems, digital signage, point of sales (PoS) units, etc. They are also commonly used in vehicles’ digital dashboards. In some cases partitioning is employed, so that several squarer displays dealing with different functional aspects can be accommodated on a single bar.
Though bar type displays offer size, cost and integration advantages, the way that their graphics are rendered is not without its challenges. In the following article we will look at what can be done to address challenges of this kind.
Figure 1: Car dashboard display with 1440 x 540 pixel resolution
Let’s take a typical modern automotive dashboard. The example shown in Figure 1 relies on a 12.3-inch stretched LCD display with 1440 x 540 pixel resolution. Given that the driver needs to be kept informed of all the different parameters relating to the vehicle’s operation (such as speed, RPM, tire pressure, fuel level, oil pressure, navigation data), the display requires real time response plus superior image quality.
The graphic controller devices currently available have difficulty in providing the required pixel clock necessary for certain standard or non-standard LCD panel formats. In our example, the 1440 x 540 resolution panel will require the pixel clock to be set around 50MHz in order to achieve the required 60Hz display refresh rate. Fast response is not just paramount in an automotive context though, in medical equipment or industrial hardware it can be equally important.
A slow boot up period for the display system can be another inconvenience, so this needs to be given consideration. It will take time for the operating system to initiate on the graphics chip and then for the whole first frame to be rendered pixel by pixel on to by display, as all the necessary data will need to read from the flash memory and pass through the frame buffer. This can take several seconds to complete and is not particularly good from a user experience perspective.
It should also be mentioned that some bar type display panels will have non-square pixel dimensions – and this has the potential to be problematic. For example, a 1024 x 600 LCD may have the pixel width to length ratio of 1.05 (not 1.00). In many applications this does not represent a problem, but certain applications (such as ones where circles are being rendered) may require some aspect ratio adjustment to be applied.
The partitioning of the bar type display, so that several different sub-displays are shown, can bring sizeable complications when using a normal graphic controller IC. It will take a lot of software development work, as such graphic controllers rely on a frame based approach. Graphic controller devices are now available that offer an alternative however.
Bridgetek has developed graphic controller technology that can deal with the pixel clock, pixel size and boot up time issues just described, as well as accelerated HMI software development. The new ExtSync block, which has been incorporated into the company’s latest BT817/BT818 series of Embedded Video Engine (EVE) ICs, has a separate clock domain to that of the graphics processing element. As a result, the scan-out units of these EVE devices can output the required pixel clock for optimised operation of the LCD panel. It means that pixel clocks of up to 96MHz can be supported. This translates to up to 1.28Mpixels being refreshed at 60Hz (assuming 20% blanking time).
The EVE line buffer architecture is highly optimised for stretched or bar type LCD displays, with maximum pixels per line up to 2046 pixels. By eliminating the need for a frame buffer and a large flash memory resource, the overall bill of materials costs can be kept relatively low – so it remains in line with any budgetary constraints imposed on the design. With the EVE approach being object based, rather than frame based, it is significantly quicker and easier for HMIs to be constructed. The boot up time is likewise faster (being under 1s). In addition, the BT817/BT818 EVE devices support non-square pixel correction using their horizontal scan-out filter functionality.
Examples of the bar type LCD resolutions that can be supported by the BT817/BT818 include 1920 x 540/480/360, 1440 x 540 and 1280 x 480/400/320. A 1920 x 720 resolution is also possible if the refresh rate is slightly reduced (going down to around 50/55Hz) or the blanking time is lowered (by approximately 13%). The display orientation used can be either landscape or portrait, as applications requirements dictate.
Figure 2: AV control panel with 1200 x 280 pixel resolution
Though these EVE devices can streamline HMI design significantly, they may require a little more engineering effort. When the design features relatively complicated graphical constructions on a high resolution display, it will be advised to optimise the design to avoid potential pipeline underrun occurring. Here are some tips that will help with the fine tuning:
- Set the PCLK to the lowest figure allowed by the display panel, so that the GPU has more processing time per line.
- Increase the horizontal blanking time where possible, and keep the vertical blanking time at minimum allowed by the display panel
- Use of the adaptive Hsync feature will be of great benefit. Through this it is possible to define the maximum horizontal blanking for adaptive Hsync at the maximum PCLK cycles outlined in the display’s specifications.
- Always check visually for graphics distortion, or use the interrupt flag for graphics underrun. If underrun occurs, dump the line time to check which line/area has underrun and then optimise the display list accordingly – for example, use a solid line to replace a dotted line, or use an image instead of multiple widgets overlaid in the same area.
- Use font-cache in RAM_G for Unicode fonts.
- Load ASTC images to RAM_G and play animation from RAM_G
BT817 supports capacitive touch operation, with touch controllers from a wide range of vendors able to work directly with it (with the BT818 being applicable for resistive touch HMIs). For CTP using another touch controller IC, engineers can build customised touch firmware to be loaded to BT817 at runtime, using a C-like compiler provided by Bridgetek’s EVE Asset Builder software package. Alternatively, touch host mode can be used where the microcontroller unit (MCU) reads the touch data from CTP and writes back to BT817 for TAG operation.
Touch calibration, when required, will usually go through 3 point touch calibration procedure at predefined screen locations. Some bar type LCD screens are cut out from a standard LCD glass. For example, a 1200 x 280 LCD is cut out from a 1280 x 800 LCD glass. The default calibration routine won’t work on a stretched LCD. The BT817 is able to leverage a calibration function which allows engineers to define the location of 3 calibration points. This enables window based calibration, which is highly appropriate for bar type LCD implementations.
In conclusion, it is clear that having a graphic controller solution that is optimised for bar type displays will be highly advantageous. Bridgetek’s EVE devices offer this, with the result that HMI implementations on such displays will be quicker to boot up and more responsive, as well as delivering better graphical performance. The BT817/8 can work in conjunction with a wide variety of MCUs as long as an SPI interface is available. Bridgetek provides supporting tool chains, along with sample applications and detailed engineering notes, to help designers to get up and running quickly and to support them throughout the design of their application.