Embedded Muse 87 Copyright 2003 TGG October 30, 2003

You may redistribute this newsletter for noncommercial purposes. For commercial use contact jack@ganssle.com.

EDITOR: Jack Ganssle, jack@ganssle.com

CONTENTS:
- Editor’s Notes
- Toolchains Aren’t Forever
- Salaries
- Jobs
- Joke for the Week
- About The Embedded Muse

Editor’s Notes

I’ll present my Better Firmware Faster seminar December 5 in San Jose, CA. See https://www.ganssle.com/classes.htm for more details. This is the only non-vendor class around that shows practical, hard-hitting ways to get your products out much faster with fewer bugs.

There’s also cheap fly-in options listed on the web site for folks coming from out-of-town.

I often do this seminar on-site, for companies with a dozen or more embedded folks who’d like to learn more efficient ways to build firmware. See https://www.ganssle.com/onsite.htm.

Need to build a great watchdog timer? Most WDTs are afterthoughts that aren’t too likely to save a crashed system. Check out the paper “Great Watchdogs” at https://www.ganssle.com. And thanks to so many of you who contributed ideas and thoughts on this subject.

One of the reasons for the success of Apple’s Mac and for the fanatical devotion of its users is the common user interface. Every program works pretty much as you’d expect, regardless of vendor. That’s partly because of Apple’s insistence on a standardized user interface. Now Unix has something similar. Eric Steven Raymond has published a book-length piece called “The Art of Unix Programming”. It’s a delightful set of rules and observations about developing Unix code.

One quote: “To do the Unix philosophy right, you have to be loyal to excellence. You have to believe that software design is a craft worth all the intelligence, creativity, and passion you can muster. Otherwise you won't look past the easy, stereotyped ways of approaching design and implementation; you'll rush into coding when you should be thinking. You'll carelessly complicate when you should be relentlessly simplifying — and then you'll wonder why your code bloats and debugging is so hard.”

Much wisdom there, indeed. Even if you’re not a Unix developer, check it out at http://catb.org/~esr/writings/taoup/html/.

Toolchains Aren’t Forever

Embedded systems have incredibly long lives. Some stay in service for decades. How do we maintain these devices for such a long time? Bob Dowling wrote with some questions on this; it’s an interesting and troublesome problem.

The second issue is way one uses the development language. Plan on the compiler vendor going out of business, and the CDs you’ve stuck in the safe no longer running on Windows 2013. (Of course, no one will be able to read a CD in 2013, just as we can’t read 8” floppies today.) The new compiler you buy won’t know about language extensions supported by the defunct one. So write your code using plain vanilla ANSI-standard constructs. Obey warnings from the compiler and Lint.

Leave the code and all development scripts in an active version control system. The VCS database gets moved from server to server over the years, but stays viable. Any offline media (DVD, CD, tape, floppy) becomes obsolete too rapidly.

Another, tricky, problem is preserving the development tools themselves. I know lots of companies that put the entire development system – PC, emulators, ROM burners – into a locked closet, ready for use when a software change is needed. That works over the short term, but electronic products do go bad with age. Capacitors leak, magnetic memory decays, and insulation rots. It’s naļve to expect a complex electronic device to work when resurrected years later.

We can assume that future maintenance people will replace the development computer from time to time. The PC of tomorrow will run at 80 zillion gigaweeniehertz, and use optical cube memory blogs, but will hopefully offer enough backwards compatibility so it’s possible to port the code. But emulators and the other hardware tools we use may go out of existence. How will the future-person download and test code in the target system?

Perhaps this suggests that even if you use an emulator or other complex tool it’s important to also have a dead-simple debug port, like a ROM monitor or BDM/JTAG interface.

What do you think?

Salaries

Software Development magazine has just released the results of their latest salary survey. It’s online at:
http://www.sdmagazine.com/documents/s=8939/sdm0311a/sdm0311a.html?temp=RdNwy-oCyH

The percentage of respondents who claimed to be in the embedded world continues to decline for the third year in a row. This may be due to the magazine’s demographics… or perhaps to more outsourcing of development. Almost 11% of respondents are looking for work because their job was outsourced, the first year this factor has been even measurable. Only half as many managers are losing their jobs for this reason.

29% report losing their jobs because of corporate downsizing. Yikes.

Salaries haven’t changed much in the last year (d’oh, you say, looking at your pay stub). Median and mean salaries for non-managers remains at $77k and $79k respectively. The lowest 25% average $64k compared to $92k for the highest quartile.

Staff bonuses run about $5k… but few of the embedded folks I talk to report much in the way of a bonus.

Indicative of the abysmal state of the market, only 36% have been contacted by headhunters in 2003, compared to 69% in 2000. Jobs are scarce.

The industry remains battered with few openings reported.

Jobs

Joke for the Week

Is Microsoft releasing a version of Linux? Check out http://www.mslinux.org/ for some laughs. A notable quote: “MS Linux is released under the provisions of the Gates Private License, which means you can freely use this Software on a single machine without warranty after having paid the purchase price and annual renewal fees.”

But be careful clicking around the site; links to latesky.net aggressively pop up undesirable windows.