# What is the difference between a DSP and a standard microcontroller?

I understand that a DSP is optimized for digital signal processing, but I'm not sure how that impacts to the task of choosing an IC. Almost everything I do with a microcontroller involves the processing of digital signals!

For example, let's compare the popular Microchip dsPIC30 or 33 DSP and their other 16-bit offering, the PIC24 general purpose microcontroller. The dsPIC and the PIC can be configured to have the same memory and speed, they have similar peripherial sets, similar A/D capability, pin counts, current draw, etc. The only major difference that appears on Digikey's listing is the location of the oscillator. I can't tell the difference by looking at the prices (or any other field, for that matter.)

If I want to work with a couple of external sensors using various protocols (I2C, SPI, etc.), do some A/D conversions, store some data on some serial flash, respond to some buttons, and push data out to a character LCD and over an FT232 (a fairly generic embedded system), which chip should I use? It doesn't appear that the DSP will lag behind the PIC in any way, and it offers this mysterious "DSP Engine." My code always does math, and once in a while I need floating point or fractional numbers, but I don't know if I'll benefit from using a DSP.

A more general comparison between another vendor's DSPs and microcontrollers would be equally useful; I'm just using these as a starting point for discussion.

-

## 6 Answers

To be honest the line between the two is almost gone nowadays and there are processors that can be classified as both (AD Blackfin for instance).

Generally speaking:

Microcontrollers are integer math processors with an interrupt sub system. Some may have hardware multiplication units, some don't, etc. Point is they are designed for simple math, and mostly to control other devices.

DSPs are processors optimized for streaming signal processing. They often have special instructions that speed common tasks such as multiply-accumulate in a single instruction. They also often have other vector or SIMD instructions. Historically they weren't interrupt based systems and operated with non-standard memory systems optimized for their purpose making them more difficult to program. They were usually designed to operate in one big loop processing a data stream. DSP's can be designed as integer, fixed point or floating point processors.

Historically if you wanted to process audio streams, video streams, do fast motor control, anything that required processing a stream of data at high speed you would look to a DSP.

If you wanted to control some buttons, measure a temperature, run a character LCD, control other ICs which are processing things, you'd use a microcontroller.

Today, you mostly find general purpose microcontroller type processors with either built in DSP-like instructions or with on chip co-processors to deal with streaming data or other DSP operations. You don't see pure DSP's used much anymore except in specific industries.

The processor market is much broader and more blurry than it used to be. For instance i hardly consider a ARM cortex-A8 SoC a micro-controller but it probably fits the standard definition, especially in a PoP package.

EDIT: Figured i'd add a bit to explain when/where i've used DSPs even in the days of application processors.

A recent product i designed was doing audio processing with X channels of input and X channels of output per 'zone'. The intended use for the product meant that it would often times sit there doing its thing, processing the audio channels for years without anyone touching it. The audio processing consisted of various acoustical filters and functions. The system also was "hot plugable" with the ability to add some number of independent 'zones' all in one box. It was a total of 3 PCB designs (mainboard, a backplane and a plug in module) and the backplane supported 4 plug in modules. Quite a fun project as i was doing it solo, i got to do the system design, schematic, PCB layout and firmware.

Now i could have done the entire thing with an single bulky ARM core, i only needed about 50MIPS of DSP work on 24bit fixed point numbers per zone. But because i knew this system would operate for an extremely long time and knew it was critical that it never click or pop or anything like that. I chose to implement it with a low power DSP per zone and a single PIC microcontroller that played the system management role. This way even if one of the uC functions crashed, maybe a DDOS attack on its Ethernet port, the DSP would happily just keep chugging away and its likely no one would ever know.

So the microcontroller played the role of running the 2 line character LCD, some buttons, temperature monitoring and fan control (there were also some fairly high power audio amplifiers on each board) and even served an AJAX style web page via ethernet. It also managed the DSPs via a serial connection.

So thats a situation where even in the days where i could have used a single ARM core to do everything, the design dictated a dedicated signal processing IC.

Other areas where i've run into DSPs:

*High End audio - Very high end receivers and concert quality mixing and processing gear

*Radar Processing - I've also used ARM cores for this in low end apps.

*Sonar Processing

*Real time computer vision

For the most part, the low and mid ends of the audio/video/similar space have been taken over by application processors which combine a general purpose CPU with co-proc offload engines for various applications.

