VOLUME 23,

NUMBER 9
NOVEMBER 2010

EMBEDDED SYSTEMS DESIGN

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

Full
Speed

High
Speed Super

USB 3.0: Speed

cranking up to superspeed 14
More nasty software bugs 9
Creating an event-flow tracer 23
Ganssle’s mailbox overflows 34
Solving the USB puzzle
USB solutions for embedded applications involve
numerous complex issues.

You can apply HCC’s extensive experience and knowledge

of USB software and hardware to your product.

Pre-configured USB packages, with running sample projects,

are available for most popular microcontroller architectures
and development boards.

HCC-Embedded
COMPLETE USB SOLUTIONS

www.hcc-embedded.com • info@hcc-embedded.com
INTEGRITY RTOS has it.
No one else does.

The NSA has certified the INTEGRITY RTOS technology

to EAL6+. INTEGRITY is the most secure real-time operating
system available and the first and only technology to have
achieved this level.

The NSA also certified INTEGRITY to High Robustness, an even higher

level of security than EAL6+, with 133 additional security mandates
over and above the 161 required for EAL6+.

When security is required, Green Hills Software’s INTEGRITY

RTOS technology is the only option.

Copyright © 2010 Green Hills Software, Inc. Green Hills, the Green Hills logo, and INTEGRITY are
trademarks of Green Hills Software, Inc. in the U.S. and/or internationally. All other trademarks are
the property of their respective owners.
www.ghs.com
 Get Your Hands On What’s Next.

Scan

mouser.com The Newest Products For Your Newest Designs ™

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.
 T H E O F F I C I A L P U B L I C AT I O N O F T H E E M B E D D E D S Y S T E M S C O N F E R E N C E S A N D E M B E D D E D. C O M

COLUMNS
barr
code 9
Five more top causes of nasty
embedded software bugs
BY MICHAEL BARR
What do memory leaks, deadlocks, and
priority inversions have in common?
They’re all Hall of Famers in the pan-
EMBEDDED SYSTEMS DESIGN theon of nasty firmware bugs.
VOLUME 23, NUMBER 9
NOVEMBER 2010
break points 34
An accumulation of stuff
BY JACK G. GANSSLE

14
Catching up with the incoming
product announcements, Jack
Ganssle finds a few gems (and some
horror stories) to share..

DEPARTMENTS
Full
Speed #include 5
A matter of energy
High BY RON WILSON
Speed Super
Speed A recent panel discussion at ESC
Boston brought to light the many
complexities of measuring power
use in embedded systems.

Cover Feature: parity bit 7

USB 3.0: Delivering superspeed with 25% ESC Silicon Valley
lower power May 2–5, 2011
San Jose, CA
BY MIKE MICHELETTI http://esc-sv.techinsightsevents.com/
USB 3.0 offers new opportunities to boost battery life for both
host and endpoint functions thanks to comprehensive power ESC Chicago
management features that operate autonomously at the hard- June 6–8, 2011
ware level. Here’s a detailed description of some of USB 3.0’s Chicago, IL
http://esc-chicago.techinsightsevents.com/
power-saving features.
ESC India
July 20–22, 2011

23 Tracing of the event flow in state-based

designs
BY PETER MUELLER
Bangalore, India
www.esc-india.com/

ONLINE
Tracing is useful both during development and after the software
is released. This article explains the different parts required for www.embedded.com
realizing a tracing function and how to implement tracing of
state-based designs with minimal effort.

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,
July/August, Sept., Oct., Nov., Dec. by the EE Times Group, 600 Harrison Street, 5th floor, San Francisco, CA 94107, (415) 947-6000. Please direct advertising and editorial
inquiries to this address. SUBSCRIPTION RATE for the United States is $55 for 10 issues. Canadian/Mexican orders must be accompanied by payment in U.S. funds with addi-
tional 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-
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, EE Times Group. All material published in EMBEDDED SYSTEMS
DESIGN is copyright © 2010 by EE Times Group. 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
of successful business operation,
and our flagship product, ThreadX, T H R E
has been used in over 800 million
electronic devices and systems,
ranging from printers to smartphones, from single-chip
SoCs to multiprocessors. Time and time again, when
leading manufacturers put their company on the line,
when their engineering team chooses an RTOS for their
next critical product, they choose ThreadX.
Our ThreadX RTOS is rock-solid, thoroughly field-proven,
and represents not only the safe choice, but the most
cost-effective choice when your company’s product
simply must succeed. Its royalty-free
licensing model helps keep your BOM low,
A D and its proven dependability helps keep
your support costs down as well. ThreadX
repeatedly tops the time-to-market results
reported by embedded developers like you. All the while,
Express Logic is there to assist you with enhancements,
training, and responsive telephone support.
Join leading organizations like HP, Apple, Marvell, Philips, NASA,
and many more who have chosen ThreadX for use in over 800
million of their products – because their products are too
important to rely on anything but the best. Rely on ThreadX,
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 new PrismX™ 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 ices
append
Now with architectures
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, PrismX, StackX, and Certification Pack are trademarks of Express Logic, Inc.
All other trademarks are the property of their respective owners.
EMBEDDED SYSTEMS DESIGN

Director of Content/Media,
BY Ron Wilson #include
EE Times Group Events and Embedded
Ron Wilson
(415) 947-6317
ron.wilson@ubm.com
Managing Editor
A matter of energy
Susan Rambo
susan.rambo@ubm.com
Acquisitions/Newsletter Editor,
Embedded.com Site Editor
Bernard Cole
bccole@acm.org
O ur cover story in this issue
treats one aspect of an in-
creasingly important design
requirement: energy consumption. It
may sound like a pure hardware issue,
enough information. An audience
member at the panel warned that bat-
tery life depends not just on current-
drain and time but on details of the
current waveform: how high are the
Contributing Editors
Michael Barr, John Canosa, but software design is at least as signifi- current pulses, what is their duty cycle,
Jack W. Crenshaw, Jack G. Ganssle, cant as hardware for energy efficiency. and what is their impact on battery
Dan Saks, Larry Mittag
Once even rudimentary hardware pro- temperature, for example. Similar in-
Art Director
Debee Rommel visions—such as standby and sleep formation is necessary for selecting
debee.rommel@ubm.com modes—are in place, the responsibility regulators for AC-powered supplies.
Production Director falls on software developers at all levels System-level power-estimation
Donna Ambrosino
dambrosino@ubm-us.com
to use the modes effectively. A non- tools can help keep track of power
power-aware OS or careless applica- modes and use models. But they often
Subscriptions/RSS Feeds/Newsletters
www.eetimes.com/electronics-subscriptions tion code can negate anything the work with averages, not waveforms,
Subscriptions Customer Service (Print) hardware designers can accomplish. and are dependent on the accuracy of
Embedded Systems Design But you can’t manage what you the hardware models you plug in. One
PO Box # 3609
Northbrook, IL 60065- 3257 can’t measure, as the saying goes. A re- panelist (an FPGA vendor) suggested
embedsys@omeda.com ally interesting panel at ESC Boston that the most accurate power estima-
(847) 559-7597
this September explored the problems tions come from FPGA vendors’ tools,
Article Reprints, E-prints, and
Permissions of estimating and measuring power simply because a vendor can control
Mike O’Brien during design. Perhaps surprisingly, the hardware, power-management ar-
Wright’s Reprints
(877) 652-5295 (toll free) neither task is easy. chitecture, and much of the silicon IP.
(281) 419-5725 ext.117 The traditional approach is to sit Of course you can build a proto-
Fax: (281) 419-5712
www.wrightsreprints.com/reprints/index.cfm down with the IC datasheets, a guess type, load the software, and measure
?magid=2210 at the end-user’s use models, and a current through the actual supply
Publisher great deal of coffee, and build a spread- nodes. But because of those complex
David Blaza waveforms, even this approach can be
(415) 947-6929
sheet. But panelists pointed out that to-
david.blaza@ubm.com day, when the hardware may have very misleading. Current meters measure
Editorial Review Board complex internal power-management RMS or average current. And measur-
Michael Barr, Jack W. Crenshaw, mechanisms of its own, the datasheet ing current over a range of ten-thou-
Jack G. Ganssle, Bill Gatliff,
Nigel Jones, Niall Murphy, Dan Saks, numbers may be only a vague sugges- sand to one without disturbing the cir-
Miro Samek tion of reality. The typical operating cuit is a huge electrical problem. Just
power, for example, may represent the taking the measurements may require
average of a random scattering of very a complex test set up and perhaps a
large but randomly-spaced current programmable mixed-signal scope. It
spikes. The real shape of the complicat- may also require forcing the prototype
ed supply-current waveform will prob- into a single operating mode during
ably be highly software-dependent. the measurements.
Even if you could count on the av- So on the one hand, software has
erage or RMS figures being reasonably very significant influence over energy
Corporate—EE Times Group representative, they may not be consumption in embedded designs.
Paul Miller Chief Executive Officer
Felicia Hamerman
Brent Pearson
Group Marketing Director
Chief Information Officer
On the other hand, estimating or even
Jean-Marie Enjuto Financial Director Ron Wilson is the measuring that influence during the
Amandeep Sandhu Manager Audience Engagement
director of content/
Barbara Couchois Vice President Sales Ops
media, EE Times design is fraught. It is a nontrivial
Corporate—UBM LLC
Group Events and problem.
Marie Myers Senior Vice President, Embedded. You may
Manufacturing
Pat Nohilly Senior Vice President, Strategic
reach him at
Development and Business ron.wilson@ubm.com.
Administration
Ron Wilson, ron.wilson@ubm.com

www.embedded.com | embedded systems design | NOVEMBER 2010 5

 Mission Critical
Make the Dreamliner Breakthrough
a reality dependability

Boeing 787 Dreamliner

The Wind River VxWorks platform
proved instrumental in the development
of the Boeing 787 Dreamliner—history’s
fastest selling wide-body aircraft.

