Texas Instruments TMS320 DSP 사용자 설명서

All modules that support object creation should support run-time object creation.

Note that the eXpressDSP-compliant algorithms are a special type of module. When we define algorithms
below, we will see how algorithms support run-time object creation. The guideline above is intended to
cover modules such as those that make up the core run-time support as well as the
eXpressDSP-compliant algorithms.

In an ideal world, a module that implements an API can be used in any system that requires the API. As a
practical matter, however, every module implementation must make trade-offs among a variety of
performance metrics; program size, data size, MIPS, and a variety of application specific metrics such as
recognition accuracy, perceived audio quality, and throughput, for example. Thus, a single implementation
of an API is unlikely to make the right set of tradeoffs for all applications.

It is important, therefore, that multiple implementations of the same API be well supported by any
eXpressDSP-standard development framework. In addition, each module has one or more "global
configuration" parameters that can be set at design time by the system integrator to adjust the behavior of
the module to be optimal for its execution environment.

Suppose for example, that one created a module that implements digital filters. There are several special
cases for digital filters that have significant performance differences; all-pole, all-zero, and pole-zero filters.
Moreover, for TI architectures, if one assumes that the filter's data buffers are aligned on certain
boundaries the implementation can take advantage of special data addressing modes and significantly
reduce the time required to complete the computation. A filter module may include a global configuration
parameter that specifies that the system will only use all-zero filters with aligned data. By making this a
design-time global configuration parameter, systems that are willing to accept constraints in their use of
the API are rewarded by smaller faster operation of the module that implements the API.

Modules that have one or more "global" configuration parameters should group them together into a C
structure, called XYZ_Config, and declare this structure in the module's header. In addition, the module
should declare a global structure named XYZ of type XYZ_Config that contains the module's current
configuration parameters.

This section develops a very simple module to illustrate the concept of modules and how they might be
implemented in the C language. This module implements a simple FIR filter.

The first two operations that must be supported by all modules are the init() and exit() functions. The init()
function is called during system startup while the exit() function is called during system shutdown. These
entry points exist to allow the module to perform any run-time initialization necessary for the module as a
whole. More often than not, these functions have nothing to do and are simply empty functions.

void FIR_init(void)

{

}

void FIR_exit(void)

{

}

The create entry point creates and initializes an object; i.e., a C structure. The object encapsulates all the
state necessary for the other functions to do their work. All of the other module entry points are passed a
pointer to this object as their first argument. If the functions only reference data that is part of the object
(or referenced within the object), the functions will naturally be reentrant.

typedef struct FIR_Params { /* FIR_Obj creation parameters */

int frameLen;

/* input/output frame length */

int *coeff;

/* pointer to filter coefficients */

} FIR_Params;

FIR_Params FIR_PARAMS = { 64, NULL }; /* default parameters */

30

SPRU352G – June 2005 – Revised February 2007