ODrive源码解析：从定时器时基到8kHz FOC控制环的完整链路

调了大半个月的电流环，电机转是转了，但一加载就嗡嗡叫。拿着示波器戳TIM1的更新事件，发现每次控制中断进来，间隔居然不是整齐的125μs，偶尔会跳成143μs、110μs。那一刻我才真正意识到，ODrive固件源码里从定时器时基到8kHz控制环这条链路，绝不是简简单单“配置几个寄存器”的事——时基不稳，后面所有FOC算法都是空中楼阁。

这篇是ODrive固件源码解析系列的第二篇，重点拆解从定时器时基到8kHz控制环的完整链路：TIM1怎么产生24kHz PWM载波、怎么通过TRGO事件触发ADC采样、ADC中断怎么调度电流环、以及源码里如何把24kHz硬件事件降频成8kHz控制迭代。如果你正准备把ODrive移植到自己画的板子上，或者被“控制环到底应该跑多少Hz、怎么保证定时确定性”这类问题卡住了，这篇应该能给你一份完整的参考答案。

1. 为什么电机控制需要一个“精确的心跳”

1.1 时基不光是“计时”，更是事件链的起点

很多人一提到定时器，第一反应就是“用来延时”或者“做个LED闪烁”。但在电机控制里，定时器的角色完全不是这个概念。你可以把整个FOC控制系统想象成一支乐队，定时器就是指挥手里的节拍器，PWM输出是乐手演奏的节奏，ADC采样是录音师按下录音键的时刻，而控制环计算则是每小节开头那一下重音。所有环节都必须咬死在同一个时间基准上，稍微错开几个微秒，电流波形就会长出毛刺，高速运行时会直接触发过流保护。

这种“精确的心跳”在嵌入式里有个专业叫法——时基。ODrive的整个实时控制架构，就是围绕一个高质量硬件时基搭建起来的。硬件定时器的优势在于：它完全独立于CPU，计数、比较、触发事件都不需要软件参与，一旦配置好，它就自己跑，还能在特定时刻通过硬件信号直接触发ADC采样。这意味着采样时刻的抖动可以控制在纳秒级，而不是靠软件延时那种微秒甚至毫秒级的误差。

1.2 ODrive硬件平台上时基资源怎么分配

ODrive常见的控制板以STM32F405/F407为核心，主频168MHz。这颗芯片定时器资源非常丰富：TIM1和TIM8是高级定时器，带互补PWM输出和死区插入；TIM2到TIM5是通用定时器，有编码器接口模式；TIM6和TIM7是基本定时器，常用来做DAC触发。

在ODrive固件源码里，这些资源是这样分工的：TIM1负责三相逆变器的六路互补PWM，同时兼任ADC采样触发源，是整个控制链路的“心跳”；TIM2到TIM5中的一个被配置成编码器接口模式，读取电机位置；SysTick则只做相对慢速的毫秒级时基，给HAL库的HAL_GetTick()用，比如跑状态机的超时判断、串口命令超时之类，完全不会碰控制链路的实时性。

这其实是个很重要的设计思路：不要拿SysTick这种低精度的软件时基去驱动控制环。SysTick虽然也能产生周期性中断，但它无法在硬件层面触发ADC，而且优先级通常是所有中断里最低的，随便一个串口中断都能延迟它。ODrive把高速控制链路全部交给TIM1和ADC的硬件事件链，正是为了把时间确定性做到极致。

2. 从定时器到ADC：一条完整的硬件触发链

2.1 TIM1的时基配置：24kHz载波从哪来

看ODrive源码，MotorControl初始化时会调用定时器初始化逻辑，把TIM1配置成中心对齐模式。我以常见的v3.x固件为参考，配置要点大致如下：

• 定时器时钟：168MHz（APB2预分频为1时，定时器时钟由硬件倍频到168MHz）
• 计数模式：中心对齐模式1（Center-aligned mode 1）
• PWM频率：24kHz
• PSC = 0，ARR = 3499

为什么要选中心对齐？因为中心对齐模式下，计数器先向上数到ARR再向下数回0，一个完整PWM周期耗时2 × (ARR+1)个时钟周期，产生的PWM波形左右对称。电流纹波在这种模式下是对称的，采样点放在波峰或波谷都能拿到比较“干净”的电流值。而边沿对齐模式下，锯齿波产生的电流纹波不对称，采样窗口的选择就没那么舒服。

