Embedded System Design 2010.12

VOLUME 23, NUMBER 10 DECEMBER 2010
EMBEDDED SYSTEMS DESIGN
The Official Publication of The Embedded Systems Conferences and https://www.wendangku.net/doc/a618768319.html,
Pointer reference proving ground 9 Are datasheets the key to easy controllers 27 Ganssle’s book shelf: TDD & more 34
ICs fordeck in your favor devices: medical Shuffling the
20

One Size Doesn’t Fit All
With HCC, you can choose a file system that’s ? File Systems ? USB Stacks ? Bootloaders ? Windows Drivers ? Embedded Development Services
THE MOST COMPREHENSIVE PORTFOLIO OF FILE SYSTEMS FOR EMBEDDED APPLICATIONS
right for your application. HCC products run with the broadest range of CPUs and memory devices, with or without an operating system.
HCC-Embedded
FILE SYSTEMS WITH A DIFFERENCE
https://www.wendangku.net/doc/a618768319.html, ? info@https://www.wendangku.net/doc/a618768319.html,

INTEGRITY RTOS has it. No one else does.
The NSA has certi?ed the INTEGRITY RTOS technology to EAL6+. INTEGRITY is the most secure real-time operating system available and the ?rst and only technology to have achieved this level. The NSA also certi?ed 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.
https://www.wendangku.net/doc/a618768319.html,

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.
https://www.wendangku.net/doc/a618768319.html,
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
programming pointers
Measuring instead of speculating
BY DAN SAKS
9
EMBEDDED SYSTEMS DESIGN
VOLUME 23, NUMBER 10 DECEMBER 2010
Some programmers think modeling memory-mapped devices as C++ objects is too costly. With some architectures, the chances are they’re wrong.
break points
BY JACK G. GANSSLE
34
New embedded systems books
20
Jack recommends some interesting reading for the embedded systems engineers.
DEPARTMENTS
#include
A medical matter
BY RON WILSON
5
To what lengths will medical devices of the future go? It’s an explosive new application area, but with some staggering challenges.
Cover Feature:
parity bit
ESC Silicon Valley
May 2–5, 2011 San Jose, CA https://www.wendangku.net/doc/a618768319.html,/
7
Bipolar vs. CMOS: Selecting the right IC for medical designs
BY KARTHIK VASANTH, SANDEEP OSWAL, AND EDUARDO BARTOLOME
Implantable, ingestible, interactive, interoperable, Internet enabled. The unique demands of medical devices, now and in the future, require the right IC process technology and packaging. Here’s a comparison between bipolar and CMOS for medical devices, along with some packaging issues to consider.
ESC Chicago
June 6–8, 2011 Chicago, IL https://www.wendangku.net/doc/a618768319.html,/
ESC India
July 20–22, 2011 Bangalore, India https://www.wendangku.net/doc/a618768319.html,/
27
Designing embedded controllers with building blocks
BY BARUCH EVENOR
ESC Boston
July 20–22, 2011 Boston, MA https://www.wendangku.net/doc/a618768319.html,/
It’s child’s play. Baruch Evenor describes a new building-block approach for designing embedded controller systems destined for mid-range apps with limited memory space.
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 ?oor, San Francisco, CA 94107, (415) 947-6000. Please direct advertising and editorial inquiries to this address. SUBSCRIPTION RATE for the United States is $55 for 10 issues. Canadian/Mexican orders must be accompanied by payment in U.S. funds with additional 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@https://www.wendangku.net/doc/a618768319.html,. For customer 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 of?ces. 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.
ONLINE
https://www.wendangku.net/doc/a618768319.html,

INDUSTRIAL
AEROSPACE
SYSTEM ON A CHIP
MEDICAL
AVIATION
CONSUMER
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, T H R E and our ?agship product, ThreadX, 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 ?eld-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!
THREADX: WHEN IT
Contact Express Logic to ?nd out more about our ThreadX RTOS, FileX? ?le 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 over?ows a thing of the past. And if you’re developing safety-critical products for aviation, industrial or medical applications, ask about our new Certi?cation Pack? for ThreadX.
Second Editio n
Newnes
E REAL-TIM ED EMBEDD ADING RE MULTITH
append Now with architectures PowerPC MIPS and
adX for ARM, Cold?re, With Thre ices
For a free evaluation copy, visit https://www.wendangku.net/doc/a618768319.html, ? 1-888-THREADX
L. Lamie Edward Copyright ? 2010, Express Logic, Inc. ThreadX, FileX, and TraceX are registered trademarks, and NetX, USBX, PrismX, StackX, and Certi?cation Pack are trademarks of Express Logic, Inc. All other trademarks are the property of their respective owners.
M CD-RO INCLU DED

