C55x DSP库基准测试实战：从FFT到FIR的性能与功耗深度解析-拓冰建站

1. 项目概述：为什么我们需要对DSP库进行基准测试？

在嵌入式信号处理的世界里，性能与功耗的平衡是永恒的课题。当你为一个音频处理设备、一个振动传感器节点或一个通信模块选择DSP算法时，你面对的往往不是“哪个算法更优”的理论问题，而是“在给定的时钟周期和毫瓦级功耗预算下，哪个实现方案能跑得更快、更省电”的工程现实。TMS320C55x系列DSP以其低功耗和高能效比，在便携式和电池供电设备中应用广泛。德州仪器（TI）提供的C55x DSP库（DSPLIB）是一套经过深度手工汇编优化的函数集合，涵盖了FFT、FIR滤波、卷积等核心运算。

然而，官方手册（如SPRU422）中提供的“周期估算”只是一个理论值或典型值。在实际的硬件上，缓存行为、内存访问延迟、流水线冲突、乃至供电电压的微小波动，都可能让实际性能与手册数字产生偏差。因此，进行真实的硬件基准测试，是连接算法理论与工程实践的必经桥梁。这不仅是为了验证性能，更是为了在系统集成阶段做出精准的决策：比如，是使用纯软件的FFT，还是启用硬件加速器（HWAFFT）？对于FIR滤波，是选择通用的fir1，还是选择对数据有特殊要求但更快的fir2？这些选择背后，都需要以精确的周期数和可比的功耗数据作为支撑。

本文将以TI官方提供的c55x-benchmarks项目为基础，手把手带你搭建一套从零开始的C55x DSP库性能与功耗基准测试环境。我会基于EZDSP5535开发板和Code Composer Studio（CCS）集成开发环境，详细拆解从项目导入、编译配置、到实际运行测试、解读结果的全过程。更重要的是，我会分享在多年嵌入式开发中积累的关于基准测试的“坑”与技巧，例如如何避免测量开销影响结果、如何为功耗测试配置超长运行时间、以及如何根据自己的需求扩展测试函数。无论你是正在评估C55x平台性能的架构师，还是需要优化现有DSP代码的工程师，这篇文章都能为你提供一套可直接复现的“实战指南”。

2. 测试环境搭建与项目结构解析

工欲善其事，必先利其器。在开始跑分之前，我们必须把测试环境搭建妥当。这个过程看似繁琐，但每一步都关系到后续测试的准确性和便捷性。

2.1 硬件与软件准备清单

你需要准备以下核心组件：

硬件平台：TI EZDSP5535开发套件。这是一款基于TMS320C5535 DSP的低成本评估板，集成了USB仿真器（XDS100v2），方便连接调试。确保你手头有这块板子、USB线以及电源（如果需外部供电）。
软件开发环境：Code Composer Studio (CCS) v6或更高版本。必须确保安装时包含了对C55x系列处理器的支持包。CCS是TI官方的集成开发环境，集成了编译器、调试器和丰富的分析工具。
基准测试源码包：从TI的Git服务器下载apps-c55x-benchmark-master.tar.gz压缩包。这个包包含了所有测试项目的框架、测试向量和链接命令文件。
C55x DSPLIB优化库：从TI的软件仓库下载最新版的DSPLIB安装包（例如SPRC100-C55_DSPLIB-03.00.00.03-Setup.exe）。安装后，我们需要其中的汇编源码文件。

注意：请务必从TI官方渠道获取上述软件和源码。第三方来源的文件可能版本不匹配或经过修改，导致测试结果不一致或编译错误。

2.2 项目目录结构深度解读

将下载的apps-c55x-benchmark-master.tar.gz解压到一个你喜欢的目录，例如C:\TI_Projects\C55x_Benchmark。解压后，你会看到如下目录结构。理解每个文件夹的用途，是灵活使用和扩展该项目的基础：