168MHz除以24kHz等于7000个时钟周期一个PWM周期，中心对齐再除以2，所以ARR+1=3500，也就是ARR=3499。这个计算看起来简单，但实际工程里有几个坑：如果你把PSC设成1、ARR设成1749，同样能到24kHz，但计数器步进精度会下降，死区时间和占空比的分辨率都会受影响。ODrive选择PSC=0、尽量大的ARR值，目的就是保留最精细的时间分辨率。

2.2 TRGO触发ADC采样：采样时刻为什么选在PWM中心

有了24kHz的PWM时基，接下来要解决一个关键问题：什么时候采样电流最准？

先想一下电流传感器的物理场景。逆变器上下桥臂交替导通，相电流是通过低侧采样电阻或电流传感器测量的。但PWM开关切换的瞬间，电流波形上会有严重的振铃和尖峰，如果这时候去采样，读到的值根本不能用。所以采样点必须避开开关瞬态，选在电流波形最平稳的时刻。

中心对齐模式给了我们一个天然的采样窗口：计数器计数到0或ARR时，对应PWM波形的中心点，此时所有桥臂的开关状态相对稳定，电流纹波恰好处于对称点，采样值最接近这一周期的平均电流。

ODrive在源码里就是通过TIM1的TRGO（触发输出）事件去启动ADC注入组转换。具体来说是：TIM1的更新事件（或者指定比较事件）被映射为TRGO输出，ADC注入组配置该TRGO作为外部触发源。这样每个PWM周期硬件自动触发一次ADC采样，完全不需要CPU干预。采样时刻的抖动，就是定时器硬件本身的确定性，是纳秒级的。

2.3 ADC中断入口：控制环第一行代码在哪

ADC采样完成之后，转换结果放在注入组的数据寄存器里。ODrive通常会配置ADC注入转换完成中断（ADC_IT_JEOC），在中断服务程序里读取两相电流和母线电压。这意味着控制环的“第一行代码”其实是在ADC中断里执行的。

这也解释了为什么中断优先级配置极其重要：ADC中断必须是最高的实时优先级之一，任何其他中断都不能抢占它。在这个中断里，CPU要完成坐标变换、两个PI调节器、SVPWM计算，然后更新TIM1的比较寄存器，这个流程必须在下一个PWM事件来临之前全部搞定，时间预算只有125μs。

这里我要特别提一句：ODrive之所以不用DMA去搬运ADC结果，而是直接用中断读取，是因为DMA虽然能不占CPU，但它只负责“搬数据”不负责“触发算法”。控制环必须知道“这一拍的数据到了”，才能开始算。在8kHz控制率下，每125μs搬一次数据的中断开销完全可以接受，反而比DMA多一层同步机制来得更干净。

3. 8kHz控制环的频率设计逻辑

3.1 为什么是8kHz而不是24kHz

这个问题我经常在技术群里看到，很多人第一直觉是：PWM是24kHz，ADC也是24kHz触发，那控制环顺势就跑24kHz呗，理论上响应更快、延迟更低。理论上确实如此，但工程上有个重要约束——CPU预算。

我们来算一笔账。STM32F405主频168MHz，一个FOC电流环周期大概要执行多少条指令？传感器读取加坐标变换、两个PI调节器、反Park变换、SVPWM，再算上编码器位置读取和滤波，一个完整的电流环在ODrive这种C++代码里大约需要3到6μs（不同优化等级差异很大）。如果跑24kHz，周期是41.67μs，看起来CPU占用率不算爆炸，但别忘了：这个中断里还要处理速度环前馈、弱磁控制、过流保护逻辑、BISS/编码器通信，而且主循环里还在跑USB通信、CAN总线、轨迹规划这些任务。24kHz意味着所有这些东西都要在更短的周期里被挤压。

所以ODrive选择了8kHz作为电流环的默认更新率。这个频率下，控制周期125μs，留给中断的CPU执行时间裕量足够大，同时8kHz的电流环带宽对绝大多数无刷电机应用也足够了。实际电流环闭环带宽通常能做到一两千赫兹，对应的控制率至少要是带宽的4到10倍，8kHz完全满足，还能留下裕量。

3.2 源码里的分频计数：从24kHz降到8kHz

那24kHz的ADC触发和8kHz的控制环怎么衔接？答案在源码的分频计数逻辑里。

简单说，ADC每个PWM周期都采样，也就是24kHz采一次电流，但并不是每一次采样完都执行完整的FOC计算。源码里维护了一个控制迭代计数器，每次ADC中断到来就把计数器加一，计数器累加到3时清零并执行电流环。24kHz除以3，正好是8kHz。

