TMS320 DSP算法标准API用户指南：接口与操作详解

需积分: 9 4 浏览量更新于2024-07-28 收藏 571KB PDF 举报

《TMS320 DSP Algorithm Standard API Reference User's Guide》是一份详尽的指南，专注于TMS320 Digital Signal Processor (DSP) 的算法标准应用编程接口（API）的使用。该文档的最新版本发布于2005年2月，并在2007年进行了修订，旨在为开发人员提供一套规范化的接口来设计、管理和优化针对TMS320 DSP平台的算法。本指南的核心内容集中在以下几个关键部分： 1. **算法接口** (Algorithm Interfaces): 首先介绍了算法接口的总体概念，包括对算法实例接口 (IALG) 的详细描述。IALG定义了一系列用于创建、初始化、控制和管理算法实例的方法，如 `algActivate()` 初始化处理前的临时存储空间，`algAlloc()` 用于获取算法对象所需的内存，`algDeactivate()` 保存算法持久数据到非临时存储，以及 `algFree()` 算法对象释放内存。 - `algActivate()` 和 `algDeactivate()` 方法确保了数据的一致性和处理流程的完整性，通过预先分配和保存临时数据，避免数据竞争。 - `algNumAlloc()` 有助于了解算法运行时可能需要的内存分配请求次数。 - DMA（Direct Memory Access）接口如IDMA2和IDMA3，分别针对不同处理器型号（如C64x和C5000系列）和高级功能（如EDMA3控制器）提供高效的数据传输支持，通过`dmaChangeChannels()` 等方法允许算法适应不同的DMA配置。 2. **特定接口示例**: 指南还提供了针对不同功能的接口实现示例，例如IDMA2接口，展示了如何在C64x和C5000 DSP上利用DMA资源进行算法操作。对于C64x+ DSP上的EDMA3，有专门的IDMA3接口，强调了其在提升数据传输性能方面的优势。这份文档对于任何在TMS320 DSP平台上进行算法开发的工程师来说，都是不可或缺的参考资料。它不仅提供了清晰的API设计原则，还为实际编程实践提供了实用的指导，帮助开发者高效地管理内存、控制算法流程，并利用DMA技术优化数据传输效率。理解并熟练掌握这些API是开发高性能、可靠且可移植的DSP算法的关键。

www.ti.com

IALG - Algorithm Instance Interface

In some cases, an implementation of IALG does not require any processing for a particular method.

Rather than require the implementation to implement functions that simply return to the caller,

implementations are allowed to set function pointer to NULL. This allows the client to avoid unnecessarily

calling functions that do nothing and avoids the code space overhead of these functions.

1. Instance object creation, initialization, and deletion

2. Algorithmic processing

3. Instance object control and relocation

The functions defined in IALG_Fxns fall into several categories. Instance object creation is complicated by

removing memory allocation from the algorithm. In order for an algorithm to be used in a variety of

applications, decisions about memory overlays and preemption must be made by the client rather than the

algorithm. Thus, it is important to give the client as much control over memory management as possible.

The functions algAlloc(), algInit(), and algFree( ) allow the algorithm to communicate its memory

requirements to the client, let the algorithm initialize the memory allocated by the client, and allow the

algorithm to communicate the memory to be freed when an instance is no longer required. Note that these

operations are not called in time-critical sections of an application.Please note that the following

enhancement affecting allocation, management, and sharing of memory resources is introduced in the

current revision of this document (SPRU360C).

• The algorithm may now provide the client, during the algAlloc() call, the base address of any statically

initialized IALG_WRITEONCE persistent buffer it is requesting. If the algorithm provides a base

address, the client may simply use it to initialize the instance object without allocating any additional

memory; otherwise, the client allocates and grants the memory as if it is a standard memory request.

However, the client may arrange sharing of write-once persistent buffers by granting multiple instances

of the same algorithm created with identical parameters, the same set of write-once persistent buffers.

This enhancement provides a simple mechanism for sharing run-time relocatable read-only look-up

