SMT ASSEMbly for EnginEErS SM

R&D Prototype
pcb assembly
$50 in 3-Days
all smt parts machine-placed!
R&D assembly pRicing matRix
3-Day turn
Up to # smt parts 25 50 100 150 200 250 300 Over 300
1st board $50 $80 $100 $150 $200 $250 $300 Call
2nd board $25 $50 $60 $90 $120 $160 $180 for
Each additional board $20 $30 $40 $60 $90 $120 $150 Pricing
Stencil $50 $50 $50 $50 $50 $50 $50
FREE Tooling anD PRogRamming
How to Order: get the advanced advantage:
• Email boM file, XyrS file and gerber files • loose parts, cut tape or reels – oK
to order@aapcb.com • Machine-placed SMT parts
• Send parts and bare pcbs or we will order them • Assemblies shipped in days
• full turn-key available
ISO 9001:2000 Certified

www.aapcb.com/system • 1-800-838-5650
SmT Component gauge and Sizing Resource
Use the guidelines below to verify you have the correct parts before the assembly
process begins.

paRt size inDicatOR

below are footprints of the 50 most common passive component packages. To find out the industry
identification for your part size, place it on the footprint that best fits the component.

cOmpOnent pitcH gaUge

To use this gauge, align the first lead with the initial size indicator space. This verification tool
will help ensure the part you have is the part you want.

www.aapcb.com/system • 1-800-838-5650
SMT ASSEMbly for EnginEErS SM
 VOLUME 22,
NUMBER 8
SEPTEMBER 2009

Embedded Systems Design

The Official Publication of The Embedded Systems Conferences and Embedded.com

SENSORS RAISE
your system’s IQ
14
Cell processor revisited
22
Is virtualization
right for your project?
28
Ganssle on memory
37
THREE AIRCRAFT, A SINGLE MODEL,
AND 80% COMMON CODE.

THAT’S MODEL-BASED DESIGN.

To develop the unprecedented
three-version F-35, engineers
at Lockheed Martin created a
common system model to
simulate the avionics, propulsion,
and other systems and
to automatically generate
final flight code.
The result: reusable designs,
rapid implementation, and
global teamwork. To learn more,
visit mathworks.com/mbd

TM

Accelerating the pace of engineering and science ©2008 The MathWorks, Inc.
 The only operating system
certified to EAL6+ High Robustness.

www.ghs.com

Copyright © 2008 Green Hills Software, Inc. Green Hills, the Green Hills logo, and INTEGRITY are trademarks of Green Hills Software, Inc. in the
U.S.and/or internationally. All other trademarks are the property of their respective owners.
 One Debugger/ Programmer

Microcontrollers
The Microchip name and logo, the Microchip logo, HI-TECH C, MPLAB, PIC and dsPIC are registered trademarks of Microchip Technology Incorporated in the USA and in other countries. PICkit is a registered trademark of Microchip Technology Incorporated in the USA and in other

A CD that includes:
– PICkit™ 3 User’s Guide

Digital Signal
Controllers
– A series of 12 lessons on PIC® MCUs
with C source code
– A debugging tutorial PICkit 3
– Microchip’s MPLAB® IDE software debugger/
– Free MPLAB C Compiler for all programmer
PIC MCUs and dsPIC DSCs

Analog
– CCS compiler for the PIC18F45K20
– HI-TECH C® Compilers PRO for
PIC10/12/16/18/32 running in
Lite Mode

Serial
EEPROMs
A 44-pin demo
board with a
PIC18F45K20
microcontroller
countries. All other trademarks mentioned herein are property of their respective companies. ©2009, Microchip Technology Inc.

One Low Price ... $69.99

Microchip’s PICkit 3 Debug Express (part number DV164131) incorporates in-circuit debugging technology to provide an extremely
affordable hardware debugger and programmer for the entire range of Microchip’s Flash Microcontrollers (MCUs) – from the smallest
8-bit PIC10 MCU, through all 16-bit dsPIC® DSCs to the largest 32-bit PIC32 MCU.
PICkit 3 runs under the popular MPLAB IDE, the free graphical integrated development environment software, complete with
programmer’s editor, software simulator and project manager. MPLAB IDE’s GUI promotes advanced debugging with a host of auxiliary
features, such as a segmented LCD Designer, a graphics display designer and a data monitor and control interface. Easily connected to the
PC with a USB interface, PICkit 3 is bundled with a demo board for fast learning and initial design prototyping. The two-wire interface
easily connects to the final designs for application tuning and quick in-circuit programming.
With rich features, free compilers fully integrated with MPLAB IDE and a suite of tutorials, Microchip PICkit 3 Debug Express delivers
substantial value at a remarkably low price.

For All PIC® Microcontrollers

www.microchip.com/PICkit3
www.microchip.com/usb
 T H E O F F I C I A L P U B L I C AT I O N O F T H E E M B E D D E D S Y S T E M S C O N F E R E N C E S A N D E M B E D D E D. C O M

COLUMNS
programming
pointers 11
Allocating and deallocating
arrays, in detail
BY DAN SAKS
Deallocating array objects, not
just array storage, requires a little
advance planning.
EMBEDDED SYSTEMS DESIGN
VOLUME 22, NUMBER 8 break points 37
SEPTEMBER 2009 Thanks for the memories
BY JACK G. GANSSLE
From oral tradition and clay tablets all
the way to modern memory devices,

14 Cover Feature:
Jack Ganssle traces the history of
memory.

Getting in touch with DEPARTMENTS

#include 5
capacitance sensor algorithms 3G is passé; 4G is the real deal
BY JOHN CAREY BY RICHARD NASS
Learn about the role of capacitance The handset vendors claim that
measurement algorithms in multi-touch 4G is a real panacea for end users.
sensing user interfaces. But do end users even know what
4G is?

parity bit 6

22Gaming the system—

28Is virtualization right
marketplace
advertising index 38
38

high-end networking for your application?

on the Cell processor BY CASEY WELTZIN
Here’s a brief “no-bull” tutorial IN PERSON
BY JIM TURLEY
on how virtualization actually ESC Boston
Complex multicore processors are
works and where it is most September 21–24, 2009
upon us. With the right open-source
useful. www.embedded.com/esc/boston
tools and a commercial RTOS, they
don’t have to be monsters to program. ESC UK
October 6–8, 2009
www.embedded.co.uk

33 ESC paper: Seamless integration of multicore

embedded systems
BY G. DE SIMONE, P. PIERANI, AND M.QUAGLIANI
ESC Grenoble
December 1–3, 2009
www.design-reuse.com/ipesc09/

Gradually introduce performance improvements while preserving ESC Silicon Valley

an established functional baseline in an embedded system with April 26–29, 2010
demanding characteristics requirements. www.embedded.com/esc/sv

EMBEDDED SYSTEMS DESIGN (ISSN 1558-2493 print; ISSN 1558-2507 PDF-electronic) is published monthly with the exception of a combined July/August issue by
TechInsights, 600 Harrison Street, 5th floor, San Francisco, CA 94107, (415) 947-6000. Please direct advertising and editorial inquiries to this address. SUBSCRIPTION
RATE for the United States is $55 for 12 issues. Canadian/Mexican orders must be accompanied by payment in U.S. funds with additional postage of $6 per year. All other
foreign subscriptions must be prepaid in U.S. funds with additional postage of $15 per year for surface mail and $40 per year for airmail. POSTMASTER: Send all changes
ONLINE
to EMBEDDED SYSTEMS DESIGN, P.O. Box 3404, Northbrook, IL 60065-9468. For customer service, telephone toll-free (877) 676-9745. Please allow four to six weeks
for change of address to take effect. Periodicals postage paid at San Francisco, CA and additional mailing offices. EMBEDDED SYSTEMS DESIGN is a registered trade-
www.embedded.com
mark owned by the parent company, TechInsights. All material published in EMBEDDED SYSTEMS DESIGN is copyright © 2009 by TechInsights. All rights reserved.
Reproduction of material appearing in EMBEDDED SYSTEMS DESIGN is forbidden without permission.
 B
E
N
C
H
BUILD it [Reliably]
With Express Logic’s award-winning BenchX® IDE or use tools from
over 20 commercial offerings including those from ARM, Freescale,
Green Hills, IAR, Microchip, MIPS, Renesas, and Wind River.

RUN it [Fast]
With Express Logic’s small, fast, royalty-free and industry leading
ThreadX® RTOS, NetX™ TCP/IP stack, FileX® FAT file system, and USBX™
T H R E A D

USB stack.

ANALYZE it [Easily]
T
With Express Logic’s graphical TraceX® event analysis tool, and new
R

StackX™ stack usage analysis tool. See exactly what is happening in your
A
C
E

system, which is essential for both debugging and optimization.

SHIP it [Confidently]
No matter what “it” is you’re developing, Express Logic’s solutions will
help you build it, analyze it, run it, and ship it better and in less time. Join
the success of over 600,000,000 deployed products using
Express Logic’s ThreadX!

B E N C H T H R E A D T R A C E S T A C K

Newnes

ion
Second Edit
E
REAL-TIM
ED
EMBEDD ADING
RE
MULTITH dX
With Threa
re,
ARM, Coldfi

For a free evaluation copy, visit www.rtos.com • 1-888-THREADX

ndices for
with appe res
Now architectu
PowerPC
MIPS and

CD-R OM
INCL UDED
ThreadX
Containing

ThreadX, BenchX, TraceX and FileX are a registered trademarks of Express Logic, Inc. All other trade-
n system
demonstratio
examples
and C code

marks are the property of their respective owners.

AD
THRE

L. Lamie
Edward
EMBEDDED SYSTEMS DESIGN

Director of Content/Media,
BY Richard Nass#include
TechInsights
Richard Nass
(201) 288-1904
rnass@techinsights.com
Managing Editor
3G is passé; 4G is the
Susan Rambo
srambo@techinsights.com
Contributing Editors
Michael Barr, John Canosa,
real deal
Jack W. Crenshaw, Jack G. Ganssle,

N
Dan Saks, Larry Mittag
ow that we’re all pretty a nominal 100-Mbit/s data rate while
Art Director
Debee Rommel sure we understand what the client (handset) physically moves
drommel@techinsights.com 3G stands for (or repre- at high speeds relative to the base sta-
European Correspondent sents), it’s time to move on to 4G. To tion, and 1 Gbit/s while the client and
Colin Holland
colin.holland@techinsights.com review, the “real” definition for 3G is station are in relatively fixed posi-
Embedded.com Site Editor
384 kbits/s. That’s the speed for a tions; a smooth handoff across het-
Bernard Cole mobile device. That high rate results erogeneous networks (wouldn’t that
bccole@acm.org
in a host of applications/features that be nice); seamless connectivity and
Production Director are more like what a consumer global roaming across multiple net-
Donna Ambrosino
dambrosino@ubm-us.com would equate with 3G. The more works (again, sounds good, but is
Subscription Customer Service widely recognized definition by con- quite difficult to implement); and
P.O. Box 2165, Skokie, IL 60076 sumers is that the bandwidth is high support for next generation multi-
(800) 577-5356 (toll free)
Fax: (847) 763-9606 enough to permit voice calls, video media applications, such as HDTV
embeddedsystemsdesign@halldata.com calls, and wireless data, all in a mo- video content, mobile TV.
www.customerserviceesp.com
bile environment. What got me to thinking about
Article Reprints, E-prints, and
Permissions For a long time, I would tell peo- this 3G-4G stuff is a couple of visits
Mike O’Brien ple who may not have understood I’ve made recently with two of the
Wright’s Reprints
(877) 652-5295 (toll free) the technical definition for 3G that it cellular power-amplifier (PA) ven-
(281) 419-5725 ext.117 was really the melding of cellular and dors. One, Anadigics is recognized by
Fax: (281) 419-5712
www.wrightsreprints.com/reprints/index.cfm WiFi. That’s obviously not technically some to be the leader in PA technolo-
?magid=2210 correct, but it lets people understand gy. They offer a really low-power de-
Publisher that a 3G handset is one that allows vice in a small package. The second is
David Blaza
(415) 947-6929
you to access the Internet as well as a vendor with a soon to be an-
dblaza@techinsights.com make phone calls. nounced part that—if it meets the
Editorial Review Board It’s somewhat ironic that 4G can claims the company is making—is
Michael Barr, Jack W. Crenshaw, be described by a similar definition, further ahead than anything I’ve
Jack G. Ganssle, Bill Gatliff,
Nigel Jones, Niall Murphy, Dan Saks, with respect to features and applica- come across. If it’s true, you’ll see
Miro Samek tions. In addition to those previous- higher integration within your hand-
ly mentioned, it could include the set pretty soon.
addition of a WiFi/WiMax interface
TM

for voice, video, or data. It also in-

Corporate—TechInsights
Paul Miller Chief Executive Officer cludes a more comprehensive securi-
Aharon Shamash Chief Financial Officer
Felicia Hamerman Group Marketing Director ty solution.
Randall Freeborn Chief Human Resources Officer
Harry Page Senior VP Professional Services, Some of the objectives that the
Semiconductor Insights, Portelligent
4G Working Group has defined for Richard Nass
its communication standard include rnass@techinsights.com

Corporate—UBM LLC
Marie Myers Senior Vice President,
Manufacturing
Pat Nohilly Senior Vice President, Strategic Richard Nass is the
Development and Business
Administration
director of content/
media at TechInsights.
You may reach him at
rnass@techinsights.com.

www.embedded.com | embedded systems design | SEPTEMBER 2009 5

 parity bit
