Want a 64 channel, 1 GHz logic analyzer? Take the salary survey and you'll be entered into a drawing to win one at the end of February, 2018.
Embedded Muse 66 Copyright 2001 TGG October 1, 2001
You may redistribute this newsletter for noncommercial purposes. For commercial use contact email@example.com.
EDITOR: Jack Ganssle, firstname.lastname@example.org
- A Dirty Word
- Very Cool Animation
- Embedded Seminars, updated
- Thought for the Week
- About The Embedded Muse
A Dirty Word
Yet another email arrived from a frustrated developer last week about how their project schedule collapsed, leading to the abandonment of the project and the likely firing of a few people.
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 insure 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.
The problem, of course, is that firmware development necessarily lags the hardware. How can we do real testing till the hardware is ready? That will be late (it always is), so our testing is even later.
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!
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
Check out http://www.ucos-ii.com for Jean LaBrosse’s awesome new Flash animation of how context switching works in an x86-based RTOS. Fancy graphics have finally come to the embedded world!
Embedded Seminars in Chicago and San Jose
I’ll present the seminar "The Best Ideas for Developing Better Firmware Faster” in Chicago on October 23 and San Jose on October 25.
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.
For more information check out http://www.ganssle.com or email email@example.com.
Can’t travel? A lot of folks have asked me to bring this seminar to their company. Email me at firstname.lastname@example.org if you’re interested.
Thought for the Week
NOTE: Failure is not an option!
It comes bundled with the software…