Texas Instruments TMS320 DSP manual Naming Conventions, Module Initialization and Finalization

Page 28

www.ti.com

Interfaces and Modules

3.1.2 Naming Conventions

To simplify the way eXpressDSP-compliant client Code is written, it is valuable to maintain a single consistent naming convention. In addition to being properly prefixed (Rule 8), all external declarations disclosed to the user must conform to the eXpressDSP naming conventions.

Rule 10

All modules must follow the eXpressDSP-compliant naming conventions for those external declarations disclosed to the client.

Note that the naming conventions only apply to external identifiers. Internal names and existing Code need not change unless an identifier is externally visible to a client application. The eXpressDSP naming conventions are summarized in the table below.

Convention

Variables and functions

Constants

Types

Structure fields

macros

Description

Variables and functions begin with lowercase (after the prefix).

Constants are all uppercase

Data types are in title case (after the prefix)

Structure fields begin with lowercase

Macros follow the conventions of constants or functions as appropriate

Example

FIR_apply()

G729_FRAMELEN

FIR_Handle

buffer

FIR_create()

In addition to these conventions, it is important that multi-word identifiers never use the '_character' to separate the words. To improve readability use title case; for example, FIR_getBuffer() should be used in lieu of FIR_get_buffer(). This avoids ambiguity when parsing module and vendor prefixes.

3.1.3 Module Initialization and Finalization

Before a module can be used by an application, it must first be "initialized"; i.e., the module'sinit() method must be run. Similarly, when an application terminates, any module that was initialized must be "finalized," i.e., its exit() method must be executed. Initialization methods are often used to initialize global data used by the module that, due to limitations of the C language, cannot be statically initialized. Finalization methods are often used to perform run-time debug assertions; for example, it might check for objects that were created but never deleted. The finalization method of a non-debug version of a module is often the empty function.

Although some modules have no need for initialization or finalization, it is easier for the clients of modules to assume that all modules have them. This allows frameworks to easily implement well-defined startup and shutdown sequences, for example.

Rule 11

All modules must supply an initialization and finalization method.

3.1.4 Module Instance Objects

Modules optionally manage instance objects. All eXpressDSP-compliant modules manage instance objects. Objects simply encapsulate the persistent state that is manipulated by the other functions or methods provided by the module.

A module manages only one type of object. Thus, a module that manages objects roughly corresponds to a C++ class that follows a standard naming convention for its configuration parameters, interface header, and all external identifiers as shown in Figure 3-2.

28

Algorithm Component Model

SPRU352G –June 2005 –Revised February 2007

Page 27 Page 29
Image 28
Page 27 Page 29
Contents Users Guide Rules and GuidelinesSubmit Documentation Feedback Contents Use of the DMA Resource Urls List of Figures Intended Audience Read This FirstDocument Overview 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 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 Interface Inheritance SummaryElement 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 Interrupt Latency Execution TimeMips Is Not Enough OperationExecution Time Model Execution Timeline for Two Periodic Tasks198000 Process59000 198000 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 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 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
Top Page Image Contents