Getting Graphic -Marrying the Low-Power Giant Gecko with emWin™ Graphics

Micro development systems provide engineers with high-level environments from which to springboard into their own designs. Device makers put a lot of work and thought into eval, demo, and development systems, and there is a tightrope to walk between keeping costs low and maximizing functionality.

Development kits typically include reference designs, schematics, documented demo programs and source code, and a variety of peripheral interfaces, which show specifics as to how to implement hardware/firmware standards like USB, TCP/IP, Ethernet, and more.

Design engineers appreciate the easily digestible and encapsulated design chunks that the development systems provide. They speed up development time to let engineers take advantage of specific standards without having to become intimately familiar with all the caveats of their often times several hundred page specifications.

Once in a while, a great strategic partnership comes along which provides exceptional opportunity and value; the marriage between the Energy Micro ARM® Cortex™ low energy processors and the Segger Microcontroller emWin™ graphics libraries and routines is just that. It gives designers who use the Energy Micro parts FREE graphics rendering, manipulating, drawing, shading, scrolling, superimposing, and more.

This article will focus on the Energy Micro DK3550 Development kit with a Giant Gecko GG990 processor board that not only provides real-time accurate energy and power profiling, but also supports the Segger emWin libraries. The kit will seamlessly connect our micro/TFT to our firmware world, and let us create user interfaces, bit map images, and screen management and rendering controls, all with a well-engineered low-power autonomous architecture.

All of the Energy Micro processors, datasheets, training information, and development tools mentioned here are available online at the DigiKey website.

The core of it

Not every micro can handle a TFT display, especially for low-power designs. It is not just about the processor’s speed. The amount of on-chip SRAM is usually a limiting factor, and the more RAM you need to keep alive, the more energy you need. The amount of RAM required just for a static display increases exponentially as the resolution of the display increases. On top of that, each pixel consists of three bytes for a typical 24-bit color palette resolution.

A better approach, especially if video or animation is to take place, is to use external low-power SRAM or DRAM to create and map display pages that can be filled and rendered in the background while a clean page of RAM is used to refresh the display. This eliminates ghosting and noisy artifacts on the display as it updates. However, the micro should have enough on-chip RAM to handle at least one full page.

In addition, most handheld and battery-powered graphics devices use touchscreens as well. A micro should have A/D converters, touch sensor support, and, hopefully, op-amps and comparators for higher integration.

The Energy Micro processors are scalable and upward code-compatible ARM7™, ARM Cortex-M3 and ARM Cortex-M4 processors that run up to 48 MHz. (There is also an ARM Cortex-M0 part but it does not support the TFT interface). What makes the Energy Micro parts really stand out are the energy modes and technology they wrap around the cores.

Each peripheral, including the UARTs, SPI ports, A/D converters, I²C, are new designs that are created to use lower clocks and less power. For example, rather than clock a UART at 3.5854 MHz to get the standard baud rate frequencies, the Geckos can use the real-time clock oscillator at 32.768 kHz. Since power is proportional to the square of the frequency, the lower frequency peripherals save a lot of power.

Next, Energy Micro’s processors have a ‘Reflex Bus’, which is basically a peripheral baton-passing resource. Rather than have the micro have to be awake for every action, the low-power peripherals can function autonomously and pass data along to other peripherals without any effort from the core micro.

For example, while the micro sleeps, a timer can kick off an A/D conversion, which can kick off a DMA transfer, which then kicks off a counter that does not wake up the processor until 4096 samples have been read in (see Figure 1). This saves all the energy the micro would typically burn up staying awake to control the A/D to memory operations.

Figure 1: The Reflex Bus is like a baton passing between autonomous peripherals. It lets the micro sleep, saving power while cyclic operations take place with conditional exits.

For lowering energy in sensor applications, the Energy Micro parts also have LESENSE, which integrates mixed-signal functions such as the on-chip analog comparators and digital magnitude detectors. These let you set up analog and digital threshold-level detectors and window detectors, which keep the micro asleep until one or more events occur. Instead of waking up and polling every millisecond or so, for example, the micro can sleep until the monitored sensors have a condition that needs micro intervention.

An important aspect of lowering energy use is the efficacy of the sleep modes. The high-speed dense processor core is the main source of the energy used. By keeping the key peripherals and memory alive and functioning autonomously while the processor sleeps, the largest power hog is cut out of the picture.

The Energy Micro parts have five sleep modes, including a shut-off mode that draws only 20 nA with a brownout detector running. A GPIO state change will wake it up. Mixed-signal sensor applications can use the stop mode, which keeps analog comparators and I²C ports active at 600 nA.

A common sleep mode is the deep sleep mode; typical configurations – with the power monitor active, a real-time clock running, and full ram and register retention – will draw only 0.9 µA and wake up in 2 µsec.

