Texas Instruments TMS320 DSP manual Program Memory, ROM-ability, Section Name Purpose

Page 23

www.ti.com

Program Memory

2.4Program 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

2.5ROM-ability

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

Page 22 Page 24
Image 23
Page 22 Page 24
Contents Rules and Guidelines Users GuideSubmit Documentation Feedback Contents Use of the DMA Resource Urls List of Figures Document Overview Read This FirstIntended Audience Guideline n Related DocumentationText Conventions Rule nOverview Rules for TMS320C5x Rules for TMS320C6x Scope of the StandardRequirements of the Standard Rules and GuidelinesIntentional Omissions Goals of the StandardFrameworks System ArchitectureCore Run-Time Support AlgorithmsGeneral Programming Guidelines Rule Use of C LanguageThreads and Reentrancy ThreadsReentrancy Preemptive vs. Non-Preemptive MultitaskingExample Data Memory Data Memory Scratch versus Persistent Memory SpacesScratch vs Persistent Memory Allocation Guideline Algorithm versus ApplicationSection Name Purpose Program MemoryROM-ability Use of Peripherals Use of PeripheralsInterfaces and Modules Algorithms Packaging Algorithm Component ModelImplementation Fir.h Interfaces and ModulesExternal Identifiers Module Instance Objects Naming ConventionsModule Initialization and Finalization Run-Time Object Creation and Deletion Design-Time Object CreationExample Module Module ConfigurationMultiple Interface Support Description Required Interface InheritanceSummary ElementAlgorithms AlgorithmsObject Code PackagingDebug Verses Release Header FilesModuleversvendorvariant.1arch Data Memory Program Memory Interrupt Latency Execution Time Algorithm Performance CharacterizationSize Heap MemoryExternal Static Local and Global Data Memory Stack MemoryData Bss Object files Size Operation Interrupt LatencyExecution Time Mips Is Not EnoughExecution Timeline for Two Periodic Tasks Execution Time Model59000 198000 Process198000 Submit Documentation Feedback DSP-Specific Guidelines Register Types CPU Register TypesData Models Use of Floating PointTMS320C6xxx Rules and Guidelines Endian Byte OrderingCSR Field Use Type Register ConventionsStatus Register Register Use TypeProgram Models Interrupt LatencyTMS320C54xx Rules and Guidelines TMS320C54xx Rules and Guidelines ST1 Field Name Use Type Status RegistersST0 Field Name Use Type Pmst Field Name Use Type TMS320C55x Rules and GuidelinesStack Architecture Example RelocatabilitySSP ST3 Field Name Use Type Status BitsST2 Field Name Use Type Homy General TMS320C24xx GuidelinesTMS320C28x Rules and Guidelines TMS320C28x Rules and GuidelinesXAR0 M0M1MAP Submitting DMA Transfer Requests Use of the DMA ResourceAlgorithm and Framework OverviewLogical Channel Requirements for the Use of the DMA ResourceData Transfer Synchronization Data Transfer PropertiesDMA Rule Abstract InterfaceDMA Guideline Average Maximum Resource CharacterizationData Transfers bytes Frequency Strong Ordering of DMA Transfer Requests Runtime APIsDevice Independent DMA Optimization Guideline Submitting DMA Transfer Requests13 C6xxx Specific DMA Rules and Guidelines Cache Coherency Issues for Algorithm Producers14 C55x Specific DMA Rules and Guidelines Supporting Packed/Burst Mode DMA TransfersNon-Preemptive System Minimizing Logical Channel Reconfiguration OverheadAddressing Automatic Endianism Conversion Issues Inter-Algorithm SynchronizationPreemptive System Algorithm B Algorithm a Inter-Algorithm Synchronization Appendix a General Rules DMA Rules Performance Characterization RulesGeneral Guidelines DMA Guidelines Submit Documentation Feedback Core Run-Time APIs DSP/BIOS Run-time Support LibraryTI C-Language Run-Time Support Library DSP/BIOS Run-time Support LibraryBooks BibliographySubmit Documentation Feedback Glossary of Terms GlossaryGlossary of Terms Glossary of Terms Important Notice
Top Page Image Contents