C55x_Benchmark/ ├── ASM_sources/ # 【核心目录】用于存放所有DSPLIB的汇编优化函数源文件（.asm） ├── cfft1/ # 复数FFT基准测试项目目录 ├── convolve2/ # 卷积（convolve2）测试项目目录 ├── correlation/ # 自相关（Auto-Correlation）测试项目目录 ├── dlmas/ # 标准延迟LMS滤波器测试目录 ├── dlmas_fast/ # 快速延迟LMS滤波器测试目录 ├── fir1/ # 通用FIR滤波器（fir1）测试目录 ├── fir2/ # 快速FIR滤波器（fir2，仅支持偶数长度）测试目录 ├── maxval/ # 求向量最大值（仅数值）测试目录 ├── maxvec/ # 求向量最大值及其索引测试目录 └── include/ # 【关键目录】存放所有测试项目共用的头文件

关键目录解析：

ASM_sources：这是整个测试框架的“发动机库”。你需要将DSPLIB安装后位于c55_dsplib_03.00.00.03\55x_src目录下的所有.asm文件复制到这里。例如，cfft_scale.asm,fir.asm,convolve2.asm等。测试项目在编译时，会从这里链接这些优化后的汇编代码。切记不要修改这些汇编文件，否则将影响测试结果的公正性。
各测试项目目录（如cfft1,fir1）：每个目录都是一个独立的CCS项目雏形。里面通常包含：
- 一个主测试文件（如CFFT_T.c,fir_t.c）：包含main()函数，负责初始化数据、调用被测函数、测量周期并验证结果。
- 数据文件（如*.h）：这些头文件定义了测试用的输入向量、滤波器系数、以及预期的输出结果（用于验证正确性）。
- 链接命令文件（.cmd）：定义了程序段（如.text,.data）在C5535内存中的具体映射地址，这是嵌入式编程的关键。
include目录：包含几个全局头文件，如time.h（用于时钟函数）和项目通用的定义。在配置CCS项目时，我们需要将这个目录的路径添加到编译器的“包含路径”中。

这种结构的设计非常清晰：测试框架（算法流、测量逻辑）与具体的DSP函数实现（汇编库）是分离的。这为我们后续扩展测试其他DSPLIB函数提供了极大的便利。

3. 基准测试核心流程与原理剖析

在深入具体操作前，我们有必要理解这个基准测试套件是如何工作的。其核心算法流程如下图所示，它被所有测试项目共享：

[加载参数] -> [启用时钟并运行函数，记录周期数] -> [对比输出与预期结果，验证正确性] -> [为功耗测量，循环执行函数极多次]

3.1 周期测量原理：`clock()`函数与开销扣除

测试代码使用C标准库的clock()函数来测量CPU周期。其基本模式如下：

#include <time.h> clock_t t1, t2, overhead; long cycle_count; // 1. 测量函数调用本身的开销 t1 = clock(); t2 = clock(); overhead = t2 - t1; // 这个值通常很小，但必须扣除 // 2. 测量目标函数的执行时间 t1 = clock(); DSPF_sp_fftSPxSP(N, ptr_x, ptr_w, ptr_y, brev, n_min, offset, n_max); // 例如，调用FFT函数 t2 = clock(); cycle_count = (long)(t2 - t1 - overhead); printf("Function time (in cycles): %ld\n", cycle_count);

为什么需要测量并扣除开销？在嵌入式精确测量中，clock()函数调用本身也需要消耗几个周期。如果不扣除这个“皮重”，当被测函数本身执行时间很短时（比如几十个周期），测量误差比例会非常大。通过先空跑一次clock()差值，我们得到了测量机制本身的固有开销，从而让后续对目标函数的测量值更接近真实值。这是编写高精度微基准测试（Micro-benchmark）的一个经典技巧。

3.2 功耗测量策略：长时间循环与平均功耗

功耗测量是另一个重要维度。数字电路的动态功耗与开关活动频率直接相关。要测量执行某个DSP函数时的“平均功耗”，必须让该函数持续运行足够长的时间（通常需要几百毫秒到数秒），以便外部的功率测量设备（如精密万用表或功率分析仪）能够捕捉到稳定的电流值。

测试代码通过一个超大的迭代循环来实现这一点：

