When it comes to building a digital signal processing (DSP) board, it is important not to neglect the requirements of the application code — the code that actually acquires and processes data to provide useful results. Developers can write code using the assembly language native for a chosen DSP chip, or they can use a higher-level language such as C or C++ that a compiler converts into the operating code for a specific DSP chip. Even higher-level tools and software applications let developers perform operations from menus or drag-and-drop lists of functions; the underlying code of the tool or application converts these graphical operations into the operating code for the specific DSP chip.

The choice of programming environment often depends on who will use the application, what support it requires, and the programming resources that are available. The proper selection also hinges on whether developers plan to code algorithms and tasks from "scratch," purchase off-the-shelf application libraries, or purchase complete software packages. In many cases, the need to get a product to market quickly is what forces the decision.

Writing in C or C++, for example, gives developers complete control over processor operations, but that flexibility comes at a cost—the time to understand a DSP chip's architecture and the time to thoroughly test and debug the final application code. In contrast, higher-level tools are generally easier to use because they shield developers from the intricacies of the chip's functions. In addition,they may offer ready-built "core" functions, such as filtering, Fourier transforms, and others that provide the foundation of many signal-processing tasks.

Developers will also find that support for higher-level tools often is better than that for programming languages such as C or C++. It's easier for a supplier's support people to help a developer understand how to use a pre-built fast Fourier-transform (FFT) algorithm than to help debug home-built FFT code that was tailored for a specific application. Also, the use of higher-level tools lets developers who are unfamiliar with the internal operations of signal-processing algorithms quickly set up and test an application. In contrast, using C or C++ forces developers to understand the logical flow of signal-processing algorithms.

Some developers may need to get involved at the low level to optimize software for a specific task, but many more developers find it easier to use pre-existing libraries of functions that were created by high-level tool suppliers and by DSP chip manufacturers. Texas Instruments, for example, has an extensive library of code available for programmers of their DSP chips.

To help decide which programming environment is right for a particular application, use the following criteria:

  • Sustainability. How easily can the application be modified or updated? Will changes to the DSP board greatly affect an application? Higher-level tools make hardware implementations almost invisible to users, making it easier to modify an application and its need less frequent.
  • Hardware abstraction. The software should operate regardless of the hardware implementation of the DSP board. Tools should let developers concentrate on their tasks, not on interconnections of memory chips, I/O ports, and communication devices.The underlying software provided by the board vendor and the tool supplier should handle all of the hardware-specific tasks.
  • Developer needs. Software tools should let developers quickly set up and test user interfaces, whether this step involves designing a complete GUI front-end or establishing a communication protocol with a host computer. Developers should not get mired in application program interface (API) calls to obscure routines to produce graphical images or to transmit data.
  • Speed. Always budget time to test and debug an application, considering time to profit in addition to time to market. Code developed using C or C++ may require additional debugging and testing tools that monitor individual variables and DSP-chip operations. In contrast, code produced using higher-level tools often include these tools and perform basic system operations, such as type-checking and memory allocations, automatically. Time gets spent on testing how an application works, not on watching how underlying code works.
  • Cost. Always evaluate cost in the overall context of other variables. such as time and staff resources.Although a DSP chip manufacturer or support group may offer low-cost or even free compilers and development tools, consider the resources needed to use them effectively. A free C++ compiler may sound like a good deal, but its idiosyncrasies may present a steep learning curve. In addition, such free tools usually lack regular, timely support. A development environment with a higher initial cost may actually save an organization money in the long term by getting developers started quickly, by making programming tasks simpler, by offering a range of available function libraries, and by providing a professional, dedicated technical support staff.

This article was written by Timothy Ludy, Product Marketing Manager at Data Translation, Marlboro, MA. For more information, visit www.datatranslation.com .