TMS320DSP算法标准_XDAIS_及参考构架RF5综述

框架参考框架。

RF5适用于含有多通道和多算法结构的高密集度应用程序。

与低等级参考框使用线程(任务TSK)阻塞，可用于包含线程间有复杂依赖关系的应用程序。

另还具有可变的通道管理、基于任务TSK的应用程序、高效的任务间通信，以及结构化的线程安全控制机制，且易于替换I／O驱动设备和易于调试。

参考框架最重要的要求就是保证易于与用户硬件接口。

每一个参考架构均被打包成基于开发工具包或其他板卡的完整的应用程序。

针对每一个板卡，可以提供不同等级的参考框架。

对应用软件进行调整以适合参考框架，主要有3个基本要求：调整算法单元和改变通道数量；调整应用程序以使其适应硬件系统；改变驱动以利于运行终端硬件。

了一个通道基础框架，使其很容易就可以封装XDAIS算法。

通过这一封装，应用程序设计1．1RF5数据处理RF5共有4个基本的数据处理部件：任务(task)、通道(channel)、单元(cell)和标准算法(XDAIS algorithm)。

它们之间的关系如图3所示。

通常，一个任务中可以包括一个或多个通道，每个通道中可以包括一个或多个单元，而每个单元中则封装有一个XDAIS算法。

单元封装XDAIS算法的作用在于：提供算法与外部世界的一个标准接口，每个单元执行一个简单的ICELL接口，通过该接口执行算法。

利用通道可以按序执行多个单元，在典型应用中，多个通道可能包含一套执行功能相同的单元序列。

利用任务可以同时处理一个或多个通道，其目的在于组织任务间的数据通信和设备驱动会话等。

与通道不同的是，任务有具体的执行代码，并需要用户自己编写。

该部分代码通常是从外界接收数据、控制通道执行等。

每个任务总是反复执行自己的代码，完成检查控制信息、获得数据、执行通道、发送数据等操作。

1．2RF5中数据通信RF5中的数据通信包括task级通信和cell级通信。

其通信机理为使用结构体进行信息传递，而非通过全局变量传输处理数据。

1．2．1t ask级通信任务级通信主要用到了SCOM消息队列和邮箱(MBX)。

DSP原理与应用大作业姓名：潘俊涛班级：应电121班学号：1204141192014年6月第1部分概述一、DSP简介；当德州仪器（TI）公司在1982年研发出第一款商用数字信号处理器是，谁也不会想到它竟能给世界带来如此大的变化。

从移动通信到消费电子领域，从汽的第一代数字信号处理器仅包含了55000个晶体管，4KB内存处理指令只有5MIPS （每秒百万条）,经过二十余年的发展，单核数字信号处理器的处理能力已经达到9600MIPS的惊人速度，寻址能力高达1280MB。

而第三代数字信号处理器则以其强大的数字信号处理能力、超低功耗和适合手持设备的超小型封装的等特点，较好的满足了新一代电子产品的要求。

二、DSP的发展；20世纪60年代以来，随着信息技术的不断进步，数字信号处理系统也应运而生并得到迅速的发展。

80年代以前，由于方法的限制，数字信号处理技术处于理论研究阶段，还得不到广泛的应用。

在此阶段，人们利用通用计算机进行数字滤波、频谱分析等算法的研究，以及数字信号处理系统的模拟和仿真。

实施数字信号处理对数字信号处理系统的处理能力提出了严格的要求，所有运算、处理都必须小于系统可接受的最大时延。

典型的数字信号处理系统的基本部分：抗混叠滤波器、模/数转换器、数字信号处理、数/模转换器和抗镜像滤波器。

以下几种问为当前实用的数字信号处理系统:1、利用X86处理器完成实时数字信号处理2、利用通用微处理器成实时数字信号处理3、利用可编程逻辑阵列（FPGA）进行成实时数字信号处理4、利用数字信号处理器（DSP）实现数字信号处理三、DSP的特点；DSP系统的应用领域极其广泛，目前主要的应用领域如下：基本信号处理、通信、语音、图形图像、军事、仪器仪表、控制、医疗和家用电器。

DSP最大的应用领域是通信，并且军事领域是高性能DSP的天地。

众所周知，微处理器的存储结构分为两大类：冯.诺伊曼结构和哈弗结构。

DSP广泛使用冯.诺伊曼结构。

