Smart Memory Management In Graphic Display Design
Graphics Memory Management
No matter how a graphics image is generated and delivered to a display there will be a certain amount of memory required. Traditional display content development typically relies on storing an entire image in fast RAM to be transported to the display when required. This may also require double buffering if the display is not static and displays need to be swapped.
If you consider a standard 800 x 600 SVGA display, the largest EVE could support, then a full frame of colour data would be 1 byte * 3 colours * 800 * 600 pixels = 1.44GBytes for a frame of data.
EVE solutions from Bridgetek, on the other hand, rely on storing a line of image data before transferring the data to the display. This is more memory efficient in terms of the displayed image storage as it is drawn on the fly and only a line of data needs to be stored as opposed to a full frame.
However, in both cases, there may be a need to store additional assets such as pictures, logos or icons to build the image, and these may be in the form of bitmaps or compressed bitmaps. EVE devices contain up to 1Mbyte of dedicated memory for storing assets on chip. Whilst this is a generous amount that may be readily accessed when the image rendering requires it, Bridgetek has recognised that more and more designs are becoming increasingly complex in their display ambitions. The flexibility that a true TFT display offers over a fixed segment solution has led to greater design ambitions with more visual elements being added to displays for greater system functionality and hence the need for more icons and images to be stored and deployed.
On-chip and off-chip storage
With EVE generations 1 and 2 (FT80x and FT81x), the devices are SPI peripherals to the main system processor and the only other bus on the device is the RGB graphics bus. As such, any memory download to the devices uses the common system SPI bus which may in some cases be shared with other system functions. This has the potential to impact on the available SPI bandwidth and affect other system features. The third generation devices (BT81x) however have resolved this issue. With a new dedicated flash hosting bus, the BT81x may draw upon assets in on chip memory or off-chip flash without the need to use the main SPI bus or impacting the other system functions that rely on the SPI interface. This also allows for a complete segregation and fixed size of allocated memory for a chosen design as opposed to alternative solutions which may share a larger block of memory across multiple functions as is often used in single chip designs, giving a misleading indicator of just how much graphics memory a system actually has.
Figure 1: EVE System Block Diagram
Supporting the new memory interface in the BT815/6 has required a slightly bigger package (64 pins) to accommodate the extra pins but this is still packaged in a QFN format making it easy to track out on PCB layout and debug. Additionally, there are new API calls specific to accessing the new interface, allowing for erasing, reading and writing to the memory.
The Assets (Bitmaps)
Enhanced memory management within an application is not just limited to the support for extra memory on a dedicated port.
The assets to be displayed may be stored either compressed or uncompressed. Clearly, a compressed image will take up less space and should be considered when selecting how to store an image. The EVE devices will handle the decompression on chip when the image is required. Also worthy of note is that images may be stored in different formats. A very pixelated image in black and white (known as L1 format) will only require 1 bit of data to be stored for every pixel. For an 800 x 600 image that is 480kbits (60 Kbytes), whereas an image with more colour data such as RGB565 will require 5 bits for Red data, 6 bits for Green data and 5 bits for Blue data for every pixel (16 bits per pixel – 960kBytes for the same image).
Figure 2: Image Formats
In addition to using *.bmp formats, there are also other formats the EVE series can support such as *.jpg, *.png, *.DXT1 and now *.ASTC, the latter 2 being more efficient in memory usage than the first 2.
It is also not necessary to store or use all images from the same format. EVE will handle a mixture of image formats on a displayed image. As a general rule – larger images or logos are best handled with the higher quality resolution, whereas smaller icons or objects may be supported with more glossy formats.
More information on this is available from Application Note AN_303
The Assets (Fonts)
For designs requiring text to be displayed, the font and font size may be a key consideration in the aesthetics of the design. Text is generally displayed from a specific font table (in-built or customised). As such the font table must be stored somewhere in the system before use. To maximise the usage of space it is recommended to consider what characters are to be used e.g. there is no point in storing the alphabet if only numbers are to be used.
Another consideration will be designs aimed at a global market and requiring character sets from different languages, such as English or Chinese. Early generations of EVE would have required two font tables to be stored for the mixture of characters, however, with the BT815/6 devices supporting Unicode this enables mixing and matching different character sets more easily and efficiently as the characters may be stored in one table.
Store only what you need.
Display List Management
Generating the display list is the primary interface between the MCU and the EVE device. There are essentially 2 display lists stored in the EVE device. The active display (the one you can see) and the one that is being edited. The creation of the display list is the primary purpose of the SPI interface between the EVE device and the MCU. To ensure minimum impact on the available bandwidth of this bus it is vital to only update that which is required.
A display list is a definition of what the display will look like based on placing objects with size, colour and location information on the list. For a largely static display or a display with a fixed background, some of the objects displayed do not change and as such there are shortcuts to developing the display lists.
Figure 3: Example Display List to show a red dot
Instructions in the EVE API allow for MEMCPY and APPEND to be used within a display list. Utilising some of the device on-chip memory to store a portion of a display list that never changes (MEMCPY) allows for the MCU to focus on simply sending the changes over the SPI interface and adding (APPEND) them to the portion that does not change. In complex displays this may save significant SPI data traffic as each element of the display list will be padded to 4 bytes in length.
More information on this is available from Application Note AN_340