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, compro-
mises often need to be made in order to incorporate memory into embedded graphics de-
signs. 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 mini-
mize, and even eliminate, the potential impact of them.
There are many benefits to using MCU's in embedded graphic designs versus using a Micro-
processing 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, driv-
ing 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 experi-
ence on their embedded device interface that they have with their favorite apps on their smart-
phones. 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 over-
lays 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 pro-
vides 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 microcon-
trollers 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
Solving the Problem of Memory
in GUI-Based MCU Designs
Kurt Parker, Microchip Technology
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
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 need-
ed 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 refer-
ence, 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-perfor-
mance graphics processing unit in the chip as well, providing an unparalleled level of integra-
tion 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 draw-
backs 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.
Figure 2. PIC32MZ DA Block Diagram