Article summary
I’m an embedded software engineer, but I don’t consider myself to be just a “software guy.” To be most effective, it’s important to have some background knowledge in electronics hardware. Likewise, a good hardware engineer shouldn’t be afraid to fire up a compiler and get their hands dirty in some C code.
There’s going to be an area of overlap between hardware and software engineers, and that’s very important during development of embedded systems.
Board Bring Up
Embedded development usually starts with a microprocessor dev kit. You add software and hardware components until you find the need to have a custom board made. At this point, a hardware engineer has probably been working on a schematic and layout for your prototype and is ordering a custom board.
What I find that typically happens next is, the boards come in, software is loaded on them, and problems begin to emerge. The problems range from manufacturing defects and layout defects to connectivity incompatibilities.
With so many technical details, limited budgets, and strict deadlines, it’s not suprising that trouble arises. What’s hard about hardware is that it’s hard — it’s physical, and the cycle time between making changes and testing this can take several weeks.
Can We Soften Hardware?
What if you designed and built simplified boards with breakout pads and connectors that could connect to other boards in a modular way? What if you could test these different hardware components before ordering boards?
I asked a hardware engineer exactly that question. I learned that they’ve tried this approach before, and it’s not without its own pitfalls and tradeoffs.
He said that in practice, when you get to the point of being ready to design and build these modular boards, a prototype is also ready to be designed and built. So the inclination to build a first rev of a prototype is huge. Also, while waiting for the hardware to be built, he can do other important “hardware engineering” stuff, so there isn’t a great need to have modular hardware to work with.
How Much Testing, and When?
The question then becomes: “Continue testing, or move forward towards your goal?” Or, trying to find problems vs. letting the problems reveal themselves.
At one point during my current project, I suggested to a fellow Atom that the best thing to do was move forward into the development cycle rather than continue an investigation into a particular concern.
He said that reminded him of a quote from Captain Ron: “If anything’s gonna happen, it’s gonna happen out there.”
I’m sure this wouldn’t be very reassuring to the passengers whose lives depend on the preparedness of the boat. But, when lives aren’t at stake, I don’t think the idea is as irresponsible as it sounds.
I still think that building modular hardware components for prototyping could be useful under certain circumstances. If you were evaluating simpler chips that do not have their own dev kits (such as various kinds of sensors), it would be useful to build a quick example application board to test different signals to the chip. With most designs being SMT, something like this is basically a necessity to practice breadboarding a new device.
As long as modular hardware components are kept fairly simple, and do not affect the design process of ordering a larger prototype, the benefit of having an isolated component outweighs the cost of building that component. When modular hardware components are available during board bring up, hardware and software engineers can use them to help troubleshoot product prototypes and the benefit to project deadlines can be immense.