Global Sources
EE Times-India
Stay in touch with EE Times India
 
EE Times-India > Interface
 
 
Interface  

Building prototype user interfaces on a PC

Posted: 01 Sep 2003     Print Version  Bookmark and Share

Keywords:Embedded 

PDF document

By Niall Murphy

Consultant

PanelSoft

E-mail: nmurphy@

panelsoft.com

Building a prototype of a user

interface will help you under-

stand its requirements and us-

ability issues early in the design

cycle.Wearegoingtolookatan

approach to prototyping user

interfaces on a PC, long before

thetargethardwareisavailable.

These prototypes have two

main purposes. One objective

is to enable other members of a

design team to see how the de-

vice works. When an interac-

tive device is designed on pa-

per,ittakesacertainamountof

imagination to judge whether

the interactions described will

work in practice. A working

prototype is less ambiguous

and allows a wider audience to

comment on the planned inter-

face. In many cases, experi-

mentingwiththeprototypewill

help you decide how many but-

tons, LEDs and numeric or text

displays the real thing needs.

The second objective is to

use the prototype to write the

software for the user interface

in the absence of working hard-

ware. To meet this objective,

the interface presented on the

PCdisplaymustbecontrollable

from C, C++ or whatever lan-

guage you use for embedded

development. For the remain-

der of this piece, let us assume

C is the language for the final

target hardware.

Consider briefly which part

of the software we hope to

simulate. At the lowest level,

thesoftwareturnsanLEDonor

off,ormaybeoutputsastringto

a small text display. Being able

to write that software on a PC

is only a minor advantage since

controlling the physical com-

ponents on a user interface is

usually trivial. Toggling an

LED might be one line of code,

and displaying a text string on

an LCD text display might take

a function 10 or 20 lines long.

The hard part is writing the

software that decides whether

the LED should be on or off,

and what string to display.

When a measured sensor value

exceedsanalarmlimitfor some

period of time, and a set of con-

ditions that make the alarm

valid are met, we might choose

to turn on the LED. When a

user presses a button to select

thenextitemonamenu,atable

of strings and actions that de-

scribes the menu may be con-

sulted to determine which item

should next be displayed. The

size of the software controlling

the menu will exceed the size of

the low-level software.

Our goal is to write simu-

latedversionsofthetextdisplay

and LED toggling routines that

show the changes on the screen

of a PC. This enables us to write

the alarm checking and menu

control code so that it runs on a

PC and the target.

This approach is not novel.

Writing software for targets,

such as PDAs and game ma-

chines,thatdonotsupporttheir

own development environment

often requires this approach.

Prototyping tools

Presenting a few buttons and a

two-line text display on a PC is

trivial with Visual Basic. Inter-

facing C code to that prototype,

however, gets pretty messy.

There are a number of

prototyping tools targeted at

the embedded market. I have

avoided these since they en-

croach too much on the design

by forcing you to comply with

their event model. These tools

can generate code if you con-

form to their style of interface,

but I am not convinced they are

flexible enough for every plat-

form--and the code they gener-

ate may not suit small

microcontrollers.

The tool I use is Borland's

C++ Builder (CPB). Though it

is not geared at the embedded

market, I find it flexible for my

needs, and it does not tie me to

one particular processor or

software architecture.

CPB has a set of predefined

graphical components. Most of

them are for desktop applica-

tions (things like pull-down

menus) rather than embedded

projects, but a small subset is

effective for the purposes de-

scribed here. UI elements like

LEDs can be simulated with

pictures.

CPB comes in three ver-

sions: standard, professional

and enterprise. The standard

version is sufficient for the in-

terface we are going to look at

in this column.

Buttons, sliders, labels and

other UI elements can be in-

serted into a form (a simple

dialog window) using the drag-

and-drop environment. Creat-

ingaformleadstothegeneration

of the skeleton of a C++ class.

Each element in the form

has a set of events that are gen-

erated when a user clicks on an

image or moves a slider, for ex-

ample. The programmer se-

lects which events require re-

sponses. Those responses are

written as member functions of

the class that was generated for

the form.

If the front panel has been

drawn by an industrial design

team, a picture of the entire

display will be available. If a

physical prototype exists, then

a digital photograph provides

an image that can be used as

the background.

Building prototype user interfaces on a PC

I use the image object (also

called Timage within CPB) for

mostphysicalcomponents.The

image object lets you import a

bitmap,whichyoucanthendis-

play. For a simple application,

I imported an image of a lit

LED. The application displays

a picture of a crude interface

with five buttons and four

LEDs, as shown in the figure

below. The background image

has LEDs in an off state. When-

ever the software decides that

one of the LEDs should be

turnedon,animageofalitLED

has its visible property set to

true. The image of the lit LED

now covers the unlit LED.

This simple trick of overlap-

ping multiple images lets you

simulate numerous parts of a

physical display. Assume, for

example, that we used the CPB

IDEtocreatealabelcontaining

the word "alarm" and we

named that element AlarmIn-

dicator. We can now write a

function to control it:

void setAlarmState(Boolean

state)