#define NUMBER_OF_ITERATIONS 10000000L // 一千万次迭代 long i; for (i = 0; i < NUMBER_OF_ITERATIONS; i++) { DSPF_sp_fftSPxSP(...); // 反复执行被测函数 }

关键参数选择：NUMBER_OF_ITERATIONS被定义为一个long型变量，最大值可达约21亿（0x7FFFFFFF）。你需要根据函数单次执行的周期数和系统时钟频率来估算一个合适的值。例如，一个函数单次执行需1000个周期，系统主频为100MHz，那么执行一次需要10微秒。如果你想让它持续运行约1秒钟以供测量，那么迭代次数应设置为1秒 / 10微秒 = 100,000。在调试阶段，可以先将该值设小（如1000），快速验证功能；在进行实际功耗测量时，再将其调整为巨大的数值。

3.3 结果验证机制：确保性能数据的有效性

性能测试的前提是功能正确。每个测试项目在测量周期前后，都会将DSP函数的输出结果与预先计算好的“黄金参考向量”（在数据头文件中）进行比较。如果结果超出允许的误差范围（对于定点DSP，通常是精度误差），测试程序会打印错误信息。只有通过了正确性验证的周期数，才是有意义的性能数据。否则，你可能测量的是一个跑飞了的、产生错误结果的函数的速度，这毫无价值。

4. 实战：以复数FFT（CFFT）项目为例，构建并运行测试

现在，我们以最经典的复数FFT测试项目cfft1为例，完整走一遍在CCS中构建、配置和运行测试的流程。请打开你的CCS，跟着步骤一起操作。

4.1 创建与配置CCS项目

新建项目：在CCS中，点击Project -> New CCS Project。
- Target：选择EZDSP5535。
- Connection：选择Texas Instruments XDS100v2 USB Debug Probe（这是EZDSP5535板载仿真器）。
- Project name：输入cfft1（与目录名一致便于管理）。
- Compiler version：选择你已安装的最新版C5500编译器。
- Project templates and examples：选择Empty Project。千万不要选择带有main.c的模板，因为我们有自己的主文件。
- 点击Finish。
清理与导入项目文件：
- 在项目浏览器中，展开新建的cfft1项目，你会看到一个自动生成的c5535.cmd链接命令文件。右键删除它，我们将使用测试包中自带的、针对性的链接命令文件。
- 右键点击项目名cfft1，选择Add Files...。
- 导航到解压目录下的cfft1文件夹，全选所有文件（.c,.asm,.h,.cmd），点击Open。
- 在弹出的对话框中，选择Copy files。这样会在CCS项目目录下创建这些文件的副本，方便你修改测试参数而不影响原始源码包。
链接优化汇编库文件：
- 再次右键点击项目名cfft1，选择Add Files...。
- 导航到ASM_sources目录。根据cfft1测试的需要，我们通常需要添加以下几个汇编文件：cbrev.asm（位反转函数）、cfft_scale.asm（支持块缩放的FFT）、cfft_noscale.asm（不支持块缩放的FFT）、twiddle.asm（旋转因子表）。选中它们。
- 在弹出的对话框中，这次务必选择Link to files。因为这些是DSPLIB的核心优化代码，我们不希望在不同项目中复制多份，链接可以确保所有项目都指向同一份源文件，便于统一更新。

4.2 设置项目属性与编译路径

这是确保编译成功的关键一步，很多“找不到头文件”或“链接错误”都源于此。

右键点击项目名cfft1，选择Properties。
在属性窗口中，导航到Build -> C5500 Compiler -> Include Options。
在Add dir to #include search path右侧，点击添加图标，选择Add。
我们需要添加两个路径：
- 项目通用头文件路径：${SOURCES_BASE}\include。这里SOURCES_BASE是一个变量，我们需要先定义它。
- 定义 SOURCES_BASE 变量：
  - 在属性窗口中，导航到Resource -> Linked Resources。
  - 点击New...，在Name中输入SOURCES_BASE，在Value中点击Folder...，然后导航到你解压基准测试源码包的根目录（例如C:\TI_Projects\C55x_Benchmark）。点击OK。