Like the sauce – It’s in there…

The DK3550, DK3650, and DK3750 are Energy Micro’s development kit carrier boards for the Gecko, Leopard Gecko and Giant Gecko processors. The carrier boards are similar and allow a different processor board to plug into the carrier sockets on the motherboard itself (see Figure 2). Different peripheral options can plug in as well like different TFT modules though headers and hardware interfaces.

Figure 2: The DK series development kits let many designs be tested and developed directly on the development board. (Courtesy of Energy Micro.)

Speaking of hardware interface – like the sauce, it’s in there. The carrier board implements RS232, I²C, SPI, Micro SD, IrDa, NOR Flash, NAND Flash, and USB interfaces, as well as a flash programming and emulation interface. But that is not all.

There is an ambient light sensor on board, as well as an accelerometer, a temperature sensor, a potentiometer, and a joystick, DIP switches, buttons, and LEDs. Single-ended and differential analog inputs are handled, as are audio-in and audio-out interfaces. As stated earlier, companies try to put a lot of functionality into their development kits, and this is one example where almost any project you can think of can be designed and tested using the development board. There is even a snap-in prototype board.

The company’s free Simplicity Studio™ development tool is a comprehensive design environment that combines code generation, libraries, a datasheet, starter kit and development kit interfaces, and many other useful tools (see Figure 3).

Figure 3: The Simplicity Studio is a comprehensive design environment, which ties together all the tools, datasheets, app notes, libraries, and flash/emulator interfaces under one shell.

A resource allocator tool lets you select each pin’s shared functions to define pin-outs. Then it generates C code to initialize all the special-function registers with the correct masks to set up each I/O pin as specified – a major time, and potential error, saver.

An integrated IAR C compiler supports up to 32 KB compiles free of charge. You must license more functionality or use one of the many third-party toolchains.

A powerful feature of the development environment is the ability to monitor power usage in real-time as code blocks are running on the target processor. Histogram-like charts show energy usage per peripheral, and graphical waveforms show real-time current draw pegged to the software running at the time. This way, you can identify the peripherals that need optimizing, as well as the software structure running in the background.

When the design approach of these and other tools is fully embraced, low-power designs are readily achievable, resulting in significant increases in battery life of four times or more depending on the application. A battery estimator tool indicates estimated battery life from your design characteristics.

Also included in the design environment is the free ARM Cortex Microcontroller Software Interface Standard (CMSIS) library, a vendor-independent hardware abstraction layer for the ARM Cortex-M processor series. It contains standard common functions including I²C and SPI drivers and interfaces.

Emmmm-good

The recent addition of the free Segger emWin support is a significant move forward for embedded designers who need graphics and LCD support in their designs.

Key for emWin is the Energy Micro direct-drive TFT controller inside the EFM32 Giant and Leopard Gecko parts. This hardware support allows full rate 60 frames per second at QVGA (320 x 240) and 30 frames per second at HVGA (320 x 480) from external memory while the micro sleeps in deep sleep mode.

The Segger emWin suite is a comprehensive ‘flicker free’ graphics library and GUI builder tools for embedding into microcontroller designs that use LCD displays. While supporting 8-, 16-, and 32-bit architectures, keep in mind that most TFT applications will need fairly fast 32-bit processors, and the ARM Cortex-M3 and ARM Cortex-M4 are good candidates.

Shipped, as C source code, the emWin suite, according to Segger, can be adapted to virtually any size physical and virtual display with any display controller and CPU. Without the need for floating point, the graphics library includes routines for fast line draw, circles, polygons, and point draw, as well as complete windows managers and font converters. Window moving, resizing, clipping, and overwriting, as well as hot-spot control items (called Widgets) are just a part of the functionality that is completely handled by the emWin library.

Mouse and touch support are included, as is a windows simulator that allows you to compile the same code as an executable on your PC and debug your user interface, create demos, and create PC-based applications.

Small displays without windows management take up 100 bytes of RAM, 600 bytes of stack, and 10 to 25 Kbytes of library code space depending on the routines needed and the complexity of your applications. Windowed displays will use up 2 to 6 Kbytes of RAM (depending on the number of windows), 1200 to 1800 bytes of stack, and 30 to 60 Kbytes of library code space, again depending on the complexity. This reinforces the point that you may need a good processor to take on display functionality. Resources, resources, and more resources.

Most higher-resolution displays use a direct-connect method, which means that the address bus is connected to the display, which then has direct access to the display memory. This is fast enough to update, control, and refresh the display once parameters like base address and display size are entered.

Smaller displays can use indirect techniques that use a command interface. These are typically slower, but effective for smaller displays or displays that use serial interfaces like SPI or I²C.

