Solving the Problem of Memory in GUI-Based MCU Designs
Kurt Parker, Microchip Technology
For me, one of the most difficult components in embedded graphics designs is memory for frame buffers. This memory should be large, high speed and cheap. Unfortunately, compromises often need to be made in order to incorporate memory into embedded graphics designs. At best, these compromises turn into expensive nuisances that drive up cost and eat away at profitability. And worse case, it can cause the need to outsource the design or hire and train new talent in order to complete the design successfully. This article will discuss the considerations that can come with incorporating the high-density, high-performance memory required in embedded graphics applications using microcontrollers (MCUs) and how to minimize, and even eliminate, the potential impact of them.
There are many benefits to using MCU´s in embedded graphic designs versus using a Microprocessing Unit (MPU) architecture. While a MPU architecture is absolutely required for a certain level of GUI, many applications can still run visually appealing and effective GUIs without having the extra cost and training required to make the switch. The advantage that is perhaps the most profound is the level of integration offered by the standard MCU. This includes the selection of sizes of volatile (SRAM) as well as non-volatile (Flash) memories, the specific core and clock speed, communications interfaces and IO ports and analog peripherals. In addition, the market offers a seemingly endless range of devices to fit most embedded needs. However, when a Graphical User Interface (GUI) is a requirement for an embedded application the simplicity, space and cost savings can get more complex for MCU users. When this need is introduced, many embedded designers are left questioning how an MCU can meet their needs or if they should take the potentially costly and complicated leap to an MPU.
Consideration One: How will graphics be driven?
The first consideration for graphics designs would be how the graphics are going to be driven. Generally, there are three functions in an embedded graphics design: rendering, driving and storage. Rendering refers to how the image is created and manipulated. Entry-level designs will use the Central Processing Unit (CPU) of the microcontroller to perform this function.Higher-end, purpose built graphics MCUs will have their own Graphics Processing Unit (GPU) that will offload some of the rendering functions, like line and rectangle draw and fill, shape movement and overlay manipulations called blits.
The drive function refers to how the image is moved to the screen. This can be done by a Direct Memory Access (DMA) unit over an external parallel port on the microcontroller, or with a purpose built graphics controller. The graphics controller will add features like overlays and rotation, enabling an enhanced end design. Finally, storage is where the information about what is to be displayed is kept. This is where the rest of this article is focused.
Consideration Two: Where will you store your GUI design?
Today, the available integrated SRAM for most high-end mass-market MCUs top out at around 512KB. This might be sufficient for driving simple static GUIs that require only one frame buffer, or GUIs that only use eight bits per pixel of color choices and smaller screens. However, the trend in the market that we are seeing is that end users want a similar experience on their embedded device interface that they have with their favorite apps on their smartphones. In addition, companies want any GUI to represent their branding accurately and in a way that drives brand identity and loyalty. Driving a smooth, rich Graphical User Interface can involve the use of multiple frame buffers, multiple layer overlays, and larger color depths. The latter is especially true if the graphics in the application are required to be photo-realistic or to exactly match a specific brand color.
Figure 1 demonstrates a couple examples of GUI applications that involve many of these enhancements. The example is a largely photo-realistic image distortion demo that has a non-volatile memory footprint at runtime of approximately 12MB. Another application, a coffee-maker GUI, took advantage of some smaller graphics icons, but also had multiple layer overlays and motion. Its runtime footprint was about 3MB.
Consideration 3: Should you use external memory to store your GUI?
Remember, integrated SRAM in the typical high-end MCU tops out at about 512KB. Clearly these two applications overrun the integrated high-speed memory of almost every MCU on the market. This necessitates the need for additional memory external to the MCU. Such memory needs to be high density, high performance and highly available. One option for external memory in MCU graphics applications is asynchronousSRAM. External SRAM provides a memory boost, providing densities of 8MB and is also relatively easy to design, with non-multiplexed address lines and pinouts that are friendly to external parallel ports on many microcontrollers. The compromise with using external SRAM is density (8MB is large, but not large enough in many graphically intense applications), cost (single unit pricing with online distributors is often larger than the MCU itself), and board space.
Many MCUs on the market today have implemented a SDRAM interface on their microcontrollers that can be used for graphics storage. The sweet spot for supported densities in this kind of external memory is 8MB and 16MB. SDRAMS are relatively easy to obtain and are far more cost effective than external SRAMs. As alluded to above, 8MB should be considered a lower limit, with some GUI applications (like the photo distortion demo) exceeding this limit. Using SDRAM is a case where board design considerations also need to be made. With busses that reach 120MHz, special design requirements need to be enforced.For example, certain applications recommend all PCB boards with end-to-end SDRAM designs contain six layers. This means that high performance external memory can add up to four layers on to the embedded PCB design, adding several dollars of cost to the overall system BOM.
Performance can be another issue to consider with SDRAM. With typical 100MHz 16-bit busses, the theoretical maximum data transfer rate is 200MB/s. An 800x480 WVGA display with a 60MHz refresh rate and 16 bits per pixel color depth requires a data throughput of 46MB/s. However, with image manipulation happening from either the CPU or an optional Graphics Processing Unit, as well as support for layered overlays which is becoming the norm in embedded graphics MCUs, the design would be pushing at or beyond the real word performance of the SDRAM-based system. In other words, SDRAM performance can be a limitation in some higher-end graphics applications. Remember the trends that were mentioned earlier? End users want all of their interactions with their electronic devices to look like what they experience with their smart phones and their favorite apps. Therefore the performance pressure is only going to increase going forward. Thus, a newer, higher performance and higher density technology is required.
Consideration 4: Is there such a thing as internal memory for GUI applications?
The final technology that we will consider is DDR2 SDRAM. This gives the developer the advantages of even higher densities (up to 128MB) than could be achieved with SDRAM. Another advantage to using DDR2 SDRAM is performance. The clock rates on the interface to DDR2 memory are at a minimum twice as fast as SDRAM. Also, DDR stands for "double data rate" meaning that data is transferred to or from memory twice for every cycle. The result is a memory technology that is at least four times faster than the SDRAM used in the market.
Harnessing the performance of DDR2 memory is one of the major drawbacks of using this technology. With the bus interface starting at 200MHz and data transfers happening on each half cycle, special considerations above and beyond what are required for SDRAM are needed to ensure proper signal integrity while providing isolation throughout the rest of the board. DDR designs also need to pay attention to other specifications, like tight tolerances on reference, source and termination voltages, appropriate decoupling, layout considerations like trace widths, interpair spacing and intrapair spacing and trace routing.
With embedded graphics applications getting larger, deeper and more complex, the need for the large memory size and fast data throughput of DDR2 memory will continue to grow. Embedded systems designers that were implementing MCUs at a maximum of 150MHz just a few years ago are now facing the need to use MCUs that are twice as fast, with memory interfaces that match the MCUs internal clock speed. Most MCU manufacturers can and do offer design assistance for their products in many forms.
However, wouldn´t it be nice to have access to high density and high performance memories in a high-speed, graphics enabled MCU without having to add expensive layers to the PCB, which adds several dollars to the overall BOM cost, and the extra effort needed for what could be the initial foray into 200MHz+ DDR2 bus design? The PIC32MZ DA from Microchip is one of the few MCUs on the market that can interface with DDR2 memories. The PIC32MZ DA family of microcontrollersalleviates the pressures of external memory design by incorporating the graphics memory in-chip. Using a stacked memory design technique, the PIC32MZ DA includes 32MB of DDR2 DRAM internal to the device so that no external memory is requried (Figure 2). This device also incorporates a three layer graphics controller and a high-performance graphics processing unit in the chip as well, providing an unparalleled level of integration and performance in graphics driven MCUs.
The need for embedded design to keep up with the beauty and complexity of graphical user interfaces will only continue to accelerate. While several memory technologies exist to help solve one of the key limitations of MCU architectures - memory storage, each comes with its own unique advantages and disadvantages. This article discussed the benefits and drawbacks of each architecture. GUI designs are not going away, and while the memory limitations can be a headache for designers, they should not limit you from being able to design great applications that are useful and effective for your customers.
LATEST issue 2/2019