Texas Instruments TMS320 DSP manual Interface Inheritance, Summary, Element, Description Required

Page 32

www.ti.com

Interfaces and Modules

module'sheader file defines a concrete interface; the functions defined in the header uniquely identify a specific (or concrete) implementation within a system. A special type of interface header is used to define abstract interfaces; abstract interfaces define functions that are implemented by more than one module in a system. An abstract interface header is identical to a normal module interface header except that it declares a structure of function pointers named XYZ_Fxns. A module ABC is said to implement an abstract interface XYZ if it declares and initializes a static structure of type XYZ_Fxns named ABC_XYZ.

The TMS320 DSP Algorithm Standard API Reference (SPRU360) contains all of the abstract interface definitions for eXpressDSP-compliant algorithms. All eXpressDSP-compliant algorithm modules, for example, must implement the IALG interface. Appendix A of the TMS320 DSP Algorithm Standard API Reference document contains an example of a module that implements the IALG interface.

By convention, all abstract interface headers begin with the letter 'i'To. insure no chance for confusion, we drop the adjective "concrete" and "abstract" when referring to a module'sinterfaces.

3.1.10 Interface Inheritance

Although all eXpressDSP-compliant algorithms implement the IALG interface, it is important to note that almost all of the TMS320 DSP Algorithm Standard modules must implement a more specific algorithm interface; i.e., they must implement all of the IALG functions as well as methods specific to the algorithm. For example, a G.729 enCoder algorithm must not only implement IALG; it must also implement an "enCode" function that is specific to the G.729 algorithm.

In this common case — where we want to define a new interface that requires additional methods beyond those defined by IALG — we define a new interface that "derives from" or "inherits from" the IALG interface. Interface inheritance is implemented by simply defining the new interface's"Fxns" structure so that its first field is the "Fxns" structure from which the interface is inherited. Thus, any pointer to the new interface's"Fxns" structure can be treated as a pointer to the inherited interface's"Fxns" structure.

In the case of the G.729 enCoder algorithm, this simply means that the first field of the G729E_Fxns structure is an IALG_Fxns structure. This ensures that any G.729 enCoder implementation can be treated as a "generic" eXpressDSP-compliant algorithm.

All interfaces (including those not currently part of the TMS320 DSP Algorithm Standard) that extend IALG should employ the same technique. The abstract IFIR interface example defined in the TMS320 DSP Algorithm Standard API Reference illustrates this technique.

3.1.11 Summary

The previous sections described the structure shared by all modules. Recall that modules are the most basic software component of an eXpressDSP-compliant system. The following table summarizes the common design elements for a module named XYZ.

Element

XYZ_init() XYZ_exit()

xyz.h

XYZ_Config

XYZ

XYZ_Fxns

Description

Required

Module initialization and finalization

yes

functions

 

Module'sinterface definition

yes

Structure type of all module configuration

Only if module has global

parameters.

configuration parameters

Global structure of all module configuration

Only if module has global

parameters.

configuration parameters

Structure type defining all functions

Only if the interface is an

necessary to implement the XYZ interface.

abstract interface definition

The next table summarizes the common elements of all modules that manage one or more instance objects.

32

Algorithm Component Model

SPRU352G –June 2005 –Revised February 2007

Image 32
Contents Users Guide Rules and GuidelinesSubmit Documentation Feedback Contents Use of the DMA Resource Urls List of Figures Document Overview Read This FirstIntended Audience Related Documentation Text ConventionsRule n 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 Use of C Language Threads and ReentrancyThreads RulePreemptive vs. Non-Preemptive Multitasking ReentrancyExample Data Memory Data MemoryMemory Spaces Scratch versus PersistentScratch vs Persistent Memory Allocation Algorithm versus Application GuidelineSection Name Purpose Program MemoryROM-ability Use of Peripherals Use of PeripheralsAlgorithm Component Model Interfaces and Modules Algorithms PackagingInterfaces and Modules Implementation Fir.hExternal Identifiers Module Instance Objects Naming ConventionsModule Initialization and Finalization Design-Time Object Creation Run-Time Object Creation and DeletionModule Configuration Example ModuleMultiple Interface Support Interface Inheritance SummaryElement Description RequiredAlgorithms AlgorithmsPackaging Object CodeHeader Files Debug Verses ReleaseModuleversvendorvariant.1arch Algorithm Performance Characterization Data Memory Program Memory Interrupt Latency Execution TimeSize Heap MemoryExternal Stack Memory Static Local and Global Data MemoryData Bss Object files Size Interrupt Latency Execution TimeMips Is Not Enough OperationExecution Time Model Execution Timeline for Two Periodic Tasks59000 198000 Process198000 Submit Documentation Feedback DSP-Specific Guidelines CPU Register Types Register TypesUse of Floating Point TMS320C6xxx Rules and GuidelinesEndian Byte Ordering Data ModelsRegister Conventions Status RegisterRegister 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 Relocatability ExampleSSP ST3 Field Name Use Type Status BitsST2 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 Rule Abstract InterfaceDMA Guideline Average Maximum Resource CharacterizationData Transfers bytes Frequency 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 GuidelinesMinimizing Logical Channel Reconfiguration Overhead Addressing Automatic Endianism Conversion IssuesInter-Algorithm Synchronization 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