Embedded Muse 66 Copyright 2001 TGG October 1, 2001

EDITOR: Jack Ganssle, jack@ganssle.com

CONTENTS:
- A Dirty Word
- Very Cool Animation
- Embedded Seminars, updated
- Thought for the Week
- About The Embedded Muse

A Dirty Word

A recent survey showed that 17% of all embedded projects are cancelled, always after months of work and accompanying schedule slippages.

Disaster comes from a number of sources. One that’s all too common is deferring test till lots of the system is built. It’s easy and exciting to crank code, lots and lots of it. Maybe we do some unit testing to ensure functions work as expected.

But too many schedules and project plans include a dirty word, one whose use is a sure indicator of problems. “Integration” is the word, and it’s worse than any four letter expletive. For when our schedules contain this as a milestone we’re doomed.

“Integration” is when we combine parts of the system for the first time (perhaps the hardware and the software), and is nearly always a disaster. It’s when the hard part starts. It’s the first time we really see how badly things are going. Prior to this point it’s pretty easy to convince ourselves that the project is on-schedule and all is well. At “integration” time, though, for the first time we’re engaged in the very difficult part of making everything work together.

I always advise developers to find a way to start testing the system – as a system – as early as possible. Don’t defer system-wide tests till some arbitrary “integration” point late in the schedule.

Remember that engineering is not so much about building projects as it is about solving problems. We KNOW the hardware will be late; even it it’s not, it’s never early enough in the cycle to allow is to start “integration” up front. So, before writing code, before finalizing the schedule, recognize that you’ll need a decent test platform and find a way to get one. Early.

Clearly, there are some systems that simply must have an integration phase. If you build F-16 avionics it’s awfully hard for each developer to have their own F-16… though it sure would be cool!

Some ideas:
1) Buy an evaluation board from the CPU vendor. These always have at least a minimal development system. You can write code, download, and test it. In many cases you can test and awful lot of the system without your unique product’s I/O.
2) Use a simulator. Some of these have gotten really good. I was running one for a 68HC11 recently that was breathtaking. Sure, you can’t simulate real time events, but it’s at least possible to test quite a bit of the system.
3) Cross develop on a PC. Write your code in a totally ANSI-compliant manner so it can run on the desktop environment. One friend enables compile-time switches to use the PC’s I/O (timers, serial, etc) in place of those in the embedded system. Again, much testing is possible, without a shred of target hardware ready.
4) Insist, while creating the schedule (long before problems surface) that the hardware group provide prototypes of risky I/O or other portions of the product. Maybe these are nothing more than wire-wrapped boards that plug into the PC’s parallel or serial port.

The moral is to test early and often.

A Very Cool Animation

Embedded Seminars in Chicago and San Jose

You’ll learn how to build embedded systems FASTER and CHEAPER with FEWER BUGS. Though this economic downturn hasn’t hit too many engineers – yet – I’m worried that unless we adopt ways to be more efficient this could change.

If you’re interested reserve early as these seminars fill completely.

With travel now more difficult feel free to contact us for hotel information in either city. I’ll also host a dinner the evening before each seminar for people coming in from out of town. Again, please reserve early, and let me know if you’re traveling.

Can’t travel? A lot of folks have asked me to bring this seminar to their company. Email me at jack@ganssle.com if you’re interested.

Thought for the Week

It comes bundled with the software…