Embedded Systems Programming, March 1996
Table of Contents
FEATURESSimulating Embedded Systems
by Kenneth F. Greenberg
Although a simulator won't solve all of your debugging problems, sometimes it's useful to have one around. Here's what simulation will and won't do for you.
Programming for Change: How to Handle the Software Crisis
by Daniel Pettyjohn
Several notorious software project failures have been blamed on too many design change requests by the customer. Here are some guidelines for writing C code that will accommodate subsequent changes.
Development of a Real-Time Simulation System
by John Boyd and Roger Theyyunni
Off-the-shelf tools targeted for a variety of applications may not always meet the requirements of a particular type of application. Embedded system developers should develop tools accordingly, as this case study points out.
How to Comment Code
Advanced DSO Techniques in Debugging Embedded Systems
COLUMNS + DEPARTMENTS
by Lindsey Vereen
Not only is embedded technology extending to niches you'd never expect, the likelihood that it will be based on x86 architecture is growing. Now, how long do you think it will take to embed a Pentium Pro-based system into a golf ball?
Clearing the Books
by Tyler Sperry
Speaking of silicon disasters, I can think of some CPU designs that have deserved to die--a few several times over.
On the Average
by Jack W. Crenshaw
If you still don't understand, ask your local bookie. Gamblers know the law of averages like their own right hands.
C and C++ Compilers
by Tyler Sperry
With every machine cycle being precious, who could afford the clumsy registershuffling of a high-level language?
A Modest Software Standard
by Jack G. Ganssle
Programmers at small companies are left to do their own thing, and such undisciplined activity inevitably results in chaos.
State of the Art
by P.J. Plauger
Subsetting way to go, enthusiasts argue. Everyone will be programming in that language sooner or later.
Return to Embedded.com