February 13, 2014
Real-world applications quickly tax our simple abstractions
Society is built on abstractions. When I write a book, I am assuming someone knows how to print them. The printer, in turn, probably uses someone to make paper and ink and carve out typefaces (which, I know, they haven’t done for a long time), and all the other things that go into making a book. Those people probably build on abstractions too, buying chemicals to make the paper and ink.
Abstractions, in general, are a good thing. However, especially in the software world, there is a temptation to get too cozy with our abstractions and forget that they are hiding complexity. If you’ve ever had a piece of code that “has to work” but doesn’t only to find out you’ve discovered a bug in the compiler or operating system, you know what I mean.
Hardware is no different. It is easy to draw a schematic and assume that it represents the real world. It is only an abstraction that is convenient, but only up to a point. You very likely are making some pretty big assumptions about what range of conditions your abstractions are valid.
Consider a simple schematic that shows a battery connected to a heater. The battery is, say, 12 volts and the heater is a 24 watt heater at 12V. It isn’t hard to think that the heater must have a resistance of 6 ohms and the total current through the heater is 2 amps (basic Ohm’s law stuff).
That sounds great and in many cases is probably pretty close to the truth. The wire on the schematic is perfect, but the real world wire isn’t. For that matter, the battery isn’t really a perfect battery either. For a reasonably good battery and a foot of copper wire, it is probably close enough. But if the heater is a long way from the battery, these things could make a difference.
In an embedded system, you might turn the heater on with a transistor or a MOSFET. We use abstractions to show how those will switch and that’s another source of unreality. Even if you don’t have long wire runs, a PC board trace has a maximum current it can carry, stray capacitance, and even a little inductance. None of that shows up on a normal schematic.
All of these things become more important when you are handling a lot of power for things like motors (say, in a CNC machine or a heater). Consider that 10 meters of 18 gauge wire has about 0.2 ohms of resistance. If you have a positive and negative lead, that’s 0.4 ohms total. Doesn’t sound like much, but what if you are drawing an amp of current through that wire? You’ll lose 0.4 volts, which could have a significant impact on performance. An 18 gauge wire can, in theory, safely carry 10 amps, and that would drop 4 volts!
On a PC board, a 10 mil trace of ½ ounce copper has nearly one ohm of resistance in only 10 inches. Don’t forget that resistance will go up as temperature rises in wires or PC board traces. In extreme environments, that can be a factor, too.
Of course, there are other problems with wires — noise pick up, skin effect for AC current, insulation suitability for the intended environment, and ability to withstand stress and the environment. Your best bet is to start with a wire table. Be sure to factor in the temperatures you expect your system to withstand. That will get you part of the way there, but probably doesn’t do it all if you are worried about environments or strength. Of course, if you have short runs of low power wiring, you probably can get away with a lot, and people do every day. But when you are doing something exotic — or something you didn’t think was exotic, but it does work, you need to dig past the simple abstraction.
My point is, real-world applications quickly tax our simple abstractions of “here’s a wire on the schematic.” The effect isn’t just limited to wire, either. Next time, I’ll talk about other components we use in embedded systems and how they don’t live up to our abstractions of them.