Application ReportSPRA577B Using the TMS320 DSP Algorithm Standard in aStatic DSP System Carl Bergman Digital Signal Processing Solutions AbstractThe TMS320 DSP Algorithm Standard is part of TI's eXpressDSP (XDAIS) technologyinitiative. It allows system designers to easily integrate algorithms from a variety ofsources (e.g., third parties, customers). However, in system design, flexibility comes witha price.This price is paid in CPU cycles and memory space, both critical in all DSP systems, but perhaps most critical in a static system. For this application note, a static system isdefined as one in which memory is allocated once and is used for the remainder of thesystem's life – there is no effort to reclaim or reuse memory. In contrast, a dynamicsystem is one in which the memory is reused while the application is executing. Adynamic system takes advantage of the available memory by sharing it betweenalgorithms, by reclaiming it when an algorithm is deactivated, and by reusing it whenanother algorithm is activated.Algorithms that comply with the TMS320 DSP Algorithm Standard are tested andawarded an eXpressDSP compliant mark upon successful completion of the test. Thisapplication note shows how an eXpressDSP-compliant algorithm may be used effectively in a static system with limited memory. It examines some optimizations and illustratesthem with a very simple example: an algorithm that copies input to output. The impact interms of code size, data size, and CPU cycles will be demonstrated.ContentsTheory of Operation (3)Review of TMS320 DSP Algorithm Standard Fundamentals (3)Naming Conventions (3)Interface Function Summary (4)Sequence of Builds (6)Build 1: No eXpressDSP Interface – Access Algorithm Directly (6)Build 2: Using the High Level Interface, 'CPY' (8)Build 3: Using and Removing Subsections in the Linker Command File (10)Build 4: Removing the Code from the CPY High-Level Interface (12)Build 5: Using Only the SPI – Creating the Object at Design Time (12)Conclusion (13)References (14)TI Contact Numbers (15)FiguresFigure 1.Test Program (6)Figure 2.Build 1 Code Size (8)Figure ing the TMS320 Algorithm Standard Interface (9)Figure 4.Build 2 Code Size (10)Figure 5.Define Subsections (11)Figure 6.NOLOAD Section in Linker Command File (11)Figure 7.Build 3 Code Size (11)Theory of OperationThe TMS320 DSP Algorithm Standard provides a general-purpose interface that allowsefficient use of a large variety of algorithms in a large variety of systems. However, thefull capability of the interface may not be useful in all systems. In a static system wemight allocate memory at design-time and initialize the algorithm at power-on and neverchange anything else. In such a system, the code implementing the create and deletefunctions, although never used, would take up valuable memory.This application note follows an example program through a sequence of steps aimed at reducing code size by linking only the required functions. The unused code is assigned toa subsection that will not be loaded by the linker. The steps in the examples involveincrementally more programming effort. The result is that the code is smaller and lessmemory is used.We begin with a typical implementation of the interface and then illustrate the processwith several optimizations. The first build provides a baseline for comparison. It calls the algorithm directly with no algorithm standard interface. The second build adds the fullalgorithm standard interface. The remaining examples simplify the use of the interfaceand recover the memory from the unused functions.Review of TMS320 DSP Algorithm Standard Fundamentals Some of the key structures of an eXpressDSP-compliant algorithm are:X Memory Table: Describes what memory the algorithm needs in order to operateX Creation Parameters: Describes how the algorithm should be initializedX Status Information: Describes the current state of the algorithmX Function Table: Describes the operations available for the algorithmThere are two levels of access to the algorithm:1) The service provider interface (SPI) provides the most direct access.2) The application programmer's interface (API) provides an alternate, more convenientinterface.The high-level functions of the API use the SPI to create and control the algorithm and to process data.Naming ConventionsThe TMS320 Algorithm Standard naming convention ensures that implementations of the same algorithm from different vendors can co-exist without duplicate symbols. This ismade possible by defining a two-part prefix to external symbols. Part one of the prefixrepresents the algorithm and part two represents the vendor.In our example, the symbol for the 'copy' algorithm is the mnemonic 'CPY'. The symbol for the vendor “Texas Instruments” is the acronym 'TI'. This yields the prefix 'CPY_TI_'.An example of a function name using this prefix would be CPY_TI_create(). This name indicates that TI implements the create function for the copy algorithm.An example of an interface name would be 'CPY_TI_ICPY'. This name indicates that TI implements the interface to the copy algorithm (ICPY) for the copy algorithm. This maysound redundant, but there are other possible interfaces to the copy algorithm. Forexample, the test interface (ITST) in this example would be named 'CPY_TI_ITST'. Interface Function SummaryThe functions that implement the two levels of access (API and SPI) may be organizedaccording to whether they apply to all algorithms (generic), apply to a specific algorithm (algorithm-specific), or apply to a specific implementation of an algorithm (vendor-specific). The naming convention helps here as well. The generic create function would be ALG_create(). The algorithm-specific create function would be CPY_create() with the copy algorithm mnemonic as a prefix. The vendor-specific function (if TI was the vendor) would have the name CPY_TI_create().Functions beginning with 'CPY_' (Algorithm Specific API)The algorithm-specific API is the most convenient access to the algorithm and is asuperset of the TMS320 algorithm standard API.CPY_activate()Prepare the algorithm to runCPY_control()Command and status mechanismCPY_create()Allocate memory and initialize a new algorithm instanceCPY_deactivate()Prepare the algorithm to be inactive or possibly deletedCPY_delete()Remove algorithm instance and deallocate the memory usedCPY_exit()Finalize module other than deleting algorithm instanceCPY_init()Initialize module other than creating algorithm instanceCPY_process()Process dataFunctions Beginning With 'ALG_' (Standard API)The following do not include the algorithm-specific processing function calls.ALG_activate()Prepare the algorithm to runALG_control()Command and status mechanismALG_create()Allocate memory and initializes a new algorithm instanceALG_deactivate()Prepare the algorithm to be inactive or possibly deletedALG_delete()Remove algorithm instance and deallocate the memory usedALG_exit()Finalize module other than deleting algorithm instanceALG_init()Initialize module other than creating algorithm instanceThe CPY_IALG Interface (Standard SPI)The IALG interface functions are described in the comments field of the ialg.h file./** ======== IALG_Fxns ========* This structure defines the fields and methods that must be supplied by* all XDAIS algorithms.** implementationId - unique pointer that identifies the module* implementing this interface.* algActivate() - notification to the algorithm that its memory* is "active" and algorithm processing methods* may be called. May be NULL; NULL => do nothing.* algAlloc() - apps call this to query the algorithm about* its memory requirements. Must be non-NULL.* algControl() - algorithm specific control operations. May be* NULL; NULL => no operations supported.* algDeactivate() - notfication that current instance is about to* be "deactivated". May be NULL; NULL => do nothing. * algFree() - query algorithm for memory to free when removing* an instance. Must be non-NULL.* algInit() - apps call this to allow the algorithm to* initialize memory requested via algAlloc(). Must* be non-NULL.* algMoved() - apps call this whenever an algorithms object or* any pointer parameters are moved in real-time.* May be NULL; NULL => object can not be moved.* algNumAlloc() - query algorithm for number of memory requests.* May be NULL; NULL => number of mem recs is less* then IALG_DEFMEMRECS.*/The CPY_ICPY Interface (Standard SPI Plus Algorithm Extensions) The algorithm extensions provide the data processing function.cpyProcess()Copy data from input buffer to output bufferThe CPY_TI_ICPY Interface (Standard SPI Plus Algorithm Extensions Plus Vendor's Extensions)The copy algorithm has no vendor extensions.Sequence of BuildsBuild 1: No eXpressDSP Interface – Access Algorithm Directly The first build is for comparison purposes. The test program accesses the algorithmdirectly. The copy algorithm only needs the count field in the object and the input andoutput data buffers. Note that the eXpressDSP header files are included to support theuse of the ICPY_TI_Obj structure, which is expected by the algorithm. Figure 1 showsthe code from main() of the test program.The system resources used are measured in terms of code size and CPU cycles. Thecode size is shown in the excerpt from the linker map file in Figure 2. The CPU cycles for the data processing function are determined with the profiler in Code Composer Studio[1].Program Memory Used37,408 bytesData Memory Used4,480 bytesCPU Cycles Used20441 (average of 3 runs on a C6201 EVM card)Figure 1.Test Program/** build1.c*/#include <stdio.h> // access to printf()#include <std.h> // basic data types#include <xdais.h> // XDAIS data types#include <ialg.h> // IALG standard#include <icpy.h> // ICPY standard#include <icpy_ti.h> // ICPY implementation#include <copydata.h> // algorithm implementation/* test data */#define COPY_COUNT 16#define BUFFER_SIZE 80Char * testString = "eXpress DSP Algorithm Standard";Char buffer[BUFFER_SIZE];Int main(){ICPY_TI_Handle handle;ICPY_TI_Obj cpyObj;Char *cp, *input, *output;Int i;printf("build1 1999 0802 1036\n");/* init test buffers ---------------------------------------- */input = testString;output = buffer;/* clear output buffer */cp = output;for (i = BUFFER_SIZE; i > 0; i--) {*cp++ = (Char)0;}printf("input: %s\n", input);printf("output: %s\n", output);/* init the algorithm ---------------------------------------*/handle = (ICPY_TI_Handle)&cpyObj;/* if create failed then exit (can't happen but keep consistent) */ if (handle == NULL) {printf ("object creation failed\n");exit(1);}else {printf ("object created\n");}/* use the algorithm ----------------------------------------*//* set the count of bytes to copy */printf ("cpyControl\n"); // for fair code comparisonprintf ("ICPY_SET_COPY_COUNT\n"); // for fair code comparisoncpyObj.count = 5;i = 1; // place profile point here/* do the copy operation */printf ("cpyProcess\n"); // for fair code comparisoncopyData(handle, input, output);i = 0; // place profile point here/* report results ------------------------------------------- */printf("copy %d bytes, output: %s\n", cpyObj.count, output);printf("end of build1\n");/* for fair code size comparison: from the control function */ printf ("ICPY_READ_STATUS\n");printf ("ICPY_WRITE_STATUS\n");printf ("default case!\n");return(0);}Figure 2.Build 1 Code SizeMEMORY CONFIGURATIONname origin length used attributes fill-------- -------- --------- -------- ---------- -------- PMEM 00000000 000010000 00000000 RWIXEXT0 00400000 000040000 00000000 RWIXEXT1 01400000 000300000 00000000 RWIXEXT2 02000000 000400000 00009220 RWIXEXT3 03000000 000400000 00000000 RWIXDMEM 80000000 000010000 00001180 RWIXSECTION ALLOCATION MAPsection page origin length input sections-------- ---- ---------- ---------- ----------------.text 0 02000000 00008500.cinit 0 02008500 00000414.cio 0 02008914 00000120 UNINITIALIZED.far 0 02008a34 000007ec UNINITIALIZED.stack 0 80000000 00000800 UNINITIALIZED.bss 0 80000800 00000054 UNINITIALIZED.const 0 80000854 0000012c.sysmem 0 80000980 00000800 UNINITIALIZEDBuild 2: Using the High Level Interface, 'CPY'The second build represents a baseline of using the copy algorithm in a static systemwith an algorithm standard interface.The code is built using Code Composer Studio (CCStudio) with the followingcomponents:Build2.mak Code Composer Studio Project FileBuild2.c Test Programmem.c Memory Allocation Utilitycpy.c Algorithm Specific High Level Interfacealg.c Standard High Level Interfacecpy.lib Algorithm LibraryBuild2.cmd Linker Command FileSystem resources used:Build 1Build 2ChangeProgram Memory (bytes)37408404563048Data Memory (bytes)44804615135CPU Cycles2044121343902The code in Figure 3 is an excerpt from the function main() in build2.c and shows thefollowing steps:1) Using the high level CPY API, an instance of the algorithm is created.2) The copy count is then changed from the default value with a control call and thecopy process is run on the input and output buffers.3) Finally, a control call is made to retrieve status, which in our case simply proves wecan find out what the copy count was.Figure ing the TMS320 Algorithm Standard Interface/* init the algorithm --------------------------------------- *//* create an instance of the algorithm object */handle = CPY_create(&CPY_ICPY, &paramDefaults);/* if create failed then exit */if (handle == NULL) {printf ("object creation failed\n");exit(1);}else {printf ("object created\n");}/* use the algorithm ---------------------------------------- *//* set the count of bytes to copy */CPY_control(handle, ICPY_SET_COPY_COUNT, (Void *)5);i = 1;/* place profile point here *//* do the copy operation */CPY_process(handle, input, output);i = 0;/* place profile point here *//* read back the copy count */CPY_control(handle, ICPY_READ_STATUS, &status);Figure 4 is an excerpt from the Build 2 linker map file.Figure 4.Build 2 Code SizeMEMORY CONFIGURATIONname origin length used attributes fill-------- -------- --------- -------- ---------- -------- PMEM 00000000 000010000 00000000 RWIXEXT0 00400000 000040000 00000000 RWIXEXT1 01400000 000300000 00000000 RWIXEXT2 02000000 000400000 00009e08 RWIXEXT3 03000000 000400000 00000000 RWIXDMEM 80000000 000010000 00001207 RWIXSECTION ALLOCATION MAPsection page origin length input sections-------- ---- ---------- ---------- ----------------.text 0 02000000 00009080.cinit 0 02009080 0000047c.cio 0 020094fc 00000120 UNINITIALIZED.far 0 0200961c 000007ec UNINITIALIZED.stack 0 80000000 00000800 UNINITIALIZED.bss 0 80000800 0000008c UNINITIALIZED.const 0 8000088c 0000017b.sysmem 0 80000a08 00000800 UNINITIALIZEDBuild 3: Using and Removing Subsections in the Linker Command FileIn the next build, the code is the same as Build 2 (refer to Figure 3). We now addpragma directives to all the interface levels to assign an input subsection for eachfunction statement (see Figure 5). This allows us to selectively include or exclude the subsections in the link process.System resources used:Build 1Build 3ChangeProgram Memory (bytes)37408394322024Data Memory (bytes)44804615135CPU Cycles2044121132691Figure 5.Define Subsections#pragma CODE_SECTION(CPY_activate, ".text:algActivate")#pragma CODE_SECTION(CPY_apply, ".text:algApply")#pragma CODE_SECTION(CPY_control, ".text:algControl")#pragma CODE_SECTION(CPY_create, ".text:algCreate")#pragma CODE_SECTION(CPY_deactivate, ".text:algDeactivate")#pragma CODE_SECTION(CPY_delete, ".text:algDelete")#pragma CODE_SECTION(CPY_exit, ".text:algExit")#pragma CODE_SECTION(CPY_init, ".text:algInit")Subsections are selected in the linker command file. By specifying a NOLOAD outputsection, the unused code is removed from the program image (see Figure 6). The code is built the same way as in Build 2.Figure 6.NOLOAD Section in Linker Command FileSECTIONS{....notUsed {* (.text:algActivate)* (.text:algApply)* (.text:algDeactivate)* (.text:algDelete)* (.text:algExit)* (.text:algInit)* (.text:algMoved)* (.text:algNumAlloc)} type = NOLOAD >EXT3...}Figure 7 is an excerpt from the Build 3 linker map file.Figure 7.Build 3 Code SizeMEMORY CONFIGURATIONname origin length used attributes fill-------- -------- --------- -------- ---------- -------- PMEM 00000000 000010000 00000000 RWIXEXT0 00400000 000040000 00000000 RWIXEXT1 01400000 000300000 00000000 RWIXEXT2 02000000 000400000 00009a08 RWIXEXT3 03000000 000400000 00000400 RWIXDMEM 80000000 000010000 00001207 RWIXSECTION ALLOCATION MAPsection page origin length input sections-------- ---- ---------- ---------- ----------------.text 0 02000000 00008c80.cinit 0 02008c80 0000047c.cio 0 020090fc 00000120 UNINITIALIZED.far 0 0200921c 000007ec UNINITIALIZED.stack 0 80000000 00000800 UNINITIALIZED.bss 0 80000800 0000008c UNINITIALIZED.const 0 8000088c 0000017b.sysmem 0 80000a08 00000800 UNINITIALIZED.notUsed 0 03000000 00000400 NOLOAD SECTIONBuild 4: Removing the Code from the CPY High-Level InterfaceIn the fourth build, we replace the calls to the CPY interface (CPY_* functions) withmacros that call the standard API (ALG_* functions) and the SPI. The three macrosshown replace the corresponding function calls to CPY_control(), CPY_create() andCPY_process().#define CPY_CONTROL(alg, cmd, status) \((alg->fxns->ialg.algControl)((IALG_Handle)alg, cmd, status));#define CPY_CREATE(fxns, prms) \(CPY_Handle)ALG_create((IALG_Fxns *)fxns, (IALG_Params *)prms);#define CPY_PROCESS(alg, input, output) \(alg->fxns->cpyProcess)((ICPY_Handle)alg, input, output);This allows us to eliminate the file cpy.c from our build. The rest remains the same.System resources used:Build 1Build 4ChangeProgram Memory (bytes)37408392241816Data Memory (bytes)44804611131CPU Cycles2044120725284Build 5: Using Only the SPI – Creating the Object at Design TimeIn Build 5, we remove the remaining API code in alg.c from the program. We can do this because we are going to 'create' the object and declare the data structures the algorithm requires at design time in the test program. Four steps are required for this build:1) Allocate the space for the memory descriptor table.memTab =(IALG_MemRec *)malloc(sizeof(memTab[IALG_DEFMEMRECS]));2) Plug in the addresses of our allocated object and working memory to the memorydescriptor table.memTab[CPY_OBJ_DATA].base =(void *)malloc(sizeof(ICPY_TI_Obj));memTab[CPY_DATA_RAM].base =(void *)malloc(sizeof(cpyDataRam));3) Set the value of our handle to the algorithm. We also set the address of the functiontable in the object. Previously ALG_create() set the function table address andreturned the value of our handle.handle = (CPY_Handle)memTab[CPY_OBJ_DATA].base;handle->fxns = &CPY_ICPY;4) Initialize the algorithm. For this, we call the SPI directly with the parameters itexpects. If the initialization fails, the handle is set to NULL.if (handle->fxns->ialg.algInit((IALG_Handle)handle, memTab,NULL, (IALG_Params *)&paramDefaults) != IALG_EOK) {handle = NULL;}Now with alg.c and mem.c removed from the program (memory allocation is no longerused) and with the subsection .text:algAlloc placed in the .notUsed section, we build theprogram as before.System resources used:Build 1Build 5ChangeProgram Memory (bytes)3740838232824Data Memory (bytes)44804611131CPU Cycles2044120653212ConclusionThese build techniques allowed us to reduce the program memory overhead for using the algorithm standard from 3048 bytes to 824 bytes, a 70% reduction. This wasaccomplished by using only the service provider interface (SPI) and by placing unusedcode in a NOLOAD section.Build 1Build 2Build 3Build 4Build 5Program Memory3740840456394323922438232Change304820241816824Percent of XDAIS100.00%66.40%59.58%27.03%The data memory was not really affected, with a change of only 4 bytes from Build 3 toBuild 4.Build 1Build 2Build 3Build 4Build 5Data Memory44804615461546114611Change From Build 1135135131131The CPU cycle count for the data processing call was measured with the profiler in Code Composer Studio. Because our copy algorithm has only 160 bytes of code, it is important to note that the percentage of overhead of the algorithm standard interface in a morerealistic algorithm would be much smaller than what is shown.With that in mind, the most direct use of the SPI gives us a cycle count of 212 – a littlemore than 1% of the total cycles used in the data processing call. This is less than 24%of the 902 cycles used with the full algorithm standard interface in Build 2.Build 1Build 2Build 3Build 4Build 5CPU Cycles2044121343211322072520653Change902691284212Percent of Total 4.41% 3.38% 1.39% 1.04%In an actual case with a G.723 algorithm, the processing call takes an average of375,000 cycles, and the overhead of 212 cycles would be less than 0.1%. The overhead of the full interface at 902 cycles would be less than 0.25%.Finally, the following chart summarizes the improvements in program memory for the examples given.eXpressDSP Overhead On Program Memory1000200030004000Build 2Build 3Build 4Build 5B y t e s References1.Code Composer Studio User's Guide , SPRU328.2.TMS320C6000 Assembly Language Tools User's Guide , SPRU186.3.TMS320 DSP Algorithm Standard Rules and Guidelines , SPRU352.4. TMS320 DSP Algorithm Standard API Reference, SPRU360.TI Contact NumbersINTERNETTI Semiconductor Home Page/scTI Distributors/sc/docs/distmenu.htm PRODUCT INFORMATION CENTERS AmericasPhone+1(972) 644-5580Fax +1(972) 480-7800Email sc-infomaster@ Europe, Middle East, and Africa PhoneDeutsch+49-(0) 8161 80 3311 English+44-(0) 1604 66 3399 Español+34-(0) 90 23 54 0 28 Francais+33-(0) 1-30 70 11 64 Italiano+33-(0) 1-30 70 11 67 Fax+44-(0) 1604 66 33 34 Email epic@JapanPhoneInternational+81-3-3344-5311 Domestic0120-81-0026FaxInternational+81-3-3344-5317 Domestic0120-81-0036Email pic-japan@ AsiaPhoneInternational+886-2-23786800 DomesticAustralia1-800-881-011TI Number-800-800-1450China10810TI Number-800-800-1450Hong Kong800-96-1111TI Number-800-800-1450India000-117TI Number-800-800-1450Indonesia001-801-10TI Number-800-800-1450Korea080-551-2804Malaysia1-800-800-011TI Number-800-800-1450New Zealand000-911TI Number-800-800-1450Philippines105-11TI Number-800-800-1450Singapore800-0111-111TI Number-800-800-1450Taiwan080-006800Thailand0019-991-1111TI Number-800-800-1450Fax886-2-2378-6808Email tiasia@TI is a trademark of Texas Instruments Incorporated.Other brands and names are the property of their respective owners.IMPORTANT NOTICETexas Instruments and its subsidiaries (TI) reserve the right to make changes to their products or to discontinue any product or service without notice, and advise customers to obtain the latest version of relevant information to verify, before placing orders, that information being relied on is current and complete. All products are sold subject to the terms and conditions of sale supplied at the time of order acknowledgment, including those pertaining to warranty, patent infringement, and limitation of liability.TI warrants performance of its semiconductor products to the specifications applicable at the time of sale in accordance with TI’s standard warranty. Testing and other quality control techniques are utilized to the extent TI deems necessary to support this warranty. Specific testing of all parameters of each device is not necessarily performed, except those mandated by government requirements.Customers are responsible for their applications using TI components.In order to minimize risks associated with the customer’s applications, adequate design and operating safeguards must be provided by the customer to minimize inherent or procedural hazards.TI assumes no liability for applications assistance or customer product design. TI does not warrant or represent that any license, either express or implied, is granted under any patent right, copyright, mask work right, or other intellectual property right of TI covering or relating to any combination, machine, or process in which such semiconductor products or services might be or are used. TI’s publication of information regarding any third party’s products or services does not constitute TI’s approval, warranty or endorsement thereof.Copyright © 2000, Texas Instruments Incorporated。

