Texas Instruments TMS320 DSP User Manual Page 23
- Page / 88
- Table of contents
- BOOKMARKS
Rated. / 5. Based on customer reviews
www.ti.com
2.4 Program Memory
2.5 ROM-ability
Program Memory
Like the data memory requirements described in the previous section, it is important that all
eXpressDSP-compliant algorithms are fully relocatable; i.e., there should never be any assumption about
the specific placement of an algorithm at a particular address. Alignment on a specified page size is
permitted, however.
Rule 4
All algorithm code must be fully relocatable. That is, there can be no hard coded program memory
locations.
As with the data memory requirements, this rule only requires that Code be relocated via a linker. For
example, it is not necessary to always use PC-relative branches. This requirement allows the system
developer to optimally allocate program space to the various algorithms in the system.
Algorithm modules sometimes require initialization Code that must be executed prior to any other
algorithm method being used by a client. Often this Code is only run once during the lifetime of an
application. This Code is effectively "dead" once it has been run at startup. The space allocated for this
Code can be reused in many systems by placing the "run-once" Code in data memory and using the data
memory during algorithm operation.
A similar situation occurs in "finalization" Code. Debug versions of algorithms, for example, sometimes
implement functions that, when called when a system exits, can provide valuable debug information; e.g.,
the existence of objects or objects that have not been properly deleted. Since many systems are designed
to never exit (i.e., exit by power-off), finalization Code should be placed in a separate object module. This
allows the system integrator to avoid including Code that can never be executed.
Guideline 2
Each initialization and finalization function should be defined in a separate object module; these
modules must not contain any other code.
In some cases, it is awkward to place each function in a separate file. 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:init Run-once initialization code
.text:exit Run-once finalization code
.text:create Run-time object creation
.text:delete Run-time object deletion
There are several addressing modes used by algorithms to access data memory. Sometimes the data is
referenced by a pointer to a buffer passed to the algorithm, and sometimes an algorithm simply references
global variables directly. When an algorithm references global data directly, the instruction that operates
on the data often contains the address of the data (rather than an offset from a data page register, for
example). Thus, this Code cannot be placed in ROM without also requiring that the referenced data be
placed in a fixed location in a system. If a module has configuration parameters that result in variable
length data structures and these structures are directly referenced, such Code is not considered
ROM-able; the offsets in the Code are fixed and the relative positions of the data references may change.
Alternatively, algorithm Code can be structured to always use offsets from a data page for all fixed length
references and place a pointer in this page to any variable length structures. In this case, it is possible to
configure and locate the data anywhere in the system, provided the data page is appropriately set.
SPRU352G – June 2005 – Revised February 2007 General Programming Guidelines 23
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. | 2.950 s |
Manymanuals.com
Manymanuals.de
Manymanuals.fr
Manymanuals.it
Manymanuals.pl
Manymanuals.cz
Manymanuals.es
Manymanuals-pt.com
Comments to this Manuals