By Jack Ganssle

Screens Everywhere

Published November 2013 on embedded.com

I had one of those medical events this summer that netted a panicked wife, fun ambulance ride, and ultimately a completely benign diagnosis. But for a couple of weeks they had me monitoring blood glucose levels using a $10 monitor and a $150 supply of test strips.

Afterwards, of course, I disassembled the monitor and found it runs on a pair of coin cells. An MSP430 16-bit MCU controls everything, including an LCD display that shows quite a bit of information.

Remember the old days of a simple seven segment display? We'd torture them into displaying some alphabetic characters and hope users could distinguish a "B" from an "8" based on context. Now it seems that fancy screens are everywhere.

Without stirring from my chair, I can see the following screens:

* 2 monitors on the PC

* The laptop (Macbook Pro)

* A VOM (an Extech I'm falling out of love with)

* At least a dozen various embedded eval boards

* A bunch of electronic products like the glucose monitor I've disassembled

* The little Canon point-and-shoot camera

* Screens on the lab power supplies

* iPhone

* iPad mini

* Several VoIP phones

That's without spinning around to see the printers, other computers and who knows what else in the same room.

Digikey lists an astonishing 4764 different Cortex M-series MCUs. Over 600 have an LCD controller on board. Today we certainly live in the time of screens everywhere. There will be a lot more in the future.

What software will drive these? The glucose monitor has a typical low-end screen which is custom made for the application. It's not bit mapped like a general purpose TV display, so the code won't be very difficult. The camera screen, the scope and other fully bit-mapped products require gobs of software.

Some of these products run Windows or Linux and can leverage the rich GUI support therein. But an MCU like those 4764 Cortex M parts will never run those operating systems. Developers face two choices: custom build a GUI or buy a component.

GUIs are surprisingly difficult to write. Where do windows overlap? Which parts of the screen are "dirty" and need updating? There's an even worse problem: that miserable marketing bozo who wants color and layout changes the night before shipping.

Some products simplify the task. You can buy GUI code, but usually a better alternative is to find a product that is comprised of both the code needed in the embedded system, and a program that runs on a PC where you'll do all of the screen design and layout. It will then generate C structures that instruct the GUI code that lives in your embedded system. You'll still have to write all of the event handlers and the like, but the heavy lifting is taken care of by the purchased components. With these tools it's usually easy to make last minute changes to satisfy the bozos.

Express Logic introduced such a system (named GUIX) at ARM TechCon. I haven't seen the demo but the data sheet looks promising. It's a very complete system that is scalable, so it will run on screens large and small. Unlike some of the embedded GUIs it will allow the full range of windowing features the iPad generation expects, and it will handle touch and gesture interfaces. Best of all, it's optimized for small 32 bit MCUs... like those 4764 Cortex M devices. GUIX Studio is the name of the Windows-hosted design code, and it will actually execute the design on the PC, so those marketing folks can see what the application will look like long before you've put months into the implementation.

At this time GUIX requires the use of the ThreadX RTOS.