EMBEDDED SYSTEMS DESIGN
BY Ron Wilson
Director of Content/Media, EE Times Group Events and Embedded Ron Wilson (415) 947-6317 ron.wilson@https://www.wendangku.net/doc/a618768319.html, Managing Editor Susan Rambo susan.rambo@https://www.wendangku.net/doc/a618768319.html, Acquisitions/Newsletter Editor, https://www.wendangku.net/doc/a618768319.html, Site Editor Bernard Cole bccole@https://www.wendangku.net/doc/a618768319.html, Contributing Editors Michael Barr, John Canosa, Jack W. Crenshaw, Jack G. Ganssle, Dan Saks, Larry Mittag Art Director Debee Rommel debee.rommel@https://www.wendangku.net/doc/a618768319.html, Production Director Donna Ambrosino dambrosino@https://www.wendangku.net/doc/a618768319.html, Subscriptions/RSS Feeds/Newsletters https://www.wendangku.net/doc/a618768319.html,/electronics-subscriptions Subscriptions Customer Service (Print) Embedded Systems Design PO Box # 3609 Northbrook, IL 60065- 3257 embedsys@https://www.wendangku.net/doc/a618768319.html, (847) 559-7597 Article Reprints, E-prints, and Permissions Mike O’Brien Wright’s Reprints (877) 652-5295 (toll free) (281) 419-5725 ext.117 Fax: (281) 419-5712 https://www.wendangku.net/doc/a618768319.html,/reprints/index.cfm ?magid=2210 Publisher David Blaza (415) 947-6929 david.blaza@https://www.wendangku.net/doc/a618768319.html, Editorial Review Board Michael Barr, Jack W. Crenshaw, Jack G. Ganssle, Bill Gatliff, Nigel Jones, Niall Murphy, Dan Saks, Miro Samek
#include
backwater, medical applications are attracting technology so advanced it is in many cases still in the research lab. Some of these devices can only work through a fusion of very different disciplines: for example MEMS, microfluidics, surface electrochemistry, nanopower computing, near-field wireless networking, and energy scavenging. These are disciplines that barely speak to each other. But what does all this mean for the embedded software expert? Take that last point, for example. Software developers on an implantable blood chemistry analyzer may find themselves trying to extract requirements and theory of operation from a diverse set of hardware designers, chemists, and nanoscale fabricators who don’t even speak each other’s languages. Good luck on that. There will be other interesting challenges. The general trend in embedded computing of late has been for the hardware to so far exceed the absolute computing needs of the application that choice of language, methodology, and quality of code didn’t make much difference. But many of these medical devices will be trying to do a great deal of control and signal conditioning with vanishingly small amounts of energy and tiny memory space. That may force a return to a level of care in coding that many embedded designers have long since forgotten. And then there is safety. With a human life potentially at stake in every application, the demands for code reliability and security will be unprecedented. Casual debugging will not answer in this space any longer. It’s an explosive new application area, but with some staggering challenges.
A medical matter
W
Corporate—EE Times Group
Paul Miller Felicia Hamerman Brent Pearson Jean-Marie Enjuto Amandeep Sandhu Barbara Couchois Chief Executive Of?cer Group Marketing Director Chief Information Of?cer Financial Director Manager Audience Engagement Vice President Sales Ops
e don’t often print a feature on medical electronics. The area might seem one of those charming but slow-moving little backwaters with which the embedded world is so replete. In some senses, medical electronics has been not a distinct application area at all, but merely a subset of the test and measurement market. Medical electronic devices have mostly been measuring instruments that get splashed with saline solutions. But as Vasanth, Oswal, and Bartolome point out in our cover story, all that is changing. The industry has begun moving along several different trajectories at once, and moving rapidly. Imaging systems are growing to include huge numbers of sensors, massive data storage capacities, and enormous amounts of processing power. At the other extreme, diagnostic devices are shrinking from the table-top to the implantable or even the ingestible—think a colonoscopy in a pill—forcing new levels of miniaturization, energy efficiency, and autonomous intelligence. Designers are working on ICs that can conduct a full set of blood chemistry measurements within one chip, log the results, and disappear unmourned into the medical waste bin. And theyre planning implantable systems that can draw energy from their host while continuously monitoring a body characteristic, transmitting results to an external relay point and thence through the cellular network to a remote center for analysis. So a great deal is changing on the hardware front. Far from being a
Ron Wilson is the director of content/ media, EE Times Group Events and Embedded. You may reach him at ron.wilson@https://www.wendangku.net/doc/a618768319.html,.
Corporate—UBM LLC
Marie Myers Pat Nohilly Senior Vice President, Manufacturing Senior Vice President, Strategic Development and Business Administration
Ron Wilson, ron.wilson@https://www.wendangku.net/doc/a618768319.html,
https://www.wendangku.net/doc/a618768319.html, | embedded systems design | DECEMBER 2010
5