目录摘要 (I)Abstract (II)1绪论 (1)1.1图像处理的研究背景 (1)1.2图像处理国内外研究现状 (2)1.3 图像处理研究内容及意义 (4)1.3.1图像处理研究内容 (4)1.3.2本文的研究意义 (5)1.4 小结 (6)2 基于DSP的开发系统 (7)2.1 DSP系统简介 (7)2.2 DSP芯片 (7)2.2.1 DSP芯片的基本结构 (8)2.2.2 DSP芯片的种类 (8)2.2.3世界主要的DSP芯片制造公司及其产品 (9)2.2.4 DSP发展现状及应用简介 (10)2.2.5 DSP技术展望 (12)2.3 DSP芯片的特点 (12)2.4图像处理中DSP芯片的选择 (15)2.5基于DSP的图像处理系统 (16)3 CCS开发环境的应用与仿真 (17)3.1 CCS的安裝及简介 (17)3.1.1 CCS简介 (17)3.1.2 CCS的安装使用 (19)3.1.3 CCS的配置与使用 (21)3.2仿真处理分析 (22)4基于DSP的图像处理 (24)4.1图像处理的基本概念 (24)4.2图像处理的硬件系统 (24)4.2.1 TMS320C6000 DSP芯片的硬件系统 (24)4.2.2 TMS320C6000的硬件结构简介 (26)4.2.3试验平台评估 (28)4.3基于DSP的图像处理实现 (29)4.3.1图像直方图统计 (29)4.3.2数字图像边缘检测sobel 算子 (30)4.3.3数字图像锐化laplace 算子 (32)4.3.4图像取反 (35)4.3.5数字图像直方图均衡化增强 (36)4.4试验及结果分析 (37)结论 (42)致谢 (43)参考文献 (44)附录 (45)1绪论1.1图像处理的研究背景数字图像处理又称为计算机图像处理在国外最早出现于20世纪50年代，当时的电子计算机已经发展到一定水平，人们开始利用计算机来处理图形和图像信息。