Real programmers code in (fill in blank)
M ichael Barr raises a good point
(“Real men program in C”
July/August 2009, p.9, www.em-
bedded.com/218600142). Teaching
Java/Python/Ruby/TCL, etc., does not
teach computer engineering. They may
be useful for many tasks, but they let
the student avoid really understanding
what the computer is doing. They teach
how to get something working quickly
by trading off speed and size.
In this day and age when nearly
every technical professional can pro-
gram (astronomers/astrophysicists,
sstructural engineers, civil engineers,
mathematicians, chemists, biologists,
cryptographers, and so on), computer
professionals need to do better than
hack out code in “some high-level lan-
guage” to earn their daily bread. As
practitioners of a profession that’s all
about the tool (computer), computer
professionals need to be experts in the
tool and able to write the foundation
that makes efficient use possible for
others. They also need to be able to go
as deep as necessary when things go
badly with all those nice abstractions.
So, if you aren’t a deep expert in
computers, how are you in any way
more than just an assistant to those
professionals who have a deep knowl-
edge of their own expert field, plus can
do your job too? IMHO, if you can’t ex-
plain in detail what happens from
printf(“Hello, world\n”), all the way
down to “fetch, decode, execute,” you
either need to find it out, or accept the
fact that your job may vaporize as soon
as someone figures out how to encapsu-
late your limited knowledge into a GUI
builder or wizard.
Remember all those folks with de-
grees in English and art getting
$150,000 a year in 1998 doing html
6 SEPTEMBER 2009 | embedded systems design | www.embedded.com
coding? Remember how they talked
about the “old” economy and how they
were part of the “new wave of computer
scientists”? Remember how they got
canned in 2001 as soon as decent web-
design software came out and the econ-
omy took a dip? Get ready to update
your resume.
I phone screened 110 “Senior Em-
bedded Software Engineers” to get five
to six who could competently answer “A
‘C’ Test: The 0x10 Best Questions for
!
People use C because it is
the least evil option. For
! embedded realtime sys-
tems, you really only have
! the choises listed: C, C++,
or assembler.
Would-be Embedded Programmers.”
Note that it shouldn’t be possible to
graduate from a reputable CS curricu-
lum without being able to answer these
questions.
—Luke Teyssier
Posted on Embedded.com’s forum
Don’t be too quick to dismiss very
high-level languages for embedded
work. I design instruments for NASA,
and our group codes the firmware in a
mixture of C and assembly. But when
I’m designing a board, I have to write
code in visual basic to glue my various
EDA tools together, I build very com-
plex models in several different envi-
ronments, we distribute the test data
through Java applets on the team web
page, and we analyze the data in either
IDL or Igor. Embedded isn’t just about
the microcontroller. When hiring a
software guy, I score about 30% on
their C skills, 40% on being able to pick
and use the best language to solve to-
day’s crisis, and the rest divided be-
tween their bit-flipping and communi-
cation skills.
—Dave Hamara
Posted on Embedded.com’s forum
From a somewhat specialized perspec-
tive (EDA), it is difficult to see C/C++
replaced soon for heavy-lifting applica-
tions. There is unquestionably high
popularity for languages a level above C
(I myself am a Perl fan and would hate
to be forced into C unless absolutely
necessary). But I observe there is con-
siderable fragmentation above the
C/C++ level—Perl, Ruby, Python,
Java—Java is perhaps the most estab-
lished of these meta-languages and al-
ready making inroads in handset appli-
cations, and I could forsee a day when
JREs are successfully implemented di-
rectly in hardware (attempts have al-
ready been made, but I am unaware of
any being wild successes).
While each of these meta-languages
has value, I think a dominant standard
has to emerge, with equivalent per-
formance across a broad range of appli-
cations for C/C++ to be superceded.
—Bernard Murphy
Posted on Embedded.com’s forum
I think part of the reason a younger
generation of software engineers is not
attracted to embedded software (and
hence C) is the lack of money/
prestige. I have been stunned to see
some job postings lately that require
years of embedded software expert-
ise/medical device control expertise/etc.
and the pay rate is $30/hr! If a software
 Maximize Multicore
Increase Your Performance with NI LabVIEW

Single-Core Sequential C Program LabVIEW

Application on Multicore on Multicore

Using LabVIEW — an inherently parallel graphical programming language —

you can take advantage of the latest advances in multicore systems, including
real-time symmetric multiprocessing and FPGA-based embedded systems.
LabVIEW simplifies visualizing and programming parallel applications for test,
control, and embedded design. Using LabVIEW, customers are realizing a
near-linear performance increase on their multicore systems.

>> Learn to maximize your multicore processor at ni.com/multicore 866 337 5041

©2009 National Instruments. All rights reserved. LabVIEW, National Instruments, NI, and ni.com are trademarks of National Instruments.
Other product and company names listed are trademarks or trade names of their respective companies. 2008-10525-821-101-D
The Newest
Embedded Technologies

New Products from:

Tower System
www.mouser.com/
freescale_tower_system

TM

Joule-Thief™ Module
www.mouser.com/
adaptivenergy_joule-thief

ZICM2410P0 MeshConnect™
ZI
Module
M
www.mouser.com/cel/a
w

The ONLY New Catalog Every 90 Days

Experience Mouser’s time-to-market

advantage with no minimums and same-day
shipping of the newest products from more
than 390 leading suppliers.

MiniCore™ RCM5600W Wi-Fi Module

www.mouser.com/rabbit_rcm5600/ The Newest Products
For Your Newest Designs

www.mouser.com
Over A Million Products Online
(800) 346-6873
engineer coming out of school can go
to Google et. al. and get a hefty salary, a
very cool reputation and stock options,
why are they going to go into a more
meticulously demanding job that re-
quires embedded design skills? Compa-
nies that need embedded software engi-
neers need to value them appropriately
and make these jobs more attractive.
—Susan McCord
Posted on Embedded.com’s forum
We might want to consider adding a
new term to the embedded universe,
something like, “Complex Embedded”
to describe systems or applications that
require (or use) processors or other suf-
ficiently complex logic that require or
are best programmed by higher-level,
perhaps OO languages. For example,
my Atmel 8-bit designs are all done in
C, not because it’s the only language
available for the Atmel AVR’s (assem-
bler and Forth are others of which I’m
aware) but because it’s readily available,
has a high-enough level of abstraction
to make many functions easy to write
but enough hardware manipulation to
handle the basic peripherals of the de-
vice. When I wrote a Windows GUI-
based configuration application for one
of our electronic advance ignition sys-
tems, I used C#, because it was a good
fit for that kind of system. I think we’ve
reached the point where we need to
start differentiating the complexity/
memory/cpu aspects of embedded sys-
tems before asking the question about
what language we use in writing the
software. New terms, anyone?
—David Telling
Posted on Embedded.com’s forum
People don’t use C because it’s a good
language, people use C because it is the
least evil option. For embedded real-
time systems, you really only have the
choises listed: C, C++, or assembler.
Assembler will of course be used at
some extent “inline”, but to write whole
programs in it is not an option if you
want portable code. At the escalating
pace in which the silicon industry plops
out new processors, one can almost be
certain that the program will live longer
than the processor. Portable code is a
must in the embedded world, therefore
we need high-level languages. Private
encapsulation is another good reason
why.
I can come up with a few advan-
tages of C++ over C in embedded sys-
tems, namely stronger type enforce-
ment, exception handling, standardized
inline asm, standardized inlining (C
does not have this because nobody but
the ISO C committee programs in
C99).
But the disadvantages weight heav-
ier in my opinion.
—Daniel Lundin
Posted on Embedded.com’s forum
(Daniel Lundin’s comments continue
online in forum at bottom of the article
at www.embedded.com/218600142.)
Real men only program in two lan-
guages and they both begin with A, As-
sembler, and Ada. Why don’t you see
more non-military systems developed
in those languages? Cause there aren’t
enough real men out there to go
around.
—William Thomas
Posted on Embedded.com’s forum
Maybe that should be “Real old men
program in C.” Anybody suffering from
the delusion that C is the only viable
“high-level” language for embedded de-
velopment should have a good hard
look at Oberon-07. (www.inf.ethz.ch/
personal/wirth/Articles/Oberon.html)
It is as powerful, if not more so,
than C but is much less prone to hu-
man error.
—Chris Burrows
Development Manager
CFB Software
Posted on Embedded.com’s forum
www.embedded.com | embedded systems design
OS for 8-bit MCU
The article (Dave Armour, “FLIRTing
with 8-bit MCU OSes,” July/August
2009, p14, www.embedded.com/
218600135) is very insightful and intu-
itive. Speaking of small footprint
RTOSes with round robin scheduling,
have you checked out µC/OS-III. Its
press release (www.micrium.com/
news/2009-03-24_Micrium-Expands-
RTOS-Family.html) in which they claim
that the new kernel would be support-
ing tasks of equal priority and more-
over the system promises near zero in-
terrupt disable time—surprising!!
Apart from the article what also
caught my eye is the short biography at
the end of it saying “recently laid off
firmware engineer with 15+ years of
experience with lots of time in hand.”
Just goes to show the kind of talent that
is sitting idle...scary!!!
—Saurabh Gandhi
Embedded Software Engineer
Posted on Embedded.com’s forum
I think that the brief critique of the ar-
ticle “Build the Super Simple Tasker”
(www.embedded.com/190302110) is not
fair. All preemptive, priority-based ker-
nels work the way described in the SST
article, that is, the higher-priority tasks
have always precedence in accessing the
CPU before the lower-priority tasks.
Starvation is only a problem when
high-priority tasks take up too much of
the CPU, but this means that the sys-
tem is overloaded. Also, it is not true
that the SST kernel requires state ma-
chines. In fact, the example code pro-
vided with the SST article (ftp://ftp.em-
bedded.com/pub/2006/07samek/sst.zip)
did not use state machines at all. The
article merely mentions state machines
because they are a natural fit for the
kernel of this type.
—Miro Samek
(Read the rest of Miro Samek’s comments
and the author’s response on the Embed-
ded.com at www.embedded.com/forums.)
| SEPTEMBER 2009 9
Development
Solutions

for ARM, 8051 & XE166 Microcontrollers

C and C++ Development Tools
• Best-in-class Keil and ARM compilers for small, fast code
• Genuine Keil µVision® IDE/Debugger/Simulator
• Fast development and verification using Device Simulation
• Easy device configuration with Device Database support
for more than 1700 devices

Microcontroller
Development Kits
C and C++ Compilers A/D I/O Parts Debug
Converter Run-Control
Examples and Templates

Royalty-Free RTX RTOS Timer/ Interrupt Debug

Counter System Channel ULINK® USB Adapters
µVision Device • JTAG, SWD & SWV support
Database & IDE Flash
PWM
ROM • Debugging and Flash download
µVision Debugger • ARM device support
& Analysis Tools
UART RAM • Data Trace for Cortex-M3
Complete Device Simulation
CPU • ARM Instruction Trace (ULINKPro)
I2C/SPI
Real-Time • 8 and 16-bit support (ULINK2)
DMA Clock

RTOS and Middleware SD/MMC

Evaluation Boards
Ethernet USB CAN
Interface
Components
RTX RTOS Source Code
Examples and Templates

TCPnet Networking Suite

Flash File System RTOS and Middleware

• Easy implementation of complex applications
USB Device Interface • Royalty-free RTX Real-Time Kernel
• TCP/IP Suite with Server Applications
CAN Interface • File System for ROM and Memory Cards Keil provides a wide range of evaluation
• Direct Support for USB and CAN interfaces boards for 8, 16 and 32-bit devices

Keil PK51, PK166, Keil RL-ARM

and MDK-ARM Download the and ARTX-166
support more than 1,700 µVision4 Beta Version highly optimised, royalty-free
microcontrollers keil.com/uv4 middleware suites
keil.com/dd keil.com/rtos

keil.com
1-800-348-8051
 programming
By Dan Saks
pointers
Allocating and deallocating arrays, in detail

L ast year and early this year, I wrote a couple of ar-

ticles on dynamic allocation in C and C++ em-
phasizing the distinction between allocating ob-
jects and allocating raw (uninitialized) storage.1,2 When ! Deallocating
array objects,

!
a program allocates an object, it not only allocates stor-
age for the object, but also initializes that storage with a not just
value appropriate for the type of object that will occupy
that storage. When a program just allocates storage, it
array storage,
leaves that storage uninitialized.
I followed those articles with one that explained the dis-
tinction between deallocating objects and deallocating stor-
age.3 When a program deallocates an object, it releases not
! requires a little
advance planning.
only the storage occupied by the object, but also any other Then a new-expression such as:
resources the object was using.
In each of those articles, I sketched out how C++ com- pw = new widget ();
pilers translate new-expressions into more primitive opera-
tions. I also showed how to write C code that emulates the translates more-or-less into something like:
behavior of new-expressions. However, I stalled out when I
got to array delete-expressions. I also left some details out pw = static_cast<widget *>
of the code for both the C++ implementation and the C (operator new(sizeof(widget)));
emulation of array new-expressions. This month, I’ll fill in pw->widget();
most of the missing pieces.
The first statement acquires storage for a widget object by
A RECAP calling operator new, and converts the address of that
New-expressions in C++ allocate objects. Each new-expres- storage from type void * to type widget *. The second
sion is conceptually, if not actually, a two-step process: (1) statement initializes the storage by applying widget’s de-
allocate storage for an object, and (2) initialize it. For ob- fault constructor. (That second statement—an explicit con-
jects of class types, initializing an object usually involves structor call—is not something you can actually write in
calling a constructor. C++.)
For example, suppose class widget is defined as: Delete-expressions in C++ deallocate objects. Each
delete-expression is also a two-step process: (1) release re-
class widget sources that the object was using, and (2) deallocate the
{ storage for the object. For objects of class types, releasing
public: resources involves calling a destructor.
widget(); // a constructor If pw is a pointer to an object of class type widget, a
~widget(); // a destructor delete-expression such as delete pw; translates more-or-
// ... less into something like:
};
if (pw != NULL)
{
pw->~widget();
Dan Saks is president of Saks & Associates,
a C/C++ training and consulting company. operator delete(pw);
For more information about Dan Saks, visit }
his website at www.dansaks.com. Dan also
welcomes your feedback: e-mail him at
dan@dansaks.com. A delete-expression applied to a null pointer does noth-

www.embedded.com | embedded systems design | SEPTEMBER 2009 11

 programmng pointers
