VOLUME 25,

NUMBER 4
MAY 2012

EMBEDDED SYSTEMS DESIGN

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

REBUILDING THE
EMBEDDED DEVELOPMENT
COMMUNITY 7 A firmware curriculum
13
15 years of embedded
trends
16
Is C beating out C++?
31
Leading Embedded
Development Tools
ARM® DS-5™ Toolchain

A full featured development solution

for all ARM Powered® platforms

1-800-348-8051
www.arm.com/ds5
 SAFE
RELIABLE
SECURE

TRUS T ED S O F T WA RE FO R
EMB ED D E D DE V I C E S
For 30 years the world’s leading companies have trusted Green Hills Software’s secure
and reliable high performance software for safety and security critical applications.
From avionics and automotive, through telecoms and medical, to industrial and smart
energy, Green Hills Software has been delivering proven and secure underpinning
technology.
To find out how the world’s most secure and reliable operating
systems and development software can take the risk out of
your next project, visit www.ghs.com/s4e

Copyright © 2012 Green Hills Software. Green Hills Software and the Green Hills logo are registered trademarks of
Green Hills Software. All other product names are trademarks of their respective holders.
 mouser.com
Semiconductors and electronic
components for design engineers.
Page Header Size

Page Header Logo Size Authorized Distributor

Page Header Logo Size

Page Header Size

Proof that the
Page Header Logo Size

company you
keep says a
lot about your
Page Header Logo Size

company.
Page Header Size

Come to Mouser for what’s next from these industry leaders.

Sub Header Size

mouser.com

Mouser and Mouser Electronics are registered trademarks of Mouser Electronics, Inc. Other products, logos, and company names mentioned herein, may be trademarks of their respective owners.

PAGE HEADER SIZE

 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

#include 7
Making necessary resource
tradeoffs
EMBEDDED SYSTEMS DESIGN BY COLIN HOLLAND
VOLUME 25, NUMBER 4 ESD magazine is closing. Here’s
MAY 2012 why it’s a good thing for you.

parity bit 9
Special Issue: Dawn of an era: Embedded
Systems Programming and ESC
Rebuilding the embedded BY TED BAHR

development community How the magazine got its start.

barr code 10
Coinciding with plans to reinvent

7
Trends in embedded
Embedded.com as a powerful software design
online community, we explore BY MICHAEL BARR
trends, challenges, and community Auto-generated code is the future of
in this final issue of the magazine. embedded systems software design.
Colin Holland explains. murphy’s law 19
Murphy’s Last Column
BY NIALL MURPHY
Users have adapted to new user-interface
technology. What’s next in usability?

significant bits 22
So this is progress
BY JIM TURLEY
Embedded systems are evolving but
new design methods .

programmer’s
toolbox 25
How I got embedded:
a special connection
BY JACK CRENSHAW

13 What a firmware curriculum would look like Experience the quirks of life in early
days of embedded systems.
BY BOB SCACCIA
Using social media, firmware engineers are organizing themselves programming
to design a firmware curriculum for next generation. pointers 33
Unexpected trends

16 Shifting sands: Trends in embedded systems design

BY DAVID BLAZA
Armed with 15+ years of data from the Embedded Systems Design
BY DAN SAKS
Reader surveys reveal some surprising
language preferences.

subscriber study, ESD’s publisher traces big trends that fizzled out break points 36
in the past or are looming large for the near future. Farewell, ESD
EMBEDDED SYSTEMS DESIGN (ISSN 1558-2493) print; (ISSN 1558-2507 PDF-electronic) is published 10 times a year as follows: Jan/Feb, March, April, May, June, BY JACK G. GANSSLE
July/August, Sept., Oct., Nov., Dec. by the EE Times Group, 303 Second Street, Ste 900, 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 10 issues. Canadian/Mexican orders must be accompanied by payment in U.S. funds with additional The MVP of ESD and Embedded.com
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 to EMBEDDED SYSTEMS DESIGN, EE Times/ESD, PO Box #3609, Northbrook, IL 60065-3257, embedsys@omeda.com. For cus-
reflects on print versus online.
tomer service, telephone toll-free (847) 559-7597. 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 trademark owned by the parent company, UBM Electronics. All material published in EMBEDDED SYSTEMS
DESIGN is copyright © 2012 by UBM Electronics. All rights reserved. Reproduction of material appearing in EMBEDDED SYSTEMS DESIGN is forbidden without permission.
 INDUSTRIAL AEROSPACE SYSTEM ON A CHIP

MEDICAL AVIATION CONSUMER

THREADX: WHEN IT
REALLY COUNTS
When Your Company’s Success, And Your Job, Are On The Line -
You Can Count On Express Logic’s ThreadX® RTOS
Express Logic has completed 14 years simply must succeed. Its royalty-free
of successful business operation, licensing model helps keep your BOM low,
and our flagship product, ThreadX, T H R E A D and its proven dependability helps keep
has been
been usedusedin inover 8001 million
over billion your support costs down as well. ThreadX
electronic devices and systems, repeatedly tops the time-to-market results
ranging from printers to smartphones, from single-chip reported by embedded developers like you. All the while,
SoCs to multiprocessors. Time and time again, when Express Logic is there to assist you with enhancements,
leading manufacturers put their company on the line, training, and responsive telephone support.
when their engineering team chooses an RTOS for their
next critical product, they choose ThreadX. Join leading organizations like HP, Apple, Marvell, Philips, NASA,
and many more who have chosen ThreadX for use in over 800
Our ThreadX RTOS is rock-solid, thoroughly field-proven, million of their products – because their products are too
and represents not only the safe choice, but the most important to rely on anything but the best. Rely on ThreadX,
cost-effective choice when your company’s product when it really counts!

Contact Express Logic to find out more about our ThreadX RTOS, FileX® file system, NetX™ Dual IPv4/IPv6 TCP/IP stack, USBX™
USB Host/Device/OTG stack, and our PEGX™ graphics toolkit for embedded GUI development. Also ask about our TraceX®
real-time event trace and analysis tool, and StackX™, our patent-pending stack size analysis tool that makes stack overflows a
thing of the past. And if you’re developing safety-critical products for aviation, industrial or medical applications, ask Newnes

about our new Certification Pack™ for ThreadX.

n
Second Editio
E
REAL-TIM
ED
EMBEDD ADING
RE
MULTITH
adX for ARM, Coldfire,
With Thre
with append
ices
ctures
Now archite
PowerPC
MIPS and

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

M
CD-RO
INCLU DED

Copyright © 2010, Express Logic, Inc. Edward

L. Lamie

ThreadX, FileX, and TraceX are registered trademarks, and NetX, USBX, PEGX, StackX, and Certification Pack are trademarks of Express Logic, Inc.
All other trademarks are the property of their respective owners.
EE M
MBB EE D
DDD EE D
D SS YY SS TT EE M
M SS D
D EE SS II G
GNN BY Colin Holland #include
Director of Content
Colin Holland
colin.holland@ubm.com
Managing Editor
Susan Rambo
(415) 947-6675
Making necessary resource
susan.rambo@ubm.com
Acquisitions/Newsletter Editor,
ESD and Embedded.com
Bernard Cole
tradeoffs
(928) 525-9087
bccole@acm.org
Contributing Editors
Michael Barr
Jack W. Crenshaw
Jack G. Ganssle
Dan Saks
M uch importance is placed to-
day on having a good
work/life balance, yet I
would think that most engineers are
really not sure what that means—if
are using the Danny Kaye classic The
Ugly Duckling (which over winter
turns into a beautiful swan), as back-
ing track for a video that contrasts a
concept car designed in the 1920s by
Art Director you have the perfect answer please let Paul Jaray with Audi’s latest creation,
Debee Rommel
debee.rommel@ubm.com me know! I only bring this up as this the A5. It might be a bit over-egging
Production Director month we have to face the hard reali- the analogy that the changes we have
Donna Ambrosino ty of another balancing act. With re- planned in our own project “Swan”
dambrosino@ubm-us.com
ducing revenue from advertising in will be equally dramatic.
Article submissions
After reading our writer’s guidelines, send
regular print publications like ESD, In fact, while the look and feel
article submissions to Bernard Cole at how do we meet the justifiably high will change significantly for the bet-
bccole@acm.org
expectations of our readers? ter, it’s the content and the personal-
Subscriptions/RSS Feeds/Newsletters Our solution has been to take the ization that readers will be able to ac-
www.eetimes.com/electronics-subscriptions
challenging step of closing this print cess that will be most dramatic. Over
Subscriptions Customer Service (Print)
Embedded Systems Design magazine and concentrate our efforts the next couple of months, we will
PO Box # 3609 and expertise on improving our on- make available on the existing plat-
Northbrook, IL 60065- 3257
embedsys@omeda.com line presence: Embedded.com. form, as downloadable PDFs, all the
(847) 559-7597 For some time now, the entire ed- technical papers that have been print-
Article Reprints, E-prints, and itorial content we’ve printed here has ed in Embedded Systems Design (and
Permissions
Mike Lander also appeared online. We’ve also wit- its previous incarnation Embedded
Wright’s Reprints nessed a shift from the days when in- Systems Programming) since its
(877) 652-5295 (toll free)
(281) 419-5725 ext.105 teresting debates occurred in these launch in 1988. We’ll also make avail-
Fax: (281) 419-5712 pages to today when the active ex- able as PDFs all the papers that have
www.wrightsreprints.com/reprints/index.cfm
?magid=2210 change of views happens almost in been presented at the Embedded Sys-
Publisher
real-time online. tems Conference since it first saw the
David Blaza With the time and expertise freed light of day in 1989.
(415) 947-6929 With the new platform, you’ll be
david.blaza@ubm.com
up by not putting print-ready pages
together, going through numerous it- able to save interesting articles to your
Associate Publisher, ESD and EE Times
Bob Dumas erations, and meeting fixed deadlines, personal library, discuss techniques in
(516) 562-5742 we will greatly improve what we can our re-established forums, and down-
bob.dumas@ubm.com
offer you at Embedded.com. load code from our upgraded and ex-
These improvements will be crys- panded code library. We’re planning
tallized in the next few months as we other features, but more of that later. I
prepare to extract Embedded.com encourage you to make your own
from its adopted home of EE Times suggestions as comments to this col-
Corporate—UBM Electronics and once again establish it under its umn, which is also online.
Paul Miller Chief Executive Officer
David Blaza Vice President own URL and personality. While looking back provides con-
Karen Field Senior Vice President, Content
Felicia Hamerman Vice President, Marketing At present, Audi cars in Europe text, it will be what we provide today
Brent Pearson Chief Information Officer
Jean-Marie Enjuto Vice President, Finance Colin Holland is the director and in the future that makes us proud
Amandeep Sandhu Director of Audience Engagement & of content for Embedded
Analytics
of our motto: Embedded.com—The
Barbara Couchois Vice President, Partner Services & Systems Design magazine,
Operations Embedded.com, and the Official Site of the Embedded Devel-
DesignWest and East (which opment Community.
Corporate—UBM LLC
Marie Myers Senior Vice President, includes the Embedded
Manufacturing Systems Conferences).
Pat Nohilly Senior Vice President, Strategic You may reach him at
Development and Business
Colin Holland
Administration colin.holland@ubm.com.
Colin.holland@ubm.com
www.embedded.com | embedded systems design | MAY 2012 7
 Get current,
without the hassle.
With Digi-Key’s Continuing Education Center, catch up to 180 days of free,
interactive courses engineered by Design News, starting January 2012.
Build your engineering know how. Take one or all. It’s your choice.

Tracks include: Microcontrollers Basic, Microcontrollers Advanced, MEMS Sensor

Technology, Lighting, Embedded Internet and Cloud, Wirelesss, and Power.

REGISTER AT
DesignNews.com/dkcec

FOLLOW US
@DigiKeyCEC

Digi-Key Continuing Education Center

Design News is a registered trademark of UBM plc © 2012


Dawn of an era: Embedded Systems
Programming and ESC
O ne day in late 1987, Computer
Language magazine editor JD
Hildebrand walked up and
down the halls of the Miller Free-
man publishing company with a
gleam in his eye, saying that we
needed to launch a newsletter on
embedded programming. JD had
been convinced by some of the com-
piler guys at Intel that embedded
programming was different—very
different—from traditional software
development and no one else “got
it.”
I knew these Intel guys because
I’d been trying to sell them ads for
years into various magazines. They
continually explained how cross
compilers were different and,
without the modern aid of re-
sources like Wikipedia, I just nod-
ded and walked away shaking my
head, also not getting it.
Over the previous few year, I
had collected a series of advertise-
ments talking about debugging,
emulation, and microprocessor-
based development that used
terms like real-time and firmware. I
didn’t know what they meant, but I
maintained folder full of them for
the day when I would understand
and maybe one day start a magazine
on the topic (I had many such fold-
ers).
Hearing JD’s description, I ran
out into the hall with my file burst-
ing with ads and said, “forget the
newsletter, let’s start a magazine!”
It took a few months to do the
research and a few more to explain
to the Miller Freeman executives
! We decided that the
more modern term
!
“embedded systems”
made more sense than
! firmware or real-time
systems.
what an embedded system was, but
we finally got approval. We had
spent a lot of time thinking about
the publication’s name because we
suspected that we would be defining
the market. We decided that the
more modern term “embedded sys-
tems” made more sense than
firmware or real-time systems, and
we attached the word “program-
ming” to definitively mark this as a
software magazine. No capacitors!
With the blessing of our soft-
ware development magazine guru PJ
www.embedded.com | embedded systems design | MAY 2012
parity bit
Plauger, JD pulled together the
columns and design and I went
about selling the ads for the first
issue.
We didn’t know what to expect
and we boldly projected 30 ad pages.
But unbeknownst to me, there was a
large and rabidly competitive market
for in-circuit emulators and those
vendors came roaring into the first
issue. We closed the ad sales for that
issue at 41.4 ad pages.
The magazine had truly struck a
chord and circulation, which started
at 25,000, began to rise almost im-
mediately.
In the fall of 1988, our team at-
tended the Wescon show, which was
beginning its long slow decline. See-
ing the absence of any software, JD
and I typed out a business plan on a
Tandy 100 for the first Embedded
Systems Conference. The only issue
we tussled over was the name. JD
thought it should be ROMDEX!
To get approval I had to guaran-
tee that we would have at least 150
people show up and I told manage-
ment that, if necessary, I would per-
sonally call people to make sure we
hit that number. We got the ap-
proval.
Our first conference brochure
was eight pages, black-and-white,
and truly low budget; but we got
about 325 people to come to the
event at the tiny Sir Frances Drake
Hotel in San Francisco and sold out
the small show floor. Wind River,
even then trying to make it’s own
unique splash, had its own room
CONTINUED ON PAGE 12
9
 barr code