DSP学习进阶学习TI的各种DSP，本着循序渐进的原则，可以分为多个层次在这里总结一下各个层次的进阶：1、DSP2000（除了2812）：进阶：标准C -> C和汇编混合编程说明：把DSP2000当作单片机来玩就可以了，非常简单。

2、DSP5000（包括DSP2812）主要：标准C -> C和汇编混合编程-> DSP/BIOS -> RF3说明：DSP5000是个中等产品，性能不高不低，基本上也没有开发难度。

3、DSP6000主要：标准C -> C和汇编混合编程-> DSP/BIOS -> XDAIS -> RF5 说明：DSP6000的开发难度明显增大，不论是硬件还是软件。

还分为两种档次：（1）DSP62XX & DSP67XX：开发这两类DSP，硬件上会初步遇到信号完整性问题，软件方面来说，DSP/BIOS是必需的，复杂的程序还需要XDAIS和RF3、RF5的知识。

（2）DSP64XX：开发难度比较大，硬件方面需要重点考虑系统合理架构问题，信号完整性问题；软件方面，需要综合运用各种比较先进、专业的知识，例如用DSP/BIOS作为RTOS，用RF5作为程序架构，尽量采用MiniDriver来编写底层驱动程序等。

如果深入编程，还会遇到令人困惑的Cache冲突问题（虽然TI最近专门针对这个难题升级了CCS），等等。