tables.

Once an algorithm instance object is created, it can be used to process data in real-time. The sub-classes

of IALG define other entry points to algorithmic processing supported by eXpressDSP-compliant

algorithms. Prior to invoking any of these methods, clients are required to activate the instance object via

the algActivate( ) method. The algActivate( ) method provides a notification to the algorithm instance that

one or more algorithm processing methods is about to be run zero or more times in succession. After the

processing methods have been run, the client calls the algDeactivate method prior to reusing any of the

instance's scratch memory. The algActivate( ) and algDeactivate( ) methods give the algorithm a chance

to initialize and save scratch memory that is outside the main algorithm-processing loop defined by its

extensions of the IALG interface.

The final two methods defined by the IALG interface are algControl( ) and algMoved( ). The algControl( )

operation provides a standard way to control an algorithm instance and receive status information from the

algorithm in real-time. The algMoved( ) operation allows the client to move an algorithm instance to

physically different memory. Since the algorithm instance object may contain references to the internal

buffer that may be moved by the client, the client is required to call the algMoved( ) method whenever the

client moves an object instance.

The following figure summarizes the only valid sequences of execution of the IALG_Fxns functions for a

particular algorithm instance.

16 Algorithm Interfaces SPRU360E – February 2005 – Revised February 2007

Submit Documentation Feedback

www.ti.com

algActivate

algMoved

”process”

algDeactivatealgFree

algInitalgAlloc

Start state

Real−time states

Terminal state

IALG - Algorithm Instance Interface

Figure 1-2. IALG Interface Function Call Order

For simplicity, the algControl( ) and algNumAlloc( ) operations are not shown above. The algControl( )

method may be called at any time after algInit( ) and any time before algFree( ). The algNumAlloc( )

method may be called at any time.

Algorithm Parameters and Status

When algorithm instances are created, the client can pass algorithm-specific parameters to the algAlloc( )

and the algInit( ) methods. To support implementation-specific extensions to standard abstract algorithm

interfaces, every algorithm's parameter structure must begin with the size field defined in the

IALG_Params structure. This field is set by the client to the size of the parameter structure (including the

size field itself) that is being passed to the algorithm implementation. Thus, the implementation can "know"

if the client is passing just the standard parameter set or an extended parameter set. Conversely, the

client can elect to send just the "standard" parameters or an implementation specific set of parameters. Of

course, if a client uses an implementation specific set, the client cannot be used with a different

implementation of the same algorithm.

Client

{

FIR_Params stdParams;

FIR_TI_Params tiParams

stdParams = FIR_PARAMS; /* initialize all fields to defaults */

stdParams.coeff = 0; /* initialize selected parameters */

fxns->algAlloc(&stdParams, 0); /* pass parameters to algorithm */

tiParams = FIR_TI_PARAMS; /* initialize all fields to defaults

tiParams.coeff = 0; /* initialize selected parameters

fxns->algAlloc(&tiParams, 0); /* pass parameters to algorithm

Int FIR_TI_algAlloc(IALG_Params *clientParams, 0

{

FIR_TI_Params params = FIR_TI_PARAMS;

/* client passes in parameters, use them to override defaults

if (clientParams != NULL)

memcpy(&params, clientParams, clientParams->size);

}

/* use params as the complete set of parameters */

}

SPRU360E – February 2005 – Revised February 2007 Algorithm Interfaces 17

Submit Documentation Feedback

www.ti.com

1.2.1 algActivate - initialize scratch memory buffers prior to processing

IALG - Algorithm Instance Interface

From the code fragments above, you can see that the client uses the same style of parameter passing

when passing generic parameters or implementation-specific parameters. A client may do both. The

implementation can also easily deal with either set of parameters. The only requirement is that the generic

parameters always form a prefix of the implementation specific parameters; i.e., any implementation

specific parameter structure must always include the standard parameters as its first fields.

Example

Algorithms that implement the IALG interface enable run-time instance creation using the following generic

