Thu 23 January 2020

Filed under Hardware

Tags Embedded

First of all, any field has its challenges and can be difficult in its own right. But designing hardware genuinely is very hard and I want to make the case that it's actually harder than writing software for said hardware.

What are those challenges then?

  1. Laws of physics
  2. Lack of information
  3. Limited manufacturability
  4. Long development cycles

Let's go over them to find out what I mean!

Laws of physics

When programming, all you care about are abstractions, logic and math. What do they have in common? They are man-created (though you can argue about math). And when the code is run, what does it run on? Well, a man-made machine.

Maybe you already get my point. All programmers ever have to care about is made by humans and thus can be read and understood by humans.

Electronics, however, are not man-made. It was not invented, it was discovered. This means that all math involved with hardware is descriptive instead of prescriptive. When getting into it you have to deal with physics every time.

The different math is not the only thing you need to worry about. Electromagnetic interference, attenuation and stray capacitance will haunt your high performance designs unless meticulously crafted.

Very frustrating.

Lack of information

When your code doesn't work, what do you do? You hook up your debugger! Set some breakpoints, step through the code and inspect (and even change) some variables at runtime at your leisure and fix your problem.

For hardware, though, it's not that simple.

Sure, you can inspect a line to see what signal it carries. But first you have to find a place where you can probe it. If you're lucky, there is a header or a special probing point/pin/ring.

Now you can see your signal on the oscilloscope, but how correct are the measurements the scope takes? So many problems can arise here. Unless your scope is analog, the signal is digitally sampled and thus has a limited accuracy. Your scope can't show you any change in the signal that is faster than 1/2 * sampling speed.

The way you probe can also be a problem. You have to connect the oscilloscope to the ground of the circuit, but that wire can act as an inductor and distort the image. The probe itself also adds some capacity to the circuit which alters the characteristics of it.

These are all the problems if you want to probe in one location. Now imagine you have four signals you want to see. All those probes and cables on your desk will make your life a living hell. More than four locations? Well, you better spend big bucks on an eight-channel oscilloscope.

There are other tools as well like spectrum analyzers. But the more specialized it gets, the more expensive it gets.

Limited manufacturability

Manufacturability plays two roles. The first one is that 99% of us can't make our own components. So we have to endlessly search until we find that perfect IC that's within budget. But they're always somebody elses design.

In software, you can make any piece of code yourself as long as you have time for it. If time is limited (which it often is), you can use a library. There are proprietary ones, but also many opensource ones. The nice thing with open source is that when you spot some weird behaviour, you can find out why that is by looking at the code. Unless you're a university researcher or a Chinese IP pirate, you won't have the ability to inspect the chips you use. All you have is the documentation and the occasional forum post.

The other role of manufacturability shows its head when hardware is being made, be it for testing, prototyping or releasing. In software we have the luxury that we can just compile and then share the binary to whom-and-whatever we want. For free. Instantly.

Hardware on the other hand needs to be ordered. There are multiple ways for that. You can order the PCB's and the components yourself, but who is going to solder it all together? And it's not like you're just going to use the soldering iron for SMD components. So you need to buy an oven and a stencil and then place all the components one by one on the PCB's taking forever.

You can also make a deal with a manufacturer. And to be fair, that's easier than ever before. But still, it will cost you unless you're doing it in bulk.

Long development cycles

Software is easy to test and release. So you do it often. But hardware needs to be ordered and manufactured. If cost is no issue, then the design -> test -> redesign cycle will be around two days. But often that is even longer. Imagine that when writing code, you can only run a new version of it every week. You can run the one weekly version as much as you want, but if you want to change anything, you need to change the bits of the binary itself.

Making dirty modifications to your hardware prototypes happens a lot! Simply redesigning and waiting a week just isn't efficient. The current proof of concept I'm working on at my job has three of those ugly hacks. A redesign will take valuable time away from my software development and is not on the table right now.

But the situation is already much better than ever before. Custom PCB prices have come down a lot and the waiting time is a lot shorter than before. But compared to software, it feels like a tortoise.


Like I said, hardware is difficult and I respect anyone who's good at developing it. At my job, I'm the one with the most experience in this area (to my knowledge) and I feel woefully underequipped in my capabilities. Luckily I have a friend who runs a business to design hardware. He's helped a lot. (Here's his Dutch website)

So maybe the conclusion is: Don't do hardware design. Pay someone who's actually good at it and let all these problems be a pain in their ass.


Carmine Crystal Blog © Dion Dokter Powered by Pelican and Twitter Bootstrap. Icons by Font Awesome and Font Awesome More