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 StudioCCS集成开发环境详细拆解从项目导入、编译配置、到实际运行测试、解读结果的全过程。更重要的是我会分享在多年嵌入式开发中积累的关于基准测试的“坑”与技巧例如如何避免测量开销影响结果、如何为功耗测试配置超长运行时间、以及如何根据自己的需求扩展测试函数。无论你是正在评估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. 实战以复数FFTCFFT项目为例构建并运行测试现在我们以最经典的复数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核软件FFT1使用硬件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;测量并扣除开销t1clock(); t2clock(); overheadt2-t1;包裹被测函数进行计时t1 clock(); DSP_iir(...); // 调用你的目标函数 t2 clock(); cycle_count (long)(t2 - t1 - overhead); printf(DSP_iir time: %ld cycles\n, cycle_count);添加长循环用于功耗测试for (long i0; iNUMBER_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平台上是嵌入式性能工程师工具箱中的一项基本功。