Wind River embedded systems deliver the cutting-edge reliability and performance that fuel innovation.
Boeing’s 787 Dreamliner is taking flight with an innovative integrated modular avionics (IMA)-based Common Core System (CCS)
developed by GE Aviation and enabled by Wind River.

Our industry-leading VxWorks 653 partitioning operating system is the foundation for GE’s CCS, which serves as the Dreamliner’s
central nervous system by infallibly orchestrating the operation of over 70 applications supplied by over 15 Boeing suppliers.

VxWorks enables the asynchronous integration of multiple suppliers and allows for applications of different RTCA DO-178B safety
criticality levels to reliably run on a single shared computer platform.

It’s the kind of cutting-edge dependability and proven performance that’s made Wind River a trusted leading provider of
advanced embedded solutions for aerospace and defense.

Take your innovation to new heights. Contact us today for our Mission Critical Toolkit,
now available for a limited time at www.windriver.com/missioncritical/safety.

©2010 Wind River Systems, Inc. The Wind River logo is a trademark, and Wind River is a registered trademark of Wind River Systems, Inc. Other marks are the property of their respective owners.
 parity bit
The MIPS benchmark can still be useful
G aurang Kavaiya (“Why MIPS is
just a number,” October, p. 16,
www.eetimes.com/design/embed-
ded/4209273/Why-MIPS-is-just-a-num-
ber) says “If generic C code is used, the
MIPS requirement may increase by
three times.” That is a huge factor. The
Cengine prototype that I have in simu-
lation running C statements and func-
tion calls has fmax about 200 Mhz and
takes two to four clock/CPU cycles per
C statement plus one cycle per opera-
tor in assignments and comparisons.
Embedded memory blocks are operat-
ing in parallel and a new CPU archi-
tecture is used. [Determining millions
of instructions per second (MIPS)] is a
complex problem for which there will
never be a single parameter to rate the
solution. One fundamental require-
ment comes down to response time. The
more things that are involved, the more
complex the calculation. —KarlS
To further complicate the equation, as
with programmable logic capabilities,
the internal hardware peripherals set
can have a pretty big impact too. For
example, hardware SPI, I2C, or PWM:
all of those can be implemented in soft-
ware via bit-banging, but having hard-
ware do all of the work can significantly
reduce the MIPS requirements. The
choice of compiler can have an impact
too. How well does your compiler opti-
mize its code? Does it allow easy em-
bedding of inline assembly code? Food
for thought to make an already complex
decision process even more so.
—Duane Benson
It’s interesting how very differently soft-
ware designers and hardware designers
think about this issue of MIPS and how
many are required for a particular ap-
plication. It may seem strange to a
hardware designer, for example, to con-
template how many MIPS it takes to
bit-bang an output pin to do something
as trivial as a PWM—because such a
function takes so little digital logic, it
would never occur to some of us that a
hardware-software trade-off should be
considered.In the context of a system-
level application, MIPS does not have to
!To the end user, the only
relevant MIPS number is
!the number of available,
unused MIPS when the sys-
!tem is running full blast
doing everything required.
be a mostly meaningless number be-
tween 0 and several thousand. The rele-
vant number of MIPS is the number
left over after the MCU/SoC has ful-
filled all of its requirements—whether
that includes brushless DC motor con-
trol, SPI communications, audio filter-
ing, video decoding, or whatever. To the
customer or the end user, the only
MIPS number that is relevant is the
number of available, unused MIPS
when the system is running full blast
and doing everything required of it.
That is the resource available for the
customer to run his own apps or make
his own customizations.
—Frank Eory
Theoretical determination of the MIPS
requirement is for me seldomly useful.
What is more accurate is to get a practi-
cal measure of certain critical execution
profiles for a particular implementa-
tion. To this end the SDK’s are useful.
Once I have a good fit, I may apply
margin of 30% to 100% to the require-
ment, this may be costly approach ini-
www.embedded.com | embedded systems design | NOVEMBER 2010
tially as one may overestimate the re-
quirement where a lower-cost MCU
might have sufficed but, by continually
assessing the execution profile during
development, one can get a better idea
of the final MIPS requirement.
—Trevormh
Some factors that aren’t so obvious.
MIPS is not the main problem, because,
now, languages, compilers, optimizers,
and processor cores are designed to
produce MIPS. The main problem is
the hierarchical memory that can have
an impact on the high level of perform-
ance required for some applications. No
compiler can manage this; solutions ex-
ist but are usually homemade. With
modern languages, when you write an
application, you describe the operations
not the operands. Often the operands
are just a variable declaration. The
problems become more difficult when
you have to share data in real-time mul-
tiprocessing application. —global hawk
Bottom line of the article: MIPS pa-
rameter shows performance of CPU
for ideal case of the full CPU load.
Most the real control tasks are too far
from this assumption due to peripher-
als, SDRAM or DDRAM, cache, etc.
MIPS parameter is especially useful
when comparing CPUs of the same ar-
chitecture. For example, if selecting
another MCU of Coldfire family with
a two-times faster clock, it’s reasonable
to expect improving the FFT time
twice. Also MIPS parameter is useful
for estimating the CPU time of pure
calculations, similar to digital filter.
—YevgeniT
We welcome your feedback. Letters to the
editor may be edited. Send your comments to
Ron Wilson at ron.wilson@ubm.com or post a
comment online, under the article you wish to
discuss. We edit letters and posts for brevity.
7
 Fail Faster.
Succeed Sooner.

Prototype Your Ideas Faster with NI Graphical System Design.

PRODUCT PLATFORM
Through the large number of prototypes he created to get the first working
light bulb, Thomas Edison taught engineers and scientists that building a NI LabVIEW
functional prototype is fundamental in bringing ideas to life. NI LabVIEW NI CompactRIO
graphical programming tools and NI customizable off-the-shelf hardware
NI Single-Board RIO
can transform an idea into a functional prototype in weeks, versus months,
NI C Series I/O Modules
and lower the risk of your next project.

>> Get to market faster with prototyping tools at ni.com/succeed 888 279 9833

©2010 National Instruments. All rights reserved. CompactRIO, LabVIEW, National Instruments, NI, and ni.com are trademarks of National Instruments.
Other product and company names listed are trademarks or trade names of their respective companies. 2412
By Michael Barr
barr code
Five more top causes of nasty embedded
software bugs
F inding and killing latent bugs in
embedded software is a difficult
business. Heroic efforts and ex-
pensive tools are often required to
trace backward from an observed
memory leaks whether we’re talking
about an embedded system or a PC
program. However, the long-run-
ning nature of embedded systems
combined with the deadly or spec-
crash, hang, or other unplanned tacular failures that some safety-
run-time behavior to the root cause. critical systems may have make this
In the worst scenario, the root cause one bug you definitely don’t want in
damages the code or data in a way your firmware.
that the system still appears to work Memory leaks are a problem of
fine or mostly fine—at least for a ownership management. Objects al-
while. located from the heap always have a
In an earlier column (“Five top creator, such as a task that calls
causes of nasty embedded software malloc() and passes the resulting
bugs,” April 2010, p.10, online at pointer on to another task via mes-
www.embedded.com/columns/ sage queue or inserts the new buffer
barrcode/224200699), I covered into a meta heap object such as a
what I consider to be the top five linked list. But does each allocated
causes of nasty embedded software object have a designated destroyer?
bugs. This installment completes the
top 10 by presenting five more nasty
firmware bugs as well as tips to find,
! What do memory leaks,
deadlocks, and priority
Which other task is responsible and
how does it know that every other
task is finished with the buffer?
fix, and prevent them.

BUG 6: MEMORY LEAK ! inversions have in com-

mon? They’re all Hall of
Best practice: There is a simple
way to avoid memory leaks and
that is to clearly define the owner-

!
Eventually, systems that leak even small Famers in the pantheon
amounts of memory will run out of
free space and subsequently fail in of nasty firmware bugs.
nasty ways. Often legitimate memory
areas get overwritten and the failure isn’t registered until
much later. This happens when, for example, a NULL
pointer is returned by a failed call to malloc() and the
caller blindly proceeds to overwrite the interrupt vector
table or some other valuable code or data starting from
physical address 0x00000000.
Memory leaks are mostly a problem in systems that
use dynamic memory allocation.1 And memory leaks are
Michael Barr is the author of three books and over
50 articles about embedded systems design, as
well as a former editor in chief of this magazine.
Michael is also a popular speaker at the Embedded
Systems Conference and the founder of embedded
systems consultancy Netrino. You may reach him
at mbarr@netrino.com or read more by him at
www.embeddedgurus.net/barr-code.
ship pattern or lifetime of each type
of heap-allocated object. Figure 1
shows one common ownership pat-
tern involving buffers that are allo-
cated by a producer task (P), sent through a message
queue, and later destroyed by a consumer task (C). To
the maximum extent possible this and other safe design
patterns should be followed in real-time systems that use
the heap.2
BUG 7: DEADLOCK
A deadlock is a circular dependency between two or more
tasks. For example, if Task 1 has already acquired A and is
blocked waiting for B while Task 2 has previously acquired
B and is blocked waiting for A, neither task will awake. Cir-
cular dependencies can occur at several levels in the archi-
tecture of a multithreaded system (for example, each task is
waiting for an event only the other will send) but here I am
concerned with the common problem of resource dead-
locks involving mutexes.

www.embedded.com | embedded systems design | NOVEMBER 2010 9

 barr code
