1. 项目概述这不是一份“CMSIS-DSP使用手册”而是一份嵌入式信号处理工程师的源码级作战地图我第一次在STM32F407上跑通CMSIS-DSP的arm_fir_f32()函数时以为只是调了个库——直到某天固件在客户现场连续72小时运行后FFT频谱出现周期性毛刺而示波器显示ADC采样时序完全正常。排查三天后发现问题出在CMSIS-DSP的arm_cfft_radix4_init_f32()初始化函数里一个未对齐的内存拷贝操作它在特定编译器优化等级下会破坏紧邻的DMA描述符缓冲区。那一刻我才真正意识到CMSIS-DSP不是黑盒API它是ARM生态里最精密、也最易被误用的嵌入式信号处理引擎。今天这篇内容就是我把过去八年在电力继保、工业振动分析、电机驱动三个领域把CMSIS-DSP从头到尾拆解、审计、打补丁、再落地的全部实战经验浓缩成的一份源码级全景指南。它不讲“怎么安装Keil”不教“如何新建工程”而是直击核心——CMSIS-DSP的架构设计哲学是什么它的汇编内核为什么必须手写而非编译器生成哪些函数在ARM Cortex-M4上能榨干FPU哪些却因内存对齐缺陷反而比纯C慢工业固件对实时性、确定性、抗干扰性的严苛要求又如何倒逼我们修改官方源码如果你正在开发需要FFT、FIR/IIR滤波、PID控制、矩阵运算或快速正交变换的工业设备且对“为什么这个函数在M4上跑得比M7还快”“为什么arm_mat_mult_f32()在中断里调用会偶发死锁”这类问题有本能追问那么这篇内容就是为你写的。它覆盖从ARM Cortex-M0到M7全系列适配ARM Compiler 5.06工业界事实标准、GCC 9.3及IAR EWARM 9.30所有结论均来自真实产线固件的静态审计与动态压测。2. CMSIS-DSP架构全景三层结构下的性能博弈与设计权衡CMSIS-DSP的代码仓库看似平铺直叙实则暗藏三重精密嵌套的架构逻辑顶层是统一的C语言API接口层中层是架构无关的通用算法实现层底层则是针对不同ARM内核深度定制的汇编加速层。这三层并非简单堆叠而是围绕“确定性延迟”“内存带宽瓶颈”“指令流水线效率”三大工业级硬约束展开的持续博弈。理解这种博弈是避免掉进性能陷阱的第一步。2.1 API接口层统一表象下的隐式契约CMSIS-DSP所有函数名都遵循arm_algorithm_datatype_suffix()命名规范例如arm_fir_f32()、arm_cfft_radix4_f32()。表面看这是为了清晰实则隐藏着关键契约所有输入输出缓冲区地址、长度参数、配置结构体都默认要求按数据类型自然对齐。float32_t要求4字节对齐q31_t要求4字节q15_t要求2字节。但问题在于这个“默认要求”在文档里是灰色地带——它不报错只在特定条件下静默降级。比如你在STM32H7上用arm_fir_fast_q15()处理一个起始地址为0x20000001的缓冲区奇数地址函数不会崩溃但会自动退化为arm_fir_q15()的纯C实现性能直接腰斩。我在某款伺服驱动器固件中就遇到过此问题客户用FreeRTOS的pvPortMalloc()分配缓冲区其默认对齐仅8字节而arm_biquad_cascade_df2T_f32()要求16字节对齐导致PID环路计算延迟从12μs飙升至48μs最终引发电机啸叫。解决方案不是改算法而是强制用pvPortMallocAligned(16)——这恰恰说明CMSIS-DSP的API层本质是一个“信任契约”它把对齐责任完全交给了使用者而工业场景恰恰最容不得这种信任。2.2 通用算法层可读性与确定性的艰难平衡位于Source/TransformFunctions/、Source/FilteringFunctions/等目录下的C语言实现是CMSIS-DSP最常被开发者直接阅读的部分。以arm_fir_f32.c为例其核心循环采用经典的“MACMultiply-Accumulate累加”模式for (i 0; i numSamples; i) { /* Accumulator is made zero for every iteration */ sum 0.0f; /* Loop over all the coefficients */ for (j 0; j S-numTaps; j) { sum pSrc[j] * pCoeffs[i j]; } ... }这段代码清晰易懂但工业固件绝不能止步于此。问题在于它没有显式声明循环依赖关系编译器在-O3优化下可能重排指令破坏实时性确定性。ARM Compiler 5.06的--no_unaligned_access选项虽能禁用非对齐访问却无法约束编译器对浮点累加顺序的优化——而IEEE 754标准下(ab)c与a(bc)结果可能微异这对需要严格复现的故障录波分析是灾难。我们的做法是在关键路径函数中手动插入__asm volatile ( ::: memory)内存屏障并将累加变量声明为volatile float32_t sum强制编译器不优化累加顺序。这牺牲了约3%的峰值性能却换来了100%的计算结果可复现性对继电保护装置而言这是不可妥协的底线。2.3 汇编加速层为什么ARM坚持手写而非Auto-VectorizeCMSIS-DSP真正的性能心脏在于Source/ARM/目录下那些.s汇编文件如arm_cfft_radix4_f32.S、arm_rfft_fast_f32.S。这里藏着ARM工程师最深的考量编译器自动生成的向量化代码无法满足工业固件对“最坏情况执行时间WCET”的硬性要求。以Cortex-M4的arm_cfft_radix4_f32.S为例它精确控制每条VFP指令的流水线阶段通过精心安排vmul.f32、vadd.f32、vsub.f32的发射间隔确保在任何缓存命中/未命中组合下FFT蝶形运算的周期数恒定为1272个时钟周期针对1024点。而GCC的-O3 -mfloat-abihard -mfpufpv4生成的代码WCET可能在1180~1350周期间波动——这点波动在消费电子里无感在工业PLC的运动控制环路中却意味着位置误差超差。更关键的是手写汇编能绕过编译器的寄存器分配策略将FFT旋转因子twiddle factors全部预加载到S0-S15寄存器组避免频繁访存。我们在某款数控系统中实测手写汇编版1024点FFT耗时218μsGCC自动生成版平均245μs但最坏情况达298μs超出运动控制器允许的250μs上限。这就是为什么ARM宁可投入人力维护汇编代码——在确定性面前一切自动化都是次要的。3. 源码审计核心方法论从静态扫描到动态注入的四维验证对CMSIS-DSP进行源码审计绝非逐行阅读注释。工业固件的特殊性要求我们建立一套四维验证体系静态语法合规性、内存安全边界、实时性确定性、硬件交互鲁棒性。这套方法论已在我们交付的17个工业项目中验证有效下面以arm_pid_init_f32()和arm_mat_mult_f32()两个典型函数为例拆解实操细节。3.1 静态语法合规性审计用PC-Lint自定义规则集捕获隐性缺陷工业固件必须通过IEC 61508 SIL2认证这意味着所有代码需符合MISRA-C:2012规则集。CMSIS-DSP官方源码虽声称“MISRA兼容”但实际存在多处灰色地带。我们使用PC-Lint 9.0L配合自定义规则集进行深度扫描。关键发现如下规则ID问题函数问题描述工业影响修复方案MISRA-C:2012 Rule 10.1arm_biquad_cascade_df2T_f32.cLine 127pState[i] pState[i] * pCoeffs[0] ...中pState[i]作为左值参与复合赋值违反“禁止在表达式中修改同一对象两次”在中断嵌套场景下若pState缓冲区被高优先级中断修改可能导致状态变量计算错误将复合赋值拆分为独立语句temp pState[i] * pCoeffs[0]; pState[i] temp ...MISRA-C:2012 Rule 17.7arm_conv_partial_f32.cLine 85for (i 0U; i (srcALen - srcBLen 1U); i)中srcALen - srcBLen 1U可能为负值无符号整型溢出当srcALen srcBLen时循环次数变为极大值如0xFFFFFFFF导致无限循环增加前置校验if (srcALen srcBLen) { ... } else { return ARM_MATH_ARGUMENT_ERROR; }MISRA-C:2012 Rule 21.3arm_fill_f32.cLine 52memset(pDst, 0, blockSize * sizeof(float32_t))直接调用memset未检查blockSize是否过大若blockSize超限如误传0xFFFFmemset可能越界写入相邻内存替换为安全循环for(i0; iblockSize; i) pDst[i] 0.0f;提示PC-Lint规则集需特别启用-e9044检测无符号溢出和-e9027检测浮点比较这两条在信号处理代码中触发率极高。我们已将完整规则集打包为cmsis-dsp-misra.lnt可联系获取。3.2 内存安全边界审计用AddressSanitizer暴露潜伏十年的越界CMSIS-DSP大量使用指针算术pointer arithmetic这是性能之源也是安全之壑。传统静态分析难以捕捉运行时越界我们采用GCC的AddressSanitizerASan进行动态注入测试。步骤如下环境准备在Ubuntu 20.04上安装gcc-9-multilib编译目标设为arm-none-eabi-gcc编译改造修改CMSIS-DSP的Makefile在CFLAGS中添加-fsanitizeaddress -fno-omit-frame-pointer并链接-lasan测试用例构造编写极端压力测试例如// 构造最小缓冲区仅1个float但传入numTaps16 float32_t test_src[1] {1.0f}; float32_t test_coeff[16] {0}; arm_fir_instance_f32 S; arm_fir_init_f32(S, 16, test_coeff, test_src, 1); // blockSize1但numTaps16 arm_fir_f32(S, test_src, test_src, 1); // 强制越界读取coeff[1..15]执行与捕获运行qemu-arm ./test_firASan立即报告 12345ERROR: AddressSanitizer: heap-buffer-overflow on address 0x004000000010 at pc 0x00400000008a bp 0x7fffffffe0a0 sp 0x7fffffffe098 READ of size 4 at 0x004000000010 thread T0 #0 0x4000000089 in arm_fir_f32 /path/to/cmsis/Source/FilteringFunctions/arm_fir_f32.c:142实测发现arm_fir_f32.c第142行的pCoeffs[i j]在j循环中未校验ij numTaps当blockSize1且numTaps1时必然越界。此缺陷在常规测试中永不触发因用户通常分配足够大缓冲区却在某客户定制的超低功耗模式下暴露——他们为省RAM将numTaps设为16但blockSize动态缩至1。我们为此在初始化函数中增加了blockSize numTaps的断言并在计算循环前插入边界检查。这个案例印证了一个残酷事实工业固件的“边缘场景”往往就是客户最在意的“特色功能”。3.3 实时性确定性审计用逻辑分析仪捕获微秒级抖动CMSIS-DSP的实时性缺陷往往藏在函数调用链的“缝隙”中。我们使用Saleae Logic Pro 16逻辑分析仪配合GPIO打点法进行毫秒级观测。以arm_mat_mult_f32()为例其标准调用流程为GPIO_SetBits(GPIOA, GPIO_Pin_0); // 打点1进入函数 arm_mat_mult_f32(S, A, B, C); GPIO_ResetBits(GPIOA, GPIO_Pin_0); // 打点2退出函数在STM32F429上运行1000次用Saleae捕获波形发现耗时分布呈双峰主峰集中在215~225μs但存在约0.3%的样本落在280~310μs区间。深入分析发现这是由于arm_mat_mult_f32()内部调用了arm_fill_f32()初始化输出矩阵而arm_fill_f32()使用了memset()——当memset()操作跨越Cache Line边界时会触发额外的Cache填充周期。解决方案是将arm_mat_mult_f32()重构为两阶段第一阶段仅做参数校验与指针设置确定性1μs第二阶段在用户明确调用arm_mat_mult_execute_f32()时才执行实际计算。这样用户可在中断服务程序中安全调用第一阶段将不确定的计算负载转移到主循环。该方案已集成到我们定制的CMSIS-DSP分支中使矩阵乘法的WCET从310μs稳定至225μs。3.4 硬件交互鲁棒性审计在真实噪声环境中验证抗扰能力工业现场的EMI噪声会直接影响CPU指令执行。我们搭建了符合IEC 61000-4-4电快速瞬变脉冲群标准的测试环境对运行CMSIS-DSP的MCU施加2.5kV/5kHz脉冲群同时监测arm_cfft_radix4_f32()的输出一致性。发现一个隐蔽缺陷在脉冲干扰下arm_cfft_radix4_f32.S中用于保存临时寄存器的栈操作push {r4-r7,lr}偶尔失败导致后续计算使用了脏寄存器值。根本原因是汇编代码未在关键段插入cpsid i关中断指令。修复方案是在函数入口添加cpsid i 关中断确保栈操作原子性 push {r4-r7,lr} ... pop {r4-r7,pc} 函数返回时自动开中断这一行代码让FFT在EFT测试中的错误率从10^-3降至0。它揭示了一个重要原则CMSIS-DSP的汇编层必须像硬件驱动一样考虑中断上下文的安全性而不仅是算法正确性。4. 工业固件落地指南从编译配置到产线部署的全链路实践CMSIS-DSP在实验室跑通不等于能在产线稳定运行。工业固件落地的核心挑战在于如何在资源受限、环境恶劣、生命周期长达10年的前提下保证算法性能、安全合规与可维护性的三角平衡。以下是我们经过23个量产项目验证的全链路实践。4.1 编译器选型与配置ARM Compiler 5.06u7为何仍是工业界黄金标准当前网络热词中频繁出现arm compiler 5.06u7 下载这绝非偶然。ARM Compiler 5.06特别是Update 7Build 960在工业界的地位堪比Linux内核的LTS版本。原因有三确定性优化模型AC5.06的--opt_level3最高优化在Cortex-M系列上生成的代码其WCET波动范围始终控制在±1.2%以内而GCC 10.2的相同优化下波动达±8.7%。我们在某款风电变流器中对比AC5.06编译的arm_pid_f32()WCET为8.3μs±0.1μsGCC 10.2为8.5μs±0.7μs。对需要μs级响应的电流环后者不可接受。FPU指令生成质量AC5.06对__asm volatile (vmla.f32 %0, %1, %2 : q(sum) : q(a), q(b))内联汇编的支持更成熟能精准映射到Cortex-M4的VFPv4指令而GCC有时会插入冗余的vmov指令增加2~3个周期。长期支持保障ARM官方对AC5.06提供至2025年的安全补丁支持而AC6基于LLVM的长期支持路线图尚不明确。注意AC5.06u7的--fpmodefast选项需谨慎使用。它会禁用IEEE 754异常检测虽提升5%性能但若算法中存在除零或溢出将导致静默错误。我们的规范是仅在纯计算密集型函数如FFT中启用PID等控制类函数必须用--fpmodeieee_full。4.2 内存布局与对齐Linker Script的工业级定制CMSIS-DSP的性能高度依赖内存对齐而默认链接脚本如Keil的ARM_SCATTER_LOADER无法满足工业需求。我们为STM32H7系列定制的stm32h7xx_flash.ld关键片段如下/* 定义专用DSP RAM区域16KB起始地址0x30040000 */ _dsp_ram_start 0x30040000; _dsp_ram_size 0x4000; MEMORY { FLASH (rx) : ORIGIN 0x08000000, LENGTH 2048K RAM (rwx) : ORIGIN 0x20000000, LENGTH 1024K DSP_RAM (rwx) : ORIGIN _dsp_ram_start, LENGTH _dsp_ram_size /* 新增DSP专用RAM */ } SECTIONS { /* FFT旋转因子表必须16字节对齐 */ .fft_twiddle (NOLOAD) : ALIGN(16) { *(.fft_twiddle) } DSP_RAM /* FIR滤波器系数必须4字节对齐 */ .fir_coeff (NOLOAD) : ALIGN(4) { *(.fir_coeff) } DSP_RAM /* PID状态变量必须8字节对齐以适配双精度中间计算 */ .pid_state (NOLOAD) : ALIGN(8) { *(.pid_state) } RAM }此配置确保1FFT旋转因子存于高速TCM-RAMDSP_RAM避免Flash访问延迟2所有系数表按数据类型严格对齐3PID状态变量与普通RAM分离防止被其他模块意外覆盖。在某款机器人关节控制器中此配置使arm_cfft_radix4_f32()执行时间从285μs降至212μs且消除了一切偶发性FFT结果异常。4.3 固件升级与算法热更新如何在不停机情况下切换滤波器参数工业设备要求7×24小时运行但算法参数如FIR滤波器系数常需根据工况动态调整。CMSIS-DSP原生不支持热更新我们设计了一套轻量级方案双缓冲机制在DSP_RAM中开辟两块相同大小的系数区coeff_buf_a和coeff_buf_b原子切换标志使用单字节标志volatile uint8_t coeff_active 0;0表示用A1表示用B安全更新流程void update_fir_coeff(float32_t* new_coeff, uint32_t len) { // 步骤1关闭相关中断如ADC DMA完成中断 __disable_irq(); // 步骤2将新系数写入非活动缓冲区 if (coeff_active 0) { memcpy(coeff_buf_b, new_coeff, len * sizeof(float32_t)); } else { memcpy(coeff_buf_a, new_coeff, len * sizeof(float32_t)); } // 步骤3原子切换标志单字节写入天然原子 coeff_active 1 - coeff_active; // 步骤4重新使能中断 __enable_irq(); }FIR函数改造在arm_fir_f32()中根据coeff_active选择系数源无需锁或互斥量。此方案经受住某钢厂连铸机连续18个月运行考验参数更新零失败。关键心得工业热更新的精髓不在复杂而在极致简化——用硬件保证的原子性单字节写替代软件锁用确定性内存布局替代动态分配。4.4 产线测试与认证自动化脚本生成MISRA报告与WCET证书量产前每个固件版本必须生成两份权威报告MISRA-C合规报告与WCET分析证书。我们开发了Python自动化脚本cmsis_audit_runner.py集成以下工具链MISRA报告调用PC-Lint生成HTML报告自动提取Rule 10.1、17.7等高危项生成misra_summary.csvWCET证书调用Rapita RVS工具对arm_cfft_radix4_f32()等12个核心函数进行10万次压力测试生成PDF证书包含最大耗时、置信区间、测试环境CPU频率、Cache状态一致性验证脚本自动编译CMSIS-DSP的Reference C版本与汇编版本在QEMU中运行相同测试向量比对输出差异生成consistency_report.txt。该脚本已集成到Jenkins CI流水线每次提交自动触发报告上传至公司PLM系统。某次审计发现arm_mat_inverse_f32()在特定矩阵条件下汇编版与C版结果偏差达1e-5超出工业允许的1e-6追查发现是汇编版未处理矩阵奇异的早期退出。此问题在自动化测试中被即时捕获避免了潜在的产线召回。5. 常见问题与独家避坑指南来自产线的27个血泪教训CMSIS-DSP的坑往往不在文档里而在产线凌晨三点的调试日志中。以下是我们在23个工业项目中踩过的27个典型问题按发生频率排序并附上一招制敌的解决方案。5.1 高频问题TOP5解决即见效问题现象根本原因一招制敌方案实测效果FFT频谱出现固定频率杂散arm_cfft_radix4_init_f32()生成的旋转因子表未用const修饰被编译器优化进Flash而Flash读取时序受电压波动影响在arm_cfft_radix4_init_f32.c中将static float32_t twiddleCoef声明改为static const float32_t twiddleCoef并链接到.rodata段杂散消失信噪比提升22dBFIR滤波器输出全为NaN输入缓冲区含Inf或NaN值arm_fir_f32()未做输入校验直接参与计算导致传播在arm_fir_init_f32()中添加for(i0;iblockSize;i) { if(isnan(pSrc[i])PID控制环路振荡加剧arm_pid_f32()中积分项累加使用float32_t在长时间运行后发生精度丢失将积分变量I改为float64_t并在arm_pid_init_f32()中初始化为0.0振荡消除1000小时连续运行积分误差1e-8矩阵乘法结果偶发错误arm_mat_mult_f32()调用arm_fill_f32()初始化输出矩阵而arm_fill_f32()使用memset()在Cache未命中时耗时波动替换arm_fill_f32()为纯循环实现并在链接脚本中将其放置于ITCM中WCET从298μs稳定至225μs波动0.5%编译报错“missing:compiler version 5”Keil MDK安装了AC6但工程仍指向AC5路径且AC5.06u7未正确注册运行AC5.06u7安装包内的armcc.exe --version确认路径然后在Keil中Project → Options → Target → ARM Compiler手动指定AC5路径为C:\Keil_v5\ARM\ARMCC\Bin\armcc.exe编译通过且启用AC5.06u7全部优化特性5.2 中频问题TOP7需系统性规避问题6arm_rfft_fast_f32()在M7上比M4慢原因M7的FPU是双精度而arm_rfft_fast_f32.S为M4单精度FPU优化M7需额外转换。方案为M7单独编译arm_rfft_fast_f32_m7.S使用vdup.f32替代vmov.f32速度提升37%。问题7arm_conv_f32()内存占用超限原因卷积函数内部使用blockSize * numTaps * sizeof(float32_t)临时缓冲区未提供外部缓冲区接口。方案修改函数签名增加pTempBuffer参数并在调用前由用户分配于TCM-RAM。问题8arm_biquad_cascade_df2T_f32()在中断中调用导致HardFault原因汇编版使用push {r4-r7,lr}若中断嵌套深度超2栈溢出。方案在启动文件中将MSP栈大小从0x400增至0x800并在arm_biquad_cascade_df2T_f32.S入口添加栈溢出检查。问题9arm_mat_mult_f32()在FreeRTOS任务中调用死锁原因函数内部调用arm_fill_f32()而arm_fill_f32()使用memset()在某些FreeRTOS移植层中memset()被重定向为带互斥量的版本。方案在FreeRTOSConfig.h中定义configUSE_MALLOC_FAILED_HOOK 0并确保memset()为libc原生版本。问题10arm_cfft_radix4_f32()结果相位偏移原因旋转因子表生成算法arm_cfft_radix4_init_f32()中twiddleCoef数组索引计算有舍入误差。方案将arm_cfft_radix4_init_f32()中twiddleCoef[i] cosf(2*PI*i/N)改为twiddleCoef[i] cosf(2*PI*(float32_t)i/(float32_t)N)强制单精度计算。问题11arm_pid_f32()在低速电机控制中积分饱和原因无抗饱和机制I值持续累积至溢出。方案在arm_pid_f32()中添加if(I max_I) I max_I; else if(I min_I) I min_I;max_I/min_I由用户配置。问题12arm_mat_inverse_f32()对病态矩阵返回成功原因未计算条件数直接执行LU分解。方案在arm_mat_inverse_f32()开头添加arm_mat_cond_f32()调用条件数1e6时返回ARM_MATH_SINGULAR。5.3 低频但致命问题TOP3产线召回级风险问题13arm_fir_fast_q15()在ADC采样率突变时输出毛刺原因arm_fir_fast_q15()假设采样率恒定其内部状态管理未考虑采样周期跳变。方案在采样率变更时强制调用arm_fir_init_q15()重新初始化并清空pState缓冲区。此操作需在ADC停止期间完成。问题14arm_cfft_radix4_f32()在-40℃低温下FFT结果全零原因低温导致Flash读取时序违规旋转因子表读取失败。方案将旋转因子表复制到RAM中执行修改arm_cfft_radix4_init_f32()在初始化时memcpy()到RAM并更新函数指针。问题15arm_mat_mult_f32()在电磁干扰下偶发计算错误原因EMI导致CPU寄存器位翻转arm_mat_mult_f32.S中未启用纠错码ECC校验。方案在Cortex-M7上启用TCM的ECC功能通过SCB-CCR | SCB_CCR_DC_Msk并在arm_mat_mult_f32.S关键计算段前后插入__DSB()和__ISB()内存屏障。实操心得所有这些解决方案我们都已打包为cmsis-dsp-industrial-patchset-v2.3包含详细README和Kconfig配置项。它不是简单的“打补丁”而是将工业现场的生存智慧编码进CMSIS-DSP的基因里。当你在产线面对一个凌晨三点的诡异bug时请记住CMSIS-DSP的源码既是你的武器也是你的镜子——它照见的永远是你对嵌入式世界理解的深度。6. 性能实测数据全景横跨6大MCU平台的硬核Benchmark理论终需数据验证。我们选取工业界最具代表性的6款MCU在统一测试环境下对CMSIS-DSP核心函数进行满负荷Benchmark。所有测试均在裸机环境无OS下运行关闭所有中断CPU主频锁定结果取1000次运行的平均值与最大值WCET。数据来源Keysight InfiniiVision MSO-X 3104T示波器逻辑分析仪联合测量。6.1 测试环境与方法论硬件平台STM32F407VGCortex-M4168MHz、STM32H743VICortex-M7400MHz、NXP RT1064Cortex-M7600MHz、Renesas RA6M5Cortex-M33200MHz、GigaDevice GD32H750Cortex-M7480MHz、TI TM4C1294Cortex-M4F120MHz软件环境ARM Compiler 5.06u7--opt_level3 --fpmodeieee_full --cpuCortex-M4依平台调整测试用例1024点实数FFTarm_rfft_fast_f32()、128阶FIR滤波arm_fir_f32()、3x3矩阵乘arm_mat_mult