Segger suggests that the graphics library live in a structure of its own while developing your user interface and graphics (see Figure 4). Once an application has been developed, tested, and refined, Segger lets you make your own libraries that can include subsets of the master library along with any routines you have modified or added. This can reduce overhead when generating object code since unused library routines are not carried along in the process.

 

Figure 4: As its own self-contained addition to your libraries, all functions of emWin are easily accessible. A custom library can be created for compile time that eliminates unnecessary overhead.

A particularly nice feature of emWin is that the libraries have the hooks in them for support for an RTOS. Segger provides its embOS® priority-controlled RTOS with pre-emptive scheduling that has been optimized for minimum memory use (RAM and ROM). Energy Micro also offers a free RTOS.

The emWin suite should be able to connect to virtually any monochrome or color LCD, with or without an internal controller. Once you configure emWin so it knows the correct memory area, driver locations, color conversion routines, and initialization routines, it is ready to go with any memory-mapped display. You will need to define port buffer access if indirect drive methods will be used.

A nice feature of emWin is the simulator, which allows you to compile the same C source code that you intend to run on your embedded system and use your PC as a test vehicle. This lets you design AND DEBUG your user interface on the PC (which is much easier on the eyes). This also lets you create demos for promotional and marketing materials (see Figure 5).

Figure 5: The simulator running on the PC. (Courtesy of Segger Microcontrollers.)

The font converter can also come in handy to preserve custom company styles and logos. The emWin application supports mono-spaces and proportional spaced bitmap fonts, as well as True Type Fonts (TTF), External Bitmap Fonts (XBF), and System Independent Fonts (SIF) to name a few. In addition, extensive palette controls make it easier for displays to match colors for calibrated applications.

A nice feature is its ability to work with different color depths. Instead of using a 24-bit/pixel color palette, many displays truncate color information to allow a relatively good palette to be stored as 8-, 16-, or 18-bit values (see Table 1). Many displays and systems use reduced color palette bus widths. It can reduce the amount of required memory.

Format	Color Depth	Compression	Transparency	Palette
1 bit per pixel	1bpp	no	yes	yes
2 bits per pixel	2bpp	no	yes	yes
4 bits per pixel	4bpp	no	yes	yes
8 bits per pixel	8bpp	no	yes	yes
Compressed, RLE4	4bpp	yes	yes	yes
Compressed, RLE8	8bpp	yes	yes	yes
High color 555	15bpp	no	no	no
High color 555, red and blue swapped	15bpp	no	no	no
High color 565	16bpp	no	no	no
High color 565, red and blue swapped	16bpp	no	no	no
High color 565, compressed	16bpp	yes	no	no
High color 565, red and blue swapped, compressed	16bpp	yes	no	no
True color 888	24bpp	no	no	no
True color 8888 with alpha channel	32bpp	no	yes	no
True color 8888 with alpha channel, compressed	32bpp	yes	yes	no
Alpha channel, compressed	8bpp	yes	yes	no

Table 1: emWin supports coding for different color palettes and color depth representations.

Another huge time saver is the widgets. These are the type of user interface elements with which we have all become accustomed, mainly from working within a windowed environment. These common user interface items include dialog boxes, drop down menus, radio buttons, scroll bars, text boxes, graphics frames, and more, and include minimizing, maximizing and rendering for overlapping windows.

Mapping efficiently to the Energy Micro processors means the software’s alpha blending and transparency features take advantage of the hardware support in the micro for these functions. Colored pixels can be indexed to determine if they are transparent and will not be displayed. This simplifies stacking windows, graphics, or sprites when manipulating a display. Alpha blending combines foreground and background color to make overlaps seem semi-transparent (See Figure 6). The emWin libraries also hook well into the low power and sleep mode features of the Gecko processors.

Figure 6: Alpha blending and transparency indexing.

Another nice feature is the graphics support for bar graphs, traces, and oscilloscope types of displaying, scrolling, and plotting (see Figure 7). This really cuts down on development time for medical, test and measurement, and data logging applications. The emWin tool just makes a graph widget with all the defined parameters directly accessible in your code (see Figure 8).

 

Figure 7: Canned routines for graphing, plotting, and scrolling are huge time savers for medical, data logging, and test and measurement applications.

Figure 8: Predefined APIs let you fill in the blanks to get a good-looking graphics interface up and running in no time (Courtesy of Energy Micro).

Where to go from here

If you have ever coded a graphics interface from scratch, you know that this can take more time than coding your main application firmware. Graphics routines can be tricky and subjective.

The Giant Gecko/DK3750 and the Leopard Gecko/DK3650 development boards with the Segger emWin libraries is a win-win for embedded designers combining full-featured processors and tools for low-power graphic designs.