MCUs or DSPs: Which is in (Motor) Control? -

MCUs or DSPs: Which is in (Motor) Control?

Quick!—name the world's most popular microprocessor chip. If you said “Pentium” you're wrong. Way wrong. Fact is, Intel's famous Pentium family makes up barely 2% of the world's microprocessors. The other 98% are all embedded processors.

Since “embedded processor” covers just about everything that's not inside a PC or workstation, it's pretty hard to generalize about them. Some embedded processors are small enough to inhale. Some, like the upcoming Sony/IBM/Toshiba “Cell” processor are fire-breathing behemoths that could shame most Unix workstations.

What embedded processors do have in common is a focus on cost-effectiveness and suitability to the task, whatever that task may be. Some are designed for thermostats, some for antilock brakes, some for video games, and some for the mundane task of washing your clothes. On that front, the humble motor inside a washing machine proves an unlikely battleground for chip makers. There's argument over whether traditional microprocessors (and microcontrollers) are best suited for handling motor-control tasks, or whether digital signal processors (DSPs) have the upper hand. With motors so prevalent in everyday items, the debate is no tempest in a teapot

The Endless Spin Cycle

Processor-controlled motors are more prevalent than the average person might think. Household appliances including “white goods” such as washing machines and dryers are prime examples. These homely devices all got automated several years ago. European appliance makers in particular jumped to processor-controlled motors more than a decade ago in order to comply with tight governmental regulations on power usage and efficiency. One by one, Europe's households were invaded by computer-controlled clothes dryers.

What does motor control get you? After all, spinning an AC or DC motor couldn't be simpler; the motors themselves haven't changed much in almost a hundred years. Yet controlling their motion is tricky. Apart from just turning them on and off, controlling the motion of a spinning motor is quite tricky. It involves the science of kinematics, lots of math, and a better than average understanding of inertia, momentum, commutation, mechanical loading, velocity arcs, friction, and any number of arcane fields of study normally closed to electrical engineers and programmers.

For starters, you can “soft start” a motor that's processor-controlled. Rather than just applying power to the windings, you can feed power in gradually (over a few seconds or milliseconds) to bring the motor up to speed without wasting energy or causing abrupt mechanical jolts. Once the motor's underway, a processor can also tweak its speed or torque based on need. With just a little feedback a processor-controlled motor can adapt to heavy or light loads (in the washer, for example), or even to brown-out conditions on the AC line.

Processor-controlled motors can also add features that an end user might pay for, or that reduce maintenance overhead or improve safety. Over time the processor may sense that the motor requires more torque than usual, indicating a failing bearing. Diagnostic code might detect impending failure in other parts of the system or alert maintenance personnel when service is required.

At the other extreme, industrial robots need a whole different level of motor control. Rather than simply spinning a shaft, assembly-line robots move in relatively small increments but with high precision. A midrange four-joint robot (shoulder, elbow, wrist, and twist) will have half a dozen motors all working in concert to bring the “end effector” (a screwdriver, welder, inspection camera, or what have you) to just the right location, attitude, and angle. It's a hardware/software dance that's scary-complicated, and for a large robot undergoing debugging, just plain scary.

Surveying the Options

So what processors are good at this task? For high-volume home appliances that control a single AC motor, a little 8-bit microcontroller is probably adequate. Virtually every new dishwasher, microwave oven, washer, or dryer will have one of these. At the high end, though, the choices get more complicated. Stretching the definition of “motor control,” automakers now use 32-bit microprocessors to run the car's engine. Another processor controls the automatic transmission, another runs the antilock brakes, and so on. The average new car now includes more than a dozen different microprocessors; the Mercedes S-class and BMW 7-series vehicles both include more than 100 processors apiece.

In the middle we have industrial robots both large and small, consumer electronics, actuators, security systems, and innumerable other specialty products. The motors within are controlled by everything from decades-old Motorola 68000 processors to late-model RISC processors, to new chips that combine a microcontroller and a digital signal processor (DSP) to create a new kind of hybrid chip. Although most of these chips could be used in most of these applications, the best choice isn't always clear.

Lately there's been a move toward DSPs and away from conventional microprocessors for motor control. The reasons for this aren't always clear, but the trend is definitely there. In some situations, DSPs are better suited to the task. But the real reason may have more to do with software than with the chips themselves. Experienced DSP programmers, and established DSP programming tools, often take a different view toward real-time performance compared to mainstream programmers. A healthy respect for predictability and determinism are two strong streaks running through the DSP talent pool. And when you're swinging a 100-pound robot arm or commanding a 5.7-liter V8, predictability is a big deal.

The DSP Mystique

Contrary to popular opinion, a DSP processor is not inherently better at generating analog waveforms than a conventional processor. After all, they've both got digital outputs. DSPs pass digital data over a parallel bus just like any other CPU. It's the job of some other hardware in the system to covert that data into something the motors can actually use. What DSPs are better at, though, is calculating just where that motor should go.

For all their peculiarities, DSP chips are good at repetitive math. Running tight code loops is what DSPs are born to do. And the quick, repetitive closed-loop calculations of a motor-control application are right up that alley. At its heart, motor control isn't all that different from communications processing, something that DSPs traditionally excel at. Both have hard real-time demands and both require filtering and extended-precision processing. The computation itself may or may not be all that demanding, but the high bandwidth and high precision come in handy. Many of TI's DSP chips for motor control offer 32-bit precision while its mainstream DSP have just 16-bit math units.