Trends in embedded software design
I n many ways, the story of my ca-
reer as an embedded software
developer is intertwined with the
history of the magazine Embedded
Systems Design. When it was
launched in 1988, under the origi-
nal title Embedded Systems Program-
ming (ESP), I was finishing high
school. Like the vast majority of
people at that time, I had never
heard the term “embedded system”
or thought much about the com-
puters hidden away inside other
kinds of products. Six years later I
was a degreed electrical engineer
who, like many EEs by that time in
the mid-1990s, had a job designing
embedded software rather than hard-
ware. Shortly thereafter I discovered
the magazine on a colleague’s desk
and became a subscriber and devo-
tee.
THE EARLY DAYS
In the early 1990s, as now, the spe-
cialized knowledge needed to write
reliable embedded software was
mostly not taught in universities. The
only class I’d had in programming
was in FORTRAN; I’d taught myself
to program in assembly and C
through a pair of hands-on labs that
were, in hindsight, my only formal
education in writing embedded soft-
ware. It was on the job and from the
pages of the magazine, then, that I
first learned the practical skills of
writing device drivers, porting and
using operating systems, meeting
real-time deadlines, implementing fi-
nite state machines, the pros and cons
of languages other than C and assem-
bly, remote debugging and JTAG, and
so much more.
In that era, my work as a
firmware developer involved daily in-
teractions with Intel hex files, device
10 MAY 2012 | embedded systems design | www.embedded.com
! As the magazine that
catered to embedded sys-
! tems programmers closes,
the future lies in less
!
hands-on programming and
more auto-generated code.
programmers, tubes of EPROMs with
mangled pins, UV erasers, mere kilo-
bytes of memory, 8- and 16-bit
processors, in-circuit emulators, and
ROM monitors. Databooks were ac-
tual books; collectively, they took up
whole bookshelves. I wrote and com-
piled my firmware programs on an
HP-UX workstation on my desk, but
then had to go downstairs to a lab to
burn the chips, insert them into the
prototype board, and test and debug
Michael Barr is CTO of Barr Group and a leading expert in the architecture of
embedded software for secure and reliable real-time computing. Barr is also a
former lecturer at the University of Maryland and Johns Hopkins University and
author of three books and more than sixty five articles and papers on embedded
systems design. Contact him at mbarr@barrgroup.com or read his blog at
http://embeddedgurus.com/barr-code.
By Michael Barr
via an attached ICE. I remember that
on one especially daunting project
eight miles separated my compiler
and device programmer from the
only instance of the target hardware;
a single red LED and a dusty oscillo-
scope were the extent of my debug-
ging toolbox.
Like you I had the Internet at my
desk in the mid 1990s, but it did not
yet contain much information of use
to me in my work other than via cer-
tain FTP sites (does anyone else re-
member FTPing into
sunsite.unc.edu? or Gopher?). The
rest was mostly blinking headlines
and dancing hamsters; and Amazon
was merely the world’s biggest river.
There was not yet an Embedded.com
or EETimes.com. To learn about soft-
ware and hardware best practices, I
pursued an MSEE and CS classes at
night and traveled to the Embedded
Systems Conferences.
At the time, I was aware of no
books about embedded program-
ming. And every book that I had
found on C started with “Hello,
World”, only went up in abstraction
from there, and ended without ever
once addressing peripheral control,
interrupt service routines, interfacing
to assembly language routines, and
operating systems (real-time or oth-
er). For reasons I couldn’t explain
years later when Jack Ganssle asked
me, I had the gumption to think I
could write that missing book for
embedded C programmers, got a
contract from
O’Reilly, and did–ending, rather than
starting, mine with “Hello, World” (via
an RS-232 port).
In 1998, a series of at least three
twists of fate spanning four years found
me taking a seat next to an empty chair
at the speaker’s lunch at an Embedded
Systems Conference. The chair’s occu-
pant turned out to be Lindsey Vereen,
who was then well into his term as the
second editor-in-chief of the magazine.
In addition to the book, I’d written an
article or two for ESP by that time and
Lindsey had been impressed with my
ability to explain technical nuance.
When he told me that day he was look-
ing for someone to serve as a technical
editor, I had no idea it would end up
being me.
FUTURE TRENDS
Becoming and then staying involved
with the magazine, first as technical ed-
itor and later as editor-in-chief and
contributing editor, has been a high-
light of my professional life. I was a
huge fan of ESP and of its many great
columnists and other contributors in its
first decade and believe my work
helped make it an even more valuable
forum for the exchange of key design
ideas, best practices, and industry
learning in its second. And, although I
understand why print ads don’t sup-
port it anymore, I am nonetheless sad-
dened to see the magazine come to an
end.
Reflecting back on these days long
past reminds me that a lot truly has
changed about embedded software de-
sign. Assembly language is used far less
frequently today; C and C++ much
more. EPROMs with their device pro-
grammers and UV erasers have been
supplanted by flash memory and boot-
loaders. Bus widths and memory sizes
have increased dramatically. Expensive
in-circuit emulators and ROM moni-
tors have morphed into inexpensive
JTAG debug ports. ROM-DOS has been
replaced with whatever Microsoft is
branding embedded Windows this year.
And open-source Linux has done so
well that it has limited the growth of
the RTOS industry as a whole—and be-
come a piece of technology we all want
to master if only for our resumes.
So what does the future hold? What
will the everyday experiences of embed-
ded programmers be like in 2020, 2030,
or 2040? I see three big trends that will
affect us all over those timeframe, each
of which has already begun to unfold.
!
Although you may be
programming for a 32-bit
! processor already, 8- and
16-bit processors still
! drive overall CPU chip
sales volumes.
Trend 1: Volumes finally shift to 32-bit
CPUs
My first prediction is that inexpensive,
low-power, highly-integrated micro-
controllers—as best exemplified by to-
day’s ARM Cortex-M family—will
bring 32-bit CPUs into even the highest
volume application domains. The vol-
umes of 8- and 16-bit CPUs will finally
decline as these parts become truly ob-
solete.
Although you may be program-
ming for a 32-bit processor already, it
remains the situation that 8- and 16-bit
processors still drive overall CPU chip
sales volumes. I’m referring, of course,
to microcontrollers such as those based
on 8051, PIC, and other instruction set
architectures dating back 30 to 40 years.
These older architectures remain popu-
lar today only because certain low-mar-
gin, high-volume applications of em-
bedded processing require squeezing
every penny out of BOM cost.
The limitations of 8- and 16-bit ar-
chitectures impact the embedded sys-
tems programmers who have to use
them in a number of ways. First, there
www.embedded.com | embedded systems design | MAY 2012
are the awkward memory limitations
resulting from limited address bus
widths—and the memory banks, seg-
menting techniques, and other
workarounds to going beyond those
limitations. Second, these CPUs are
much better at decision making than
mathematics—they lack the ability to
manipulate large integers efficiently
and have no floating-point capability.
Finally, these older processors also lack
the ability to run larger Internet-en-
abled operating systems, such as Linux,
as well as the security and reliability
protections afforded by an MMU.
There will, of course, always be
many applications of computing that
are extremely cost-conscious, so my
prediction is not that they go away but
that the overall price (including BOM
cost as well as power consumption) of
32-bit microcontrollers based on im-
proved instruction set architectures and
transistor geometries will win on price.
That will put the necessary amount of
computing power into the hands of
some designers and make the job easier
for all of us.
Trend 2: Complexity forces program-
mers beyond C
My second prediction is that the days of
the C programming language’s over-
whelming dominance in embedded sys-
tems are numbered.
Don’t get me wrong, C is a lan-
guage I know and love. But, as you may
know firsthand, C is simply not up to
the task of building systems requiring
over a million lines of code. Nonethe-
less, million-plus line of code systems is
where the demanded complexity of em-
bedded software has been driving our
programs for some time. Something
has to give on complexity.
Additionally, there is the looming
problem that the average age of an em-
bedded systems developer is rapidly in-
creasing while C is no longer generally
taught in universities. Thus even as the
demand for embedded intelligence in
every industry continues to increase,
11
 barr code
the population of skilled C program-
mers is on the decline. Something has
to give on staffing, too.
But what alternative language can
be used to build real-time software, ma-
nipulate hardware directly, and be
quickly ported to numerous instruction
set architectures? It’s not going to be
C++ or Ada or Java, for sure—as those
have already been tried and found lack-
ing. A new programming language is
probably not the answer either, across
so many CPU families and with so
many other languages already tried.
Thus I predict that tools that are
able to reliably generate those millions
of lines of C code automatically for us,
based on system specifications, will ul-
timately take over. As an example of a
current tool of this sort that could be
part of the trend, I direct your attention
to Miro Samek’s dandy open source
Quantum Platform framework for
event-driven programs and his (option-
al) free Quantum Modeler graphical
modeling tool. You may not like the
idea of auto-generated code today, but I
guarantee that once you program for a
state machine framework, you’ll see the
benefits of the overall structure and be
ready to move up a level in program-
ming efficiency.
I view C as a reasonable common
output language for such tools (given
that C can manipulate hardware regis-
parity bit
from page 9
filled with examples of embedded sys-
tems, all running VRTX.
I had managed to secure Andrew
Grove as a keynote speaker and as I met
him before the talk, he told me he was
nervous! I asked why and he said that
he had given hundreds of talks on In-
tel’s microprocessor/PC business, but
this would be the first keynote he ever
did on embedded systems. It may have
been the only speech on embedded he
ever gave! But he did fine and then PJ
Plauger spoke to the audience’s true
needs while wearing a very elegant wiz-
12 MAY 2012 | embedded systems design | www.embedded.com
ters directly and that every processor
ever invented for the mass market al-
ready has a compatible compiler). Note
that I do expect there to be continued
demand for those of us with the skills
and interest to fine tune the perform-
ance of the generated code or write de-
vice drivers to integrate it more closely
to the hardware.
! I predict that tools that
are able to reliably gener-
!
ate millions of lines of C
code automatically for us,
! based on system specifi-
cations, will take over.
Trend 3: Connectivity Drives Impor-
tance of Security
We’re increasingly connecting embed-
ded systems—to each other and to the
Internet. You’ve heard the hype (e.g.,
“Internet of things” and “ubiquitous
computing”) and you’ve probably al-
ready also put TCP/IP into one or more
of your designs. But connectivity has a
lot of implications that we have mostly
not dealt with yet. Probably the most
obvious of these is security.
ard’s cape with a large wooden staff.
The moment I knew we had found
something special came at the party
following the keynote. An attendee
from Minnesota, who working in a
disc drive manufacturing division of
IBM, told me he had been to Comdex,
and many other software and electron-
ics conferences but, he said, “this was
the first one where I don’t feel like a
freak.”
Even though it’s been over 10 years
since I was involved directly with Em-
bedded Systems Programming (since re-
A connected device cannot hide for
long behind “security through obscuri-
ty” and, so, we must design security
into our connected devices from the
start. In my travels around our industry
I’ve observed that the majority of em-
bedded designers are largely unfamiliar
with security. Sure some of you have
read about encryption algorithms and
know the names of a few. But mostly
the embedded community is shooting
in the dark as security designers, within
organizations that aren’t of much help.
And security is only as strong as the
weakest link in the chain.
This situation must change. Just as
flash memory has supplanted UV-
erasable EPROM, so will over-the-air
patches and upgrades take center stage
as a download mechanism in coming
decades. We must architect our systems
first to be secure and then to be able to
take downloads securely so that our
products can keep up in the inevitable
arms race against hackers and attackers.
AND THAT’S A WRAP
Whatever the future holds, I am certain
that embedded software development
will remain an engaging and challeng-
ing career. And you’ll still find me writ-
ing about the field at Embedded.com,
EmbeddedGurus.com, and on Twitter
at http://twitter.com/embeddedbarr. ■
named to Embedded Systems Design)
and ESC, I still subscribe to the maga-
zine and still get to the occasional con-
ference to see “my baby.” ■
Ted Bahr is the co-founder and served
as publisher of Embedded Systems Pro-
gramming magazine and director of the
Embedded Systems Conferences for the
first eight years of their lives. He left
Miller Freeman to start BZ Media, which
publishes SD Times, Software Test & Per-
formance, and Systems Management
News. Bahr can be reached at Ted@bz-
media.com.
 feature

Using social media, firmware engineers come together to design a

firmware curriculum for embedded systems engineering students.

What a firmware
curriculum would look like
BY BOB SCACCIA

A
standard curriculum designed to prepare firmware en-
gineers to succeed in today’s market is well over-
due. Although the number of devices with embed-
ded firmware continues to climb, the number of
firmware engineers has not. Businesses are
searching for ways to adjust their available

talent pool, but mation revolution accelerates,

many of the engineers being
pressed into service as firmware
engineers are inadequately
prepared.
This problem is unlikely to be
resolved any time soon. The price
points for MCUs and FPGAs con-
tinue to drop, as do the form fac-
tors of these devices. As the infor-
we’re seeing dramatic growth in
wireless and device interconnectiv-
ity, and, as result, wireless device
users are increasingly demanding
the ability to stay constantly con-
nected while mobile.
With complexity of systems
and code increasing, it’s critical
that we as an industry address this

www.embedded.com | embedded systems design | MAY 2012 13

 feature
A four-year curriculum for firmware engineering students. training issue directly and drive the adjustments to firmware
Courses Credits engineering education necessary to meet the demand while
ENG: College Writing 3 maintaining design integrity and quality.
Year 1, Semester 1

MTH: Calculus I 4 To gather insights and information on this topic, I’ve

CHM: Chemistry I 4 taken advantage of the communications speed and flexibili-
CHM: Chemistry Lab 1 ty of LinkedIn, one of the Internet’s leading professional
networks. Through several of LinkedIn’s firmware-related
Fundamentals of Engineering 3
groups, I have led multiple discussion threads and created
Total 15
several surveys to raise a number of critical questions. What
ENG: Technical Writing 3
exactly is firmware? Has it ever been precisely defined or
Year 1, Semester 2

CIS: Introduction to Programming 4 pinned down? Has the demand for firmware engineers gen-
PHY: Physics 4 uinely increased? Will this high demand last? What areas to-
PHY: Physics Lab 1 day are experiencing the greatest growth? Is a full-fledged
CE: Digital Design I 4 degree in firmware engineering critical? Would a minor
Total 16 course of study or a certification program be sufficient?
COMP: Computer Architecture 4 Who are these creatures we fondly call “bit-heads.” Where
Year 2, Semester 1

COMP: Digital Design Lab 1 do they come from? Where should they come from?
MTH: Differential Equations 4 I also used more classic techniques for collecting infor-
EE: Circuit Analysis I 4 mation, including my own 20+ years of firmware develop-
ment experience, as well as input of some of my colleagues
CIS: C Programming Language 4
from the academic, entrepreneurial, and business arenas. My
Total 17
expert advisors included Dr. Marvin Schwartz and Robert
FIRM: Assembly Code 4
Bowser (see sidebar below).
Year 2, Semester 2

MECH: Statics & Dynamics 4 The result of my research is a curriculum (shown in Table
EE: Circuit Analysis II 4 1) that I freely admit is only a starting point, subject to critical
COMP: Digital Design II 4 feedback and debate. I came up with list of coursework via a
COMP: Digital Design Lab 1 combination of feedback from my LinkedIn group, my inter-
Total 17 view with Dr. Schwartz (especially the Art of Computer Pro-
FIRM: Firmware Data Structures & Algorithms 4 gramming portion of the curriculum), and my general knowl-
Year 3, Semester 1

CIS: C++ Programming Language 4 edge from my years of experience in this field. Some IEEE
EE: Microelectronics I 4 members suggested I work on developing a curriculum with a
EE: Microelectronics Lab I 1 team of other firmware engineers. I’m building a team that
FIRM: Knuth’s Art of Computer Programming, Vol 1 4
Total 17
ABOUT THE CONSULTING EXPERTS
CIS: C++ Programming Language 4
Year 3, Semester 2

Dr. Marvin Schwartz is the chief science officer at

FIRM: Microcontroller Firmware Design 4
the Youngstown Business Incubator and the Case
FIRM: Microelectronics Lab II 1
Connection Zone. He is a serial entrepreneur with a
FIRM: Knuth’s Art of Computer Programming, Vol 2 4
history of launching successful technology ventures
EE: Systems and Signals 4 and is best known as being the founder, CEO and
Total 17 CTO of Noteworthy Medical Systems, an electronic
Year 4, Semester 1

FIRM: Hardware Design Languages 4 health record company. Dr. Schwartz received his
FIRM: Microelectronics Lab III 1 PhD in computing and information sciences from
EE: Control Systems 4 Case Western Reserve University, where he serves as
FIRM: Knuth’s Art of Computer Programming, Vol 3 4 an adjunct professor of computer sciences.
Total 13 Robert Bowser is a senior director of controls
technology at Steris Corporation. Prior to joining
Year 4, Semester 2

FIRM: Digital Signal Processors 4

FIRM Real-Time Operating Systems
FIRM: Microelectronics Lab V
FIRM: Knuth’s Art of Computer Programming, Vol 4
Total
Table 1
4 Steris, Rob was a senior manager at Cisco Systems,
where he was responsible for the development of
1
platform software and feature software, as well as
4
defining the feature roadmap for Cisco’s $500+ mil-
13
lion enterprise wireless access points business.

