Archive for the ‘Uncategorized’ Category

How to Set the Size of your C Stack

Wednesday, March 24th, 2010 Michael Barr

A reader of my monthly Firmware Update newsletter recently sent an e-mail to ask:

I am a firmware engineer. I read your recent blog post regarding the C stack, about which I have two questions: First, how can I increment or decrement the size of the stack in my code? Second, what size should I choose?

Here’s what I told him:

The size of the stack is set either in the linker command file or in the C or C++ startup code. You should be able to learn more about how to change the stack size from your specific compiler vendor’s manual or customer support.

Identifying the minimum stack size required for your specific application is made challenging by these stubborn facts:

- MEASURING the maximum stack growth during testing may not be sufficient. If you test for half a year, the product is sure to be run for a year or longer in the field. Have you really tested all possible cases? What about all possible series of interrupt service routines on top of that worst case use by main()?

- TOP DOWN ANALYSIS of the compiled code can be done to determine the number of function calls and interrupt service routines at maximum depth; their individual parameter and local variable use, etc. Unfortunately, these things may keep changing whenever you change the code and recompile.

The best approach is usually to perform a conservative top down analysis of the source code; when in doubt, always round up. Don’t forget about nested interrupt service routines. Double that conservative to set your initial stack budget. Then measure actual stack utilization during testing, preferably with code coverage analysis tools running–to ensure that you’ve tested all possible paths (except interrupts, which may run at different times in the field).

Then if you need to reclaim memory to ship the product, start shrinking the stack. But also put into place a high water mark system (e.g., 0xDEADBEEF) complete with supervisor code to put the product into a failsafe state if more than, for example, 80% of the stack is ever used.

Toyota’s Embedded Software Image Problem

Friday, March 19th, 2010 Michael Barr

It remains unclear whether Toyota’s higher-than-industry-average number of complaints regarding sudden unintended acceleration (SUA) is caused (in whole or in part) by an embedded software problem. But whether it is or it isn’t actually firmware, the company has clearly denied it and yet still developed an embedded software “image problem”. They’ve brought some of this on themselves.

Side Note: I think it is a net positive that journalists, the mass media, and a broader swath of the general public are increasingly aware that there is software embedded inside cars, airplanes, medical devices, and just about everything else with a power supply or batteries. Firmware has been inside these products for many years, of course. But as I wrote in a recent article in Electronic Design, my experience working with companies across many industries lead me to believe there is a looming firmware quality crisis. Greater public awareness is sure to bring litigation. This will force engineering management to care more about firmware quality than they currently do.

Toyota’s Firmware Image Problem

Long before the “floor-mat recall” NHTSA had logged a higher number of unintended acceleration complaints (4.51 complaints per 100,000 cars sold for the 2005 to 2010 model years) for Toyota than any other company. (A recent Washington Post graphic has more data.) Apparently, NHTSA and Toyota were investigating the reports–but hadn’t yet taken any action.

It seems that what set that first Toyota recall in motion was a high-profile fatal August 2009 crash involving an off-duty California Highway Patrol office, his family, a runaway Lexus, and a disturbing 911 call,  Given the context of that specific crash, I’m not convinced the floor mat recall made much sense. In particular, I find it hard to believe that a police officer with adrenaline pumping through his veins and his family’s life on the line, wouldn’t just rip a stuck floor mat out of the way like the Incredible Hulk. (Or that he would choose running off the road at 125 mph vs. shutting the vehicle off entirely.)  But I don’t have all the facts about either that specific accident or the reasoning behind the floor mat recall.

The broader recalls that have happened since have focused on also adding mechanical strength to the accelerator pedals in a number of different makes and models. To this day, Toyota categorically denies any sort of electrical problem.  Yet some cars that have been modified in this way have since been reported to experience unintended acceleration!  Besides which, mechanical parts generally fail visibly or entirely once they first fail–rather than intermittently.  Intermittent failures are far more common with electronics (think EMI) and firmware.