另外还有一些辅助知识，根据自己需要可以选学：1、GEL：推荐所有阶段的开发者都要学；2、RTDX：一般来说没有必要学习；3、CCS中的C++面向对象编程技术：不建议采用；4、CSL：对于DSP6000以上的开发，必须的；5、各种DSP库函数：对于复杂算法程序，建议学习。

TMS320C54xDSP原理及应用学习心得前言TMS320C54xDSP是一款高性能数字信号处理器，它以其出色的运算速度和丰富的资源而广泛用于音视频处理、工业自动化等领域。

在本文中，我将分享我的学习心得和对该DSP的一些应用理解。

硬件架构TMS320C54xDSP采用了Harvard结构，同时拥有两个数据存储器：P(M)Memory和Data(M)Memory。

其中，P(M)Memory用于存放程序代码和常量，Data(M)Memory则用于存放数据和中间结果。

此外，该DSP还具有丰富的外设资源，如定时器、中断控制器、GPIO等。

运算部件TMS320C54xDSP包含多个运算部件，其中最常用的是乘法器和累加器。

乘法器包括一系列独立的32位乘法器和累加器。

而累加器则用于实现多个数据的加减运算。

此外，该DSP还具有一定程度的并行计算能力，即能够同时执行多个指令。

指令集TMS320C54xDSP支持多种指令集，如算术指令、逻辑指令、移位指令等。