- 回到Include Options，添加路径${SOURCES_BASE}\include。现在编译器就知道去哪里找time.h等公共头文件了。
- DSPLIB头文件路径（可选但推荐）：如果你希望编译器能索引DSPLIB的函数声明，可以添加DSPLIB安装目录下的include文件夹路径，例如C:\ti\c55_dsplib_03.00.00.03\include。

4.3 配置测试参数并编译

打开项目中的CFFT_T.c文件，找到文件开头的配置部分。这里是控制测试行为的“开关”：

#define NUMBER_OF_ITERATIONS 1000000L // 迭代次数，功耗测试时需调大 #define FFT_HARDWARE 0 // 0=使用DSP核软件FFT，1=使用硬件FFT加速器(HWAFFT) // 以下是一系列包含数据尺寸和缩放选项的头文件，每次只启用一个 // #include "t1_SCALE.h" // 尺寸 8， 带缩放 // #include "t2_SCALE.h" // 尺寸 16，带缩放 #include "t6_SCALE.h" // 尺寸 256，带缩放 <-- 我们启用这个 // #include "t2_NOSCALE.h" // 尺寸 16，无缩放 // ... 其他尺寸

NUMBER_OF_ITERATIONS：对于初步性能测试，1000000（一百万）次迭代可能已经足够产生稳定的周期计数。对于真实的功耗测量，你可能需要将其增加到数千万甚至上亿。
FFT_HARDWARE：这是关键选择。C5535芯片内部包含一个硬件FFT加速器（HWAFFT）。设置为1将使用硬件加速，通常能大幅降低FFT运算的周期数，但需要关注其精度和适用范围。
头文件选择：通过注释/取消注释来选择合适的测试向量。例如，t6_SCALE.h代表一个256点、使用块缩放的复数FFT测试案例。块缩放（Block Scaling）可以在FFT计算过程中动态调整数据尺度，防止溢出，但会增加一些计算开销。

配置完成后，点击CCS的Project -> Build Project或锤子图标进行编译。如果之前步骤正确，你应该能在控制台看到成功的编译和链接信息，最终生成cfft1.out文件。

4.4 连接硬件、加载程序与运行

创建目标配置文件：如果这是你第一次使用EZDSP5535，需要在CCS中创建目标配置。在View -> Target Configurations打开视图。右键User Defined，选择New Target Configuration，取名如EZDSP5535.ccxml。在配置中，选择连接为Texas Instruments XDS100v2 USB Debug Probe，设备选择TMS320C5535。保存。
连接与加载：
- 将EZDSP5535开发板通过USB连接到电脑。
- 在Target Configurations视图里，右键你刚创建的配置，选择Launch Selected Configuration。CCS会切换到调试透视图。
- 在调试视图的左上角，右键显示为Texas Instruments XDS100v2 USB Debug Probe_0/C55xx_0的设备，选择Connect。控制台会打印一系列GEL脚本初始化信息，表明连接成功。
- 点击Run -> Load -> Load Program，选择刚刚编译生成的cfft1.out文件，点击OK。程序会被加载到DSP的内存中。
启用时钟与运行：
- 点击Run -> Clock -> Enable。你会看到CCS窗口底部状态栏出现一个时钟图标，并显示0。
- 按F8（运行）或点击绿色运行箭头。程序开始执行。
查看结果：程序运行完毕后，输出会显示在CCS的Console窗口中。例如，对于256点软件FFT，你可能会看到：
```
Complex FFT number of elements is 256 fft time (in cycles) 5366 bit reverse time (in cycles) 521 Done with 1000000 iteration
```
这表示，一次256点复数FFT（带缩放）在DSP核上执行大约需要5366个周期，位反转操作需要521个周期。而如果启用硬件加速（FFT_HARDWARE 1），输出可能变为：
```
Using bit reversal Number of elements is 256 Bit reversal accelerator time (in cycles) 538 Complex FFT number of elements is 256 fft time (in cycles) 1136 ...
```
可以看到，硬件FFT加速器将核心FFT计算时间从5366周期大幅降低到1136周期，性能提升显著。但有趣的是，位反转操作的时间（521 vs 538）软件实现反而略快一点。这个细节告诉我们，硬件加速器并非万能，需要针对具体操作进行实测评估。

