Texas Instruments TMS320 DSP User Manual Page 71
- Page / 88
- Table of contents
- BOOKMARKS
Rated. / 5. Based on customer reviews
www.ti.com
6.14.2 Minimizing Logical Channel Reconfiguration Overhead
6.14.3 Addressing Automatic Endianism Conversion Issues
6.15 Inter-Algorithm Synchronization
6.15.1 Non-Preemptive System
Inter-Algorithm Synchronization
Some common C55x DMA devices impose additional restrictions that affect when a channel needs to be
reconfigured. A logical channel needs to be reconfigured when the source or destination addresses refer
to different memory ports (SARAM, DARAM, EMIF) compared with the most recently configured channel
settings.
Additionally, utilizing the reload registers is not possible when the source or destination addresses
correspond to different memory ports currently being used by the ongoing transfer.
DMA Guideline 5
C55x algorithms should minimize channel configuration overhead by requesting a separate logical
channel for each different transfer type. They should also call ACPY2_configure when the source or
destination addresses belong in a different type of memory (SARAM, DARAM, External) as compared
with that of the most recent transfer.
Some C55x/OMAP architectures perform on-the-fly endianism conversion during DMA transfers between
DSP internal Memory (SARAM/DARAM) and external memory (via EMIF). Certain coherency problems
may arise due to automatic enabling/disabling of endianism conversion by the hardware, based on DMA
transfer settings, CPU access modes, and address alignments. In order to ensure correct operation of
general C55x algorithms on hardware with automatic endianism conversion following rules regarding
alignment, size, and access, all rules for data buffers that may reside in external memory must be
followed.
DMA Rule 10
C55x algorithms must request all data buffers in external memory with 32-bit alignment and sizes in
multiples of 4 (bytes).
DMA Rule 11
C55x algorithms must use the same data types, access modes and DMA transfer settings when reading
from or writing to data stored in external memory, or in application-passed data buffers.
An ideal system with unlimited DMA resources would assign a physical DMA channel to each logical
channel requested by the algorithms comprising the system. Unfortunately, the DMA resource is limited
and some of the physical DMA channels may be used for other system functions such as servicing serial
ports etc. As such, a variety of application scenarios are possible with regards to sharing physical DMA
channels. Let's consider two scenarios to illustrate how this can be dealt with: a non-preemptive system
and a preemptive system.
Assume a system with one physical DMA channel that has been assigned to be used by two algorithms.
The algorithms require one logical channel each. The algorithms do not preempt each other.
We know from DMA Rule 1 that upon return from the algorithm functions, the DMA is not active. The
system can easily share this single DMA channel among the two algorithms, since they will run
sequentially and use the DMA channel sequentially. See Section 6.15.2 .
SPRU352G – June 2005 – Revised February 2007 Use of the DMA Resource 71
Submit Documentation Feedback
- User's Guide 1
- Submit Documentation Feedback 2
- Contents 3
- Read This First 7
- Related Documentation 8
- Text Conventions 8
- Overview 9
- 1.1 Scope of the Standard 10
- 1.1.1 Rules and Guidelines 11
- 1.3 Goals of the Standard 12
- 1.4 Intentional Omissions 12
- 1.5 System Architecture 13
- 1.5.1 Frameworks 13
- 1.5.2 Algorithms 14
- 1.5.3 Core Run-Time Support 14
- Chapter 2 15
- 2.1 Use of C Language 16
- 2.2 Threads and Reentrancy 16
- 2.2.1 Threads 16
- 2.2.3 Reentrancy 17
- 2.2.4 Example 18
- 2.3 Data Memory 19
- 2.3.1 Memory Spaces 20
- Data Memory 21
- 2.4 Program Memory 23
- 2.5 ROM-ability 23
- 2.6 Use of Peripherals 24
- Algorithm Component Model 25
- 3.1 Interfaces and Modules 26
- 3.1.1 External Identifiers 27
- 3.1.2 Naming Conventions 28
- 3.1.4 Module Instance Objects 28
- Interfaces and Modules 29
- 3.1.7 Module Configuration 30
- 3.1.8 Example Module 30
- 3.1.10 Interface Inheritance 32
- 3.1.11 Summary 32
- 3.2 Algorithms 33
- 3.3 Packaging 34
- 3.3.1 Object Code 34
- 3.3.2 Header Files 35
- 3.3.3 Debug Verses Release 35
- Packaging 36
- Chapter 4 37
- 4.1 Data Memory 38
- 4.1.1 Heap Memory 38
- 4.1.2 Stack Memory 39
- 4.2 Program Memory 40
- 4.3 Interrupt Latency 41
- 4.4 Execution Time 41
- 4.4.1 MIPS Is Not Enough 41
- 4.4.2 Execution Time Model 42
- Execution Time 43
- DSP-Specific Guidelines 45
- 5.1 CPU Register Types 46
- 5.2 Use of Floating Point 47
- 5.3.1 Endian Byte Ordering 47
- 5.3.2 Data Models 47
- 5.3.3 Program Model 47
- 5.3.4 Register Conventions 48
- 5.3.5 Status Register 48
- 5.3.6 Interrupt Latency 49
- 5.4.1 Data Models 49
- 5.4.2 Program Models 49
- 5.4.3 Register Conventions 51
- 5.4.4 Status Registers 51
- 5.4.5 Interrupt Latency 52
- 5.5.1 Stack Architecture 52
- 5.5.2 Data Models 52
- 5.5.3 Program Models 53
- 5.5.4 Relocatability 53
- 5.5.5 Register Conventions 54
- 5.5.6 Status Bits 55
- 5.6 TMS320C24xx Guidelines 57
- 5.6.1 General 57
- 5.6.2 Data Models 57
- 5.6.3 Program Models 57
- 5.6.4 Register Conventions 57
- 5.6.5 Status Registers 58
- 5.6.6 Interrupt Latency 58
- 5.7.1 Data Models 58
- 5.7.2 Program Models 59
- 5.7.3 Register Conventions 59
- 5.7.4 Status Registers 59
- 5.7.5 Interrupt Latency 60
- Use of the DMA Resource 61
- 6.1 Overview 62
- 6.2 Algorithm and Framework 62
- 6.4 Logical Channel 63
- 6.5 Data Transfer Properties 64
- 6.7 Abstract Interface 65
- 6.8 Resource Characterization 66
- 6.9 Runtime APIs 67
- 6.15.1 Non-Preemptive System 71
- 6.15.3 Preemptive System 72
- Rules and Guidelines 75
- A.1 General Rules 76
- A.3 DMA Rules 77
- A.4 General Guidelines 78
- A.5 DMA Guidelines 79
- Core Run-Time APIs 81
- Bibliography 83
- Glossary 85
- Glossary of Terms 86
© 2020, manymanuals.com. All rights reserved. | 2.095 s |
Manymanuals.com
Manymanuals.de
Manymanuals.fr
Manymanuals.it
Manymanuals.pl
Manymanuals.cz
Manymanuals.es
Manymanuals-pt.com
Comments to this Manuals