DSP gets easier

Many of today's sexiest embedded applications require processing real-time signals. Examples include: digital TV, digital cameras, MP3 players, cellular phones, and modems. Processing signals in real time requires some serious number-crunching horsepower. Digital signal processors, or DSPs, have integrated hardware multipliers that let them perform sophisticated math fast. The devices offer high performance, low cost, and low power for real-time applications. And, because they are programmable, DSPs assure fast time to market and ease of design, maintenance, and feature upgrades.

Problem solved? Well, not so fast. DSPs also have the reputation of being so difficult to program that one course developed to teach working engineers the art was titled "DSP Without Tears."

Aware of this reluctance to embrace DSP technology, many DSP chip companies are going out of their way to make using the devices as painless as possible. Today, you can program DSPs in C, use familiar microcontroller-like functions and programming tools, assemble programs using a company's software block library, and find third parties to help.

What's the difference? Before deciding whether you need the power of a DSP, you should understand how DSPs differ from other processors. With the current levels of integration, microprocessors, microcontrollers, and DSPs can all function as stand-alone devices and have similar peripherals. The key difference is the ability to processes signals continuously in real time.

Combining a DSP and a microcontroller on a single core, the 16-bit DSP56800E series from Motorola offers both DSP and microcontroller peripherals up to 4 Mbytes program and 32 Mbytes data memory and performance from 40 up to 200 MIPS.

Unless the application is quite simple, microcontrollers and microprocessors can't keep up. Instead, they are best for control applications that involve taking a snapshot of what the outside world looks like and then making a decision based on that information.

In contrast, DSPs are more like video cameras—they don't take just a snapshot at a particular point in time, they continuously monitor what's going on in the world and modify the output based on that data.

In a nutshell, DSPs manipulate real-time signals—such as voice, audio, images, and video—in real time. These manipulations include filtering (removing unwanted information) and transforms (looking at the data in a different way). "Real time is key to the character of a DSP," say Gene Franz, a senior fellow at Texas Instruments. He gives this example: "When we hit the brakes in our car it is not good to have an 'hour glass' show up on the dashboard screen."

DSPs take control. In the beginning, DSPs offloaded the math-intensive processing from the microcontroller and let the controller make decisions based on the results. "But now DSPs are sophisticated enough that they themselves can make the decisions and take on some of the control applications," says Victor Berrios, a Motorola DSP applications engineer based in Tempe, AZ.

In addition, microcontrollers are becoming sophisticated enough to take on low-end DSP applications. "But microcontrollers are not necessarily designed to handle real-time signals," says Frantz. "If the device cannot guarantee real time, the system will break."

So despite technology advances, many products have both a DSP and a microcontroller. "A cellular phone is a great example," notes Motorola's Berrios. "You have the DSP for continuously checking the incoming RF signal and then processing the data when it detects an incoming call. But in the same application you have a display and a keypad, and things need to happen when the user presses a button—that's the control part."

Most DSPs today have a hybrid architecture. Initially, chip companies put both a DSP core and a microcontroller core on the same piece of silicon. Now, companies are integrating the capabilities of DSPs and microcontrollers into a single core to bridge the performance and ease-of-use gaps between the two.

One example of a hybrid is Motorola's DSP 58600E. Considered a 16-bit CPU, the chip can act as a controller, as a signal processor, or support both functions at once. Users can program the DSP in C instead of assembly code, and Motorola provides a development kit that includes a library of software drivers for all the chip's peripherals.

DSP or microcontroller? For embedded systems that process real-time signals, the options are using a microcontroller, DSP, one of each, or a hybrid. How do you decide? "I usually use a rule of thumb of 80/20," says TI's Frantz. "If 80 percent of the system-level task is best suited for a microcontroller, the designer should seriously consider using the microcontroller to do the DSP tasks—if it can. If 80 percent of the system-level task is real-time DSP activity, the remainder of the tasks should be handled by the DSP."

Unfortunately, he notes, most systems end up being about 50/50. "In this case, it's best to combine the efforts of both," says Frantz.

You really still need to be an expert to work with DSPs, according to Frantz. But other options include using consultants and third-party companies to help with the programming and integration, and DSP vendors offer extensive help through their web pages, applications engineers, and field sales organizations.

What do you need to know about embedded systems?

This article is one of a monthly series on "Embedded Systems and the OEM Engineer," alternately sponsored by Microchip Technology and Texas Instruments. Today's products are designed by teams—the electronics segment is part of the total design and not relegated to specialists. The lead engineer—who may or may not be an electrical engineer—is often the one who chooses a microcontroller, digital signal processor, or embedded operating system. And the trend of adding intelligence to everything from household appliances and automobiles to medical equipment and machine tools is just getting started. What do you need to know to specify the best components for your particular application? What seemingly "dumb" products are you reincarnating with embedded brains? What are your greatest challenges and frustrations? We really want to know. Please send any questions, answers, or comments to Contributing Editor Julie Anne McNamara at julie_mcnamara@email.com

Algorithm standards ease DSP development

Programming standards can help reduce the learning curve and speed development of DSP-based products for the influx of designers moving from the microcontroller world to digital signal processing.

When DSPs debuted, each device could handle only one algorithm. As designers began building complex systems that required additional algorithms, they created schedulers to manage chip resources, and soon DSPs were running several algorithms. These homegrown schedulers became extremely complex to accommodate intensive signal processing and multiplied like rabbits, making a prudent choice almost impossible.

Early algorithm standards were cumbersome and sluggish, and many developers found them less appealing than no standard at all. However, time to market became more critical as development cycles continued to shrink and competitive products hit the market almost simultaneously.

Reliable, straightforward standards. In 1999, Texas Instruments introduced the first programming standard for DSPs: the TMS320™DSP Algorithm Standard. Part of TI's eXpressDSP™Real-Time Software Technology, the standard comprises coding conventions and application programming interfaces (APIs) that enable creators of intellectual property to produce algorithms that developers can reuse in different systems. It supports every member of the TMS320C2000™, TMS320C5000™, and TMS320C6000™families of TI DSPs, while adding an average of less than one percent overhead in MIPS and memory requirements.

The standard's rules enable interoperability between different types of algorithms such as MP3 and JPEG, which reduces integration time and increases programming predictability. And because algorithm vendors must specify parameters such as maximum interrupt latency, required memory, and worst-case instruction execution time, designers can compare algorithms from different vendors without addressing the issue of differing specifications.

Based on the reaction to the TMS320 DSP Algorithm Standard, acceptance can come swiftly—even among skeptics. With DSPs now finding their way into consumer products with lifetimes measured in months, the advantages of designing DSP-based products using a single standard is becoming even more evident. Comprehensive algorithm standards, such as those within eXpressDSP, will soon become as widespread in the DSP development world as they have been in the PC community for decades—and the DSP segment will reap similar benefits.