在实际应用中，我们可以根据具体需求选择不同的指令集来完成相应的任务，从而提高运算效率和减少功耗。

应用实例下面，我将以数字信号滤波为例，简要介绍TMS320C54xDSP的应用实例。

假设我们要对一段音频数据进行低通滤波，那么我们可以按照以下步骤来进行计算：1.从P(M)Memory中读取滤波器系数。

2.从Data(M)Memory中读取音频数据。

3.将滤波器系数和音频数据送入乘法器中进行乘法运算。

4.将累加器的值累加，并将结果写入Data(M)Memory中。

5.重复步骤2-4，直到所有数据都被处理完毕。

通过使用TMS320C54xDSP，我们可以快速、高效地完成数字信号滤波过程。

同时，该DSP还可以广泛应用于其他领域，如图像处理、控制系统等。

从学习的角度来看，TMS320C54xDSP的掌握不仅可以帮助我们更好地理解数字信号处理的基本原理，也可以提高我们的工程实践能力。

大家在阅读的时候使Word成折叠模式看着会更舒服些。

关于文档里边用到的中文参考资料，附下载地址：/icview-161578-1-1.html前言DSP的本质还是单片机-微机，个人认为，微机类芯片，不论是MCU,ARM还是DSP 甚至是PC上的处理器，我们在学习这类芯片的使用时，首先要学习的便是这些芯片的CPU 核，存储器组织和中断系统。

