Table of Contents Table of Contents
Previous Page  4 / 48 Next Page
Show Menu
Previous Page 4 / 48 Next Page
Page Background

south-east european




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

Figure 1

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