这个设计好在哪？好处是电流采样依然保持24kHz的高频，能捕捉到更丰富的电流纹波信息；而控制环以8kHz更新，避免了不必要的计算浪费。同时，分频计数还能方便地做变速：想跑12kHz就把计数阈值设为2，想跑6kHz就设为4，改一个参数就行。ODrive固件早期版本甚至允许用户配置这个频率，后来为了稳定性和支持矩阵简化，固定成8kHz默认。

3.3 一个控制周期125μs内要完成多少活

既然控制环8kHz，那每个周期内的时间分配大致是这样：ADC中断进入、读取三路注入转换结果（两相电流加母线电压），大约10μs；读取编码器位置并通过SPI或编码器接口拿到电角度，加上滤波和速度估算，约20μs；Clarke变换加Park变换，约5μs；Id和Iq两个PI调节器各几步运算，约10μs；反Park变换加SVPWM，约10μs；写比较寄存器、检查过流标志、清除中断标志，约5μs。满打满算60到80μs，留在125μs周期内还是有余量的。

但这里有个隐形雷区：如果中断里某个模块写得拖沓，比如编码器SPI通信用了阻塞式等待，或者某个滤波算法里用了除法、浮点三角函数，执行时间很容易飙到100μs以上。一旦超过125μs，下一次ADC中断到来时上一次还没跑完，轻则控制环丢拍，重则中断重入导致死机。

ODrive的控制环代码里大量使用查表法和定点近似，比如SVPWM的基本时间计算用乘法替代三角函数，坐标变换用预先算好的正余弦值，就是为了把中断耗时压到最低。这些在实际移植时非常值得照搬。

4. 源码关键路径：从采样到SVPWM的现场还原

4.1 中断处理函数的主干

我以ODrive v3.x固件为参考，把ADC中断里的主干逻辑梳理一下。整个流程可以用下面这个骨架来理解：

