What do streaming audio, motor control, and power conversion have in common? Digital signal controllers (DSCs) to solve the problem. These DSP wolves in microcontroller clothing combine the integer number-crunching of a DSP with the peripherals and onboard memory of a microcontroller, providing single-chip solutions for a range of applications.
Generally, DSCs continuously process the same kind of information. And usually it's with tight timing tolerances, such as each time a motor's rotor turns a few degrees, or when handling a digitally controlled power supply (see "Overcoming The Challenges Of Moving To Full Digital Power-Supply Control" at www.electronicdesign.com, Drill Deeper 13203).
Typical DSCs are 16- and 32-bit microcontrollers with DSP functionality. These days, most vendors push an 8- to 32-bit microcontroller continuum by supporting a common set of peripherals, pinouts, and development tools.
This seemingly squeezes the 16-bit processors out, yet they've found a niche in the 16-bit DSC market with a growth path to 32-bit DSCs. In fact, DSCs target numerous applications thanks to the range of available solutions.
Onboard clocks for Microchip's dsPIC family churn out 16 to 40 MIPS, while Analog Devices' Blackfin tops out at 756 MIPS. Of course, how all of this power is used will depend on the application and the peripherals that developers can bring to bear on these microcontrollers. Many peripherals are customized or accelerated for particular applications, such as motor control.
As for the DSC's architecture, it's relatively consistent among vendors, though the details vary significantly (Fig. 1). For example, data and address manipulation tend to be split, and multiple operations often can be performed in each area.
Dual multiply-accumulates (MACs) are common. So is dual address pointer manipulation, which lets DSCs step through arrays of information and perform manipulation on each cycle—just like a DSP.
Often, the DSC's DMA is more sophisticated than a typical microcontroller's DMA because of the incoming data's repetitive nature. The DMA consistently must perform scatter/merge operations to place incoming data in a layout conducive to SIMD-style algorithms. Likewise, DSCs usually repeat the same procedure forever, such as bringing in video data for each frame. An intelligent DMA often can be set once and allowed to run forever.
HARDWARE SIMPLIFIES DSC CHORES DSCs provide compute power. Yet even massive horsepower may not be enough for many applications without adding matching peripheral hardware support.Microchip's 16-bit dsPIC30F1010 and dsPIC30F202x chips incorporate a pair of high-speed, 1-ns resolution, pulse-width modulators (PWMs) and 2-Msample/s, 10-bit analog-to-digital converters (ADCs). As a result, the chips will suit multiloop switch-mode power supplies (SMPSs) and other power-conversion applications, like ac-dc converters, isolated dc-dc power-converters, and uninterruptible power supplies (UPSs).
Without these enhanced peripherals, the standard dsPIC would be hard-pressed to attack some high-end applications, requiring developers to use even higher-performance but more expensive solutions. Of course, a wide selection of DSC options can make things interesting when choosing a chip (see " Choosing The Right DSC For Your Application," above).
Texas Instruments takes a similar peripheral approach with its 32-bit C280xx DSCs. These chips' enhanced PWM (ePWM) unit has over 11 bits of resolution at a 2-MHz frequency, thanks to TI's Micro Edge Positioning technology. The ePWM incorporates a range of submodules for synchronization, asynchronous override, dead-band generation, and PWM chopping.
The C280xx's enhanced capture (eCAP) module can work with the ePWM. Power and motor-control applications usually need to synchronize the PWM output with inputs processed by the eCAP module.
In many cases, the hardware can handle much of the peripheral-interaction, as the processor provides the initial setup or tuning. Still, DSCs with the C280xx's power often will be able to interact with these peripherals on an interrupt basis.
The ADCs in the C280xx also look to reduce processor overhead. For instance, the hardware can remove the offsets by trimming the internal offsets and by dynamically trimming the digital result in the ADC output register.
The big problem for developers is the wide range of options that are available from different vendors, since these enhanced peripherals aren't available across the board. In fact, common peripherals such as PWMs, ADCs, and quadrature encoders differ significantly from vendor to vendor and even within vendor product lines.
In many cases, a 16-bit DSC with the right peripheral support can run rings around a faster 32-bit DSC with a nonenhanced peripheral. Therefore, finding the right hardware may be a challenge. But it's a relatively minor task compared to finding the right software.
DSC SOFTWARE CHALLENGE DSC programming can be, let's say, interesting, due to the complexity of the algorithms and their application to the underlying hardware. Couple this with the timing dependencies of most DSC applications, and the number of developers who can handle the entire software chore shrinks dramtically.Fortunately, most vendors offer software tools that can greatly-simplify the development process. For instance, Freescale's CodeWarrior's "expert beans" provide a way to customize the interface between an application and its peripherals. This lets users configure just a few of the many options a peripheral may have, as well as get all of the necessary source-code files when the process is complete.
Although such a process usually targets real peripherals, it's just as easy to employ a virtual peripheral. This might be strictly a software entity or a combination of hardware peripherals that will cooperate with each other, like the PWM and capture support found in many DSCs.
Code generation is one way to blackbox functionality like a virtual peripheral. But it has some drawbacks, especially when the support within the box is kept secret. A software vendor may have a digital filter that it licenses for less money in binary form. This approach is frequently used with runtime libraries.
The implementation also can be employed with device drivers, just like some of the support available for Analog Devices' Blackfin. It can be used to implement an 802.11g media access control in software, but it's frequently implemented as a closed-source product to prevent users from controlling the strength of the radio.
In this case, the media access control is part of a protocol stack. It's quite common for developers to know nothing about a protocol stack, other than the application programming interface (API). This isn't restricted to services used by a DSC. Very few developers know or care about the insides of an Ethernet protocol stack, but these insides are indispensible for building a networked application.
The library or device driver approach works well for a standalone service. Black-box driver maintenance, on the other hand, can become a major issue between kernel releases of the underlying operating system. As such, find a vendor that will deliver both the kernel and the drivers on a regular basis.
The approach gets a little more cumbersome when multiple filters are tied together. However, this can be quite common with signal-processing applications in the audio and video realm, where multiple codecs, filters, and encryption may be used at the same time.
TI's dual-core DaVinci platform tackles this well by allowing an ARM processor to handle the non-signal-processing chores. TI takes the device driver route when supporting Linux on the ARM processor.
The Linux device driver contains the DSP code that's downloaded to the other processor (Fig. 2). The Linux device driver handles communication between the ARM and DSP so its operation is transparent to the Linux application.
Developers who need to get down and dirty with the DSC can use tools like Freescale's CodeWarrior and TI's Code Composer Studio for assembler-based and C/C++-based applications. These tools add a level of debugging sophistication that's unavailable with conventional development tools due to the kinds of signal-processing applications.
For instance, Code Composer can display an array of data as a graph. This comes in handy, since such data often is the input or output to a software filter. Likewise, tight loop timing can be achieved with execution pipeline analysis presented by the development tools, thereby highlighting stalls that slow performance (see "Making The Blackfin Perform" at Drill Deeper 13205).
A graphical programming environment like National Instruments' Lab-VIEW also can hide a DSC's complexity. LabVIEW's virtual instruments (VIs) encapsulate the functionality of filters and other software components as well as hardware interfaces.
Graphical programming works equally well for general embedded applications. But its data-flow nature makes it ideal for signal-processing applications, where the details are hidden behind the VI hierarchy and interactive configuration (Fig. 3). Developers only need to know what settings to adjust.
National Instruments and Analog Devices teamed up to deliver an integrated LabVIEW/Blackfin solution called LabVIEW Embedded for Blackfin (see "Graphical Programming For Embedded Systems" at Drill Deeper 13204). It comes with a copy of Lab-VIEW and Analog Devices' ADSPBF537 EZ-KIT Lite evaluation board.
The out-of-the-box experience is stunning, enabling developers to begin working with significant signal-processing applications in an afternoon. The enhanced version of LabVIEW works directly with the ADSP-BF537 board, including the ability to download and debug applications using the graphical interface.
LabVIEW's model-based approach permits easy simulation without hardware as well as the ability to target different platforms. LabVIEW can work with Analog Devices' Visual DSP++ integrated development environment. Yet many developers can do graphical model-based development without resorting to C/C++ or assembler.