|
Embedded Muse 160 Copyright 2008 TGG May 9, 2008
You may redistribute this newsletter for noncommercial purposes. For commercial use contact jack@ganssle.com. Subscribe and unsubscribe info is at the end of this email.
EDITOR: Jack Ganssle, jack@ganssle.com
CONTENTS:
- Editor’s Notes
- Firmware - Best Practices
- VDC Survey Results
- Tools and Tips
- More Response to Great Engineers
- Free Stuff
- Jobs!
- Joke for the Week
- About The Embedded Muse
Editor’s Notes
Did you know it IS possible to create accurate schedules? Or that most projects consume 50% of the development time in debug and test, and that it’s not hard to slash that number drastically? Or that we know how to manage the quantitative relationship between complexity and bugs? Learn this and far more at my Better Firmware Faster class, presented at your facility. See https://www.ganssle.com/classes.htm .
Vinzent Hoefler sent along this interesting link about Ada:
http://www.gcn.com/print/27_8/46116-1.html .
Clyde Shappee was working on floating point algorithms and noted how the Patriot Missile failed in the first Gulf war. Some of us still shudder when thinking about this software problem; others haven’t heard of it. A quick summary is here: http://www.ima.umn.edu/~arnold/disasters/patriot.html .
The April issue of IEEE Computer looks at those North American colleges that award doctorial degrees. Only half as many people enrolled in computer science majors in 2007 compared to 2000. Total enrollments slipped 18% in the single year between 2005/6 and 2006/7. That sounds pretty alarming, so I hunted around for more data and came across this NSF site: http://www.nsf.gov/statistics/nsf07307/pdf/nsf07307.pdf . NSF has looked at degrees awarded by all colleges, not just PhD-granting institutions. The data runs from 1966 through 2004, and science & engineering bachelor degrees have represented between 31 and 35% of all degrees awarded in the US. The number was 32% in 2004, which is pretty typical over that nearly 40 year period. Engineering accounted for 5-8% of all bachelors (5% in 2004), while math and computer science varied from 2-6%, hovering around 5% in the 2000s.
The two data sets are by no means matched; not only do they differ in terms of PhD granting institutions, Computer’s data is for all of North America and the NSF’s is just for the US. And NSF lumped math and computer science together.
Which leads to a question I’m often asked: which universities excel in teaching embedded systems development? I’ll publish responses so we can all get some perspective.
*****************************************************************
This Muse issue is sponsored by Gary Stringham & Associates:
Are you having problems integrating hardware and firmware?
Are you wasting $500,000 and three months to respin chips?
Avoid these problems with over 200 proven design practices.
"...your class was incredibly valuable!" Keith Huster, Hill-Rom
http://www.garystringham.com/workshop.shtml
Ask for a free one hour, no-obligation phone consultation.
*****************************************************************
Firmware - Best Practices
In sync with this college theme, Richard Wall recently contacted me about a class he’s developing. His email follows, and I’d like to hear ideas from you folks, and of course will pass them along in the next Muse.
As I come to the end of another semester of teaching microcontrollers, I am faced again with the challenge of attempting to teach students to write quality (in the sense of Robert Pirsig) embedded software. I am looking for the few and the good "best practices" that can result in functional, reliable, and maintainable software based systems. My search has yielded two such lists: "10 Tips Make Embedded-System Code Easy to Maintain" by Timothy Stapko, Digi International, Ecnmag.com - January 01, 2008 and "The Power of 10: Rules for Developing Safety- Critical Code" (http://www.spinroot.com/gerard/pdf/Power_of_Ten.pdf) From my own experience and search on the subject, I have comprised my own list that I can start junior level electrical and computer engineers down the right path. Some of these are borrowed for other lists.
1. Quality Code: How to get there
- Recognize that writing quality software is an acquired disciplined art.
- Writing quality code requires practice, diligence and assessment (outside review).
- Make writing quality code part of your personal process.
- Teach how to write quality code. (I ponder this ling and hard - any ideas?)
- Value quality code. (corporate and individual)
2. Impediments to quality code
- Time pressure
- Lack of training / experience
- Motivation - lack of professionalism or just plain lazy
3. Quality code the implementation
- Well structured
a) Consistency + Neatness
b) Use accepted (mandated) practices
Simple structure
1. Simple instructions
2. One instruction per line
3. Minimal use of macros ( I have a horror story about multi-instruction macros)
4. Effective modularization: Limit LOC per function to one screen of code. Use task portioning and functional encapsulation (I have seen some embedded articles that discourage too many functions because they require both time and memory.)
Clean interfaces
1. Pass minimal data (reduce memory requirements and increase speed)
2. Expose only variables that are necessary: minimal use of global variables (IO port and configuration registers as well as variable use to communicate with ISRs are notable exceptions.)
3. Minimize dependencies confine processor dependent code to specific functions
Functionality
1. Minimize amount of code: less LOC is usually better
2. Test frequently completely, and thoroughly
3. Start simple - add complexity in layers
4. Zero tolerance for errors (no “know bugs” list)
I need a list that is easily implementable, easily enforced, and easily learned. Do you have any suggestions on things to include in my list or sources of such lists to leverage from?
VDC Survey Results
To all the Embedded Muse readers who participated in VDCs 2008 Embedded Systems Engineering Survey, thank you! Although the survey is still open at this point, we wanted to share some of the preliminary results around salary and employment data with you.
You can access this information at:
www.vdc-corp.com/ganssle/salary_data.pdf
The survey will remain open over the rest of this month. We look forward to analyzing the remainder of the data and e-mailing a much more substantial summary of the results of the survey to all of those who participated shortly. Thanks again for your contributions.
If you havent participated in the survey yet, and would like to, it is still available at:
www.vdc-corp.com/08esdt?RID=G
Tools and Tips
Robert Bristow-Johnson sent: “Because division is so expensive in a DSP or a RISC (usually it costs one instruction cycle for each *bit* in your quotient), I have always tried to make polynomial approximations without the need to divide by another expression (another polynomial). I came up with some pretty good results using a MATLAB program I wrote that is an implementation of the Remes Exchange Algorithms for finding coefficients that minimize the maximum weighted error.
“If you want and have time, please review some of the code, it's short and reasonably well commented, I think. in the file __functions.c is the code that has the coefficients for 2^x, log2(x), sqrt(x), sin(pi*x), and so on. It was written for a job I did where they had a floating-point processor, but no standard math lib for C (so they could add, subtract, multiply and divide, but little else). It *is* the case that for arctan(x), I *did* have to divide (the optimized polynomial goes into the denominator), but the rest of the functions needed no divide.
“I have the same functions implemented in DSP code for fixed point, but that code does not belong to me (but to a previous client), so I can't send it to you. But the coefficients are the same, one has to deal with the arithmetic shifting and ranging differently, but once the x value is between 0 and 1 (or between 1 and 2 for log2(x)), it's all the same. I am also including the MATLAB code I use to determine the optimized coefficients. I just hope that exposure to someone else's tweaking might be both interesting and useful to you.”
The code is available here: https://www.ganssle.com/misc/approx.zip
Greg Williams wrote: “Actually, it's been a while since I've used Eclipse for C development. It looks like the current version of Eclipse finally supports C and C++ text formatting and does it pretty well, with help of the CDT (C Development Tools). Therefore, I think that SimpleIndent has worn out it's usefulness. The built-in formatter for C/C++ in Eclipse is pretty full featured and has nice configuration via the Eclipse Preferences
GUI.
“Although, the AStyle formatter may still be good to mention as another option. It's freely available via SourceForge at: http://astyle.sourceforge.net/
“The page does a pretty good overview of it's features. With its command-line interface, it is really easy to patch in to any editor.”
More Response to Great Engineers
Stephen Pelc wrote:
> John Taylor had some good thoughts in response to this from Steve
> Litt in the last Muse:
> I contend that the guru is using a troubleshooting
> process. Sure, it looks to *us* like he sniffs, licks his
> finger and touches a node, and immediately discovers the
> problem, but what he really did was use a process to
> troubleshoot, including sophisticated use of divide and
> conquer. Either that or he's seen the symptom before and
> remembers the corresponding fix.
“The response is good, but ... the topic of debugging really, really pushes a button in me! IMHO, debugging requires two primary comprehensions:
1) Don't let them in
2) When they are there, fixing them is just formal scientific method:
a) Observation
b) Hypothesis
c) Experiment with a yes/no answer
d) Repeat until experiment succeeds
e) Fix
and go round for the next bug. Debugging is a process.
“In this view, debugging consists of two nested loops. How fast you can debug is dependent of how fast you go round the inner loop a to d above.
“I've run classes on this topic for years and years, but it's truly amazing how few people get it. If you cannot observe accurately (John Taylor's point), you can't debug efficiently.
“There are corollaries that we've known for decades, but still don't apply, in particular:
1) Documented code is much easier to maintain. And if write this stuff as part of the implementation, your initial bug level goes way down. We're big fans of literate programmming.
2) Because bugs interact, it is much cheaper to fix the bugs as soon as they are seen than to leave them to the next "ample spare time" moment.
“But then, we're a Forth shop, and the main reason for using an interactive language on the target is for observation. And because our VFX compilers are optimising compilers using the same techniques as most C compilers, we don't have a performance penalty for the interactivity. And we use literate programming.”
Free Stuff
Want to learn about DSP programming? Microchip has generously donated an MPLAB starter kit for the DsPIC digital signal controller. Send us a prediction about what embedded development will be like in 10 years, and one of those entries will be selected at random to get the DsPIC kit.
Contest rules: one winner only, who will be selected at random on or about May 16 from all of the entries. Send your entry to marybeth@ganssle.com . Sorry, we can’t acknowledge entries. I’ll post the winner’s name (but no other contact info) in the next Muse and any funny or interesting commentary.
Newnes is offering a 20% discount till May 31 to Muse readers who want a copy of my new book. See https://www.ganssle.com/misc/adesch1.pdf for the discount code and the book’s first chapter.
Jobs!
Joke for the Week
Steve Bresson has some hints about recognizing engineers.
You might be an engineer if...
Q: What is the definition of a engineer?
A: Someone who solves a problem you didn't know you
had in a way you don't understand
Q: When does a person decide to become a engineer?
A: When he realizes he doesn't have the charisma to
be an undertaker.
Q: What do engineers use for birth control?
A: Their personalities
Q: How can you tell an extroverted engineer?
A: When he talks to you, he looks at your shoes
instead of his own
Q: Why did the engineer cross the road?
A: Because they looked in the file and that's what
they did last year
Q: How do you drive a engineer completely insane?
A: Tie him to a chair, stand in front of him, and fold
up a road map the wrong way
You might be an engineer if:
Choosing to buy flowers for your girlfriend or upgrading your RAM is a moral dilemma.
You take a cruise so you can go on a personal tour of the engine room.
In college you thought Spring Break was metal fatigue failure.
The sales people at the local computer store can't answer any of your questions.
You can quote scenes from any Monty Python movie.
You can type 70 words per minute but can't read your own handwriting.
You look forward to Christmas so you can put the kids' toys together.
You see a good design and still have to change it.
You spent more on your calculator than you did on your wedding ring.
You still own a slide rule and know how to use it.
You think that people yawning around you are sleep deprived.
Your wife hasn't the foggiest idea of what you do at work.