-
Thanks for the detailed answer and history! –  Kevin Vermeer Jun 17 '10 at 22:08
Another addition perhaps. In an application with quite about 80 I/O lines and 12 analog inputs we are now using a single microcontroller with a linked FPGA to handle the I/O streams. Solutions like this are becoming more common. We are using this system: embeddedarm.com/products/board-detail.php?product=ts-7800 to make the development quick for a short Time-to-Market and I must say it works very well (Of course the price of such a product may not be suited for applications with a lower selling price/expected value.) – Wouter Simons 33 secs ago –  Wouter Simons Jun 30 '10 at 9:52
Not all microcontrollers have interrupts. In mission-critical applications they're never used. Case in point: the Viper controller used in fighter planes. –  stevenvh Jul 13 '11 at 7:03

Many digital signal processors include a variety of functions not found in 'ordinary' processors:

1. The ability to perform a multiply-accumulate, with both operands fetched from RAM, at a rate of one cycle per pair of operands.
2. The ability to perform some form of 'modulo' or 'wrapping' addressing, so as to allow a buffer to be used repeatedly without having to use manual code to ensure pointers wrap. The 3205x, for example, has a 'buffer start' and 'buffer end' register; if code attempts to incrementing or decrement a pointer register that points to 'buffer start', the processor will load the pointer with 'buffer end'. The 3205x also has a reverse-carry mode, where address additions propagate carry MSB to LSB, rather than vice versa; this allows for modulo-N addressing if N is a power of 2, though stuff gets stored in jumbled sequence.
3. The ability to specify that an instruction be executed 'n' times without needing to be re-fetched. Some processors like the 8088 include this for a few instructions, but many DSP's allow this on many instructions.
4. The ability to specify that a block of code be executed repeatedly, up to 'n' times, without need for branching. Before each code fetch, the program counter is checked against the 'loop-end' register; if it matches, and looping is enabled, the program counter will be reloaded with 'loop-start' (otherwise it will increment). If 'loop-count' is zero, looping will be disabled; otherwise 'loop-count' will be decremented.

Note that many DSPs will have separate buses to allow both operands of a multiply-accumulate to be fetched simultaneously; I've never seen a non-DSP that could do that. While I'm unaware of any feature that a chip must 'lack' to be a DSP, extra silicon space required to allow double-operand fetching is silicon space that isn't being used for some other more-generally-useful purpose.

-
I was familiar with the multiply-accumulate, but modulo addressing and repeated fetch-free code execution were features I wasn't familiar with. –  Kevin Vermeer Mar 9 '11 at 23:25
You have a lot of great answers, and it's cool that you work on both old and new questions. I would go through and upvote all of your answers if it weren't for the fraud detection algorithms and daily rep cap. Expect a few a day, though! Keep up the awesome work! –  Kevin Vermeer Mar 9 '11 at 23:26
@reemrevnivek: Glad you find my responses useful. As I noted, the design for double-fetch multiply-accumulate is a feature I've not seen on non-DSP processors. The ARM does a good job with operations requiring multiply-accumulate and modulo addressing (using an effective address of e.g. (R0 + (R1 >> 24)) for a 256-byte table) but a typical ARM would require four instructions to do what a DSP does in one cycle. –  supercat Mar 10 '11 at 2:32

One thing the others didn't mention is behavior on numeric overflow. In normal processors this usually wraps around from the maximal value to the minimal value.

For DSP usage there is often at least an option to use saturation instead. That is, on overflow the value stays at the maximal value, which produces less distortion and better mimics the behavior of analog circuits.

-

The biggest difference between DSP and the standard uController is the DSP's multiply accumulate feature (MAC) that uC does not have. This valuable if you want to perform true digital signal processing math such as FFT (one example). Doing an FFT in a standard microcontroller will take a long time compared to performing it on a MAC of the DSP.

Processing I2C and serial signals is not the same as processing waveforms in a DSP. Totally different kind of processing going on since serial signals are just bit-banging.

Here's a similar discussion on a DSP forum: DSP vs. Microprocessor