will eventually petition IEEE to complete
the curriculum. We currently have 15
colleagues who have expressed interested
in building this curriculum.
Here are some of the findings I’ve
gathered to the questions I asked the
group and advisors.
WHAT IS FIRMWARE?
Defining firmware is no small task. The
IEEE defines firmware thus: The combi-
nation of hardware devices and computer
instructions and data that reside as read-
only software on that device . . . the con-
fusion around this term has led some to
suggest that it be avoided altogether.
Firmware has also been defined as the
fixed, usually rather small programs
and/or data structures that internally
control various electronic devices.
When definitions use words such as
usually, often, small, and avoid, it’s a
good indication we need to go back to
the basics to define the term.
I posed this question to the
Firmware group on LinkedIn, both in
discussion threads and in survey form.
After weeks of online debate, no clear
definition emerged on which the ma-
jority of engineers responding could
agree.
With that in mind, let me share
some of my findings that I feel may
help in building a foundation. After
much discussion and attempts to de-
fine the term, I decided to create a poll
using the definitions that had found
the greatest support in the discussion
threads. Among the 148 firmware engi-
neers who participated, the most popu-
lar definition, with 81 percent accept-
ance, was the one provided by Arthur
Sittler (a firmware engineer from the
LinkedIn group): Firmware is program-
ming stored in nonvolatile storage that
the end user is not generally expected to
change at run time.
This focus on persistence and stor-
age has been nearly constant in all the
discussions I have had. The only notable
exception was provided by Robert
Gezelter, who made a compelling argu-
ment: The storage mechanism is a thin
reed to grasp for classification . . . The ety-
mology of “firmware” is, in essence, “soft-
ware embedded in hardware.” FPGA con-
figuration information is part of that
continuum, as are many other realiza-
tions of hardware-dependent encoding.
During my discussion with Dr.
Schwartz, he presented the following
definition: I define firmware as anything
that comes with a device, any device that
the end user is not likely to change or
would have to know something unusual
to be able to change.
Dr. Schwartz had no awareness of
my survey or the online discussion and
was not a member of the Firmware
group at the time of our discussion. I
will not attempt piecing a definition to-
gether from these gentlemen’s contribu-
tions, but suffice it to say that constancy,
hardware dependency, and device pro-
gramming are probable elements.
FIRMWARE ENGINEERS
If firmware engineers are not receiving
formal education specific to the field,
what is the most common degree that
they hold? Answering this question will
give us some guidance on the prevailing
skills a firmware engineer should have.
Again, I drew upon the wisdom of the
Firmware group to help answer this
question, shown in Table 2.
Clearly, the majority of firmware
engineers come out of the field of elec-
trical engineering and a large minority
comes from the computer disciplines
(namely computer engineering and sci-
ence).
Not coincidently, here is what Dr.
Schwartz had to contribute to this dis-
cussion: A curriculum in firmware en-
gineering needs to have an electrical
engineering core—computer science
today starts too high. Secondarily,
computer science will create bad
habits. Start below assembly level and
build up from there. Computer science
doesn’t even begin to explain to you
how computers work.
As will be discussed later, Dr.
Schwartz made it very clear that the art
of programming would play a very cru-
www.embedded.com | embedded systems design | MAY 2012
feature
Firmware engineers by degree.
Electrical Computer Other Total
Minor/Option 2 5 2 9
Bachelors 19 3 7 29
Masters/PhD 11 5 2 18
32 13 11 56
57% 23% 20%
Table 2
USING SOCIAL MEDIA TO
CREATE LOCAL MEET-UPS
FOR ENGINEERS
Say social media and engineers
typically cringe. Or do they?
Firmware engineer Bob Scac-
cia and members of the Firmware
group that Scaccia initiated on
LinkedIn are embracing the profes-
sional social media site to organize
in person meet-ups and online dis-
cussions about technical and not-
so-technical topics relevant to em-
bedded systems firmware
development. Scaccia, who moder-
ates and keeps the discussions go-
ing on the site, used the LinkedIn
group specifically to organize a lo-
cal firmware group in his home
state of Ohio. “Our group here in
Northeast Ohio has190 mem-
bers,” he said. “We’ve met several
times, and I’ve arranged to have
speakers attend and provide some
training.”
To further the profession, Scac-
cia has also started a firmware-
community website called Firmware
Planet (www.firmwareplanet.com)
where he has set up a consultants’
and contractors’ database.
Firmware practitioners will be able
to upload information about their
expertise and connect with other
firmware engineers and customers.
The consultants registry has about
100 members. —Susan Rambo
cial role in a firmware curriculum. But
he also agrees with most other engi-
neers that it would start with electrical
CONTINUED ON PAGE 35
15
 feature

Armed with over 15 years of data from the Embedded Systems Design
subscriber study, ESD’s publisher traces trends and preferences of
embedded systems developers and industry vendors.

Shifting sands:
Trends in embedded
systems design
BY DAVID BLAZA, PUBLISHER, EMBEDDED SYSTEMS DESIGN

I
am prompted to write this short review of embedded systems
design trends for two reasons: first, to mark a milestone, and
second, purely out of curiosity about the embedded systems
market—how it evolved and where it’s going. This magazine
itself is the milestone to which I refer. May 2012 is the last
print issue of Embedded Systems Design (ESD, originally Em-
bedded Systems Programming), after 24 years in print.

How sad a milestone it is for you depends upon
your relationship with this particular print maga-
zine and the rapidly changing world of print
publications in general. Although this may be a
farewell to print, I assure you that the energy and
talent we put into serving you in print will increase
online, now and for many years to come.
To be crystal clear, the magazine will not be
printed and mailed from now on; nor will it be
available as a digital edition. The website and
community on Embedded.com, however, contin-
ues to thrive (with 3x the readership the maga-
zine ever had). The Embedded Systems Confer-
ence (ESC), which was launched in 1989 by the
same Miller Freeman publishing team that
spawned the magazine, also continues to grow
and evolve with new outposts in India and Brazil
that have bright futures.
Why close the print publication, then, if oth-
er areas are thriving? The simple answer lies in
pure economics. ESD, always a free magazine for
qualified readers (known as controlled circulation
in the media business), was supported by print
advertising, and the number of advertisers who
run print ads has fallen to a level that can’t sus-
tain the business model. Luckily for you, the

16 MAY 2012 | embedded systems design | www.embedded.com


reader, the same high-quality content
that was the foundation of the maga-
zine will continue online.
The second reason for this history is
to share what ESP/ESD readers and ESC
attendees have had to say over the last 15
years through our the annual subscriber
survey. The survey, started by ESP maga-
zine in the mid-1990s, became an annual
rite of passage for the industry as we
asked the magazine readers and confer-
ence attendees what hardware and soft-
ware they were using and considering,
and what their challenges were. Over the
last five years, I’ve had the pleasure (and
pain) of shepherding the survey through
its many stages and then trying to make
sense of it for readers, vendors, and in-
dustry watchers. The survey has its fans
and detractors, and many people in the
industry will see the data in a different
light, so I encourage you to comment on
this article on Embedded.com.
In 1997 (the earliest study we can
find), we mailed a floppy disk (really, re-
member those?) and a crisp $2 bill to
1,000 readers of the magazine. In a direct
reflection of how much the readers were
engaged with the magazine, we got a
43.4% response rate—truly incredible
and unlikely to be ever repeated in the
history of market research. We’re going
to look then at the study data from 1997
to 2012 and stir some emotion and opin-
ion about the embedded systems design
market. Broadly, the trends we should
look at are software, hardware, tools, and
challenges.
SOFTWARE LANGUAGES
In 1997, 80% of respondents were using
C. Fifteen years later that number is still
65%, so C is still the dominant language
used for programming embedded sys-
tems.
But what happened to C++? Back in
the day, 35% were using C++ and now its
20%, so C++ didn’t take hold. A Java
“bubble” peaked in 2004 with 20%
thinking they may use it next, but Java is
now down in the noise again at 2%. The
promise of Java in embedded systems was
huge and logical at that point in time but
never delivered on the “write once, run
anywhere” promise. One of the great
mysteries of the embedded market is why
design teams don’t migrate all code de-
velopment to new tools like MATLAB or
LabView and free themselves of the
drudgery of C? Our guess is the legacy
code base is large and needs to be sup-
ported and that it would take a very brave
engineering team to abandon all that
code and risk a failed project. My take is
that one day many design teams will have
to (and should) bite that bullet, painful
and scary as it may seem.
! I wanted to share what the
readers and conference
!
attendees have had to say
over the last 15 years.
OPERATING SYSTEMS
Here is a topic that should get everyone
fired up! Back in 1997, Wind River was
the top used and considered RTOS (20
and 24% respectively) followed closely by
pSOS. Wind River’s VxWorks remained
king of the hill until 2006 (peaked at
26%) but has seen a gradual decline since
then and is now only used by 11% of our
readers. pSOS was acquired by Wind Riv-
er and despite valiant attempts by some
companies to keep licensed versions alive,
it faded away. There was a time that the
industry thought Microsoft would make
a big play for the embedded systems mar-
ket but their interest was spasmodic
peaking in 2006 (with WinCE), and they
show few signs of interest in the market
today. So what about open source you
say? In 1997, we didn’t even ask the “Lin-
ux” question but by this year 56% of you
are using Linux in some shape or form
and it seems to have stabilized at that lev-
el, the big growth years were from 2004
onward when we started to see double
digit usage of some form of Linux.
One OS has maintained a roughly
20% hold on the market and that’s “in-
house”—confusing I know, but it is what-
ever you define it as. All that homespun
code and intellectual property is locked
www.embedded.com | embedded systems design | MAY 2012
feature
into your devices so you’re understandably
reluctant to throw it out. In 2012, the hot
OS is Android; it reminds me of the Java
wave discussed earlier and makes me won-
der if Android will also be a passing fad.
MICROCONTROLLERS
Many people believe that the real embed-
ded industry began with the broad avail-
ability (and affordability) of 8-bit micro-
controllers primarily the 6800 from
Motorola in the mid 1970s and the Intel
8051 from 1980 on. By the time we did
our first survey in the 1990s, half of our
readers had used or were planning to use
the 8- or 16-bit versions of the Motorola
68HCxx or Intel 80xx controllers. There
was a robust set of tool and emulator
suppliers during those years but most
have now merged, disappeared, or been
acquired by a silicon vendor (more on
this later).
In the first survey (1997), which was
dominated by Motorola and Intel, we see
the emergence of Microchip, which had
20% market share and Zilog with 15%.
Interestingly the use of 32-bit parts was
in its infancy, but most designers had at
least tried or were considering migrating
to the 32-bit architecture (a few were
looking at 64-bit and still are!). By the
time we get to this year’s study only 13%
of readers were using 8 bit, 16% using 16
bit, and 63% are at 32 bit. We have been
asked many times over the years how
long 8- and 16-bit parts will endure and
frankly it could be for many more years
as those parts continue to evolve and
prices fall.
What we’re seeing is strong growth in
the number of ARM-based processors
(SOCs really), and the number of ven-
dors who offer their own ARM variants is
increasing all the time. Let’s not forget
that in our top 10 Microchip has made a
good showing with the MIPS architec-
ture and Intel is still in the running with
ATOM, which it’s pushing down the
power curve to stay in the hunt.
TOOLS
There was a time in embedded when
both large companies and startups saw
17
 feature
opportunity in tools, debuggers, OSes,
and emulators, the magazine was full of
companies advertising their products,
such as Nohau, Huntsville Micro, and
even Hewlett-Packard. So where are all
those vendors today? To understand any
market, you need to follow the money
and ultimately in embedded the money
has remained with the hardware ven-
dors. They have either purchased, li-
censed, or developed many of the tools
needed to get that all-important design
win. This trend has been hard on inde-
pendent software vendors of all kinds
and with Intel’s acquisition of Wind
River last year, it does make us wonder
what the future looks like for those few
brave software businesses who are
caught between open source and the
hardware giants battling for share. De-
spite this, your favorite tools are consis-
tently compilers, oscilloscopes, and de-
buggers. We think this is because it’s
where you spend the bulk of your time,
so you have to learn to use and to live
with them.
FPGAS, MEMORY, AND LCDS
Over the years it looked like the phe-
nomenal success of Xilinx and Altera
and the lure of programmability would
attract designers, but this year’s study
points to a declining interest in FPGA’s.
The perennial criticism of FPGA’s in
embedded was always threefold; too
hard to program, too expensive, and
too power hungry. It’s going to take
some creativity and innovation for the
FPGA vendors to overcome these preju-
dices. FPGAs have been incredibly suc-
cessful in the communications and mil-
itary markets where programmability is
a huge advantage, but we’re seeing new
generations of ARM-based microcon-
trollers with clever programmable com-
munications and analog blocks being
offered at very low prices that will keep
the FPGA vendors on their toes.
Over the years we’ve also asked read-
ers about their use of memory and LCDs
but if we’ve learned one thing, it’s how
the specs, not brand, drive these deci-
sions. Few respondents have expressed
18 MAY 2012 | embedded systems design | www.embedded.com
any preference for a vendor. After all, en-
gineers are driven by rational and logical
decisionmaking, or so they tell us!
ECOSYSTEMS
Over the last few years as it became clear
that embedded systems are really a col-
lection of many kinds of software, hard-
ware, and tool chains, so we’ve asked the
“ecosystem” question. What we mean by
this is which vendors offer you the best
environment for getting your design
completed and its very telling that in the
results (unaided by the way) that of the
!
The biggest shift is the • Embedded designers have even more
move to open-source code.
! 37% of teams think their
next OS will be open-source. •
top 10 answers only 1 was a software
vendor (actually a tool vendor, IAR).
This finding seems contrary to the data
we see which shows most of the effort
(60 to 70%) goes into writing code so
why would the hardware vendor’s
ecosystem be so top of mind? Is it the
only place where all the interdependen-
cies in design come together?
CHALLENGES
Finally, the consensus is that the largest
challenge (and overwhelming enemy)
of design teams face is the “schedule.”
For three years in a row, 58% of all
projects were late or cancelled. That’s a
pretty poor average in any industry.
Why is this happening? Recent studies
point to a skill-level issue. But, I predict
it may also be all that legacy code sink-
ing the project timeline. This year, we
asked about project management tools;
after Microsoft Project, a full 40% of
you were using Excel as a project tool,
which shocked us but was roundly de-
fended by some teams because its cheap
and everyone has it!
CLOSING THOUGHTS
This year’s study (all 89 slides) is avail-
able for download along with our annual
webinar, which distills all our findings
into a quick 30-minute PowerPoint (on-
line at www.eetimes.com/4369712).
Therefore, after 15 years of surveying
this market, what can we say about the
current state of the industry and where
it’s heading? The embedded systems
market is very conservative and changes
slowly, but we can see some broad trends:
• More systems are connected to the
web with 65% of design now includ-
ing some form of Wi-Fi connectivity
(Bluetooth, cellular and ZigBee make
up the next three).
reasons to move to 32-bit processors
these days (and the price differential
shrinks every day).
Perhaps the biggest shift is the move
to open-source code. The numbers
show that more design teams (37%)
think their next OS will be some fla-
vor of open-source compared with
31% using a commercial OS. This
trend is fueled by many silicon ven-
dors who offer their latest hardware
with a free OS/RTOS loaded up and
ready to go. It’s hard to beat free, and
if designers become comfortable
with the support issues and tool
chains, its going to become com-
monplace for design teams to take
the hardware/software bundle.
A much deeper question is “what
happens to the for-profit embedded soft-
ware business?” I don’t have the answer
but the remaining players (remember
Wind River is now owned by Intel) are
going to have to examine their business
models intently over the next year or so
and really figure out how to add value
that designers will pay for.
I’m sure I’ve missed something here
that may be particularly important to you,
so, leave a comment on Embedded.com
when this article is posted. ■
David Blaza is the vice president of UBM
Electronics and publisher of Embedded
Systems Design magazine. You may reach
him at david.blaza@ubm.com.
By Niall Murphy
murphy’s law
Murphy’s Last Column
Editor’s note: Niall Murphy started writing The general population has been
about user interface design for Embedded
exposed to the idea of an app market
Systems Programming magazine in 1995.
He wrote the column Murphy’s Law for phones, and this concept has influ-
(archived at www.eetimes.com/4210709/ enced the way we think about updat-
and at www.panelsoft.com/murphyslaw). ing the software on our computing de-
vices. The previous way of getting new

L ooking back at the years when I

wrote the Murphy’s Law column,
I wondered about whether the
challenges of designing embedded sys-
tems have changed. Much of my work
is in the usability area, and we can be
lured into thinking that basic human
psychology does not change over the
years and so the same usability princi-
ples that worked 10 years ago still ap-
ply. However, the technologies and
concepts that the general population
has been exposed to has changed dra-
software onto a dedicated device was
an unwieldy flash upgrade that re-
quired the user to manage the down-
load usually with the assistance of an
Internet-connected PC—and it was
typically a complete upgrade with no
flexibility to choose which compo-
! Niall looks at the changes in
user interface technology
nents or applications you wanted.
More powerful processors make it
practical to run a full-featured operat-
! over the past few years and
makes a few predictions
ing system instead of just a real-time
kernel. This opens up a lot of potential
for integrating existing applications

