Texas Instruments TMS320 DSP manual Packaging, Object Code

Page 34

www.ti.com

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'simplementation 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.

3.3Packaging

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'simplementation 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.

3.3.1 Object Code

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

34

Algorithm Component Model

SPRU352G –June 2005 –Revised February 2007

Page 33 Page 35
Image 34
Page 33 Page 35
Contents Users Guide Rules and GuidelinesSubmit Documentation Feedback Contents Use of the DMA Resource Urls List of Figures Intended Audience Read This FirstDocument Overview Rule n Related DocumentationText Conventions Guideline nOverview Scope of the Standard Rules for TMS320C5x Rules for TMS320C6xRules and Guidelines Requirements of the StandardGoals of the Standard Intentional OmissionsSystem Architecture FrameworksAlgorithms Core Run-Time SupportGeneral Programming Guidelines Threads Use of C LanguageThreads and Reentrancy RulePreemptive vs. Non-Preemptive Multitasking ReentrancyExample Data Memory Data MemoryMemory Spaces Scratch versus PersistentScratch vs Persistent Memory Allocation Algorithm versus Application GuidelineROM-ability Program MemorySection Name Purpose Use of Peripherals Use of PeripheralsAlgorithm Component Model Interfaces and Modules Algorithms PackagingInterfaces and Modules Implementation Fir.hExternal Identifiers Module Initialization and Finalization Naming ConventionsModule Instance Objects Design-Time Object Creation Run-Time Object Creation and DeletionModule Configuration Example ModuleMultiple Interface Support Element Interface InheritanceSummary Description RequiredAlgorithms AlgorithmsPackaging Object CodeHeader Files Debug Verses ReleaseModuleversvendorvariant.1arch Algorithm Performance Characterization Data Memory Program Memory Interrupt Latency Execution TimeExternal Heap MemorySize Stack Memory Static Local and Global Data MemoryData Bss Object files Size Mips Is Not Enough Interrupt LatencyExecution Time OperationExecution Time Model Execution Timeline for Two Periodic Tasks198000 Process59000 198000 Submit Documentation Feedback DSP-Specific Guidelines CPU Register Types Register TypesEndian Byte Ordering Use of Floating PointTMS320C6xxx Rules and Guidelines Data ModelsRegister Use Type Register ConventionsStatus Register CSR Field Use TypeTMS320C54xx Rules and Guidelines Interrupt LatencyProgram Models TMS320C54xx Rules and Guidelines ST0 Field Name Use Type Status RegistersST1 Field Name Use Type Stack Architecture TMS320C55x Rules and GuidelinesPmst Field Name Use Type Relocatability ExampleSSP ST2 Field Name Use Type Status BitsST3 Field Name Use Type Homy TMS320C24xx Guidelines GeneralTMS320C28x Rules and Guidelines TMS320C28x Rules and GuidelinesXAR0 M0M1MAP Use of the DMA Resource Submitting DMA Transfer RequestsOverview Algorithm and FrameworkRequirements for the Use of the DMA Resource Logical ChannelData Transfer Properties Data Transfer SynchronizationDMA Guideline Abstract InterfaceDMA Rule Data Transfers bytes Frequency Resource CharacterizationAverage Maximum Runtime APIs Strong Ordering of DMA Transfer RequestsSubmitting DMA Transfer Requests Device Independent DMA Optimization GuidelineCache Coherency Issues for Algorithm Producers 13 C6xxx Specific DMA Rules and GuidelinesSupporting Packed/Burst Mode DMA Transfers 14 C55x Specific DMA Rules and GuidelinesInter-Algorithm Synchronization Minimizing Logical Channel Reconfiguration OverheadAddressing Automatic Endianism Conversion Issues Non-Preemptive SystemPreemptive System Algorithm B Algorithm a Inter-Algorithm Synchronization Appendix a General Rules Performance Characterization Rules DMA RulesGeneral Guidelines DMA Guidelines Submit Documentation Feedback DSP/BIOS Run-time Support Library Core Run-Time APIsDSP/BIOS Run-time Support Library TI C-Language Run-Time Support LibraryBibliography BooksSubmit Documentation Feedback Glossary Glossary of TermsGlossary of Terms Glossary of Terms Important Notice
Top Page Image Contents