5. 其他DSP函数测试项目要点与结果分析

遵循与cfft1项目完全相同的创建和配置流程，你可以构建并运行其他DSP函数的基准测试。每个项目的主要区别在于其主测试文件、所需的特定汇编文件以及链接命令文件。下面我汇总了其他关键项目的核心信息和典型结果分析。

5.1 FIR滤波器：fir1 与 fir2 的抉择

FIR滤波是DSP中最常见的操作之一。DSPLIB提供了两个版本：fir1（通用）和fir2（快速，但有约束）。

fir2项目：
- 测试文件：fir2_t.c
- 汇编文件：fir2.asm
- 核心约束：fir2函数要求输出的样本点数（nx）必须是偶数。这是其算法优化（可能使用了循环展开或并行指令）带来的限制。
- 测试注意：项目自带的t5_ran.h数据文件是为256抽头滤波器设计的，但其提供的参考输出结果向量只对前32个输出点有效。如果你需要测试更多输出点，必须自己生成新的测试向量和参考结果，并相应修改nx的定义。
- 典型结果：对于一个256抽头、处理32个输出点的滤波器，fir2可能报告约4247个周期。如果将nx改为2（最小偶数），周期数可能骤降至330。这清晰地展示了处理数据量对性能的线性影响，以及小数据量下函数调用开销的相对占比。
fir1项目：
- 测试文件：fir_t.c
- 汇编文件：fir.asm
- 特点：没有输出点数必须为偶数的限制，通用性更强，但速度通常比fir2慢。
- 性能对比：在相同256抽头条件下，处理1个输出点，fir1约310周期；处理32个输出点，约8309周期。与fir2的4247周期相比，在处理批量数据时，fir2的速度优势（约快一倍）非常明显。工程选择：如果你的应用场景中输出点数总是偶数，且对性能有极致要求，应优先选用fir2；否则，fir1是更安全的选择。

5.2 卷积（Convolve2）与自相关（Auto-Correlation）

这两个操作在信号检测、模式识别中广泛应用。

convolve2项目：
- 测试文件：conv2_T_ran.c
- 汇编文件：convolve2.asm（这是最快版本，同样有convolve1.asm和convolve.asm可供替换测试）。
- 典型结果：对于80点数据与80点核的卷积，可能报告约3285个周期。这为评估实时卷积系统的处理能力提供了基准。
correlation项目：
- 测试文件：ARAW_T.c
- 汇编文件：araw.asm
- 验证机制：该项目的一个亮点是，它不仅调用优化的汇编函数araw，还同时调用一个用C语言编写的参考模型函数araw_c。然后将两者的结果进行比对，以此验证汇编优化函数的正确性。这是验证优化代码功能正确性的良好实践。
- 典型结果：80点的自相关运算可能报告约3456个周期。

5.3 延迟LMS滤波器：标准版与快速版

LMS滤波器常用于自适应滤波、回声消除等。

dlmas(标准) 与dlmas_fast(快速) 项目：
- 测试文件：dlms_T.c和dlms_fast_T.c
- 汇编文件：DLMS.asm和dlms_fast.asm
- 核心区别：dlms_fast通过施加一些内存对齐和数据结构的限制，换取了更高的速度。具体限制需查阅SPRU422手册。
- 结果分析：在32个系数、64个数据点的测试案例中，标准版可能耗时4474周期，而快速版耗时4372周期，提升约2%。这个例子说明，快速版算法的优势可能依赖于特定的数据规模和内存布局。在系数更多、数据量更大的场景下，优势可能会更明显。测试结果中的FAIL THE TEST提示我们，快速版可能在某些边界条件下（如本例）因精度或舍入方式不同而无法通过严格的比特级结果比对，但这不一定代表算法错误，可能需要根据应用场景放宽误差容限。

5.4 向量最大值查找

