1 interfaces and modules, Implementation – Texas Instruments TMS320 DSP User Manual

Page 26

Advertising
background image

www.ti.com

3.1

Interfaces and Modules

client.c

#include <fir.h>

...

FIR_apply();

}

fir.h

typedef struct FIR_obj *FIR_Handle;

extern void FIR_init();

extern void FIR_exit();

extern FIR_HandleFIR_create();

fir_apply.asm

FIR_apply:

.globalFIR_apply

fir_create.c

FIR_HandleFIR_create() {

Includes

Interface

Implementation

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.

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

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

Advertising