-
I saw an Accumulator on the DSP block diagram, but didn't know what it did. Good to know! I understand that I2C and serial are not the same as processing waveforms when you're sending ASCII data, but some peripherials (Serial-access accelerometers, external A/D, GPS, etc. encode waveforms in their data streams. It has to get into the DSP somehow! –  Kevin Vermeer Jun 17 '10 at 22:10
most signal processing is mathematically comprised of multiplying matrices and/or vectors together. The process of doing this results in a lot of answer = ab + cd + e*f type calculations. On a cpu without a MAC that takes a lot of instructions to do, with a MAC it can be many times faster. –  Mark Jun 17 '10 at 22:35
This comment is flat out WRONG. Not all, but many MCUs include hardware multipliers with MAC functions. This has nothing to do with a DSP vs. MCU distinction. Yes, DSPs are more likely to have a MAC than an MCU, but there are far more fundamental differences than this small feature. –  adrian Jun 18 '10 at 16:53
If you turn the clock back 15 years, you see almost no MCU's with this feature. If you take the MAC or equivalent feature out of the DSP, can you honestly say that you have a DSP? I certainly wouldn't want to buy one if didn't have it or something close too it. There architecture differences when you get into Harvard vs. von Neuman and memory access, but I was giving a simple answer without going into a long detailed explanation. I think you're too harsh with your comment by saying "Flat out WRONG". You're welcome to post an answer discussing the depth you think needs to be covered. –  Jay Atkinson Jun 18 '10 at 17:43
@adrian: Your comment is flat out WRONG. If an MCU has a MAC function it will be marketed as a DSP. –  Johan.A Sep 3 '13 at 9:49

What used to set DSPs apart was their optimization for arithmetic operations, especially multiplication, although these days it's not uncommon for microcontrollers to come endowed with multiplication and division instructions. There may still be an edge to doing signal processing with DSP chips, insofar as some of them have hardware support for fixed-point math (e.g., the TI TMS320s 'IQ' lib), whereas micros are more likely to just include integer units.

Personally, when faced with choosing between the two for a design, I'd try to categorize whether the application called for repetitive calculations with only occasional mode change logic, or only needs to perform short sequences of calculations as need arises. The former would be the DSP, the latter a micro.

And then, of course, there are fun things like the OMAP that have both. =P

-
I think I understand the difference in intent (your second paragraph), but I'm just not sure why I would do that when micros don't have DSP-like math ability and DSPs have micro-like peripherial sets. As I said in my OP, the dsPIC33 and PIC24 can have an almost identical feature set and an identical price. Correct me if I'm wrong, but while the DSP has repetitive processing facilities, I don't think that the PIC24 (or any other micro that I've looked at) has any advantage over a DSP in mode changes, like a dual pipeline or faster FLASH. –  Kevin Vermeer Jun 17 '10 at 23:28
@reemrevnivek: so you're saying, why not always just choose a DSP? –  JustJeff Jun 18 '10 at 0:33
@JustJeff: Yes, that's exactly what I'm saying. –  Kevin Vermeer Jun 18 '10 at 12:57

Yet another possible feature the MAC instruction can have is auto-incrementing the registers that point to multiplicands. I programmed a Zilog DSP that used the (16-bit fixed-point) Clarkspur core. It was a variation on Harvard architecture with three busses, letting it access three areas of memory simultaneously: Instruction memory, data ram bank 1, and data ram bank 2. With a data stream in one ram bank and coefficients in the other, one could do an FIR filter with one single-cycle instruction per MAC/pointer increment operation. In C the single instruction looks like:

Accumulator += rambank1 [r1++] * rambank2 [r2++];

And of course this instruction is repeated for each coefficient.

Also not pointed out earlier, DSPs (at least the older ones I've used) are generally RISC architecture and are designed with many or most instructions executing in a single cycle (or in the same number of cycles). This allows the ability to program for deterministic interrupt response (a fixed clock count between the interrupt line going active and the first instruction in the ISR executed), whereas most other processors respond to interrupts in a variable number of clock cycles, depending on at what point in a multi-cycle instruction the interrupt occurs. The fixed execution time eliminates multiple-of-clock-time jitter in repetitive outputs.

To the OP's comparison of the Microchip Pic and DSPic, it was my understanding when DSPic was introduced that it was mainly just a Pic with a MAC instruction and a few other added features, which can certainly speeds up a microcontroller doing signal processing functions, but (due to its lack of any of the other features discussed) it might be pushing the terminology to call it a DSP. The MSP430 is also available in versions with a hardware MAC, but no one calls THAT a DSP.

I recall 10 to 15 years ago reading that mainstream processors from Intel were adding MAC and similar instruction to do "native" signal processing (instead of on expansion cards with dedicated DSP processors, which were common for audio production in the 1990s) - some inexpensive 56k dialup PC bus modems were just A/D and D/A converters, and relied on the main processor to do the modem signal encoding and decoding functions, so there was a demand for more efficient processor use right there. Media uses such as video editing/encoding/decoding as well as audio recording/production are greatly sped up by DSP-type instructions.

-
There's nothing new under the sun. <g> Back in the early days of C, the increment and decrement operators were designed to be directly translated into single hardware instructions on the PDP. –  Pete Becker Apr 25 '13 at 21:17