这是一个简单的但常用的操作。

maxval(仅最大值) 与maxvec(最大值及索引) 项目：
- 测试文件：MAXVAL_T.c和Maxvec_T.c
- 汇编文件：maxval.asm和maxvec.asm
- 性能洞察：在100个元素的向量中，仅找最大值 (maxval) 可能只需77个周期，而同时找到值和索引 (maxvec) 则需要322个周期。多返回一个索引，代价增加了约4倍。这提醒我们，即使是简单的操作，功能细微增加也可能带来不成比例的开销。在不需要索引的场景下，使用maxval显然是更经济的选择。

6. 扩展指南：如何为你关注的DSPLIB函数添加基准测试

官方基准测试包并未覆盖DSPLIB中的所有函数。如果你需要测试其他函数（如IIR滤波、矩阵运算、三角函数等），可以遵循一个标准流程进行移植。这个流程本质上是在复制一个现有项目框架，并替换核心测试逻辑。

定位单元测试：在DSPLIB的安装目录下，通常有一个examples或test子目录，里面包含了每个库函数的单元测试代码。这是你最好的起点。
创建项目目录：在基准测试包的根目录下，复制一个现有项目目录（如fir1），重命名为你的函数名（如iir）。
替换核心文件：
- 将单元测试中的C源文件、数据头文件（.h）、链接命令文件（.cmd）复制到新目录，覆盖旧文件。
- 清理并修改主测试C文件（例如iir_t.c）。
修改测试代码框架：这是最关键的一步，你需要将单元测试代码“套用”到基准测试框架中。具体修改遵循第3.1节所述的原理：
- 添加头文件：#include <time.h>。
- 定义迭代宏：#define NUMBER_OF_ITERATIONS ...。
- 声明计时变量：clock_t t1, t2, overhead;
- 测量并扣除开销：t1=clock(); t2=clock(); overhead=t2-t1;
- 包裹被测函数进行计时：
```
t1 = clock(); DSP_iir(...); // 调用你的目标函数 t2 = clock(); cycle_count = (long)(t2 - t1 - overhead); printf("DSP_iir time: %ld cycles\n", cycle_count);
```
- 添加长循环用于功耗测试：
```
for (long i=0; i<NUMBER_OF_ITERATIONS; i++) { DSP_iir(...); }
```
- 保留结果验证逻辑：确保原有的结果正确性检查代码被保留，并在计时循环之外执行。我们只对单次执行计时，验证也只做一次。
链接汇编文件：在CCS项目中，从ASM_sources目录链接对应的汇编源文件（如iir.asm）。
配置与编译：参照第4章，在CCS中创建新项目，添加文件，设置SOURCES_BASE链接资源和包含路径，然后编译运行。

通过这个流程，你可以将DSPLIB中任何感兴趣的函数都纳入到统一的基准测试体系中，获得可比较的周期性能数据。

7. 基准测试中的常见陷阱与优化实践

基于多年的嵌入式性能调优经验，在进行此类基准测试时，有几个关键的陷阱需要避开，同时也有一些优化实践可以提升测试的准确性和效率。

7.1 常见问题与排查技巧

