FOC电流采集代码性能优化：从ADC等待到DMA与查表

1. 优化前先看清楚：一段典型 FOC 电流采集代码的性能瓶颈

做 FOC 控制的工程师基本都经历过这样一个阶段：算法在仿真里跑得挺好，波形也很漂亮，一上板子就发现电流环跑不了太高频率，中断里干的事太多，CPU 占用率报警，甚至偶尔还出现采样数据跳变、电机噪音大。我最近在优化一套 PMSM 无感 FOC 方案时，就把电流采集这一段代码从头到尾捋了一遍，结论是：很多性能问题其实不是芯片算力不够，而是代码写法把算力浪费在了不该花的地方。

先说结论：FOC 电流采集代码的性能优化，核心目标不是把代码“写快”，而是把中断里的时间预算留给真正需要实时计算的部分。电流环中断是要在极短时间内完成电流采样、Clarke 变换、Park 变换、PI 调节、反 Park 变换、SVPWM 更新的，任何一个环节多耗几十个周期，整个控制频率就可能从 20kHz 掉到 16kHz，系统的动态响应和高转速性能都会受牵连。

这篇文章适合谁看？正在做 PMSM 无感 FOC、BLDC 方波/正弦波驱动，或者对电机控制代码做实时性优化的嵌入式工程师。我会把我实际优化过的一段电流采集代码拿出来，从采样触发方式、ADC 配置、数据搬运、数学计算四个层面拆解性能瓶颈，再给出每一步的优化做法和实测数据。以后你再看自己项目里的电流采集代码，应该能一眼看出哪些地方在浪费 CPU。

2. 优化前：一段典型的 FOC 电流采集代码到底慢在哪

2.1 原始代码长什么样

先贴一段我早期项目里的 FOC 电流采集代码，这段代码的结构在很多入门级的电机控制工程里都能看到。它跑在 PWM 定时器更新中断里，中断频率就是电流环频率，我当时的配置是 10kHz。

