Texas Instruments TMS320 DSP manual Interfaces and Modules, Implementation Fir.h

www.ti.com

Interfaces and Modules

These rules and guidelines enable many of the benefits normally associated with object-oriented and component-based programming but with little or no overhead. More importantly, these guidelines are necessary to enable two different algorithms to be integrated into a single application without modifying the source Code of the algorithms. The rules include naming conventions to prevent duplicate external name conflicts, a uniform method for initializing algorithms, and specification of a uniform data memory management mechanism.

3.1Interfaces and Modules

This section describes the general structure of the most basic software component of the eXpressDSP-compliant application—the module. Since all standard-compliant algorithms are implemented as modules, this section describes the design elements common to all of them. This structure is designed to encourage both modular coding practices and reentrant implementations.

A module is an implementation of one (or more) interfaces. An interface is simply a collection of related type definitions, functions, constants, and variables. In the C language, an interface is typically specified by a header file. It is important to note that not all modules implement algorithms, but all algorithm implementations must be modules. For example, the DSP/BIOS is a collection of modules and none of these are eXpressDSP-compliant algorithms.

All eXpressDSP-compliant modules:

∙Provide a single header that defines the entire interface to the module

∙Implement a module initialization and finalization method

∙Optionally manage one or more "instance" objects of a single type

∙Optionally declare a "Config" structure defining module-wide configuration options

Suppose we create a module called FIR, which consists of a collection of functions that create and apply finite impulse response filters to a data stream. The interface to this module is declared in the single C header file, fir.h. Any application that wants to use the functions provided by the FIR module must include the header fir.h. Although the interface is declared as a C header file, the module may be implemented entirely in assembly language (or a mix of both C and assembly).

Figure 3-1. Module Interface and Implementation

Includes

client.c

#include <fir.h>

...

FIR_apply();

}

Implementation

fir.h

typedef struct FIR_obj *FIR_Handle; extern void FIR_init();

extern void FIR_exit();

extern FIR_HandleFIR_create();

fir_apply.asm

.globalFIR_apply FIR_apply:

fir_create.c

FIR_HandleFIR_create() {

Interface

Since interfaces may build atop other interfaces, it is important that all header files allow for the possibility that they might be included more than once by a client.

26 Algorithm Component Model SPRU352G –June 2005 –Revised February 2007

Submit Documentation Feedback