Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼

Al Williams

Dr. Dobb's Bloggers

High Capacity

February 26, 2014

The last few blogs, I've been talking about how our abstract representation of electronic components can have serious implications for real-life embedded systems. That's probably an endless topic, but I did want to wrap up with one last installment.

I was actually thinking about this topic while watching a movie this week. In the movie, the good guy was pretty much all good and the bad guy was wholly despicable. Real life isn't usually like that. Even the good guys have their flaws. I like to think the bad guys have some redeeming quality too, for the most part.

That real life mix is what gets us in trouble with components. I've talked about how wire isn't perfect and neither are resistors. They all have little stray bits of things we don't expect like resistance, inductance, or capacitance. Even a common battery has some resistance that prevents it from working as a perfect voltage source. In the case of an inductor, you not only get resistance from the wire, you also get voltage spikes that vary based on how fast you switch voltage across the inductor.

You've probably seen diodes put across the coil of a relay or solenoid to shunt that voltage spike, because that is such a common problem. However, most of these effects are typically pretty small and only become problems when you are dealing with special cases (like the long wire runs or high currents I've mentioned in the last few weeks).

Sometimes the domain of the circuit changes the unspoken assumptions about components, too. For example, in the real world, capacitors can be rather finicky. They are hard to make precise, hard to stabilize for temperature, and have other non-ideal characteristics. However, if you are designing circuitry for an integrated circuit die, the photographic process used allows you to make very precise ratios of capacitors very easily. On the other hand, very precise resistors are often hard to make, depending on the technology used. For that reason, many ICs use capacitors for precise applications where on a printed circuit board you'd be smarter to use resistors.

Electromechanical designs are getting more attention lately, probably due to the popularity of 3D printing and other kinds of industrial robots. That adds a whole other layer of confusion to our simplified models. For example, consider this: What's the difference between a motor, a generator, and a transformer? Theoretically, not very much. A generator takes a rotating shaft and converts the motion to electricity. A motor takes electricity and rotates a shaft. A transformer is just a generator that replaces the rotating shaft with electricity (literally electricity in and electricity out).

In real life, you might optimize the design of a motor differently than that of a generator. But no matter what you do, every generator is also a motor and every motor is also a generator. If you turn a motor shaft, it will generate electricity into your drive circuit. If you don't consider that, a good wind blowing your motor around can burn out your controller. It isn't sufficient to understand the difference between an ideal motor and one that has windings with resistance, inductance, and capacitance that you don't intend. You also have to consider the physical effects to have a successful design.

The truth is, software has the same problem, but software engineers are just more accustomed to thinking about it. For example, despite appearances to the contrary, your computer can't do an endless number of things at once. The fiction that it does requires us to think about deadlocks and other nuances of multiprogramming. Most software engineers are well trained to think about what's under those abstractions and don't even realize they are doing it.

I could keep going, but I think next time I will swing back to the software side of things. Just remember that simplifications we make to manage complexity in circuit design can come back to haunt you if you ignore what is really happening.

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.