! Resource sharing combined with the
priority-based preemption found in
! commercial real-time operating sys-
tems can cause priority inversion,
! which is equally difficult to reproduce
and debug.
Best practice: Two simple programming practices are
each able to entirely prevent resource deadlocks in embedded
systems. The first technique, which I recommend over the
other, is to never attempt or require the simultaneous acqui-
sition of two or more mutexes. Holding one mutex while
blocking for another mutex turns out to be a necessary con-
dition for deadlock. Holding one mutex is never, by itself, a
cause of deadlock.3
In my view, the practice of acquiring only one mutex at a
time is also consistent with an excellent architectural practice
of always pushing the acquisition and release of mutexes into
the leaf nodes of your code. The leaf nodes are the device driv-
ers and reentrant libraries. This keeps the mutex acquisition
and release code out of the task-level algorithmics and helps to
minimize the amount of code inside critical sections.4
The second technique is to assign an ordering to all of the
mutexes in the system (for example, alphabetical order by mu-
tex handle variable name) and to always acquire multiple mu-
texes in that same order. This technique will definitely remove
all resource deadlocks but comes with an execution-time price.
I recommend removing deadlocks this way only when you’re
dealing with large bodies of legacy code that can’t be easily
refactored to eliminate the multiple-mutex dependency.
BUG 8: PRIORITY INVERSION
A wide range of nasty things can go wrong when two or more
tasks coordinate their work through, or otherwise share, a sin-
Priority inversion.
Priority
Inversion!
H the resource shared by low and high—preempts low (time t3).
M There could even be multiple medium priority tasks.
L
t t t time
1 2 3
Figure 2
10 NOVEMBER 2010 | embedded systems design | www.embedded.com
A design pattern with clear ownership.
Task P
Message queue
Task C
alloc free
Buffer pool
Figure 1
gleton resource such as a global data area, heap object, or pe-
ripheral’s register set. In the first part of this column (www.em-
bedded.com/columns/barrcode/224200699), I described two of
the most common problems in task-sharing scenarios: race
conditions and non-reentrant functions. But resource sharing
combined with the priority-based preemption found in com-
mercial real-time operating systems can also cause priority in-
version, which is equally difficult to reproduce and debug.
The problem of priority inversion stems from the use of an
operating system with fixed relative task priorities. In such a
system, the programmer must assign each task it’s priority. The
scheduler inside the RTOS provides a guarantee that the high-
est-priority task that’s ready to run gets the CPU—at all times.
To meet this goal, the scheduler may preempt a lower-priority
task in mid-execution. But when tasks share resources, events
outside the scheduler’s control can sometimes prevent the
highest-priority ready task from running when it should.
When this happens, a critical deadline could be missed, caus-
ing the system to fail.
At least three tasks are required for a priority inversion to
actually occur: the pair of highest and lowest relative priority
must share a resource, say by a mutex, and the third must have
a priority between the other two. The scenario is always as
shown in Figure 2. First, the low-priority task acquires the
shared resource (time t1). After the high priority task preempts
low, it next tries but fails to acquire their shared resource (time
t2); control of the CPU returns back to low as high blocks. Fi-
nally, the medium priority task—which has no interest at all in
At this point the priorities are inverted: medium is allowed to
use the CPU for as long as it wants, while high waits for low.
The risk with priority inversion is that it can prevent the
high-priority task in the set from meeting a real-time deadline.
The need to meet deadlines often goes hand-in-hand with the
choice of a preemptive RTOS. Depending on the end product,
this missed deadline outcome might even be deadly for its
user!
 Announcing the

RX Design Contest
you do with
n
ca

...

 165 DMIPS at 100MHz

500µA/MHz
What


 Zero-wait Flash
at will you d
 Ethernet, USB, CAN
h
W

ow
ith...
t weapon...
re  Over $110,000 in
Cash and Prizes
ec
Your s

 Free to Qualified
Contestants,
the RX62N
Development Kit

Get details on how to enter, and the over $110,000 in cash and prizes.
 www.renesasRulz.com/rx-contest
Renesas Partners participating in the RX Design Contest

© 2010 Renesas Electronics America Inc.

 barr code
! A generation of embedded software devel-
opers are unaware of the proper technique.
!
There is simply too little feedback from
non-reproducible deadline misses in the
! field to the original design team—unless a
death and a lawsuit forces an investigation.
One of the major challenges with priority inversion is that
it’s generally not a reproducible problem. First, the three steps
need to happen—and in that order. And then the high priority
task needs to actually miss a deadline. One or both of these
may be rare or hard to reproduce events. Unfortunately, no
amount of testing can assure they won’t ever happen in the
field.5
Best practice: The good news is that an easy 3-step fix will
eliminate all priority inversions from your system.
• Choose an RTOS that includes a priority-inversion work-
around in its mutex API. These work-arounds come by
various names, such as priority inheritance protocol and
priority ceiling emulation. Ask your sales rep for details.
• Only use the mutex API (never the semaphore API, which
lacks this work-around) to protect shared resources within
real-time software.
• Take the additional execution time cost of the work-
around into account when performing the analysis to
prove that all deadlines will always be met. Note that the
method for doing this varies by the specific work-around.
Note that it’s safe to ignore the possibility of priority inver-
sions if you don’t have any tasks with consequences for missing
deadlines.
BUG 9: INCORRECT PRIORITY ASSIGNMENT
Get your priorities straight! Or suffer the consequence of
missed deadlines. Of course, I’m talking here about the relative
priorities of your real-time tasks and interrupt service rou-
tines. In my travels around the embedded design community,
I’ve learned that most real-time systems are designed with ad
hoc priorities.
Unfortunately, mis-prioritized systems often “appear” to
work fine without discernibly missing critical deadlines in test-
An example of jitter in the timing of a 10-ms task.
> 10 ms
< 10 ms
Figure 3
12 NOVEMBER 2010 | embedded systems design | www.embedded.com
ing. The worst-case workload may have never yet happened in
the field or there is sufficient CPU to accidentally succeed de-
spite the lack of proper planning. This has lead to a generation of
embedded software developers being unaware of the proper
technique. There is simply too little feedback from non-repro-
ducible deadline misses in the field to the original design
team—unless a death and a lawsuit forces an investigation.
Best practice: There is a science to the process of assigning
relative priorities. That science is associated with the “rate mo-
notonic algorithm,” which provides a formulaic way to assign
task priorities based on facts. It is also associated with the “rate
monotonic analysis,” which helps you prove that your correct-
ly-prioritized tasks and ISRs will find sufficient available CPU
bandwidth between them during extreme busy workloads
called “transient overload.” It’s too bad most engineers don’t
know how to use these tools.
There’s insufficient space in this column for me to explain
why and how RMA works. But I’ve written on these topics be-
fore and recommend you start with “Introduction to Rate-
Monotonic Scheduling”6 and then read my column “3 Things
Every Programmer Should Know About RMA.”7
Please know that if you don’t use RMA to prioritize your
tasks and ISRs (as a set), there’s only one entity with any guar-
antees: the one highest-priority task or ISR can take the CPU
for itself at any busy time—barring priority inversions!—and
thus has up to 100% of the CPU bandwidth available to it. Also
note that there is no rule of thumb about what percentage of
the CPU bandwidth you may safely use between a set of two or
more runnables unless you do follow the RMA scheme.
BUG 10: JITTER
Some real-time systems demand not only that a set of dead-
lines be always met but also that additional timing constraints
be observed in the process. Such as managing jitter.
An example of jitter is shown in Figure 3. Here a variable
amount of work (blue boxes) must be completed before every
10 ms deadline. As illustrated in the figure, the deadlines are all
met. However, there is considerable timing variation from one
run of this job to the next. This jitter is unacceptable in some
systems, which should either start or end their 10 ms runs
more precisely.
If the work to be performed involves sampling a physical
input signal, such as reading an analog-to-digital converter, it
will often be the case that a precise sampling period will lead to
higher accuracy in derived values. For example, variations in
the inter-sample time of an optical encoder’s pulse count will
CONTINUED ON PAGE 32
< 10 ms
 HALF THE TWICE THE
POWER PERFORMANCE
A WHOLE NEW WAY OF THINKING.

Introducing the 7 Series. Highest performance,

lowest power family of FPGAs.

Lowest power Powerful, flexible, and built on the only unified

and cost
architecture to span low-cost to ultra high-end FPGA
families. Leveraging next-generation ISE Design
Best price
and performance Suite, development times speed up, while protecting
your IP investment. Innovate without compromise.
Highest system
performance
and capacity LEARN MORE AT WWW.XILINX.COM / 7

© Copyright 2010. Xilinx, Inc. XILINX, the Xilinx logo, Artix, ISE, Kintex, Spartan, Virtex, and other designated brands included herein are trademarks of Xilinx in the United
States and other countries. All other trademarks are the property of their respective owners.
 cover feature

USB 3.0 offers new opportunities to boost battery life for both host and endpoint
functions thanks to comprehensive power management features that operate
autonomously at the hardware level.

USB 3.0: Delivering

superspeed with
25% lower power
BY MIKE MICHELETTI

T he desire to extend battery life in the fast growing mobile com-

puting market has placed a new spotlight on power management
within portable systems. Developers of laptops, netbooks, smart
phones, and tablets now scrutinize every amp of power usage at
the system level in their drive for better power efficiency. The in-
troduction of USB 3.0 brings new opportunities to boost battery
life for both host and endpoint functions thanks to comprehen-
sive power-management features that operate autonomously at
the hardware level.

Designed to overcome the draw-

backs of the Advanced Power Manage-
ment (APM) model, the Advanced Con-
figuration and Power Interface, or ACPI,
was introduced in1997. The specifica-
tion brings some level of power aware-
ness to the BIOS, system hardware and
software. ACPI relies on tables in the
BIOS to define the power modes for in-
dividual peripherals. The operating sys-
tem then uses these definitions to decide
when to switch a device, or the entire
system, from one power state to another.
USB 2.0 has supported this software-
based approach relying on suspend-re-
sume commands to place the universal
serial bus in a power-reduced state.
However, these ACPI-based implemen-
tations have been plagued by stability
and latency issues.
Implementing an effective power-
management policy for interfaces such

14 NOVEMBER 2010 | embedded systems design | www.embedded.com


