cover feature

The Official Publication of The Embedded Systems Conferences and Embedded.com
MARCH 2008
VOLUME 21, NUMBER 3
Learn
today
•
Design
tomorrow
p. 16
>> Linkage in C & C++ p.9
>> Atomic transactions p.27
>> Calculating CRC
efficiently p.33
>> 20 Years Ago: Hardware
description languages
p.41
>> Ganssle: Determining
complexity p.49
90% CUT IN EMISSIONS
AND 50% CUT IN DEVELOPMENT TIME.
THAT’S MODEL-BASED DESIGN.
To meet a tough performance
target, the engineering
team at Nissan used dynamic
system models instead of
paper specifications.
The result: 50% time savings,
the first car certified to meet
California’s Partial Zero
Emissions Vehicle standard,
and a U.S. EPA award.
To learn more, visit
mathworks.com/mbd
Accelerating the pace of engineering and science
©2005 The MathWorks, Inc.
Need to make sure they line up for
your product first?
With more than half of the product development cycle consumed by debugging, finding bugs faster
means your product will get to market first.
Green Hills Software provides premier tools that pinpoint the most elusive bugs in minutes, instead
of hours or days. With the MULTI ® development environmentʼs time-saving code analysis tools, errors
in code are automatically found, long before the debugging process begins.
MULTI and the TimeMachine™ debugger allow developers to easily find every bug so that shipping a
product with known problems becomes a thing of the past.
With Green Hills Softwareʼs sophisticated technology youʼll produce a better product and get it out
the door long before your competition.
Call 800-765-4733 or visit us on the web www.ghs.com to learn more.
Copyright © 2006 Green Hills Software, Inc. Green Hills, the Green Hills logo, MULTI and TimeMachine, are trademarks or registered trademarks of
Green Hills Software, Inc. in the U.S. and/or internationally. All other trademarks are the property of their respective owners.
RADIO + MCU + FLASH + USB
Low-Power RF System-on-Chip
The new CC1111 from Texas Instruments is the first sub-1 GHz RF SoC with an integrated full-speed USB controller,
enabling a fast and easy bridge between PCs and RF. The integration of a high-performance radio, MCU, Flash memory
and USB controller results in smaller PCB size, easier assembly and reduced overall system cost. Combined with TI’s
SimpliciTI™ network protocol, the CC1111 provides easy development and improved low-power design.
Wireless Sensor Network
High-Performance Analog >>Your Way
CC1110
CO2 Sensor
CC1110
Full-Speed
USB 2.0
Occupancy Sensor
CC1110
Light Sensor
High-Performance Analog >> Your Way, Technology for Innovators and the red/black banner are trademarks of Texas Instruments. XXXXXX © 2007 TI
SimpliciTI, High-Performance Analog >> Your Way, Technology for Innovators and the red/black banner are trademarks of Texas Instruments. 1942A0 © 2008 TI
For development kits,
samples and datasheets, visit >>
www.ti.com/cc1111
800.477.8924 ext. 4189
THE OFFICIAL PUBLICATION OF THE EMBEDDED SYSTEMS CONFERENCES AND EMBEDDED.COM
columns
programming
pointers
OO9
Linkage in C and C++
BY DAN SAKS
www.embedded.com
MARCH 2008
VOLUME 21, NUMBER 3
Cover Feature:
Designing DSP-based motor
control using fuzzy logic
BY BYRON MILLER
break points
Taming software
complexity
The increased use of variable-speed drive motors to reduce
energy consumption will require a shift from PID controllers to
systems based on fuzzy logic algorithms to simplify design, reduce
development time, and eliminate complex math formulas.
A simple equation can help
you measure the complexity
of your code.
BY JACK G. GANSSLE
BY GEORGE HARPER
Although you may not have heard of
atomic transactions, they’re likely to
change how you design and verify
embedded systems.
e
Efficient CRC calculation
with minimal memory
footprint
BY YANIV SAPIR AND YOSEF STEIN
You can implement the cyclic redundancy check function in
an embedded systems design with minimal impact on memory or performance by using linear feedback shift register
instructions more intelligently.
OO33
#include
OO4
LiMo Foundation aims to
put Linux in your handset
BY RICHARD NASS
Will a pro-Linux consortium
unwittingly present a roadblock instead smooth sailing
for mass adoption of Linux?
OO
Hardware/
software
verification enters
the atomic age
+
+
+
+
OO49
departments
OO16
27RR
Scope determines what you
can see within a translation
unit. Linkage determines what
you can see across translation
units.
parity bit
What are our readers thinking?
Go to the Embedded.com
Forum to join the discussion.
www.embedded.com/forum
advertising index
OO48
marketplace
OO51
in person
ESC Silicon Valley
San Jose Convention Center
April 14–18, 2008
www.embedded.com/esc/sv/
on-line
www.embedded.com
41RR
Programming your own
microcontroller
Web archive:
BY ERNEST L. MEYER
www.embedded.com/wriguide
When this article was written 20 years ago, the FPGA was
only five years old and not widely used yet. Here’s an early
how-to article on PLD design that stands the test of time.
www.embedded.com/archive
Article submissions:
EMBEDDED SYSTEMS DESIGN (ISSN 1558-2493 print; ISSN 1558-2507 PDF-electronic) is published monthly by CMP Media LLC., 600 Harrison Street, 5th floor, San Francisco, CA 94107, (415) 9476000. Please direct advertising and editorial inquiries to this address.
SUBSCRIPTION RATE for the United States is $55 for 12 issues. Canadian/Mexican orders must be accompanied by payment in U.S. funds with additional postage of $6 per year. All other foreign subscriptions must be prepaid in U.S. funds with additional postage of $15 per year for surface mail and $40 per year for airmail. POSTMASTER: Send all changes to EMBEDDED SYSTEMS DESIGN, P.O.
Box 3404, Northbrook, IL 60065-9468. For customer service, telephone toll-free (877) 676-9745. Please allow four to six weeks for change of address to take effect. Periodicals postage paid at San Francisco,
CA and additional mailing offices. EMBEDDED SYSTEMS DESIGN is a registered trademark owned by the parent company, CMP Media LLC. All material published in EMBEDDED SYSTEMS DESIGN
is copyright © 2005 by CMP Media LLC. All rights reserved. Reproduction of material appearing in EMBEDDED SYSTEMS DESIGN is forbidden without permission.
#include
BY Richard Nass
Editor in Chief
Richard Nass
(201) 288-1904
rnass@cmp.com
LiMo Foundation
aims to put Linux in
your handset
P
urple Labs has joined the
LiMo Foundation. Unless
you’re really in the know,
you’ll probably look at this announcement the same way I did. I
said, “Who is Purple Labs, and what
is the LiMo Foundation?” But more
importantly, “Why is this important
to me?”
Let me first start with who the
LiMo Foundation (www.limofoundation.org) is. Founded by Motorola,
NEC, NTT DoCoMo, Panasonic Mobile Communications, Orange, Samsung Electronics, and Vodafone, the
group claims to be an independent,
not-for-profit entity that strives to
increase the adoption of Linux within the mobile industry, particularly
for mobile handsets. The LiMo Foundation aims to leverage the mobile
Linux platform (hence the name,
LiMo) to create an open, transparent,
scalable ecosystem spanning application and middleware developer communities and to encourage the creation of compelling, differentiated,
and enhanced consumer experiences.
Not too long ago, the LiMo
member list grew with the addition
of Aplix, Celunite, LG Electronics,
McAfee, and Wind River as Core
members. Additional Associate members include ARM, Broadcom, Ericsson, Innopath, KTF, MontaVista Software, and NXP. The Foundation,
Richard Nass is
editor in chief of
Embedded Systems
Design. You can
reach him at
rnass@cmp.com.
which is open to device manufacturers, operators, chip-set makers, independent software vendors, integrators, and third-party developers,
expects to see the first handsets supporting the LiMo platform reach the
market in the first half of 2008.
It probably won’t come as much
of a surprise to learn that Purple Labs
(www.purplelabs.com) is a supplier of
embedded Linux solutions for mobile phones. In addition to joining
the LiMo Foundation as an Associate
member, it will support the organization’s mission to develop a worldclass Linux-based software platform
for mobile devices. The company
claims to be the first commercial Linux platform for feature phones in the
consortium. This extends the LiMo
initiative to mass-market mobile
handsets.
While I thought that Linux already had a place in this market, a
flavor of the operating system is now
endorsed by an industry consortium,
assuming that was even necessary. I’d
probably argue to the contrary. Having to go through yet another governing body, albeit a light-handed
governing body, still presents a roadblock to mass adoption.
Good technologies tend to eventually find their way into mainstream
devices, regardless of whether they’re
adopted by an industry group. I suspect the same will be true for Linux,
if it’s not already true.
Richard Nass, rnass@cmp.com
4
MARCH 2008 embedded systems design www.embedded.com
Managing Editor
Susan Rambo
srambo@cmp.com
Contributing Editors
Michael Barr
John Canosa
Jack W. Crenshaw
Jack G. Ganssle
Dan Saks
Larry Mittag
Art Director
Debee Rommel
drommel@cmp.com
European Correspondent
Colin Holland
colin.holland@btinternet.com
Embedded.com Site Editor
Bernard Cole
bccole@acm.org
Production Manager
Pete Scibilia
pscibili@cmp.com
Director of Audiences Services
Kristi Cunningham
kcunningham@cmp.com
Subscription Customer Service
P.O. Box 2165, Skokie, IL 60076
(800) 577-5356 (toll free), Fax: (847) 763-9606
embeddedsystemsdesign@halldata.com
www.embeddedsystemsdesigncustomerservice.com
Back Issues
Kelly Minihan
(800) 444-4881 (toll free),
Fax: (785) 838-7566
Article Reprints, E-prints, and Permissions
PARS International Corp.
102 West 38th Street, Sixth Floor
New York, NY 10018
(212) 221-9595, Fax: (212) 221-9195
reprints@parsintl.com
www.magreprints.com.quickquote.asp
Publisher
David Blaza
(415) 947-6929
dblaza@cmp.com
Editorial Review Board
Michael Barr
Jack W. Crenshaw
Jack G. Ganssle
Bill Gatliff
Nigel Jones
Niall Murphy
Dan Saks
Miro Samek
Corporate
David Levin
Scott Mozarsky
Tony Uphoff
Robert Faletra
Paul Miller
Philip Chapnick
Anne Marie Miller
Marvlieu Jolla Hall
Marie Myers
Alexandra Raine
Chairman
Chief Financial Officer
President, CMP Business Technology
Group
President, CMP Channel
President, CMP Electronics Group
President, CMP Game, Dobb’s, ICMI
Group
Corporate Senior Vice President, Sales
Senior Vice President, Human
Resources
Senior Vice President, Manufacturing
Senior Vice President,
Communications
FAST-FORWARD THE LEARNING CURVE.
Maximize your team’s existing expertise. Familiar yet powerful tools—like
Microsoft® Visual Studio® and the .NET programming model—allow your team to
focus project hours on building the next generation of smart, connected devices.
Plus, componentized and fully configured platforms in Windows ® Embedded can
help save more unnecessary effort—so more time can be spent differentiating your
final product, or simply bringing it to market faster. Learn more about how to
fast-forward device development at: windowsembedded.com/fastforward
COVERITY FINDS THE DEADLY
DEFECTS THAT OTHERWISE
GO UNDETECTED.
Your source code is one of your organization’s most valuable assets. How can you be sure there are no
hidden bugs? Coverity offers advanced source code analysis products for the detection of hazardous defects
and security vulnerabilities, which help remove the obstacles to writing and deploying complex software.
With Coverity, catastrophic errors are identified immediately as you write code, assuring the highest possible
code quality—no matter how complex your code base. FREE TRIAL: Let us show you what evil lurks in your
code. Go to www4.coverity.com to request a free trial that will scan your code and identify defects hidden in it.
© 2007 Coverity, Inc. All rights reserved.
Your code is either coverity clean—or it’s not.
Reticulitermes Hesperus, or
Subterranean Termite—unchecked,
property damage estimated
at $3 billion per year.
Electron Micrograph, 140X
Rethink performance.
Embedded performance per watt just got a big boost. This is powerful stuff.
You need designs to do more, but can’t increase power. No problem. Thanks to breakthroughs in 45nm,
multi-core architectures, and a host of other exclusive innovations, Intel’s latest quad-core platform
produces up to 67% more compute performance per watt.* Go to town. intel.com/go/rethink
*Compared to previous generation Quad-Core Intel® Xeon® platform. Actual performance may vary. Comparison details at intel.com/go/rethink
Intel and the Intel logo are trademarks of Intel Corporation in the U.S. and other countries. © 2008 Intel Corporation. All rights reserved.
The Newest
Semiconductors
The ONLY New Catalog Every 90 Days
Experience Mouser’s time-to-market
advantage with no minimums and same-day
shipping of the newest products from more
than 335 leading suppliers.
The Newest Products
For Your Newest Designs
www.mouser.com
Over 925,000 Products Online
(800) 346-6873
programming pointers
BY Dan Saks
Linkage in C and C++
A
In my earlier article on the scope
name declared in C or C++
rules,1 I explained the distinction
may have attributes such as
type, scope, storage durabetween declarations and definition, and linkage. Not every name
tions, but omitted some details.
has all of these attributes. For examThose details are pertinent to the
ple, a function name has a type, a
concept of linkage, so let’s take a
scope, and a linkage, but no storage
look at them first.
duration. A statement label name
has only a scope.
DECLARATIONS AND
An object’s type determines the
DEFINITIONS
object’s size and memory address
A declaration associates attributes
alignment, the values the object can
with names. A declaration either inhave, and the operations that can be
troduces a name into the current
performed on that object. A functranslation unit or redeclares a name
tion’s type specifies the function’s
introduced by a declaration that apparameter list and return type.
peared earlier in the same translaA name’s scope is that portion of
tion unit. A declaration for a name
a translation unit in which the
might also be a definition. Informalname is visible.1 (A translation unit
ly, a definition is a declaration that
not only says “here’s a name,” but
is the source code produced by the
Scope determines what
also “here’s all the information the
preprocessor from a source file and
you can see within a trans- compiler needs to create the code
all its included headers.) C supfor that name”.
ports four different kinds of scope:
lation unit. Linkage deterC++ lets you declare all sorts of
file scope, block scope, function
mines what you can see
things that aren’t valid in C, such as
prototype scope, and function
across translation units.
classes, namespaces, and linkage
scope. C++ generalizes file scope
specifications. Not surprisingly, these
into namespace scope, and adds
features make the distinction between definitions and other
class scope.
declarations, as well as the linkage rules, more complicated
An object’s storage duration determines the lifetime of
the storage for that object.2 That is, it determines how and in C++ than in C. However, we don’t really need to consider all those features to explain linkage—using just functions
when during program execution the storage for that oband objects should provide adequate illustration.
ject comes and goes. Each object in C and C++ has one of
For function declarations that are valid in both C and
the following three storage durations: static, automatic,
C++, the rule for deciding when a function declaration is
and dynamic. Only objects have storage duration. Enualso a definition is the same for both languages, namely,
meration constants, functions, labels, and types don’t.
that a function declaration is also a function definition if
Which brings us to linkage. A name’s linkage affects
whether two or more declarations for that name are valid, it includes a brace-enclosed body, as in:
and if so, whether they refer to the same entity (such as a
function or an object). Understanding linkage clears up a
int abs(int v)
number of misconceptions about the behavior of C and
{
C++ programs.
return v < 0 ? -v : v;
};
Dan Saks is president of Saks & Associates,
a C/C++ training and consulting company. For
more information about Dan Saks, visit his
website at www.dansaks.com. Dan also welcomes your feedback: e-mail him at
dsaks@wittenberg.edu.
A function heading without a body, as in:
int abs(int v);
is just a declaration.
www.embedded.com | embedded systems design | MARCH 2008
9
programming pointers
For object declarations that are valid in both C and
C++, the rule for deciding when an object declaration is
also a definition is—surprisingly—simpler in C++ than
in C. In C++, an object declaration is also a definition unless it contains an extern specifier and no initializer.
For example, all of the following object declarations
are also definitions in C++:
int i;
static int j;
extern int k = 0;
// definition
// definition
// definition
They are definitions whether they appear at file scope,
namespace scope, or block scope.
The following object declaration is not a definition:
extern int m;
// non-defining declaration
Again, the rule I just cited is how C++ distinguishes object definitions from other object declarations. The cor-
// foo.c
#include “foo.h”
int foo(int n)
{
...
}
to ensure that the function defined in the source is working with the same declaration(s) as in the header. After
preprocessing, the translation unit contains:
int foo(int n);
int foo(int n)
{
...
}
From the compiler’s viewpoint, these are two
declarations for the same function in the same
scope. They refer to the same function
because they have linkage.
responding rule in C is complicated by the added presence of these things called tentative definitions. A
tentative definition is an object declaration that might
also be a definition, or it might not, depending on the
presence of other definitions. In truth, the previous declarations for i and j are tentative definitions in C. C++
doesn’t recognize tentative definitions, so some combinations of object declarations that are valid in C aren’t
valid in C++.
The C++ rule for distinguishing object definitions
from other object declarations works equally well in C as
in C++. If you follow that rule in C, you won’t go wrong.
THE CONCEPT OF LINKAGE
In some cases, C and C++ let you declare the same entity
more than once, in different translation units, different
scopes of the same translation unit, or even in the same
scope. For example, the common C technique for packaging a library function is to declare the function in a header:
// foo.h
// from the header
which declares the function twice. The second
declaration is also the definition. From the
compiler’s viewpoint, these are two declarations for the same function in the same scope.
They refer to the same function because they
have linkage.
C and C++ provide for three levels of
linkage:
name with no linkage denotes an entity that can’t be
• Areferenced
via names from anywhere else.
with internal linkage denotes an entity that can
• Abename
referenced via names declared in the same scope or
in other scopes of the same translation unit.
with external linkage denotes an entity that can
• Abename
referenced via names declared in the same scope or in
other scopes of the same translation unit (just as with internal linkage), or additionally in other translation units.
Both function and object names can have either internal or external linkage. Object names can also have no linkage. Beyond that, all other names in C have no linkage. In
contrast, other names in C++ can have external linkage, including names for classes, enumeration types and constants, namespaces, references, and templates. References
and function templates can also have internal linkage.
LINKAGE FOR FUNCTIONS
A function declared without a storage class specifier normally has external linkage by default. Placing the keyword
extern in a function declaration such as:
int foo(int n);
extern int foo(int n);
and define the function in a corresponding source file.
That source file should include the header, as in:
10
MARCH 2008 | embedded systems design | www.embedded.com
has no effect. With or without the extern specifier, you
N
IO
RS L E
B
A
NE
W
AV V
AI E
L
NI LabVIEW.
Limited Only by Your Imagination.
Communicate via
multiple protocols
including Bluetooth
Build and program robots
with LEGO® MINDSTORMS®
NXT using software powered
by NI LabVIEW
Graphically program
concurrent, real-time
applications
Develop your human machine
interface (HMI) display
Target 32-bit
microprocessors
and FPGAs
Independently control
multiple servo motors
Real-Time and Embedded
PRODUCT PLATFORM
LabVIEW Real-Time Module
LabVIEW FPGA Module
LabVIEW Microprocessor SDK
NI CompactRIO Embedded
Hardware Platform
Signal Processing
High-Performance Test
Industrial Control
When the LEGO Group needed parallel programming
and motor control tools intuitive enough for children,
it selected graphical software powered by NI LabVIEW.
With LabVIEW graphical system design, domain experts
can quickly develop complex, embedded real-time
systems with FPGAs, DSPs, and microprocessors.
>> Expand your imagination with technical resources at ni.com/imagine
© 2007 National Instruments Corporation. 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. LEGO and MINDSTORMS are trademarks of the LEGO Group used here with special permission. 2007-9039-821-101D
866 337 5041
programming pointers
can place this function declaration in a header, include
that header in several source files, compile each file, and
link the compiled modules together. Subsequently, all calls
to that foo from any of those source files will call the
same function.
A function declared at file or namespace scope with
the keyword static has internal linkage. That is, when
you declare:
static int foo(int n);
Written either way, these declarations are valid in
both C and C++, and foo has internal linkage. However,
just because you can do this doesn’t mean you should.
Writing function declarations that differ only in their
storage class specifiers is rarely, if ever, necessary, and can
be confusing.
If a single identifier has both internal and external
linkage in the same translation unit, the resulting program has undefined behavior. That is, it’s an error, but
you might not get an error message from the compiler
all calls to foo in that translation unit will be to a
Written either way, these declarations are
function foo defined in that same translation unit. If
valid in both C and C++ . . . however, just
the translation unit contains calls to foo, yet function foo isn’t defined in that translation unit, the
because you can do this doesn’t mean
program won’t compile or link, even if there’s a defiyou should.
nition for function foo in another translation unit.
Table 1 illustrates how C and C++ determine
or linker. For example, reversing the order of the exthe linkage for a function from the storage class specifier
and the scope of the function’s declaration. For example,
tern and static declarations from the previous examthe row labeled extern shows that a function declared
ple, as in:
extern doesn’t always have external linkage. The row labeled none shows that a function declared without a storextern int foo(int n);
// external linkage
age class specifier at file, namespace, or block scope be...
haves as if it were declared with the keyword extern.
For example, a single translation unit can contain the
static int foo(int n);
// undefined behavior
following declarations:
yields undefined behavior. All the more reason not to
static int foo(int n);
// internal linkage write things like this.
...
extern int foo(int n);
// still internal
The extern declaration could be in an inner scope, as in:
static int foo(int n);
...
// internal linkage
int bar(int m)
{
extern int foo(int n); // still internal
...
}
Linkage for functions in C and C++.
storage class
at file scope (C) or
specifier
namespace scope (C++)
auto
extern
register
static
none
invalid
normally external linkage,
but possibly internal linkage*
invalid
internal linkage
same as extern
LINKAGE FOR OBJECTS
Table 2 illustrates how C and C++ determine linkage and
storage duration for an object from the storage class
specifier and the scope of the object’s declaration. It
shows, for example, that a non-const object declared at
file or namespace scope without a storage class specifier,
such as:
int n;
has external linkage and static storage duration. This declaration is also a definition in C++ but only a tentative
definition in C.
at block scope
invalid
normally external linkage,
but possibly internal linkage*
invalid
invalid
same as extern
*The name has internal linkage if previously declared with internal linkage in a visible declaration.
Table 1
12
MARCH 2008 | embedded systems design | www.embedded.com
at class scope
(only in C++ )
invalid
invalid
invalid
internal linkage
external linkage
It’s the best connected
15-year-old in the
MCU industry.
ColdFire® Architecture. The perfect 32-bit compilation.
The ColdFire Architecture has a 15-year heritage steeped in innovation. With
more than 100 individual devices, ColdFire has one of the broadest 32-bit
portfolios in the industry. Whether it’s USB, Ethernet, CAN or ZigBee®, ColdFire
connects and controls millions of networked products in homes, offices and
factories around the world. ColdFire also enables your design to keep pace
with today’s eco-trends thanks to its industry-leading, ultra-low-power 32-bit
MCU. And to make its own ecosystem even stronger and more vibrant, we are
now openly licensing ColdFire V1. Find out what ColdFire can do for you.
Meet ColdFire at freescale.com/coldfire101
and save 50% on the QE128 Development Kit.*
* While supplies last.
Freescale™ and the Freescale logo are trademarks and ColdFire is a registered trademark of Freescale Semiconductor, Inc. All other product or service names are the property of their respective owners. ©Freescale Semiconductor, Inc. 2008.
programming pointers
Linkage and storage duration for objects in C and C++.
storage class
at file scope (C) or
specifier
namespace scope (C++)
auto
extern
register
static
none
at class scope
(only in C++ )
at block scope
invalid
normally external linkage,
but possibly internal linkage;*
static storage
invalid
internal linkage;
static storage
normally external linkage, except
that const objects in C++ have
internal linkage; static storage
no linkage; automatic storage
normally external linkage,
but possibly internal linkage;*
static storage
same as auto
no linkage;
static storage
same as auto
invalid
invalid
invalid
external linkage;
static storage
no linkage; same
storage duration
as enclosing object
*The name has internal linkage if previously declared with internal linkage in a visible declaration.
Table 2
With many C compilers, you can place this declaration
in a header, include that header in several source files, compile each source file, and link them together. The linker will
treat one of those tentative definitions as a definition and
all the other tentative definitions as declarations referring
to that definition. This behavior is a common extension to
the C standard, but may not be portable to all C environments, and doesn’t work in C++. Using C++, you’ll get a
link error complaining about a multiply-defined symbol.
If you want the code to compile and link in C++ as well
as C, you must declare n with the extern specifier, as in:
extern int n;
As before, n has external linkage, but now the declaration is not a definition—not even a tentative one in C.
You can place this declaration in a header, include that
header in several source files, compile each source file, and
link them together. But you’ll still get a link error, unless
there’s exactly one definition for all those declarations to
reference. Just one of the source files must provide a definition for n. Any one of the following definitions will do:
14
// still internal linkage
int foo(int v)
{
static int n;
...
}
// still no linkage
defines two distinct objects named n, both with static
storage duration. The n at block scope still has no
linkage.
There’s more to say about linkage, but this is enough
for now. ■
1.
An object declared at block scope without a storage
class specifier has automatic storage duration and no linkage. For example, in:
int foo(int v)
{
int n;
...
}
static int n;
ENDNOTES:
int n;
int n = 0;
extern int n = 0;
static int n;
both parameter v and local object n have no linkage.
You can’t write a declaration for an integer v elsewhere
and get it to link to foo’s parameter v. Likewise for n.
Thus, the two objects named n in this example are distinct objects.
If you add the static storage class specifier to the
declaration of n at block scope, you change its storage duration but not its linkage. For example:
// internal linkage
2.
Saks, Dan, “Scope regions in C and C++,” Embedded Systems
Design, November, 2007, p. 15. Available online at
www.embedded.com/columns/programmingpointers/
202600398.
Saks, Dan, “Storage class specifiers and storage duration,”
Embedded Systems Design, January, 2008, p. 9. Available online
at www.embedded.com/columns/programmingpointers/
205203843.
ACKNOWLEDGMENTS:
// no linkage
MARCH 2008 | embedded systems design | www.embedded.com
My thanks to Steve Adamczyk of the Edison Design Group
(www.edg.com), Tom Plum of Plum Hall (www.plumhall.com), and
Joel Saks (www.joelsaks.com) for their valuable assistance with this
article.
SMIlE, MaRS!
ThreadX RTOS manages camera software
critical to NaSa mission
®
“We found ThreadX to be a proven solution based on its demonstrated success for the
Deep Impact mission, so using it for the HiRISE instrument aboard the MRO was a logical
decision. ThreadX delivered a first-rate performance for us and helped the
MRO mission return extraordinary high-resolution images from Mars.”
– Steve Tarr, HiRISE Software Lead, Ball Aerospace & Technologies Corp.
Images courtesy NASA: http://mars.jpl.nasa.gov/mro
MRO spacecraft depicted in Mars orbit: NASA
The Mission
Opportunity Rover
When they wrote the embedded software that controls the cameras aboard the Mars
Reconnaissance Orbiter (MRO), a team of Ball Aerospace and Technology Corp.
engineers led by Steve Tarr knew they only had
one chance to get it right. If there was a seriT H R E A D
ous flaw anywhere in the software, the $720
million spacecraft might have no more value
than a digital camera dropped in a bathtub.
Tarr and his team wrote 20,000 lines of code and used Express Logic's ThreadX RTOS.
The software has worked flawlessly, resulting in history-making photographs such as
the one to the left that shows the Opportunity rover traversing the surface of Mars.
The Technology
With its intuitive API, rock-solid reliability, small memory footprint, and high-performance, ThreadX delivered the goods for NASA's MRO. ThreadX is in over 450 million
electronic devices from NASA's MRO to HP's printers and digital cameras. Which RTOS
will you choose for YOUR next project?
Order today on Amazon
Real-Time Embedded
Multithreading
Using ThreadX and ARM
by Edward L. Lamie
Small Memory Footprint • Fast Context Switch • Fast Interrupt Response
Preemption-Threshold™ Technology • Picokernel™ Design • Event Chaining™
Broad Tools Support • Supports All Leading 32/64-bit Processors • Easy to Use
Full Source Code • Royalty-Free
For a free evaluation copy, visit
www.rtos.com • 1-888-THREaDX
Copyright © 2007, Express Logic, Inc.
ThreadX is a registered trademark of Express Logic, Inc. All other trademarks are the property of their respective owners.
cover feature
Designing
DSP-based
BY BYRON MILLER
V
ariable-speed drive (VSD) motors provide hope for
greatly reducing energy consumption and reliance
on foreign fuels. In one approach, digital signal
processors (DSPs) are being used to create a new
generation of VSD-based controllers for motors
such as brushless direct current (BLDC) motors.
However, these motors present challenges. Controlling motor
speed on a BLDC motor is complicated when using traditional proportional, integral, and differential (PID) controllers because they
rely on a complex mathematical model and are computationally intensive. An alternative approach is to use fuzzy logic (FL) algorithms
to eliminate the need for complex math formulas and provide an
easy-to-understand solution. FL motor control also has a shorter development cycle compared to PID controllers, and thus a faster
time-to-market. This article discusses the process of using FL algorithms to control BLDC motors using a Texas Instruments c28xx
fixed-point family of DSPs.
BLDC CONTROL MODEL DEVELOPMENT
Before constructing the FL engine, we must first develop a model to
base the design on. FL controllers use heuristic knowledge and express the design using a linguistic description of the model. Rather
than develop a model from scratch, we’ll use the PID controller
model as a starting point. Once developed and implemented, the FL
controller is improved by adjusting its parameters.
In general, there are three design steps for developing a FL
BLDC controller:
16
MARCH 2008 | embedded systems design | www.embedded.com
The increased use of variable-speed drive motors to reduce energy
consumption will require a shift from PID controllers to systems based
on fuzzy logic algorithms to simplify design, reduce development time,
and eliminate complex math formulas.
motor
control
using
fuzzy logic
cover feature
The BLDC controller block diagram.
termine system behavior, rather than
complex math equations. For example,
IF the error (E) is equal to NM and
+
Hysteresis
Ιρ
ΔΙ
Voltage
current
3-Phase
I dt
change in error (CE) is equal to PS,
inverter
–
controller
Position
then the change in the armature voltcy
decoder
age (CV) is equal to NS. The number
Speed
controller
of rules used is based on the experience
of the designer and the knowledge of
Encoder
cε
ε
the system. Thus, for our system the
d/dt
number of rules used is 25, which is
+ –
ω
d/dt
based on our basic PID controller
ωρ
model using the PID’s control surface.
Figure 1
In order to energize the armature,
the CV fuzzy output must be converted
back to a crisp output. This process is
natively, CE is negative iff the current
called defuzzification. A popular
1. Define inputs, outputs, and the
speed is greater than the set speed.
method of defuzzification called the
controller’s range of operation.
center of gravity method is used; I’ll
2. Define fuzzy membership set func- When close to the set speed CE alternates between positive and negative
discuss it in greater detail later.
tions and rules.
values. CV is the energizing voltage apThe last step of design is to adjust
3. Tune the engine.
plied to the armature. This voltage is
the membership functions and rules.
expressed in implementation as a pulse This stage is also referred to as tuning.
Figure 1 shows the block diagram of
Tuning is used to imthe BLDC controller model.
prove the performance
The first step is to define
Instead of math formulas, a fuzzy-logic
of the FL controller.
the relevant inputs and outOnce designed, the
puts of the model. The incontroller uses fuzzy rules to make a
controller is ready to
puts are the error (E), which
decision and generate an output;
be implemented.
is the current error between
how cool is that?
The FL controller
the set speed (SS) and the
implementation
is
current speed (CS). The othwidth
modulation
(PWM)
duty
cycle.
made
up
of
three
modules.
They
are
er input is the change in error (CE),
The next step is to define the fuzzy
fuzzification, rule-base, and defuzzifiwhich is the difference between the
cation. The following sections discuss
current error, and the previously calcu- membership set functions, variables
and rules. In order to work, non-fuzzy
the modules as related to the FL-BLDC
lated error (PE). The output is the
(crisp) inputs and outputs must be
implementation.
change in armature voltage (CV),
converted into fuzzy ones. Conversion
which is the difference between the
is performed by using linguistic variFUZZIFICATION
current armature voltage (CAV) and
ables to represent input and output
Fuzzificaton is the process of convertthe stored value of the previous armaranges. These are also referred to as
ing crisp value data into fuzzy data.
ture voltage (PAV). The resulting
fuzzy variables. Fuzzy variables are used The resulting fuzzy data conversion is
model equations are as follows:
to partition a region of values for
based on the degree of fuzzy set memmembership functions. For example,
bership of input variables. For this apE = SS – CS
five variables are used to map the inplication, motor control input variCE = E – PE
puts and output. They are negative
ables are rotational error (Error) and
CV = CAV – PAV
medium (NM), negative small (NS),
change in rotational error (Cerror),
zero (Z), positive small (PS), and posiwhich are taken from the PID conMotor speed units are in revolutive medium (PM). The model’s inputs troller model discussed earlier. Error is
tions per minute (RPM), and E deterand outputs are membership set functhe absolute error from one sample
mines how close we are to the target
tions that are described over the range
time to the next. Similarly, Cerror is
speed. So for E > 0 motor speed is below set speed. Alternatively, E < 0 indiof operation by the five fuzzy variables. the change in Error from one sample
time to the next. The formulas for
cates that the motor is spinning faster
Instead of math formulas, an FL
each
are:
than the set speed. CE determines concontroller uses fuzzy rules to make a
troller direction to adjust. CE is posidecision and generate an output; how
Error = SetSpeed – CurrentSpeed
tive if and only if (iff) the current
cool is that? FL rules are in the form of
Cerror = Error – PreviousError
speed is less than the set speed. AlterIF-THEN statements. Fuzzy rules deBLDC
motor
18
MARCH 2008 | embedded systems design | www.embedded.com
The Microchip name and logo, the Microchip logo and dsPIC are registered trademarks of Microchip Technology Incorporated in the USA and in other countries. All other trademarks mentioned herein are property of their respective companies.
©2008, Microchip Technology Inc. All rights reserved.
More Efficient
3-Phase Motor Control
Explore the New Motor Control Solutions from Microchip
Are you considering moving to brushless motors, eliminating costly sensors or adding PFC? Let Microchip show
you how to improve your efficiency, lower noise, reduce your form factor and explore cost reduction options. Visit
www.microchip.com/DSCMOTOR and discover Microchip’s comprehensive motor control solutions, which feature 16-bit
digital signal controllers, free software, development tool discounts, technical training and more!
Looking for?
Energy Savings
Noise Reduction
Cost Reduction
Better Torque Control
Improve Reliability
to...
Microchip Has the Solution!
Add Power Factor Correction
PWM with 2 Time Bases
Incorporate Field-Oriented Control
Free Software
Incorporate Sinusoidal Control
Free Software
Remove Expensive Sensors
Free Software, 4 S&H ADC
Integrate PFC and Motor Controller
PWM with 2 Time Bases
Integrate Controller on Motor
6x6 mm Small Packages
Easily Migrate to Other DSCs in Portfolio
Optimized Feature Set
Remove Crystal
1% Internal Oscillator
Incorporate Field Oriented Control
Free Software
Better Loop Response
Multiple S&H ADC
Migrate from Brushed to Brushless Motors
Free Software
Noise Profile Diagnostics
DSP Resource On-chip
Purchase Microchip’s motor control
development solutions at...
microchip
DIRECT
www.microchipdirect.com
www.microchip.com/DSCMOTOR
Microcontrollers • Digital Signal Controllers • Analog • Serial EEPROMs
cover feature
The membership function for the input variables Error, and Cerror.
y
0x1AAA
X1[ ] 0x0 0x0 0x196A 0x13F 0x0
X2[ ] 0x0 0x0 0x19D6 0x6A 0x0
PM
PS
ZE
NS
NM
Fuzzified data resulting from Error
equal to 0x30 (x-axis) and Cerror
equal to 0x10 (x-axis).
Array NM NS
ZE
PS PM
Table 1
-0x5000
-0x3554
0x1AAA
0
-0x1AAA
0x5000
0x3554
Figure 2
The fuzzified membership function for the input variable Error: X1[].
y
0x196A
0x1AAA
NM
NS
ZE
PS
PM
0x13F
-0x5000
-0x3554
-0x1AAA
0
0x1AAA
0x3554
0x5000
Figure 3
The fuzzified membership function for the input variable Cerror: X2[].
y
0x19D6
0x1AAA
NM
NS
ZE
PS
PM
0x6A
-0x5000
-0x3554
-0x1AAA
0
0x1AAA
0x3554
0x5000
Figure 4
The inference rule table.
Error: X1[ ]
NM
NS
ZE
PS
PM
NM
Cerror:X2[]
NS
ZE
PS
PM
NM
NM
NM
NS
ZE
NM
NM
NS
ZE
PS
NS
ZE
PS
PM
PM
ZE
PS
PM
PM
PM
NM
NS
ZE
PS
PM
Table 2
20
As mentioned during the design
section, five membership sets are defined for variables Error and Cerror:
3. ZE: Zero
4. PS: Positive Small
5. PM: Positive Medium
1. NM: Negative Medium
2. NS: Negative Small
Figure 2 shows the membership
sets for variables Error and Cerror. The
MARCH 2008 | embedded systems design | www.embedded.com
membership sets are triangular-shaped
and overlap to provide good response.
Each set has a maximum value of
0x1AAA. This differs from typical fuzzy
logic literature, which sets the maximum range equal to one. Using a maximum value of 0x1AAA for the range reduces computational complexity.
Specifically, the multiplying operation
is reduced to either a series of additions
or subtractions rather than converting
to and from a floating point number.
The resulting fuzzification of the
input variables produces a vector with
five components that correspond to the
fuzzy membership sets NM, NS, ZE, PS,
PM. The value (y-axis) of each component represents the degree of membership for that crisp input value. The vectors containing the fuzzified values of
Error and Cerror are denoted by arrays
X1[] and X2[] respectively. For example, with Error equal to 0x30 (x-axis),
and Cerror equal to 0x10 (x-axis), the
resulting fuzzified data are shown in
Table 1.
Figures 3 and 4 graphically show
the resulting fuzzified values for Error
and Cerror.
FUZZY INFERENCE RULES
Fuzzy inference rules operate on the
fuzzified data to determine the system’s
behavior. Specifically, the fuzzified data
is applied against the rule table. Linguistically, this is where the input data
Error and Cerror are compared with
the rule table. The rule table contains
membership set components NM, NS,
ZE, PS, and PM, depending on the control surface. The output is “inferred”
from the valid or “fired” rules. The inference process is described by pseudo
code in Listing 1.
Table 2 shows the initial rule base
for the motor control surface.
Microcontroller
Development
Tools
ARM Microcontroller Solution
ARM Powered Microcontrollers – available from many silicon
vendors; offer high computing performance along with rich peripherals.
Turn ARM Microcontrollers into your solution for cost-sensitive
powerful applications – with Keil Development Tools.
®
Cx51
Keil Cx51 is the de-facto industry standard for all
classic and extended 8051 device variants.
C51 Version 8.5 includes the latest devices such as
XC800,ADE7169, and C8051F4xx - F6xx.
More information: www.keil.com/c51
C/C++ Development Kit
JTAG Debugger
The RealView Microcontroller Development
Kit (MDK) is the complete software development
environment for ARM7/9 and Cortex-M1/M3.
ULINK2® connects to
the JTAG or 2-wire debug
interface and supports
on-the-fly debugging and
Flash programming.
MDK is easy to learn and use, yet powerful
enough for the most demanding embedded ARM
®
application.The integrated Device Database
simplifies tool configuration and includes more
than 250 ARM Powered Microcontroller
variants for your embedded project.
C166
Keil C166 is the complete software development
environment for Infineon C166, XC166, XC2000
and ST Microelectronics ST10 with debug and
programming support via ULINK2.
More information: www.keil.com/c166
®
RealView Microcontroller
Development Kit
RTX RTOS Kernel Library
µVision
Device Database & IDE
µVision
Debugger & Analysis Tools
Examples and Templates
RealView C/C++ Compiler
Complete Device Simulation
A/D Converter
I/O Ports
Debug
Run-Control
Timer/Counter
Interrupt System
Debug
Channel
PWM
UART
Flash ROM
CPU
RAM
ARM
RealView MDK combines the best-in-class
ARM C/C++ Compiler, the genuine Keil µVision
IDE/Debugger/Simulator, and the royalty-free
RTX RTOS Kernel.
More information: www.keil.com/arm
Real-Time
Clock
I2C/SPI
DMA
®
Ethernet
RealView
Real-Time Library
SD/MMC
Interface
USB
CAN
TCPnet Networking Suite
Flash File System
USB Device Interface
CAN Interface
Examples and Templates
RTX RTOS Source Code
RTOS and Middleware
The RealView Real-Time Library (RL-ARM)
solves the real-time and communication
challenges of your ARM project and expands
MDK with essential components for
sophisticated communication and interface
peripherals.
Keil MCB evaluation boards come with code
size limited tools and extensive example
projects that help you get up and running
quickly with your own embedded application.
More information: www.keil.com/boards
Learn more about RealView MDK, RL-ARM, and ULINK2. Download a free
evaluation version from www.keil.com/demo or call 1-800-348-8051.
www.keil.com
cover feature
Listing 1 Inference rules pseudo code.
MinValue = MaxValue = 0
Y[0..N] = 0;
For (I = 0 to N)
{
for (j = 0 to M)
{
MinValue = Min{X1[I], X2[M]};
// compare each X1 element to X2 element and store
// smaller value
// store max value found among X2 members
If (Max{X1[I], X2[M]} > MaxValue) //
{
MaxValue = Max{X1[I], X2[M]};
}
// add max value to output vector function defined by
// membership rules
MaxValue += output_vector_member(x);
}
}
FUZZY LOGIC DEFINITIONS
Centroid calculation function: used for producing an exact output
value by calculating the center of gravity of the union of areas bound
by membership functions and the input variable axes.
Defuzzification: a general method for determining the best exact or
“crisp” output of a given fuzzy set, defuzzification uses the centroid
calculation function or a similar function to generate a crisp output.
Fuzzification: a method for converting a “crisp” input value to a
fuzzy membership function. The resulting fuzzy value is a member of a
multivalued set.
Fuzzy control system: a control system based on fuzzy IF-THEN
rules that use fuzzy sets for input and output.
Fuzzy inference system: a collection of fuzzy IF-THEN rules.
Fuzzy logic: logic that uses linguistic variables to describe a system.
Examples include: “fast,” “slow,” and “medium.”
Fuzzy set: any set that allows its members to have different “grades”
of membership. Each member may be expressed by a continuous number between zero and one: [0,1]. This contrasts to Boolean logic that
limits set members to a value of either zero or one.
Fuzzy system: a system whose variables range over states that are
fuzzy sets.
Membership function: the mapping of a fuzzy set that associates
each set member with its grade of membership.
22
MARCH 2008 | embedded systems design | www.embedded.com
Defuzzified output vector table.
Array NM NS
ZE
PS PM
Y[ ]
0x0 0x13F 0x196A 0x0 0x0
Table 3
In the earlier example, output vector Y[] is shown in Table 3.
DEFUZZIFICATION
Defuzzification is the process of converting fuzzy data back into crisp value
data. For the purpose of this application the defuzzified value determines
the duty cycle of the PWM signal used
to drive the motor. The duty cycle is
determined by using the modified centroid calculation function. The defuzzification approach used here takes
the centroid function and multiplies it
by a coefficient. The modified calculation is also known as the centroid point
calculation function. This approach
provides additional precision over the
centroid calculation function.
The centroid point calculation is
obtained by the center point of the
function that is the result of the multiplication of the output membership
function by the output vector Y[]. The
formula for the centroid point calculation is:
Defuzzified Value =
Σ_Y[i] X multCoeff[I] / Σ Y[i]
where Y[i] are the i-th elements of the
output vector, and multCoeff[i] are the
multiplying coefficients of the output
membership function. The index i has
a range of i = 1 to i = 5.
Figure 5 shows the graphical representation of the output membership
function used by this application with
the coefficients of [-0x10, -0x8, 0x0,
0x8, 0x10].
Using the example output vector
Y[] = [0x0, 0x13F, 0x196A, 0x0, 0x0],
the following defuzzification output
value is calculated:
Defuz = 0 X (-16) + 319 X (-8)
+ 6506 X (0) + 0 X (8) + 0 X
(16) / 0 + 319 + 6506 + 0 + 0
= -2552 / 6825 => -0.37391
cover feature
ECAP1-3 capture signals from the halleffect sensors.
The motor is driven with PWM
signals generated by the DSP and
translated to a 3-phase output. The six
PWM signals are used to source the 3phase power inverter. The power inverter converts the six signals to a 3phase signal that directly powers the
motor. The 3-phase power inverter
function is handled by an auxiliary
Figure 6 shows the graphical representation of the centroid point calculation for the output vector Y[].
termined by detecting edges from signals received from the hall-effect sensors. The signals are fed into the
TMS320F2812’s capture pins and are
debounced to eliminate noise or false
edges from motor oscillations. The actual motor speed is calculated by
counting the edge-triggered signals
from the Hall-effect sensors via a software module. Figure 7 shows the hardware block diagram for controlling a
three phase BLDC
motor.
HARDWARE DESCRIPTION
The eZdsp2812 board is used in this
motor control application. At the heart
of the eZdsp board is the
TMS320F2812 DSP. The
TMS320F2812 is a 150-MHz device
that uses timer T1 running at 20 kHz
for generating PWM1-6 signals, and timer T2 running
The fuzzy controller calculates
at 40 kHz for executing inthe absolute and differential based on the SOFTWARE
terrupt service routines
DESCRIPTION
(ISRs). Additionally, the intarget set speed, current speed, and
The motor control
put capture pins CAP1-3 are
previous absolute error.
software is composed
used to collect speed data
of DMC Library modfrom the hall-effect sensors.
motor control board. Spectrum Digital ules and the FL motor control routines.
Other members of the 28xx family
Seven of the DMClib modules are used
provides two boards that provide this
may be substituted for the
in this application. They are:
function: the DMC550 and the
TMS320F2812. For instance, the eZdsp2808 board may be used if the timers DMC1500. Either board plugs directly
into the eZdsp28xx board.
driving the PWM and ISRs are
Datalog
Hall-effect sensors are used for
changed. Specifically on the eZdsp2808
BLDC3PWM
feedback for the fuzzy logic control
board, EPWM1-3 is used for PWM
Hall3_Drv
loop. The commutation instants for the
generation, while CPU timer 0 is used
Mod6_Cnt
3-phase power inverter switches are defor an ISR interrupt source. Similarly,
Rmp2Cntl
Ramp_Cntl
Speed_PR
•
•
•
•
•
•
•
The output membership function.
y
NM
NS
-0x10
-0x8
ZE
0x0
PS
PM
0x8
0x10
Figure 5
The output membership function multiplied by vector Y[].
y
NM
NS
-0x10
-0x8
ZE
0x0
0x13F
0x196A
PS
PM
0x8
0x10
Figure 6
24
MARCH 2008 | embedded systems design | www.embedded.com
Additionally, the FL motor control is
handled by a main FuzzyCtl() routine; this is FuzzyBLDC() for BLDC
motors. When configured, these components demonstrate fuzzy logic control of a variable speed motor.
The software works by first performing configuration, then application-specific setup. Specifically, the
GPIO pins are configured to act as
PWMs and CAPture pins. Next the
timers and module parameters are initialized, as well as ISR setup. After all
peripherals are setup, interrupts are
enabled, and the main control loop is
entered. The main control loop calls
the fuzzy controller once every 8.7 ms.
The error values are converted
through fuzzification into fuzzy values
and stored in X1[], and X2[]. Once
converted, the fuzzified values applied
to the fuzzy inference rules. The results
from the inference module are stored
in Y[]. Output from Y[] is then applied
cover feature
to the defuzzification module to convert the fuzzy value back to a crisp value. The resulting crisp value is a PWM
offset that is added to the current
PWM duty cycle; creating a closed loop
system. The updated PWM value is
checked to see if the new value is within bounds, and appropriate action is
taken if it is not. Finally the fuzzy controller returns the updated PWM duty
cycle count to the calling routine.
Figure 8 shows a debug session of
the demo application. Channels 1 &2
(the display window in the upper-right
hand corner) displays the PWM counter, and the capture of the hall-effect
sensors respectively. Channels 3 & 4
(the display window beneath channels
1 & 2) show the edge-triggered versions of the PWM counter and the
hall-effect sensors. The watch window
displays important variables. Most important are SetSpeed, and CurrentSpeed. These values are close
enough so that the output of the fuzzy
controller has a zero value. Also note
the other values used in the controller
process. This session shows the motor
under no-load conditions. The behavior may be slightly different with a
load. Moreover, if a finer granularity is
desired it may be necessary to tune the
controller. ■
Byron Miller is an independent firmware
engineer specializing in the design of
microprocessors, DSPs, hardware debug, porting, as well as the development
of firmware for control, data acquisition,
fuzzy logic, and Internet appliances. He
has a BA in computer science and a
masters in software engineering. You
can reach him at bmiller2@isd.net.
FURTHER READING:
Von Altrock, Constantin. Fuzzy Logic and NeuroFuzzy Applications Explained. Englewood Cliffs, NJ: Prentice Hall, 1995.
Miller, Byron. The Design and Development of
Fuzzy Logic Controllers. Minneapolis,
MN: Impatiens Publications, 1997
Demonstration application motor control block diagram.
3.3V
BLDC
motor
12Vdc
6 - PWMs
3-Phase
inverter
3-Phase
TMS320F/C2812
CAP1 - 3
X1
Hall
effect
sensors
X2
Figure 7
Motor debug session.
Figure 8
Brubaker, David. “Fuzzy-logic system solves
control problem,” EDN June 18, 1992,
p. 121.
Brubaker, David. “Design and simulate your
own fuzzy setpoint controller,” EDN
January 5, 1995, p. 167.
V. Donescu, D.O. Ncacsu, G. Griva, “Design
of a Fuzzy Logic Speed Controller for
Brushless DC Motor Drives,” IEEE
Spectrum September 1996, p. 404.
G. Klir, D. Schwartz, “Fuzzy logic flowers in
Japan, IEEE Spectrum JULY 1992, p. 32.
M. Chow, Y. Tipsuwan, “Fuzzy Logic Microcontroller Implementation for DC
Motor Speed Control,” IEEE Spectrum
March 1999, p. 1271.
Brubaker, David. “Fuzzy-logic basics: intuitive
rules replace complex math,” EDN June
18, 1992, p. 111.
J. Lee, T. Im, H. Sung, Y. Kim, “A Low Cost
Speed Control System of Brushless
DC Motor Using Fuzzy Logic,” IEEE
Spectrum April 1999, p. 433.
Miller, Byron. “A Top-Down Approach to
Fuzzy Logic Design,” Embedded Systems
Programming, July 1998, p. 52.
Simon, Dan. “Fuzzy Control,” ESP July, 2003,
p. 55.
Miller, Byron. “Fuzzy Logic Does Real Time
on the DSP,” Dr. Dobbs Journal, July
2004, p. 25.
Fuzzy Logic: An Overview of the Latest Control Methodology. (TI doc – SPRA028).
Fuzzy Logic Motor Control with MSP430x14x.
(TI doc- SLAA235).
TMS320F/C28xx Data Manual. (TI doc –
SPRS174M).
www.embedded.com | embedded systems design | MARCH 2008
25
From the core to the access, over copper, optical fibers and through the air, AMCC
powers and connects the technology that connects today's world. With unique solutions
like the PowerPC 405EX, winner of Electronics Products’ 2007 Product of the Year award,
we’re setting the pace in the development of:
• Power Architecture Processors
• Datacom PHYs
• SAS and SATA RAID Controllers
• Telecom PHYs
• Framers/Mappers
• Storage Processors
And we’re ready to help you with all your PROCESS • TRANSPORT • STORE applications.
Ready to find out more? Visit us at...
San Jose, CA
April 15-17, 2008
Expo Booth 2010
or learn about the latest AMCC products online at
www.amcc.com
AMCC is a registered trademark of Applied Micro Circuits Corporation. All other trademarks are the property of their respective holders. Copyright © 2007 Applied Micro Circuits Corporation. All Rights Reserved.
feature
Although you may not have heard of atomic transactions, they’re
likely to change how you design and verify embedded systems.
Hardware/software
verification
enters the atomic
age
BY GEORGE HARPER
W
hile the 1940s and 1950s saw the dawn of the nuclear age for power and weaponry, a half a century
later we’re just now entering an atomic age of a
different sort. Having little to do with radioactivity, this atomic age is about software and hardware
design, specifically using atomic transactions, by far the most powerful technique for managing one of our most tricky problems, concurrency.
Even if you haven’t heard of atomic transactions before, they’re likely to have an impact on your future work,
whether you design embedded software, architect systems,
perform verification, or design hardware. Atomic transactions are not a new technology, but the increasing complexity and amount of concurrency in systems is pressing their
emergence in all of these areas.
So, just what are atomic transactions? And, how are
they already manifesting themselves in embedded systems
software, processor, and hardware design? After introducing
atomic transactions and ways in which they’re revealing
themselves, this article will take a special look at their implications to verification.
e-
e+
+
+
+
ee-
ATOMIC TRANSACTIONS 101
If you are familiar with database transactions, you’ve probably already
been exposed to atomic transactions. When processing multiple, simultaneous transactions, databases use atomic transactions to maintain consistency. Imagine a couple who share a bank account and simultaneously
make two withdrawals of $100 from separate ATM machines across town
(Figure 1). Several steps are involved in each withdrawal: A) checking the
www.embedded.com | embedded systems design | MARCH 2008
27
feature
A common instance of the use of atomic transactions is in
databases, such as those used in ATM machine applications.
The example here shows simultaneous withdrawals from one
account.
ATM 1
ATM 2
Bank operations (non-atomic)
ATM 1
Get balance =
$1000
Output $100;
Calculate new
balance = $900
Update new
balance
ATM 2
Account
ATM 1
$1000
Get balance =
$1000
Get balance =
$1000
Output $100;
Calculate new
balance = $900
Update new
balance
Bank operations (Atomic)
ATM 2
$1000
Output $100;
Calculate new
balance = $900
Update new
balance
$900
Get balance =
$900
$900
Output $100;
Calculate new
balance = $900
$900
Incorrect
Update new
balance
balance; B) providing the money and
calculating the new balance, and; C) updating the balance with the new amount.
Now imagine that each step were independent (1A, 1B, and 1C for one of the
couple and 2A, 2B and 2C for the other)
and performed in the following order:
1A, 2A, 1B, 2B, 1C, 2C. What would happen? Both would receive $100, but the
bank account would only be debited a
total of $100, instead of $200.
Databases use atomic transactions to
prevent this inconsistency from occurring and ensure that steps A, B, and C
happen together and indivisibly for each
withdrawal transaction. Atomic transactions ensure that the two withdrawals are
performed in one of two orders: 1A, 1B,
1C, 2A, 2B, 2C or 2A, 2B, 2C, 1A, 1B, 1C.
Atomic transactions have the same
properties that we saw in the bank ATM
example. These transactions are atomic,
which means that they are indivisible
and all-or-nothing. Atomicity ensures
that multiple, related operations occur
$800
TRS EXPRESSES ATOMICITY
One example of a high-level specification
language using this computational model is the term rewriting system (TRS).
TRSs offer a convenient way to describe
parallel and asynchronous systems and
prove an implementation’s correctness
with respect to a specification. TRS descriptions, augmented with proper information about the system building blocks,
also hold the promise of high-level synthesis. High-level architectural descriptions that are both automatically synthesizable and verifiable would permit
architectural exploration at a fraction of
the time and cost required by current
commercial tools.
A TRS is defined as a tuple (S, R, S0),
where S is a set of terms, R is a set of
rewriting rules, and S0 is a set of initial
terms. The state of a system is represented as a TRS term, while the state transitions are represented as TRS rules. The
general structure of rewriting rules is:
Correct
Figure 1
28
Account
descriptions of the highest abstraction
and simplifies the reasoning around
correctness.
indivisibly, as though they’re happening
in isolation and without having to be
concerned about other system activities.
And, atomicity ensures that multiple, related operations are all-or-nothing—all of the operations in a transaction are completed or none of them are
completed. These properties ensure a
consistent state relative to all other
transactions in the system.
Many high-level specification languages for concurrent systems express
concurrent behavior as a collection of
rewrite rules, where each rule has a
guard (a Boolean predicate on the current state) and an action or set of actions
that transform the state of the system.
The active rules, where the guards
are true, can be applied in parallel, but
each rule operates as an atomic transaction—each rule observes and ensures a
consistent state relative to all other rules
in the system.
This atomicity model is popular because it enables concurrent behavioral
MARCH 2008 | embedded systems design | www.embedded.com
( )
s1 if p s1
→ s2
(1)
where s1 and s2 are terms, and p is a predicate. We can use a rule to rewrite a term
if the rule’s left-hand-side pattern matches the term or one of its subterms, and
the corresponding predicate is true. The
new term is generated in accordance
with the rule’s right-hand side.
If several rules apply, then any one of
them can be applied. If no rule applies,
the term cannot be rewritten any further.
In practice, we often use abstract data
types such as arrays and FIFO queues to
make the descriptions more readable.
With proper abstractions, we can
create TRS descriptions in a highly
modular fashion. And using a compiler
for hardware synthesis from TSRs, such
descriptions can be translated into a
standard hardware description language like Verilog. By restricting the
generated Verilog to be structural, commercial tools can be used to go all the
feature
way down to gates and layout.
The terms’ grammar, when augmented with details such as instruction
formats and sizes of various register
files, buffers, memories, and so on, precisely specifies the state elements.
Each rule is then compiled such
that the state is read in the beginning of
the clock cycle and updated at the end
of the clock cycle. This single-cycle implementation methodology automatically enforces the atomicity constraint
of each rule.
All the enabled rules fire in parallel
unless some modify the same state element. In case of such a conflict, one of
the conflicting rules is selected to fire on
the basis of some policy.
An example of the power that the
use of TSR atomicity brings to hardware synthesis is illustrated in Figure 2,
in which Euclid’s algorithm for computing the greatest common divisor
(GCD) of two numbers is expressed in
TSR notation. From this, the Term
Rewriting Architectural Compiler generates a Verilog description of the circuit shown in Figure 3.
Euclid’s algorithm for greatest
common divisor (GCD) using
rewrite rules.
ATOMICITY AND GENERATING
HARDWARE/SOFTWARE
How do atomic transactions such as
those employed in TRSs contrast with
other approaches used in software and
hardware, such as with C/SystemC, Verilog, and VHDL? Contrasting these approaches with atomicity highlights just
how low-level, manually intensive, and
fragile these approaches are.
In all of these other approaches, coordinating and managing the access to
shared resources, which includes both
arbitration and control, must be done
explicitly and from scratch by the engineer in every instance. This makes these
approaches:
Rewrite rules to implement Euclid’s algorithm.
•
•
Tedious, due to the ad hoc, low-level
nature of managing concurrency.
Error prone, subject to race condi-
( )
( )
( )
(
)
R1 GCD a, b → GCD b, a if a > b, b ≠ 0
R2 GCD a, b → GCD a, b − a if a ≤ b, b ≠ 0
Example of rules executing.
(
Apply
R2
)
Apply
R2
( )
Apply
R1
( )
GCD 6,15 → GCD 6, 9 → GCD 6, 3 →
( )
Apply
R2
Apply
( )R
( )
GCD 3, 6 → GCD 3, 3 → GCD 3, 0
Figure 2
•
2
Solution: 3 is the GCD of 6 and 15.
tions, interface protocol errors, mistimed data sampling (for hardware),
deadlocks, among others.
Brittle to changes, requiring the
control to be redesigned each time
there is a small change in the specification or implementation.
Another issue with these approaches
www.embedded.com | embedded systems design | MARCH 2008
29
feature
The greatest common divisor circuit. The δ wires represent the
new state values, while the π wires represent the corresponding
rules’ firing condition. π1 + π2
π1
Enabled
δ1, x
x
>
–
π1
δ2, x
π2
π2
Zero?
δ1, y
δ1, y
δ2, x
y
δ1, x
Enabled
Figure 3
π1
is that shared resource management is
non-modular in nature, extending across
module boundaries throughout system
designs. Even if you ensure that individual modules operate properly from an
atomic operation standpoint, you cannot
use them as black boxes as you compose
larger systems with them. Atomicity
management requires control logic, and
control logic is inherently non-modular.
As you compose larger and larger systems, threads, events, always blocks and
processes do not scale.
Atomic transactions, in contrast,
dramatically raise the level of abstraction
by automatically managing the complex
aspects of concurrency: shared resource
arbitration and control. And, atomic
transactions can be easily composed at a
system level, allowing modules to be integrated as black boxes, without having
to consider the impact of inter-module
interactions on the internal resources of
the modules. With atomic transactions,
module-level testing can leveraged at the
system level, without having to reverify
that interface protocols at every interface
point are properly being handled and remaining within required boundaries.
IMPLICATIONS FOR EMBEDDED
As a much higher level of abstraction for
concurrency, atomic transactions are becoming available in areas that previously
have not benefited from their power.
30
While widely available as a database tool,
how are atomic transactions likely to surface for those writing embedded systems
software, working with processors, and
designing hardware?
Programming for multicore and
multithreaded processors requires conscious, low-level synchronization of access to shared memory resources. In order to make software development more
efficient for these architectures, this burden needs to be removed. The burden for
coordinating access to shared resources
needs to shift from the engineer to the
programming languages, operating systems, compilers, and processors.
Expect to see atomic transactions as
an additional concurrency tool in software languages, supplementing the roles
currently played by lower level mechanisms like semaphores, events, and locks.
According to “M’soft: Parallel programming model 10 years off” (Rick Merritt
(EE Times, 7/23/07, available at www.em
bedded.com/201200461), Microsoft is
planning to build atomic transactions
into C# and is already building software
transactions into Haskell. Burton Smith
of Microsoft was quoted in this article, “I
think we ultimately will see atomic transactions in most, if not all, languages.
That’s a bit of a guess, but I think it’s a
good bet.”
Also, expect to hear about “transactional memory.” It’s already getting a lot
MARCH 2008 | embedded systems design | www.embedded.com
of attention as a key mechanism in architecture circles for ensuring atomicity
with multicore, multithreaded architectures. A transactional memory mechanism
enables a series of shared memory reads
and/or writes to occur atomically. If all
memory accesses cannot complete, the
transaction may be fully aborted and retried later.
Transactional memory allows a software programmer to think about each
transaction as a single-threaded operation, leaving the details of shared resource management to the underlying
software and hardware. While transactional memory solutions have been implemented in software, the performance
overhead for maintaining transaction
logs argues for hardware support.
For this reason, a lot of research is
focusing on the right kinds of hardware
support to build into processors. Hardware mechanisms in commercial products shouldn’t require a long wait. According to Sun, support for transactional
memory is “imminent.” (At ISSCC recently, Sun outlined details of their Rock
processor with transactional memory.)
For those working directly with processors, writing software and debugging applications, expect to encounter transactional memory and associated language,
compiler, run-time, and (possibly) operating-system support.
IMPLICATIONS FOR VERIFICATION
There are several ways in which atomic
transactions are likely to affect verification: first, as a hardware and/or software
component, such as transactional memory, that must be verified; second, as an
additional tool in the verification toolbox; and, finally, as a device-under-test
(DUT) that has been designed with
atomic transactions.
Verifying atomic-transaction
mechanisms: As transactional memory
and other mechanisms become more
prevalent, more people will be involved
in the verification of multicore-, multiprocessor-, multithread-based designs
that use atomic transactions.
Doing so will require a deep understanding of the atomic transaction
mechanisms and their potential failure
feature
modes. Test scenarios for these types of
designs are complex and numerous, as
they involve system-level hardware and
software with many subtle corner cases.
Fortunately, while these mechanisms
may be more complex to verify, they dramatically reduce the complexity for software teams that are end-users of the devices in which these mechanisms live.
Using atomic transactions as a
new verification tool: Although verifying atomic-transaction mechanisms is
akin to handling yet another complex
piece of IP, its more interesting to explore what atomic transactions can deliver as a verification tool.
Managing complex concurrency is
an issue for hardware verification engineers as well—and will soon be a much
broader one for those verifying software.
Atomic transactions can simplify the
complexity of concurrency and consequently accelerate verification efforts and
reduce bugs in testbenches and models
developed by verification teams.
When validating concurrent designs,
test-case stimulus generation can get
complex, involving contortions and a lot
of complex control to induce desired
conditions. Atomic transactions simplify
the specification of the requisite conditions under which a test case should be
performed—and simplify the generation
of the proper stimulus. Atomic transactions allow each test case to be written
succinctly and separately.
Other verification activities that can
be challenging, especially when concurrency comes into play or cycle accuracy is
required, are creating golden reference
models, system models, and verification
models. Designing these types of models
typically takes much longer than desired
or required and often involves much
more debugging than acceptable.
With its much simpler concurrency
model, atomic transactions accelerate the
development of these types of models
and dramatically reduce the bugs. And,
the best thing of all, these models and
testbenches can be synthesized into efficient RTL for use in emulators and FPGAs. Imagine being able to develop a
golden reference model quickly and run
it in hardware against a synthesizable
testbench at orders of magnitude faster
than simulation.
DUT designed with atomic transactions: When verification teams are
the downstream beneficiaries of designs
built using atomic transactions instead
of traditional, lower-level concurrency
mechanisms, the verification teams will
adapt their methods and experience
improvements in the verification
process thanks to the design’s stronger
EMBEDDED STOR AGE
SOLUTIONS
Reliable File
Systems
SAFE
HCC specializes
in storage
solutions
for embedded
systems
NAND Flash
NOR Flash
interface semantics and simpler concurrency model.
I’ll explain the methods and improvements in part two of this article,
posted online at Embedded.com. ■
George Harper is vice president of marketing at Bluespec and has more than 15
years of experience in the semiconductor industry. He holds a BSEE and MSEE in electrical engineering from Stanford University
and an MBA from Harvard University. He
can be reached at gharper@bluespec.com.
COMPLETE USB
SOLUTIONS
USB Stacks
USB
Device
Data Flash
TINY
uC Flash
Data Flash
USB Host
Serial Fash
FAT File
Systems
FAT
THIN
Quick Start storage
devboards are
available for:
MSP340,
LPC2xxx,
STR7xx,
XC16x,
AT91SAM7, 8051 and
more.
HDDs
Embedded Pipe
Windows driver
for embedded
application
control
Mass Storage
MTP
CDC
HID
Embedded Pipe
Bootloader
Mass Storage
Printer
CDC
HUB
HID
Embedded Pipe
OTG
Supported Targets Include:
MMC/SD/SDHC
Compact Flash
EHCI, OHCI, ISP1161, ISP1362, ISP1561/2,
NAND Flash
ISP1761, MAX3421e, STR71x, STR91x,
MMC/SD/SDHC
Compact Flash
Data Flash
NAND Flash
All our systems are sold royalty
free with full C source code
and our unrivalled suppor t.
LPC2148, LPC23xx, LPC24xx, LPC3180,
AT91SAM7xx, AT91SAM926x, AT91RM9200,
MPC834x, MCF52xxx, MCF53xx, MCF54xx
Embedded design,
realization and porting
services available
w w w . h c c – e m b e d d e d . c o m
www.embedded.com | embedded systems design | MARCH 2008
31