ing. If the pointer is non-null, the delete-expression applies
the destructor to the soon-to-be-deleted object, and then
deallocates the object’s storage by passing the object’s address
to operator delete.
In contrast to a new-expression, a call to the Standard C
malloc function, as in:
pw = (widget *)malloc(sizeof(widget));
merely allocates storage for a widget, leaving the storage
uninitialized. In contrast to a delete-expression, a call to the
Standard C free function, as in:
Thereafter, you can construct a dynamically-allocated widg-
et with a default initial value using just:
pw = new_widget();
which is a pretty good approximation for the C++ new-ex-
pression:
pw = new widget;
Similarly, you can mimic the behavior of a C++ delete-
expression by using another inline function:

free(pw); inline
void delete_widget(widget *pw)
merely deallocates the storage for a widget, without any re- {
gard for any additional resources that the widget may have if (pw != NULL)
been using. {
Although C doesn’t have classes with constructors and widget_destroy(pw);
destructors, you can emulate them by using structs and func- free(pw);
tions.4,5 For example, you can implement a C++ widget class }
as a C struct: }

typedef struct widget widget; Then, if pw points to a dynamically-allocated widget, you

struct widget can delete it by calling:
{
// widget data members go here delete_widget(pw);
};
which is a pretty fair approximation for the C++ delete-ex-
(The typedef immediately before the struct definition ele- pression:
vates the name widget from a mere tag to a full-fledged type
name.)6 delete pw;
You can also implement each widget class member func-
tion in C++ as a non-member function in C whose first pa- ALLOCATING AND DEALLOCATING ARRAYS
rameter is a pointer to the widget to be manipulated, possi- A C++ array new-expression as in:
bly along with other parameters. For example, you might
declare the C implementation of the widget default con- pw = new widget [10];
structor and destructor as:
allocates an array of 10 properly initialized widgets. As with
void widget_construct(widget *pw); other new-expressions, an array new-expression is still a two-
void widget_destroy(widget *pw); step process: (1) allocate storage, and (2) initialize it. Howev-
er, with an array new-expression the second step is a loop,
You can closely approximate the behavior of a C++ new- which applies the default widget constructor to each array
expression as an inline C function: element in ascending order by element address.
An array delete-expression such as:
inline
widget *new_widget() delete [] pw;
{
widget *pw = (widget *)malloc(sizeof(widget)); is also a two-step process: (1) apply the destructor to each ar-
if (pw != NULL) ray element, and (2) deallocate the storage for the array. In
widget_construct(pw); this case, it’s the first step that’s the loop—a loop that applies
return pw; the destructor to each array element in the reverse order.
} You can emulate the behavior of a C++ array new-ex-
pression as a C function:

12 SEPTEMBER 2009 | embedded systems design | www.embedded.com

widget *new_widget_array(size_t n) A common technique for passing the array dimension to
{ the delete-expression is for the array new-expression to stash
widget *pw = (widget *) the array dimension in a location just before the array itself, as
malloc(n * sizeof(widget)); illustrated in the Figure 1. Inasmuch as that additional loca-
if (pw != NULL) tion stores an array dimension, it should be declared as type
{ size_t, the same as the parameter to new_widget_array.
widget *p; Previously, new_widget_array allocated space for the
for (p = pw; p != pw + n; ++p) array using:
widget_construct(p);
} widget *pw = (widget *)malloc(n * sizeof(widget));
return pw;
} In the new version, it allocates space for the array plus stor-
age for the array dimension using:
Thereafter, you can dynamically allocate an array of properly
initialized widgets using just: size_t size = sizeof(size_t) + n * sizeof(widget);
size_t *ps = (size_t *)malloc(size);
pw = new_widget_array(n);
If ps is non-null (malloc returns a pointer to the re-
which is a pretty good approximation for the C++ new-ex- quested storage), then new_widget_array can proceed to
pression: place the array dimension at the beginning of that storage:

pw = new widget [n]; *ps = n;

You can mimic the behavior of an array delete-expression and then compute the address of the first element in the ar-
as a function declared as: ray itself:

void delete_widget_array(widget *pw); ++ps;

but the implementation isn’t as straightforward as it is for The allocated array is an array of widgets, but ps is a point-
new_widget_array. Whereas the array dimension appears er to a size_t, so new_widget_array needs a cast to obtain
explicitly in an array new-expression, it never appears in an a pointer it can use to access the array elements:
array delete-expression nor in the declaration of
delete_widget_array. Each array delete-expression speci- pw = (widget *)ps;
fies the address of (the initial element of) the array, but not
the array’s dimension. The delete-expression and Altogether, the new version of new_widget_array looks like:
delete_widget_array have to obtain the array dimension
another way. widget *new_widget_array(size_t n)
{
widget *pw = NULL;
Storage layout for a dynamically allocated array. size_t size = sizeof(size_t)
+ n * sizeof(widget);
The array new-expression places
the array dimension in this size_t size_t *ps = (size_t *)malloc(size);
location just before the first if (ps != NULL)
array element
{
widget
widget *p;
The array new-expression
returns the address of this *ps = n;
location as the address of pw = (widget *)++ps;
the initial (the 0th) array element widget
for (p = pw; p != pw + n; ++p)
widget_construct(p);
}
widget
return pw;
}
Figure 1

CONTINUED ON PAGE 38

www.embedded.com | embedded systems design | SEPTEMBER 2009 13

 cover feature

Learn about the role of capacitance measurement algorithms

in multi-touch sensing user interfaces.

Getting in touch
with capacitance
sensor algorithms

I
BY JOHN CAREY

ncreasingly embedded applications must interact directly with

their environment and their end users. Consider the best new
touchscreen phones, in which the user interface is a large ca-
pacitive sensing screen that differentiates a flick from a tap and
tracks the motion of your finger but doesn’t track your ear.

Sensors are at the heart of these
systems. They sense the environment
and user behavior, enabling the prod-
uct to respond in an intuitive but reli-
able way. However, the sensor films
themselves aren’t intelligent. They don’t
even collect data. They only sense. They
aren’t capable of differentiating be-
tween useful and useless data or dis-
criminating between the quality of dif-
ferent types of inputs.
Truth be told, these sensor films
hardly sense at all. They really just proj-
ect an electric field created by an intel-
ligent capacitive sensing chip. This type
of capacitive sensing is known as pro-
jected capacitive technology, and it’s
used in the most advanced capacitive
touchscreen solutions. Figure 1 shows
and example of how a projected capaci-
tive touchscreen works.
This is not to say that the sensors
themselves are not complex. On the
contrary, a capacitive touchscreen sen-
sor consists of a large array of indium
tin oxide (ITO) conductors on one or
more layers of glass or polyethylene
terephthalate (PET) plastic. Figure 2
presents an example of a touchscreen
sensor construction.
The good optical clarity and low re-
sistivity of ITO make it the perfect con-

www.embedded.com | embedded systems design | SEPTEMBER 2009 15

 ductor for creating a touchscreen.
When the ITO sensor is connected to a
capacitive sensing chip with a suitably
high signal-to-noise ratio (SNR), it can
accurately sense minute changes in ca-
pacitance. A finger’s presence for in-
stance is on the order of a picoFarad
(1012 Farads).
It is typically ac-
companied by back-
ground capacitances
of 10’s of nano- ! Charge transfer tech-
nology enables high
high SNR by using a pair of sensing
electrodes for each capacitive channel.
One is a transmit electrode into which
a charge consisting of logic pulses is
driven in burst mode. The receive elec-
trode couples to the emitter via the
overlying panel dielectric. When a fin-
ger touches the panel, the field coupling
is reduced and
touch is detected.
Most charge
signal acquisition

!
Farads (109 Farads). techniques leave
This situation makes
SNR by using a pair of the charge lines
the sensing environ- sensing electrodes for hot (sensitive to
ment challenging the touch) during
and mandates an ex-
ceptionally high
SNR. Charge trans- ! each capacitive channel.
One is a transmit elec-
signal conversion.
The current on
the sensor edge
fer technology is well
suited to high SNR
capacitive sensing
systems. It allows the
capacitive system to
! trode, the other the
receive electrode.
wiring can be in-
cluded as part of
the position cal-
culation, intro-
ducing positional
sense minute changes in capacitance— inaccuracy to the measurement.
even from a finger as it approaches the The contribution of the edge
phone before it touches it or from the wiring increases with the length of the
touch of a fingernail. routing between the sensor and the
Charge transfer technology enables driver chip and becomes seriously

Projected capacitive touchscreen.

Field coupling

Dielectric
front panel

Drive Drive electrode Receive electrode

buffer
Collected charge

Drive pulses

Figure 1

16 SEPTEMBER 2009 | embedded systems design | www.embedded.com

 ENCORE The Embedded Internet
PRESENTATION!
09.15.09 Conversation Continues

Join us September 15th for another chance to chat live, at our Don’t miss out on your chance to
chat with experts about Intel
FREE virtual trade show, with experts from all corners of technologies and innovation in
our industry. This is a great opportunity for you to get expert intelligent, connected devices.

advice and expand your resource network. If you are interested You’ll find:
• New videos and white papers
in embedded solutions, this is the show for you. • Two Intel executive keynotes
• Seven intriguing courses
• Unlimited networking opportunities

09.15.09
7 4
Learn more and register today at intelembeddedevent.com
Intel and the Intel logo are trademarks of Intel Corporation in the U.S. and other countries. ©2009 Intel Corporation. All rights reserved.
 cover feature
problematic if the distance exceeds a
few centimeters.
The charge transfer technique
holds the receive lines at zero potential
during the charge acquisition process
and solves this problem, effectively re-
stricting the transfer of charges to
those between the transmitter X and
receiver Y electrodes at the point of in-
terest in the main sensor area.
This “charge-transfer” signal-acqui-
sition technique uses individual resis-
tive one-dimensional stripes to create a
touchscreen. These stripes can be read
either in parallel or sequentially, since
the connections to these stripes are in-
dependent of one another. There is an
interpolated coupling between adja-
cent lumped electrode elements and
an object such as a finger.
The charge-transfer technique re-
stricts signal acquisition to the imme-
diate vicinity where a row and col-
umn electrode couple to each other.
This localized coupling means that all
other parts of the row and column
are largely not touch sensitive at the
time the signal is acquired, literally en-
abling true, unlimited multi-touch ca-
pability.1 Figure 3 shows an example of
a charge transfer.
MUTUAL VS. SELF CAPACITANCE
There are two approaches to determin-
ing finger position with a projected ca-
pacitive touchscreen: measuring self
capacitance and measuring mutual ca-
pacitance. Touchscreen solutions that
measure self capacitance measure an
Touchscreen sensor construction.
Layer1 ITO (Y)
εr_panel
εr_adhesive
εr_substrate
εr_adhesive
εr_substrate
Figure 2
18 SEPTEMBER 2009 | embedded systems design | www.embedded.com
entire row or column for capacitive
change.
Self capacitance works OK for sin-
gle-touch systems, but with multi-
touch systems there is no way to re-
solve the positional ambiguity that
results from more than one simultane-
ous touch on different parts of the
screen.
For example, if a user touches on
the capacitive grid at locations X1, Y1
and X2, Y2, the energized lines simply
tell the chip that X1, X2, Y1, Y2 lines
!
Charge-transfer signal
acquisition, combined with
! a mutual-capacitance meas-
urement, provides a superi-
!
or SNR and better tolerance
to parasitic capacitance
have all been touched. It doesn’t know
the combination thereof. It could be
that the chip reports X1, Y2 and X2, Y1
were the touch locations. This problem
is known as ghosting.
Another problem with self-capaci-
tance touchscreens is the snapping ef-
fect. It happens when tracking two
touches moving towards a shared row
or column electrode; the reported co-
ordinates tend to “snap” to that elec-
trode causing a strong nonlinearity
and poor user feel.
Tpanel
Tadhesive
Tsubstrate
Tadhesive
Layer2 ITO (X)
In contrast, mutual capacitance
measurement uses an orthogonal ma-
trix of transmit and receive electrodes
arranged as an array of multiple small-
er touch nodes created by the geome-
try of the electrode structure.
In a mutual capacitance based sys-
tem, each touch is uniquely detected as
an XY coordinate pair, whereas in a
self capacitance system, the detection
of X and Y coordinates of a touch is
independent.
If two touches are present in a mu-
tual capacitance system, this would be
detected as (X1,Y1) and (X2,Y2),
whereas in a self-capacitance system
it would be detected as
(X1,X2,Y1,Y2), leaving two potential
combinations of coordinates. The
self-capacitance ghosting problem is
exponential and becomes impossible
to solve as you transition to three or
more touches.
A mutual capacitive array is inter-
preted as a complete touch surface
that maintains the ability to resolve
multiple touch points within each in-
dividual “small” screen. Because the
capacitive coupling at each point in
the matrix can be measured independ-
ently, it means that there is no ambi-
guity in the reported coordinates for
multiple touches. It is then technically
possible to have unlimited touch
recognition. Figure 4 compares mutu-
al vs self capacitance.
Charge-transfer signal acquisition,
combined with a mutual-capacitance
measurement technique, provides a
superior SNR and better tolerance to
parasitic capacitance, allowing weak
signals, such as capacitance conducted
through a fingernail, coin or stylus, to
be processed.
SENSOR RESOLUTION
Sensor resolution, the ability to a re-
solve passive conductive stylus, can be
directly linked to the electrode pattern
or ITO sensor design. A high-resolution
pattern can be formed by having an ar-
ray of vertical transmit bars separated
by a dielectric to a second layer, which
 cover feature
contains a horizontal array of receiving Charge transfer.
lines.
Drive
In each location the bars cross, a electrode
parallel plate capacitor or sensing elec- X
Drive pulses X Drive buffer
trode is formed.2 In order to maximize
the resolution and SNR of this pattern, Cross-coupling
capacitance
to detect a 2-mm passive stylus tip for
instance, it is important to optimize
the density of electrodes. Adding more Y
Receive 1
capacitive channels in each axis for a electrode
Vss
Sample capacitor
given screen size can have a beneficial Transfer/reset switches
effect even though the sensor is more
1
complex to manufacture. Vss
Timer
More channels will result in a capture
higher SNR. The optimum row and register
Slope resistor Voltage
column pitch of the electrodes should
comparator
approximate the tip-to-tip distance be- Vss

