Computer Hardware Algorithm Standard User's Guide

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