By Jack Ganssle

Hardware/Software Disconnect

Published 11/10/2008

When the embedded field was young most developers wore at least two hats, that of firmware and hardware designer. Some also came up with analog, power and maybe even RF circuits. A single engineer might be responsible for most of the electronics in a product. Sometimes the same person would even lay out the PCB and assemble prototypes.

But systems were simpler back then. 8 KB of code was a lot, and SMT hadn't turned board assembly into an art practiced only by the caffeine-deprived. 12 bit A/D converters were expensive, which meant those of us working in the analog domain had, in general, smaller noise issues than today's systems that measure femtoamps. Low clock rates dodged Maxwell's Laws and programmable logic was merely a dream.

Though a huge number of embedded systems are still small, often containing a bare sliver of silicon embodied in a small PIC or other high integration CPU, big applications are common. Firmware can consume hundreds of thousands or even millions of lines of code. Hardware people design with multi-hundred pin chips running with tiny noise margins, while wrestling with EMI and ESD requirements that were unheard-of decades ago. It's natural that engineers started to specialize, at first to divide the work into manageable chunks, and later because of the specialized knowledge required to deal with advancing technology and requirements.

Today an increasing number of embedded systems developers live in their own domain, with little knowledge of other aspects of the system they're building. That's a natural part of the progression of knowledge: as a technology or science advances people's expertise at their own arcane area grows while their breadth narrows. But it's interesting how that, in a single generation, we've progressed to the point where many firmware developers can't answer simple questions about their hardware platform. In casual discussions with engineers I'll often ask about their system's clock rate, or supply voltage, or any of a number of hardware issues. Quite a few can't answer; in some cases the software people don't know what the target processor is.

The reverse is often true as well: ask a hardware developer about the firmware's data structures or which RTOS is used and you might get a blank look. The FPGA whizzes are sometimes clueless about classes and analog gurus can be completely ignorant about PWM control.

I've worked with groups that use embedded Windows or Linux simply to minimize their need for firmware people, who can be hard to find and a lot more expensive than Visual Studio programmers. These GUI people may have little idea about the physical instantiation of their product.

This natural and necessary specialization has created a new job category, one that doesn't even have a name, which I call the systems guy or gal. The person who does have a deep understanding of all of these interrelated issues, who can sling some VHDL and C while probing a low-noise preamp. Sometimes they're the computer experts who can tie together the digital hardware and code to interface with the RF crowd to help the entire team solve a challenging multipath problem.

These systems people are invaluable and increasingly hard to find. At times I wonder if they are a vanishing breed. But other fields have managed to keep systems folks with armies of specialists. Medical GPs, for instance, look at the whole body.

What is your experience? Are systems folks a dying breed?