This hands-on how-to demonstrates how to use object-oriented programming features of Matlab 2008a to model C++ digital signal processing solutions.
By James Metzger, SPARTA, Inc.
Object-oriented analysis and design
It's less common that one would opt to host DSP applications in C++ in the first place given the footprint associated with the language and the number-crunching needs of the applications. Traditionally, DSP programs have been written in C, assembly, Verilog, or, heaven forbid, cast as an ASIC. Nevertheless, tools like Texas Instrument's Code Composer and Analog Devices' VisualDSP++ support C++ development. A performance-sensitive version of the language called Embedded C++ constrains the language to key features forbidding more luxurious items such as multiple inheritance, templates, use of standard template library (STL), and real-time type identification (RTTI).
For software DSP applications, an object-oriented description can go a long way toward functional reuse and extensibility. Little analysis is required to see that the items of a signal-processing flow diagram could be readily mapped to a system of classes, as shown in Figure 1.
View the full-size image
Specifically, an abstract class called Module will perform some operation on an abstract class called Data, which may produce more Data for further processing, detect the occurrence of some feature in the data or both. In the case of detection, another abstract class called Event may be devised to notify interested modules of its occurrence. Modules may have virtual functions for its operation on data (Apply method), notification of an event (Notification method), or resetting to its original state (Reset method).
Any number of concrete classes can be derived from Module to create a library of reusable signal-processing building blocks. For example, the OSCModule would perform overlap-and-save convolution; ALCModule would perform automatic level control on its input; and finally the TDModule subclass could detect the presence of a pure tone, as Figure 2 shows.
View the full-size image
These modules could operate on Signal objects derived from the Data abstraction and produce other Signal objects, Event objects, or both. When an event of interest occurs, registered modules would be notified through the Notification method. Finally, a container module shown in Figure 3 could chain subordinate modules into larger signal-processing schemes and handle events produced by its children.
View the full-size image