tween thumb and forefinger when

pinched together, divided by two
(about 5 mm or less). This means that
a 4.3-inch screen in a 16:9 aspect ratio
should ideally have 19 rows by 11
columns, totaling 209 mutual capaci-
tance electrodes.3
Increasing the electrode density
also allows a more qualitative interpre-
tation of the data. For example, a 200+
channel matrix makes it possible to
process the “size” and “shape” of the
touch, allowing the end user to draw a
picture or execute a signature. With a
sufficiently high refresh rate (200 Hz),
the technology can even support full-
speed signature and handwriting
recognition with as small as a 2-mm
stylus.
While high sensitivity and resolu-
tion vastly improves the screen’s flexi-
Figure 3
bility, it also introduces the problem of
selectivity. The entire surface of the
touchscreen measures any small
change in capacitance resulting from
any charged object (finger, ear, face)
that is even near the surface of the sen-
sor, whether intentional or uninten-
tional.
The challenge is to collect the data,
discard useless data and utilize useful
data in a selective and accurate way.
Introducing selectivity and accuracy
involves arranging and measuring the
change in capacitance in a meaningful
way, while also acquiring enough data
Slope drive
and applying appropriate algorithms
to allow for qualitative differentiation.
MULTI-TOUCH:
HOW MANY IS TOO MANY?
Two touches allow objects to be
stretched, squeezed, and rotated. One
might wonder what is the utility of pro-
cessing five or 10 touches simultane-
ously, when you can barely fit three fin-
gers on the phone?
The answer goes back to the notion
of making the sensor selective—able to
interpret the quality or size of a touch
and to suppress accidental on unwant-

Mutual vs. self capacitance.

Self capacitance Mutual capacitance
Result: Result:
X3 & X0 = 0 X2 * Y0 = 1
X2 & X1 = 1 X1 * Y3 = 1
X3 X3
Y0 & Y3 = 1
X2 Y1 & Y2 = 0 X2
Conclusion: Conclusion:
X1 X2,Y0 = 1 X1 X2,Y0 = 1
X2,Y3 = 1 X1,Y3 = 1
X0 X1,Y0 = 1 X0
X1,Y3 = 1
Y0 Y1 Y2 Y3 4 + 4 = 8 sensors Y0 Y1 Y2 Y3 4 * 4 = 16 sensors

Figure 4

www.embedded.com | embedded systems design | SEPTEMBER 2009 19

 MEN Micro’s
ESMexpress® COMs:
Power Your Performance Drift compensation.
with Intel ® Atom™ up to
Signal
Dual Core
Hysteresis

Threshold
Reference

Output

Figure 5

ed inputs. A true multi-touch technolo- quite tricky, as it isn’t as simple as just

Higher Performance…XM1
with Intel® AtomTM up to
gy allows intended touches to be identi-
fied and interpreted (such as flick vs.
tap). It also allows unintended touches
to be identified and rejected.
On its own, a capacitive touchscreen
sensor has no idea what is touching it or
why. It cannot distinguish between a fin-
ger, ear, face, elbow, or butterfly. Thus,
it’s possible for the end user to issue ac-
cidental com-
ignoring presses at the edges.
In actuality, the chip has to be
smart enough to determine the touches
from a grip at the edges, track them as
they move, and ensure that they don’t
trigger false presses. All the while the
chip needs to keep the whole screen ac-
tive for multi-touch support, even as
the correct touches move to the edges
where the grip oc-

!
1.6 GHz and 1 GB DDR2 SDRAM,
-40°C to +85°C – extreme reliability mands to the On its own, a capacitive curs.
for rugged and safety-critical phone by just Gesture pro-
applications. using it: grip- touchscreen sensor has no cessing algorithms

!
ping its edges or that calculate and
Highest Performance…XM2
pressing it to
idea what is touching it or interpret the XY
with Intel® CoreTM2 Duo up to
2.26 GHz and 4 GB DDR3 SDRAM, his/her ear or why. It cannot distinguish coordinates of a
face. stream of physical-

0 to +60°C – powerful graphics and
computing for demanding tasks.
Robust ESMexpress® Standard
EMC-proof housing for conduction
and convection cooling, shock and
vibration resistant connectors and
the small 95 x 125 mm format
(ANSI-VITA 59 in process).
Rely on MEN for rugged computer
boards and systems in harsh, mobile
and mission-critical environments.
MEN Micro, Inc.
24 North Main Street
Ambler, PA 19002
Tel: 215.542.9575
E-mail: sales@menmicro.com
www.ESM-express.com
!
Some of the between a finger, ear, face,
“extra” touch
points in a true
elbow, or butterfly.
multi-touch so-
lution can be assigned to unintended
touches. Suppressed touches must be
tracked and stay suppressed even if
they stray into the active region.
This means the controller must be
able to uniquely and unambiguously
resolve, classify, and track many touch-
es at once. This enables a user to com-
fortably hold a small product with
some amount of finger/screen overlap,
while also allowing the touchscreen to
operate normally.
Face and grip suppression algo-
rithms can be used that identify and re-
ject unintentional input from the user’s
face or ear or from fingers gripping the
edges of the phone. Grip suppression is
ly present data
from each of the
10 unique touch
points to execute
gesture commands such as tap, drag,
drop, zoom, rotate, or flick—based on
the speed of the gesture and the XY po-
sitions in the data stream.
Another potential use of the under-
lying many-touch data is to recognize
shapes on the touch surface. This al-
lows all kinds of potentially useful in-
terface enhancements. Basic shape
recognition for a nose, cheek, or even
an ear allows further suppression of
real-world situations that would other-
wise falsely trigger the touchscreen.
As more touches can be uniquely
identified and reported to the host, the
applications will start making use of
multiple touch data.

20 SEPTEMBER 2009 | embedded systems design | www.embedded.com


NOISE AND SYSTEM ISSUES
As noted earlier, capacitive touchscreen
controllers measure very small changes
cover feature
! Exploiting these
exceptionally sensitive
struction, fast performance, and inno-
vative algorithms, embodied in highly
intelligent, capacitive touchscreen con-

!
in the row to column coupling capaci-
tance. The way the controller performs
sensors requires
the measurement has a strong influence innovative algorithms . . .
on the susceptibility of the controller to
external noise.
One common noise generator encountered with touch-
screens is the LCD itself. It often has voltage transients meas-
ured as several volts with rise/fall times measured in mi-
croseconds. Using the right type of capacitive-to-digital
conversion and noise suppression algorithms, it’s possible to
reject most of the noise at source.
Another approach is to use a sensor electrode pattern
that uses two ITO layers but is self shielding from behind.
This approach saves cost by eliminating the need for an extra
shield layer of ITO while still renderings the sensor immune
to the noisy LCD surface.
The second most problematic noise source is found with
“floating” power supplies that often capacitively couple several
hundred volts of distorted 50/60-Hz waveform relative to
earth, into the entire touchscreen device. When a user touches
the device, the sensor effectively becomes part of a capacitive
voltage divider, contaminating the measurements with huge
amounts of low-frequency noise. Again, with clever chip design
and noise suppression algorithms can eliminate this effect.
troller chips that can deliver high chan-
nel density, a high SNR, and a multi-
touch capability. ■
John Carey, director of Marketing Touch
Technology at Atmel Corp., has a masters in electrical engi-
neering from California State University, as well as a bachelors
in electrical engineering from Arizona State University. You
may reach him at John.Carey@atmel.com.
ENDNOTES:
1. “Charge Transfer Capacitive Position Sensor.” U.S. Pat. No. 7,148,704,
December 12, 2006.
2. Capacative Position Sensor United States Patent Pending
20080278178 , November 13, 2008.
3. Hybrid Capacitive Screen Element, United States Patent Pending
20070247443 October 25, 2007.
4. Hybrid Capacitive Screen Element, Patent Pending 20070247443
October 25, 200.7
5. Capacitive Position Sensor. U.S. Pat. No. 6,288,707, September 11,
2001.
6. Adjacent Key Suppression—U.S Patent 6,993,607, January 31, 2006.

CALIBRATING TOUCH
Although many touchscreen solutions require the factory
and/or the end user to calibrate them before use, solutions are
available with self-calibration algorithms that allow the chip to
operate independently of any user or manufacturing calibration.
Signal drift can occur because of changes in the un-
known electrode capacitance and Cs sampling capacitors
over time, often resulting from changes in temperature or
humidity, and causing false detections, non-detections, and
sensitivity shifts.
Drift compensation algorithms compensate using a
slew-rate limited change to the reference level; the threshold
and hysteresis values are slaved to this reference. Once an
object is sensed, the drift compensation mechanism ceases
since the signal is legitimately high, and therefore should not
cause the reference level to change.4,5,6 Figure 5 illustrates
drift compensation.

ITO SENSORS ARE THE HEART

Capacitive touchscreens will likely make their way into prod-
ucts not even imagined today. Consumers are demanding
that user interfaces interact with them in an intuitive, effort-
less, and reliable way.
ITO sensors are at the heart of the solution. Exploiting
these exceptionally sensitive sensors requires thoughtful con-

www.embedded.com | embedded systems design | SEPTEMBER 2009 21

 feature

Complex multicore processors are upon us. With the right open-source tools and
a commercial RTOS, they don’t have to be monsters to program.

Gaming the system—

high-end networking
on the Cell processor

T
BY JIM TURLEY

urn the clock back 10 years. Windows Vista was still on the
horizon; Intel’s processors were single-core Pentium designs;
Chrysler and General Motors were still going concerns; and
Google was just a moderately popular search engine. It was
also the time that hints of a rumored “super chip” first began

swirling around the technology press. 2006, www.embedded.com/188103194)