{

PanelForm->AlarmIndicator

->Visible = state;

}

PanelForm is the name of

the form that contains all of the

graphical objects for our simu-

lation. AlarmIndicator is the

name we assigned to the label

afterweplacedoneontheform.

When it is added to the form--

by dragging it on to the form

window--it becomes a data

member of the form.

In CPB, all of the properties

of an element on the display are

A user inteface simulation displays a picture of a crude interface with five buttons and four LEDs.

available as public data mem-

bers of the class representing

that element. This way, the

property Visible can be altered

with a simple assignment. Pub-

lic data members can be altered

byassignmentfromanyplacein

the program. Within CPB,

propertiesalsohavespecialsta-

tus, which allows them to be al-

tered from the IDE. The devel-

oper can click on a label and set

theVisiblepropertyintheprop-

erties window. Similarly, the

developer can change the color

and font.

We looked at a version of

setAlarmState() that drives the

CPB-based simulation. This

code is CPB specific and it will

not run on the final target.

Later on, we will have to write a

version of this function for the

target that might look some-

thing like:

void setAlarmState(Boolean

state)

{

if (state)

{

ledRegister |= 0x02;

}

else

{

ledRegister &= ~0x02;

}

}

Sometimes, this style of pro-

grammingleadstoasetofsmall

functions that create some

function call overhead. On

small systems where this is a

concern, some of these func-

tions can be written as macros

or inline functions. I usually

defer those sorts of optimiza-

tions until fairly late in the

project.

Code organization

If we have got two versions of

setAlarm-State(), we must en-

surethatweonlycompileoneat

a time. One option is to use the

CPB code until the target hard-

ware is available, and then re-

place all of the CPB-specific

code with target-specific code.

If we do this, we will not be able

to run the simulation after we

move to the target. You might

not think this is a problem, but

the simulation is useful even

when hardware is available.

The simulation's PC-based

debugging environment, for

example, is often superior to

the target's environment. The

target may have a slow down-

load time or you may have to

blowaone-time-programmable

chip for every software change.

A debugger that allows single-

stepping and breakpoints may

not be available. Even if we as-

sume a good debugging envi-

ronment on the target, the PC

simulation has other advan-

tages. You can e-mail an .exe

file to colleagues working at

other sites to get feedback.

Once you have decided to

keep both versions functional

through the life of the project,

it is easy to separate them. In

CPB, under project/options,

you can define macros, and I al-

ways define USING_CPB.

Then, in my source code, I can

use an #ifdef to distinguish ver-

sions. Another approach is to

keep the target code and the

simulation code in separate

files, but share a single header

file to ensure that the same set

of function signatures is used

for both.

The CPB environment is

basedonC++,butmanyembed-

ded targets barely support C. It

is important in those cases to

use only the C++ subset that

yourcross-compilersupportsin

the shared code. This is not all

that difficult. One way to do it

is to compile the code for the

embedded target, even if you

have no hardware to run it on.

This will highlight features

used on the PC that may not be

legal on the target. Some

smaller processors will not al-

low recursion. Checking the

softwareontheembeddedcom-

piler will quickly flag any CPB-

specific code that has acciden-

tally been included in the build

for the target. I also find this a

useful way to keep track of how

large the software is, because

compiling for the PC does not

give realistic results. The CPB

libraries are so large that they

distort the size completely.

Three types of code are in

usehere.SomecodeisCPBspe-

cific and only compiles on the

PC.Somecodeistargetspecific

andonlycompilesonthetarget.

Therestofthecodeiscommon,

and should run on both plat-

forms. Ideally, each source file

should only contain one type of

code. Your IDE or makefile

should allow you to choose

which files you want to include

in each build.

I recommend naming any

file that is CPB-specific as .cpp.

Any file that is target-specific

or shared is named with a .c ex-

tension. For the target environ-

ment, I then compile all of the

.c files, but not the .cpp files.

If you follow this style, you

will run into one problem in the

CPB environment. It assumes

that .c files are C code and .cpp

filesareC++.Callsfromonefile

to the other cause link-time

problemsrelatedtothewayC++

generates mangled function

names. You can get around this

by using the "extern C" con-

struct.ButIfindthatabitmessy,

especially when calls are going

from C to C++ and vice versa. I

prefer to set a flag for the

Borland compiler that indicates

all files are to be compiled as

C++irrespectiveofthefilename

extension. Unfortunately, no

flag in the IDE does this. The

hack is to edit the project con-

figuration file by hand.

Building simulations like

this requires some knowledge

of C++, and the CPB environ-

ment has a learning curve, es-

pecially if you have not used an

event-driven, object-oriented

environment. The good news is

that once you have built one

simulation, others follow the

same format. Learning CPB

also pays off if you ever write a

PC-based program that re-

quires a GUI. I have used it in

the past for simple download

utilities that perform serial

communications with the em-

bedded target.

[Embedded Systems Programming]





Comment on "Building prototype user interfaces o..."
Comments:  
*  You can enter [0] more charecters.
*Verify code:
 
 
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

 

Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

 
Back to Top