Texas Instruments TMS320 DSP User Manual Page 33
- Page / 88
- Table of contents
- BOOKMARKS
Rated. / 5. Based on customer reviews
www.ti.com
3.2 Algorithms
IALG
IALG_Fxns
FIR_Config FIR;
FIR_init();
FIR_exit();
FIR_Fxcs FIR_IALG;
FIR
Implements
Algorithms
Element Description Required
Module's object definition; normally not
struct XYZ_Obj yes
defined in the module's header.
Handle to an instance object; synonym for
XYZ_Handle yes
struct XYZ_Obj *
Structure type of all module object creation
XYZ_Params yes
parameters
Constant structure of all default object
XYZ_PARAMS yes
creation parameters
Run-time creation and initialization of a
XYZ_create() no
module's object
XYZ_delete() Run-time deletion of a module's object no
eXpressDSP-compliant algorithms are modules that implement the abstract interface IALG. By this, we
mean that the module must declare and initialize a structure of type IALG_Fxns, the structure must have
global scope, and its name must be XYZ_IALG, where XYZ is the unique module-vendor prefix described
above. The IALG interface allows algorithms to define their memory resource requirements and thereby
enable the efficient use of on-chip data memories by client applications. The IALG interface is described in
detail in Chapter 1 of the TMS320 DSP Algorithm Standard API Reference (SPRU360).
Not every mathematical function should be cast as an eXpressDSP-compliant algorithm. In particular,
many "traditional" math library operations such as FFT or dot product, which do not maintain state
between consecutive operations and do not require internal workspaces to perform their computation, are
not good eXpressDSP-compliant candidates. These algorithms encapsulate larger computations that
require internal working memory and typically operate on (conceptually) infinite data streams.
Figure 3-4. Example Implementation of IALG Interface
The IALG interface defines a "protocol" between the client and the algorithm used to create an algorithm
instance object at run-time. The IALG interface is designed to enable clients to use the algorithm in
virtually any execution environment; i.e., preemptive and non-preemptive, static and dynamic systems.
Thus, it is important that eXpressDSP-compliant algorithms never use any memory allocation routines
(including those provided in the standard C run-time support libraries). All memory allocation must be
performed by the client.
Rule 12
All algorithms must implement the IALG interface.
Since all eXpressDSP-compliant algorithm implementations are modules that support object creation and
all such modules should support design-time object creation, all eXpressDSP-compliant algorithms
support both run-time and design-time creation of algorithm objects. In order to ensure support for
design-time object creation, it is important that all methods defined by the IALG interface be independently
relocatable.
SPRU352G – June 2005 – Revised February 2007 Algorithm Component Model 33
Submit Documentation Feedback
- User's Guide 1
- Submit Documentation Feedback 2
- Contents 3
- Read This First 7
- Related Documentation 8
- Text Conventions 8
- Overview 9
- 1.1 Scope of the Standard 10
- 1.1.1 Rules and Guidelines 11
- 1.3 Goals of the Standard 12
- 1.4 Intentional Omissions 12
- 1.5 System Architecture 13
- 1.5.1 Frameworks 13
- 1.5.2 Algorithms 14
- 1.5.3 Core Run-Time Support 14
- Chapter 2 15
- 2.1 Use of C Language 16
- 2.2 Threads and Reentrancy 16
- 2.2.1 Threads 16
- 2.2.3 Reentrancy 17
- 2.2.4 Example 18
- 2.3 Data Memory 19
- 2.3.1 Memory Spaces 20
- Data Memory 21
- 2.4 Program Memory 23
- 2.5 ROM-ability 23
- 2.6 Use of Peripherals 24
- Algorithm Component Model 25
- 3.1 Interfaces and Modules 26
- 3.1.1 External Identifiers 27
- 3.1.2 Naming Conventions 28
- 3.1.4 Module Instance Objects 28
- Interfaces and Modules 29
- 3.1.7 Module Configuration 30
- 3.1.8 Example Module 30
- 3.1.10 Interface Inheritance 32
- 3.1.11 Summary 32
- 3.2 Algorithms 33
- 3.3 Packaging 34
- 3.3.1 Object Code 34
- 3.3.2 Header Files 35
- 3.3.3 Debug Verses Release 35
- Packaging 36
- Chapter 4 37
- 4.1 Data Memory 38
- 4.1.1 Heap Memory 38
- 4.1.2 Stack Memory 39
- 4.2 Program Memory 40
- 4.3 Interrupt Latency 41
- 4.4 Execution Time 41
- 4.4.1 MIPS Is Not Enough 41
- 4.4.2 Execution Time Model 42
- Execution Time 43
- DSP-Specific Guidelines 45
- 5.1 CPU Register Types 46
- 5.2 Use of Floating Point 47
- 5.3.1 Endian Byte Ordering 47
- 5.3.2 Data Models 47
- 5.3.3 Program Model 47
- 5.3.4 Register Conventions 48
- 5.3.5 Status Register 48
- 5.3.6 Interrupt Latency 49
- 5.4.1 Data Models 49
- 5.4.2 Program Models 49
- 5.4.3 Register Conventions 51
- 5.4.4 Status Registers 51
- 5.4.5 Interrupt Latency 52
- 5.5.1 Stack Architecture 52
- 5.5.2 Data Models 52
- 5.5.3 Program Models 53
- 5.5.4 Relocatability 53
- 5.5.5 Register Conventions 54
- 5.5.6 Status Bits 55
- 5.6 TMS320C24xx Guidelines 57
- 5.6.1 General 57
- 5.6.2 Data Models 57
- 5.6.3 Program Models 57
- 5.6.4 Register Conventions 57
- 5.6.5 Status Registers 58
- 5.6.6 Interrupt Latency 58
- 5.7.1 Data Models 58
- 5.7.2 Program Models 59
- 5.7.3 Register Conventions 59
- 5.7.4 Status Registers 59
- 5.7.5 Interrupt Latency 60
- Use of the DMA Resource 61
- 6.1 Overview 62
- 6.2 Algorithm and Framework 62
- 6.4 Logical Channel 63
- 6.5 Data Transfer Properties 64
- 6.7 Abstract Interface 65
- 6.8 Resource Characterization 66
- 6.9 Runtime APIs 67
- 6.15.1 Non-Preemptive System 71
- 6.15.3 Preemptive System 72
- Rules and Guidelines 75
- A.1 General Rules 76
- A.3 DMA Rules 77
- A.4 General Guidelines 78
- A.5 DMA Guidelines 79
- Core Run-Time APIs 81
- Bibliography 83
- Glossary 85
- Glossary of Terms 86
© 2020, manymanuals.com. All rights reserved. | 1.394 s |
Manymanuals.com
Manymanuals.de
Manymanuals.fr
Manymanuals.it
Manymanuals.pl
Manymanuals.cz
Manymanuals.es
Manymanuals-pt.com
Comments to this Manuals