On the other hand, a DSP might be overkill. You may not need the floating-point arithmetic, extended-precision calculations, or seemingly bizarre addressing modes that many DSP processors offer. Midrange and high-end chips tailored for telecommunications infrastructure are burdened with features that most motor-control programmers won't need—or understand. For plenty of motor-control systems, a low-end DSP is all that's required.

Hybrid Motoring

What frightens most developers away from DSP chips is their programming model. Fill a room with software engineers and the DSP programmers can't talk with the CPU coders. For the most part, they're from two different backgrounds and program in two different ways. While the basics may be the same, the specifics of DSP architecture frighten a lot of developers who remember when RISC-versus-CISC was a big debate.

But times are changing. Analog Devices, Microchip, Renesas, Texas Instruments, and others have launched outreach programs for disenfranchised CPU coders. ADI's Blackfin chips and TI's MSP430 chips, to name just two, were designed to be non-threatening to conventional embedded programmers. These chip families, and others like them, have familiar register files, recognizable instruction mnemonics, and manageable addressing modes. They also maintain most of a DSP's facility with math, but leavened a bit so as not to alarm the unwary C programmer.

Which highlights another issue. By their nature, DSP processors don't lend themselves to C programming. They've historically been programmed directly in assembly language, partly because DSP routines were often time-critical and partly because standard programming languages were inadequate. The C language, for example, just doesn't map well onto a typical DSP architecture. C was developed, somewhat unconsciously, with certain assumptions about how registers, memory, and execution units behave. It's a fine language for procedural, flow-oriented programs—but somewhat less so for signal-processing code. Like Klingon haiku, it's just the wrong language for the job.

Here again, the hybrid CPU/DSP families come to the rescue. With their RISC-like programming models these chips host compiled C code quite comfortably. They still often require hand-written assembly routines for critical inner code loops, but the chip vendor will supply these as often as not. (After all, it's in their best interest to give away code if it means selling more chips. Ain't capitalism great.)

Motor Winding Wind-Up

So where does that leave the traditional microprocessor? Are yesterday's RISC and CISC processors being kicked aside by newer CPU/DSP hybrids, or do these chips still have a role in motor-control applications? The answer is yes to both.

First off, most 32-bit processor families have been around for years, if not decades. Intel's x86 family tree got planted way back in 1971 and today's embedded 386, 486, and Pentium-class chips still have some remarkable (some would say appalling) similarities to those early 8008 and 8086 processors. That kind of longevity breeds programmer loyalty. You can't swing a dead cat through most engineering labs without hitting a programmer with experience using an x86, or 68000, or ARM, or MIPS processor. That kind of experience doesn't come cheap, and most programmers are loath to give up their hard-fought experience. Better to write code for an old, familiar chip than struggle with a new, unfamiliar one.

Second, many motor-control applications are well served by existing RISC or CISC processors. Unless the motor's moving very rapidly and needs constant course correction a standard microprocessor will probably do just fine. Comparing current position to desired position and accounting for momentum, load, and acceleration are all within the abilities of most 32-bit microprocessors.

Third, processors have speeded up faster than motors have. In other words, an old 16-MHz Motorola 68000 chip might have had a tough time keeping up with a robot arm, but a modern 100-MHz ColdFire processor would have no problem – and the two CPUs could probably run the same code. As processors have gotten faster they're able to take on more of the filtering, commutation, and encoding tasks. All without switching to an alternate architecture.

But the newer hybrids chips have their advantages, too. Sometimes it has nothing to do with the internal architecture or programming model but with what's outside the chip. Hybrid devices often come with PWM (pulse-width modulation) outputs, CAN interfaces, or other useful peripherals that aren't so common on conventional microprocessors. For a low-cost system, or one that's space constrained, those peripherals—not the processor core—can swing the deal. Sometimes it's what's on the outside that counts.

Caches are different, too. DSP chips and DSP hybrids generally take a different view toward caches: they're a bad thing. Paradoxically, one of the features that almost every 32-bit microprocessor added in the past decade now works against them. Caches are the bane of real-time predictability, and DSP programmers avoid them. Caches are great for speeding up most code, most of the time. But they play havoc with determinism. Plenty of motor-control systems just can't afford to work reliably 99% of the time, but then fail unpredictably because of a cache-miss. Better to have no cache than an unpredictable one.

In the end, the world's motor-control applications will be split three ways between traditional microprocessors, DSP processors, and hybrid processors. The major automakers have already selected their chips, and they're almost all conventional 32-bit RISC or CISC designs. Consumer-electronics vendors have made hybrid CPUs popular in everything from DVD players to digital cameras (which have motors for focusing). And DSPs are a big hit with industrial users and anything that requires image processing or high-speed communication. As with most things, there's no single right answer. But that doesn't mean it's not worth evaluating the alternatives and taking a good look at previously unanticipated options.

About the Author
Jim Turley is an acknowledged authority on microprocessor chips, embedded systems, semiconductor intellectual property, computers, and silicon technology. He is the author of seven books, Editor-in-Chief of Embedded Systems Programming magazine, publisher and principal analyst of Silicon Insider , past editor of the prestigious industry journal Microprocessor Report (a three-time winner of the Computer Press Award), and is a regular speaker at industry events. He is frequently quoted in The Wall Street Journal , New York Times , San Jose Mercury News , and appears regularly on television, radio, and Internet broadcasts. His email address is .

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.