Long Live Hardware - Embedded.com

Long Live Hardware

Like most other articles in Embedded Systems Programming, Jim Turley's column, “The Death of Hardware Engineering,” (March 2002, p. 53) was thought-provoking.

I am an analog/RF chip designer and only read about computer programming and digital design as a hobby. A few months ago, I asked one of my colleagues, who is a digital designer, to tell me what was new in the world of digital design, because all the material I have read recently originated in the '60s and '70s. She told me that the only new thing in the digital world is the complexity of the systems and their speed. I think Turley's column shows a more significant new trend: hardware and software co-development using tools like Handel-C or System-C.

However, Turley may have overlooked a recent trend in the world of programming itself. There are signs that language-based programming is being replaced by flow-chart-based programming. These flow-chart programming methods result in programs that look more and more like circuits. This enables the designer to better visualize the whole program instead of being bogged down by the order of elses and ifs. Furthermore, this type of programming lends itself easily to parallel processing.

Perhaps the software engineering work of the future will look like today's digital design. On the other hand, as the column suggests, the hardware engineer's work is looking more and more like that of the software engineer too.

Babak Sehari

Message from Mars

I enjoyed reading David Kalinsky and Michael Barr's Beginner's Corner article on priority inversion in the April 2002 issue (p. 55). Unfortunately, your information on the Pathfinder priority inversion bug is factually incorrect. I know because I wrote the software involved.

There is some misinformation on the subject that has been propagated on the Internet. The e-mail from Mike Jones, who was not involved with the Pathfinder project, originally quoted in the Risks Forum Digest reference you cited is incorrect. The correct information appeared in a followup post by Glenn Reaves, the cognizant design engineer for the Pathfinder Flight Software. This information can be found in a later issue of the Risks Forum Digest.

Steve Stolper

Michael Barr responds:

You are correct that we got some bad information about the Pathfinder software's flaw on the Internet. The scenario described in our article was a valid example of priority inversion. However, it was not an accurate description of what actually happened on Pathfinder. A corrected description of the facts and a link to the Glenn Reeves post you mention can be found in the online version of this article.

Thanks for reading and letting us know about this so promptly. We regret the error.

Sanity check

Thank you for the breath of fresh air! Jack Ganssle's April 2002 column (“Comments on Comments,” p. 73) arrived at a time when I was struggling to remain sane.

I recently went through yet another iteration of the software-guru blues. As an embedded software guy, I sometimes feel like a necessary evil. Hey, it's just software, right?

Finally, the industry is slowly realizing that this is not true (now, if someone will please let the marketing folks know). However, when working so closely with hardware-minded folks, it seems as though we will never treat software as a true engineering effort. Ganssle's remarks about comments not matching source code hit us right between the eyes. But he stopped too soon.

What is worse is that the requirements and design documents are often even farther removed from reality. After reading Jack's column, I am even more determined to make the requirements match the design and the final code on every project. Otherwise, it would be more honest to just do away with all documentation.

Thank you, from the very bottom of my bit bucket, for reminding us of the importance of documenting what we do.

Kenny O'Dell


What's on your mind?

Embedded Systems Programming welcomes feedback. Please send any comments to editor-in-chief Michael Barr at . Letters to the editor will be considered for publication in any and all media unless the writer requests otherwise. They may be edited for clarity and length.

Return to June 2002 Table of Contents

Leave a Reply

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