!
matically. People’s expectations move into a product—in many cases the ap-
forward as their relationship with about application upgrade plications are far too large and com-
their personal devices evolves. Some- and cloud connectivity. plex for the manufacturer of the end-
one who glances at their smart phone product to develop themselves. For
to see the weather forecast and the lat- example the Linux version of some
est pictures from a friend’s social net- multiple unrelated areas. The screen in popular sat-nav products can be inte-
work has vastly different expectations my car can function as a DVD player, a grated into systems like the in-car
of technology than someone who sat-nav, and a display for a reversing computer I described. They provide
treated a phone as something only camera, as well as giving access to a APIs to allow the application to be
used for spoken conversation. range of air-conditioning and other controlled by the custom hardware of
The term dedicated device is used comfort controls. In fact, the model that system and to provide signals to
to describe embedded systems that presented to me as a user is of a single the application when, for example, the
have a sole purpose; it’s a term I often device capable of running several dif- ignition starts or stops. Similarly the
found useful for systems I worked ferent unrelated applications. We’re developer of the in-car system does
on—they aren’t general purpose com- used to the concept of running multi- not want to face the challenges of writ-
puting devices like a personal comput- ple applications on a PC, and this con- ing software to play a DVD. This range
er or a tablet computer but have a sole cept has become popular on smart of applications can come from a di-
purpose to fulfill. As with the smart phones, but a combination of forces verse set of vendors as long as the plat-
phone, however, the feature set of a lot are making this model attractive on form is based on a well-established op-
of devices is expanding to try to cover many other systems. erating system.
At the moment, the markets for
Niall Murphy, a software engineer, has been designing user interfaces for standalone apps is in the smart phone
20 years. He is the author of Front Panel: Designing Software for Embedded and tablet market—but now that the
User Interfaces, has written over 50 magazine articles (many for this mag- population has been seeded with peo-
azine), and currently writes the blog Usability Bites (http://embeddedgu-
rus.com/usability-bites/). Murphy teaches and consults on building better ple who understand the model, don’t
user interfaces and has been a frequent speaker at the Embedded Systems be surprised if your Android-powered
Conference. For more information about him, go to www.panelsoft.com. in-car computer or set-top box allows
Niall can be reached at nmurphy@panelsoft.com.

www.embedded.com | embedded systems design | MAY 2012 19

 murphy’s law
you to download apps that have been
written for that device. The goal in
those cases is not to create a market
with tens of thousands of applications,
but to provide a software-deployment
model that allows the end user the flex-
ibility to include the features they want
on their device and to leave out the fea-
tures that only appeal to others. It also
allows the manufacturer the flexibility
to deploy more advanced features long
after the original hardware has
shipped. Flash upgrades never got us to
that point for the majority of users, but
the flexibility of a file system for stor-
age on a general-purpose operating
system combine to make this viable. So
my next car will not just have a sat-nav,
but will give me a choice of sat-nav ap-
plications from different vendors that I
can download and use. Upgrading the
current sat-nav software will be com-
pletely independent of upgrading the
DVD player software.
IT’S ALL ABOUT THE SCREEN
Processing power is so cheap that the
car manufacturer might have consid-
ered dedicating a separate computer to
each of the applications above, but the
driving force behind the decision to
combine them is the display. The cost
of the display is a big fraction of the
overall cost. And the more money spent
on the display, the better the user expe-
rience, but for every extra square inch
of display, the greater the attraction of
channelling more applications through
that shared display. And why not put
Skype or a weather app or a fuel con-
sumption monitor app onto the display
of a connected car.
It’s not just the price and quality of
the displays where our expectations
have evolved. Twenty years ago I
worked on a system with a touch
screen, and we designed the start up
screen to contain a 3D-looking button
with the words “Touch Me” on it. Our
concern was that the user would not
realize that it was possible to touch the
screen and would fumble around look-
ing for off-screen buttons or a mouse
device. A couple of days ago I handed
20 MAY 2012 | embedded systems design | www.embedded.com
my six-year-old daughter a digital cam-
era and she was puzzled when the pic-
tures on the display could not be re-
sized with a two-fingered stretch
gesture. Expectations have changed.
WHO AM I
As we become surrounded by more so-
phisticated displays, one of the biggest
challenges is telling those devices who
we are. There is a limit to the richness
of the experience that the device can
deliver without identifying the user.
With personal computing devices you
can dodge this step since my phone is
A key contributor to the
! personalized experience
will be cloud storage.
always logged in as me. Developers of
embedded systems often have to design
for industrial or medical devices where
a different user may start the device
each day. In many cases, it’s the em-
poyer who wants more data about who
is using the device, but identifying the
user also opens up opportunities to re-
member the preferences, which are
personalized to that user.
If you want to customize the set-
tings on a per-user basis you need to
know who that user is. However once
you give the user a password, you have
to put all the infrastructure in place to
allow the password to be changed and
to give the user a path they can follow
if they forget their password, and this
infrastructure is unpleasant for the
user. Innovation in this area is going to
be driven by a combination of forces.
Employers purchasing industrial
equipment will want to know more
about who was using the equipment
and end users will want a customized
experience without having to remem-
ber a sequence of 6 to 8 characters in-
cluding one capital and one digit and
at least one non-alphanumeric charac-
ter—Oh rats i have forgotten it again,
maybe I will just stick it to a piece of
paper in front of the machine !
THE CLOUD
A key contributor to the personalized ex-
perience will be cloud storage. Ten years
ago embedded systems designers fastidi-
ously avoided having a server element in
their design to avoid forcing the cus-
tomer to deploy a server to support its
devices, or the need for the manufacturer
to provide a server somewhere on the in-
ternet, which becomes a single point of
failure and a maintenance nightmare.
Cloud computing has lowered the
barrier to entry for this server element.
Cloud computing providers such as the
Amazon Web Service make it possible to
deploy any number of computers on the
internet with no hardware outlay or con-
nectivity infrastructure concerns. The
number of computers available can grow
or shrink with demand. At the other end
of the connection, the price of hardware
and software to put an embedded system
on the internet is constantly dropping,
and many of our devices have other de-
sign reasons to be already connected, so
the incremental cost might be zero.
So what opportunities does this
open up? Consider the sat-nav applica-
tion that I use on my phone. I may have
stored favorite routes and destinations,
or a history of past journeys. If I now
switch to the sat-nav unit built into my
car, I would like to have the same jour-
neys and preferences available to me.
The fact that I’m using a different physi-
cal device is a minor detail—the device
should know who I am and present my
data. However, a typical design today
stores my data locally on the device just
used and makes it impossible to syn-
chronize the data with another instance
of the application running on another
device.
Two steps are required to move to the
synchronization scenario described above.
The first is that the storage can no longer
be local. Instead of recording journeys
on the flash drive of the device, it must
be stored on a server in some easily dis-
coverable part of the Internet. The second
piece is the ability to log in. Once you
move to the cloud, you have to identify
yourself. But no one wants to type in a
password, and so we need better solutions.
 It all Rides On the