as USB presents additional challenges.
USB is one of the few peripheral buses
that allow different types of devices
with varying usage frequencies to at-
tach simultaneously. Many of these
USB devices experience extended peri-
ods of idle. In addition, developers
must contend with the growing popu-
larity of devices that draw power or
recharge batteries over USB.
The USB 2.0 power-management
Full
Speed
High
Speed Super
Speed
model was enhanced with the intro-
duction of Link Power Management
(LPM) in the EHCI specification 1.1.
The new LPM transaction is similar to
the existing USB 2.0 suspend/resume
capability, however—it defines a mech-
anism for faster transition of a root
port from an enabled state (L0) to a
new sleep state (L1). Implementing
LPM requires changes at both the chip
and software layers, which have slowed
market adoption. Table 1 outlines the
LPM entry and exit timing windows.
USB 3.0: DESIGNED FOR POWER
EFFICIENCY
Recognizing that continued adoption
of USB will require improved power
efficiency, the USB Implementers Fo-
rum (USB-IF) has made power man-
agement a cornerstone to its next gen-
eration interface, SuperSpeed USB. For
backwards compatibility, USB 3.0 de-
vices are required to support both 2.0
and 3.0 link speeds. USB 3.0 devices will
maintain separate controllers and physi-
cal layers for high/full speed and super-
speed links. To ensure power savings
gained while operating in USB 3.0 mode
are not lost when 3.0 hosts are connect-
ed to legacy 2.0 devices, all USB 3.0
ports (host and device) are now required
to support the LPM feature above when
operating at high/full speed. Correct
power-management operation in both
! The higher power required
to drive the 5-GHz signal-
! ing in superspeed mode is
more than offset by the
!
improved efficiency of 3.0
data transfers.
legacy USB 2.0 mode as well as super-
speed mode will be verified during USB
3.0 logo certification.
SuperSpeed USB uses dual simplex
differential signaling operating at 5 GHz
frequency to provide a 10x performance
increase over high-speed USB. The high-
er power required to drive the 5 GHz
signaling in superspeed mode is more
25% less system power is used during a SuperSpeed 20-Mbyte data
transfer compared with high-speed.
High-speed USB 2.0
data transfers
13 W
12.5 W
System power
7W
Figure 1
16 NOVEMBER 2010 | embedded systems design | www.embedded.com
than offset by the improved efficiency of
3.0 data transfers. The USB-IF estimates
the system power necessary to complete
a 20-MB superspeed data transfer will be
25% lower when compared with high-
speed mode. This is possible because
several architectural issues that ham-
pered USB 2.0 power efficiency have
been enhanced in the USB 3.0 specifica-
tion below:
• Elimination of device polling by al-
lowing devices to asynchronously
signal when they need service from
the host.
•
•
The ability for device ports to initi-
ate low-power states.
The ability for device ports to re-
•
move power from all or portions of
their circuitry (function level sus-
pend).
The ability to use data streaming for
bulk transfers.
• More efficient token/data/hand-
shake sequence.
• The addition of packet routing
eliminates the need to broadcast
packets to all endpoints downstream
from hubs.
In addition to these changes, USB
3.0 improves efficiency by implementing
power management at the link layer to
provide greater speed and precision in
managing power consumption. Figure 1
SuperSpeed USB 3.0
data transfers
Average system
power using
high-speed
device
9.7 W
Average system
power using
superspeed
device
7.5 W
Time
 cover feature
USB 2.0 Link Power Management (LPM) states.
Entry Exit
L1 Sleep Host-initiated via LPM extended transaction Device or host-initiated via resume signaling;
Entry: ~10 µs Remote-wake can be (optionally) enabled/disabled via software
Exit latency: ~70 µs to 1 ms (host-specific).
L2 Suspend Implicitly entered after 3 ms of link inactivity Device- or host-initiated via resume signaling; (OS-dependent)
Table 1

shows the power savings when using superspeed data transfer.
Table 2 outlines the four power states in USB 3.0. Each
state incrementally lowers power use while increasing the al-
lowed exit latency. This method provides a more adaptive
power-management model that uses timers and link-state
awareness to reduce power use. Although the specifics of how
devices will lower their power draw are left to the vendor,
Table 2 outlines the link states defined by the USB 3.0 specifi-
cation.
Most early 3.0 devices rely on inactivity timers to initiate
entry into the U1 state. In the U1 state, these devices will typi-
cally reduce power to their SuperSpeed PHY. These devices will
progressively lower power to other parts of the interface as the
inactively period increases. In some cases, host ports will im-
mediately request transition to the most aggressive power sus-
pend state (U3) during idle periods. This more rigid approach
to lowering power draw is generally initiated by higher layers
and is based on expected usage patterns for specific device
classes. USB 3.0 also preserves function-suspend features from
USB 2.0 allowing individual functions to be placed into a lower
power state. The remainder of this article explores the Super-
Speed power-management model and the power-state transi-
tions required by the USB 3.0 specification.
These timers provide the flexibility to delay power state
transitions for specific applications, such as Blu-Ray disk
writers, that could suffer usability problems if response la-
tency is introduced. The U1 and U2 inactivity timeout can
be as long as 127 µs and 65 ms respectively. Sending an
LMP with the U1 inactivity timeout value between the
range 0x01-0xFE also serves to implicitly enable the host
port to initiate U1/U2 transitions.
4. Host will inform the device of the U1/U2 System Exit La-
tency using SET_SEL. Reporting System Exit Latency
(SEL) allows the host to more intelligently manage power
state transitions for periodic endpoints, such as isochro-
nous devices. SEL represents the total latency to transition
the entire path of links between the device and host from
U1/U2 back to U0. It provides a mechanism for higher lay-
ers to reduce or even disable U1/U2 entry if system exit la-

CONFIGURE USB DEVICES FOR POWER MANAGEMENT

Four steps are involved in configuring a USB 3.0 device for
power management.

1. Devices must report their level of support for power

management within their Endpoint Descriptors. While
it’s required for all devices to support power management
to gain SuperSpeed certification, USB developers may elect
to configure devices with this functionality disabled for
specific applications.
2. Host must send SET_FEATURE to U1/U2_ENABLE during
configuration. Alternatively, some peripheral devices that
are used intermittently may aggressively direct their own
links to the lower power state. Higher layers require a
mechanism to enable (or disable) the upstream port’s abil-
ity to request low-power entry. When asserted, U1/U2_EN-
ABLE allows the upstream port to initiate entry to U1/U2.
3. Host must send Link Management Packet (LMP) to de-
fine the U1/U2 Inactivity Timeout. The U1/U2 inactivity
timers allow the host to define the time interval between
the U0 > U1 and the U1 > U2 power-state transitions.

www.embedded.com | embedded systems design | NOVEMBER 2010 17

 cover feature
Logical link states defined in USB 3.0.
Link Key
state Description characteristics
U0 Link active
U1 Link idle, fast exit RX & TX circuit quiesced
U2 Link idle, slow exit Clock generation circuit also quiesced Low ms range
U3 Suspend Portions of device power removed
Table 2
tency exceeds the minimum service
intervals reported by the device. Fig-
ure 2 shows a host-device exchange
of Power Management Configura-
tion data.
TRANSITIONING FROM U0 >U1
Either link partner can initiate a transi-
tion from U0 >U1 based on the expira-
tion of the PORT_U1_TIMEOUT timer. Al-
ternatively, some devices may attempt to
save power by proactively initiating U1
mode more aggressively by setting their
U1_Enable feature selector and reporting
their U1 Inactivity Timeout equal to 0.
Initial entry into a low-power state
is always negotiated between ports using
the LGO_Un followed by LAU (accept) or
LXU (reject). The port sending the LAU
should wait until it receives a single
LPMA (accept response), which serves as
a final handshake before transitioning
to any of the low-power states. To maxi-
mize power savings, ports are required
to respond to power-management com-
Host-device exchange of Power Management Configuration data.
Figure 2
18 NOVEMBER 2010 | embedded systems design | www.embedded.com
Exit
latency
NA
µs range
Higher ms range
mands within the PM_LC_TIMER time-
out. If the port initiating the state
change does not receive an LAU or LXU
before the PM_LC_TIMER expires (3 µs),
it’s considered a link error and should
initiate recovery.
! The U3 state is a deep
power-saving state where
! interface power may be
removed. It’s the equiva-
! lent of Suspend state in
USB 2.0
Alternatively, if after sending the
LAU, the device doesn’t receive the LPMA
or any other valid traffic (such as TS1,
LFPS, Link Command) before the
PM_ENTRY_TIMER expires (6 µs), it
should proceed to the low-power state
anyway. In this event, it’s assumed the
LPMA was corrupted and the port issuing
the LGO_U1 has already entered U1.
TRANSITIONING FROM U1 > U2
The transition from U1 to U2 is general-
ly triggered by a second timer called the
U2_Inactivity_Timer which, when
enabled, will silently move the link to the
lower power U2 state. This U2 inactivity
time out value is reported by the end-
point’s configuration descriptor. It’s the
host responsibility to enable this timer
using the U2 Inactivity Timeout LMP.
When a link enters U1, this starts the U2
inactivity timer and provides a mecha-
nism for the port to autonomously
move to the U2 state.
For some devices, it may not be
practical for individual endpoint func-
tions to enter U1 (in other words, com-
posite devices that may have a shared
PLL). Some devices may bypass the U1
mode altogether and instead transition
the link from U0 directly to U2 using the
LGO_U2 link command thus allowing a
larger portion of the SuperSpeed inter-
face to be suspended. A device can be
configured to support U2 exclusively
with SET_FEATURE: U1_DISABLE.
As mentioned previously, some de-
vices may attempt to save more power
by immediately transitioning to U1 or
U2, using the U1/U2_Enable feature se-
lector. For example, storage devices may
immediately issue an LGO_U2 after each
transfer if the packets pending bit is de-
asserted in the previous transaction
packet.
TRANSITIONING FROM U0 > U3
The U3 state is a deep power-saving state
where interface power may be removed.
It’s the equivalent of Suspend state in
USB 2.0, and it can only be initiated by a
downstream facing port using the
LGO_U3 followed by LAU (accept). Up-
stream facing ports are not allowed to
reject the LGO_U3. While the goal is to
conserve as much power as possible,
while in U3, a port must still maintain
its Warm Reset detect, U3 wake detect,
(for host initiated wakeup) as well as
Mouser is proud to give an approving nod

to those who never stop thinking what’s next.

To all those inquisitive minds that challenge