问题现象	可能原因	排查与解决思路
编译错误：找不到头文件	项目属性中`Include Options`路径未正确设置。	仔细检查`SOURCES_BASE`变量是否正确定义，以及`${SOURCES_BASE}\include`路径是否已添加。确保路径中无中文或特殊字符。
链接错误：未定义的符号	1. 对应的汇编源文件（`.asm`）未添加到项目。 2. 汇编文件添加方式错误（应为`Link`而非`Copy`）。 3. 函数名在C代码中声明与汇编中导出不一致。	1. 确认`ASM_sources`目录下有所需的`.asm`文件，并将其链接到项目。 2. 检查函数原型。在DSPLIB的C头文件（如`dsplib.h`）中查找正确的函数名和参数类型。
程序运行无输出或输出乱码	1. 程序在运行前崩溃或跑飞。 2. 串口或Console配置不正确。 3. 内存访问越界。	1. 尝试在`main()`函数开头设置一个断点，单步执行，看程序能否正常启动。 2. 检查链接命令文件（`.cmd`）是否正确分配了堆栈（`stack`）和堆（`heap`）的大小，特别是当测试数据很大时。 3. 确认测试数据数组没有超出其在内存段中定义的范围。
测量的周期数波动很大	1. 缓存效应：第一次运行冷缓存，后续运行热缓存。 2. 中断干扰：系统其他中断（如定时器）打断了测试。 3. 测量开销未扣除或扣除不准确。	1. 在计时循环前，先“预热”调用几次被测函数，让指令和数据进入缓存。 2. 在基准测试时，确保关闭所有不必要的中断。对于C5535，可以在测试代码前后用`__disable_interrupts()`和`__enable_interrupts()`（或类似 intrinsic）包裹。 3. 确保`overhead`的测量是准确的，可以考虑测量多次取平均值。
功耗测量时电流读数不稳定	1. 迭代次数不够，函数执行时间太短。 2. 板卡上其他外设（LED、未用接口）仍在耗电。 3. DSP核心频率或电压未锁定在测试状态。	1. 大幅增加`NUMBER_OF_ITERATIONS`，确保单次测量窗口（如1秒）内函数在持续运行。 2. 在测试前，通过代码关闭所有GPIO驱动的外设，将未用的外设时钟门控。 3. 确认测试期间DSP处于稳定的高性能状态（非IDLE），并且使用外部稳压电源而非USB供电进行测量，以获取稳定电流。

7.2 实操心得与高级技巧

建立性能基线档案：不要只测一组参数。对于像FFT、FIR这样的函数，其执行周期与数据规模（N）通常有明确的数学关系（如O(N log N)， O(N*M)）。你应该系统性地测试不同规模（如FFT的8, 16, 32, ..., 1024点；FIR的不同抽头数和输入长度），将周期数记录在表格中。这能帮助你建立该函数在目标平台上的性能模型，未来在做系统预算时可以直接估算。
关注“每样本周期数”：对于流处理函数（如FIR），单纯看总周期数意义不大。更重要的指标是处理每个输出样本所需的平均周期数（Cycles per Sample）。例如，fir1处理32个输出用8309周期，每样本约260周期；处理1个输出用310周期。这说明该函数存在固定的“启动开销”，批量处理能摊薄这个开销。这个指标对于评估系统实时吞吐能力至关重要。
内存布局的影响：DSP性能极度依赖于内存访问效率。确保你的测试数据数组是按照链接命令文件中定义的位置存放的，并且考虑数据对齐。对于dlms_fast这类函数，手册中明确要求数据必须放在特定的内存块或满足对齐要求，不满足会导致运行错误或性能下降。在编写自己的测试或产品代码时，务必仔细阅读DSPLIB手册中每个函数的“特殊要求”部分。
编译器优化等级：本文所述测试默认使用CCS项目创建时的优化设置（通常是-O2或-O3）。请注意，测试代码中调用的是汇编函数，因此C编译器优化主要影响测试框架本身（如循环、变量访问）。为了获得最稳定的结果，建议在项目属性的编译器设置中，明确指定优化等级（如-O2），并关闭调试信息生成（-g选项）后再进行最终性能测试，因为调试信息会影响代码布局和少量性能。
超越周期数：使用CCS内置分析工具：CCS提供了强大的代码剖析（Profiling）和周期精确仿真（Cycle Accurate Simulator）工具。在硬件测试之外，你可以利用仿真器在不连接实际板卡的情况下，进行更细致的性能分析，例如查看流水线停顿、缓存命中率等。这对于深度优化和理解性能瓶颈非常有帮助。

基准测试不是一次性的任务，而是一个持续的过程。随着你对应用场景理解的深入，以及编译器、库版本的更新，重新运行这些测试，能帮助你持续掌控系统的性能脉搏，做出最优的工程决策。这套基于C55x DSPLIB的基准测试方法，其思想和流程完全可以迁移到其他系列的DSP或MCU平台上，是嵌入式性能工程师工具箱中的一项基本功。