只有把这几方面的内容掌握之后，你才能说根据其特点来使用这块芯片，Debug时你心中才有数。

至于片上外设，与芯片本身其实并没有太大关系，大可以要使用时再去学习，而且不同芯片的外设其实还都是相通的。

基于此，我把我在学习这类芯片时对于这几块的学习的笔记摘录出来（这篇文档中对是对Ti的TMS320C54x系列的学习笔记），以供大家参考。

我的笔记虽然可能次序，排版，没有市面上的书本组织得好，但我可以说，我决对是面面向应用来写的，而不是为了出书来写的。

市面上的技术类的书，大多数其实只是简单的把官方的文档翻译过来而已，而且在翻译的过程中还省略了很多细节，这些细节其实对于我们的理解和工程开发都是很重要的，另外很多翻译还不准确。

在我的笔记中，中文资料我只是作为一个参考，或者作为一种线索，真正有价值的信息都是来自于我对于官方文档的学习。

每一部分的记录都是以一个新手的态度来写的，这些问题都是新手在学习过程中很可能会遇到或想到的。

虽然排版不好，但当你遇到相关问题或想了解某一块时，把我写的这个Word 文档下载下来，然后使用Word文档的搜索功能搜索自己感兴趣的内容，相信一定会让你得到较为满意的结果的。

不仅是DSP芯片方面的知识笔记，在我向信号处理工程师奋斗的路程上，我对我每一天的学习都作了笔记记录，这些笔记记录都是面向新手，面向细节，面向工程的，都是自己用心的体会。

当有笔记成熟或自成一块时，我会把这些笔记都陆续分享给大家，以供大家在学习或开发过程的参考，希望能为大家节省点时间。

附一张目前自己的笔记文件夹的图。