convention by asking the simple question…

What if? The ones committed to developing new

technological breakthroughs that make all our

lives easier. We want you to know that we’re here

to support you and all your ideas. No matter how

far out there they might seem.

Keep dreaming.

mouser.com The Newest Products For Your Newest Designs ™

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.
 cover feature
Test tools capable of monitoring link state changes with independent
timers in each state are essential for identifying timing violation
Figure 3
wake transmission (for remote_wake
capable devices).
TRANSITIONING FROM U1/U2 >U0
Returning a link from U1 to U0 active
state mandates the shortest recovery
time in the range of 10 µs. This transi-
tion is normally initiated when a pack-
et needs to be transmitted, such as an
IN message from the host, or an ERDY
message from the device. Ports in lower
power states need a mechanism to sig-
nal its link partner to begin the link re-
covery process. Low Frequency Period-
ic Signaling (LFPS) is a 50-MHz
side-band signal that provides a port
with a low-power mechanism to send a
“wake signal” to a link partner. Both
sides must receive an LFPS “hand-
shake” to avoid entering the Recovery
link state before the far-end receiver is
ready.
To deliver acceptable performance,
SuperSpeed devices use a low-latency
recovery sequence that provides a
streamlined way to retrain links when
exiting these low-power conditions. Su-
perSpeed ports may also enter the Re-
covery state when errors are detected
during data transfers. In both cases,
only TS1 and TS2 ordered sets are ex-
changed with the goal of returning the
link to U0 as quickly as possible.
20 NOVEMBER 2010 | embedded systems design | www.embedded.com
RESOLVING CONFLICTS BETWEEN
COMMANDS
Numerous rules and conditions are de-
fined in the USB 3.0 specification to pre-
serve the integrity of the link during
power-state changes. Included are obvi-
ous requirements such as disallowing
devices from starting low-power transi-
tions unless they have transmitted and
received all pending data packets, ac-
knowledgements, flow-control link com-
mands, header and buffer credit adver-
tisements. There are also rules to ensure
links maintain coherency in the event an
expected power-management response
is not received.
For example, a port that sends U1 or
U2 exit signal but does not receive an
LFPS handshake from its link partner
should transition to the SS.disabled state
(assumes the sleeping device is removed
from the system). Because power-state
changes can be initiated by both host
and peripheral device ports, several rules
are designed to manage link-state race
conditions and potential conflicts be-
tween ports. For example, peripheral de-
vices that have sent an LGO_U1 or
LGO_U2 and also received an LGO_U3,
should wait until they receive an LXU
from the host and then send an LAU ac-
cept for the U3 request.
In the case of a host port that has
been directed (by a higher layer) to initi-
ate a transition to U3 while a transition
to U1 or U2 has been initiated but not
yet completed, the host port should
complete the in-process transition to U1
or U2, then immediately return to U0
and request entry to U3.
TESTING AND VERIFYING USB 3.0
POWER MANAGEMENT
To ensure USB 3.0 devices properly im-
plement these power management be-
haviors, they will be verified during the
USB-IFs SuperSpeed certification pro-
gram. Testing devices to ensure reliable
operation in power-managed environ-
ments raises a substantial verification
challenge. Post-silicon functional test
teams may struggle to simply initiate
power-management transitions as the
necessary commands occur at the low-
est layers making them difficult to con-
trol using software. Entrance and exit
from these low-power states must occur
within rigid predefined time limits.
This task is greatly simplified by proto-
col-layer test tools that have the follow-
ing capabilities:
• Low-level traffic generation—To
test many of the link states outlined
above requires special test systems
that can control and manipulate the
logical link layer. Most functional
test teams rely on traffic generators
capable of emulating real device be-
haviors to perform this testing.
These tools should be capable of
creating intentional timing viola-
tions and invalid state transitions to
test error recovery on the device-un-
der-test. The ability to arbitrarily
control link-layer handshaking in a
consistent and repeatable way is im-
portant for validating power man-
agement and other USB 3.0 link lay-
er behaviors.
• Accurate capture of U1 recovery se-
quence—The SuperSpeed transition
from U1 to the active state
(Ux_EXIT_TIMER) mandates both
ports should enter U0 within 6 ms
or the link will enter SS.disabled.
 cover feature
Unlike Power-on link training, re- Power monitoring tools measure and display vBUS power draw
covery from U1 uses a fast link- graphically in a timeline format.
training sequence without the added
equalization training symbols. This
frequent retraining can occur in as
little as 1µs, which places consider-
able pressure on analysis tools as
they must seamlessly capture the
LFPS handshaking and achieve 5-
GHz signal lock during this short-
ened link-training sequence.
• Triggering on power link-state
changes—Traffic at the logical link
layer is invisible to the upper layers
of USB 3.0 protocol making it im-
possible to see Link Commands us-
ing software-based tools. This man-
dates using an inline protocol
analyzer capable of accurately cap-
turing link-layer traffic between de-
vices. Triggering on link commands
such as the LGO/LAU exchange and
the LFPS wake signals are critical for
efficient power management debug.
• Triggering on power-management
timeouts—Returning to U0 from
the U1 low-power state has proven
to be a common problem area for
early devices. This transition in par-
ticular can occur hundreds of times
in only a few seconds. To minimize
latency at the application layer, de-
vices are required to enter and exit
Figure 4
power save modes within very short
timing windows. For example, dur-
ing the low-power exit sequence,
• Monitoring VBUS power draw—
VBUS power supplied by the down- Mike Micheletti is the senior product mar-
keting manager at LeCroy with over 10
both link partners must exchange stream facing port can represent a years of experience defining high-speed
an LFPS exit handshake within 2 ms significant source of battery drain serial data acquisition solutions for USB,
(tNoLFPSResponseTimeout). If ei- for mobile platforms. Test equip- WiMedia, Bluetooth, SAS, SATA, and Fi-
ther side fails to send the required ment is now available that merges bre Channel. Micheletti is a regular con-
tributor to the USB-IF Compliance Work-
response, the opposite link will go voltage meter functionality with ing Group.
to SS.disabled and the link should protocol analyzer features. These
revert to USB 2.0 mode. Testing systems, such as the one shown in
these behaviors is simplified if de- Figure 4 by LeCroy, help users cor- FURTHER READING:
velopers can set up independent relate actual VBUS power draw with 1. Ethier, Sheridan. “Application-Driven
event timers that trigger when ei- protocol-layer state changes. These Power Management,” 2004, QNX Software
ther a handshake or the required tools will typically display voltage Systems Ltd.
state change is late. It’s particularly graphically in a timeline format. 2. “Universal Serial Bus 3.0 Specification,”
useful to have a mechanism, such as This power information is synchro- USB Implementers Forum Inc., 2008,
that shown in Figure 3, for captur- nized to I/O requests, enabling users www.usb.org.
ing rare or intermittent timing vio- to correlate power use at the electri- 3. Walsh, James. “SuperSpeed USB Power
Management,” 2008, www.usb.org.
lations during these power-manage- cal layers with commands occurring
ment transitions. at the higher layers. ■

www.embedded.com | embedded systems design | NOVEMBER 2010 21

 CONCEPT TO SILICON & PROTOTYPE
COMPLETE SILICON & EMBEDDED SYSTEM SOLUTIONS

Turn Key System Design ASIC Design Embedded Software Development FPGA & Board Design

Infotech Enterprises is an 8,000 employee Global Engineering Services company focused on providing “concept to

silicon and prototype” solutions for ASIC/FPGA Engineering and Embedded Software Development. Our comprehensive

and highly skilled design solution team has been serving the Hi-Tech Industry and the manufacturing OEM’s for 20 years.

We provide:

Innovative client centric solutions to meet current design requirements & roadmaps for future design trends

Reliable and cost effective services that combine global delivery with local interface

Reduced product development costs and faster time-to-market

An impeccable track record of “first pass silicon success” over 200+ ASIC tapeouts

Australia | Canada | France | Germany | India | Japan | Malaysia | Netherlands | Norway | New Zealand |Sweden| Singapore | UAE | UK | USA
www.info t ech- enterprises.co m e n g i ne e r i ng @ i nf o t e ch - enterprises.com
 feature

Tracing is useful both during development and after the software is released. Here is an
explanation of the different parts required for realizing a tracing function and how to
implement tracing of state-based designs with minimal effort.

Tracing of the event

flow in state-based
designs
F
BY PETER MUELLER

inite state machines (FSMs) are a well-established tool for the

design of embedded systems. Using state machines offers many
benefits throughout the whole development process.1 In an FSM-
based software architecture the application is designed as indi-
vidual state machines. Such a system design can be realized
with or without an operating system.

In systems with real-time operating
systems (RTOSes), the individual state
machines typically run in its own task.
Tasks are generally constructed as
while () loops, and the task body real-
izes the state machine. After an event is
received, the task becomes ready and
reads the event, for example, from a
message queue. The event is then
processed from the state machine and
eventually a state change happens. The
task then waits for the next event. The

www.embedded.com | embedded systems design | NOVEMBER 2010 23

 feature