This is one area where software alone is not sufficient.
Swipe cards and fingerprint detectors are hardware solu-
Right Technology
tions that are more secure than passwords and more user
friendly. RFID tags and other near-field devices provide
great solutions. If you walk up to a device with an RFID
tag in your pocket and the device immediately logs you in,
the user effort of logging in vanishes to zero. It’s also more
secure since the device can detect when that user has
walked away and so log them out. This is being used suc-
cessfully to identify drivers of shared commercial vehicles,
and the drivers key-ring is the obvious place to hand the
RFID tag.
If I walk into a conference room and start to use the
speaker phone to make a phone call, the RFID tag may iden-
tify me to the phone and now the phone at the other end can
receive my name and number as the caller ID instead of the
Get Pattern Recognition
TM
shared phone number of the conference room. I effectively
logged into the speaker phone simply by walking up to it. Right with CogniMem!
There are other interesting login solutions out there. (I¿FLHQWSDWWHUQUHFRJQLWLRQDQGGDWDPLQLQJGHPDQGVDGHSDUWXUHIURPWUDGLWLRQDO
Windows 8 has introduced the concept of a login picture. FRPSXWLQJWHFKQRORJ\DQGSURJUDPPLQJ:KDWWKHZKHHOGLGWRUHYROXWLRQL]H
After you enter your user name, the computer presents a WUDQVSRUWDWLRQ&RJQL0HPGRHVIRUSDWWHUQUHFRJQLWLRQ
picture that the user previously chose, and, to confirm his
identity, the user touches a few positions on the picture. For Native Parallelism for High-Performance Reduced-Energy Computing
example, when setting up my password I might decide to 0DWFKDSDWWHUQDPRQJDQ\QXPEHULQD¿[HGDPRXQWRIWLPH)RUJHWDERXWWKH
use a picture of my favorite car and point to the back door PHPRU\VL]HDQGDFFHVVWLPHERWWOHQHFNV7DNHDGYDQWDJHRIWKHQDWLYHO\SDUDOOHO
followed by touching the middle of hood followed by DUFKLWHFWXUHRIRXUFRJQLWLYHPHPRULHVIRUPDVVLYHO\SDUDOOHOGDWDPLQLQJ6HDPOHVVO\
touching one of the clouds in the sky behind the car. This VWDFN&RJQL%OR[70IRUVFDODEOHKLJKSHUIRUPDQFHUHFRJQLWLRQZLWKUHGXFHGHQHUJ\
ODWHQF\VL]HDQGFRVW
doesn’t solve the problem of users forgetting their pass-
word, but it may make it easier to remember, and it reduces 1DWLYH0RGHO*HQHUDWRUDQG5HDO7LPH&ODVVLÀHUIRU,QWHOOLJHQW6HQVLQJ
the amount of typing to be done on a device that may not
7XUQGLJLWDOLQSXWVWUHDPVLQWRYDOXDEOHLQIRUPDWLRQDWWKHVHQVRUOHYHOZKHWKHULW
have a dedicated keyboard.
LVWRDFWXDWHDGHYLFHZDUQIRUDQRPDOLHVRUVHQGRQO\UHOHYDQWLQIRUPDWLRQWRWKH
Once we have provided a login solution and cloud con-
FORXG2XUFRJQLWLYHPHPRULHVOHDUQLQUHDOWLPHIURPH[DPSOHVZKLFKHOLPLQDWHV
nectivity, I think embedded systems designers still face chal- SURJUDPPLQJDQGLPSURYHVDFFXUDF\
lenges that aren’t present in the conventional computing en-
vironment. We often need to allow for intermittent internet
Sensor Input Data Mining/Analytics
connectivity since the environment might be mobile—and
The
we don’t want to render the device unusable because our ve- Classification Cloud

hicle is in a remote area. We also may need to provide the

option of anonymous use. If the sat nav in my car does not
Identification Act
recognise the driver, maybe it makes the routes personally ADC
chosen by the previous driver unavailable to the anonymous
driver but allows this anonymous user to request new routes 1,024
cognitive
Anomaly Detection
!
CogniBloxTM
that in turn will be forgotten when the anonymous driver is memories Nothing to Declare 4 - CM1K chips/board
later replaced by a driver with who validly identifies himself. (4,096 cognitive memories)
Stack for unlimited performance

THE WAY FORWARD *HW<RXU3DWWHUQ5HFRJQLWLRQ5ROOLQJZLWK&RJQL0HP

Many of the steps forward in embedded systems makes
them more like their desktop cousins. Personalized cloud
(YDO.LW6'. Technical Training
‡&0.YLVLRQVHQVRU ‡/HDUQDERXWSDWWHUQUHFRJQLWLRQ
storage and user identification will be another progression.
Like many such advances, we can learn from having met the ‡)UHHVFDOHL0;4XLFN6WDUW%RDUG IURPWKHLQGXVWU\SLRQHHUVLQRQOLQH
‡$995ZKLOHVXSSO\ODVWV DQGFODVVURRPWUDLQLQJ
same issues on conventional PCs. Adopting these technolo-
gies will challenge us in areas like security, but the benefits
of moving our data to the cloud where it can be shared
across devices will be irresistible in many designs. ■
‡ZZZFRJQLPHPFRP
 significant bits
So this is progress
Editor’s note: Jim Turley started writing
about semiconductors for Embedded Sys-
tems Programming magazine in 1997. He
wrote the column Significant Bits (archived
at www.eetimes.com/4210710) and was edi-
tor in chief of ESP/ESD from 2004 to 2006.
A “computer” used to be a person. It
was a job description, sort of like
accountant or actuary. You hired
computers to compute things, like lists
of numbers or probabilities or statistics.
Then these computers were replaced by,
well, computers.
Now our computers outnumber us.
The average middle-class American
home has more than a hundred differ-
ent microprocessors and microcon-
trollers scattered around. There are a
half-dozen processor chips in every PC
(not just the one big one that most peo-
ple think of), plus at least a dozen
MCUs in the family car. A high-end car
like an S-class Mercedes has more than
a hundred different microcontrollers in
it, complete with their own fiber-optic
network. A $2 musical greeting card has
about as much computing power as the
Apollo 11 lunar lander.
We’ve taken computer technology
from the sci-fi laboratory to the bath-
room, from the extraordinary to the
ridiculous, all in the span of one life-
time. One career, even. Within living
memory, people were telling us that a
dozen or so computers would satisfy the
entire world demand. After all, how
many weather-prediction machines do
you really need? How many ICBM sim-
ulators? It took less than 20 years from
the time room-sized computers were
predicting missile trajectories to the
time we started playing Missile Com-
mand at the local arcade. The only
things we don’t seem to have are the
21st-century flying cars and the jetpacks
we were promised.
Now we’re just getting silly. Last
week I was handed a shaving razor—
22 MAY 2012 | embedded systems design | www.embedded.com
By Jim Turley
a hard time finding a traditional
bimetallic thermostat these days, and if
you did it would probably be for ironic
period-correctness, as if you were
restoring a 1970s-era house. Would
anyone in the 1970s have predicted that
you’d use a computer—a freakin’ com-
puter!—to control the thermostat?
Computers are cheap because sand is
cheap (okay, silicon is cheap) and be-
cause of the wonders of mass produc-
!
tion. Build enough of something and
Embedded systems are you can start to amortize the costs across
evolving in exciting a whole lot of units. Economics 101 is
what got us here. Today’s microproces-
! ways but our design
methods out of date.
sor chips are one of the most complex
things ever devised by humankind, yet
we toss them out when the batteries die.
We inject them into our pet’s neck; we
not an electric shaver, mind you, but a stick them in the handle of a razor.
traditional razor with blades—with a That’s mass production for you.
microcontroller chip and a battery in its A high-end microprocessor today
handle. The label on the box proudly has well over two billion transistors. A
proclaims it’s the “world’s first custom big FPGA can have more than six bil-
power wet shave razor,” and I’m not lion. Even low-cost MCUs include over
surprised. The surprising part is that a million transistors. Semiconductor
they had to qualify the statement so transistors are more plentiful than
much. It’s not the first powered razor; grains of rice. Congratulations, Silicon
it’s the first custom power wet shave ra- Valley, you’ve out-produced God.
zor, which means other companies beat Yet these transistors are cheaper
them to it. I’m almost afraid to try it than ink on a page (just ask any pub-
out. What is this thing going to do to lishing company). As a rough guide,
my face? And most of all… why? transistors cost about $0.00000055
Because we can, that’s why. Because apiece these days. We’re asymptotically
computers are cheaper than mechani- approaching zero cost. And really, the
cal devices. Consider the old room silicon and other ingredients that go
thermostat: two pieces of bent metal into a transistor pretty much are free.
that curl a bit as the temperature The raw materials are a negligible part
changes. What could be simpler or of the cost of chip-making. It’s the de-
more reliable? An 8-bit microcontroller sign, the labor, and—most of all—the
and 4K of code, apparently. You’d have big shiny factory that cost real money.
Jim Turley is the author of seven books, was editor in chief of the
Microprocessor Report (a three-time winner of the Computer Press
Award), was editor-in-chief of Embedded Systems Design magazine, and
is currently editor of Embedded Technology Journal and publisher of
Silicon Insider. For more about Jim Turley, go to www.jimturley.com. You
may reach him at info@jimturley.com.
 Figure on spending $3 billion to $5
billion to erect a new fab. We’re talking
space-program levels of expenditure here.
And that factory will be obsolete in just a
few years, so you’ve got maybe 36 months
to make back that $5 billion you invested.
Suddenly the cost of a little silicon and
copper doesn’t seem so bad. Instead, you
work like crazy to make chips in high vol-
ume so you can amortize that cost across
more chips. Before you know it, the chips
are almost free. Your customers are hap-
py, your salespeople are happy, and the
razor manufacturers are happy.
So where do these gazillions of little
CPUs and MCUs go, apart from bath-
room electronics? Mostly into living
rooms and, um, bedrooms. Televisions,
DVD players, game consoles, and all oth-
er sorts of living-room electronics are a
big part of the whole consumer-electron-
ics industry. The other driving force is
sex. Just as sex helped drive the market
for digital cameras, cable television, in-
stant (Polaroid) cameras, VCRs, high-
speed Internet connections, and mail-or-
der catalogs, it’s also a powerful force in
embedded systems. Hey, all those digital
cameras and cable routers need embed-
ded hardware and software, too. Some
estimates say as much as one-quarter to
one-third of the Internet’s total band-
width is consumed by porn sites, and
that stuff doesn’t download itself.
Ironically, the retailers for these
shiny new consumer gadgets are being
driven out of business by the very tech-
nology they’re selling. Online shopping,
combined with search engines and glob-
al shipping, has conspired to turn elec-
tronics stores into Amazon showrooms.
So long, Circuit City and Best Buy. Hel-
lo, UPS driver.
So where do we go from here? Have
we, as one patent examiner reportedly
said in 1899, already invented every-
thing? Hardly. The number of embedded
systems keeps growing as we devise ever-
more-clever (or increasingly silly) uses
for them. Chipmakers’ production num-
bers have been rising steadily since the
beginning of time, and chip companies
don’t make new chips unless they’re sell-
ing the old ones. More programmers are
employed today than ever before. Some-
body is giving these people work.
One good way to predict where to-
morrow’s embedded systems will go is to
look at mechanical systems of today.
What mechanical devices could be re-
placed by electro-mechanical or wholly
electronic systems? Looking again at au-
tomobiles, some cars are already using
magnetorheological suspension compo-
nents in place of springs. Like the old
thermostat, coiled springs may be dead
simple and utterly reliable, but they’re no
match for electro-mechanical equivalents
that can adjust a car’s ride thousands of
times per second. Sure, it seems silly now,
but so did in-car radios in the 1950s.
Another angle is to look at today’s
embedded systems and imagine what
they could do with two times, or ten
times, the processing power. This ap-
proach led us to the smartphones of to-
day. An Android phone or iPhone still
makes phone calls in essentially the same
way as the early Motorola “brick” phones
of decades past; that part hasn’t really
changed. What’s different is the “bonus”
processing power for games, apps, phone-
SMX® RTOS
BSPs
Device Drivers
Kernel Awareness
Simulator
Free Evaluation Kits: www.smxrtos.com/eval
Free Demos: www.smxrtos.com/demo
ARM • Cortex • ColdFire • PowerPC • x86 • IAR EWARM • CrossWorks • GCC • CodeWarrior
www.embedded.com | embedded systems design | MAY 2012
book lookup, GPS location, and more.
What would you do with an order of
magnitude more processing power in the
same size, space, and power envelope?
A third growth vector is, sadly, secu-
rity. Embedded systems are gradually,
and grudgingly, adding more security
features as they become more centrally
integrated into our financial, medical,
and personal lives. We’ve all read about
(or experienced) security breaches at
banks or credit-card processors. We’ve
overheard stories about smartphone
“Bluejacking” or how the world will be
overthrown by cyber-terrorists attacking
the power grid, etc. New technology
leads to new fears and new areas of mis-
understanding. Even benign little utility
meters with low-wattage, low-band-
width wireless connections spur outrage
from irate (and ill-informed) communi-
ty groups waving virtual pitchforks. We
are afraid of what we don’t understand.
It was ever thus.
On the plus side, the security angle
provides opportunities for a lot of embed-
Looking for the
right software for
your processor?
You’ve found it. Our software is built to
run right out of the box—no integration
required—and we provide 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 the right start. Visit
www.smxrtos.com/processors today.
TCP/IP USB Device
FAT File System USB Host
Flash File System USB OTG
GUI WiFi
C++ Support Floating Point
R T O S I N N O V A T O R S
www.smxrtos.com
23
 significant bits
ded systems programmers and hardware
designers. Certainly there is a need for some
of this. Financial transactions need to be se-
cured and the data protected better than
they are now. Most short-range wireless
connections are pretty insecure. In the early
days, that was fine. Our first priority as de-
signers is usually just to get the darned sys-
tem working. After that, if there’s time, we’ll
tweak it to make it better. Now it’s time.
The good news is, there are a lot of
new chips and software to help us along.
Low-cost microcontrollers now often in-
clude crypto hardware such as random-
number generators and AES or 3DES en-
cryption accelerators. The additional
hardware for this is essentially free, as
we’ve seen. But the added value can be
priceless. Before long, crypto and security
features will be a standard part of most
processors and interface chips, and we
won’t think anything of it.
The day may not be too far off when
the security features of an embedded sys-
tem take up more RAM and ROM space
than the “real” code itself. It’s not unrea-
sonable that a cable router, for instance,
may have 512KB of code to make the
router work, but another 4MB of securi-
ty-related features, some of which will
never get used. It seems a shame that so
much of the project’s resources are “wast-
ed” on nonessential features, but that’s
where we’re headed. Treat it as a compli-
ment: Your product is so valuable that it
requires its own anti-theft device.
What doesn’t seem to be improving is
the situation with development tools. We’ve
seen a million-fold increase in hardware
complexity, and similar gains in lines of
code per device, yet we still program our
systems in C, assembly, or (heaven help us)
Java. That’s like building the Pyramids of
Giza with stone tools. (Wait a minute;
make that building a Saturn V with bronze
tools.) Our design methods have not kept
pace with our design materials. The weak
link there is… us.
Creatures of habit are we. Regardless
of how advanced our products may be,
our methods for designing them are al-
most medieval. We cling to the same pro-
gramming languages we used in college
and the same circuit-design techniques
we used in our first job. We design mil-
lion-gate ASICs essentially the same way
we designed test circuits in undergraduate
lab. Why the inertia? Why the lack of
progress?
The fault lies not in our stars but in
ourselves. We don’t like change. Ironically
enough, a typical engineer creating to-
morrow’s newest fast-paced technology is
resistant to change. We simply prefer to
use the tools and methods to which we’ve
grown accustomed. That’s natural—peo-
ple in other professions behave the same
way—but it’s also hugely paradoxical.
We’re more productive when we use (and
reuse…) the languages, compilers, debug-
gers, and bench tests we’ve used before.
We are quite naturally building on our
own experience, and isn’t that what our
employers want? Isn’t that experience
what makes us more valuable than some
trainee fresh out of school?
Well, yes and no. Writer Douglas
Adams said, “Everything that’s already in
the world when you’re born is just nor-
mal; anything that gets invented before
you turn 30 is incredibly exciting and cre-
ative and with any luck you can make a
career out of it; and anything that gets in-
vented after you’re 30 is against the natu-
ral order of things and the beginning of
the end of civilization as we know it until
it’s been around for about ten years, when
it gradually turns out to be alright really.”
There’s a reason so many startups are
created by young college students with little
or no industry experience. They don’t have
any established history to protect. Whether
consciously or unconsciously, we protect
and defend our own habits and methods.
We know what works and we try to keep it
working through repetition. In our 20s we
learn; in our 30s we practice; and in our 40s
and beyond we dig in our heels. That’s a
bit of a simplification, but it’s truer than
many of us would like to admit.
So in the spirit of change, Embedded
Systems Design (née Embedded Systems
Programming) is making another trans-
formation. It’s transmogrifying from its
old, familiar form but that’s not a bad
thing. That’s what’cha call progress. But
somebody out there better be working on
my jetpack. ■
 programmer’s
By Jack W. Crenshaw
toolbox
How I got embedded: a special connection
A t this moment, you’re looking at
the last print issue of Embedded
Systems Design magazine. The oc-
casion is especially poignant for me,
because so much—20+ years—of my
customers were treated so shabbily. The
explanation has to do with money and
bureaucracy.
In those days, computer time was
expensive: $600 per hour. That’s in
career has been tangled up with the 1960 dollars, when a Coke cost a nick-
magazine in general, and the Program- el, gasoline 25 cents per gallon, and
mer’s Toolbox column in particular. that $600 would pay my salary for six
Some folks have been blessed (or weeks. So the priesthood tended to

!
cursed) by careers that are “linear.” guard the computer jealously. To
They start one job, stay with it, move
Take a trip through the them, we were not so much valued
up the ladder, and retire happy. Mine life’s work of one engi- customers, as necessary evils to be tol-
hasn’t been that way. It’s taken some erated, however grudgingly.
sometimes-unexpected twists and
turns—some more pleasant than oth-
ers. Not all of those directions have ! neer who was involved
in embedded systems
The systems administrator was
not judged on how many problems
that were solved, but by his ability to
had anything whatever to do with em-
bedded systems. I thought, however,
that you might enjoy hearing about
the ones that did. But first, I need to
set the stage with a little background.
! from Day 1 (courtesy of
Rambling Jack).
hood, from floor supervisors to man-
keep the computer backlog down.
Backlog, as in the number of jobs
waiting in the queue. The easiest way
to keep the backlog down was simply
to deny access to the job queue, or to
agers to that highest of all high priests, abort jobs on the flimsiest of excuses.
GIANT BRAINS the systems administrator. In one shop, I had jobs rejected be-
I’ve been involved with computers for a This was my world for the next cause the card deck had too many
long time. How long? Here’s a hint: The decade or so. Not that I actually got to rubber bands around it. Other times,
textbook for my first computer science enter the computer room, of course. too few. One computer group actually
class, in 1956, was entitled Giant Brains, That privilege was reserved for the issued written guidelines for how
or Machines That Think. Back then, the anointed. We mere engineers and sci- many rubber bands should be used,
notion of “micro brains” wasn’t even a entists were not welcome. Heck, it was per inch. The only problem was that
blip on anyone’s radar. Computers two years before I even saw the com- the computer operators didn’t follow
were—and, we assumed, always would puter, and that was from the outside of their own guidelines. So a deck they
be—monster, power-hungry machines those glass walls, looking in. My only returned to me was likely to be reject-
that filled large rooms with glass walls, contacts with it were the “keypunch ed on the next turnaround.
raised floors, and over-engineered cool- girls” who punched my card decks, Despite the oppressive, Big Broth-
ing systems. and the clerk behind the counter who er environment, we got exciting things
The computer room of 1960 felt accepted my jobs and returned their done. We did, after all, help Neil and
more like a cathedral than a place of results. If, on rare occasions, I interact- Buzz walk on the Moon. What’s more,
science, and it had its share of mysteri- ed with the priesthood, it was in it was in this environment that I
ous icons, rituals, a small army of hushed and reverent tones, and a learned my craft and developed tech-
acolytes, and a hierarchy of priest- proper air of respect. I resisted the niques that I still use today.
urge to genuflect. I did, however, take one thing away
Now, when you consider from the experience: A deep and abid-
Jack Crenshaw is a systems engi-
neer and the author of Math Toolkit that the purpose of the com- ing hatred of systems administrators.
for Real-Time Programming. He puter was, after all, to help us
holds a PhD in physics from Auburn scientists and engineers solve FIRST PERSONAL COMPUTERS
University. E-mail him at
jcrens@earthlink.net. our problems, it may seem During those oppressive years, I found
hard to understand why we a glimmer of hope and a glimpse into

www.embedded.com | embedded systems design | MAY 2012 25

 PROUD SPONSOR:

EST CELEBRATION
G

OF
T MISS THE LAR

SCIEN
CE IN THE
N’

.S.
O

U
D

GRAND FINALE

EXPO & BOOK FAIR

APRIL 28 & 29, 2012 USASCIENCEFESTIVAL.ORG
WALTER E. WASHINGTON CONVENTION CENTER, WASHINGTON, D.C.

OVER 2000 FUN HANDS-ON ACTIVITIES AND MORE THAN 100 STAGE SHOWS
MEET SCIENCE CELEBRITIES & AWARD-WINNING AUTHORS
NEW THIS YEAR: CAREER PAVILION & BOOK FAIR | A FREE EVENT

LOCKHEEDIUM K&L GATESIUM NOBELIUM EINSTEINIUM KRYPTON PLATINUM

LEGO Education Vertex Pharmaceuticals U.S. Army RDECOM

CrazyEngineers.com Celestron and eCYBERMISSION
The Kavli Foundation Baxter International Purdue University
Medimmune American Nuclear Society Center for America
Sigma Xi Xconomy Northern Virginia
American Scientist Association of Technology Council
Illumina, Inc. Science-Technology Centers The Scripps Foundation for
Physics Today You Can Do the Rubik's Cube Science and the Environment
Forbes/Wolfe Amgen 3M
SchoolTube U.S. Environmental Johns Hopkins University/
Protection Agency Whiting School of Engineering
NASA
The Planetary Society Society for Maintenance and Center for Biotechnology
Reliability Professionals (SMRP) Education at Johns Hopkins
Washington Family Magazine University
Applied Physics Laboratory
PBS Kids Aldebaran-Robotics
Raytheon
WAMU Project Lead the Way
U.S. Department of Defense
the future. I discovered that not all com-
puters had to be large, nor limited in ac-
cess. Around 1961, I gained access to
what we’d now call a personal computer.
The Royal McBee LGP-30 was about
the size of a desk.3 A vacuum-tube ma-
chine, it had a grand total of 15 flip-
flops. Its only memory was a 4k, mag-
netic drum. All the data—even the
machine registers—resided there. Bits
marched to/from the drum in serial
fashion. “Bulk storage” was rolls of pa-
per tape.
As primitive as the LGP-30 was, it
offered important advantages over the
Giant Brains. First, I didn’t have to beg
for permission to use it, No accountant
or systems administrator stood behind
me, tapping his foot. And though the
computer was shared among our team, I
had virtually unlimited access to it. Sav-
ing computer clock cycles was no longer
an issue.
Most importantly, I could use the
LGP-30 interactively. I’d sit down at its
console, a modified electric typewriter,
and type. Answers came back in seconds,
on the same page. I didn’t have to learn
and use machine language; the LGP-30
sported a primitive interpreter. If you
think of it as a 1960 version of an Apple,
with paper tape instead of tape cassettes,
you won’t be far from wrong.
Using that computer, I formulated a
philosophy that I’ve held ever since:
Having virtually unlimited and interac-
tive access to a small computer is infi-
nitely preferable over needing an act of
Congress and wading through a hierar-
chy of bureaucrats, to get batch-mode
access to a big one. Limited though a
small computer might be, a “turn-
around” time in seconds trumps one in
hours or days.
I got a lot of problems solved with
that old computer, but my main take-
away was a dream. Someday, I vowed, I’d
have a computer of my very own. I
wouldn’t have to justify my use of it to
anyone. Its only job would be to sit on
my desk, waiting for me to give it some-
thing to do. And if I chose to use it frivo-
lously, inefficiently, or not at all—well,
that would be entirely up to me.
CHANGES IN THE WINDS
Fast forward to 1970. I was still pro-
gramming an unseen mainframe in
FORTRAN. That particular mainframe
wasn’t even in our building; it belonged
to NASA. Our only contact with it was a
courier, who made twice-daily runs to
pick up our card decks and return print-
outs. Turnaround time was 24 hours. To
keep the pump primed, each time we got
a run back, we’d pore through the print-
out with a red pen in hand, marking it
up for the next cycle.
But big changes were on the horizon:
I’d been reading about these newfangled
gadgets called minicomputers. Though far
more capable than my old “desk” com-
puter, a typical minicomputer was about
the same size and price, and had a simi-
lar, interactive user interface: A Teletype
console with paper tape I/O.
Most exciting, people began con-
necting minicomputers to the real
world.
In truth, we could have done the same
thing with a big mainframe. All comput-
ers have I/O ports and support interrupts.
With enough specialized (and very expen-
sive) interface devices like analog-to-digi-
tal (A/D) and digital-to-analog (D/A)
converters, a computer could interact with
its surroundings. But unless you had a
budget equal to NASA’s, you weren’t
likely to use a mainframe that way.
With minicomputers, cost wasn’t
such an issue. What’s more, minicom-
puters tended to have more uncommit-
ted I/O ports and interrupts, and the cost
of A/D and D/A converters was plum-
meting. Suddenly, all over the world,
people were hooking their minicomput-
ers up to all manner of external machin-
ery, including factory assembly lines and
research lab equipment. The era of real-
time and embedded systems had arrived.
One day, I was walking down the halls
at my job, and passed room after room of
guys poring over fan-fold printouts,
marking them up with red pens. I had the
thought, “these guys—indeed, ALL us
guys—will soon be as obsolete as dodo
birds.” I resolved not to let that happen
to me. I resolved to get involved with
minicomputers and real-time systems.
www.embedded.com | embedded systems design | MAY 2012
CHASING THE DREAM
In a nice, orderly, and linear world, I
would have followed up that resolution.
But my world has been anything but lin-
ear. To explain, I have to rewind to the
mid-1960s. I was back at college, chasing
another degree. For both my teaching
duties and NASA research, I found my-
self back in the world of FORTRAN and
mainframes. But at home, in my “spare
time,” my thoughts turned back to my
dream: A computer of my very own.
During those years, I was hardly alone.
Some enterprising souls actually man-
aged to realize their dream, assembling
their own minis from surplus parts.
Others settled for slices of a time-shared
mini, like the BASIC system developed
at Dartmouth. My own thoughts, how-
ever, took a more primitive turn: I want-
ed to build a homebrew computer from
scratch.
Two unrelated events had steered me
in that direction. First, in a GE semicon-
ductor manual, I found a very nice tuto-
rial on Boolean logic. Fascinated, I
learned all about 1’s and 0’s, ANDs and
ORs, exclusive ORs, and De Morgan’s
theorem. I learned about flip-flops. I
learned about circuit minimization and
Karnaugh maps. Just for fun, I would
pick some logic problem (Example:
build me a circuit to drive a seven-seg-
ment display) and work out a gate-level
solution.
Second, Fairchild introduced a line
of low-cost integrated circuit (IC) logic
devices. Even a grad student could afford
a dual NOR gate 80 cents or a J-K flip-
flop for $1.50. I bought a bunch of them,
and spent many glorious hours making
lights blink, sensing pushbutton inputs,
and mechanizing some of those logic so-
lutions. I built a couple of useful gadgets:
a lap timer for a racetrack and a counter-
timer-frequency meter for myself. For
the first time, my dream of a homebrew
computer seemed within reach.
As my design evolved, I took a page
from that old LPG-30, and used serial
logic, with shift registers ICs replacing its
magnetic drum memory. My next prob-
lem was I/O. For output, I wanted to dis-
play decimal digits. After much trial and
27
 programmer’s toolbox
error, I settled on the idea of displaying
seven-segment digits, drawn cursively on
an x-y-z oscilloscope. I worked out the
waveforms I’d need, and etched and sol-
dered circuit boards to generate them. I
had gotten as far as displaying a single
digit, when my plan was severely rerout-
ed by advancing technology.
THE MICROPROCESSOR
When Intel’s 4004 burst on the scene, it
not only changed my plans, it changed
the world forever. I asked myself: Why
should I bother building a homebrew
computer from discrete gates, when I
could get the whole CPU on a single
chip?
Interestingly enough, this vision
wasn’t shared by many respected com-
puter gurus and manufacturers. Even
Intel themselves, when they introduced
the 8080, wrote an article showing how
it could be used to control a traffic light.
That’s one traffic light. Three sets of
light bulbs, and four pressure sensors.
That kind of use seemed to be the limit
of their imaginations.
Even years later, respected computer
gurus were saying things like
“A microprocessor will never be
used as a general-purpose computer.”
“A high-order language compiler
will never run in a microprocessor.”
“Why would anyone want more
than 20k of RAM?”
But for those pioneers who had been
building homebrew computers out of
surplus core memories, discrete logic,
and duct tape, the intellectual leap from
controller chip to general-purpose com-
puter was obvious. One thing’s for sure:
entrepreneurs were not just building, but
marketing kits. Three or four used the
Intel 8008. I started writing software for
it, including a complete floating-point
package.
PERSONAL COMPUTERS
If the first microprocessors changed the
world, the next event shook it to its core,
and created an industry of unprecedent-
ed scope. Only a month or two after Intel
released the 8080, Ed Roberts, owner of
the electronics firm MITS, announced
28 MAY 2012 | embedded systems design | www.embedded.com
the 8080-based Altair kit. This was no
bag of parts or a set of etched circuit
boards; the Altair was a real computer,
with a rugged power supply, bus struc-
ture, and a beautiful case.
What’s more, it only cost $395—just
$45 more than the CPU chip alone. The
day I saw the ad in Popular Electronics, I
bought one.
FINALLY, REAL TIME
The next event didn’t change the world
at all, but it sure changed mine. Not
! Testing a nav system is not
simple. You can spend two
! weeks just calibrating sen-
sors. Instead, we simply put
! the box on a desk, and veri-
fied it could find “down.”
wanting to become a dodo bird, I’d been
looking for a chance to get into a micro-
based business. At a Huntsville electron-
ics trade show, I met Paul Bloom, presi-
dent of Comp-Sultants. At his booth,
Paul was displaying the components for
his own 4040-based computer kit, the
Micro 440. That was enough for me.
Hands were shaken, some money
changed hands, and I ended up as
Comp-Sultants’ software guy and its
manager. Which interprets as among
other duties, I got to handle phone calls
from irate customers, deal with door-to-
door salesmen and beggars, keep the toi-
let working, and sweep the chad from
the floor. In my “spare” time, I had to di-
rect our four technicians and develop
software.
Paul and I had our differences,
mostly about money and “vision,” but
you have to give him this: He was a true
visionary. Where I was still stuck in
homebrew computer mode, Paul saw the
value of the microprocessor in its com-
mercial value in real-time processor con-
trollers. Before I arrived on the scene, he
already had two products under devel-
opment: A controller for a cold-forge
machine, and another for a plastic injec-
tion-molding machine.
To say that our “laboratory” was
primitive would be far too kind. Paul’s
designs used the Intel 4040. His “devel-
opment system” consisted of a 4004-
based single-board computer, a primi-
tive ROM-based assembler, and a
Teletype ASR-33. Intel had upgraded the
assembler to support the 4040. Our test
equipment consisted of an equally prim-
itive bus monitor, a multimeter, and an
oscilloscope.
To hold our software, we used UV-
erasable EPROMS. But we had no
EPROM eraser. Instead, we just put the
EPROMs outside, on the hood of
someone’s car, and let the Sun do the
job. Sometimes, the software acted
strangely. Do you think maybe a cloud
passed over the Sun?
When I arrived on the scene, we
bought the much more capable Intel
Intellec-8, which improved our capabil-
ities big time. The Intellec-8 included
both a better assembler and a PROM
reader-burner. That’s the way we burned
PROMs for the cold-forge machine. But
more importantly, we could now devel-
op software for the 8080.
Paul sold a contract for software to
control a satellite-tracking antenna. It
was to include a two-state Kalman filter
(KF)—surely one of the first KFs in a
microprocessor. I wrote the software for
it.
A KF is best implemented in floating
point. So I ported my 8008 floating-
point package to the 8080. It was on this
project that I learned the value of RAM
bytes and clock cycles. For each assem-
bly-language subroutine, I counted the
clock cycles and bytes used. The end re-
sult was a package that was smaller and
more efficient than both Intel’s own
package, and Microsoft’s (yes, Bill, I dis-
assembled your code). I also had to pro-
gram the fundamental functions: square
root, sine, cosine, and arctangent. My al-
gorithms eventually found their way,
first into the pages of ESD, and then into
my book (www.amazon.com/Math-
Toolkit-Real-Time-Programming-Cren-
shaw/dp/1929629095).
 Now, you have to ask: If we were de-
veloping microprocessor-based, real-time
systems in 1975, how come we didn’t be-
come rich and famous billionaires? An-
swer: We tended to snatch defeat from
the jaws of victory. My Kalman filter
worked like a champ, but I can’t say as
much for our other products.
As it turned out, the Micro 440 kit
that Paul had at that trade show was a
myth. He had some of the real parts, but
most were just random circuit boards,
put there for show. We did eventually
complete the Micro 440, and even sold a
few, mostly to universities. But we had
made a serious marketing error. We
thought that the public wanted lower
cost, and the Micro 440 was $100 cheap-
er than the Altair. In reality, our cus-
tomers wanted a horsepower race: The
more RAM, longer words, and faster
clock speed, the better. The hobbyists
saw our ads, yawned and moved on.
Paul made another egregious error.
Before I came along, he needed a pro-
grammer for his cold forge machine.
Thinking to get one on the cheap, he
went to the computer science depart-
ment at the University of Alabama,
Huntsville, and asked them for their
smartest senior. Tim may indeed have
known computer science, but he turned
out to be the most inept programmer
I’ve ever known (and that’s saying a
lot). He wrote impossibly obtuse and
lengthy code, filled with flags and
branches, for even the simplest algo-
rithms. We had to scrap his code for a
TTY interface because it filled the entire
memory.
Worse yet, his only way of testing the
software was to go to Nashville, 100+
miles away, and plug the EPROMS into
the machine. It’s called the Big Bang the-
ory of testing. And when you’re talking
of a big machine with 5000-psi hy-
draulics, you’re talking about a BIG
bang! Week after week, the software mis-
behaved, destroying the machine and
sending technicians diving behind
crates. In the end, I fired Tim, rewrote
the software myself, and delivered a
working product. But not before the due
date on the contract had expired. The
customer took our system, said, “Thank
you very much,” and walked away.
The future of the company now de-
pended on my antenna controller. We de-
livered that one on time, and it exceeded
its performance spec. In fact, it may have
been a little too good. We had been hop-
ing that, if we did a good job, we’d get a
follow-on contract to refine and extend
the code. Turns out, the customer was
happy with version 1.0, so that was that.
GYROS, SHIPS, MISSILES, TORPEDOES
After Comp-Sultants, I wandered into
other jobs, including teaching computer
science at a local university, writing soft-
ware requirements for NASA projects,
and even a stint as a chief engineer for
Heathkit. My next job with real-time
systems involved developing software for
the 16-bit Zilog Z8000. The company
made navigation systems using ring-
laser gyros. One of our top scientists had
developed an algorithm that used a
computer to predict and compensate for
gyro errors. It promised to improve per-
formance by an order of magnitude. My
job was to turn the algorithm into code.
On this job, my biggest problem was
clock cycles. To implement the algo-
rithm, I had to make the software gener-
ate those same fundamental functions—
square root, sine, cosine, and
arctangent—in a millisecond. That’s
1000 clock cycles. To make this happen
was without a doubt the biggest chal-
lenge I’ve faced. I didn’t even have time
to store and fetch data to/from RAM. As
much as possible, I had to keep them in
CPU registers. To optimize the register
usage, I used graph-coloring algorithms,
as an optimizing compiler does.
I had another idea that I’m kinda
proud of. The issue was: how do you test
an algorithm to see if it’s working right?
You can single-step through the code,
but once the gyro is connected, you can’t
stop the CPU. To solve the problem, I
hooked up another Z8000, and let it
share memory with the unit under test.
The CPU couldn’t wait to peek and poke
all the CPU registers, but I could afford
to do about four of them. So I added
software that would peek at the registers,
www.embedded.com | embedded systems design | MAY 2012
grab four of them, and then—if asked—
poke new values. It worked like a charm.
I had one more job involving the
Z8000. We had an existing ship naviga-
tion system. Our company had sold the
Navy the idea of using it in an old torpe-
do, basically turning the torpedo into a
self-locating mine. The catch was, we
had only 2 weeks to deliver a prototype. .
Testing a navigation system is not
usually a simple thing. You can spend
two weeks just calibrating the sensors.
We couldn’t do that, but we could deliv-
er a working, if not perfect, system. In-
stead of a calibrated, computer-con-
trolled test rig, we simply put the box on
a desk, and verified that it could find
“down.” After we’d done that in a few
orientations, we rotated the box back
and forth by hand, and verified that it
knew “North.”
The next test was way cool. The tor-
pedo had a tachometer on the propeller,
which it used to “trim” the position cal-
culations. We couldn’t give the nav sys-
tem a propeller, but we did the next best
thing; we hooked up a square-wave gen-
erator to the prop input, so the system
would think it was moving at constant
speed. Then we put the system, a battery,
and a terminal on an equipment cart.
One of our techs had been practicing,
pushing the cart around the parking lot
at a constant pace. When we had him
push our system around a big loop and
back to the starting point, we closed the
loop within 15 feet. Not bad, for a cali-
brated technician.
I did two more embedded systems
for that company: A large, ground-to-
ground missile and an experimental ship
navigator. The ship navigator required
me to implement an 18-state Kalman fil-
ter. Both systems were successful. The
missile is currently deployed, and the
ship navigator achieved the highest ac-
curacy ever achieved, to that time.
My next real-time job was among the
most fun, mainly because I got to recom-
mend all the parts of our development
system and tools. It was for yet another
satellite tracking antenna, only this one
was in an airplane, and therefore bopping
around instead of bolted to the ground.
29
 programmer’s toolbox
We chose the Motorola 68332 chip. We
used the Intermetrics C compiler, which
included a very nice source-level debug-
ger. For once, I didn’t need floating-point
software, but I still needed—guess
what—functions for square root, sine, co-
sine, and arctangent. We also gave the
customer an added feature. Instead of a
readout showing hex numbers in green,
uppercase characters, we gave him a Win-
dows-based interface, complete with mul-
ticolored graphs, simulated compass nee-
dles, spin-dials, and point-and-click
inputs. Nice.
I’m particularly proud of the op-
erating system I wrote for this job.
First, it used all the real-time features
of the 68332—watchdog timer,
counter-timer, etc., to the fullest.
More importantly, it was rather
tial to kill people. The FDA has very
strict rules for certifying a given system
as safe. To create the new patient moni-
tor, we had to assure the FDA that it
would perform exactly the same func-
tions, using the same algorithms, as the
old one. That’s not easy when you’re
changing both the CPU(s) and the pro-
gramming language. To make sure that
happened, I first had to understand, in
precise detail, the Z80 code in the old
one. And that was the rub, because
! To update the patient monitor,
we had to assure the FDA it
! would perform exactly the
same with same algorithms—
SEE JACK WRITE
I’ve always enjoyed writing. My first cre-
ation, as I recall, was a comic book when
I was around 10. During my aerospace
days, I wrote many technical reports,
white papers, and some journal articles.
The biggie was my Ph.D. dissertation,
which ran to 140 pages. Later I was writ-
ing software requirements specs, test
plans, etc., for NASA and DOD cus-
tomers.
When I got involved with micro-
computers, I wrote a few articles for
magazines like Byte, Kilobaud, and
ProFiles, the house organ for the
Kaypro computer. In 1988, I started
writing a tutorial on compiler con-
struction. It’s still on the web here at
www.freetechbooks.com/let-s-build-a-
compiler-t56.html.

!
unique in that the interrupt handler
was itself reentrant. That is, the sys-
tem could tolerate one or more new
interrupts coming in, while it was
still processing the last one. The only
requirement was that the average time
required to service the interrupt had to
be less than the interrupt time
We delivered this system on time
and on budget, and it met its perform-
ance specs. We also did several other jobs
for this company, all successful. As a “re-
ward” the customer, thinking to save
some money, cut me out of the next
contract, and hired my ex-partner. My
only satisfaction out of the deal came
from learning that, because he didn’t
understand the OS, his job went two
years over schedule, was way over cost,
and under performance. The company is
no longer in business. Payback is sweet,
but I’d much more have preferred that
both our companies had prospered.
THE MEDICAL BUSINESS
I have one more job to tell you about. A
medical electronics firm wanted to re-
place their existing patient monitor,
which used something like eight Z80’s,
with a new one using a single Intel
80286. Our job was to port the code
from Z80 assembler to C. Now, as you
might guess, medical electronics is spe-
cial because if it fails, it has the poten-
not easy when you’re chang-
ing the CPU and the language.
while the original programmer was su-
perb, he wasn’t big on comments. As in,
there were none. So before I could write
the first line of C, I had to psychoana-
lyze the Z80 code, commenting and
studying it until I knew it as well as I
know my own memories.
To get that job done, I used every
programming trick I’d ever learned, and
then invented some more. It was a hard
job, but also exciting and instructive. I
extended the concept of the dataflow dia-
gram, to include real-time interrupts,
synchronous, asynchronous, and back-
ground tasks.
My design evolved into a set of nest-
ed, hierarchical state machines. It was
very slick, if I do say so myself. In any
medical application (and most other
real-time applications), it’s important to
quickly respond to, and recover from, er-
rors. In my design, each state machine re-
turned an enumerated state identifying,
some of which were typically error con-
ditions. Looking back, I see that the de-
sign amounted to sort of a do-it-yourself
exception mechanism. It worked just
fine, and the software turned out to be
both robust and error-free.
JD Hildebrand, then editor of
Computer Language magazine, saw the
tutorial and asked me to write an arti-
cle on the topic. I did, and presented a
paper at the next Computer Language
Conference. That article and paper start-
ed my long relationship with Computer
Language and its sister publication, Em-
bedded Systems Programming. Computer
Language also maintained a forum
(CLMFOR) on CompuServe, and I
spent many hours chatting about com-
puters, and almost any other topic, with
its denizens.
In 1992, I was laid off from my day
job. It was most probably the shortest of
unemployment periods on record. That
night, I got on CLMFOR and said,
“Guess what? I’ve been laid off. Anyone
want me to write an article or two?”
JD responded immediately, with “I
can take an article every two months.”
Tyler Sperry, then editor of Embedded
Systems Programming, said, “I’ll take one
a month.”
And that was that. I didn’t stay “un-
employed” forever. I worked at other
companies, and ran my own company
for a time. But my writing for Embedded
Systems Programming started then, and
has never stopped.
And, as Paul Harvey used to say,
“Now you know the rest of the story.” ■

30 MAY 2012 | embedded systems design | www.embedded.com


By Dan Saks
Unexpected trends
I started writing for computer trade
publications almost 23 years ago,
publishing my first article in The
C Users Journal in the summer of
1989. Within a year, I became secre-
tary of the ANSI C++ standards
committee and landed my first col-
umn writing about the emerging
standard for The C++ Report. Just a
few months later, I started writing a
column on programming style for a
curiously named magazine called
Tech Specialist, which soon morphed
into The DOS Developers Journal and
eventually into The Windows™/DOS
Developers Journal. Over the next
several years, I wrote columns for a
handful of other magazines, includ-
ing The C User Journal (later the The
C/C++ Users Journal), Software De-
velopment, and an obscure little pub-
lication called The Journal of C Lan-
guage Translation. None of these
publications is with us anymore.
I wrote my first Programming
Pointers column in 1998, when this
publication was still Embedded Sys-
tems Programming. Now that Em-
bedded System Design is going out of
print, this could well be my last col-
umn for a print publication.
However, I expect to continue writ-
ing for Embedded.com.
Back in 1998, the consensus was
that C had overtaken assembly lan-
guages as the most commonly-used
language for programming embed-
ded systems. By then, C had been
around for a quarter century and had
been standardized for almost a
Dan Saks is president of Saks & Associates, a C/C++ training and con-
sulting company. 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.
programming
pointers
Dan Saks crunches over
12 years of data on
programming-language
preferences from reader
studies and finds some
surprises about C/C++.
decade. However, object-oriented
programming was going mainstream
and newer languages with native
support for objects, notably C++ and
Java, were encroaching on C’s turf.
At that time, I thought C++ or Java
would eventually displace C as the
language of choice for embedded
systems. I was hardly alone.
So in my final column for Em-
bedded Systems Design, I’d like to
look back and see if what we thought
www.embedded.com | embedded systems design | MAY 2012
would happen actually did happen.
This seems like as good a time as any.
EARLY LANGUAGE USAGE DATA
Starting in 1993, the publisher of
Embedded Systems Programming con-
ducted annual reader surveys to as-
sess the purchasing habits of embed-
ded systems designers and their
managers. Each year, the survey in-
cluded at least one question on pro-
gramming language usage. The total
number of responses varied from
slightly less than 400 in one year to a
little over 2,000 in another.
From 1998 through 2004 the sur-
vey asked two questions:
• “Which of the following pro-
gramming languages have you
used for embedded development
in the last 12 months?”
• “Which of the following pro-
gramming languages are you
planning to use for embedded de-
signs in the next 12 months?”
Table 1 displays the responses for
the first question; Table 2 displays the
responses to the second. (I couldn’t
locate the data for 2003, so that year
is missing from both tables.) The ta-
bles list only the most popular lan-
guages. I left out languages, such as
Forth, Fortran, Modula 2, and Pascal,
that less than 3% of the surveyed pro-
grammers selected each year.
Table 1 shows that, on average,
nearly 80% of the surveyed program-
mers reported using C, nearly 60%
used assembly language, and roughly
45% used at least some C++. Java
was a distant fourth, with Basic just
behind it. On average, less than 5%
of programmers reported using Ada.
Table 2 shows what programmers
reported they were planning to use.
31
 programming pointers
“Which of the following programming languages have you used for em- What’s interesting is how the entries in
bedded development in the last 12 months?” Table 2 compare with those in Table 1.
Language 1998 1999 2000 2001 2002 2004 Average Table 3 displays the differences be-
C 81.4% 79.0% 79.8% 71.8% 79.7% 86.1% 79.6% tween the corresponding entries in Ta-
Assembly 70.1% 61.0% 59.6% 43.5% 58.3% 64.4% 59.5% bles 1 and 2. Positive values in Table 3
C++ 39.4% 46.6% 41.5% 52.2% 46.4% 49.5% 45.9% indicate expected increases in language
Java 7.0% 9.3% 8.0% 16.5% 10.0% 14.0% 10.8% use; negative values (in red) indicate
Basic 9.3% 8.5% 9.9% 9.8% 9.0% 9.7% 9.4% expected decreases.
Ada 4.9% 6.1% 5.3% 3.5% 3.4% 3.0% 4.4% For example, Table 3 shows that,
Table 1 on average, the number of program-
mers who expected to use C the next
“Which of the following programming languages are you planning to use year was 2.6% less than the number
for embedded designs in the next 12 months?” currently using C. Even more pro-
Language 1998 1999 2000 2001 2002 2004 Average grammers aspired to get the assembly
C 80.7% 76.8% 75.2% 68.8% 78.5% 82.3% 77.1% language monkey off their backs—the
Assembly 67.0% 57.3% 54.5% 39.2% 54.1% 56.5% 54.8% number of programmers who expected
C++ 53.6% 56.6% 49.5% 59.0% 56.4% 58.8% 55.7% to use assembly language the next year
Java 14.7% 24.1% 19.8% 26.1% 16.5% 20.3% 20.3% averaged 4.7% less than the current
Basic 8.2% 5.9% 7.4% 8.0% 7.6% 8.8% 7.7% year.
Ada 8.8% 5.1% 5.5% 4.1% 3.6% 3.1% 5.0% In contrast, many more program-
Table 2 mers who hadn’t been using C++ or
Java expected to start using those lan-
guages. On average, 9.7% more re-
The projected annual difference in language use. spondents expected to use C++ in the
Language 1998 1999 2000 2001 2002 2004 Average coming year than were using C++ in
C -0.7% -2.2% -4.6% -3.0% -1.2% -3.8% -2.6% the current year. The percentage for
Assembly -3.1% -3.7% -5.1% -4.3% -4.2% -7.9% -4.7% Java was only slightly less. At that rate,
C++ 14.2% 10.0% 8.0% 6.8% 10.0% 9.3% 9.7% you might expect C++ to overtake as-
Java 7.7% 14.8% 11.8% 9.6% 6.5% 6.3% 9.5% sembly language in just a few years and
Basic -1.1% -2.6% -2.5% -1.8% -1.4% -0.9% -1.7% bypass C several years later. You might
Ada 3.9% -1.0% 0.2% 0.6% 0.2% 0.1% 0.7% expect Java to follow a similar trajecto-
Table 3 ry, lagging a bit behind C++. However,
reality played out a little differently.
Figure 1 contains a plot of the val-
The four most used languages in embedded systems for the years 1998 to 2002 and 2004, ues in Table 1 for the four most com-
along with linear trendlines. monly-used languages: C, assembly
language, C++, and Java. For each lan-
100.0% guage, Figure 1 shows a solid line that
C
90.0% plots the reported language use (from
C++
80.0% Table 1) along with a dashed line de-
Assembly
picting the linear trend.
70.0% Java
Figure 1 shows that, from 1998 to
60.0% 2004, both C++ and Java usage indeed
Trendlines:
50.0% trended upward at about the same
C
rate, although nowhere close to the 9
40.0% C++
to 10% per year predicated by the sur-
Assembly
30.0% veys. It also shows that assembly lan-
Java
20.0% guage usage trended downward. How-
ever, I think the trendline for assembly
10.0% language is less meaningful because
0.0% half the data points are so far off the
1998 1999 2000 2001 2002 2003 2004 trend.
The real surprise in Figure 1 is that
Figure 1 it shows C usage actually trending up-

32 MAY 2012 | embedded systems design | www.embedded.com

ward, rather than downward as the sur-
veys projected. It’s only slightly up-
ward, but upward nonetheless.
A few more years of data might tell
us if assembly language usage is really
diminishing and C language usage real-
ly is increasing.
MORE RECENT DATA
Starting in 2005, the Embedded Systems
Design reader surveys changed the
wording of the questions to:
• “My current embedded project is
programmed mostly in which lan-
guage?”
• “My next embedded project will
likely be programmed mostly in
which language?”
Whereas the earlier surveys asked each
programmer to list all languages used,
the latter surveys asked each program-
mer to name only the one language
used most. Not surprisingly, the survey
data changed dramatically starting in
2005. If you ask a different question,
you usually get a different answer.
Table 4 displays the responses for
the first question for every year starting
in 2005. Table 5 displays the responses
to the second question. Table 6 displays
the differences between the correspon-

Responses to “My current embedded project is programmed mostly in which language?” 2005 to 2012.
Language 2005 2006 2007 2008 2009 2010 2011 2012 Average
C 51% 51% 63% 60.2% 62.0% 60.0% 62.4% 64.7% 59.3%
C++ 26% 30% 22% 25.0% 24.0% 20.0% 21.9% 19.6% 23.6%
Assembly 8% 8% 7% 4.5% 4.7% 6.0% 5.5% 4.8% 6.1%
Other 6% 5% 4% 4.1% 3.3% 3.0% 3.0% 3.3% 4.0%
Java 3% 3% 1% 2.1% 1.8% 3.0% 2.3% 2.3% 2.3%
UML, Matlab, or like 3% 3% 2% 1.1% 1.3% 2.0% 2.1% 1.3% 2.0%
.NET 3.0% 1.2% 1.7% 2.0%
LabView 2% 1% 1.3% 1.0% 2.0% 0.9% 1.1% 1.3%
Basic 2% 1% 1% 1.3% 1.5% 1.0% 0.6% 0.8% 1.2%
XML 1% 0% 0.4% 0.3% 1.0% 0.2% 0.2% 0.4%
Table 4

Responses to “My next embedded project will likely be programmed mostly in which language?” 2005 to 2012.
Language 2005 2006 2007 2008 2009 2010 2011 2012 Average
C 48% 47% 59% 56.7% 58.7% 55.8% 58.5% 59.7% 55.4%
C++ 31% 32% 24% 28.8% 26.6% 22.6% 25.0% 23.5% 26.7%
Assembly 5% 6% 5% 3.6% 4.1% 3.6% 3.4% 3.1% 4.2%
Other 6% 5% 5% 3.7% 3.8% 4.1% 3.1% 3.7% 4.3%
Java 5% 3% 2% 2.3% 2.3% 3.7% 3.1% 3.5% 3.1%
UML, Matlab, or like 3% 3% 3% 1.6% 1.8% 3.1% 2.6% 2.3% 2.6%
.NET 3.8% 1.5% 1.7% 2.3%
LabView 0% 2% 2% 1.4% 1.0% 1.8% 1.4% 1.5% 1.4%
Basic 2% 1% 1% 1.2% 1.2% 0.8% 0.9% 0.5% 1.1%
XML 1% 1% 0% 0.6% 0.4% 0.7% 0.6% 0.5% 0.6%
Table 5

Responses to “My next embedded project will likely be programmed mostly in which language?” 2005 to 2012.
Language 2005 2006 2007 2008 2009 2010 2011 2012 Average
C -3% -4% -4% -3.5% -3.3% -4.2% -3.9% -5.0% -3.9%
C++ 5% 2% 2% 3.8% 2.6% 2.6% 3.1% 3.9% 3.1%
Assembly -3% -2% -2% -0.9% -0.6% -2.4% -2.1% -1.7% -1.8%
Other 0% 0% 1% -0.4% 0.5% 1.1% 0.1% 0.4% 0.3%
Java 2% 0% 1% 0.2% 0.5% 0.7% 0.8% 1.2% 0.8%
UML, Matlab, or like 0% 0% 1% 0.5% 0.5% 1.1% 0.5% 1.0% 0.6%
.NET 0% 0% 0% 0.0% 0.0% 0.8% 0.3% 0.0% 0.1%
LabView 0% 0% 1% 0.1% 0.0% -0.2% 0.5% 0.4% 0.2%
Basic 0% 0% 0% -0.1% -0.3% -0.2% 0.3% -0.3% -0.1%
XML 0% 1% 0% 0.2% 0.1% -0.3% 0.4% 0.3% 0.2%
Table 6

www.embedded.com | embedded systems design | MAY 2012 33

 programming pointers
The four languages most often reported as the primary language for embedded projects for the years
2005 to 2012, along with linear trendlines.
70.0%
60.0%
50.0%
40.0%
30.0%
20.0%
10.0%
0.0%
2005 2006 2007 2008 2009 2010 2011 2012
Figure 2
ding entries in Tables 4 and 6. As in
Table 3, positive values in Table 6 indi-
cate expected increases in language
use; negative values (in red) indicate
expected decreases.
Most of the percentages in Tables
4 and 5 are rounded to the nearest
tenth of a percent. However, the values
for 2005 through 2007 are rounded
only to the nearest percent.
The columns in Tables 1 and 2 add
up to well over 100% because each
programmer could select more than
one language, and apparently many
did. In contrast, the columns in Tables
4 and 5 add up pretty close to 100%
because each programmer could select
only one language. (Some columns
don’t add up to 100% because of
rounding errors.)
Table 4 shows that, on average,
slightly more than half of the surveyed
programmers worked on projects writ-
ten mostly in C, whereas slightly less
than a quarter of them worked on
projects written mostly in C++.
Table 1 showed that roughly 60%
of developers used assembly language,
but Table 4 shows that assembly lan-
guage is the primary language on only
around 6% of projects. This suggests
34 MAY 2012 | embedded systems design | www.embedded.com
C picted in Table 6 are rather striking.
C++
Assembly
Java
Trendlines:
C
C++
Assembly
Java
! Over the seven-year survey
period, C as the primary
!
project language grew
from slightly more than half
! to nearly two-thirds of all
projects. Most of that
! growth seems to have come
at the expense of C++.
that, while many developers use some
assembly language, only a few unfortu-
nate ones have to use it a lot.
Table 6 shows that, as a group, pro-
grammers expected that C, assembly
language, and Basic would to be pri-
mary language on fewer projects as the
years went by. They expected C++,
Java, and other languages would be-
come the primary language on more
projects. However, more so than in the
earlier years of the survey, reality didn’t
go along with these expectations.
Figure 2 contains a plot of the val-
ues for the four languages with the
highest average percentages in Table 1,
along with their linear trends. The con-
trasts between the actual usage shown
in Figure 2 and the expectations de-
Although year after year, the sur-
veyed developers expected C to be the
primary language on fewer projects,
C’s dominance actually grew. Over the
seven-year survey period, C as the pri-
mary project language grew from
slightly more than half to nearly two-
thirds of all projects. Most of that
growth seems to have come at the ex-
pense of C++. Although developers ex-
pected C++ to become the primary
language on more projects, it actually
diminished from nearly 30% of proj-
ects to only about 20%.
Java’s trendline in Figure 2 is essen-
tially flat. Only assembly language
trended downward as expected.
LET THE SPECULATING BEGIN
I think these results are very interest-
ing. The recent trends for assembly
language and Java are much as I ex-
pected, but I’m rather surprised at the
apparent trends for C and C++.
Those of you who read my column
regularly know that I think C++ is a
decidedly superior programming lan-
guage compared with C. My columns
have addressed, and will continue to
address, the needs of both C and C++
programmers, but I make no bones
about my preference for C++. It’s
rather puzzling to see the industry
moving the other way.
Why might this be happening? I
don’t know. Maybe I’ll have more to
say about this in a future online col-
umn, but for now, I’ll leave it to you to
speculate. I’ll just go back to my busi-
ness of helping programmers write
better embedded systems. See you on
the web. ■
ACKNOWLEDGEMENT:
Special thanks to my brother, Joel Saks,
who has helped me improve almost
every column I’ve written for Embedded
Systems Programming/Design.

firmware curriculum
from page 15
engineering and end with computer
science.
FIRMWARE GROWTH
As mentioned previously, the demand
for firmware engineers is growing. Of
those polled, the majority saw either
steady demand or growth. About one
in ten found reported demand was
dropping.
In my dealings with those who have
a business-level exposure to the de-
mand, there is very clear growth in the
demand and businesses are struggling
to find appropriate talent to match. I
would argue this demand is not tempo-
rary and must be addressed with both
long-term and short-term solutions
that elevate and educate engineers in
firmware design and development.
EDUCATIONAL OPTIONS
So far we have developed an argument
for what firmware is, who firmware en-
gineers are, and why there is a need to
develop educational options that will
educate and elevate engineers and stu-
dents of engineering.
But what are our options? How can
we address the short-term demand cri-
sis and long-term need for talent? Inter-
estingly, the debate in the discussion
boards on LinkedIn presented a differ-
ent story than my polling results.
I found that a certification program
generated some very stern and negative
knee-jerk reactions in my discussion
threads. Many have found that certifi-
cation programs have been designed to
create profit for those who create them
rather than educate and elevate the tal-
ent pool.
But when I put this to a poll, I re-
ceived a very different profile. By a
great majority, the idea of certification
developed by the right people and for
the right reasons received resounding
approval. A certification program suc-
cessfully implemented would go a long
way towards meeting the short-term
demand for talent.
I believe that a firmware certifica-
tion program would provide courses
and curricula that would allow an elec-
trical engineer to develop the software
skills necessary to be an effective
firmware engineer while leveraging the
his or her electrical engineering back-
ground. A master’s level program of
study in firmware might be an alterna-
tive to a certification program. Robert
Bowser, senior director with Steris Sys-
tems, notes,“Certifications always ele-
vate the work force and the profession.
Certifications help companies under-
stand the level of understanding (in a
somewhat measured way). In a job
!
A certification program
generated some very
! stern and negative knee-
jerk reactions in my
discussion threads.
search situation, a hiring manager can
focus more on other fit parameters if
they are not spending a lot of time
evaluating technical competence, mak-
ing a better hire and a more effective
industry.”
The creation of a bachelor’s program
did not receive strongly negative or posi-
tive responses. With that said, the primary
argument against a bachelors degree pro-
gram was that it might encourage fur-
ther fragmentation of disciplines.
I’m firmly convinced that a degree
in firmware engineering is a necessity.
The next logical step in our technologi-
cal evolution will include massive con-
nectivity of devices for the purpose of
data analysis on a scale unimaginable
from our present vantage point.
I see a multitude of devices that
perform some purposeful action having
firmware as part of their basic composi-
tion. All these devices can and will be
connected in a massive wired and wire-
less infrastructure for the purpose of
improving the human condition. We
www.embedded.com | embedded systems design | MAY 2012
feature
have seen how being connected socially
has improved the human condition.
The next logical step is the device.
With that said, the skills taught to a
computer scientist are not sufficient due
to the obvious lack of electrical engi-
neering competency and the fact that
computer science is taught from a com-
pletely different vantage point than
what is required for firmware develop-
ment. Schwartz notes, “Computer sci-
ence doesn’t even begin to explain to
you how computers work . . . In a
firmware world I would absolutely start
with how computers work and assembly
language. . . . I can see a full curricu-
lum.” He went on to say, “I think there
is a need for a major. I think there are a
number of skills a firmware engineer
needs that are not being taught either in
electrical engineering or in computer
science.”
BACK TO THE CURRICULUM
Dr. Schwartz went on to note that “Ag-
ile design methodologies welcome
change instead of avoiding it. In
firmware, it is the complete opposite.
You need to have very high reliability in
what I think of as firmware because you
can’t afford to go and update it
all . . . Take a ISO 9000 rather than an
Agile approach. You would want to be
able to look at certain sets of require-
ments for a system and easily estimate
whether it’s possible with the resources
you are given. People try to do ‘the im-
possible’ and fail.”
Now that we have addressed the
prerequisites, let’s start building a cur-
riculum. Comment on this article on
Embedded.com to put in your two
cents for a firmware curriculum. ■
Bob Scaccia is a principal firmware con-
sultant with over 25 years experience in
embedded systems development. He is
the founder and leader of Firmware En-
gineers of Northeast Ohio group and is
also the chair of the IEEE Computer Soci-
ety for the Cleveland IEEE Section. He
has a BS degree in electrical engineer-
ing and is working toward an MBA. For
more information about Bob, go to
www.usafirmware.com or contact him at
bob.scaccia@usafirmware.com.
35
 break points
Farewell, ESD
I f you’ve made it to this column, at
the very end of the magazine, by
now you know that this is the last
installment of Embedded Systems
Design.
ESD, like so many other publica-
tions, is a victim of the Internet. In its
glory days it ran well over a hundred
pages, but in recent years has been
hollowed out to the slender magazine
you hold in your hands. In the pub-
lishing business it’s all about ad rev-
enue, but that has deserted print in
favor of those online eyeballs.
Print is pretty much dead, at least
in terms of free trade magazines.
Those I get are all just ghosts, hints
really, of their former glory. So many
that have been so important to work-
ing engineers now play second fiddle
to their online versions. Does anyone
remember Electronics or Computer,
both done in even before the web?
The failure of print is not good
for the embedded systems industry.
Hard-copy publications are very ex-
pensive to produce and mail, which is
both their strength and their Achilles’
heel. The high costs means a decent
editorial staff is needed to cull weak
or vendor-serving articles. So quality
is high. But the costs undermine prof-
itability. The relationship between a
reader and a hard-copy magazine is
very different from that of the same
reader and Internet sources. With the
former, one relies on the magic of
serendipity; new or different ideas ex-
plode off the page as one flips
through the magazine. Readers of on-
line content largely get narrowly-tar-
geted responses to specific queries.
Web alternatives are sometimes
great, but too many are designed as
Google magnets. Content is needed to
draw searches to the site; lots of con-
36 MAY 2012 | embedded systems design | www.embedded.com
! Jack Ganssle, the MVP of
ESD and Embedded.com,
! reflects on how a good
concept 24 years ago
!
touched his life and those
of other developers.
tent, so quality actually has little ben-
efit to the bottom line. Blogs and
blather replace detailed analysis and
the exposition of complex concepts.
The supreme irony of online pub-
lishing is that we’ve become very effi-
cient at ignoring the ads that pay the
freight. Who looks at those flashing
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.
By Jack G. Ganssle
graphics? A click and they’re gone.
Print ads, on the other hand, are large
enough to contain real content. We
engineers peruse them and absorb in-
formation that’s useful to us and
worthwhile to the vendor.
The only magazines that thrive are
those with paid subscriptions, which
is a pretty small set when it comes to
embedded systems. Circuit Cellar Ink
and IEEE Embedded Systems Letters
are the only ones I can think of that
are published in the U.S.
A GOOD CONCEPT
ESD started as Embedded Systems
Programming. In 1988, Ted Bahr, one
of the founders, visited my company
in Maryland soliciting an ad for the
first issue. He left us with a stack of
demographics about the potential cir-
culation. It seemed a gutsy idea, al-
most goofy. After all, the word “em-
bedded” was pretty new, at least in the
context of computer systems. Al-
though the microprocessor was al-
most two decades old, most of us re-
ferred to this business as “the micro
industry” or used other more cum-
bersome terms. But Ted’s pitch was
persuasive, and we took a small ad in
the first issue. A PDF of this inaugural
ESP is here www.ganssle.com/misc/
firstesp.pdf.
The ad worked pretty well, and we
eventually took full page displays at
something like $7,000 an issue, which
was quite a bit for a small outfit. Pre-
web all of the magazines had “bingo
cards,” postcards with an array of
numbers, one per ad. Interested
readers circled the numbers asso-
ciated with products they wanted
more information about, and
mailed the card to the magazine.
(Via snail mail—remember that
quaint concept?) This was in
turn passed on to the advertisers.
You’d be surprised how few leads
were generated: Our full-page
ads pulled in 15 to 25 per month.
But ESP appealed to a very spe-
cific audience, and the lead quali-
ty was very high.
We would ply the salespeople
with dreams of more ads to find
out how many leads the competi-
tors’ ads generated. They’d hem
and haw, protesting that they
weren’t allowed to share this informa-
tion, but eventually would let it leak.
I’m sure all of the advertisers did the
same.
Just about everyone in the embed-
ded tools business advertised in ESP.
One editor told me that each page of
advertising supported one of editorial
content, so lots of ads meant plenty of
articles, most of which were really
quite good. ESP thrived.
Although the web dates to the ear-
ly 1990s, by the turn of the millennia
even business types took notice of it.
Startups abounded and venture capi-
talists would fund any crazy notion
that had an Internet component.
Price/earnings ratios soared (in the
cases where there were any earnings,
that is) and the stock market became
irrationally exuberant. At the peak in
October 1999, the Dow wasn’t much
lower than it is today. High valuations
meant publicly-traded companies’
stock was very valuable, and waves of
acquisitions followed. In the embed-
ded world, Wind River, then the 800
pound gorilla of the industry, bought
lots of tool vendors. One friend
worked for five companies in a six
week period without changing jobs,
all of them absorbed into the Wind
empire.
!
Probably the coolest
part about this business
! is that we’re always
balancing the mix of the
hardware and software.
As a result ESP’s advertising dried
up. Many of the companies vacuumed
up in the acquisition frenzy had taken
good-sized ads in the magazine. Those
were replaced by a single, generic, Wind
River ad. Page counts took a hit. Then
the dot-com insanity was replaced by
the inevitable bust, and tech in general
lost a couple of years of good times.
That didn’t help the magazine, either.
Finally, of course, the web became
the dominant source of information.
ESP was quick to exploit it and early
on got the coveted “embedded.com”
domain, which is going strong today.
(Please don’t ask me why it redirects to
“eetimes.com.” I get lots of email
about this and have no idea why.)
In 2005, the magazine was re-
named Embedded Systems Design,
which was another gutsy move. It’s al-
ways risky to rebrand a product, and
www.embedded.com | embedded systems design | MAY 2012
the ESP brand by then was sev-
enteen years old and well-estab-
lished. But it was the right deci-
sion; in fact, one could argue
that the original name was a
mistake. The embedded indus-
try is truly unique in that it’s
the synergy of both hardware
and software. Probably the
coolest part about this business
is that we’re always balancing
the mix of the two. That’s rep-
resented so well in the FPGA
world where the tools let us
seamlessly convert software
into hardware or vice versa. The
new name reflected this essen-
tial reality, and the content did
change somewhat to reflect
hardware tradeoffs. Unlike an
EDN, though, I can’t recall a single
hardware-only article in the succeed-
ing years. The editors did a great job of
picking pieces that, when discussing
hardware, also worked through the
firmware implications.
ESD is owned by UBM, a British
media conglomerate. As of 2010 the
company produced 123 print maga-
zines, but a summary of 2011 results
shows that online revenue has doubled
in the last five years while print’s con-
tribution is a third of what it was
(http://investors.ubm.com/download/
2011+Final+Results+Presentation+-
+%2828+Feb%29+%28FINAL%29.pdf.
The trend is clear. I doubt that any free
trade magazine will survive the Web’s
inexorable force.
LOOKING BACK
I contributed two articles “over the
transom” (that is, unsolicited) in 1989,
and the following year the very colorful
Tyler Sperry asked me for a monthly
column. He named it Breakpoints,
which has now run about 260 times.
The first Breakpoints showed how to
use extended memory on Hitachi’s
long-obsolete 64180 and 647180X
processors.
Some of those columns stand out
for being completely irrelevant today.
37
 break points
The same year I penned one that
showed how C code was substantially
bigger than assembly, and cautioned
that, while C made sense for a lot of
applications, one had to be wary about
using it. In 1990 the language had so
many dialects that compatibility be-
tween compilers was a huge problem.
Younger readers may be astonished
that so many developers wrote their
programs entirely in assembly lan-
guage. Other than for applications us-
ing the very smallest microcontrollers,
I wonder if anyone uses assembly ex-
clusively any more.
In 1991, I
wrote about the
increasing use
of prefetchers
Misrouting was extremely common,
and one could count on them crashing
many times a day. The FPGAs weren’t
much better: Some had known flaws
that would occasionally keep them
from booting from their dedicated
ROM properly. Some designers added
a small microcontroller just to watch
the boot sequence, and toggle the reset
line if the part didn’t properly come to
life.
I wrote about the future of in-cir-
cuit emulators in 1997 and predicted
that their market would narrow but
they’d continue to be important. A
others have contributed articles and
commentary?
The readers sure had commentary.
A lot. I’ve exchanged over 100,000
emails with ESD/ESP subscribers over
the decades, and the online articles elicit
plenty of thoughtful replies. Unlike
pretty much every other Internet venue
those comments are always polite and
thoughtful. And often really, really
smart.
As the magazine winds down I’d
like to express my special thanks to Su-
san Rambo, my editor for seven years
and now the magazine’s managing edi-
tor. All of the
previous edi-
tors stuck
around for a

!
on some CPUs,
The future is a bit year, maybe
like Intel’s 186 murky, at least to me, two, but Susan
(an embedded has been a con-

!
version of the but the staff is busily stant presence,
8086). Memory and she has
had gotten
getting all of the old markedly im-

faster than
processors, so
vendors added
hardware that
would fetch a
couple of extra
bytes ahead if
the CPU was
busy executing an instruction, in the
expectation that those queued bytes
would be needed next. Well, since then
the opposite has happened. Processors
are oodles faster than memory today,
so caches serve the opposite role. In a
2008 Breakpoints, I showed how this
memory/CPU mismatch now means
that a lot of the multicore hype is mar-
keting mumbo-jumbo that doesn’t
stand up to an engineering analysis.
Or how about the column on writ-
ing relocatable code? Before architec-
tures that supported position-inde-
pendent code came along one had to
do horrible things to write apps that
had to run in varying locations in
memory.
Then there was the 1994 piece
about the difficulty of using FPGAs.
Gads, the tools were so awful then!
!
issues online and are
working on a revamped
Embedded.com.
month later an outfit made an offer
for my emulator company and we took
it. They bought a couple of competi-
tors at about the same time, and just a
few years later the emulator business
imploded.
LOOKING AHEAD
There were so many people associated
with Embedded Systems Programming/
Design. The names rush in as I write,
people I came to know well. Some
were authors; others editors, market-
ing folk, and business development
types. Some went on to greater suc-
cesses, but there were sad stories, too. I
never met anyone associated with the
magazine I didn’t like.
Regular columnists Dan Saks and
Jack Crenshaw have had a fiercely-loy-
al following. Who knows how many
proved my
clumsy sen-
tences.
And I’d
like to thank
you, the read-
ers. When I’ve
gotten things
wrong, you’ve been quick to correct me.
And I have learned so much in my dia-
log with so many of you. I consider
some frequent correspondents friends
though we’ve never met.
The future is a bit murky, at least to
me, but the staff is busily getting all of
the old issues online and are working on
a revamped Embedded.com. Meanwhile
I plan to continue writing, at the very
least in my e-newsletter, The Embedded
Muse (subscription info is at
www.ganssle.com), and hopefully on-
line at Embedded.com as well. If you
haven’t explored that site, check it out. I
can’t wait to see what’s in store for it,
but have no doubt the redesign will re-
sult in an even better source of critical
information for design engineers.
Embedded Systems Design is dead.
Long live Embedded.com. ■

38 MAY 2012 | embedded systems design | www.embedded.com

The most advanced search engine for
Electronic Engineers & Buyers. For free.

Compare Get Pricing &

Electronic Parts Inventory

NEW

Discover New Parametrically

Electronic Parts Search Parts

Stop by Booth #748 for

demos, giveaways & contests
COMING TO A CITY NEAR YOU!

From April through September 2012, Avnet

and Xilinx will co-host X-fest technical
training events throughout Asia, Europe
and North America. Register for a FREE
REGISTER FOR A FREE
ALLALL
ACCESS PASS
ACCESS PASS
X-fest’s in-depth curriculum offers a full-day of practical, how-to training
for FPGA, DSP & embedded systems designers. The fully-customizable budurl.com/2012Xfest
training experience allows attendees to pick up to four courses from any
of the three unique training tracks. budurl.com/2012Xfest
FPGA Fundamentals Track
The FPGA Fundamentals track focuses on common design issues facing
PARTNER DEMONSTRATIONS
both new and advanced FPGA designers. AND EXHIBITS
Applications Track Xilinx Aldec
The Applications track delves deeper into design methodologies and Avnet ARM®
techniques required when designing with the Zynq™-7000 Extensible Analog Devices MathWorks
Processing Platform (EPP) and 7 series FPGAs. Maxim Spansion
Zynq-7000 EPP Track Micron FCI
TE Connectivity Samtec
The Zynq-7000 EPP track provides four courses dedicated to the ARM®
dual core Cortex™-A9 MPCore™ based device. Texas Instruments PLDA
Cypress Semiconductor Ericsson

DON’T MISS ANY X-FEST UPDATES.

JOIN THE CONVERSATION TODAY!

@avnetxfest
facebook.com/xfest2012
Learn more at budurl.com/2012Xfest Join the Avnet X-fest group!