Computer Hardware Algorithm Standard User's Guide
Table Of Contents
- Table of Contents
- Preface
- 1 Overview
- 2 General Programming Guidelines
- 3 Algorithm Component Model
- 3.1 Interfaces and Modules
- 3.1.1 External Identifiers
- 3.1.2 Naming Conventions
- 3.1.3 Module Initialization and Finalization
- 3.1.4 Module Instance Objects
- 3.1.5 Design-Time Object Creation
- 3.1.6 Run-Time Object Creation and Deletion
- 3.1.7 Module Configuration
- 3.1.8 Example Module
- 3.1.9 Multiple Interface Support
- 3.1.10 Interface Inheritance
- 3.1.11 Summary
- 3.2 Algorithms
- 3.3 Packaging
- 3.1 Interfaces and Modules
- 4 Algorithm Performance Characterization
- 5 DSP-Specific Guidelines
- 6 Use of the DMA Resource
- 6.1 Overview
- 6.2 Algorithm and Framework
- 6.3 Requirements for the Use of the DMA Resource
- 6.4 Logical Channel
- 6.5 Data Transfer Properties
- 6.6 Data Transfer Synchronization
- 6.7 Abstract Interface
- 6.8 Resource Characterization
- 6.9 Runtime APIs
- 6.10 Strong Ordering of DMA Transfer Requests
- 6.11 Submitting DMA Transfer Requests
- 6.12 Device Independent DMA Optimization Guideline
- 6.13 C6xxx Specific DMA Rules and Guidelines
- 6.14 C55x Specific DMA Rules and Guidelines
- 6.15 Inter-Algorithm Synchronization
- A Rules and Guidelines
- B Core Run-Time APIs
- C Bibliography
- D Glossary
![](/manual/texas-instruments/tms320-dsp/computer-hardware-algorithm-standard-users-guide/images/img-35.png)
www.ti.com
3.3.2 Header Files
3.3.3 Debug Verses Release
Packaging
<module> is the name of the module (containing characters from the set [a-z0-9]),
<vers> is an optional version number of the form v<num> where num consists of
characters from the set [0-9],
<vendor> is the name of the vendor (containing characters from the set [a-z0-9]),
<arch> is an identifier indicating the DSP architecture (from the set 24, 281, 54, 54f, 54m,
55l, 62, 62e, 64, 64e, 67, 67e) These identifiers have the following meanings:
• 24 - TMS320C2400 object files
• 281 - TMS320C2800 large model object files
• 54 - TMS320C5400 near call/return object files
• 54f - TMS320C5400 far call/return object files
• 54m - TMS320C5400 mixed call/return object files
• 55l - TMS320C5500 large model object files
• 62 - TMS320C6200 little endian object files
• 62e - TMS320C6200 big endian object files
• 64 - TMS320C6400 little endian object files
• 64e - TMS320C6400 big endian object files
• 67 - TMS320C6700 little endian object files
• 67e - TMS320C6700 big endian object files
Rule 16
Each eXpressDSP-compliant algorithm header must follow a uniform naming convention.
In addition to the object Code implementation of the algorithm, each eXpressDSP-compliant module
includes one or more interface headers. In order to ensure that no name conflicts occur, we must adopt a
naming convention for all header files. C language headers should be named as follows:
<module><vers>_<vendor>.h
Assembly language headers should be named as follows:
<module><vers>_<vendor>.h<arch>
A single vendor may produce more than one implementation of an algorithm. For example, a "debug"
version may include function parameter checking that incurs undesirable overhead in a "release" version.
A vendor may even decide to provide multiple debug or release versions of a single algorithm. Also, each
version may make different tradeoffs between time and space overhead.
In order to easily manage the common case of debug and release versions of the same algorithm within a
TMS320 DSP Algorithm Standard development environment, it is important to adopt a naming convention
that makes it easy to ensure that a eXpressDSP-compliant application is built from a uniform set of
components. For example, it should be easy to ensure that an application is built entirely from release
versions of eXpressDSP-compliant components.
Rule 17
Different versions of a eXpressDSP-compliant algorithm from the same vendor must follow a uniform
naming convention.
SPRU352G – June 2005 – Revised February 2007 Algorithm Component Model 35
Submit Documentation Feedback