Listing 1 An RTOS task body in a state-machine-based system design.
1 void task(void){
2 while(1){
3 // blocking wait for event
4 event = wait_for_event();
5 switch(state){
6 if(event==eventA){
7 // process transition
8 ...
9 }
10 }
code in Listing 1 shows this principle.
In a non-RTOS design (fore-
ground/background system design), the
difference is that in the background a
main loop executes the different state
machines one after the other. The state
machines return immediately if an even-
tually available event was processed. One
of the advantages of this design is that
the issues of task switching and re-
source-sharing between RTOS tasks is
not relevant, as Listing 2 demonstrates.
In both designs, the individual state
machine can be coded by hand, such as
in C. But this is an error-prone task es-
pecially for hierarchical designs. In
practice, a code generator can fully
Listing 2 State machine function in a non-RTOS system design.
1 void main(void){
2
3 …
4 while(1){
5 state_machine1(eventVar1);
6 state_machine2(eventVar2);
7 …
8 }
9 }
1 void state_machine1(eventT event){
2 switch(state){
3 if(event==eventA){
4 // process transition
5 ...
6 }
7 }
24 NOVEMBER 2010 | embedded systems design | www.embedded.com
transform UML state diagrams into
source code. This saves a lot of time es-
!
In a non-RTOS design,
the difference is that in
! the background a main
loop executes the differ-
! ent state machines one
after the other.
pecially if the model is not complete
from the beginning and transitions or
entry/do/exit code are to be added later.
Additionally, a code generator can per-
form design checks on the model level
before generating the source code.
TESTING STATE-BASED DESIGNS
After the design and coding phase, the
behavior of a state machine must be
tested. It’s recommended that you go
through every state transition at least
once. Based on the state diagram, a tool
can suggest test routes through the state
chart ensuring 100% transition coverage.
Debugging an application that is
based on generated code from a state
diagram is a bit different from debug-
ging handwritten state-machine code.
Why? Because you can assume that the
generated code is correct. You don’t
have to worry about all the nitty gritty
details of the realization of a state ma-
chine, such as handling history, han-
dling hierarchical designs, placement of
entry/exit. If the machine does not do
what it should do, then most probably
the model is not correct. To track down
the problem—especially in deeply em-
bedded real-time systems—typically
means to add a tracing mechanism that
allows you to see which events do fire.
Here a code generator can support you
again by automatically generate trace
code that provides you with informa-
tion useful for debugging or testing.
The trace data can be used both
during the development process and
after the software is released either on-
line or in a post mortem. The main ad-
vantage of dynamic analysis is that it
can run in real-life production condi-
tions. In practice, the information col-
lection does disturb the system execu-
tion, but the disturbance may remain
extremely small, possibly negligible, in
many cases.
The Tracing Book on Wikipedia
provides a good overview on the differ-
ent parts needed to realize a tracing
function.2 Based on a small mobile ro-
bot, these different parts are exemplary
realized and discussed in the following
section of the article. Figure 1 shows
the hardware setup of the demo system.
 ®

m
Find it at
mathworks.com/accelerate
datasheet
video example
trial request

Run Matlab
Programs
in parallel
with
Parallel Computing Toolbox™

If you can write a FOR-loop, you can

write a MATLAB parallel program
for high-performance computing. Parallel
Computing Toolbox lets you quickly adapt
MATLAB programs to run on your multicore
computer, GPU or cluster, with features for
task-parallel and data-parallel programs.
©2010 The MathWorks, Inc.

®
 feature
Mobile robot used as demo to show the different parts needed for testing state machines.
PC side Target side

Communication link
Target

UDP
client
Target Event ids sent
com. via 868-MHz link
Wireless
USB interface
GUI + UDP server:
codegen.jar-S …
Figure 1

To log trace messages while the robot is
cruising, the connection to the moni-
toring PC was realized as wireless link.
Data providers are the basic mecha-
nisms to access the needed data, for ex-
ample by adding instructions to trace
the execution of some program section.
be written to a trace buffer or sent serial link) to a PC; this second aspect
through the network (for example, a is called data collection and transfer.
Listing 3 State machine with enabled tracing in line 6, 9, and 23.
1 switch(instanceVar->stateVarEXPLORE){
2

!
3 case AHEAD:
Pullquote — please pull a 4
quote for this puillquote. 5 if(usDist<15){
6 behaviourTraceEvent(2U);

! Pullquote — please pull a

quote for this puillquote.
7
8
9
...
}else if(msg==(BEHAVIOUR_EVENT_T)evTimeoutT0){
behaviourTraceEvent(0U);

! Pullquote — please pull a

quote for this puillquote.
10
11
12
13
}
...

else
{
14 /* Intentionally left blank */
In state-based systems, an important 15 }
information to trace are the events 16 break;
causing a state transition. A state-ma- 17
chine tool can automatically create the 18 case TURN:
needed trace code. The code in List- 19 /* action code */
ing 3 shows trace code that was auto- 20 turned=turn(90,100);
matically inserted (lines 6, 9, 23) in the 21
generated cruising algorithm’s state 22 if(turned==1){
machine. Each event is uniquely identi- 23 behaviourTraceEvent(1U);
fied with an unsigned integer so the 24 /*Transition from TURN to IDLE4 */
overhead is minimized. In other words, 25 ...
no strings needs to be copied. 26 }
The event information must then

26 NOVEMBER 2010 | embedded systems design | www.embedded.com

 ?
Who makes the fastest real-time oscilloscopes?

100 MHz - 200 MHz

100 MHz - 500 MHz

20 MHz - 40 MHz
100 MHz - 1 GHz

60 MHz - 200 MHz The fastest-growing 100 MHz - 1 GHz

oscilloscope company.*

DC - 90 GHz Sampling
100 MHz - 1 GHz

2.5 GHz - 13 GHz 600 MHz - 4 GHz

Introducing 16-32 GHz

Agilent Infiniium 90000 X-Series

Our portfolio offers families engineered to deliver the best:

• Best measurement accuracy
• Broadest measurement capability
• Best signal visibility
• More scope than you thought you could afford

Are you using the best scope?

Take the 5-minute scope challenge and find out.
www.agilent.com/find/scopecheck
*Prime Data 2009 Market Growth Analysis.
© Agilent Technologies, Inc. 2010 u.s. 1-800-829-4444 canada 1-877-894-4414
 feature

! Based on the trace data, a

data-analysis tool can
Listing 4 Trace function which sends the trace data from the mobile robot to
the monitoring PC.

!
1 const char* const behaviourTraceEvents[] = {
measure or identify inter- 2 “evTimeoutT0”,
esting properties or met- 3 “turned==1”,

!
4 “usDist<15”,
rics, such as number of 5 “usDist>30”,
processed events. 6 “evKey”
7 };
8

Once the data is available on the PC, it 9 void behaviourTraceEvent(BEHAVIOUR_EVENT_T evt){

can be either stored in a disk file (for
later analysis) or sent through a stream
(pipe, socket) to an analysis tool. Data
collection and transfer is typically a
very system-dependent process be-
cause it depends on the available hard-
ware resources (for example, memory
to store trace data) and communica-
tion links to a PC (such as RS232,
CAN, and wireless). Within the trace
function, the trace data can be
buffered for later download or directly
Online display of the robot’s internal state machine.
Figure 2
10 SerPrint(behaviourTraceEvents[evt]);
11 crlf();
12 }
sent out as shown in Listing 4. On the
PC, it’s now already possible to watch
the event flow in a terminal window.
On the PC side, it’s useful to have
a dedicated event-reception software
to decouple the data analysis and visu-
alization tool from the used communi-
cation link.
For the mobile robot, a basic event
forwarder was used that simply re-
ceives trace data from the serial port
where the wireless receiver was con-
nected to and forwards it to a UDP
port. The data-visualization software
always listens to a UDP port and is as
wanted independent from the commu-
nication link. Larger embedded sys-
tems with an own Ethernet link might
sent the UDP packets directly to the
analysis software.
Based on the trace data, a data-
analysis tool can measure or identify a
number of interesting properties or
metrics, for example the number of
processed events or the frequency a
certain event occurs with.
The final component is the data
visualization. It can be used to replay
the traced events or display the device
state graphically. Figure 2 shows the
data-visualization window of Sinela-
boreRT.3 It displays the robot’s state as
a state-machine graph generated with
the help of the DOT tool.4 This allows
to do a visualization of the state-ma-
chine independently of the used UML
modeling tool. The presently active
states are shown in red. Transitions
that can be taken are shown in blue
(others in grey). The bottom window

28 NOVEMBER 2010 | embedded systems design | www.embedded.com

 24th International Trade Fair
New Munich Trade Fair Centre
09–12 November 2010

Register online and enjoy the benefits:

www.electronica.de/en/tickets

egnahc
means exploring new paths.

Boards Software Microcontrollers Virtualisation DSPs Forum

Time for embedded. Time for the future.

The entire range of key technologies and forward-looking innovations. Visit electronica
and the embedded Forum and experience their incomparable significance to the entire electronica 2010
industry—with today’s solutions for tomorrow’s applications.
embedded
Parallel event: hybridica. Trade fair for hybrid-component production. www.hybridica.de

get the whole picture

www.electronica.de/embedded
 NOVEMBER 9-11, 2010
The Santa Clara
Convention Center
Santa Clara, CA

With over 25% of all consumer electronic 
devices in the world running on ARM processors,
the future may well be in your hands. 
Are you ready?
Immerse yourself in Best-in-Class design strategies for the leading digital architecture – ARM.

NOVEMBER 9: Chip Design Conference
Conference: Centers around designing ICs using ARM cores. Learn from the best amongst the EDA,
foundries and hardware companies supporting the ARM architecture. Topics will span the gamut from
SoC architecture analysis and SoC IP to design, verification, reliability and yield. These sessions will
strengthen your hardware and chip design expertise.

Exhibition: Showcasing carefully selected tabletop exhibits from leading solutions providers, FRE
E
designed to make it easier for you to evaluate available support tools for chip design. SavEXPO PA
ou e $ SS
if y
NOVEMBER 10-11: Software & System Design Conference
pre 7
-reg 5
teris
Conference: The focus will be on designing systems and developing software around ARM-based hardware.
Learn about the latest ARM processors, roadmap and strategies. Optimize your ARM based design; through classes
taught by industry experts across the entire development chain from SoC, embedded, physical IP and EDA solutions to
software and tools.

Exhibition: theatre sessions, and a comprehensive exhibition hall, featuring the hottest new products to support the
entire ARM ecosystem. There will be giveaways, special events, and a few surprises too!

If your responsibilities span across both areas- we offer an all access pass to attend the entire conference, the
best value.

Take advantage of the only design conference dedicated to the ARM architecture and strengthen your
core design.

REGISTER NOW for best rates www.armtechcon.com

displays the source code that was exe- Statement of Ownership, Management, and Circulation
cuted as a reaction to a state change on Required by 39 USC 3685
the target. It’s also possible to interac-
tively send events to the machine (left
Publication title: Embedded Systems Design; Publication number: 5873;
window) for example, to enter a spe- Filing date: 9/22/2010; Issue frequency: Monthly with a combined Jan/Feb and July/August
cific start state. With this final compo- issue; No. of issues published annually: 10; Annual subscription price: $55.00;
Complete mailing address of Known Office of Publication: 600 Community Drive,
nent, the tool chain for implementing
Manhasset, Nassau County, NY 11030-3875; Complete Mailing Address of Headquarters or
tracing is complete now. General Business Offices of the Publisher: 600 Community Drive, Manhasset, Nassau
County, NY 11030-3875; Full Names and Complete Mailing Addresses of Publisher, Editor,
and Managing Editor. Publisher: David Blaza, UBM Electronics Group, 600 Harrison Street,
GO WITH THE TRACING FLOW 6th Floor, San Francisco, CA 94107; Editor: none; Managing Editor: Susan Rambo, UBM
In this article, I’ve shown how useful it Electronics Group, 600 Harrison Street, 6th Floor, San Francisco, CA 94107; Owner: UBM
Media LLC (600 Community Drive, Manhasset, NY 11030-3875), an indirect, wholly owned
is to implement tracing in an embed- subsidiary of United Business Media (Ludgate House, 245 Blackfriars Road, London SE1
ded system. Tracing is useful both dur- 9UY U.K.) Known Bondholders, Mortgages, and Other Security Holders Owning or Holding
ing the development process and after 1 Percent or More of Total Amount of Bonds, Mortgages, or Other Securities: None; Issue
Date for Circulation Data Below: September 2010
the software is released either online or
for a post mortem analysis. A code
generator can automatically generate
the required trace statements, which
saves a lot of work. So the effort for
the developer can be reduced to the
job of coding the trace function. In a
state-based design, tracing of the event
flow enables embedded systems devel-
opers to follow the system internals
with minimal overhead. ■

Peter Mueller has been an embedded

systems developer for nearly 15 years,
involved in projects in the area of public
transportation, instrumentation, and
process automation. During this time, he
was involved in several initiatives to im-
prove the embedded software quality.
Peter Mueller created and sells Sinela-
boreRT, a code generator. He can be
reached at pmueller@sinelabore.com.

ENDNOTES:
1. Mueller, Peter. “State charts can provide
you with software quality insurance.” Em-
bedded.com, August 19, 2009, www.embed-
ded.com/219400531.
2. Tracing Book, Wikipedia.
http://lttng.org/tracingwiki/index.php/Trac- This Statement of Ownership will be printed in the November 2010 issue of this publication.
ingBook I certify that all information furnished on this form is true and complete. I understand that
anyone who furnishes false or misleading information on this form or who omits material or
3. Mueller, Peter. SinelaboreRT. SinelaboreRT
information requested on the form may be subject to criminal sanctions (including fines and
generates code from UML state charts. imprisonment) and/or civil sanctions (including civil penalties).
www.sinelabore.com.
4. Graphviz—Graph Visualization Software. Signature and Title of Editor, Publisher, Business
Manager, or Owner:
www.graphviz.org/
David Blaza, Publisher,
October 1, 2010.

www.embedded.com | embedded systems design | NOVEMBER 2010 31

 barr code
from page 12
Jitter is affected by relative priority.
10 ms
ISR
10 ms 10 ms
T
H
> 10 ms
T
L
Figure 4
lower the precision of the velocity of an attached rotation
shaft.
Best practice: The most important single factor in the
amount of jitter is the relative priority of the task or ISR that
implements the recurrent behavior. The higher the priority the
lower the jitter. The periodic reads of those encoder pulse
counts should thus typically be in a timer tick ISR rather than
in an RTOS task.
! For these particular bugs, the single
best way to keep them out of your
! system is to have someone perform a
thorough independent high-level review
Figure 4 shows how the interval of three different 10 ms
recurring samples might be impacted by their relative priori-
ties. At the highest priority is a timer tick ISR, which executes
precisely on the 10 ms interval. (Unless there are higher priori-
ty interrupts, of course.) Below that is a high-priority task
(TH), which may still be able to meet a recurring 10-ms start
time precisely. At the bottom, though, is a low priority task
(TL) that has its timing greatly affected by what goes on at
higher priority levels. As shown, the interval for the low priori-
ty task is 10 ms +/- approximately 5 ms.
HIRE AN EXTERMINATOR
As with any bug that’s difficult to reproduce, your focus
should be on keeping all five of these nasty bugs out of your
system before they get in. For the particular bugs in this in-
stallment, the single best way to do that is to have someone
inside or outside your company perform a thorough inde-
pendent high-level review of the firmware architecture, look-
ing especially at task and ISR interactions and relative priori-
ties. Of course, coding standards and coding reviews are also
helpful in picking up on some of these issues—as they were
especially for the top five.8 ■
32 APRIL 2009 | embedded systems design | www.embedded.com
10 ms
< 10 ms < 10 ms
ENDNOTES:
1. Unlike fragmentation (see http://embeddedgurus.com/barr-code/
2010/03/firmware-specific-bug-5-heap-fragmentation/), memory leaks
can happen even with fixed-size allocators.
2. In addition to avoiding memory leaks, the design pattern shown in
Figure 1 can be used to ensure against “out-of-memory” errors, in
which there are no buffers available in the buffer pool when the pro-
ducer task attempts an allocation. The technique is to (1) create a dedi-
cated buffer pool for that type of allocation, say a buffer pool of 17-
byte buffers; (2) use queuing theory to appropriately size the message
queue, which ensures against a full queue; and (3) size the buffer pool
so there is initially one free buffer for each consumer, each producer,
plus each slot in the message queue.
3. In theory, the task that wants the mutex could starve while a series of
higher priority tasks take turns with the mutex. However, the rate mo-
notonic analysis can be used to ensure this doesn’t happen to tasks
with deadlines that must be met.
4. An additional benefit of this architectural pattern is that it reduces the
number of programmers on the team who must remember to use and
correctly use each mutex. Other benefits are that each mutex handle
can be hidden inside the leaf node that uses it and that doing this al-
lows for easier switches between interrupt disables and mutex acquisi-
tion as appropriate to balance performance and task prioritization.
5. One of the most famous priority inversions happened on Mars in
1997. Glitches were observed in Earth-based testing that could not
be reproduced and were not attributed to priority inversion until af-
ter the problems on Mars forced investigation. For more details,
read Glenn Reave’s “What really happened on Mars?” account
(http://catless.ncl.ac.uk/Risks/19.54.html#subj6).
6. Barr, Michael and Dave Stewart. “Introduction to Rate Monotonic
Scheduling,” Beginner’s Corner, Embedded Systems Programming, Feb-
ruary 2002. Available online at www.embedded.com/showArticle.jhtml?
articleID=9900522.
7. Barr, Michael. “Three-Things-Every-Programmer-Should-Know-
About-RMA,” Barr Code, Embedded.com, available at
www.eetimes.com/discussion/other/4206206/Three-Things-Every-
Programmer-Should-Know-About-RMA.
8. Barr, Michael. “Five top causes of nasty embedded software bugs,”
Embedded Systems Design, April 2010, p.10, available online at
www.embedded.com/columns/barrcode/224200699.
Upcoming
Virtual Conferences

When: Thurs., Nov. 18, 2010, 11am – 6pm EDT

www.eetimes.com/soc

On Demand
Virtual Conferences
Embedded Linux
www.eetimes.com/linux EE Times, the leading resource for design decision makers in
the electronics industry brings to you a series of Virtual
Approaching Multicore Conferences. These fully interactive events incorporate online
www.eetimes.com/multicore learning, active movement in and out of exhibit booths and
sessions, vendor presentations and more. Because the
Advances in Power Management conference is virtual you can experience it from the comfort
www.eetimes.com/power
of your own desk. So you can get right to the industry
Digi-Key Symposium: information and solutions you seek.
Lighting and System Design
www.eetimes.com/lighting Why you should attend:
• Learn from top industry speakers
Maximizing the Flexibility of FPGAs
www.eetimes.com/FPGA • Participate in educational sessions in real time
• Easy access to EE Times library of resources
Medical Systems Design
www.eetimes.com/medical • Interact with experts and vendors at the Virtual Expo Floor
• Find design solutions for your business
Motor Control:
Intelligent Control Maximizes
Performance, Minimizes Power/Cost For sponsorship information, please contact:
www.eetimes.com/motor David Blaza, 415-947-6929 or david.blaza@ubm.com

Designing with ARM:

Engineer an Optimal ARM-based system
www.eetimes.com/arm
 break points
An accumulation of stuff
I have a very strange job, if one were
to even try and glorify my efforts
with that three letter word. My com-
mute is 10 feet across the hallway, or 30
miles to Baltimore Washington Inter-
national. I work with people I never
see. Susan Rambo, for instance, has ed-
ited this column for years yet we’ve
only been in each other’s presence four
or five times. I have never been given a
charter or objective for these articles so
have no idea if the powers that be—
whoever they are—are infuriated or
pleased with them. But frequent read-
ers realize that the subject matter is all
over the map, from opinions to book
reviews to educational pieces about
embedded systems engineering.
It’s rather unusual for me to write
about products. Who wants to be a
corporate shill parroting some press re-
lease? But the PR people don’t seem to
understand this, and they send a daily
barrage of exciting news about new
version 4.1.2.c of the latest widget
(even fewer bugs than in 4.1.2.b!!!) or
breathless releases covering Joe Crony’s
promotion to Executive Assistant Sub-
Vice President. Most of it gets
eTrashed, but occasionally something
grabs my attention and gets set aside.
Sometimes for years.
So here’s a potpourri of product
announcements, ideas, and thoughts
that have been piling up. I hope you
find some of these as interesting
as I do.
First there’s news in the bearing in-
dustry. Yep, bearings, those metallic
items that reduce rotational friction. A
company called Synchrony (www.syn-
chrony.com) has introduced bearings
that hold the rotating shaft in position
with a magnetic field, essentially elimi-
nating friction and wear. That’s not
new; what struck me is that their Fu-
sion line incorporates the required
34 MONTH 2009 | embedded systems design | www.embedded.com
! Catching up with the
incoming product
! announcements, Jack
Ganssle finds a few
!
gems (and some horror
stories) to share.
controller inside the bearing! Sensors
digitize the shaft’s position 15,000
times per second and feed that data
into an on-board DSP. The processor
drives a pulse-width modulator whose
output goes to two high-power ampli-
fiers that control the magnetic field.
These are not your typical McMas-
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
ter-Carr bearings; they’re bulky, with
the smallest being seven inches in di-
ameter and 3.8 inches thick. (See Fig-
ure 1.) Besides, one needs a bit of heft
so there’s room for the RJ-45 Ethernet
connection, which lets engineers moni-
tor the health of the bearing and un-
derstand loads imposed on it. Who
would have dreamed of an Internet-
enabled bearing?
The devices need only a 48-volt
DC supply of power. They’re promot-
ed as being green due to the frictional
power savings, but one wonders how
much that is offset by the 48-volt
supply.
The thought of putting embedded
smarts into something as boring as a
bearing is truly mind-bending.
POWER STUFF
In unrelated news, Microchip intro-
duced yet another in their dizzingly-di-
verse families of PIC microcontrollers
this year. The PIC18 “K22” series are
notable for their extremely low power
consumption. The most miserly parts
consume just 75 microamps per mega-
hertz at 1.8 volts. (Note that power
consumed in a digital circuit is propor-
tional to V2F, where V is voltage and F
frequency. So, though these parts will
run at up to 5 volts, there’s quite a hit
on power consumption.) Sleep current
is a miniscule 20 nanoamps, which is
so low it’s hard to measure.
The company claims a “typical”
application can run for two decades on
a couple of AAs. That’s pretty close to
the self discharge rate of alkalines,
which is generally quoted at around 2%
per year at room temperature.
Or, one could slap one of these con-
trollers into a system that uses energy
harvesting to suck tiny amounts of pow-
er from the environment. Unfortunately
many harvesting approaches get power
at intermittent intervals, so some sort of
storage is needed. Ultracapacitors are
popular, but they have a very high leak-
age rate. A CamelCase company with a
name that screams for an acronym, In-
finitePowerSolutions (www.infinitepow-
ersolutions.com) has a line of tiny power
sources designed just for that sort of ap-
plication. Their INFINERGY Micro
Power Module products have very low
self-discharge rates and a claimed
charge efficiency of 98%. The battery,
charger, and low dropout regulator are
all housed in a postage stamp-sized
SMT package (Figure 2 shows an exam-
ple) that can be assembled onto a PCB
via conventional pick and place equip-
ment.
The Micro Power Module won’t
boot up an Atom processor, as it’s rated
for a peak of 30 mA with a capacity of
only about one milliamp-hour. But sol-
der it on to a board with a low-power
PIC and a solar cell or piezoelectric
transducer and you’ll have a self-pow-
ered embedded system. And that’s pret-
ty cool.
LIFECYCLE STUFF
On another front, the folks at LDRA
(www.ldra.com) gave me an indepth
demo of their products (and pizza) at
the recent Embedded Systems Confer-
ence in Boston. I’ve been following
LDRA for some time, both because of
their interesting products and since they
have some really smart people. I find it
hard to describe the Tool Suite as it’s
composed of a great number of individ-
ual components that can work together
or alone (and they can be purchased in-
dividually). Their web site only hints at
the products’ capabilities. But these are
software tools that, together, manage
pretty much the entire development
lifecycle.
For instance, components can do
Synchrony’s Fusion smart bearings, with an embedded controller and
Ethernet connection.
Figure 1
both static and dynamic analysis of your maintaining our code bases, and these
code. The former includes checks sorts of tools greatly ease the process.
But in my travels I see few compa-
nies that use these sorts of tools, despite
! Solder it on to a board
with a low-power PIC and
a barrage of PR about them. Do you?
Why or why not?
VDC Research Group is running a
! a solar cell or piezoelec-
tric transducer, and you’ll
survey about lifecycle-management
tools that will shed some interesting
light on our practices in the embedded
!
space. Check it out here at
have a self-powered http://bit.ly/bnsdiR.
embedded system.
DRAM STUFF
How reliable are DRAMs? In the olden
against software standards (such as days, we assumed not-very and always
MISRA and many others) as well as the had at the very least a parity bit associ-
deeper analysis of how the program will ated with each word, if not full error-
actually work: ranges of variable values, correcting code (ECC). An utterly fasci-
detecting unreachable code, and much nating—and horrifying—study by a
more. In dynamic analysis, the tool in-
struments your code to gather run-time
One of InfinitePowerSolutions’
information. Unit testing tools will
build test harnesses with little user in- INFINERGY micro power modules.
volvement. Couple these together and
the tools identify those hard-to-find
testing gaps.
Other LDRA tools manage require-
ments, a subject that induces narcolepsy
in some developers, but which is be-
coming much more important. Chang-
ing rules at the FDA and certification
requirements for avionics mean fewer of
us can duck the thorny issues of, say, re-
quirements traceability. As this industry
matures, we will have to get more disci- Photo from the INFINERGY D-MPM 101-7A datasheet on
plined at all aspects of building and www.infinitepowersolutions.com/product/infinergy.
Figure 2
www.embedded.com | embedded systems design | NOVEMBER 2010 35
 break points
The iPad is that Internet appliance we’ve been writing about for over
10 years?
Figure 3
trio of researchers who ruined my day
suggests that DRAMs errors are “orders
of magnitude higher than previously
reported.” The paper “DRAM Errors in
the Wild: A Large-Scale Field Study”
(Bianca Schroeder, Eduardo Pinheiro,
and Wolf-Dietrich Weber, SIGMET-
RICS/Performance’09, June 15–19,
2009, Seattle, WA. ACM 978-1-60558-
511-6/09/06) is available at
www.cs.toronto.edu/~bianca/papers/sig-
metrics09.pdf and is a must-read.
Errors can be single-shot events
like a bit corrupted by a cosmic ray or
an all-out hardware failure. The au-
thors studied Google’s vast array of
servers over a couple of years and con-
clude that error rates are 25,000 to
70,000 per Mbit per billion device
hours. Over 8% of the DIMMs they
studied were effected by correctable er-
rors; a typical DIMM has about 4,000
correctable errors per year. The error
rate varies considerably by the hard-
ware platform, leading the authors to
think that some have better designs
than others. They also conclude that
soft errors—like those from cosmic
rays—are unlikely to be more common
than hard errors.
The numbers are scary and lead to
many unanswered questions, like, does
Google buy cheap chips? But my key
36 NOVEMBER 2010 | embedded systems design | www.embedded.com
Photo courtesy of Apple Inc.
! The numbers are scary
and lead to unanswered
! questions, like, does
Google buy cheap chips?
!
My takeaway: we need
mitigation strategies.
takeaway is that we need mitigation
strategies. Even if you could build a
provably correct chunk of firmware, a
watchdog timer is still needed to deal
with these sorts of problems. High-rel
systems probably need serious ECC. It’s
wise to seed code with assertions that
are active at run time and that take re-
medial action.
The study shows that the funda-
mental rule of computer program is
more important than ever: expect the
unexpected.
iSTUFF
Finally, I have to make a few com-
ments about this year’s non-embed-
ded rage product, Apple’s iPad. It’s
simply breathtaking. The display is so
crisp and clean it’s hard to imagine
how the inevitable version two will
improve on it.
The iPad is, in my view, primarily
an Internet appliance, though some
people are successfully using it as a lap-
top replacement. As such I’d be reluc-
tant to get one without the 3G option,
despite the $30/month charge from
AT&T. Between the office Internet con-
nection, the phones’ data plans, and
now that of the iPad, the monthly
charges really mount up. But we often
use ours in the car (the passenger only,
always) for navigation and for general
Internet access. It’s astonishing how of-
ten we’ll turn to it to look up some-
thing on a billboard or roadside sign. At
a museum we’ll Wikipedia some aspect
of a display to get more insight than
that provided by the little display card.
In a restaurant we’ll go to the ‘net to
augment a discussion.
Smartphones do pretty much
everything the iPad does. As an iPhone
user, I find the iPad to be a giant
iPhone without the phone (and with-
out the cameras). But it’s so much
faster for surfing, with a much better
screen, that it’s a go-to tool when it’s
around.
And that’s the rub. It satisfies an odd
niche—somewhere between a smart-
phone and a laptop. Its size is one of its
best features, but that size is too big for a
pocket. I don’t care to wander around
clutching anything, other than my wife.
On a business trip it would be nice as a
book reader, but the 3G versions are a bit
expensive for that. Marybeth packs it in
her purse most of the time, but for us
guys, unless we’re decked out with a
man-purse, that’s not an option.
A friend brought his on a vacation
to Europe and was able to support his
customers without a laptop. There are
pretty decent Office-like apps for it as
well as SSH clients. The keyboard works
extremely well, except accessing non-al-
pha keys requires an extra keystroke, as
on the iPhone. I doubt that it would
support any real development environ-
ment, though, and for real work I prefer
a big screen or three.
But it does fill a useful niche. And
did I mention the thing is just breath-
taking? ■
 R&D Prototype

PCB Assembly
$50 in 3-Days
Advanced Assembly specializes in fast assembly for R&D prototypes, NPI, and low-
volume orders. We machine-place all SMT parts and carefully follow each board through
the entire process to deliver accurately assembled boards in three days or less.

R&D Assembly Pricing Matrix/Free tooling and programming

Up to # SMT Parts 25 50 100 150 200 250 300 Over 300
1st board $50 $90 $110 $165 $215 $265 $315
2nd board $30 $60 $70 $105 $135 $175 $195 Call for
Each additional board $25 $40 $50 $75 $105 $135 $165 Pricing
Stencil $60 $60 $60 $60 $60 $60 $60

aapcb.com/esd9
1.800.838.5650

The new standard for pcb assembly