Schedule slips

To read original PDF of the print article, click here.


Internet Appliance Design

Also in this issue:

Schedule Slips

Michael Barr

Have you ever had one of those days where nothing seems to go your way? Well, with regard to my own UDP/IP development work, I've just had “one of those months.” By now, I had hoped to have a pretty solid body of code to share with you, including the protocol stack and some client and server application software. I hadn't expected to be done with the development altogether, and I'm far from being done describing the code to you, but I had at least hoped to have my stack up and running on the µC/OS-II operating system, with a fake network driver passing the UDP/IP packets back and forth in local RAM.

In fact, I was actually quite close to achieving that milestone prior to writing last month's column. However, in the time since, I've had absolutely zero chance for any further development. Admittedly, part of the problem was that I was on the road for two weeks of the four and tried to take some vacation during a third. But even when I did find time to sit down at my computer to program, my efforts were thwarted. Reflecting on my difficulties has led me to some broader concerns.

Progress?
How have we allowed ourselves to become so dependent on a technology that is so unreliable? The technology of which I write is, of course, the personal computer. And by that I mean not only Wintels, but also Macs and even Unix workstations. They're all built on the same hardware these days anyway.

Now don't get me wrong, I understand that a modern computer is a terribly complex and wonderfully adaptable system, whose hardware and software requirements are primarily driven by dollars and cents. But maintaining one of these things can be a nightmare and a substantial hidden cost of ownership.

Try as I might to avoid installing new software unless absolutely necessary; run the most reliable operating systems (my three machines run a combination of Windows 2000 and Linux), backup religiously; scan every new file for viruses; and never, ever fiddle with PC hardware (all rules adopted after painful experiences with the alternatives), it's a good week when something major doesn't go wrong on my network.

This week it was a hard disk failure that kept me from my work. The drive that failed was only about one and a half years old, as is the machine in which it was installed. Of course, I let this machine (my primary development platform and “gateway to the Internet”) run 24 hours a day, 365 days a year. But the machine is plugged into a UPS that regulates the quality of the power signal and is only shut down and restarted about three or four times a month. Is 13,000 hours of life the best this hard disk manufacturer (a big one) can do? Of the eight or nine drives I've owned personally over the years, three have failed, two of them before their warranties had expired!

Remember the first color TV you or your family owned and how it lasted for 20 years before you bought a second? Now we go through TVs as if they were candy bars. We go through PCs at a similar rate, both at home and at work. Sure, more of us than ever have these gadgets. But are we really making progress?

A major flaw of our current social system is that we measure our overall success and progress by an increase in the total amount of stuff produced per year (if I were writing for The Economist, I'd simply say GDP). But are we really better off individually or as a society with a new TV, PC, PDA, cell phone, car, house, (and spouse?) every 3-5 years, especially if the replaced items are, by then, broken or of little use to others?

Upgrade cycles
The most serious problem on the horizon is that more and more products look like computers on the inside. Of course, this is great news for our industry; embedded software developers should have no shortage of job oppotunities. The problem, though, is the price we'll pay as a society if every one of those embedded computers isn't built to be reliable and long lasting. I bet every ESP reader could tell a story or two about a product within their company that was doomed to failure from the start. In particular, projects not given enough time, money, or engineers to do the job right are likely to develop products that look great in the store but won't last long in the hands of an actual user.

Embedded systems designers have traditionally been conservative in their technology choices. As a group, we tend to choose proven processors (with multiple sources only, please) over new ones, the same programming languages over and over again, internally developed operating systems, and so on. We are slow to incorporate the latest and greatest the research community has to offer. And that is a good thing.

When I look around my office and my home I do see some products that are built around microprocessors yet remain reliable. I count among these: a 10 BaseT network hub, a fax machine, a stereo receiver (the tape drive and CD player bought at the same time are long since dead), an alarm clock, and a bread machine. All of these products have been with me for as long as I can remember and show no signs of aging.

What sets these products apart is their specificity of purpose and simplicity of design. Each of them does one thing and does it very well. Where mechanical components are required (in the fax and bread machines, in particular), it is clear even to a casual observer that the designs have been optimized for decades of heavy use. In all of these products, a minimum number of components are used. Only what is needed is there. There is none of the “upgradeable this,” “replaceable that,” and “updateable firmware” that is becoming all too common with all sorts of products these days.

As an engineer, I tend to be particularly skeptical of products whose firmware can be upgraded. Perhaps I've just worked at one too many companies where the attitude (of both managers and developers) has been: since we can upgrade the firmware after we ship, we don't have to get the product completely working before we start manufacturing. That attitude, combined with pressure to get products out the door before some other company beats you to it, is a recipe for disaster (or a lawsuit).

I don't want to upgrade my alarm clock, I just want it to tell me the time. Build systems that work and people will buy them, use them, and love them. Build systems that are updatable, yet unreliable, at your peril.

A new milestone
In the original plan, this month's column was supposed to be about the IP layer of my protocol stack. Unfortunately, some of my UDP/IP code was among the data not recently backed up and has gone to the big bit bucket in the sky. The ARP code, most of which was printed in the magazine, is fine. And the IP code had already been copied to my template for this month's column before the crash, so that's fine too. But I will have to spend some time over the next few weeks getting back to where I was overall.

I'm going to postpone our discussion of IP until I can sit down with my code and make sure that what I'm showing you is reliable. I take that aspect of my work very seriously, and I hope you do too. If all goes well, I'll get to IP next month. In the meantime, try to stay connected.

Michael Barr is the editor-in-chief of Embedded Systems Programming . He holds BS and MS degrees in electrical engineering from the University of Maryland. Prior to joining the magazine, Michael developed embedded software and device drivers. He is also the author of the book Programming Embedded Systems in C and C++ (O'Reilly & Associates). Michael can be reached via e-mail at mbarr @ netrino.com.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.