Texas Instruments TMS320 DSP User Manual Page 29
- Page / 88
- Table of contents
- BOOKMARKS
Rated. / 5. Based on customer reviews
www.ti.com
FIR_Config FIR;
FIR_init();
FIR_exit();
FIR_create();
FIR
firObject
Creates firObject
FIR
FIR_create();
Creates
firObject
Int length;
Int coeff[];
Int delay[];
Read-only
coefficient array
Filter input
history buffer
3.1.5 Design-Time Object Creation
3.1.6 Run-Time Object Creation and Deletion
Interfaces and Modules
Figure 3-2. Module Object Creation
Figure 3-3 illustrates an object appropriate for a finite impulse response filter implemented by a module
named FIR.
Figure 3-3. Example Module Object
Many embedded systems are very static in nature; memory, MIPS, and I/O peripherals are statically
partitioned among a fixed set of functions that operate continuously until power is removed. Static systems
admit a number of performance optimizations that simply are not possible in dynamic systems. For
example, there is no need for a memory manager in a static system and general data structures, such as
linked lists, can be often replaced with much simpler and more efficient structures, such as fixed length
arrays. These optimizations not only reduce the system's Code size requirements; they may also have a
significant effect on the execution performance of the system.
When designing a system that is very cost sensitive, must operate with limited power, or has limited MIPS,
designers look for portions of the system that can be fixed at design time (i.e., made static). Even if the
entire system cannot be static, often certain sub-systems can be fixed at design time. It is important,
therefore, that all modules efficiently support static system designs.
Guideline 3
All modules that support object creation should support design-time object creation.
In practice, this simply means that all functions that are only required for run-time object creation be
placed either in separate compilation units or separate COFF output sections that can be manipulated by
the linker. Ideally, every function should be in a separate compilation unit. This allows the system
integrator to eliminate run-time support that is unnecessary for a static system.
Modules may optionally support run-time object creation and deletion. In some applications, run-time
creation and deletion is a requirement. For example, without the ability to remove unneeded objects and
reuse memory, the physical constraints of the system make it impossible to create rich multi-function
applications.
Run-time creation of objects is valuable even in systems that do not support or require run-time deletion of
these objects. The precise nature of the objects, the number of objects, and even the type of objects
created may be a function of parameters that are only available at run-time. For example, you may want to
create a single program that works in a variety of hardware platforms that differ in the amount of memory
available and this amount is determinable at run-time.
SPRU352G – June 2005 – Revised February 2007 Algorithm Component Model 29
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. | 6.341 s |
Manymanuals.com
Manymanuals.de
Manymanuals.fr
Manymanuals.it
Manymanuals.pl
Manymanuals.cz
Manymanuals.es
Manymanuals-pt.com
Comments to this Manuals