做电机控制的同行应该都有类似的经历算法层面已经调通电机转起来波形也漂亮但CPU负载一直压不下来。尤其是当你把开关频率从16kHz提到32kHz或者在同一颗MCU上同时跑CAN通信、上位机调试和故障保护的时候电流采样这条链路的性能会瞬间变成整个系统的瓶颈。这篇文章是我“嵌入式性能优化”系列的第11篇记录的是对一个实际PMSM驱动项目中FOC电流采集代码的完整优化过程。项目主控是STM32F407主频168MHz开关频率16kHz电流环每隔62.5微秒需要完成一次采样、坐标变换、电流环PI和SVPWM输出。如果你正在用FOC做电机驱动或者刚把网上例程里的FOC代码搬进自己的工程这篇文章里提到的思路和坑大概率你也会碰到。1. 我拿到的那版代码到底慢在哪先定位再动手1.1 原始实现的基本盘16kHz电流环全挤在一个中断里这段代码不是从零开始写的而是从一套“能转起来”的参考实现里改出来的。它的结构非常典型TIM1更新中断触发ADC转换然后在同一个中断服务函数里轮询等待转换完成紧接着做电流标定、Clarke变换、Park变换、PI运算、逆Park和SVPWM输出。/* 优化前的核心结构TIM1更新中断里轮询ADC并完成全部FOC运算 */ void TIM1_UP_TIM10_IRQHandler(void) { uint16_t raw[3]; uint8_t i; /* 触发规则组转换3个通道扫描 */ ADC1-CR2 | ADC_CR2_SWSTART; /* CPU在这里空转等待三路转换完成 */ for (i 0; i 3; i) { while ((ADC1-SR ADC_SR_EOC) 0); raw[i] ADC1-DR; ADC1-SR ~ADC_SR_EOC; } /* 电流标定每次都算一遍除法 */ float ia (float)raw[0] * 3.3f / 4095.0f / 0.01f / 20.0f - offset_a; float ib (float)raw[1] * 3.3f / 4095.0f / 0.01f / 20.0f - offset_b; /* Clarke变换 */ float ialpha ia; float ibeta (ia 2.0f * ib) * 0.577350269f; /* Park变换直接调标准数学库的cosf/sinf */ float ct cosf(theta); float st sinf(theta); float id ialpha * ct ibeta * st; float iq -ialpha * st ibeta * ct; /* 电流环PI、逆Park、SVPWM、装载CCR */ /* ... */ }第一版跑通的时候电机确实能转电流波形在示波器上也勉强能看。但有几个现象特别明显打开CAN总线发包之后偶尔会出现控制毛刺想加一个上位机实时波形显示CPU就紧张了把开关频率提到32kHz试了一下整个系统几乎被电流环吃死。这个时候我才决定老老实实坐下来做性能优化。1.2 用DWT的CYCCNT把耗时钉死别靠感觉猜性能优化第一步永远是量化不能靠“感觉这个函数挺慢”来猜。我用的办法是在Cortex-M内核上开启DWT的CYCCNT计数器它是内核里的一个32位周期计数器每个主频周期加一测FOC代码段的耗时非常方便。/* 初始化DWT周期计数器 */ static void dwt_init(void) { CoreDebug-DEMCR | CoreDebug_DEMCR_TRCENA_Msk; DWT-CYCCNT 0; DWT-CTRL | DWT_CTRL_CYCCNTENA_Msk; } /* 在ISR里打点测耗时 */ void TIM1_UP_TIM10_IRQHandler(void) { uint32_t t_start DWT-CYCCNT; /* ... 整个采样控制逻辑 ... */ uint32_t t_cost DWT-CYCCNT - t_start; if (t_cost max_cost) { max_cost t_cost; /* 记录峰值通过调试器观察 */ } }为了能看到包含中断进出栈在内的真实耗时我同时在ISR入口拉高一个GPIO、出口拉低用逻辑分析仪测量脉冲宽度。这样得到的数据和DWT计数器互相印证比单独看任何一项都可靠。实测结果这段代码在最坏情况下大约要跑1900个周期左右折算到168MHz主频大约是11.3微秒。注意16kHz开关频率下整个控制周期才62.5微秒这意味着一个ISR就吃掉了将近18%的CPU时间。听起来好像还行但加上通信、显示、保护逻辑CPU负载就非常难看了。1.3 瓶颈排序最大的浪费不是数学运算把11.3微秒逐项拆开之后我发现最大的浪费有三处环节估算周期数问题ADC三路EOC轮询等待约500转换期间CPU空转什么都干不了电流标定中的多次浮点除法约180每次采样都重复算同样的除法cosf/sinf标准库函数约350从标准数学库拉进来的软浮点版本开销大Clarke/Park及PI常规乘加约550FPU上不算贵但存在冗余的全局变量读写中断现场保存与恢复约80不可避免但ISR太长会放大它的影响其他状态判断、限幅等约240分散开销真正让我意外的是单纯看单点开销没有任何一个环节是“天价”。问题出在它们叠加在一起而且整段代码的结构把所有耗时都串行化了。特别是第一步的轮询等待ADC转换大概需要4到5微秒这期间CPU完全是在干等。如果能让ADCDMA自己去搬数据同时把数学运算里那些不必要的库函数调用和重复除法去掉性能立刻就能上一个台阶。2. 采样时刻死磕在下桥导通窗口这不是玄学是硬件原理2.1 为什么FOC电流采集要设置在下桥导通期间很多初学者看FOC电流采样的代码看到ADC触发点配置在下桥导通的时间点第一反应是“为什么不挑个方便的时候”。这个问题问得好原因要从采样电阻的位置说起。常见的低成本电流采样方案是低边采样也就是在每个桥臂的下管源极串一个毫欧级采样电阻。当某个下管导通时流过这个采样电阻的电流就是对应相绕组的相电流当下管关断时采样电阻上要么没有电流要么流的是死区时间里通过续流二极管的那部分电流无法反映真实相电流。在中心对齐的SVPWM里一个载波周期的谷底对应的是零矢量000也就是三个下管全部导通。这个时候三个采样电阻上的电流刚好分别是A、B、C三相的相电流是一次性采齐三相电流的最佳窗口。而载波周期的峰值对应的是零矢量111三个上管全部导通此时三个下管全部关断采样电阻上什么都采不到。所以“为什么设置在下桥”本质上是一个采样窗口选择问题你要在下管导通、且三个下管同时导通的时间点去触发ADC。这个时间点就是中心对齐PWM的谷底。2.2 中心对齐PWM下的触发点配置在STM32上实现“谷底触发ADC”的经典做法是让定时器在中心对齐模式下产生更新事件作为ADC的外部触发源再把ADC配置成外部触发启动转换。/* 中心对齐模式2只在计数器下溢谷底时产生更新事件 */ TIM1-CR1 | TIM_CR1_CMS_1; /* CMS10 */ /* TRGO选择为更新事件 */ TIM1-CR2 | TIM_CR2_MMS_1; /* ADC1规则组外部触发选择TIM1_TRGO */ ADC1-CR2 | ADC_CR2_EXTEN_0; ADC1-CR2 | (ADC_CR2_EXTSEL_0 | ADC_CR2_EXTSEL_1 | ADC_CR2_EXTSEL_3);这里有个容易被忽略的点中心对齐模式有三种区别在于更新事件产生的位置。模式1只在计数器上溢峰值时产生更新事件模式2只在计数器下溢谷底时产生模式3是上下溢各产生一次。你要在谷底触发ADC就必须选用模式2或者用模式3但通过其他方式区分上下溢。很多例程默认给的是模式1结果触发点跑到了峰值下管全部关断采样出来全是噪声和零调试时还会怀疑是硬件坏了。2.3 触发点与开关边沿之间的距离贴着采但别贴着开关噪声选定了谷底触发之后还面临一个更精细的问题触发点离开关边沿多远才合适。在SVPWM的一个周期里PWM输出从零矢量000切换到有效矢量时会存在一个具体的开关边沿。如果ADC的采样窗口正好压在开关边沿附近采样电阻上的电压会因为寄生电感和di/dt产生严重振铃运放输出也会跟着抖。这时候采到的电流值带毛刺电流环的PI输出也跟着毛刺电机声音会变差甚至引起过流误保护。我在这类项目里的做法是分两步调整第一步把ADC采样时间从15个ADC时钟周期放大到56甚至84个时钟周期让采样保持电容有更充分的时间稳定第二步如果采样窗口还是和开关振铃重叠就在定时器输出比较通道上做一个小的触发偏移让ADC触发点延后几百纳秒到一微秒。但要注意采样点也不能无限制往后拖。调制比升高之后零矢量000的持续时间会变短如果触发点拖到有效矢量才启动转换采到的就是错误的电流。所以这个触发偏移量需要在最大调制比下验证过确保零矢量窗口仍然足够覆盖整个采样保持时间。3. DMA双缓冲改造让ISR从搬运工变成调度员3.1 为什么轮询等待ADC是最亏的做法原始代码里那段while ((ADC1-SR ADC_SR_EOC) 0);看着不起眼实际上是整个FOC ISR里最亏的一段。ADC在转换时CPU在轮询标志位这里干等着什么都做不了。而ADC本身的转换逻辑是在硬件里完成的CPU本来完全可以用这段时间准备别的数据或者干脆做一部分不需要采样结果的运算。对于一个实时性要求极高的电流环这种阻塞式等待还会引入不确定的抖动影响电流环的性能。改成DMA之后ADC转换完成的数据会自动搬运到指定内存不需要CPU逐次读取ISR也能从“等数据”变成“数据来了直接拿去算”。更关键的是ADC扫描模式下三路通道全部转换完DMA会产生一个传输完成中断CPU只需要处理一次中断而不是每转换完一路就打断一次。3.2 双缓冲设计一个缓冲在算一个缓冲在采我把采样缓冲改成了双缓冲结构也就是用两块内存区域轮流接收DMA搬运的数据。一块正在被CPU读取使用的时候另一块已经被DMA填好了准备切换。在STM32F4上可以通过DMA的双缓冲模式直接实现也可以用循环模式配合半传输/全传输中断来模拟。/* 双缓冲两块内存轮流被DMA填充 */ #define FOC_SAMPLE_NUM 3 __IO uint16_t adc_buf[2][FOC_SAMPLE_NUM]; volatile uint8_t boot_buf_done; void DMA1_Stream0_IRQHandler(void) { if ((DMA1-HISR DMA_HISR_TCIF0) ! 0) { DMA1-HIFCR DMA_HIFCR_CTCIF0; dma_cur_buf ^ 1; /* DMA已经自动切到另一块 */ FOC_SampleReady 1; /* 通知控制逻辑采样完毕 */ } } /* 控制逻辑里读取“刚填完”的那块缓冲 */ uint16_t *cur (uint16_t *)adc_buf[dma_cur_buf ^ 1];DMA配置时要注意几个关键参数内存数据宽度必须和ADC数据寄存器一致12位数据存到16位变量里应该用半字HalfWord宽度外设地址固定为ADC1-DR内存地址用递增模式传输方向是外设到内存如果开了双缓冲模式必须在初始化时就把两块内存地址分别写入DMA_SxM0AR和DMA_SxM1AR。改成双缓冲之后ADC三路转换加DMA搬运大约耗时仍是4到5微秒但这段时间CPU完全不用参与ISR的总时长明显下降了。3.3 控制数学到底该放在ISR里还是主循环里DMA改造完之后很多人会纠结一个问题电流环的数学运算放在ISR里还是放在主循环里轮询标志位。我的建议是16kHz以上的电流环运算还是放在高优先级中断里更合适。原因是电流环对相位延迟极其敏感如果你把运算放到主循环里一旦主循环被某个耗时稍长的任务阻塞控制周期就会出现抖动轻则电流波形变差重则电流环失稳。放在ISR里只要控制周期稳定问题就简单得多。那ISR能不能缩短能。DMA传输完成中断里最好只做三件事清除标志位、切换缓冲索引、置一个FOC_SampleReady标志位。真正的坐标变换和PI运算放在同一个ISR的后续阶段但不要嵌套其他外设的中断处理逻辑。CAN、串口、上位机这些对实时性要求没那么高的东西全部放到主循环或者更低优先级的中断里去。4. 坐标变换与PI运算里的数学暗礁4.1 先治标把重复除法换成预计算的乘法原始代码里电流标定那段每次都要算好几遍除法float ia (float)raw[0] * 3.3f / 4095.0f / 0.01f / 20.0f - offset_a;在主频168MHz的M4F上单精度浮点除法大约需要14个周期左右比一次乘法贵很多。更重要的是这段标定系数在整个运行过程中根本不会变完全可以在初始化阶段一次性算好运行期间只做一次乘法和一次减法。/* 初始化阶段算好系数 */ float ia_scale vref / 4095.0f / shunt_r / amp_gain; float ia_offset ...; /* 电流环里直接乘 */ float ia (float)raw[0] * ia_scale - ia_offset;这类改动看起来微不足道但在16kHz的电流环里把三路采样标定全改成一次乘减每次ISR能省下大约150到200个周期占优化总收益的近十分之一。做性能优化时千万不要小看这种“小钱”积少成多才是正道。4.2 三角函数查表精度与开销的权衡原始代码直接调用标准数学库的cosf和sinf这是整套FOC代码里最贵的一笔开销。标准数学库为了追求通用性和精度使用了比较复杂的多项式逼近在M4F上每次调用大概要上百个周期。如果你一不小心写成了cos()而不是cosf()就会把单精度浮点变成双精度软浮点运算那开销直接翻好几倍。对于电流环来说电角度θ需要的三角函数精度根本用不着标准库那么高。我用的是1024点正弦查表加线性插值最大误差在10的负5次方量级电流环完全感觉不到区别但单次sin或cos的耗时从上百周期降到了二三十个周期。查表实现起来并不复杂但有个细节值得注意如果每个周期都要同时算sin θ和cos θ千万不要调两次查表函数。把两个查表合并在一个函数里表只查一遍插值系数只算一遍。#define SIN_TABLE_SIZE 1024 static const float sin_table[SIN_TABLE_SIZE]; static inline void sincos_fast(float theta, float *out_sin, float *out_cos) { float idx_f theta * (float)SIN_TABLE_SIZE / TWO_PI; uint32_t idx (uint32_t)idx_f; float frac idx_f - (float)idx; uint32_t idx1 (idx 1) (SIN_TABLE_SIZE - 1); float s0 sin_table[idx]; float s1 sin_table[idx1]; *out_sin s0 (s1 - s0) * frac; /* cos就是sin向前移90度也就是1/4表长度 */ uint32_t cidx (idx SIN_TABLE_SIZE / 4) (SIN_TABLE_SIZE - 1); uint32_t cidx1 (cidx 1) (SIN_TABLE_SIZE - 1); float c0 sin_table[cidx]; float c1 sin_table[cidx1]; *out_cos c0 (c1 - c0) * frac; }表用const数组放在Flash里读取时走指令缓存性能很稳定。有一类实现喜欢把三角函数表放在RAM里我建议没必要除非你的Flash读取因为外部总线太慢而成为瓶颈。4.3 把SVPWM的扇区判断从atan2变成整数比较在早期的参考代码里SVPWM部分是通过atan2f(v_beta, v_alpha)算出电压矢量角然后根据角度区间判断扇区。这种写法逻辑上很清晰但atan2f在M4F上是一笔相当贵的开销而且每个控制周期都要算一次。更好的做法是直接用电压矢量的两个分量做符号判断这种方法在很多电机控制的应用笔记里都有核心思想是把电压矢量投影到三条间隔120°的轴上每条轴的符号形成一个3位编码直接映射到扇区。static inline uint8_t svm_sector(float valpha, float vbeta) { float v1 vbeta; float v2 0.8660254f * valpha - 0.5f * vbeta; float v3 -0.8660254f * valpha - 0.5f * vbeta; uint8_t sector 0; if (v1 0.0f) sector | 1; if (v2 0.0f) sector | 2; if (v3 0.0f) sector | 4; return sector; }这段代码里没有除法没有三角函数也没有if/else长链条整个扇区判断只用了三次乘加和三次浮点比较编译器在M4F上可以把它们排得相当紧凑。感兴趣的同行可以把原来的atan2f版本和这个版本分别汇编出来对比差距非常直观。4.4 消除全局变量的来回搬运还有一个不太容易注意到的开销原始代码习惯把中间计算结果保存在全局变量里比如先写g_ialpha下一次运算再读出来。编译器在优化这种代码时往往束手束脚因为全局变量可能在任意地方被修改导致它无法把中间值留在FPU寄存器里。我的做法是一个控制周期内的所有中间量全部用局部变量承接函数之间用参数传递只在最终需要输出到外设或者供其他模块查询时才写入全局变量。这既能减少内存读写又能让编译器更好地利用FPU寄存器。为了进一步减少函数调用开销Clarke、Park、SVPWM这几个热函数都改成static inline放在头文件里。static inline void clarke_transform(float ia, float ib, float *ialpha, float *ibeta) { *ialpha ia; *ibeta (ia 2.0f * ib) * ONE_OVER_SQRT3; } static inline void park_transform(float ialpha, float ibeta, float sin_theta, float cos_theta, float *id, float *iq) { *id ialpha * cos_theta ibeta * sin_theta; *iq -ialpha * sin_theta ibeta * cos_theta; }这样改完以后整个电流环的函数调用栈几乎摊平了编译器能看到全部中间变量的生命周期寄存器分配质量明显提高。这部分优化不改变任何算法逻辑但周期数能再省10%左右。5. 编译器选项、内存排布和volatile最后一层看不见的收益5.1 编译选项与FPU的ABI问题代码层面的优化做得差不多之后我把注意力转到编译器上。这里有一个非常关键但很多人会踩的坑M4F处理器的FPU必须配合正确的编译选项否则浮点运算根本不会用硬件单元。对STM32F4正确的编译参数应该是-mcpucortex-m4 -mthumb -mfloat-abihard -mfpufpv4-sp-d16 -O2-mfloat-abihard表示浮点参数通过FPU寄存器传递如果写成softfp虽然浮点运算也会用硬件指令但函数传参仍然走整数寄存器中间多一层搬运。检查编译出的汇编文件里有没有vldr、vadd.f32这类指令就能确认FPU有没有真正用上。优化级别方面我用的是-O2。对这段电流环代码-O3带来的额外收益有限反而可能因为激进优化导致代码体积变大、Flash取指压力上升。我还试过-ffast-math电流环确实能再快一点点但它允许编译器做更多的重排序和无符号浮点假设对于控制系统中可能出现的除零、越界情况不太友好我最后没有在生产代码里开它。5.2 把热数据塞进CCM RAMF4专属的免费午餐STM32F4有一块64KB的CCM RAM地址在0x10000000它和CPU紧耦合访问延迟比普通SRAM略低而且不会和DMA抢总线。但代价是DMA访问不了这块内存。我在这个项目里把电流环的几个关键状态量比如PI累加器、当前电角度、电流参考值放进了CCM RAM。__attribute__((section(.ccmram))) static float pi_q_accum; __attribute__((section(.ccmram))) static float theta_elec;这里有个大坑如果你用的是CMSIS自带的启动文件默认可能不会对.ccmram段做初始化。这会导致放在里面的全局变量在复位后是随机值。你必须自己在启动文件或者SystemInit里加上对CCM段的清理和拷贝逻辑否则第一次上电电流环就会因为PI累加器初始化为垃圾值而炸管子。DMA使用的缓冲区千万不能放CCM因为DMA访问不了这块区域。缓冲区老老实实放在普通SRAM里控制变量放CCM这个分工要记清楚。5.3 volatile用不对优化会把你的标志位“吃掉”DMA改造之后FOC_SampleReady这个标志位是在中断里置位、在主循环或者控制流程里查询的。如果这个变量没有声明成volatile编译器在优化时可能认为主循环里没有任何地方会修改它直接把查询条件简化成死循环。这是C语言里一个经典的未定义行为也是很多“一开优化代码就跑飞”的元凶。/* ISR里置位控制流程里查询 */ volatile uint8_t FOC_SampleReady 0;对于单字节或者单字的标志位volatile在Cortex-M上通常就够用了。但如果你的中断和数据缓冲区之间有更复杂的共享结构体建议用临界区保护__disable_irq(); memcpy(local_buf, shared_buf, sizeof(local_buf)); __enable_irq();在FOC代码里我不主张滥用关中断每次关中断都会增加电流环时间抖动的风险。所以共享数据越少越好能用一个标志位解决的不要搞复杂结构体。5.4 const和restrict给编译器更多优化空间查表函数里的sin_table声明为const可以让编译器确定它不会被修改从而放心把数组放进Flash并且在读取时采用更高效的加载方式。对于指针参数加上restrict关键字可以告诉编译器这些指针指向的区域不会重叠编译器就能更大胆地用寄存器和缓存。void controller_run(float *restrict id_ref, float *restrict iq_ref, float *restrict id_fb, float *restrict iq_fb);这些细节单独拿出来看收益都不大但叠加在一起编译器生成的代码质量会有肉眼可见的提升。做完这些之后我对比了一下优化前后的汇编ISR里的浮点运算几乎全部变成FPU寄存器操作内存搬运少了很多。6. 优化后的实测数据与三个差点翻车的坑6.1 优化前后的性能对比整个优化做完以后我在同样的硬件、同样的开关频率下重新用DWT周期计数器和GPIO测了时长阶段主要改动ISR耗时168MHz占16kHz周期的比例V0基线轮询EOC 库函数cosf/sinf 多次除法约11.3µs约18%V1DMA双缓冲 合并缩放系数 查表 整数扇区约5.8µs约9.3%V2内联函数 局部变量化 CCM 编译选项约4.9µs约7.8%从11.3微秒降到4.9微秒优化收益超过一半。更重要的是ISR的结构变好了没有阻塞式等待没有昂贵的数学库调用中断里要做的事情非常确定。把开关频率从16kHz提到32kHz之后控制周期从62.5微秒缩短到31.25微秒4.9微秒的ISR占比约15.7%系统还能腾出时间跑CAN、跑上位机诊断这在优化前几乎做不到。电流波形上的改善也比较直观优化前在电流过零附近偶尔能看到采样毛刺导致的抖动优化后波形干净了很多。这是因为采样时刻移到了真正的谷底窗口而且DMA方式减少了采样时刻的抖动。6.2 坑一双缓冲标志反了电流环白吃一个周期的旧数据第一次改DMA双缓冲的时候我犯了一个典型的错误。DMA在传输完成中断里已经自动把内存指针切换到了另一块缓冲我却在中断里直接置了一个标志位表示“当前缓冲已经填完”然后控制代码里去读当前缓冲。结果读出来的永远是上一块、也就是上一拍的旧数据。从代码上我后来用了一个dma_cur_buf ^ 1来读取刚填完的那块缓冲逻辑上才正确。如果你用的是寄存器配置建议在调试阶段用两个GPIO分别代表buffer0和buffer1的传输完成用逻辑分析仪观察切换时序和PWM周期的对齐关系。一个控制周期的数据延迟看起来不算大但在电流环这种高带宽的闭环系统里额外一个周期的延迟会实打实地降低相位裕度电机的动态响应会变差刹车或者加载时更容易啸叫。6.3 坑二采样点没避开开关振铃电流毛刺全进来了DMA改造后我把ADC触发点配置在了谷底但一开始没有对采样时刻和开关边沿的间距做精细调整。结果电流波形在扇区切换点附近出现明显的尖刺尤其是调制比比较大的时候尖刺更严重。排查过程很简单用示波器同时测PWM输出和采样电阻两端的电压。能清楚看到在PWM边沿之后采样电阻电压上叠加了一段大约几百纳秒到一微秒的振铃而ADC的采样窗口正好压在这段振铃上。解决办法就是我前面提到的两步加大ADC采样时间让采样保持电容在振铃结束后有更长的稳定窗口再把ADC触发点用输出比较通道做一个小的延时偏移让它离上一个开关边沿再远一点。有人可能会问为什么不直接用一个硬件低通滤波器把振铃滤掉可以但低通会带来相位延迟高带宽电流环通常不愿意为这个买单。所以我更倾向于在触发时序上解决问题而不是在信号链路上加滤波器。6.4 坑三volatile漏了一个标志位开-O2后控制流程卡死在调试早期FOC_SampleReady这个标志位我一开始没有加volatile。编译级别低的时候一切正常从-O0切到-O2之后主循环里的查询条件“看起来永远不会成立”程序表现像是进入了死循环。查了半天最后反汇编一看编译器把标志位查询优化成了读取寄存器里的常量因为它判定全局变量在循环体内没有被任何代码修改。这类问题的排查思路很明确凡是中断和主循环共享的变量一律加volatile如果共享的数据结构超过一个机器字就用临界区保护。不要试图“这次不加volatile也侥幸能用”在编译器版本升级之后同样的问题还会再来找你。6.5 一点更远的扩展想法做完这个优化项目之后我还有个体会这套“先量化、再解耦、再降开销”的思路并不仅仅适用于FOC电流采样。ADC采集、通信协议栈、传感器数据处理几乎所有的嵌入式性能问题都可以套用同样的流程。特别是DMA双缓冲精简中断这套组合拳在CAN总线收发、以太网包搬运、数据采集前端里都是到处可见的通用套路。如果你用的是M0/M0这类没有硬件除法器和FPU的MCU本文里的浮点运算优化思路甚至可以更激进直接改成定点数学。浮点数标定系数在编译时可以换算成整数比例查表也能用整数索引实现。不过那就要注意动态范围和溢出问题了是另外一个比今天长得多的话题。最后分享一个我个人的习惯每次优化完一段代码我都会把优化前后的周期数、改动点、踩过的坑记在项目笔记里。隔一段时间再看往往能发现以前忽略掉的更低成本的方案。性能优化这件事永远有下一层空间。性能优化的最终目的不是把某一段代码的周期数压到极致而是把CPU时间还给真正需要它的功能。我把这段FOC电流采集代码从11.3微秒优化到4.9微秒之后系统才有余量去支持更高的开关频率、更复杂的观测器和更完善的上位机诊断。如果你手头的电机控制项目也碰到类似的CPU吃紧问题建议先拿起DWT计数器老老实实把耗时量出来再对症下药。
做电机控制的同行应该都有类似的经历算法层面已经调通电机转起来波形也漂亮但CPU负载一直压不下来。尤其是当你把开关频率从16kHz提到32kHz或者在同一颗MCU上同时跑CAN通信、上位机调试和故障保护的时候电流采样这条链路的性能会瞬间变成整个系统的瓶颈。这篇文章是我“嵌入式性能优化”系列的第11篇记录的是对一个实际PMSM驱动项目中FOC电流采集代码的完整优化过程。项目主控是STM32F407主频168MHz开关频率16kHz电流环每隔62.5微秒需要完成一次采样、坐标变换、电流环PI和SVPWM输出。如果你正在用FOC做电机驱动或者刚把网上例程里的FOC代码搬进自己的工程这篇文章里提到的思路和坑大概率你也会碰到。1. 我拿到的那版代码到底慢在哪先定位再动手1.1 原始实现的基本盘16kHz电流环全挤在一个中断里这段代码不是从零开始写的而是从一套“能转起来”的参考实现里改出来的。它的结构非常典型TIM1更新中断触发ADC转换然后在同一个中断服务函数里轮询等待转换完成紧接着做电流标定、Clarke变换、Park变换、PI运算、逆Park和SVPWM输出。/* 优化前的核心结构TIM1更新中断里轮询ADC并完成全部FOC运算 */ void TIM1_UP_TIM10_IRQHandler(void) { uint16_t raw[3]; uint8_t i; /* 触发规则组转换3个通道扫描 */ ADC1-CR2 | ADC_CR2_SWSTART; /* CPU在这里空转等待三路转换完成 */ for (i 0; i 3; i) { while ((ADC1-SR ADC_SR_EOC) 0); raw[i] ADC1-DR; ADC1-SR ~ADC_SR_EOC; } /* 电流标定每次都算一遍除法 */ float ia (float)raw[0] * 3.3f / 4095.0f / 0.01f / 20.0f - offset_a; float ib (float)raw[1] * 3.3f / 4095.0f / 0.01f / 20.0f - offset_b; /* Clarke变换 */ float ialpha ia; float ibeta (ia 2.0f * ib) * 0.577350269f; /* Park变换直接调标准数学库的cosf/sinf */ float ct cosf(theta); float st sinf(theta); float id ialpha * ct ibeta * st; float iq -ialpha * st ibeta * ct; /* 电流环PI、逆Park、SVPWM、装载CCR */ /* ... */ }第一版跑通的时候电机确实能转电流波形在示波器上也勉强能看。但有几个现象特别明显打开CAN总线发包之后偶尔会出现控制毛刺想加一个上位机实时波形显示CPU就紧张了把开关频率提到32kHz试了一下整个系统几乎被电流环吃死。这个时候我才决定老老实实坐下来做性能优化。1.2 用DWT的CYCCNT把耗时钉死别靠感觉猜性能优化第一步永远是量化不能靠“感觉这个函数挺慢”来猜。我用的办法是在Cortex-M内核上开启DWT的CYCCNT计数器它是内核里的一个32位周期计数器每个主频周期加一测FOC代码段的耗时非常方便。/* 初始化DWT周期计数器 */ static void dwt_init(void) { CoreDebug-DEMCR | CoreDebug_DEMCR_TRCENA_Msk; DWT-CYCCNT 0; DWT-CTRL | DWT_CTRL_CYCCNTENA_Msk; } /* 在ISR里打点测耗时 */ void TIM1_UP_TIM10_IRQHandler(void) { uint32_t t_start DWT-CYCCNT; /* ... 整个采样控制逻辑 ... */ uint32_t t_cost DWT-CYCCNT - t_start; if (t_cost max_cost) { max_cost t_cost; /* 记录峰值通过调试器观察 */ } }为了能看到包含中断进出栈在内的真实耗时我同时在ISR入口拉高一个GPIO、出口拉低用逻辑分析仪测量脉冲宽度。这样得到的数据和DWT计数器互相印证比单独看任何一项都可靠。实测结果这段代码在最坏情况下大约要跑1900个周期左右折算到168MHz主频大约是11.3微秒。注意16kHz开关频率下整个控制周期才62.5微秒这意味着一个ISR就吃掉了将近18%的CPU时间。听起来好像还行但加上通信、显示、保护逻辑CPU负载就非常难看了。1.3 瓶颈排序最大的浪费不是数学运算把11.3微秒逐项拆开之后我发现最大的浪费有三处环节估算周期数问题ADC三路EOC轮询等待约500转换期间CPU空转什么都干不了电流标定中的多次浮点除法约180每次采样都重复算同样的除法cosf/sinf标准库函数约350从标准数学库拉进来的软浮点版本开销大Clarke/Park及PI常规乘加约550FPU上不算贵但存在冗余的全局变量读写中断现场保存与恢复约80不可避免但ISR太长会放大它的影响其他状态判断、限幅等约240分散开销真正让我意外的是单纯看单点开销没有任何一个环节是“天价”。问题出在它们叠加在一起而且整段代码的结构把所有耗时都串行化了。特别是第一步的轮询等待ADC转换大概需要4到5微秒这期间CPU完全是在干等。如果能让ADCDMA自己去搬数据同时把数学运算里那些不必要的库函数调用和重复除法去掉性能立刻就能上一个台阶。2. 采样时刻死磕在下桥导通窗口这不是玄学是硬件原理2.1 为什么FOC电流采集要设置在下桥导通期间很多初学者看FOC电流采样的代码看到ADC触发点配置在下桥导通的时间点第一反应是“为什么不挑个方便的时候”。这个问题问得好原因要从采样电阻的位置说起。常见的低成本电流采样方案是低边采样也就是在每个桥臂的下管源极串一个毫欧级采样电阻。当某个下管导通时流过这个采样电阻的电流就是对应相绕组的相电流当下管关断时采样电阻上要么没有电流要么流的是死区时间里通过续流二极管的那部分电流无法反映真实相电流。在中心对齐的SVPWM里一个载波周期的谷底对应的是零矢量000也就是三个下管全部导通。这个时候三个采样电阻上的电流刚好分别是A、B、C三相的相电流是一次性采齐三相电流的最佳窗口。而载波周期的峰值对应的是零矢量111三个上管全部导通此时三个下管全部关断采样电阻上什么都采不到。所以“为什么设置在下桥”本质上是一个采样窗口选择问题你要在下管导通、且三个下管同时导通的时间点去触发ADC。这个时间点就是中心对齐PWM的谷底。2.2 中心对齐PWM下的触发点配置在STM32上实现“谷底触发ADC”的经典做法是让定时器在中心对齐模式下产生更新事件作为ADC的外部触发源再把ADC配置成外部触发启动转换。/* 中心对齐模式2只在计数器下溢谷底时产生更新事件 */ TIM1-CR1 | TIM_CR1_CMS_1; /* CMS10 */ /* TRGO选择为更新事件 */ TIM1-CR2 | TIM_CR2_MMS_1; /* ADC1规则组外部触发选择TIM1_TRGO */ ADC1-CR2 | ADC_CR2_EXTEN_0; ADC1-CR2 | (ADC_CR2_EXTSEL_0 | ADC_CR2_EXTSEL_1 | ADC_CR2_EXTSEL_3);这里有个容易被忽略的点中心对齐模式有三种区别在于更新事件产生的位置。模式1只在计数器上溢峰值时产生更新事件模式2只在计数器下溢谷底时产生模式3是上下溢各产生一次。你要在谷底触发ADC就必须选用模式2或者用模式3但通过其他方式区分上下溢。很多例程默认给的是模式1结果触发点跑到了峰值下管全部关断采样出来全是噪声和零调试时还会怀疑是硬件坏了。2.3 触发点与开关边沿之间的距离贴着采但别贴着开关噪声选定了谷底触发之后还面临一个更精细的问题触发点离开关边沿多远才合适。在SVPWM的一个周期里PWM输出从零矢量000切换到有效矢量时会存在一个具体的开关边沿。如果ADC的采样窗口正好压在开关边沿附近采样电阻上的电压会因为寄生电感和di/dt产生严重振铃运放输出也会跟着抖。这时候采到的电流值带毛刺电流环的PI输出也跟着毛刺电机声音会变差甚至引起过流误保护。我在这类项目里的做法是分两步调整第一步把ADC采样时间从15个ADC时钟周期放大到56甚至84个时钟周期让采样保持电容有更充分的时间稳定第二步如果采样窗口还是和开关振铃重叠就在定时器输出比较通道上做一个小的触发偏移让ADC触发点延后几百纳秒到一微秒。但要注意采样点也不能无限制往后拖。调制比升高之后零矢量000的持续时间会变短如果触发点拖到有效矢量才启动转换采到的就是错误的电流。所以这个触发偏移量需要在最大调制比下验证过确保零矢量窗口仍然足够覆盖整个采样保持时间。3. DMA双缓冲改造让ISR从搬运工变成调度员3.1 为什么轮询等待ADC是最亏的做法原始代码里那段while ((ADC1-SR ADC_SR_EOC) 0);看着不起眼实际上是整个FOC ISR里最亏的一段。ADC在转换时CPU在轮询标志位这里干等着什么都做不了。而ADC本身的转换逻辑是在硬件里完成的CPU本来完全可以用这段时间准备别的数据或者干脆做一部分不需要采样结果的运算。对于一个实时性要求极高的电流环这种阻塞式等待还会引入不确定的抖动影响电流环的性能。改成DMA之后ADC转换完成的数据会自动搬运到指定内存不需要CPU逐次读取ISR也能从“等数据”变成“数据来了直接拿去算”。更关键的是ADC扫描模式下三路通道全部转换完DMA会产生一个传输完成中断CPU只需要处理一次中断而不是每转换完一路就打断一次。3.2 双缓冲设计一个缓冲在算一个缓冲在采我把采样缓冲改成了双缓冲结构也就是用两块内存区域轮流接收DMA搬运的数据。一块正在被CPU读取使用的时候另一块已经被DMA填好了准备切换。在STM32F4上可以通过DMA的双缓冲模式直接实现也可以用循环模式配合半传输/全传输中断来模拟。/* 双缓冲两块内存轮流被DMA填充 */ #define FOC_SAMPLE_NUM 3 __IO uint16_t adc_buf[2][FOC_SAMPLE_NUM]; volatile uint8_t boot_buf_done; void DMA1_Stream0_IRQHandler(void) { if ((DMA1-HISR DMA_HISR_TCIF0) ! 0) { DMA1-HIFCR DMA_HIFCR_CTCIF0; dma_cur_buf ^ 1; /* DMA已经自动切到另一块 */ FOC_SampleReady 1; /* 通知控制逻辑采样完毕 */ } } /* 控制逻辑里读取“刚填完”的那块缓冲 */ uint16_t *cur (uint16_t *)adc_buf[dma_cur_buf ^ 1];DMA配置时要注意几个关键参数内存数据宽度必须和ADC数据寄存器一致12位数据存到16位变量里应该用半字HalfWord宽度外设地址固定为ADC1-DR内存地址用递增模式传输方向是外设到内存如果开了双缓冲模式必须在初始化时就把两块内存地址分别写入DMA_SxM0AR和DMA_SxM1AR。改成双缓冲之后ADC三路转换加DMA搬运大约耗时仍是4到5微秒但这段时间CPU完全不用参与ISR的总时长明显下降了。3.3 控制数学到底该放在ISR里还是主循环里DMA改造完之后很多人会纠结一个问题电流环的数学运算放在ISR里还是放在主循环里轮询标志位。我的建议是16kHz以上的电流环运算还是放在高优先级中断里更合适。原因是电流环对相位延迟极其敏感如果你把运算放到主循环里一旦主循环被某个耗时稍长的任务阻塞控制周期就会出现抖动轻则电流波形变差重则电流环失稳。放在ISR里只要控制周期稳定问题就简单得多。那ISR能不能缩短能。DMA传输完成中断里最好只做三件事清除标志位、切换缓冲索引、置一个FOC_SampleReady标志位。真正的坐标变换和PI运算放在同一个ISR的后续阶段但不要嵌套其他外设的中断处理逻辑。CAN、串口、上位机这些对实时性要求没那么高的东西全部放到主循环或者更低优先级的中断里去。4. 坐标变换与PI运算里的数学暗礁4.1 先治标把重复除法换成预计算的乘法原始代码里电流标定那段每次都要算好几遍除法float ia (float)raw[0] * 3.3f / 4095.0f / 0.01f / 20.0f - offset_a;在主频168MHz的M4F上单精度浮点除法大约需要14个周期左右比一次乘法贵很多。更重要的是这段标定系数在整个运行过程中根本不会变完全可以在初始化阶段一次性算好运行期间只做一次乘法和一次减法。/* 初始化阶段算好系数 */ float ia_scale vref / 4095.0f / shunt_r / amp_gain; float ia_offset ...; /* 电流环里直接乘 */ float ia (float)raw[0] * ia_scale - ia_offset;这类改动看起来微不足道但在16kHz的电流环里把三路采样标定全改成一次乘减每次ISR能省下大约150到200个周期占优化总收益的近十分之一。做性能优化时千万不要小看这种“小钱”积少成多才是正道。4.2 三角函数查表精度与开销的权衡原始代码直接调用标准数学库的cosf和sinf这是整套FOC代码里最贵的一笔开销。标准数学库为了追求通用性和精度使用了比较复杂的多项式逼近在M4F上每次调用大概要上百个周期。如果你一不小心写成了cos()而不是cosf()就会把单精度浮点变成双精度软浮点运算那开销直接翻好几倍。对于电流环来说电角度θ需要的三角函数精度根本用不着标准库那么高。我用的是1024点正弦查表加线性插值最大误差在10的负5次方量级电流环完全感觉不到区别但单次sin或cos的耗时从上百周期降到了二三十个周期。查表实现起来并不复杂但有个细节值得注意如果每个周期都要同时算sin θ和cos θ千万不要调两次查表函数。把两个查表合并在一个函数里表只查一遍插值系数只算一遍。#define SIN_TABLE_SIZE 1024 static const float sin_table[SIN_TABLE_SIZE]; static inline void sincos_fast(float theta, float *out_sin, float *out_cos) { float idx_f theta * (float)SIN_TABLE_SIZE / TWO_PI; uint32_t idx (uint32_t)idx_f; float frac idx_f - (float)idx; uint32_t idx1 (idx 1) (SIN_TABLE_SIZE - 1); float s0 sin_table[idx]; float s1 sin_table[idx1]; *out_sin s0 (s1 - s0) * frac; /* cos就是sin向前移90度也就是1/4表长度 */ uint32_t cidx (idx SIN_TABLE_SIZE / 4) (SIN_TABLE_SIZE - 1); uint32_t cidx1 (cidx 1) (SIN_TABLE_SIZE - 1); float c0 sin_table[cidx]; float c1 sin_table[cidx1]; *out_cos c0 (c1 - c0) * frac; }表用const数组放在Flash里读取时走指令缓存性能很稳定。有一类实现喜欢把三角函数表放在RAM里我建议没必要除非你的Flash读取因为外部总线太慢而成为瓶颈。4.3 把SVPWM的扇区判断从atan2变成整数比较在早期的参考代码里SVPWM部分是通过atan2f(v_beta, v_alpha)算出电压矢量角然后根据角度区间判断扇区。这种写法逻辑上很清晰但atan2f在M4F上是一笔相当贵的开销而且每个控制周期都要算一次。更好的做法是直接用电压矢量的两个分量做符号判断这种方法在很多电机控制的应用笔记里都有核心思想是把电压矢量投影到三条间隔120°的轴上每条轴的符号形成一个3位编码直接映射到扇区。static inline uint8_t svm_sector(float valpha, float vbeta) { float v1 vbeta; float v2 0.8660254f * valpha - 0.5f * vbeta; float v3 -0.8660254f * valpha - 0.5f * vbeta; uint8_t sector 0; if (v1 0.0f) sector | 1; if (v2 0.0f) sector | 2; if (v3 0.0f) sector | 4; return sector; }这段代码里没有除法没有三角函数也没有if/else长链条整个扇区判断只用了三次乘加和三次浮点比较编译器在M4F上可以把它们排得相当紧凑。感兴趣的同行可以把原来的atan2f版本和这个版本分别汇编出来对比差距非常直观。4.4 消除全局变量的来回搬运还有一个不太容易注意到的开销原始代码习惯把中间计算结果保存在全局变量里比如先写g_ialpha下一次运算再读出来。编译器在优化这种代码时往往束手束脚因为全局变量可能在任意地方被修改导致它无法把中间值留在FPU寄存器里。我的做法是一个控制周期内的所有中间量全部用局部变量承接函数之间用参数传递只在最终需要输出到外设或者供其他模块查询时才写入全局变量。这既能减少内存读写又能让编译器更好地利用FPU寄存器。为了进一步减少函数调用开销Clarke、Park、SVPWM这几个热函数都改成static inline放在头文件里。static inline void clarke_transform(float ia, float ib, float *ialpha, float *ibeta) { *ialpha ia; *ibeta (ia 2.0f * ib) * ONE_OVER_SQRT3; } static inline void park_transform(float ialpha, float ibeta, float sin_theta, float cos_theta, float *id, float *iq) { *id ialpha * cos_theta ibeta * sin_theta; *iq -ialpha * sin_theta ibeta * cos_theta; }这样改完以后整个电流环的函数调用栈几乎摊平了编译器能看到全部中间变量的生命周期寄存器分配质量明显提高。这部分优化不改变任何算法逻辑但周期数能再省10%左右。5. 编译器选项、内存排布和volatile最后一层看不见的收益5.1 编译选项与FPU的ABI问题代码层面的优化做得差不多之后我把注意力转到编译器上。这里有一个非常关键但很多人会踩的坑M4F处理器的FPU必须配合正确的编译选项否则浮点运算根本不会用硬件单元。对STM32F4正确的编译参数应该是-mcpucortex-m4 -mthumb -mfloat-abihard -mfpufpv4-sp-d16 -O2-mfloat-abihard表示浮点参数通过FPU寄存器传递如果写成softfp虽然浮点运算也会用硬件指令但函数传参仍然走整数寄存器中间多一层搬运。检查编译出的汇编文件里有没有vldr、vadd.f32这类指令就能确认FPU有没有真正用上。优化级别方面我用的是-O2。对这段电流环代码-O3带来的额外收益有限反而可能因为激进优化导致代码体积变大、Flash取指压力上升。我还试过-ffast-math电流环确实能再快一点点但它允许编译器做更多的重排序和无符号浮点假设对于控制系统中可能出现的除零、越界情况不太友好我最后没有在生产代码里开它。5.2 把热数据塞进CCM RAMF4专属的免费午餐STM32F4有一块64KB的CCM RAM地址在0x10000000它和CPU紧耦合访问延迟比普通SRAM略低而且不会和DMA抢总线。但代价是DMA访问不了这块内存。我在这个项目里把电流环的几个关键状态量比如PI累加器、当前电角度、电流参考值放进了CCM RAM。__attribute__((section(.ccmram))) static float pi_q_accum; __attribute__((section(.ccmram))) static float theta_elec;这里有个大坑如果你用的是CMSIS自带的启动文件默认可能不会对.ccmram段做初始化。这会导致放在里面的全局变量在复位后是随机值。你必须自己在启动文件或者SystemInit里加上对CCM段的清理和拷贝逻辑否则第一次上电电流环就会因为PI累加器初始化为垃圾值而炸管子。DMA使用的缓冲区千万不能放CCM因为DMA访问不了这块区域。缓冲区老老实实放在普通SRAM里控制变量放CCM这个分工要记清楚。5.3 volatile用不对优化会把你的标志位“吃掉”DMA改造之后FOC_SampleReady这个标志位是在中断里置位、在主循环或者控制流程里查询的。如果这个变量没有声明成volatile编译器在优化时可能认为主循环里没有任何地方会修改它直接把查询条件简化成死循环。这是C语言里一个经典的未定义行为也是很多“一开优化代码就跑飞”的元凶。/* ISR里置位控制流程里查询 */ volatile uint8_t FOC_SampleReady 0;对于单字节或者单字的标志位volatile在Cortex-M上通常就够用了。但如果你的中断和数据缓冲区之间有更复杂的共享结构体建议用临界区保护__disable_irq(); memcpy(local_buf, shared_buf, sizeof(local_buf)); __enable_irq();在FOC代码里我不主张滥用关中断每次关中断都会增加电流环时间抖动的风险。所以共享数据越少越好能用一个标志位解决的不要搞复杂结构体。5.4 const和restrict给编译器更多优化空间查表函数里的sin_table声明为const可以让编译器确定它不会被修改从而放心把数组放进Flash并且在读取时采用更高效的加载方式。对于指针参数加上restrict关键字可以告诉编译器这些指针指向的区域不会重叠编译器就能更大胆地用寄存器和缓存。void controller_run(float *restrict id_ref, float *restrict iq_ref, float *restrict id_fb, float *restrict iq_fb);这些细节单独拿出来看收益都不大但叠加在一起编译器生成的代码质量会有肉眼可见的提升。做完这些之后我对比了一下优化前后的汇编ISR里的浮点运算几乎全部变成FPU寄存器操作内存搬运少了很多。6. 优化后的实测数据与三个差点翻车的坑6.1 优化前后的性能对比整个优化做完以后我在同样的硬件、同样的开关频率下重新用DWT周期计数器和GPIO测了时长阶段主要改动ISR耗时168MHz占16kHz周期的比例V0基线轮询EOC 库函数cosf/sinf 多次除法约11.3µs约18%V1DMA双缓冲 合并缩放系数 查表 整数扇区约5.8µs约9.3%V2内联函数 局部变量化 CCM 编译选项约4.9µs约7.8%从11.3微秒降到4.9微秒优化收益超过一半。更重要的是ISR的结构变好了没有阻塞式等待没有昂贵的数学库调用中断里要做的事情非常确定。把开关频率从16kHz提到32kHz之后控制周期从62.5微秒缩短到31.25微秒4.9微秒的ISR占比约15.7%系统还能腾出时间跑CAN、跑上位机诊断这在优化前几乎做不到。电流波形上的改善也比较直观优化前在电流过零附近偶尔能看到采样毛刺导致的抖动优化后波形干净了很多。这是因为采样时刻移到了真正的谷底窗口而且DMA方式减少了采样时刻的抖动。6.2 坑一双缓冲标志反了电流环白吃一个周期的旧数据第一次改DMA双缓冲的时候我犯了一个典型的错误。DMA在传输完成中断里已经自动把内存指针切换到了另一块缓冲我却在中断里直接置了一个标志位表示“当前缓冲已经填完”然后控制代码里去读当前缓冲。结果读出来的永远是上一块、也就是上一拍的旧数据。从代码上我后来用了一个dma_cur_buf ^ 1来读取刚填完的那块缓冲逻辑上才正确。如果你用的是寄存器配置建议在调试阶段用两个GPIO分别代表buffer0和buffer1的传输完成用逻辑分析仪观察切换时序和PWM周期的对齐关系。一个控制周期的数据延迟看起来不算大但在电流环这种高带宽的闭环系统里额外一个周期的延迟会实打实地降低相位裕度电机的动态响应会变差刹车或者加载时更容易啸叫。6.3 坑二采样点没避开开关振铃电流毛刺全进来了DMA改造后我把ADC触发点配置在了谷底但一开始没有对采样时刻和开关边沿的间距做精细调整。结果电流波形在扇区切换点附近出现明显的尖刺尤其是调制比比较大的时候尖刺更严重。排查过程很简单用示波器同时测PWM输出和采样电阻两端的电压。能清楚看到在PWM边沿之后采样电阻电压上叠加了一段大约几百纳秒到一微秒的振铃而ADC的采样窗口正好压在这段振铃上。解决办法就是我前面提到的两步加大ADC采样时间让采样保持电容在振铃结束后有更长的稳定窗口再把ADC触发点用输出比较通道做一个小的延时偏移让它离上一个开关边沿再远一点。有人可能会问为什么不直接用一个硬件低通滤波器把振铃滤掉可以但低通会带来相位延迟高带宽电流环通常不愿意为这个买单。所以我更倾向于在触发时序上解决问题而不是在信号链路上加滤波器。6.4 坑三volatile漏了一个标志位开-O2后控制流程卡死在调试早期FOC_SampleReady这个标志位我一开始没有加volatile。编译级别低的时候一切正常从-O0切到-O2之后主循环里的查询条件“看起来永远不会成立”程序表现像是进入了死循环。查了半天最后反汇编一看编译器把标志位查询优化成了读取寄存器里的常量因为它判定全局变量在循环体内没有被任何代码修改。这类问题的排查思路很明确凡是中断和主循环共享的变量一律加volatile如果共享的数据结构超过一个机器字就用临界区保护。不要试图“这次不加volatile也侥幸能用”在编译器版本升级之后同样的问题还会再来找你。6.5 一点更远的扩展想法做完这个优化项目之后我还有个体会这套“先量化、再解耦、再降开销”的思路并不仅仅适用于FOC电流采样。ADC采集、通信协议栈、传感器数据处理几乎所有的嵌入式性能问题都可以套用同样的流程。特别是DMA双缓冲精简中断这套组合拳在CAN总线收发、以太网包搬运、数据采集前端里都是到处可见的通用套路。如果你用的是M0/M0这类没有硬件除法器和FPU的MCU本文里的浮点运算优化思路甚至可以更激进直接改成定点数学。浮点数标定系数在编译时可以换算成整数比例查表也能用整数索引实现。不过那就要注意动态范围和溢出问题了是另外一个比今天长得多的话题。最后分享一个我个人的习惯每次优化完一段代码我都会把优化前后的周期数、改动点、踩过的坑记在项目笔记里。隔一段时间再看往往能发现以前忽略掉的更低成本的方案。性能优化这件事永远有下一层空间。性能优化的最终目的不是把某一段代码的周期数压到极致而是把CPU时间还给真正需要它的功能。我把这段FOC电流采集代码从11.3微秒优化到4.9微秒之后系统才有余量去支持更高的开关频率、更复杂的观测器和更完善的上位机诊断。如果你手头的电机控制项目也碰到类似的CPU吃紧问题建议先拿起DWT计数器老老实实把耗时量出来再对症下药。