Toyota’s firmware image problem stems from two things:  First, they have separately recalled the Prius for a braking-related firmware upgrade.  Other possible Prius software issues have been identified by Steve Wozniak and Jim Sikes, but these have not yet been confirmed.  Additionally, the continued reliance (by Toyota and NHTSA) on theories such as “we can’t reproduce the problem and we haven’t been able to see it during testing” as proof that there’s not a software bug is simply unbelievable.  

Anyone who works with software knows from experience that lots of bugs can’t be easily reproduced.  The fact that these incidents can’t be reproduced is not a proof of anything.

Software in Cars: The Future

Don’t get me wrong.  I want more software in my car not less.  I very much look forward to the day that an in-car computer takes over the driving for me.  After all, some cars already have more sensor data to make decisions on than the driver does.  Imagine what a car with an integrated GPS navigation system, auto-follow cruise control, and collision avoidance systems could do.  While I guess that I should move left one lane to avoid a crash, the computer is capable of seeing in all directions at once, calculating all of the trajectories of near-by cars, including instantaneous changes in their acceleration or deceleration.

Additionally, I suspect that even with bugs in a car’s drive-by-wire software the car may be much safer overall for its electronic traction control and anti-lock braking systems.

I just wish that Toyota would own up to the fact that the inability to reproduce a problem doesn’t rule out a software (or EMI) flaw.

Embedded Gurus – Site Redesign

Tuesday, March 2nd, 2010 Michael Barr

I am pleased to announce that the EmbeddedGurus website has been redesigned. Among the new features of the site are:

1. A dynamically updating home page, featuring the most recent posts from all of our bloggers. If you prefer, you may view these posts by category.

2. A common look and feel to all of the individual blogs.

3. The ability to search individual blogs, as well as to easily browse from one post to the next and via tags and categories.

4. A sixth guru named Gary Stringham with a blog called Embedded Bridge.

A number of other minor improvements have also been made.

We hope you like the new look and continue to find our blogs about embedded systems design both readable and informative.

Resume Inflation

Wednesday, January 14th, 2009 Michael Barr

Like many companies, Netrino is perpetually interviewing candidates for software engineering positions. However, since our work is primarily in the area of embedded systems design we tend to meet many software candidates who come originally from electrical engineering backgrounds. Among this group of candidates there is a prevalent bias toward a kind of resume inflation, in the technical skills section.

Almost all of the resumes we receive for firmware engineering positions contain one of the strings “C, C++” or “C/C++” at or near the front of a longer list of programming language skills (e.g., “C/C++, Fortran, Assembly (various), Forth”). C is generally at the front of that language list for good reason–because it is the one programming language with which the candidate has the most hands-on experience. Too often, though, our interviews have revealed that C++ is listed second for no good reason.

C and C++ are fundamentally different languages. Many of these “resume inflation” job candidates don’t even realize that C++ is as different as it is from C. Often, their actual experience with C++ turns out to be that they’ve used C++ compilers to build C programs. And when they really have used C++, their practical experience usually ends at the use of classes.

Object-oriented C++ has three important aspects: encapsulation, inheritance, and polymorphism. Mere use of encapsulation is insufficient to claim you have C++ programming skills. When we include C++ in a job listing it is because the work may involve the use of every part of C++. To get the job, you must be knowledgeable in all of C++.

What can you do if you are submitting your resume and know some C++ rather than a lot? Be clear and humble. If you merely worked with C++ in school or on a single project, list it in a separate section. Or put C++ apart from C in your language list.

Interviewers (as well as resume reviewers) are impressed by modesty and clear communication.

Windows Embedded Compact

Sunday, April 27th, 2008 Michael Barr

From a recent entry in VDC’s blog:

In an effort to remove any confusion around its embedded offerings, Microsoft has reorganized and rebranded its Windows Embedded product family. Going forward, new editions of Windows XP Embedded will be titled Windows Embedded Standard, Windows Embedded CE will be titled Windows Embedded Compact, and restricted licenses of Windows Vista and Windows XP will be offered through the Windows Embedded Enterprise group. In addition, new products specific to certain device categories, including the next generation of Windows Embedded for Point of Service, will be offered through the Windows Embedded Ready division.

Sure, that’s less confusing!