Could Sony, IBM, and Toshiba really be
collaborating on a massively parallel
supercomputer microprocessor? Was it
for real? What would it be used for?
Over the intervening years, I covered
Cell (as it came to be called) in the
pages of Embedded Systems Design (“A
glimpse inside the Cell processor,” June
and elsewhere and decided it was one
of the most ambitious chips I’d ever
seen. Since then, it’s only gotten more
interesting.
Quick—what do video games and
advanced network routers have in com-
mon?
Quite a lot, as it happens. Both

22 SEPTEMBER 2009 | embedded systems design | www.embedded.com

 !
need to shovel large amounts of data flashy but equally demanding embed-
from Point A to Point B while keeping ded systems.
No mere coprocessors,
up with real-time performance dead- each SPE is a serious

lines. Drop a data packet and you’re
dead—just like first-person shooters. In
networks, there are no do-overs.
Both types of systems also consume
high-end processors and high-speed
memories at a surprising rate. While PC
performance has leveled off, game con-
soles and network boxes are still shoot-
ing up the performance charts. PC users
!
A NINE-HEADED BEAST
At first blush, Cell looks like a big Pow- high-end CPU in its own
erPC chip. Coming in part from IBM,
that’s understandable. But the 3.2-GHz
right, on par with the
PowerPC processor core is the least in-
teresting part of Cell, and accounts for
barely 10% of the chip’s silicon and a
fraction of its massive computing pow-
er. In contrast, half the chip is dedicated
! PowerPC “master”
processor.

may swoon over dual-core processors to eight identical and oddly named have their own SPE instruction set
and multitasking operating systems, but Synergistic Processor Elements, or SPEs that’s unique to Cell. Each SPE is a
any kid with a PlayStation 3 can beat (see Figure 1). massive 128-bit single-instruction,
that with a 9-processor smackdown. No mere coprocessors these, each multiple-data (SIMD) vector-process-
Bring it on, Poindexter. SPE is a serious high-end CPU in its ing machine, meaning it executes one
That’s why video games and net- own right, on par with the PowerPC instruction at a time but can “broad-
work systems both lead the way in in- “master” processor. The SPEs don’t exe- side” multiple math operations across
teresting combinations of killer hard- cute the PowerPC instruction set; they wide data values. This is typical of vec-
ware and real-time software. Their
demand for performance is essentially
infinite: if you build a faster box, it will Block diagram of Cell Broadband Engine chip. The central 3.2-GHz
find a ready market. And the volumes PowerPC processor core is surrounded by eight identical SPE
are large enough to justify serious en- (synergistic processor element) vector processors, which provide
gineering expense and software-devel- most of the chip’s power.
opment time. That means developers
in both of these markets need to make
their systems (a) faster than last year’s
box; (b) cheap enough to build in high SPE1 SPE3 SPE5 SPE7 I/O
XDR MIC
volume; and (c) reliable enough that Mem
you don’t lose money on yield, recalls LS LS LS LS
XIO (265 KB) (265 KB) (265 KB) (265 KB)
or repair. In short, it’s just like every 25.6 GB/s
Memory
I/O
interface
other embedded-system development, controller
Flex
IO1
but with higher stakes. And cooler DMA DMA DMA DMA
prototypes.
This price/performance equation
also explains why IBM, Sony, and
Toshiba each spent hundreds of mil- Total
EIB is 4 ring buses up to 96B per clock, 2 in each direction
76.8 GB/s
lions of dollars and collaborated for
years to create Cell: a wickedly fast and
astonishingly complex multiprocessor
chip for . . . video games. I/O
PPE SPE0 SPE2 SPE4 SPE6 Flex
Actually, Cell is for more than just IO0
games. Its creators wouldn’t have spent L1 (32 KB I/D)
LS LS LS LS
all that time and money concocting a (265 KB) (265 KB) (265 KB) (265 KB)
chip that only Sony could use. Instead,
Cell was devised to handle all sorts of L2 (512 KB)

data-intensive broadband media, in- DMA DMA DMA DMA

cluding network packets, video streams,

and massive floating-point calculations.
Figure 1
The heart of the PlayStation 3 is also
becoming the heart of a number of less
www.embedded.com | embedded systems design | SEPTEMBER 2009 23
 TS-7500
Embedded Computer
Faster. Smaller. Cheaper. tor and media processors, which often
have to iteratively add, multiply, or ro-
tate several integer or floating-point
Qu. 100 84 values. Rather than execute eight sepa-
rate floating-point instructions in a
row, for example, an SPE can execute a
74.3 mm / 2.925 in.
the same software as each other. With
nine fully capable processors, an ambi-
tious (or masochistic) programmer
could conceivably partition the Cell
processor into nine different software
environments.

single eight-wide operation on all the As fun as that sounds, layering on

values at once.
Each SPE also has its own 256K
block of private RAM for executing
code or storing local data. This is part
bonus and part necessity; with eight
high-speed processors all running at
once (not to mention the ninth Power-
66 mm / 2.600 in. PC processor), there’s no good way to
feed them all
the heavy-duty software may not always
be the best solution. In embedded ap-
plications, agility and elegance are usu-
ally preferable over fully optioned-out
alternatives. Every line of code burns
CPU cycles, so less (code) is more (per-
formance).
In at least one case, Sony engineers
came to the same con-

!
from shared clusion. In a paper
Powered by a
memory. With nine fully capable presented at an IEEE
250 MHz ARM9 CPU Instead, each conference on inter-
SPE fetches and
processors, an ambi- connects, a team of

!
Low power, fanless, < 2 watts
64MB DDR-RAM
executes code tious (or masochistic) Sony programmers
from its own local described an interest-
4MB NOR Flash
memory, staying programmer could ing embedded use of

!
Micro-SD Card slot - SDHC
off the internal the Cell processor.1 It
USB 2.0 480Mbit/s host (2) slave (1)
and external bus-
conceivably partition seems the company
10/100 Ethernet es as much as the Cell processor into wanted to add high-

Boots Linux in less than 3 seconds
Customizable FPGA - 5K LUT
Power-over-Ethernet ready
Optional battery backed RTC
Watchdog Timer
8 TTL UART
33 DIO, SPI, I 2 C
Dev Kit provides out-of-box
development + extra features
Over 20 years in business
Never discontinued a product
Engineers on Tech Support
Open Source Vision
Custom configurations and designs w/
excellent pricing and turn-around time
Most products ship next day
Technologic
S Y S T E M S
We use our stuff.
visit our TS-7800 powered website at
www.embeddedARM.com
(480) 837-5200
!
possible. Each
SPE can fill or nine different software
purge its local
store to/from off-
environments.
chip memory
anytime it wants to. As long as each
SPE’s program fits into 256K of code
and data space, life is good—but there-
in lies the challenge.
IT’S FREE, BUT IT’S NOT CHEAP
If you’re a numbers geek, Cell’s per-
formance numbers are impressive.
Adding it all up, the chip has a theoreti-
cal peak computational arsenal of just
over 230 billion floating-point opera-
tions per second. That’s mainframe or
supercomputer territory. Indeed, IBM’s
first uses of the chip were in its System
z9 mainframes and the $133 million
Roadrunner supercomputer.
Surely a chip this awesome can run
a heavyweight operating system? You
betcha—in fact, it can run several.
There’s no rule that says the PowerPC
needs to run the same RTOS as the
SPEs, or that the SPEs all need to run
speed Ethernet to one
of its upcoming con-
sumer-electronics
products.
The developers
wanted to get as close to 10 Gbit/sec
“wire speed” as possible, while still us-
ing a TCP/IP stack for compatibility
and overall ease of development.
They’d initially planned to run Linux
on Cell’s central PowerPC processor for
all the usual reasons: Linux is royalty-
free, it’s customizable, it supports net-
working, and it’s already been ported to
PowerPC. PowerPC chips are common
in networking so the whole process
seemed pretty straightforward.
Then the project hit its head on the
low doorway of reality. First off, the
Sony team discovered that the PowerPC
wasn’t fast enough to handle 10-Gbps
Ethernet traffic after all. At least, not
while running Linux. So they decided
to shift the networking stack onto one
of the chip’s eight SPEs. Clearly an SPE
would be up to the task. If one SPE can
crunch a billion floating-point opera-

24 SEPTEMBER 2009 | embedded systems design | www.embedded.com


tions per second, surely it can handle a
TCP/IP stack.
Actually, no. And therein lay the
second problem. It so happens that Lin-
ux’s TCP/IP stack is much too big to fit
in an SPE’s 256K local store. That’s a
real setback when you’re designing for
maximum performance at minimum
cost. Performance would suffer because
the Linux code (running on the Power-
PC) would need to load and unload
portions of the driver, performing
processor-mediated DMA transfers like
an awkward software cache. And cost
would suffer because Sony’s engineers
would have to include more off-chip
memory to hold all that code.
Instead, the Sony team abandoned
Linux in favor of a royalty-free commer-
cial real-time operating system and
TCP/IP stack running on the SPE.
Specifically, they chose ThreadX and its
companion networking layer, NetX,
both from Express Logic in San Diego.
Like Linux, ThreadX is royalty-free but
unlike Linux, it fits easily within Cell’s
256K memory constraint.
Sony’s engineers decided to run Linux on the PowerPC processor core and use the ThreadX RTOS on the SPE
to handle networking. The combination of the two operating systems and processor architectures provided
better performance, and used less memory, than using a single operating system.
Kernel space
Service application program
NetX TCP/P protocol stack
RC-101 10-Gigabit Ethernet driver
ThreadX real-time OS
SPE side components
Figure 2
In fact, the network stack and the
RTOS together used just 80K of memo-
ry, less than a quarter of what Linux
would have required. Granted, NetX
doesn’t support all the elaborate net-
work functions that a Linux stack
!
Instead, the Sony team
abandoned Linux in favor
! of a royalty-free commer-
cial real-time operating
! system and TCP/IP stack
running on the SPE.
would, but for most embedded systems,
that’s exactly the right tradeoff. The
overall software structure is illustrated
in Figure 2.
The only downside was porting.
NetX wasn’t available for the SPE in-
struction set – but then again, neither
was anything else. Sony’s engineers had
User space
Ring buffers
XDR Memory
Allocate
SPENET kernel module
Allocate
PPE side components
www.embedded.com | embedded systems design
feature
already braced themselves for the task
of porting the Linux network stack.
This would be a breeze by comparison.
Both Linux and NetX were available as
C source, so a quick recompile got
them most of the way there. For the
time being, Sony chose not to take ad-
vantage of the SPE’s SIMD architecture,
sticking with the standard scalar code.
After some performance tweaking (de-
tailed below), they came away quite
happy with the results.
The Linux distribution for Cell
treats the SPEs as virtualized resources,
which means you can create more SPE
threads than there are SPEs. That’s a
nice feature, but it also means an SPE
thread might be swapped out while it’s
running. Such is the nature of context
switching. To prevent that from hap-
pening, the Sony team “pinned” the net-
work stack to one SPE, effectively pro-
hibiting Linux from swapping it out and
dedicating that SPE exclusively to net-
work processing.
Given the high packet rates Sony
was hoping for, frequent interrupts
Linux user process
application
(on SPE or PPE)
Communication
Library or SPENET
(on SPE or PPE)
Communicate
via device file
| SEPTEMBER 2009 25
 feature
turned from being a necessity to being
a problem. In their experience, most
network stacks are interrupt-driven, es-
pecially from the hardware interface
when it needs servicing. As data rates
climb, these interrupts (and their atten-
dant context switching) become so fre-
quent that the overhead overwhelms
the actual task. The faster it works, the
slower it goes.
To fix this, the team decided to
switch from an interrupt-driven to a
software-polled design. They kept the
same hardware components but just
tweaked the network driver to poll the
chip at regular timer-tick intervals. The
resulting efficiency was dramatic. Be-
cause the SPE is dedicated to network-
ing and doesn’t have a plethora of sys-
tem-level functions to look after, it can
focus on the task at hand without fear
of being interrupted and missing a
packet. So paradoxically, this modern
high-speed network interface relies on
Your solution
is here.
Save time – and money – with embedded
software solutions built to run right out of
the box. Get development started quickly,
with no integration required and full support
for popular tools. With Micro Digital you have
low-cost, no-royalty licensing, full source
code, and direct programmer support. So
get your project off to a great start. Visit us
at www.smxrtos.com today.
Free Evaluation Kits: www.smxrtos.com/eval
Free Demos: www.smxrtos.com/demo
RTOS INNOVATORS
800.366.2491 sales@smxrtos.com
www.smxrtos.com
ARM s ColdFire s Cortex s PowerPC s x86 s CodeWarrior s CrossWorks s GCC s IAR EWARM
26 SEPTEMBER 2009 | embedded systems design | www.embedded.com
one of the oldest and simplest of driver
methods.
!
Given the high packet
rates Sony was hoping
! for, frequent interrupts
turned from being a
!
necessity to being a
problem.
WHEN LESS IS MORE
Sony was optimizing for speed, was
limited by hardware constraints, and
needed only a certain well-defined fea-
ture set. Sound like a typical embedded
application? In situations like this, a
smaller software TCP/IP stack with a
reduced feature set can process packets
and decode headers with minimal over-
head, often through the use of zero-
copy buffers. Larger stacks might have
trouble squeezing into limited memory
space, as was the case here.
There’s never been a case where
more code makes a processor run
faster. Like racecars, high-performance
programs are tuned for light weight
and efficiency, with no extraneous fea-
tures. “Simplify and add lightness” is a
common phrase among racecar design-
ers, and a similar philosophy prevails
among embedded designers. “It can’t
break if it’s not on the car,” might be
another useful axiom.
Although richly appointed, fully
featured network stacks are fine when
you’re designing for “big iron,” they
only make sense if you need the full
repertoire of network operations. Oth-
erwise, all those other features are dead
weight. Most TCP/IP stacks assume the
presence of, and rely on, an operating
system scheduler to manage threads for
packet processing, buffer management,
and communication with the host
processor. That’s only natural, because
network management is generally an
add-on to some existing operating sys-
tem. Whether it’s Unix, Linux, Vx-
Works, Windows, or whatever, the op-
erating system came first and the
networking features were grafted onto
it. That wasn’t really the case here, even
though Sony was using Linux in the
system (and for that matter, on the
same chip).
In SoC or multicore architectures,
small and fast is usually the way to go.
Sometimes that’s by necessity; some-
times it’s by design. Multicore proces-
sors, in particular, often can’t afford
the overhead of simultaneous accesses
to shared memory. The common
memory is likely on a shared bus that’s
slower than local resources, and there’s
probably arbitration overhead among
multiple requests as well. A designer’s
best bet is to use the common memory
only infrequently, and rely on local
memory for repetitive use in tightly
coded algorithms that execute in mini-
mum cycles.

In Sony’s case, they
chose to run Linux on the
main PowerPC processor,
so whatever ran on the
SPEs would have to com-
municate with Linux –
but it didn’t have to be
Linux. In such situations,
a smaller and simpler net-
work stack running on an
SPE can use very simple
IPC mechanisms to keep
the control processor (the
PowerPC) in sync with the
packet processing. So,
there are two issues: oper-
ating system services to
support the stack, and IPC
services to communicate
with whatever operating
system is running on the
control processor (Linux
in Sony’s case)
As a side note, the same minimalist
philosophy also applies to graphics. Al-
though Sony isn’t saying much about
it, it’s safe to assume that this particu-
lar project includes some interesting
graphics with some sophisticated num-
ber-crunching. Cell is the ideal chip for
this, after all. But this tends to rule out
the “traditional” Linux approach, for
all the same reasons we just explored.
One or more SPEs running specialized
code will probably do a far better job
than dumping the task on the central
PowerPC processor. More and more, it
looks like the right way to exploit Cell’s
massive processing power is to divide
and conquer, not to throw everything
at the chip and let it power its way
though.
TWEAKING FOR FUN AND PROFIT
Once Sony’s engineers decided to dele-
gate all the networking functions to a
single SPE (as opposed to running
some or all of it on the parent PowerPC
processor), they could make some other
optimizations, too. For example, once
you know your processor will handle
network traffic and only network traf-
fic, you no longer have to cooperate
!
As frightening as Cell
might appear, it’s actual-
!
ly an easy beast to tame.
. . . Cell is proving itself
! as an unusually accom-
modating platform.
with unknown, non-network tasks. You
can ignore interrupts, turn off task pre-
emption, and eliminate mutexes and
other exclusion processing. All of which
the Sony team did.
They also aligned the TCP/IP stack’s
data structures. Like most RISC proces-
sors, the SPE has no instructions for ac-
cessing misaligned data; it assumes all
operands are aligned on natural bound-
aries, which in this case is 128 bits. Ac-
cessing misaligned operands requires
multiple instructions, so code size can
bloat pretty quickly when you’re access-
ing lots of misaligned data structures—
exactly like the network stack would. A
quick application of the gcc alignment
attributes shrunk the code size by 21%,
at a slight cost of data size.
www.embedded.com | embedded systems design
feature
Together, those two
changes improved perform-
ance by 13% and 22%, re-
spectively. Tweaking branch
prediction (a trivial compil-
er switch) gained them an-
other 22% improvement in
speed.
When all was said and
done, Sony saw sustained
transfer rates of 8.5 Gbit/sec
Photo: Cell processor, courtesy of IBM.
for TCP packets, and even
faster (close to wire speed)
for the simpler UDP pack-
ets. Impressively, this was all
done with off-the-shelf,
scalar, 32-bit commercial
code that was never de-
signed for the Cell proces-
sor. Looking forward to tak-
ing advantage of Cell’s 128-bit
SIMD operations, the Sony
team feels there’s a lot more perform-
ance and code efficiency still to be
found in this combination of hardware
and software.
So as frightening as Cell might ap-
pear, it’s actually an easy beast to tame.
Between its open-source development
tools, commercial and open-source
RTOS options, and fearsome hardware
resources, Cell is proving itself as an
unusually accommodating platform for
networking, encryption, media pro-
cessing, gaming, floating-point acceler-
ation, and even supercomputing. Com-
plex multicore processors are upon us;
it’s good to see that they don’t have to
be monsters to program. ■
Jim Turley is an acknowledged authority
on microprocessor chips, embedded sys-
tems, semiconductors, and intellectual
property licensing. He is the author of
seven books, was past editor of the Mi-
croprocessor Report, was editor in chief
of Embedded Systems Design magazine,
and is currently publisher of Silicon Insid-
er. Contact him at http://jimturley.com.
Endnotes:
1. “Network Processing on an SPE Core in
Cell Broadband Engine,” 16th IEEE Sym-
posium on High Performance Intercon-
nects, 2008; www.hoti.org/archive/2008pa-
pers/2008_S4_3.pdf
| SEPTEMBER 2009 27
 feature

A brief “no-bull” tutorial on how virtualization actually works and where it is most useful.

Is virtualization right
for your application?

A
BY CASEY WELTZIN

ny electrical or computer engineer that reads industry publica-

tions today has likely seen the word “virtualization” enough
times to know that it’s a hot topic. In fact, a quick search of
embedded.com yields over 200 results for the buzz word.
How real is this trend? Does virtualization provide real sav-
ings? This article will attempt to answer these questions by
outlining the major engineering use virtualization hardware and software.
cases for virtualization, discussing how The basic goal of virtualization is to
it impacts performance, and addressing run multiple operating systems in par-
a topic that is critical in engineering de- allel on one computer such that no in-
signs: hardware I/O. The goal is to allow dividual operating system affects the
you to make a straightforward assess- others in any way. In simple terms, any
ment of virtualization technology for individual operating system (called a
your application—independent of the virtual machine) cannot be allowed to
hype. affect shared system resources except in
To fully understand the perform- very special circumstances. For exam-
ance implications of using virtualiza- ple, envision several operating systems
tion in your own designs, it helps to inadvertently accessing the same mem-
know the basic principles that make ory location at the same time. This sit-

28 SEPTEMBER 2009 | embedded systems design | www.embedded.com


uation would be a nightmare to debug,
as any operating system could over-
write the stored value at any time.
The key component required to
make virtualization work is a piece of
software called a virtual machine moni-
tor (VMM), also known as a hypervisor.
See Figure 1 for a conceptual represen-
tation of how this software fits into a
virtualized system. The VMM’s mission
is straightforward: prevent individual
operating systems (virtual machines or
VMs) from altering shared system state,
therefore making sure that conflicts do
not occur. In more exact terms, a
VMM cannot allow individual VMs to
independently execute “privileged in-
structions” such as accessing memory
or I/O devices that could potentially
conflict with other VMs accessing the
same resource.
Note that there are two basic cate-
gories of VMM software: hosted and
bare-metal. Because hosted VMM so-
lutions (such as VMWare Worksta-
tion) rely on a host operating system
for scheduling and I/O access, they are
generally not a good fit for deployed
engineering applications. Therefore, we
will focus on bare-metal VMM software
for the remainder of this piece.
To effectively manage shared system
resources, VMM software must be
called whenever an operating system
wishes to execute a privileged instruc-
tion. For instance, the VMM should in-
tervene when a particular operating
system attempts to write to an Ethernet
port that is shared by several OSes. In
Bare-metal virtualization software enables
engineers to run multiple operating systems
in parallel on one set of computing hardware.
OS 1 OS 2
Virtualization software (VMM)
CPUs I/O
Figure 1
practice, there are three different ways
of making sure that this happens:
• Binary translation—Software is
used to translate pieces of code on
the fly and call the VMM when
necessary.
• Hardware assist—Virtualization
features built into a processor (such
as Intel-VT or AMD-V) are used to
call the VMM automatically when
an operating system attempts to ex-
ecute privileged instructions.
• Paravirtualization—Operating sys-
!
The basic goal of virtualization
is to run multiple operating
! systems in parallel on one
computer such that no
! individual operating system
affects the others in any way.
tem code is explicitly modified (if
source code is available) to call the
VMM.
Regardless of which of the methods
above is used to call the VMM, the per-
formance implications of virtualization
can be compared to context switches in
multithreaded applications. Every time
that an operating system must call vir-
tual machine monitor software, the
state of that operating system needs to
Sharing I/O devices between operating systems
requires a VMM driver and can impact performance.
General-purpose OS
OS n
Shared Ethernet device
Memory
Figure 2
www.embedded.com | embedded systems design
feature
be saved in a memory structure. Like-
wise, this memory must be restored
when control is transitioned back to the
operating system. This can be a very
time-consuming operation, and there-
fore, it’s advantageous to avoid VMM
intervention at all costs.
In practice, VMM intervention can
be kept to a minimum with some clever
design techniques. First of all, by using a
multicore processor in your virtualized
system and dedicating individual
processor cores to individual operating
systems, you can avoid using the VMM
for operating system scheduling.
Instead, each operating system can
run independently as long as priv-
ileged instructions are not execut-
ed. Next, by partitioning memory
between operating systems and
configuring individual operating
systems to access a certain block of
physical memory, you can reduce
or eliminate address translation
overhead. Finally, by assigning I/O
devices to individual operating
systems and carefully routing in-
terrupts, you can avoid invoking the
VMM upon each I/O access or inter-
rupt. The trend here is clear: in virtual-
ized systems, partition where you can
and share only when you must to guar-
antee the best performance.
To summarize, incorporating virtu-
alization into an engineering design by
using VMM software has the potential
of adding some overhead to your appli-
cation that can reduce performance.
The exact amount of this overhead will
Real-time OS
VMM software
VMM driver
| SEPTEMBER 2009 29
 feature
depend on how many times the VMM
BACKGROUND AND BENEFITS OF VIRTUALIZATION software must be called to abstract
Here’s a brief review of what the term virtualization means and how the shared system resources from individual
technology has evolved. Many engineers (and IT professionals) improve virtual machines. For designers that
time to market by using operating systems in their applications. Operat- must share system components between
ing systems provide a large set of capabilities and programs that a de- operating systems, a number of tech-
signer can leverage without having to “reinvent the wheel.” Because nologies exist that attempt to minimize
each operating system is specialized with a focus on certain capabili- the performance hit. When possible, the
ties, many applications use multiple operating systems to gain access to best strategy is to avoid VMM interven-
more features. In the engineering domain, different operating systems tion altogether using partitioning.
provide features like deterministic performance (in the case of a real-time It should also be noted that virtual-
operating system) or a rich user interface (in the case of a general pur- izing two operating systems to run on a
pose operating system like Linux). The bottom line is that many complex single computer (as opposed to using
engineering applications today use a multitude of operating systems to two or more computers) inherently
get the job done. means that only a fraction of the overall
However, until recently, multiple operating systems meant multiple processing power may be present in the
computers. Multiple sets of computing hardware were required to sup- system. Virtualization technology is
port the use of multiple operating systems at the same time. While in meant to use computer hardware, in-
some applications the extra hardware required to run multiple operating cluding processor resources, in an effi-
systems is warranted, a large number of multi-OS systems contain redun- cient way. It doesn’t mean that a given
dant hardware and underutilized processors, often resulting in inefficien- application will necessarily be able to
cy, added cost, and increased physical footprint. run with a fraction of the computing
The inefficiency in multi-OS server farms in the IT world has motivat- cycles.
ed a shift toward new technology. Virtualization is a broad term that
means abstraction of computer resources, but in practice it refers to a I/O ACCESS IN VIRTUALIZED
combination of software and hardware that enables multiple operating SYSTEMS
systems to run in parallel on the same computer. One of the most important considera-
In the IT world, this technology has been widely adopted and im- tions when evaluating virtualization
proved for years, resulting in an enormous reduction of the number of options for your application is I/O.
computers that it takes to run a typical set of server programs. It’s not dif- Does the piece of VMM software that
ficult to quantize the end benefits that virtualization has brought to IT or- you are evaluating support sharing I/O
ganizations; companies can save upwards of 80% on their energy costs devices if needed? What is the perform-
by implementing virtualization. The environmental benefits are also ance overhead introduced when the
clear: it’s estimated that unused server capacity worldwide produces VMM deals with incoming interrupts?
more pollution annually than the entire country of Thailand (4 tons of Can the VMM penalty be reduced to
CO2 per server). near zero when I/O devices are parti-
The following are just some of the potential use cases for virtualiza- tioned (assigned to a given operating
tion in engineering applications: (See sidebar on opposite page.) system)?
Let us first consider the case of
sharing a certain I/O device amongst
different virtual machines. There are
Partitioning I/O devices between operating systems improves two major challenges to this approach:
performance and allows the use of native device drivers. additional software complexity and
performance degradation. VMMs that
General-purpose OS Real-time OS share I/O devices between operating
Native driver Native driver systems must contain a driver for ac-
cessing those I/O devices (as shown in
Figure 2), which can mean additional
VMM software
development time. In addition, under a
sharing scheme VMMs must present
Bus interface IO Data-acquisition device virtual machines with an emulated view
of the hardware that is shared. As men-
Figure 3 tioned in the previous section, because

30 SEPTEMBER 2009 | embedded systems design | www.embedded.com

 feature

! Though virtualization is a
promising technology that
•

•
Combining real-time processing and a graphical user interface on
one set of hardware.
Incorporating a wide variety of communication protocols and pro-

! can be beneficial in many

systems, it is important to •
grams that exist for a general purpose operating system (such as Lin-
ux) in conjunction with real-time performance and reliability.
Isolating critical system components from non-critical parts.

! understand the perform-

ance and I/O implications
• Accessing existing applications or driver stacks from a non-support-
ed operating system.

The benefits of virtualization include lower hardware costs, re-

shared I/O devices lead to more VMM
intervention, some performance over-
head is typically added with each I/O
request or incoming interrupt.
A good example of shared I/O in a
virtualized system is an Ethernet de-
vice. Sharing a single Ethernet connec-
tion between different virtual machines
can be advantageous for reducing hard-
ware while providing connectivity to
each operating system. To make this
possible, VMM software must include a
driver for communicating with the
physical Ethernet device and also pres-
ent individual VMs with an emulated
view of the Ethernet device. When a
VM wishes to communicate via Ether-
net, the VMM intervenes and uses its
driver to actually perform the commu-
nication, adding some latency in the
process.
In contrast, let us consider partition-
ing of I/O devices between virtual ma-
chines. If access to a certain I/O resource
such as a data acquisition device is only
needed from a particular VM, perform-
ance can be increased and software com-
plexity decreased. In this scheme, VMM
software doesn’t need to intervene at all
if configured correctly. VMs can use
their native I/O drivers to access parti-
tioned devices without conflicts, as long
as the VMM software hides these I/O de-
vices from all other VMs. See Figure 3
for a diagram showing how this works.
For example, in the case of a partitioned
data-acquisition board the virtual ma-
chine monitor doesn’t need a built-in
data-acquisition driver. A performance
hit can be minimized or avoided by al-
lowing a single operating system to ac-
duced overall system footprint, higher reliability due to increased isola-
tion of different subsystems (compared with a single-OS solution), and
reduced development time in porting applications or drivers across op-
erating systems.
cess the device directly using its native
data-acquisition drivers.
The lesson here is simple: remem-
ber to think carefully about I/O when
considering virtualization for your ap-
plication. VMMs that share devices can
provide convenience, but may require
additional development effort and
mean a higher performance hit. VMMs
that partition devices typically provide
higher performance and enable the use
of native device drivers by individual
VMs, which can greatly reduce develop-
ment time.
WHEN TO USE VIRTUALIZATION
Though virtualization is a promising
technology that can be beneficial in
many systems, it is important to under-
stand the performance and I/O impli-
cations when looking at incorporating
virtualization into your application.
Specifically, virtualization may be use-
ful if:
• you’re using multiple operating sys-
tems and reducing cost or physical
footprint of your design is impor-
tant;
• you aren’t currently using multiple
operating systems, but you wish to
isolate pieces of your application
from each other or reduce develop-
ment time by leveraging operating
system capabilities;
• you’re willing to take some per-
formance hit in exchange for the
consolidation that virtualization
brings (this can be minimized by
partitioning system resources or
choosing a VMM that incorporates
advanced technology);
• you can afford to spend some de-
velopment time integrating a
VMM into your application and
developing drivers for shared I/O
devices (less development time
may be required with a turnkey
virtualization solution or one that
partitions devices).
As engineering designs continue to
evolve, virtualization will play an im-
portant role by decreasing system cost
and physical footprint while increasing
capability. It is time for engineers to
look at virtualization technology seri-
ously, while at the same time carefully
consider the engineering tradeoffs that
virtualization brings and make sound
decisions. Ultimately, it’s up to you to
decide whether virtualization lives up
to the buzz. ■
Casey Weltzin is a product manager for
real-time solutions at National Instruments.
Weltzin manages the LabVIEW Real-Time
product line, with special emphasis in
multicore processing and virtualization
technology solutions. Weltzin joined NI in
2005 and has worked as an applications
engineer and manager for the Engineer-
ing Leadership Program. He holds a de-
gree in electrical engineering from the
University of Wisconsin-Madison.

www.embedded.com | embedded systems design | SEPTEMBER 2009 31

 Build Your Own Embedded System

Behold the power of the Atom.

Get an Intel® Atom™ based
development kit running Windows®
Embedded Standard 2011 at ESC
Boston and take it from class to
class to build your own embedded
system. Reserve your seat and
kit, now. While you’re there,
learn about the 85+ technical
sessions, speakers and exhibitors.

Register Today.
embedded.com/boston
Use code ESCBPT

Proud sponsors of the Build Your Own Embedded System 2009 Hynes Convention Center
 ESC paper

Is it the slow code movement? Here’s a seamless and continuous integration

approach being presented at ESC Boston this year (class 261) that allows you to
gradually introduce performance improvements while preserving an established func-
tional baseline in an embedded system with demanding characteristics requirements.

Seamless integration
of multicore
embedded systems

E
BY GIUSEPPE DE SIMONE, PAOLO PIERANI,
AND MASSIMO QUAGLIANI

mbedded software is by definition difficult to test: when run-

ning on the target, the code is not always reachable; debug-
ging tools their limits; sometimes the software designer may
have to code using assembly; hardware devices may have
bugs—just to mention a few typical barriers to a fault-free
embedded software application.
In recent years, multicore technolo- In the next phase, the “basic tested”
gy has contributed to increasing the software is loaded on the target hard-
complexity of embedded systems, ware (a microprocessor, DSP, multicore
showing a very interesting opportunity ASIC, FPGA) where the interaction
to find efficient solutions to problems with the real hardware is tested: a sec-
requiring high performance. ond type of fault will be discovered
Often the development of such sys- here. These faults often require more
tems requires the use of simulation time to be analyzed and fixed; typically
tools. A “basic test” phase with a simu- this is run in the lab with all the needed
lator is the first mandatory step in a instruments available for tracing and
comprehensive test strategy aiming at troubleshooting.
discovering and fixing all kind of As pieces are put together and the
faults. system grows, more complex function-

www.embedded.com | embedded systems design | SEPTEMBER 2009 33

 ESC paper
alities will be tested, and a third type of
faults comes up that originates from in-
teraction of the many integrated soft-
ware parts.
When the system is almost complete
and under test for days, a fourth type of
fault is likely to show: a crash or a stop-
ping fault. Here, finding which part of
the system is misbehaving is usually very
hard; in fact, this kind of fault is not easy
to reproduce and when you succeed in
reproducing it, you realize you need
more logs and tracings. Time passes by
and the software… is still unstable.
What is the best approach to deal
with such problems? Maybe nobody
has “the” answer, but we successfully
tried the approach we present in this
paper. The application case illustrat-
ed at the end of the paper is a real
project where the multicore nature
of the platform has been exploited
to address the fault localization with
a minimum human troubleshooting
effort.
Editor’s note: The application
case just mentioned is not included in
this printing but will be available in
the full article online at www.embed-
ded.com/219400429. This article is
an excerpt from the paper prepared
for ESC Class 261 (Seamless Integration
of Multicore Embedded Systems), part of
the debugging tract at the Embedded Sys-
tem Conference, Boston. Massimo
Quagliani will be teaching the class on
September 22.
SMALL STEPS APPROACH
Generally speaking, development of a
complex software system usually deals
with the same problem: the project
finds too many severe faults and unde-
sired characteristics too late, leading to
off-control quality and expensive re-
engineering.
Most developers experience that af-
ter the code is developed and the sys-
tem is integrated, suddenly nothing
seems to work anymore (even those
parts that were working before). The
time and effort needed to get the sys-
tem quality and performance back to
34 SEPTEMBER 2009 | embedded systems design | www.embedded.com
an acceptable rate is a real “nightmare”:
extra time, task forces, customer pres-
sure, and so forth.
Instead, a developer or a project
manager would go for is normally solv-
ing important issues day by day with-
out pressure.
The solution can be to adopt an in-
tegration driven software engineering
model that blends functional decompo-
sition (into very small packages) with
rigorous management of ESW func-
tional and quantitative performance re-
quirements and continuous system in-
tegration to secure a high degree of
! Development of a complex
software system usually
!
deals with the same problem:
the project finds too many
!
severe faults and undesired
characteristics too late, lead-
! ing to off-control quality and
expensive re-engineering.
accuracy and efficiency.
The suggested approach is then to
develop software with a tight control
on system changes and pursuing an
early feedback on quality by using con-
tinuous planning and small integration
steps, in order to achieve predictability
and efficiency.
The main principles in this soft-
ware-engineering model are:
(1) Quality first.
(2) System development in small steps.
(3) Continuous system integration.
(4) Regression test before verification.
(5) Parallel test phases.
Quality first
To achieve the desired software quality,
the correction of faults should have
higher priority than introducing addi-
tional system changes, so that backlog
of unresolved troubles is very small and
the time needed for stabilizing the sys-
tem before delivering it to the customer
is also very short.
A good starting point is for sure
quality of the design base, but this is
definitely not enough.
Human nature prefers to minimize
unnecessary work, and fault trou-
bleshooting and fixing is indeed unnec-
essary work. So, any faults in the system
must be found early, corrected very
quickly as well as the project has to en-
sure that the same fault is not found
and corrected several times.
However the golden rule is to
make as few faults as possible from
the beginning by emphasizing soft-
ware quality practices (ideally you
should stop making faults at all!).
System development in small steps
The solution is split into very small
system changes (let’s call them deltas).
A regression test is performed to
ensure that the changes implemented
in all different system components are
working and not harming legacy
functions and thus avoiding the big
bang delivery at the end of the project.
The benefits are many:
• Get frequent feedback on product
quality.
• Reduce complexity: by implement-
ing a small chunk of code you re-
duce the number and the complexi-
ty of the faults potentially
introduced in that step (less and
simpler faults, much faster to solve
and fix).
• Track progress: frequent deliveries
provide objective evidence of
progress in the project.
• Achieve efficiency: by doing things
frequently, people can learn lessons
and improve project performances.
The basic goal is then to setup a
software factory that runs and verifies
frequent deliveries of new system ver-
sions to get quality feedback early with
an efficient use of resources.

Project anatomy.
Figure 1
Continuous system integration
Delivered deltas are integrated into the
latest version of the system, either if
they contain testable content or incom-
plete functions. At different ESW/HW
maturity stages, the number of compo-
nents that can be integrated may vary,
but the ambition is to have system level
integration as soon as possible.
Build procedure must be automat-
ed and a smoke test is needed to ensure
basic functionalities of the system, in
order to reject failed components and
not to harm the integrated system.
A project anatomy (as sketched in
Figure 1) is used to show all planned
development steps and how they de-
pend on each other, from test, integra-
tion and design perspective: it is a very
important tool to find the most effi-
cient way to implement a given set of
system changes.
The dependencies define the order
in which the different deltas must be
integrated and hence the implementa-
tion order: changes without dependen-
cies, for instance, can be developed in
parallel with each other.
Regression test before verification
Once the code implementing a delta is
delivered, a regression test is run first to
secure that previous baseline has not
been destroyed (whatever worked be-
fore must keep on working), before ver-
ification of new functions starts.
A fully automated regression test
suite is dynamically updated on system
growth, driven by project anatomy. The
same approach is performed at every
level (from basic test to system test),
but the highest applicable test phase
depends on the ESW/HW matu-
rity stage.
After delivery to integra-
tion and regression test, the
design team continues imple-
menting new changes, but if
any fault is found on the deliv-
ered delta, it is corrected with higher
priority.
Parallel test phases
The main enabler for a stable product
quality is to have feedback from test as
early as possible. Doing verification ac-
tivities in parallel is a way to push for
high quality, as well as a way to decrease
the verification lead time.
One could argue that starting sys-
tem test before function test is complet-
!
And even if this were not
true, it’s good anyway to
! let testers “play” with
the system, even only to
! get rid of as many bugs
as possible.
ed can be risky: the system stability
might not be mature enough, for in-
stance, to stand up to stress tests. That’s
not really the case: the assumption is
that the two activities should find dif-
ferent faults.
And even if this were not true, it’s
good anyway to let testers “play” with
the system, even only to get rid of as
many bugs as possible: it will be much
cheaper and faster to verify a less faulty
system.
However, the whole model is really
effective (and doesn’t risk becoming a
“nightmare” itself) only if it’s run on
each of the very small system changes,
and quality gates are established before
entering the different test phases in
parallel.
www.embedded.com | embedded systems design
ESC paper
QUANTITATIVE MANAGEMENT OF
STEPWISE DEVELOPMENT
Characterization of embedded soft-
ware is one of the problems a designer
has to face at least once in a lifetime.
Typical critical factors are millions of
instructions per second (MIPS) con-
sumption and memory usage (pro-
gram memory and data memory). A
“heavy” algorithm can load the proces-
sor and affect a processing delay, with
the risk that real-time constraints are
not fulfilled.
To save money and reuse the avail-
able hardware for introducing new fea-
tures or simply to increase the number
of channels per processor, the develop-
er has to face with code optimization
and sometimes that means writing or
rewriting those parts of the software
that are the most time consuming.
The performance gained optimiz-
ing the code is difficult to predict, espe-
cially if the volume of software to be
optimized is large and the amount of
assembly code to write is critical.
In this scenario, it’s important to
monitor the optimization activity and
take the right corrective action at the
right time in order to avoid any im-
pacts on the project deadline.
Profiling your code is another fea-
ture available to almost every real-time
debugger.
The small-steps approach described
here is well suited for this kind of activ-
ity, where the metric can be measured
at each step.
The problem of tracking progress
Estimating the final optimization grade
reached at the end of the project can be
done if you have access to historical
data for assembly conversion and by
studying algorithm-level optimization
techniques. It’s necessary to have access
to a previous project’s information with
a similar software application. For in-
stance, optimizing estimations for the
AMR-WB speech codec algorithm
could be based upon the result ob-
tained from the same activity on the
predecessor AMR-NB algorithm.
| SEPTEMBER 2009 35
 ESC paper
The final estimation has an un-
avoidable uncertainty depending of the
complexity of the application. For this
reason the estimate is given with a mini-
mum and a maximum value.
But even if the estimation of the to-
tal load reduction can be considered re-
liable, the problem of verifying the per-
formance of the optimization activity
during the project is still an issue. After
the first optimizations, the measure-
ments can give us some figures. How
can we use this information to judge if
we are on the right track? There is no
way to say that the activity is on track
(concerning the nonfunctional require-
ment of target MIPS load) because
there is no estimation of the ideal path
between the start and the final target
values.
Solution
A solution of the tracking problem ex-
ists. Of course, a linear law of the load
reduction is a wrong model and cannot
be taken into account because the opti-
mization degree depends on the kind of
program flow in each function.
The correct model can be obtained
solving a linear programming problem.
Let’s assume:
R = mean reduction factor (this is the
estimated load reduction per chan-
nel)
Y = clock cycles of the not optimized
channel code after N frames
yi = clock cycles of the i-th function ac-
cumulated after N frames (descents
excluded)
ri = reduction factor of the i-th function
(descents excluded)
So the following constraint is valid:
Σ (1 – ri) yi ≤ (1 – R)Y
Simplifying:
Σ ri yi ≥ RY
The linear programming problem
is obtained by minimizing the effort ex-
36 SEPTEMBER 2009 | embedded systems design | www.embedded.com
pressed in terms of optimization grade
under the constraints above and assum-
ing that each function cannot be opti-
mized beyond a reasonable limit.
min f(r) = Σ ri
Σ ri yi ≥ RY
0 ≤ ri ≤ limit ∀ i∈ set of functions
to be optimized
Having the predicted curve of load
reduction, it’s now possible to monitor
if the activity is on track (in terms of
non functional requirement fulfill-
ment), but this requires a certain
! A more structured
approach exploiting ready
! to use techniques, such
as linear programming,
!
leads to a more con-
trolled development.
amount of test at least in simulation
environment in order to profile the op-
timized functions as soon as they are
ready to be integrated.
Iterative approach
The predicted curve of load reduction
is measured at each step of the itera-
tion. Deviations are allowed and the
right actions are taken accordingly. As
soon as the profiler returns the load re-
duction of a released function, the esti-
mated curve for the remaining steps is
modified taking into account the meas-
ures. The model is then updated with
the following constraints:
ri = ri* ∀ i∈ set of already
optimized functions
0 ≤ ri ≤ limit ∀ i∈ set of functions
to be optimized
With this approach, a feedback can
be received and evaluated upfront. Pos-
sible corrective actions are:
• Put more effort in optimizing the
remaining functions;
• Analyze the functions performing
worse than predicted and rework
them to be more aligned with the
prediction.
Practical consideration
Solving the linear programming prob-
lem requires to use the simplex algo-
rithm. You do not need any special tool
for it; the lp-solver is provided by the
common Excel spreadsheet with the
solver add-in.
Sometimes designers prefers to fol-
low their experience or their rule of
thumb, which no doubt could be suc-
cessful, but a more structured approach
exploiting ready to use techniques, such
as linear programming, leads to a more
controlled development.
In this section, we have seen the
case of MIPS load optimization, but
similar considerations are valid also for
memory optimization and, being a
general approach, it could be applied to
other kind of problems.
CONTINUOUS INTEGRATION
As explained early, one of the key suc-
cess factors of the method proposed in
this paper is a continuous integration
of the step-wise delivered software to
ensure an always-working system,
whereas verification activities at differ-
ent levels are run in parallel, to get an
earliest and efficient quality feedback
from different perspectives: coding, in-
terfaces, functionalities, robustness, and
performances. ■
Giuseppe De Simone is a systems man-
ager, Paolo Pierani is a program man-
ager, and Massimo Quagliani is a sen-
ior software engineer, all with Ericsson
(Italy). The three authors joined forces in
the areas of embedded software design,
systems, project engineering, and de-
fined and implemented the strategy. You
may reach the authors through massi-
mo.quagliani@ericsson.com.
Note: This article is an excerpt of an ESC
class paper for ESC Boston, 2009. The full
article is available at www.embedded.
com/219400429
By Jack G. Ganssle
Thanks for the memories
I f each of our hands had eight
fingers, we’d count in hexadeci-
mal and non-geeks wouldn’t
puzzle over numbers that include
the letters A through F. But would
we still start at one instead of zero?
How often have you seen a
child learning to enumerate hold
three fingers out in an effort to re-
member how many of something
he just counted? Perhaps these
digits were the earliest memory
devices.
Or maybe not. Long before
writing was invented people had
developed storytelling to a fine art.
Oral traditions taught the young to
avoid the bad berries and saber-
toothed tigers. Long before being
committed to paper or papyrus, the
Bible was transmitted between genera-
tions by word of mouth. Matthew and
Luke’s begats most likely mirrored
how elders tracked their own family
history.
The very concept of “mine” that
toddlers unceasingly chant likely is
buried deep in our genes. Unless earli-
est societies were truly communal,
Grog the caveman would have needed
some sort of device, perhaps piles of
stones, to track exactly how much was
“mine.”
At some point humans made the
leap from physical representations of
quantities to the abstract. Perhaps the
first form of writing involved scratch-
ing lines in the dirt as a memory aid. I
have read that the earliest symbols ex-
Jack G. Ganssle is a lecturer and consultant on embedded
development issues. He conducts seminars on embedded systems
and helps companies with their embedded challenges.
Contact him at jack@ganssle.com.
break points
!
From oral tradition and
clay tablets all the way
! to modern memory
devices, Jack Ganssle
! traces the history of
memory.
isted as far back as some 30,000 years
ago. These were mnemonics rather
than novels; but the very word
mnemonic means “memory aid.”
Clearly, humankind has long wanted
mass storage. Unfortunately, the early
history of writing has gone to
/dev/null.
Some scholars date the Tărtăria
tablets from Romania back to 5,500
BC, in which case they may preserve
www.embedded.com | embedded systems design
the oldest known written data.
Photo: Tartaria Tablet (Amulet): Museum of: National Transylvanian History Museum di Cluj-Napoca, Period is
The regular shapes of the
glyphs encoded in the clay sug-
gest that standardized writing
had existed for some time. No
one knows what the symbols
mean, but a media that lasts
Developed Neolithic; photo from www.europeanvirtualmuseum.net/virtual_museum/.
seven thousand years puts all of
our modern high-tech solu-
tions to shame.
Just as the Kindle uses se-
quences of ones and zeroes to
store the Kama Sutra, at some
point most societies moved
from pictographs to alphabets.
Egyptian hieroglyphs contain
elements of both. Our alphabet
reduces the number of symbols need-
ed to express complex ideas from
thousands to 26. Fewer symbols
means more storage is needed to en-
code an idea, but there’s no practical
limit to the things that can be de-
scribed. This remains a very diverse
world, so ironically we still need thou-
sands of representations in Unicode to
build computers useful to the planet’s
population.
Clay tablets gave way to papyrus
and parchment. The latter, made from
animal skin, is quite expensive and led
to what was perhaps the first
rewritable storage medium: the
palimpsest. Scribes would scrape or
wash the ink from a parchment docu-
ment and write again on the now-
blank sheet. In fact here in Baltimore,
the Walters Art Museum holds the
Archimedes Palimpsest
(www.archimedespalimpsest.org/). In
the tenth century an unknown scribe
copied some of Archimedes’ work
onto parchment; two centuries later it
was reused for a liturgical text. Science
has been able to reveal the original
| SEPTEMBER 2009 37
 EMBEDDED SYSTEMS MARKETPLACE
Compact Embedded Server
T he Compact
SIB is a small,
low cost, yet
powerful Server
that is ideal for hostile
rugged environments &
has the following features:
!Fanlessx861GHzCPU
!256MBDDR2RAMOnBoard 2.6KERNEL
!128MBInternalFlashDisk
!10/100Base-T Ethernet
!OnBoard Audio
!2RS-232&3USB2.0Ports Pricing
!CompactFlash&MicroSDSlots Starts
!Reliable(NoCPUFanorDiskDrive) at
!OptionalWirelessLAN&HardDrive $230.00
!Dimensions:4.5”x4.5”x1.375”
http://www.emacinc.com/linux_compact_sib.htm
Since 1985
OVER
24
YEARS OF
EQUIPMENT MONITOR AND CONTROL SINGLE BOARD
SOLUTIONS

Phone: (618) 529-4525 · Fax: 457-0110 · Web: www.emacinc.com

Programming pointers . . . from page 13

ad index
The delete_widget_array function assumes that its parameter, pw,
is a pointer returned from some prior call to new_widget_array. There-
Advertiser URL Page
fore, delete_widget_array must obtain the array dimension by effec- ARM/KEIL www.onARM.com 10
tively reversing the pointer computation done in new_widget_array. A EMAC, INC. www.emacinc.com 38
EXPRESS LOGIC www.rtos.com 4
complete implementation of the function looks like: GREEN HILLS SOFTWARE INC www.ghs.com 1
INTEL CORP intelembeddedevent.com 17
MEN MICRO www.ESM-express.com 20
void delete_widget_array(widget *pw) MENTOR GRAPHICS www.mentor.com/nucleus CV3
{ MICROCHIP www.microchip.com/PICkit3 2
MICRO DIGITAL www.smxrtos.com/usb 26
if (pw != NULL) MOUSER ELECTRONICS www.mouser.com 8
{ NATIONAL INSTRUMENTS www.ni.com/multicore/ 7
SARL CALAO SYSTEMS www.calao-systems.com 21
size_t *ps = (size_t *)pw; SEGGER MICROCONTROLLER www.segger.com 16
size_t n = *--ps; SMART BEAR SOFTWARE www.CodeCollaborator.com 38
TECH TOOLS www.tech-tools.com 38
widget *p = pw + n; TECHNOLOGIC SYSTEMS www.embeddedARM.com 24
while (p != pw) THE MATHWORKS www.mathworks.com/connectCV2
widget_destroy(--p);
free(ps);
} ADVERTISING
} EMBEDDED SYSTEMS DESIGN

MEDIA KIT: www.embedded.com/mediakit

PADDING AND ALIGNMENT, AGAIN
These implementations of new_widget_array and delete_widget_ Sales Advertising
array will work just fine on any processor in which no type has an align-
TechInsights Coordination and
600 Harrison St., 5th Flr. Production
ment stricter than that of size_t. However, it could produce undefined San Francisco, CA 94107 United Business Media
behavior on any machine with more strictly aligned types. I’ll explain why, David Blaza 600 Community Drive
and what you can do about it, in a future column. ■ Publisher Manhasset, NY 11030
(415) 947-6929 Donna Ambrosino
dblaza@techinsights.com Production Director
ENDNOTES: TechInsights (516) 562-5115
1. Saks, Dan.“Allocating objects vs. allocating storage,” www.embedded.com/210200586 600 Community Drive dambrosi@ubm-us.com
2. Saks, Dan.“Allocating arrays,” www.embedded.com/212700451 Manhasset, NY 11030
3. Saks, Dan.“Deallocating objects vs. deallocating storage,” www.embedded.com/214501964 Bob Dumas
Associate Publisher
4. Saks, Dan.“Abstract Types Using C,” www.embedded.com/15300198 (516) 562-5742
5. Saks, Dan.“Incomplete Types as Abstractions,” www.embedded.com/16100434 bdumas@techinsights.com
6. Saks, Dan.“Tag vs.Type Names,” www.embedded.com/9900748.

38 SEPTEMBER 2009 | embedded systems design | www.embedded.com

break points
!
text, which is fortunate as it has
the only known copy of the sage
of Syracuse’s The Method of Me-
chanical Theorems.
I suppose one could make the
argument that the abacus was a
storage device, since, like the reg- !
!
isters in a CPU, it held numbers
during a calculation. The Sumeri-
ans had this technology, in a
primitive form, nearly 5,000 years
ago. The Romans called the limestone
pebbles used in their table abacuses
“calculi,” from which we derive the
word “calculate.”
After the invention of paper in Chi-
na around the second century, not
much happened to storage technology
for thousands of years. Paper remained
expensive and was hand-made until the
19th century, and indeed history
records “rag pickers” who recycled old
cloth for papermaking.
Most techies know that the
punched card long predated main-
frames. Cards and paper tape were
originally adopted in France in the ear-
ly 18th century to control textile looms.
(I would have thought that the idea of
punching holes in paper to store in-
structions and data stemmed from
player pianos, but those didn’t come
around till over a century later.)
Charles Babbage designed a calcu-
ENIAC: Detail of the
back of a panel of
ENIAC, showing vacu-
um tubes. Copyright
2005 Paul W Shaffer,
curator of the
University of
Pennsylvania ENIAC
Museum.
(http://en.wikipedia.or
g/wiki/File:ENIAC_Pen
n2.jpg)
Computer centers used fan-
tastic quantities of punched
cards. In the early 1970s,
the University of Maryland
supplied unlimited quantities
to students for free.
lating machine that used punched
cards, but he wasn’t the one to couple
cards to computing. Russian Semen
Korsakov, a bureaucrat in a police sta-
tistics department, anticipated Google
when he invented several machines that
used punched cards to search though
data. But they remained a novelty in in-
formation processing until Herman
Hollerith built machines to record data
for the 1890 census. His company later
morphed into IBM. That company sup-
ported a number of different kinds of
punched cards, but their 80-column
version remains the iconic image of the
technology.
My grandmother died years ago at
age 99, still furious at FDR (she couldn’t
even say his name, always blurting out
“that man!”) for creating Social Security
and other Depression-era programs.
She drew on Social Security for 34 years.
But FDR’s creation did drive a massive
www.embedded.com | embedded systems design
expansion in the use of punched card
machines, and so in some way con-
tributed to the birth of the computer in-
dustry. (Aside: Ida May Fuller got the
first SS check. She paid $24.75 into the
system, or one percent of three year’s in-
come, and netted almost $23,000 in
payouts before dying at age 100, surely
one of the great jackpots of all time!)
Computer centers used fantastic
quantities of punched cards. In the ear-
ly 1970s, the University of Maryland
supplied unlimited quantities to stu-
dents for free. A 10,000-line program
needed 10,000 cards, which filled five
boxes. Even as early as 1937, IBM man-
ufactured five to 10 million cards a day.
Yet when working on the ESC’s twenti-
eth anniversary event, I could find
none, except from a vendor who
charged a buck a card, since they faded
away in the ’70s as other media became
more cost effective.
Paper tape, too, was initially used
for looms. Both Morse and Edison
worked on paper tape systems for teleg-
raphy, though their systems initially
used marks made on the tape instead of
holes. In the 1920s, various communi-
cations links using teletypewriters were
established. The infamous newsrooms
of yore with dozens of these clanking
machines are an example. Prior to and
during World War II, the Teletype cor-
poration built some 200,000 of their
model 15 teletypewriters (often called
“teletypes,” just as copiers are referred
to as “xerox machines.”) These usually
had a paper tape reader and punch at-
tached with which to log and send
streams of messages. All of the model
15 machines I have seen use a five-level
code derived from Baudot rather that
the ASCII 8 or Unicode’s zillions com-
mon today. Mechanical fingers probed
the holes across the tape and converted
the pattern to a 5-bit parallel stream,
which was sent to what looked exactly
like a car’s distributor (for a five cylin-
der car, that is). Five contacts were
swept by a rotor to convert the parallel
to serial.
Konrad Zuse in Germany used pa-
per tape to feed instructions to his Z1
| SEPTEMBER 2009 39
 break points
Tape: A tray of tapes for Data General’s Nova minicomputer.
(http://en.wikipedia.org/wiki/File:Dg-papertapes.jpg)
machine, completed in 1938. He also
used moving metal sheets as main
memory, for a total of sixty-four 22-bit
words (www.epemag.com/zuse/
part3b.htm).
Teletype’s ASR-33 appeared in
1961. At $2,000 (about $14,000
! Eventually sizes shrank tremendously.
today), it was inexpensive, as
these machines went, and was a
perfect match for the newly
!
emerging minicomputers.
The machine had a built-in
8-bit paper tape reader and
punch that read tape at a blis-
tering 10 characters per sec-
ond. It’s interesting that the in-
credibly complex mechanical
mechanism of the ASR-33 was
! costs today. What other industry has
much cheaper than the electronics
needed to build a video terminal, so
these machines were common in com-
puter centers. The racket 50 of them
made in a terminal room cannot be
imagined. ASR-33s were the first termi-
nals used by microprocessor develop-
ment systems.
Flash memory stick.
40 SEPTEMBER 2009 | embedded systems design | www.embedded.com
The story of
computers is one of
speed, and 10 CPS
didn’t tax even the
low-powered ma-
chines of the ’60s.
High-speed paper-
tape readers ap-
peared, which could
suck tape through
at hundreds of
characters per sec-
ond. When some-
thing went wrong,
these devices would spew a snarl of
tape that could fill an office in seconds.
Vendors of both mini- and micro-
computers delivered their tools on tape.
Happily, programs then were not 500-
MB monsters!
Prices did too, falling to about a
penny a bit, about seven orders of
magnitude more than what memory
seen costs tumble so precipitously?
Tape remained the mass storage of
choice in the ’70s till supplanted by
magnetic media.
Meanwhile, other forms of memory
were tried, used and abandoned. A
complete list would take volumes, but
here are some of my favorites.
Today, we store programs and data
in, among other things, active elements
like transistors. That’s not a new con-
cept. The vacuum tube is an active ele-
ment as well, and was used in early
computers both as ALU and memory.
Of course, a tube is about the size of a
skyscraper compared to 45-nm FETs,
and dissipates enormous amounts of
heat. ENIAC stored twenty 10-digit
numbers in ring counters. Every digit
stored needed 36 tubes.
Core memory came about either
from a paper by An Wang, whom old-
timers recognize as the man behind
once-great Wang Laboratories, or from
Jay Forrester and Ken Olsen in their
work on the Whirlwind computer, de-
pending on which sources one be-
lieves. Wang’s paper came out in 1949,
but core didn’t become viable in com-
puters till the following decade. Core
memory is composed of large planes
of tiny ferrite donuts. Three or four
wires are threaded through each torus,
and they are all interconnected in an
X-Y matrix. By sending small currents
through a row and a column it’s possi-
ble to flip the magnetic field of the
core located at the X-Y intersection. A
sense wire detects the transition to sig-
nal if the core was set to a zero or one.
This is a destructive read, so another
cycle resets the core. Compared with
other early memory devices, core was
very fast, switching in under a
microsecond.
Core became the standard
memory store for all computers
from the ’50s until superseded by
semiconductor memory in the
’70s. Though early cores weren’t
much smaller than a Cheerio,
eventually sizes shrank tremen-
dously. Prices did too, falling to
about a penny a bit, about seven
orders of magnitude more than
what memory costs today. Think about
that—what other industry has seen
costs tumble so precipitously?
The Whirlwind machine men-
tioned in the previous paragraph even-
tually had core memory, but initially re-
lied on Williams-Kilburn tubes. These
were essentially CRTs that painted bits
on the phosphor screen (some versions
didn’t bother with the phosphor coat-
ing). A metal plate on the front of the
screen sensed the charges. Typical
Williams-Kilburn tubes could hold a
few hundred to a thousand bits; those
used in the Whirlwind stored 256 bits
each. Unfortunately, the tubes aged
poorly, couldn’t be scaled up to higher
memory densities, and were very sub-
ject to electronic noise.
But they were a pretty cool idea.
And I’ve run out of room. More
next month! ■