Channels ▼

Al Williams

Dr. Dobb's Bloggers

Abstract Art and Embedded Systems

February 13, 2014

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.

Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 


Video