create and delete functions.

#define MAXMEMRECS 16

typedef struct IALG_Obj {

IALG_Fxns fxns; /* algorithm functions */

} IALG_Obj;

IALG_Handle ALG_create(IALG_Fxns *fxns, IALG_Params *params)

{

IALG_MemRec memTab[MAXMEMRECS];

IALG_Handle alg = NULL;

Int n;

IALG_Fxns *fxnsPtr = NULL;

IALG_Handle p = NULL;

if (fxns->algNumAlloc() <= MAXMEMRECS) {

n = fxns->algAlloc(params, &fxnsPtr, memTab);

if (fxnsPtr != NULL) {

if ((p = ALG_create(fxnsPtr, NULL)) == NULL)

return ((IALG_Handle) NULL);

}

if (allocMemory(memTab, n)) {

alg = (IALG_Handle)memTab[0].base;

alg->fxns = fxns;

if (fxns->algInit(alg, memTab, p, params) != IALG_EOK) {

fxns->algFree(alg, memTab);

freeMemory(memTab, n);

alg = NULL;

}

return (alg);

}

Synopsis

Void algActivate(IALG_Handle handle);

Arguments

IALG_Handle handle; /* algorithm instance handle */

Return Value

Void

Description

algActivate( ) initializes any of the instance's scratch buffers using the persistent memory that is part of the

algorithm's instance object.

The first (and only) argument to algActivate() is an algorithm instance handle. This handle is used by the

algorithm to identify the various buffers that must be initialized prior to calling any of the algorithm's

processing methods.

The implementation of algActivate() is optional. The algActivate() method should only be implemented if a

module wants to factor out initialization code that can be executed once prior to processing multiple

consecutive frames of data.

18 Algorithm Interfaces SPRU360E – February 2005 – Revised February 2007

Submit Documentation Feedback

www.ti.com

IALG - Algorithm Instance Interface

If a module does not implement this method, the algActivate field in the module's static function table (of

type IALG_Fxns) must be set to NULL. This is equivalent to the following implementation:

Void algActivate(IALG_Handle handle)

{

}

Preconditions

The following conditions must be true prior to calling this method; otherwise, its operation is undefined.

• algActivate( ) can only be called after a successful return from algInit( ).

• handle must be a valid handle for the algorithm's instance object.

• No other algorithm method is currently being run on this instance. This method never preempts any

other method on the same instance.

• If the algorithm has implemented the IDMA2 or IDMA3 interface, algActivate( ) can only be called after

a successful return from dmaInit( ).

Postconditions

The following condition is true immediately after returning from this method.

• All methods related to the algorithm may now be executed by client (subject to algorithm specific

restrictions).

Example

typedef struct EncoderObj {

IALG_Obj ialgObj; /* IALG object MUST be first field */

Int *workBuf; /* pointer to on-chip scratch memory */

Int *historyBuf; /* previous frame's data in ext mem */

… ;

} EncoderObj;

Void algActivate(IALG_Handle handle)

{

EncoderObj *inst = (EncoderObj *)handle;

/* copy history to beginning of on-chip working buf */

memcpy(inst->workingBuf, inst->histBuf, HISTSIZE);

}

Void encode(IALG_Handle handle,

Void *in[], Void *out[])

{

EncoderObj *inst = (EncoderObj *)handle;

/* append input buffer to history in on-chip workBuf */

memcpy(inst->workBuf + HISTSIZE, in, HISTSIZE);

/* encode data */

…

/* move history to beginning of workbuf for next frame */

memcpy(inst->workBuf, inst->workingBuf + FRAMESIZE, HISTSIZE);

}

Void algDeactivate(IALG_Handle handle)

{

EncoderObj *inst = (EncoderObj *)handle;

/* save beginning of on-chip workBuf to history */

memcpy(inst->histBuf, inst->workingBuf, HISTSIZE);

}

See Also

algDeactivate( )

SPRU360E – February 2005 – Revised February 2007 Algorithm Interfaces 19

Submit Documentation Feedback

www.ti.com

1.2.2 algAlloc( ) - get algorithm object's memory requirements

IALG - Algorithm Instance Interface

Synopsis

numRecs = algAlloc(const IALG_Params *params, IALG_Fxns

**parentFxns, IALG_MemRec memTab[]);

Arguments

IALG_Params *params; /* algorithm specific attributes */

IALG_Fxns **parentFxns;/* output parent algorithm functions */

IALG_MemRec memTab[]; /* output array of mem records */

Return Value

Int numRecs; /* number of initialized records in memTab[] */

Description

algAlloc() returns a table of memory records that describe the size, alignment, type and memory space of

all buffers required by an algorithm (including the algorithm's instance object itself). If successful, this

function returns a positive non-zero value indicating the number of records initialized. This function can

never initialize more memory records than the number returned by algNumAlloc(). If algNumAlloc() is not

implemented, the maximum number of initialized memory records is IALG_DEFMEMRECS.

The first argument to algAlloc() is a pointer to the creation arguments for the instance of the algorithm

object to be created. This pointer is algorithm-specific; i.e., it points to a structure that is defined by each

particular algorithm. This pointer may be NULL; however, in this case, algAlloc(), must assume default

creation parameters and must not fail.

The second argument to algAlloc() is an output parameter. algAlloc() may return a pointer to its parent's

IALG functions. If this output value is assigned a non-NULL value, the client must create the parent

instance object using the designated IALG functions pointer. The parent instance object must then be

passed to algInit().

algAlloc() may be called at any time and it must be idempotent; i.e., it can be called repeatedly without any

side effects and always returns the same result.

Preconditions

The following conditions must be true prior to calling this method; otherwise, its operation is undefined.

• The number of memory records in the array memTab[] is no less than the number returned by

algNumAlloc().

• *parentFxns is a valid pointer to an IALG_Fxns pointer variable.

• The params parameter may be NULL.

Postconditions

The following conditions are true immediately after returning from this method.

• If the algorithm needs a parent object to be created, the pointer *parentFxns is set to a non-NULL

value that points to a valid IALG_Fxns structure, the parent's IALG implementation. Otherwise, this

pointer is not set. algAlloc() may elect to ignore the parentFxns pointer altogether.

• For each memory descriptor in memTab with an IALG_WRITEONCE attribute, the algorithm has either

set the base field to a non-NULL value, which is the address of a statically allocated and initialized

memory buffer of the indicated `size,' or has set the base field to NULL, thereby requiring the memory

for the buffer to be provided by the client.

• Exactly n elements of the memTab[ ] array are initialized, where n is the return value from this

operation.

• For each memory descriptor in memTab with an IALG_PERSIST or IALG_SCRATCH attribute, the

algorithm does not set its base field.

• If the params parameter is NULL, the algorithm assumes default values for all fields defined by the

parameter structure.

• memTab[0] defines the memory required for the instance's object and this object's first field is an

IALG_Obj structure.

• memTab[0] is requested as persistent memory.

20 Algorithm Interfaces SPRU360E – February 2005 – Revised February 2007

Submit Documentation Feedback

剩余97页未读，继续阅读

JAMES

粉丝: 6
资源: 29

TMS320 DSP算法标准API用户指南：接口与操作详解

TMS320C55x Chip Support Library API Reference Guide

TMS320 DSP Algorithm Standard.pdf

tms320c66x dsp cache user guide

tms320c67x dsp csdn

tms320c54x汇编语言,TMS320C54x DSP原理及应用

tms320c3xuser鈥檚guide

基于tms320f2812 dsp的设计

tms320f2833x dsp原理与应用教程 pdf

tms320c6000系列dsp编程工具与指南 csdn

tms320f28335dsp原理开发及应用 符晓 朱洪顺 pdf

最新资源

tms320f28335dsp原理开发及应用符晓朱洪顺 pdf