void TIM1_UP_IRQHandler(void) { if (TIM_GetITStatus(TIM1, TIM_IT_Update) != RESET) { TIM_ClearITPendingBit(TIM1, TIM_IT_Update); // 软件触发ADC转换 ADC_SoftwareStartConvCmd(ADC1, ENABLE); // 等待转换完成 while (ADC_GetFlagStatus(ADC1, ADC_FLAG_EOC) == RESET); int32_t ia = ADC_GetConversionValue(ADC1); ADC_SoftwareStartConvCmd(ADC1, ENABLE); while (ADC_GetFlagStatus(ADC1, ADC_FLAG_EOC) == RESET); int32_t ib = ADC_GetConversionValue(ADC1); ADC_SoftwareStartConvCmd(ADC1, ENABLE); while (ADC_GetFlagStatus(ADC1, ADC_FLAG_EOC) == RESET); int32_t ic = ADC_GetConversionValue(ADC1); // 减去零点偏置 ia -= ia_offset; ib -= ib_offset; ic -= ic_offset; // Clarke变换 float i_alpha = ia; float i_beta = (ia + 2 * ib) * 0.57735f; // Park变换 float cos_theta = cosf(theta); float sin_theta = sinf(theta); float id = i_alpha * cos_theta + i_beta * sin_theta; float iq = -i_alpha * sin_theta + i_beta * cos_theta; // PI调节、反Park、SVPWM... } }

这段代码功能上完全正确，但性能上到处都是坑。我当时测了一下，在 72MHz 主频的 Cortex-M3 上，从进中断到完成电流采集和坐标变换，大概花了 22 到 25 微秒。听着不多？但 10kHz 中断周期就是 100 微秒，光采集和变换就占了接近四分之一的时间预算，后面还要跑 PI、SVPWM、无感观测器，完全不够用。

2.2 三个明显的性能黑洞

第一个黑洞是软件触发 ADC 后的死等。ADC 转换虽然快，但每次转换都要等 EOC 标志位置位，这个 while 循环就在那空转。而且 ADC 每次启动还要重新配置触发源、等待稳定，三段采样串行执行，中间的时间全是浪费。更糟糕的是，这种写法把 ADC 转换时间完全暴露在中断关键路径上，中断里啥正事没干，就光等硬件干活了。

第二个黑洞是三角函数实时计算。代码里直接调cosf和sinf，这两个函数在带 FPU 的芯片上还能凑合，如果是没有 FPU 的 M3/M4F，一次cosf可能要几百个周期。我当时的 MCU 是带 FPU 的，但即便如此，两个三角函数也要 1 到 2 微秒。如果换成定点查表，这个开销能压到几百纳秒。

第三个黑洞是ADC 结果读取方式。直接用ADC_GetConversionValue()读数据寄存器，在部分芯片上会插入总线等待周期，而且三次读取之间完全没有流水线优化空间，CPU 就这么被拖住了。

注意这三个问题本质上不是“代码风格差”，而是“架构设计没有考虑到控制周期的实时性预算”。在 FOC 这种高实时性场景下，中断里的每一微秒都是算过的，不是能跑就行。

2.3 用性能剖析工具确认瓶颈

在我开始动手优化之前，先做了一件事：用 GPIO 翻转法测出中断里各段代码的实际耗时。方法很简单，在关键代码段前后分别拉高拉低一个 GPIO，然后用示波器看脉冲宽度。我测得的结果是这样的：

这个表格说明了一个重要事实：ADC 采样与等待相关的时间占了一半以上。如果不把 ADC 转换时间从关键路径上摘掉，后面再怎么优化数学计算，收益都很有限。所以我的优化顺序是：先动 ADC 触发和转换方式，再动数据搬运方式，最后才优化数学计算。这个顺序建议你也按着来，先解决大头，再做精细化调整。

3. 采样时机才是命根子：FOC 电流采样为什么必须和 PWM 同步

3.1 为什么 FOC 电流采样要设置在下桥

相关热搜词里出现频率特别高的一句话是“foc 电流采集为什么要设置在下桥”。这个问题正好是采样时机优化的引子，值得先讲透。

FOC 电流采样的常用方案是电阻采样，也就是在逆变器桥臂上串联采样电阻，通过测量电阻两端的压降来推算相电流。采样电阻放的位置不同，采样策略也不同。下桥采样是指采样电阻放在下桥 MOSFET 的源极和地之间，利用下桥导通时电流流过采样电阻的原理来获取相电流。

为什么要在下桥采样而不是上桥？因为上桥导通时，相电流确实在流动，但采样电阻上的电压是浮地的，需要差分放大器把电压降提取出来，电路复杂且成本高。而下桥采样时，下桥 MOSFET 导通，电流从电机相线流过下桥、采样电阻回到地，采样电阻的一端直接接地，另一端对地的电压就是电流乘以电阻值，用普通的运放就能放大，简单可靠。所以工程上绝大多数低压电机驱动板都用下桥采样。

但下桥采样有个前提条件：必须在下桥导通的时候才能采到正确的电流。如果下桥关闭、上桥导通，电流走的是上桥，采样电阻上没有电流信号，这时候采集的数据毫无意义。所以 FOC 电流采样必须和 PWM 开关状态严格同步，要在下桥导通的窗口期内启动 ADC 转换。

3.2 三段式 PWM 和七段式 PWM 的采样窗口差异

SVPWM 的调制方式会影响采样窗口。三段式 PWM（也称中心对齐、对称 PWM）在一个载波周期内，三相桥臂的开关状态会经历一个完整的“从全部下桥导通到部分上桥导通再到全部下桥导通”的过程。在 PWM 计数器的特定时刻，三相下桥全部导通，此时三个采样电阻上都有电流信号，是理想的采样时机。

七段式 PWM 的每个 PWM 周期被分成七个时间段，其中首尾两个时间段是零矢量，此时三相下桥全部导通或全部关断。在零矢量期间，三相电流仍然存在（续流），所以也可以采样。但要注意，零矢量期间采样到的电流方向和有效矢量期间相反吗？不，电流方向是一样的，只是电机相电流在这个阶段流经的是续流二极管和下桥，采样电阻上的信号依然有效。

实际操作中，最常用的采样触发点是PWM 计数器计数到 0 的时刻，也就是载波周期的起始点。在中心对齐模式下，此刻三相下桥全部导通，ADC 可以采到三路完整的相电流。也有工程师选择在计数到峰值时触发，那对应的是三相上桥全部导通的状态，下桥采样在这种时刻采不到信号，所以大多数用下桥采样的设计都会把采样点设在计数到 0 的地方。

我用一个真实的波形说明这个问题。示波器同时抓 PWM 输出和采样电阻上的电压，能看到在下桥导通窗口内，采样电阻电压是一个相对平缓的平台，而在开关切换瞬态，电压会有剧烈震荡。如果 ADC 的采样时刻落在开关切换的震荡区，采到的电流值就是毛刺，PI 调节器会被这些毛刺干扰，轻则电流噪音大，重则控制器发散。所以定时器触发 ADC 的时刻必须避开开关切换瞬态，选择在平台期的中间位置。

3.3 优化第一步：从软件触发改为硬件触发

理解了采样时机的重要性之后，第一项优化就顺理成章了：把 ADC 触发方式从软件触发改为定时器硬件触发。

原来的代码是在中断里启动 ADC 转换，然后死等。改法是把定时器的触发事件配置为 ADC 的触发源，让硬件在 PWM 计数到 0 时自动启动 ADC 转换。这样 ADC 转换和数据到达事件与 PWM 精确同步，不需要中断参与，中断里只需要处理已经转换完成的数据。

以 STM32 为例，配置思路是这样的（具体寄存器操作因型号而异）：

// 配置ADC为定时器触发 ADC_ExternalTrigConvCmd(ADC1, ENABLE); ADC_ExternalTrigConv = ADC_ExternalTrigConv_T1_CC2; // 由TIM1捕获比较2触发 // 配置TIM1产生触发信号 TIM_SelectOutputTrigger(TIM1, TIM_TRGOSource_Update); // 更新事件作为触发输出 // 或者更精确地，使用某个通道的比较事件 TIM_OC2Init(...); // 配置比较值，使得PWM计数到特定值时产生触发

这里的核心思想是让硬件完成“采样时刻控制”和“转换启动”两件事，CPU 完全不需要参与。ADC 转换完成后，数据会存放在 ADC 数据寄存器里，或者通过 DMA 搬运到内存。CPU 只在下一次中断到来时取走已经准备好的数据。

注意 硬件触发 ADC 时，要留意触发信号和 ADC 采样开始之间是有延时的。一般芯片手册会给出触发延迟时间，例如 STM32F4 系列的触发延迟大概是几个 ADC 时钟周期。在配置采样时刻时，要把这个延迟算进去，确保采样点仍然落在下桥导通的稳定窗口内。

优化做完这一步，中断里的轮询等待代码就完全删掉了。测了一下，中断关键路径从原来的 25 微秒直接降到 12 微秒左右，省下来的一半时间全在 ADC 等待上。

4. ADC 数据搬运优化：DMA 双缓冲把采集开销从关键路径上彻底摘掉

4.1 ADC 转换结果为什么要用 DMA

硬件触发 ADC 解决了“什么时候启动转换”的问题，但还有一个问题没解决：转换完成之后，CPU 怎么拿到数据。最原始的做法是中断里查询 EOC 标志位然后读寄存器，这种方式在上一节已经否掉了。另一种做法是 ADC 转换完成触发 DMA 请求，由 DMA 硬件把数据从 ADC 数据寄存器搬到内存变量里，全程不需要 CPU 参与。

对于 FOC 电流采集这种周期性很强的场景，DMA 几乎是标配。而且我建议用DMA 循环模式 + 双缓冲的设计，而不是简单的单缓冲。

单缓冲的问题是：DMA 搬完一次数据后要重新配置，或者要在中断里同步“DMA 已经搬完了”和“CPU 正在使用数据”这两个事件，搞不好就会产生数据覆盖冲突。双缓冲的含义是： DMA 在搬当前数据到缓冲区 A 的同时，CPU 在处理缓冲区 B 里的上一帧数据，两个缓冲区交替使用，互不干扰。

4.2 结合 FOC 场景的双缓冲设计

我在双电阻 FOC 方案里的具体做法是：

1. 用 ADC 的两个通道分别采集两相电流（第三相通过基尔霍夫定律计算），或者用三个通道采集三相电流。
2. 把 ADC 配置成扫描模式，一次触发依次转换多个通道。
3. ADC 转换完成后，DMA 按顺序把数据搬运到数组adc_buf[2][3]中。
4. DMA 传输完成中断只在“半传输”和“全传输”时触发，实际上每个 PWM 周期触发两次，一次对应前 3 个数据（缓冲区 A），一次对应后 3 个数据（缓冲区 B）。

伪代码示意：

volatile int32_t adc_buf[2][3]; volatile uint8_t dma_idx = 0; // 当前DMA正在填充的缓冲区索引 void DMA1_Channel1_IRQHandler(void) { if (DMA_GetITStatus(DMA1_IT_TC1)) { DMA_ClearITPendingBit(DMA1_IT_TC1); // 上半段传输完成 -> 当前使用缓冲区0的数据 process_foc_current((int32_t *)adc_buf[0]); } else if (DMA_GetITStatus(DMA1_IT_HT1)) { DMA_ClearITPendingBit(DMA1_IT_HT1); // 下半段传输完成 -> 当前使用缓冲区1的数据 process_foc_current((int32_t *)adc_buf[1]); } }

这里有个重要的同步问题：DMA 搬运到缓冲区 A 完成时，CPU 要处理的应该是缓冲区 B 里上一帧的数据，而不是缓冲区 A 刚搬完的数据。在 FOC 控制中，电流环的采样和控制存在一个 PWM 周期的延迟是可以接受的，甚至很多方案故意引入一拍延迟来换取计算的确定性和稳定性。所以 DMA 中断服务函数里不要直接使用刚写完的缓冲区，而是使用上一次 DMA 周期写入的另一块缓冲区数据。上面的伪代码里，我是直接用了“当前 DMA 刚完成”的缓冲区，这个在实际项目中要注意根据你的控制周期和 DMA 周期对齐情况设计。

更稳妥的办法是把 DMA 中断当作“数据就绪信号”，然后置一个标志位，真正的 FOC 计算放在更高优先级的控制中断里处理。控制中断去读“上一次 DMA 准备好的缓冲区”。这个思路实质上是解耦了电流采样数据的产生和消费，避免了在 DMA 中断里做复杂运算。

4.3 优化前后的中断负载实测

我把这一步做完后再测了一轮，中断里的耗时变化如下：

数据说明问题。光把 ADC 采集和数据搬运从关键路径上摘掉，就把电流环中断的耗时降到了原来的五分之一。这时候中断里剩下的时间全部留给坐标变换、PI 运算和 SVPWM 生成，控制频率从 10kHz 提升到 20kHz 甚至更高都有了空间。

5. 数学计算层优化：从浮点到定点查表，还能再抠出几个微秒

5.1 浮点运算在 FOC 中是主要开销吗

硬件触发和 DMA 已经解决了采样采集的大头，接下来就是数学计算。很多工程师会觉得 MCU 带了 FPU，浮点运算应该不慢，没必要做定点化。这个观点部分正确，但要看具体芯片和具体运算。

如果用的是带单精度 FPU 的 M4/M7，浮点加减乘除确实很快，几条指令就完事。但在 FOC 电流环里，有两个东西再快的 FPU 也救不了：一个是cosf/sin这类超越函数（库函数内部可能包含多项式展开、迭代逼近等），另一个是当代码用了double类型时，会强制调用软浮点库，慢到没法看。

我的建议是：在 FOC 电流环和速度环的热路径上，全部改用单精度float，并且把三角函数替换成查表或者定点整数运算。float的精度对于电流环 PI 控制器完全够用，电流采样本身最多 12 位 ADC，换算成物理量后浮点误差远小于硬件噪声。

5.2 Clarke/Park 变换的定点化改造

Clarke 变换和 Park 变换本身只是加减乘除，用浮点算没问题。如果芯片性能紧张或者想彻底去掉 FPU 的依赖，可以改成定点 Q 格式。我在一个使用无 FPU 的 Cortex-M0+ 的电机控制项目里试过定点化，直接把整段坐标变换从浮点改成了 Q15 格式，配合查表得到正余弦值。效果非常明显，坐标变换的时间从浮点模拟的 10 多微秒降到了 3 微秒以内。

定点化的核心是确定 Q 格式。电流采样值可以先做归一化处理，把 ADC 原始值（比如 0 到 4095）映射到 Q15 的有符号范围（-32768 到 32767），也就是把零点偏置减掉之后，满量程电流对应0x7FFF。反正切角度用查表得到 sin/cos 的 Q15 值，再做乘法累加时用 Q15 乘法，最后左移或右移恢复标度。

这里有个细节要注意：定点乘法是很容易溢出的。两个 Q15 数相乘，结果是 Q30，必须右移 15 位才能回到 Q15。如果中间累加需要更高精度，可以先用 Q31 或 Q32 做中间变量，最后归一到 Q15。这些在定点代码里都要提前设计好，不能随手乱算。

对于绝大多数用 M4/M7 的 FOC 项目，我建议不必强求全定点化，但把cosf/sin换成查表是无论如何都值得做的。

5.3 查表法替换三角函数的实现细节

角度查表的基本思路是：把 0 到 360 度分成 N 个点，预先把每个点的 cos 和 sin 值存到数组里，运行时根据当前角度索引直接取值。N 选多大？我常用 256 或者 512。256 点意味着角度分辨率是 360/256 = 1.40625 度，对于 FOC 电流环来说查到的 sin/cos 精度是 8 位左右，可能会有轻微谐波；512 点更好一些，内存也就多几百字节，我的实际项目里通常用 512 点。

索引计算要小心。电角度theta是浮点数，比如 0 到 2π。查表前先归一化到表长范围，然后转成整数索引。如果不做任何保护，浮点转整数的时候有截断误差，表边界处可能出现索引越界。我建议用下面的方式：

#define SIN_TABLE_SIZE 512 static const int16_t sin_table[SIN_TABLE_SIZE] = { /* 预先生成的正弦值 */ }; int16_t fast_sin(int32_t angle_q15) // angle_q15范围 0~32767 对应 0~2π { int32_t idx = (angle_q15 * SIN_TABLE_SIZE) >> 15; // 乘表长后右移15位 int32_t frac = (angle_q15 * SIN_TABLE_SIZE) & 0x7FFF; // 取小数部分 int16_t y0 = sin_table[idx]; int16_t y1 = sin_table[(idx + 1) & (SIN_TABLE_SIZE - 1)]; int16_t result = y0 + ((int32_t)(y1 - y0) * frac >> 15); return result; }

这段代码用了线性插值，比直接查表精度更高，而且表长取 2 的幂时，取模操作可以用&代替%，非常高效。angle_q15可以是角度累加器的直接输出，完全避开浮点角度运算。实测下来，一次带插值的查表大约在 20 到 50 个周期，比cosf快一个数量级。查表对 FOC 代码的实时性提升非常大，而且实现简单，强烈建议优先做这一步。

注意 查表法的精度在高转速下尤其重要。转速越高，电角度变化越快，如果查表分辨率不够，电流环里会出现明显的量化噪声，听感上就是电机高频啸叫。所以表长宁大勿小，512 点是最低建议，有内存余量可以用 1024 点。

5.4 预计算常量，减少重复除法

还有一个不起眼但确实有效的优化：在 Clarke 变换里，2 * 0.57735f是常量，每次中断都在算同样的乘法。同样的还有 Park 变换里的系数组合、PI 控制器里的积分系数乘以控制周期等。把这些常量在初始化时预先算好存成全局变量，中断里直接引用，能省掉一小部分浮点乘法。单看一次没啥感觉，但在 20kHz 的电流环里跑一整天，这些重复计算累积的功耗和指令周期就是实打实的。

我在优化时甚至会把这几个变换的中间变量尽量复用，避免频繁申请栈上变量。嵌入式编译器对局部变量的处理通常没问题，但在中断里调用一个大的函数，栈的使用也要控制，不能把栈顶推得太高，否则容易踩掉其他任务的栈空间。

6. 优化后的完整代码结构：硬件帮你采样，CPU 只做核心控制

优化到这里，整个电流采集代码的结构已经和初始版本完全不同了。我把优化后的代码主干贴出来，供参考。

// ========== 初始化部分 ========== void foc_current_sampling_init(void) { // 1. 配置ADC：扫描模式，通道序列为 A相、B相、C相 // 2. 配置ADC触发源：TIM1更新事件或比较事件 // 3. 配置DMA：循环模式，搬运3个数据到adc_buf // 4. 使能DMA半传输/全传输中断 } // ========== DMA中断：只做标记 ========== volatile uint8_t current_frame_ready = 0; volatile int32_t *current_data_ptr = NULL; void DMA_IRQHandler(void) { if (半传输完成) { current_frame_ready = 1; current_data_ptr = adc_buf[1]; // 上一帧数据在另一个缓冲 } else if (全传输完成) { current_frame_ready = 1; current_data_ptr = adc_buf[0]; } } // ========== 控制中断：真正的FOC计算 ========== void TIM1_UP_IRQHandler(void) { // 使用上一次DMA准备好的数据 if (current_frame_ready) { int32_t ia = current_data_ptr[0] - ia_offset; int32_t ib = current_data_ptr[1] - ib_offset; int32_t ic = 0 - ia - ib; // 三相电流和为零 int16_t sin_t = fast_sin(angle_q15); int16_t cos_t = fast_cos(angle_q15); // 定点Clarke + Park int32_t i_alpha = ia; int32_t i_beta = (ia + 2 * ib) * 0.57735f; // 实际使用定点系数 int32_t id = (i_alpha * cos_t + i_beta * sin_t) >> 15; int32_t iq = (-i_alpha * sin_t + i_beta * cos_t) >> 15; // PI调节、反Park、SVPWM... } }

这个代码结构把“数据采集”“数据就绪通知”“核心计算”完全解耦了。ADC 和 DMA 负责采数据，DMA 中断只负责设置一个标志位，真正吃 CPU 时间的只有坐标变换和 PI 运算。中断里不再有任何等待操作，所有数据都是“上一帧已经准备好了”的。

实测优化后的 20kHz 电流环中断耗时，总共大约 7 到 8 微秒（包括 PI、SVPWM），比原始代码的 25 微秒（10kHz 贵一倍频率）还要快两倍以上。CPU 占用率大幅下降，系统还余出算力跑无感观测器、速度环和上位机通信。

7. 调试过程中踩过的坑：给后来者提个醒

优化过程中最容易出问题的点往往不在“改代码”本身，而在“改完之后系统行为变了”。我把自己踩过的几个坑整理成表格，希望你不用再走一遍。

这六个问题里，最坑的是第二个。DMA 双缓冲的同步逻辑，如果没想清楚“这一帧”和“上一帧”的关系，调试起来会非常痛苦。我的经验是：先在 DMA 中断里用 GPIO 翻转做标记，用示波器同时看控制中断和 DMA 中断的时序，确认数据消费和数据生产的顺序，再开始调 FOC 参数。不要一上来就指望电机动起来，先把数据流捋顺了，后面就是顺理成章的事。

还有一个实用的小技巧：调试采样波形时，不要只看 DA 输出的电流波形，要直接读 ADC 原始值，看一下「电流采样原始数据 + 零点偏置」的散点图。如果散点的分布在噪声水平内，说明采样链路没问题；如果散点有成团、跳变、平台缺失等现象，优先查采样时刻和 DMA 同步，别先去调 PI。这个排查顺序能省下大量定位时间。

8. 写在最后：优化 FOC 电流采集代码的通用思路

这套优化流程并不局限于某一款芯片。无论你用的是 STM32、国民技术、GD32，还是其他主流 MCU，思路都是通用的：先做性能剖析定位热点，再把等待型操作从关键路径摘掉，接着用 DMA 卸载数据搬运，最后优化数学计算。每一步落地后都应该用 GPIO 翻转和示波器重新测一遍耗时，用数据确认优化有效再进入下一步。

我个人在实际操作中的体会是，嵌入式性能优化最关键的不是某个技巧，而是建立“时间预算”的意识。FOC 控制里 20kHz 的电流环意味着每个周期只有 50 微秒，你必须清楚地知道这 50 微秒里每一项操作花了多少，哪些占了预算的大头，哪些是可以通过架构设计省掉的。只要把这种意识带进项目里，不用刻意追求花哨的优化手段，代码的性能也能一步步逼近硬件的极限。

最后再分享一个我在多个项目里验证过的经验：优化完电流采集代码后，记得把电流环的中断优先级和 DMA 中断优先级放在一个合理的层级。我一般会把 DMA 数据就绪中断设为最低实时性需求，只要保证它在下一个控制周期到来前置位就行；而控制中断保持最高优先级。这样哪怕 DMA 中断有点延迟，也不会错过电流环的实时计算窗口。优先级设置得好，系统在极端负载下也不会丢帧。