Mission
Make the Dreamliner a reality
Critical
Breakthrough 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 ?ight 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 https://www.wendangku.net/doc/a618768319.html,/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
Embrace the bugs
B
ugs are always cursed but they have a vital function, too. (Michael Barr, “Five more top causes of nasty embedded software bugs,” November, https://www.wendangku.net/doc/a618768319.html,/ discussion/other/4210308/Five-moretop-causes-of-nasty-embedded-software-bugs.) They force us to take a hard look at the design and the code (this usually does not happen in code reviews) and keep us familiar with the software to fight future new [bugs] and to perform general maintenance of the software—a sort of periodic refresh. Somewhat similar to the viruses and bacteria that keep the immune system up-to-date and alive. Bugs are part of interconnected web of software life. —piyush_ Adherence to coding standards is great advice as are code reviews. But what do you do if you’re an independent or a one-person software team? Obviously, following best practices is vital in that case, as in all cases. If you or your company have to money to hire out for a code review, problem solved. But what do you do if logistically or financially those aren’t options. No programmer should ever be forced into a “No time to do it right, but time enough to do it over” scenario, but the real world all too often has other ideas. Back through the way-back machine, I found myself in such a situation every now and then. No one to look over my shoulder and no resources to hire out a code review. I’d typically take my code to a friend or family member. They didn’t have programming experience, but I’d walk through my code, explaining how each function worked.
I certainly wasn’t going to get someone to point out a flaw, but just through the act of explaining things to someone, I would frequently find a large number of my errors or usage of lousy coding practices. Anyone have any thoughts on how to best hunt down bugs in such a nonoptimal environment where peer or independent code reviews are not an option? —Duane Benson Memory leaks—better still, never use malloc() and statically define the buffers (or only malloc once for the
recent energy article (“A matter of energy,” November, https://www.wendangku.net/doc/a618768319.html,/ discussion/other/4210707/A-matter-ofenergy). I believe there’s a misconception among our fellow engineers that energy conservation only applies to mobile (battery-powered) devices. I would argue there is a need for all embedded devices to practice power management. I would also like to add that power management is perhaps foremost a system design issue. Thanks for the great article. —Bill Long Generic event processor The article “Tracing of the event flow in state-based designs” (Peter Mueller, November, https://www.wendangku.net/doc/a618768319.html,/design/ embedded/4210574/Tracing-of-theevent-flow-in-state-based-designs) focuses on automatic generation of software tracing instrumentation in-line with the generated state machine code. An alternative implementation strategy for state machines is to use a generic event processor, which executes the user-defined actions and transitions generically. The benefit for software tracing is that the tracing instrumentation can be placed inside the event processor instead of being repeated in every entry action, exit action, initial transition, regular transition, etc. This avoidance of repetitions can save a lot of code. Another aspect not fully exploited in the article is that the execution environment for state machines can also be used for software tracing. For example, the article shows how to execute state machines with an RTOS (Listing 1) and in a “superloop” (Listing 2). The presented designs are reusable, but in
CONTINUED ON PAGE 33
! ! !
No programmer should be forced into a “No time to do it right, but time enough to do it over” scenario, but the real world often has other ideas.
fixed buffer pool). KEEP STATS on the buffer pools. The end-notes are correct. Deadlock—Dining Philosophers. Race conditions—Don’t allow them; wait until the race is guaranteed over, and everything else. Only the first two actually work. —one_armed_bandit Nice collection of “design patterns for bugs.” Most of these have corresponding patterns in circuit design for hardware. Nice. —ShepSiegel Energy matters I just read and enjoyed Ron Wilson’s
https://www.wendangku.net/doc/a618768319.html, | embedded systems design | DECEMBER 2010
7

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 e?ective services that combine global delivery with local interface Reduced product development costs and faster time-to-market An impeccable track record of “?rst pass silicon success” over 200+ ASIC tapeouts
Australia | Canada | France | Germany | India | Japan | Malaysia | Netherlands | Norway | New Zealand |Sweden| Singapore | UAE | UK | USA https://www.wendangku.net/doc/a618768319.html, t ech- enterprises.co m e n g i ne e r i ng @ i nf o t e ch - https://www.wendangku.net/doc/a618768319.html,

By Dan Saks
programming pointers Measuring instead of speculating
alternative data representations for memory-mapped device registers that eliminate the need to use pointers to access memorymapped devices.4 In November, I delineated some of those alternatives more explicitly.5 All of this brings us back to the question I set out to answer: Does eliminating pointer references from function calls and function bodies actually improve the run-time performance of C or C++ code that manipulates memory-mapped devices? To answer this, I ran some timing tests using a few different C and C++ compilers. This month, I’ll describe how I wrote the tests and what conclusions I think we can draw from the results. Some of the results surprised me. I suspect they’ll surprise many of you, too. TEST DESIGN CONSIDERATIONS Different processors support different combinations of addressing modes. Some are better at, say, absolute addressing than they are at base+offset addressing, and others are just the opposite. For a given processor, some compilers may be better than others at leveraging the addressing modes on the target processor. Thus, the results you get from measurements made with one compiler targeting one processor may not be the same as what you get with a different compiler or different target processor. No surprise there. I have access to only a modest assortment of compilers and processors. Any conclusions that we can draw from running tests with the tools I have might be broadly applicable, but I have no illusions about discovering universal truths. Running tests on only a small set of compilers or processors can still yield useful information—just not as much as most of us would like. Therefore, I’ll explain how and why I designed the test programs as I did so that you can write similar (or perhaps better) tests for other compilers and processors, make your own measurements, and share your observations with the rest of us. For this first round of measurements, I decided to use
https://www.wendangku.net/doc/a618768319.html, | embedded systems design | DECEMBER 2010
ast spring, I began a series of columns on representing and manipulating memory-mapped devices in C and C++. In May, I considered the alternatives in C and advocated that structures are the best way to represent device registers.1 In June, I explained why C++ classes are even better than C structures.2 In Standard C and C++, you can’t declare a memory-mapped object at a specified absolute address, but you can initialize a pointer with the value of that address. Then you can dereference that pointer to access the object. That’s what I did in those articles last spring. The June column prompted several readers to post comments alleging that using a pointer to access a C++ class object representing a memory-mapped device incurs a performance penalty by somehow adding unnecessary indirect addressing. Interestingly, no one complained that using a pointer to access a C structure incurs a similar performance penalty. This left me wondering if the allegation is that using a C++ class is more expensive than using a C structure, or if it’s that using pointers to access memory-mapped class objects is more costly than using some other means. My impression is that the authors of the comments were more concerned about the latter—the alleged cost of using pointers. However, I suspect many of you are also interested in knowing whether using C++ classes is more expensive than using comparable C structures. I know I am. Therefore, I decided to evaluate alternative memorymapped device implementations in both C and C++. In my August column, I described the common standard and non-standard mechanisms for placing objects into memory-mapped locations.3 In September, I presented
L
! ! !
Some programmers think modeling memory-mapped devices as C++ objects is too costly. With some architectures, the chances are they’re wrong.
Dan Saks is president of Saks & Associates, a C/C++ training and consulting company. For more information about Dan Saks, visit his website at https://www.wendangku.net/doc/a618768319.html,. Dan also welcomes your feedback: e-mail him at dan@https://www.wendangku.net/doc/a618768319.html,.
9

programmer’s pointers
! ! !
the one evaluation board I have that I can program with multiple compilers. The board has a 50MHz ARM processor with 512 Kbytes of memory and a small assortment of memory-mapped devices. I used three different compilers, each from a different vendor and of different vintage. Each compiler supported both C and C++. I compiled for the ARM (rather than THUMB) instruction set with little-endian byte ordering. I set each compiler to optimize for maximum speed. I didn’t turn the instruction cache on. All of the tests are variations on the same theme: the main function in each program repeatedly calls a function that accesses a memory-mapped device, and counts the number of calls it makes in a given span of time. Each program differs in (1) how it represents the registers of the memory-mapped device, (2) how it accesses those registers, and (3) whether the access functions are inline or not. The purpose of these test programs is to provide information to help evaluate programming techniques. They’re not for compiler benchmarking. Therefore, I won’t identify the compiler vendors. Rather, I’ll refer to each compiler by the year in which it was released: 2000, 2004, and 2010. IMPLEMENTATION CHOICES Each program tests either a polystate implementation, a bundled monostate implementation, or an unbundled monostate implementation. As I explained last month, a polystate implementation of a memory-mapped device uses a C structure or C++ class accessed via a pointer or reference. Polystate implementations support multiple instances of the same kind of device. The structures and classes that I presented in May and June, and that provoked the comments that triggered this investigation, are polystate implementations. A monostate implementation eliminates the need for pointers or references to access the device. A monostate implementation for a device permits only one instance of that device. As I explained last month, a monostate implementation can be bundled or unbundled. A bundled monostate wraps its data members in an additional structure; an unbundled monostate does not. For each design, I wrote a C implementation and a C++ implementation, and for each of those implementations, I wrote a version that used inline functions and another that did not. Thus, for example, I wrote a polystate implementation in C with inline functions, a polystate implementation in C with non-inline functions, a polystate implementation in C++ with
The purpose of these test programs is to provide information to help evaluate programming techniques. They’re not for compiler benchmarking.
inline functions, a polystate implementation in C++ with noninline functions, and so on for the bundled and unbundled monostate implementations. Not all the C compilers I used support inline functions, so I implemented the inline functions in C using function-like macros. PLACEMENT CHOICES As I noted earlier, in Standard C and C++, you can’t declare a memory-mapped object at a specified absolute address, but you can initialize a pointer with the value of that address. In the following discussion of the test cases, I describe this technique as using pointer-placement. For example, to access a timer_registers object residing at location 0xFFFF6000, you can declare a pointer called the_timer as a macro:
#define the_timer \ ((timer_registers *)0xFFFF6000)
or as a constant pointer:
timer_registers *const the_timer = (timer_registers *)0xFFFF6000;
My tests that use pointer-placement use the latter form. I randomly replaced the pointer constants with macros in a few test cases and saw no difference in the generated code. In C++, you can also write pointer casts using the reinterpret_cast operator, as in:
timer_registers *const the_timer = reinterpret_cast (0xFFFF6000);
I use this form in my C++ tests. In C++, but not C, you can use a reference instead of a pointer, as in:
timer_registers &the_timer = *reinterpret_cast (0xFFFF6000);
I call this technique reference-placement. As some readers suggested, you can declare a memorymapped object using a standard extern declaration such as:
extern timer_registers the_timer;
and then use a linker command to force the_timer into the desired address. I call this technique linker-placement. Some C and C++ compilers provide language extensions that let you position an object at a specified memory address. For example, to declare a timer_registers object residing at
10
DECEMBER 2010 | embedded systems design | https://www.wendangku.net/doc/a618768319.html,

RX Design Contest
What ca
Announcing the
do you with n
W
Your s ec
apo t we n... re
Get details on how to enter, and the over $110,000 in cash and prizes.
https://www.wendangku.net/doc/a618768319.html,/rx-contest
Renesas Partners participating in the RX Design Contest
...
165 DMIPS at 100MHz 500μA/MHz Zero-wait Flash Ethernet, USB, CAN
ill y at w ou d h
ith... ow
Over $110,000 in Cash and Prizes
Free to Qualified Contestants, the RX62N Development Kit
? 2010 Renesas Electronics America Inc.

programmer’s pointers
Listing 1 A C++ class de?nition for the Fibonacci device (using a polystate implementation with inline member functions).
class fibonacci_registers { public: void enable() { a0 = 0; a1 = 1; } unsigned get() { unsigned a2 = a0 + a1; a0 = a1; a1 = a2; return a0; } private: unsigned volatile a0, a1; };
Listing 2 A C “class” de?nition for the Fibonacci device (using a polystate implementation with inline member functions implemented as macros).
typedef struct fibonacci_registers fibonacci_registers; struct fibonacci_registers { unsigned volatile a0, a1; }; #define fibonacci_enable(_this) \ ((_this)->a0 = 0, (_this)->a1 = 1) #define fibonacci_get(_this, v) do \ { \ unsigned a2 = (_this)->a0 + (_this)->a1; \ (_this)->a0 = (_this)->a1; \ (_this)->a1 = a2; \ *(v) = (_this)->a0; \ } \ while (0)
location 0xFFFF6000, you might write:
timer_registers the_timer @ 0xFFFF6000;
with one compiler, or:
timer_registers the_timer _at(0xFFFF6000);
with another, or:
timer_registers the_timer __attribute__((at(0xFFFF6000)));
with yet another. I describe test cases that use declarations such as these as using at-placement. Of the compilers at my disposal, all three support pointerplacement—as they should because it’s standard—and all three C++ compilers support reference-placement. Only one compiler supports at-placement. I suspect all the compilers support linker-placement, but to be honest, I could figure out how to do it with only one. However, I realized I could simulate the behavior of linkerplacement easily, and increase the portability of the tests at the same time. Here’s how. A SOFTWARE “DEVICE” In order to time the execution of function calls that manipulate memory-mapped devices, I needed just two devices: a timer and something else. My hardware platform has a small assortment of devices such as lights, switches and serial ports, and I could have picked any one of them. But then again, I wanted these tests to be fairly easy to migrate, and I didn’t think I could rely on any one of these devices being available on other platforms. Rather than use a real hardware device, I invented a soft12
DECEMBER 2010 | embedded systems design | https://www.wendangku.net/doc/a618768319.html,
ware “device” that manipulates memory, and I wrote the tests to address the “device” as if it really were a memory-mapped device. The “device” is a Fibonacci sequence generator; each “get” operation applied to the device returns the next number in the Fibonacci sequence. A C++ implementation appears in Listing 1. The corresponding C implementation appears in Listing 2. The address range of the memory on my target evaluation board is from 0 to 0x7FFFF. I determined that my test programs weren’t using any memory at the higher addresses, so I placed the ?bonacci_registers object at 0x7FF00. For example, C test cases that use pointer-placement declare a pointer to the ?bonacci_registers using a declaration such as:
fibonacci_registers *const fibonacci = (fibonacci_registers *)(0x7FF00);
Programs that use at-placement declare the device as:
fibonacci_registers fibonacci @ 0xF7700;
Using the Fibonacci “device” also gave me a way to mimic linker-placement when I couldn’t figure out the linker commands to really do it. With linker-placement, the test program declares the “device” using the extern declaration:
extern fibonacci_registers fibonacci;
When I couldn’t use genuine linker-placement, I simply wrote the definition for the object in another source file, as in:
/* fibonacci.c */ #include “fibonacci.h” fibonacci_registers fibonacci;

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 and cost
Best price and performance Highest system performance and capacity
Powerful, flexible, and built on the only unified architecture to span low-cost to ultra high-end FPGA families. Leveraging next-generation ISE Design Suite, development times speed up, while protecting your IP investment. Innovate without compromise.
LEARN MORE AT https://www.wendangku.net/doc/a618768319.html, / 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.

programmer’s pointers
The linker places the compiled definition for the ?bonacci object among the other global objects in the program, not at 0x7FF00. I call this technique default-placement. Using default-placement let me measure the performance of linker-placement without actually using linker-placement. On the one compiler that I actually tested linker-placement, default-placement did indeed produce the same run times as linker-placement. COMPUTING RUN TIMES All of the test programs have a main function that repeatedly calls the Fibonacci device’s get function, and counts the number of calls it makes in 15 seconds. The C version of main for a polystate implementation appears in Listing 3. The C++ version (not shown) is nearly identical; it uses the C++ member function notation for calls to the timer and Fibonacci functions. The test program generates no output. I used a debugger to examine the value of iterations when the program terminated. The final value of iterations indicates the relative speed of the call to the Fibonacci get function: faster implementations of the get function yielded more iterations, while slower implementations yielded fewer iterations. I thought the results would be easier to read if I convert-
Listing 3 The main function in a C version of the test program (for a polystate implementation).
int main() { unsigned seconds = 0; unsigned iterations = 0; unsigned value; timer_counter prior = timer_counts_per_second; fibonacci_enable(fibonacci); timer_disable(timer); timer_set(timer, prior); timer_enable(timer); while (seconds < 15) { timer_counter next = timer_get(timer); if (next > prior) ++seconds; prior = next; fibonacci_get(fibonacci, &value); ++iterations; } return 0; }
Function call times in nanoseconds using Compiler 2000.
Language
C++ C++ C++ C++ C++ C++ C++ C++ C C C C C C C++ C++ C++ C++ C++ C++ C++ C C C C C C++ C
Table 1
Design
Function Function implementation Placement Scope call time
inline inline inline inline inline inline inline inline inline inline inline inline inline inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline default default default default pointer pointer reference reference default default default default pointer pointer linker linker pointer pointer reference reference default default default pointer pointer default default default global global global local global local global local global global global local global local global local global local global local global global local global local global global global 865 865 865 865 865 865 865 865 865 865 865 865 865 865 1349 1349 1349 1349 1349 1349 1429 1469 1469 1469 1469 1548 1570 1690
monostate (bundled) monostate (unbundled) polystate polystate polystate polystate polystate polystate monostate (bundled) monostate (unbundled) polystate polystate polystate polystate polystate polystate polystate polystate polystate polystate monostate (bundled) polystate polystate polystate polystate monostate (bundled) monostate (unbundled) monostate (unbundled)
14
DECEMBER 2010 | embedded systems design | https://www.wendangku.net/doc/a618768319.html,

? Where can I ?nd the next generation Intel? Atom? E6xx based scalable platforms? ? ? ?smroftalp elbalacs desab xx6E motA letnI ? ?smroftalp elbalacs desab xx6E motA letnI ? ?smroftalp elbalacs desab xx6E motA letnI ? ?smroftalp elbalacs desab xx6E motA letnI ? ?smroftalp elbalacs desab xx6E motA letnI ? ?smroftalp elbalacs desab xx6E ?motA ?letnI noitareneg txen eht dn? I nac erehW ? noitareneg txen eht dn? I nac erehW ? noitareneg txen eht dn? I nac erehW ? noitareneg txen eht dn? I nac erehW ? noitareneg txen eht dn? I nac erehW ? noitareneg txen eht dn? I nac erehW ?
Kontron brings the next generation Atom? E6xx processor to market on high performing, embedded platforms for use in extended temperature ranges of - 40 °C to +85°C.
? The next generation Atom? is a cost effective building block for future designs ? Open standard interfaces deliver unprecedented levels of I/O flexibility ? Extended graphics capabilities and low power enhance technologies like streaming video, video displays and audio ? Increased software services including consultation, design, porting and validation
INTEL? ATOM? E6XX BASED SCALABLE PLATFORMS
HMI TR
EN 50155 Compliant HMI
nanoETXexpress-TT
Computer - On - Module
? Fanless and rugged design ? Upgradable and scalable
? Ready for use in harsh environments ? Optimized integrated resources ? Simplified expansion options
CRITICAL QUESTIONS ... ANSWERED
Call, Email or Visit today. Call: 1-888 -294-4558 Email: info@https://www.wendangku.net/doc/a618768319.html, Visit: https://www.wendangku.net/doc/a618768319.html, / NextGen
If it’s embedded, it’s Kontron.

programmer’s pointers
Function call times in nanoseconds using Compiler 2004.
Language
C++ C++ C++ C++ C++ C++ C++ C++ C++ C++ C++ C C C C C C C C C C C++ C++ C++ C++ C++ C++ C++ C++ C++ C++ C++ C C C C C C C C C++ C++ C C
Table 2
Function call times in nanoseconds using Compiler 2010.
Language
C++ C++ C++ C++ C++ C++ C++ C++ C++ C++ C++ C++ C C C C C C C C C C C++ C++ C++ C++ C++ C++ C++ C++ C++ C++ C++ C C C C C C C C C C++ C
Table 3
Design
Function Function implementation Placement Scope call time
inline inline inline inline inline inline inline inline inline inline inline inline inline inline inline inline inline inline inline inline inline inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline default linker default linker default default linker linker pointer pointer reference default linker default linker default default linker linker pointer pointer reference pointer pointer reference default linker linker linker linker linker reference pointer pointer default linker default default linker linker default linker default linker global global global global global local global local global local local global global global global global local global local global local global global local local global global global local global local global global local global global global local global local global global global global 863 863 863 863 863 863 863 863 863 863 863 863 863 863 863 863 863 863 863 863 863 1005 1529 1529 1529 1551 1551 1551 1551 1551 1551 1551 1649 1649 1669 1669 1670 1670 1670 1670 1689 1689 2012 2012
Design
Function Function implementation Placement Scope call time
inline inline inline inline inline inline inline inline inline inline inline inline inline inline inline inline inline inline inline inline inline inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline non-inline at default at default at at default default pointer pointer reference reference at default at default at at default default pointer pointer at at linker linker pointer pointer reference at at default reference at at default default pointer pointer at at default default default global global global global global local global local global local global local global global global global global local global local global local global local global local global local local global global global global global local global local global local global global global global global 862 862 862 862 862 862 862 862 862 862 862 862 862 862 862 862 862 862 862 862 862 862 1348 1348 1348 1348 1348 1348 1348 1409 1409 1427 1427 1469 1469 1469 1469 1469 1469 1529 1529 1551 1569 1951
monostate (bundled) monostate (bundled) monostate (unbundled) monostate (unbundled) polystate polystate polystate polystate polystate polystate polystate monostate (bundled) monostate (bundled) monostate (unbundled) monostate (unbundled) polystate polystate polystate polystate polystate polystate polystate polystate polystate polystate monostate (bundled) monostate (bundled) polystate polystate polystate polystate polystate polystate polystate monostate (bundled) monostate (bundled) polystate polystate polystate polystate monostate (unbundled) monostate (unbundled) monostate (unbundled) monostate (unbundled)
monostate (bundled) monostate (bundled) monostate (unbundled) monostate (unbundled) polystate polystate polystate polystate polystate polystate polystate polystate monostate (bundled) monostate (bundled) monostate (unbundled) monostate (unbundled) polystate polystate polystate polystate polystate polystate polystate polystate polystate polystate polystate polystate polystate monostate (bundled) monostate (unbundled) monostate (bundled) polystate polystate polystate polystate polystate polystate polystate monostate (bundled) monostate (unbundled) monostate (bundled) monostate (unbundled) monostate (unbundled)
ed the number of iterations into the actual execution time of the function call. The time for each iteration is simply the elapsed time for all the iterations (15 seconds) divided by the number of iterations. But that time, which I’ll call Te, includes the time for loop overhead (the increments, compares and branches) as well as the function call. I wanted the time for just the function call. I simply commented out the function call and ran the test again. (I did check that commenting out the function call removed only the instructions for the call.) I used that iteration count to compute To, the execution time for one iteration without the call. The execution time for each call, Tf, is then simply Te – To.
16
DECEMBER 2010 | embedded systems design | https://www.wendangku.net/doc/a618768319.html,
THE ENVELOPE, PLEASE Tables 1 through 3 show the results I obtained running my tests with each of the three compilers. The results in each table are sorted from fastest to slowest, with bands of shading to highlight tests with the same run times. The tables have unequal length because some compilers support more testable features than others. For example, Compiler 2004 was the only one that I could figure out how to test linker-placement. Only Compiler 2010 has a syntax for atplacement. The tables have a column labeled “scope.” For monostate implementations, the scope is always global. For polystate implementations, the scope indicates whether the placement dec-

IS IT THE HARDWARE OR THE SOFTWARE?
FIND OUT BEFORE YOUR PRODUCT SHIPS.
In-System Diagnostics
In-System Diagnostics Kozio provides a packaged solution for hardware validation and circuit board test to leading edge customers across the globe. Our tools are constructed from a library of over a million lines of proven diagnostic code that has been run thousands of times, on hundreds of designs throughout the whole product life cycle. Comprehensive hardware design validations are performed in minutes, not weeks, accelerating time-to-market with reduced risk and better allocation of engineering resources. Whether your application is in Engineering, Manufacturing, or In-Field test, Kozio is the trusted leader in In-System Diagnostics. For more information go to https://www.wendangku.net/doc/a618768319.html, or call us at +1.303.776.1356. Supporting OMAP, Sitara, QorIQ,PowerQUICC, and PowerPC ?
Fastest path to reliable hardware
?2010 Kozio, Inc. All Rights Reserved. Kozio is a registered trademark of Kozio, Inc.

programmer’s pointers
laration is at the global scope (outside main) or local scope (within main). For example, the main function for a C polystate implementation using local pointer-placement would look in part like:
int main() { fibonacci_registers *const fibonacci = (fibonacci_registers *)0x7FF00; ~~~ }
SO WHAT HAVE WE LEARNED TODAY? It appears that using inline functions does more than anything to improve the performance of memory-mapped accesses. With each compiler, every inline implementation outperformed every non-inline implementation. In fact, with the exception of one slightly unusual case in Table 2 (the C++ polystate implementation using reference-placement at global scope), inlining erased every other factor from consideration. Among the non-inline implementations, three things strike me as significant. One is that, in general, the best non-inline polystate implementations outperform the best non-inline monostate implementations. This is the case for all three compilers. I believe this is because the ARM architecture loves
base+offset addressing, which the polystate implementations leverage effectively. Secondly, the non-inline unbundled monostate implementations with linker-placement (or default-placement) have the worst performance of all, and the C implementation is worse than the C++ implementation. Again, this is true for every compiler. By shifting knowledge of the data layout from the compiler to the linker, this approach robs the compiler of useful information it might use to improve code quality. The third and possibly the most striking observation is that, except for the non-inline unbundled monostate in C++, every non-inline C++ implementation outperformed every non-inline C implementation. Once again, this was true for every compiler, regardless of its age. I gotta say, this last one surprised me. I expected the C code to be clearly better in the oldest compiler and for the gap between C and C++ to disappear with the newer ones. I didn’t expect the non-inline C++ to be better than the non-inline C across the board. As I cautioned earlier, we shouldn’t put too much stock in measurements made using just one architecture, albeit a popular one. No doubt there are things we could do to improve these measurements. But I think I’ve done my part to lift the discussion above speculation and anecdotes. To those who maintain that C++ polystate implementations are too costly to use: the ball’s now in your court. ■ ACKNOWLEDGEMENTS Thanks to Greg Davis, Bill Gatliff, and Nigel Jones for their valuable feedback. ENDNOTES:
Announcing SMX v4
?
It’s a new day at Micro Digital
? New API ? Kernel Improvements ? smxBase Foundation Module ? Codebase Cleanup & Simpli?cation ? Same Reliable Engine ? Central Middleware Porting Layer ? Multitasking Kernel, File Systems, GUI, Networking, USB, WiFi ? ARM, Cortex, Cold?re, PowerPC, X86 ? Royalty-Free, Full Source Code
35th ANNIVERSARY
https://www.wendangku.net/doc/a618768319.html,/v4
18
DECEMBER 2010 | embedded systems design | https://www.wendangku.net/doc/a618768319.html,
1. Saks, Dan. “Alternative models for memory-mapped devices,” Embedded Systems Design, May 2010, p. 9. https://www.wendangku.net/doc/a618768319.html,/columns/224700534. 2. Saks, Dan. “Memory-mapped devices as C++ classes,” https://www.wendangku.net/doc/a618768319.html,, June 2010. https://www.wendangku.net/doc/a618768319.html,/discussion/other/ 4200572/Memory-mapped-devices-as-C— classes. 3. Saks, Dan. “Compared to what?” https://www.wendangku.net/doc/a618768319.html,, August 2010. https://www.wendangku.net/doc/a618768319.html,/ discussion/other/4205983/Compared-towhat. 4. Saks, Dan. “Accessing memory-mapped classes directly.” Embedded Systems Design, September 2010, p. 9. https://www.wendangku.net/doc/a618768319.html,/ discussion/programming-pointers/ 4208573/Accessing-memory-mappedclasses. 5. Saks, Dan. “Bundled vs. unbundled monostate classes.” https://www.wendangku.net/doc/a618768319.html,, November 12, 2010. https://www.wendangku.net/doc/a618768319.html,/ discussion/other/4210702/Bundledunbundled-monostate-classes.