Texas Instruments TMS320 DSP User Manual Page 34
- Page / 88
- Table of contents
- BOOKMARKS
Rated. / 5. Based on customer reviews
www.ti.com
3.3 Packaging
3.3.1 Object Code
Packaging
Rule 13
Each of the IALG methods implemented by an algorithm must be independently relocatable.
In practice, this simply means that each method should either be implemented in a separate file or placed
in a separate COFF output section. By placing each of these methods in a separate file or output section,
the linker can be used to eliminate those methods that are unnecessary in systems that do not require
run-time object creation.
In some cases, it is awkward to place each function in a separate file. For example, doing so may require
making some identifiers globally visible or require significant changes to an existing Code base. The TI C
compiler supports a pragma directive that allows you to place specified functions in distinct COFF output
sections. This pragma directive may be used in lieu of placing functions in separate files. The table below
summarizes recommended section names and their purpose
Section Name Purpose
.text:algActivate Implementation of the IALG algActivate method
.text:algAlloc Implementation of the IALG algAlloc method
.text:<name> Implementation of the IALG <name> method
In other words, an algorithm's implementation of the IALG method <name> should be placed in a COFF
section named ".text:<name>".
Since the IALG interface does not define methods that can be used to actually run an algorithm, it is
important that each abstract algorithm interface extend (or "derive") from the IALG interface. Thus, every
algorithm has considerable flexibility to define the methods that are appropriate for the algorithm. By
deriving from IALG, we can ensure that all implementations of any algorithm implement the IALG
interface.
Rule 14
All abstract algorithm interfaces must derive from the IALG interface.
In this section, we cover the details necessary for a developer to bundle a module into a form that can be
delivered into any TMS320 DSP Algorithm Standard development system. It is important to recall that a
module's implementation may consist of many object files and at least one C header file. By following
these conventions, algorithm developers can be sure that their components can be seamlessly integrated
into any TMS320 DSP Algorithm Standard development environment. Moreover, these conventions are
designed to enable TMS320 DSP Algorithm Standard development environments to easily manage an
arbitrary collection of eXpressDSP-compliant components.
In many cases, the TMS320 DSP Algorithm Standard requirements simply amount to file naming
conventions. In order to ensure that a single component can be used in both UNIX and Windows
development environments, it is necessary to
• never create two files whose names only differ in case, and
• always treat file names as being case-sensitive.
Rule 15
Each eXpressDSP-compliant algorithm must be packaged in an archive which has a name that follows
a uniform naming convention.
All of the object Code files for a module should be archived into a library with the following name:
<module><vers>_<vendor>.l<arch>
where
Algorithm Component Model34 SPRU352G – June 2005 – Revised February 2007
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. | 0.622 s |
Manymanuals.com
Manymanuals.de
Manymanuals.fr
Manymanuals.it
Manymanuals.pl
Manymanuals.cz
Manymanuals.es
Manymanuals-pt.com
Comments to this Manuals