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.