Texas Instruments TMS320 DSP Design-Time Object Creation, Run-Time Object Creation and Deletion

Page 29

www.ti.com

Interfaces and Modules

Figure 3-2. Module Object Creation

FIR

FIR_Config FIR;

FIR_init();

FIR_exit();

FIR_create();

Creates

firObject

firObject

Figure 3-3illustrates an object appropriate for a finite impulse response filter implemented by a module named FIR.

Figure 3-3. Example Module Object

FIR

Creates

FIR_create();

firObject

Int length;

Int coeff[];

Int delay[];

Read-only coefficient array

Filter input history buffer

3.1.5 Design-Time Object Creation

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

3.1.6 Run-Time Object Creation and Deletion

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

Page 28 Page 30
Image 29
Page 28 Page 30
Contents Rules and Guidelines Users GuideSubmit Documentation Feedback Contents Use of the DMA Resource Urls List of Figures Document Overview Read This FirstIntended Audience Text Conventions Related DocumentationRule n Guideline 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 Threads and Reentrancy Use of C LanguageThreads RuleReentrancy Preemptive vs. Non-Preemptive MultitaskingExample Data Memory Data MemoryScratch 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 Summary Interface InheritanceElement Description RequiredAlgorithms 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 Execution Time Interrupt LatencyMips Is Not Enough OperationExecution Timeline for Two Periodic Tasks Execution Time Model59000 198000 Process198000 Submit Documentation Feedback DSP-Specific Guidelines Register Types CPU Register TypesTMS320C6xxx Rules and Guidelines Use of Floating PointEndian Byte Ordering Data ModelsStatus Register Register ConventionsRegister Use Type CSR Field 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 TransfersAddressing Automatic Endianism Conversion Issues Minimizing Logical Channel Reconfiguration OverheadInter-Algorithm Synchronization Non-Preemptive SystemPreemptive 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