void ADC_IRQHandler(void) { if (ADC_GetITStatus(ADC1, ADC_IT_JEOC)) { // 1. 读取注入组采样结果 float ia = ADC_GetInjectedConversionValue(ADC1, ADC_InjectedChannel_1); float ib = ADC_GetInjectedConversionValue(ADC1, ADC_InjectedChannel_2); float vbus = ADC_GetInjectedConversionValue(ADC1, ADC_InjectedChannel_3); // 2. 更新控制迭代计数，每3次执行一次电流环 control_iteration++; if (control_iteration >= 3) { control_iteration = 0; current_control_loop(ia, ib, vbus); } // 3. 清除中断标志 ADC_ClearITPendingBit(ADC1, ADC_IT_JEOC); } }

实际源码里current_control_loop的入参不是float而是ADC原始值，转换和标定在函数内部完成。这个细节说明一个问题：中断入口要尽可能轻，复杂的数学计算丢到控制函数里，保持中断服务程序本身干净。

4.2 电流环的FOC计算链

进入current_control_loop之后，就是一个标准的FOC链路。很多初学者以为FOC很玄，其实每一步都是线性代数：

第一步，电流重建。硬件上通常只采两相电流（Ia、Ib），第三相用基尔霍夫定律算出来：Ic = -Ia - Ib。ODrive的板子上两个采样电阻加一个母线电压采样通道，正好对应注入组三个通道。

第二步，Clarke变换，把三相静止坐标系转到两相静止坐标系αβ：

Iα = Ia Iβ = (Ia + 2*Ib) / √3

这里注意，如果采样电阻在下桥臂，还需要根据PWM占空比对采样点做校正，否则低速大占空比时电流重建会失真。ODrive源码里对这个做了处理。

第三步，Park变换，把αβ坐标系转到dq旋转坐标系，需要当前电角度θ：

Id = Iα*cosθ + Iβ*sinθ Iq = -Iα*sinθ + Iβ*cosθ

电角度从编码器接口读取，再乘以极对数。ODrive支持增量式编码器、绝对值编码器、霍尔传感器，每种在读取延迟和滤波上略有差异，但进入电流环的都是同一个标量。

第四步，两个PI调节器。Id的给定通常为0（表贴电机）或者来自弱磁控制；Iq的给定来自速度环输出或力矩指令。PI输出是Vd和Vq。

第五步，反Park变换，得到Vα和Vβ，然后送进SVPWM模块，计算出三相桥臂的占空比比较值，写入TIM1的CCR1/CCR2/CCR3。

这一整套链路在ODrive源码里被封装成若干函数，但核心数据的流向就是这样。理解了这条链，看懂源码就只是逐行对号入座的问题。

4.3 标志位、过流保护与状态机

除了计算链路，中断里还会做几件容易被忽略的事。首先是过流保护：每次采样完电流，第一件事就是判断电流绝对值有没有超过阈值。ODrive的过流判断非常激进，直接在中断里做硬件级别的比较，一旦超限立即封锁PWM输出，同时把轴状态机置为错误状态，而不是等主循环慢慢轮询。

这就是“中断里既要算得快，又要守得住”的含义。实时控制系统里，保护逻辑不能放在低速主循环里做，必须放在最高优先级的中断里，否则一个CAN总线拥堵就可能让过流保护迟到几十微秒，上桥臂就烧了。

其次，中断里还会做速度估算的更新。速度环虽然可能以1kHz或8kHz的较低频率运行，但位置差分计算里面的时间戳必须对齐到控制周期上，不能拿主循环的毫秒时间戳去差分，否则速度抖动会让你怀疑人生。

5. 实操避坑：时基抖动与控制环稳定性

5.1 中断优先级配置不当导致的波形抖动

我在最开始提到的那个故障，最后定位到的原因是USART中断优先级设置得比ADC中断还高。每秒钟有大量日志从串口打印出去，每打印一帧数据，串口中断就抢占ADC中断，电流环的执行时刻被硬生生往后推，表现出来就是PWM占空比更新延迟，电流波形上有毛刺，电机噪音变大。

排查办法很简单：在ADC中断里翻转一个GPIO，用示波器看这个GPIO的脉冲间隔。正常应该是严格的125μs。如果看到每隔一段时间就出现一个拉长的间隔，说明有别的中断在高频抢占。解决方式是调整NVIC中断优先级分组，把ADC中断的抢占优先级设为最高，串口、USB、CAN这些通信中断全部降到它下面。

这里有个容易忽略的细节：STM32的NVIC抢占优先级和子优先级分组。如果把分组设成所有位都是子优先级，那就完全没有抢占功能了，任何中断都打断不了正在执行的中断，ADC中断的高优先级名存实亡。ODrive源码里明确设置了中断优先级分组，并在每个外设初始化时逐个配置优先级，这个习惯值得照抄。

5.2 采样时刻偏移：看不见的电流尖刺

另一个典型问题出在采样时刻上。如果你移植时把TIM1从中心对齐模式改成了边沿对齐模式，或者TRGO触发事件选错了比较通道，ADC采样点可能会落在PWM开关切换的附近。这时候采样到的电流带有振铃分量，电流环的PI调节器会把这些高频分量当真实信号去跟踪，结果就是电流纹波变大、电机发热，甚至触发误过流。

我在自己的板子上就踩过这个坑：PCB布局把采样电阻的地线走得太长，导致采样地和功率地之间有压差。示波器看电流波形，每次PWM切换时都有一串衰减振荡，恰好干扰到采样窗口。后来把采样点往PWM中心挪，又把地线加粗短接，问题才消失。

这类问题和定时器本身无关，但它恰恰说明：定时器时基决定了“什么时候采样”，而采样点的物理环境决定了“采到什么”。硬件布线和软件配置往往是一体的，不能只盯寄存器。

5.3 常见问题与排查速查表

我用一个表格把主要的常见问题整理一下，方便现场排查：

5.4 移植到自研板时基的调试顺序

最后说点个人经验。如果你想把ODrive这套时基架构移植到自己的板子上，我建议严格按照下面的顺序调试，每一步确认没问题再继续：

第一步，先把TIM1的PWM波形调出来，不接电机，只测桥臂输出，确认频率24kHz、占空比可调、死区时间符合你的MOSFET驱动需求。

第二步，接上ADC触发，但先不跑控制环。用示波器测PWM同步信号和ADC采样完成信号之间的时序关系，确认采样点落在PWM窗口的稳定区域。

第三步，手动给定一个占空比，让电机转起来（开环），确认电流采样和角度读取都正确，能画出正常的正弦反电动势波形。

第四步，再跑闭环电流环。如果电流环稳不住，先别调PI参数，回头检查时基链路是否还有抖动。

第五步，加速度环、位置环。

这个顺序帮我在两块自研板子上避免了至少一个月的无用功。如果你跳过前几步直接跑FOC，出了问题会很难分清是时基问题、采样问题还是控制算法问题。时基是地基，地基不稳，楼盖得再高都是危房。

我个人在实际操作中的体会是：ODrive这套固件最大的价值不只是“能转”，而是把定时器、ADC、中断、控制算法串成了一条逻辑极其清晰的硬件事件链。跟着这条链走一遍，比看十篇泛泛的FOC教程都有用。如果后面有时间，我再把中线电压采样、SVPWM的扇区判断细节和编码器角度补偿这块单独写一篇，那些都是真正吃时间的地方。