1. 为什么一个电机控制固件要先聊定时器很多人第一次翻 ODrive 的源码注意力都会被 FOC 算法、电流环、编码器校准这些看起来更高级的东西吸走结果在axis.cpp、motor.cpp里绕了半天最后卡在一个最朴素的问题上这些控制逻辑到底是谁在什么时候调用的答案就藏在定时器里。ODrive 整个控制体系的心跳来自一个 8 kHz 的定时器中断也就是每 125 微秒触发一次。这个数字不是随便拍的它直接决定了电流环的带宽、PWM 的更新频率、采样和计算的时序关系。你把这一层搞明白了后面看电流环、速度环、位置环的代码就会顺很多因为你会清楚地知道这段代码是在中断里跑的那段是在主循环里跑的而这两者的时序约束完全不同。这篇是 ODrive 固件源码解析系列的第二篇专门啃定时器时基到 8 kHz 控制环这条链路。我会从时钟树怎么配、定时器怎么初始化、中断里到底干了什么、主循环和中断怎么分工这几个角度把这条链路完整拆开。适合已经看过第一篇、对 ODrive 整体架构有初步印象的读者也适合任何在做电机控制、想搞清楚控制频率到底怎么落地的嵌入式开发者。哪怕你用的不是 ODrive而是自己拿 STM32 搭的板子这套时基设计的思路照样能直接抄。需要先说明一点ODrive 的固件版本迭代比较多不同版本在定时器配置、中断优先级、控制环拆分上会有差异。我下面讲的是基于常见固件结构以 STM32F4 系列主控、TIM 定时器产生控制中断这一典型实现的解析具体到你手上的版本寄存器名、函数名可能略有出入但设计思想和时序逻辑是一致的。遇到对不上的地方按思路去对照你本地的源码即可。2. 时钟树与时基8 kHz 到底是怎么算出来的2.1 从系统时钟到定时器时钟的推导要理解 8 kHz得先搞清楚定时器的时钟源从哪来。以 STM32F405 这类主控为例外部晶振一般是 8 MHz经过 PLL 倍频后系统时钟跑到 168 MHz。定时器的时钟并不是直接等于系统时钟它挂在 APB1 或 APB2 总线上而总线时钟和定时器时钟之间还有一个倍频规则当 APB 预分频系数不为 1 时定时器时钟等于对应 APB 总线时钟的 2 倍。假设 APB1 预分频设为 4那么 APB1 总线时钟是 168/4 42 MHz而挂在 APB1 上的定时器实际时钟是 42 × 2 84 MHz。这个 84 MHz 就是我们要拿来分频的基准。很多人算时基的时候直接把系统时钟代进去结果频率差了一倍中断频率怎么调都不对这是最常见的坑之一。有了定时器时钟接下来就是两个参数预分频器PSC和自动重装载值ARR。定时器溢出频率的公式是中断频率 定时器时钟 / ((PSC 1) × (ARR 1))我们要 8 kHz定时器时钟 84 MHz那么 (PSC1)×(ARR1) 84,000,000 / 8,000 10500。这个 10500 可以有很多种拆法比如 PSC1 1、ARR1 10500或者 PSC1 10、ARR1 1050等等。选哪一组取决于你对计数精度和寄存器范围的要求。2.2 参数选择背后的取舍这里有个容易被忽略的细节ARR 的值决定了计数器的量程也间接影响你后续如果要改频率时的灵活性。如果 PSC 设得很小、ARR 设得很大那么调整 ARR 就能比较精细地改频率反过来如果 ARR 很小频率调整的步进就会很粗。ODrive 这类固件通常会把 PSC 设成一个固定值把 ARR 作为可调项方便在不同控制频率之间切换。另外还要注意 ARR 是 16 位还是 32 位。STM32 的 TIM2、TIM5 是 32 位定时器ARR 可以到 2^32而 TIM1、TIM8 等高级定时器是 16 位ARR 最大 65535。如果你算出来的 ARR1 超过 65535就必须换定时器或者调整 PSC。10500 这个值远小于 65535所以用 16 位定时器也完全够用。我实际调试时习惯把参数列成一张表方便对照和快速切换目标频率定时器时钟PSC1ARR1实际频率误差8 kHz84 MHz1105008000.0 Hz08 kHz84 MHz1010508000.0 Hz08 kHz84 MHz1001058000.0 Hz010 kHz84 MHz1840010000.0 Hz04 kHz84 MHz1210004000.0 Hz0从表里能看出来只要整除关系成立误差就是零。但现实中时钟不一定这么整比如某些配置下定时器时钟是 90 MHz那 90000000/8000 11250依然能整除。真正麻烦的是除不尽的情况这时候就要在 PSC 和 ARR 之间找一个乘积最接近目标值的组合然后接受一点点频率误差。对电流环来说几百赫兹的频率偏差通常可以接受但如果你做的是高精度位置控制最好还是把时钟配成能整除的。2.3 中断优先级与实时性考量时基配好了中断能不能准时触发、会不会被别的中断打断是另一个关键问题。ODrive 的控制中断优先级通常设得比较高因为它直接关系到电流环的稳定性。如果控制中断被 USB、UART 这类通信中断长时间抢占电流环就会出现抖动严重时甚至炸机。STM32 的 NVIC 支持抢占优先级和子优先级。控制中断一般给一个较高的抢占优先级数值较小通信类中断给较低的抢占优先级。这样即使通信中断正在处理控制中断也能把它打断保证 125 微秒的节拍不丢。但也不能把控制中断设成最高优先级就完事因为如果它里面执行时间过长会反过来阻塞其他中断导致系统响应变差。所以中断里的代码必须尽量短这也是为什么 ODrive 把很多计算放到主循环、只在中断里做最关键的采样和 PWM 更新。提示中断优先级的数值越小优先级越高。配置时先确定哪些中断绝对不能延迟控制、故障保护再给它们分配高优先级其余按重要性依次排开。3. 中断服务函数里到底跑了什么3.1 中断触发的完整链路定时器溢出后硬件会自动把中断标志位置位然后跳转到对应的中断服务函数ISR。在 ODrive 的固件里这个 ISR 通常叫TIMx_IRQHandler或者经过 HAL 封装后的回调函数。它做的事情可以概括成一条流水线读取编码器、读取电流采样、执行 FOC 计算、更新 PWM 占空比、处理故障检测。这条流水线的每一步都有严格的时序要求。比如电流采样必须在 PWM 的特定时刻进行太早采到的可能是开关噪声太晚采到的电流已经变了。编码器读取虽然相对宽松但也要保证每次控制周期都能拿到最新值。FOC 计算是纯数学运算耗时相对固定。PWM 更新则必须在下一个周期开始前完成否则这一拍的控制量就丢了。我见过不少自己写 FOC 的朋友把这一整条链路全塞进中断结果中断执行时间超过了 125 微秒系统直接卡死。正确的做法是评估每一步的耗时把能挪出去的挪到主循环中断里只保留必须在这个时刻做的部分。3.2 采样与 PWM 的时序配合这里展开讲一下采样和 PWM 的配合因为这是 8 kHz 控制环里最讲究的地方。常见的做法是让定时器工作在中心对齐模式也叫对称 PWM计数器从 0 数到 ARR 再数回 0形成一个三角波。PWM 的占空比在计数器等于 ARR波峰或 0波谷时更新而电流采样安排在波峰或波谷附近因为这时候开关管的状态最稳定采样噪声最小。中心对齐模式相比边沿对齐模式好处是 PWM 谐波分布更优、电机噪声更小代价是同样的定时器时钟下PWM 频率是边沿对齐的一半。所以如果你要 8 kHz 的控制频率用中心对齐的话定时器的溢出频率要设成 16 kHz然后在每次溢出时判断是波峰还是波谷只在其中一个时刻执行控制计算。这个细节如果没搞清楚很容易出现控制频率只有 4 kHz的问题。注意中心对齐模式下一个完整的 PWM 周期包含两次溢出中断。如果你在每次中断里都跑一遍 FOC实际控制频率就翻倍了电流环参数会全部失配。3.3 中断执行时间的实测与优化中断执行时间怎么测最土但最有效的办法是在 ISR 入口拉高一个 GPIO出口拉低用示波器看高电平持续时间。我实测过一套典型的 FOC 中断在 168 MHz 主频下采样加计算加 PWM 更新大概在 20 到 40 微秒之间占 125 微秒周期的 16% 到 32%留有余量。如果你的实现超过 80 微秒就要警惕了一旦有突发情况比如故障检测触发就可能超时。优化的方向有几个把三角函数查表化、把浮点运算改成定点、把不紧急的故障检测挪到主循环。ODrive 在早期版本里大量使用浮点后来为了性能也做了不少优化。你自己写的时候先保证功能正确再逐步优化耗时不要一上来就追求极致。4. 主循环与中断的分工设计4.1 为什么不能所有事都在中断里做新手最容易犯的错误就是觉得中断里做最实时那就把所有逻辑都放中断。这个想法在简单场景下能跑但在电机控制里会出大问题。原因有三第一中断执行时间越长越容易错过下一个中断导致控制节拍丢失第二中断里不能做阻塞操作比如等待某个标志位、延时、打印调试信息这些都会让系统卡死第三中断里访问共享数据要考虑原子性稍不注意就会出现数据竞争。ODrive 的设计思路很清晰中断负责硬实时的部分也就是必须在精确时刻完成的采样和 PWM 更新主循环负责软实时的部分比如状态机切换、通信处理、参数更新、故障恢复。这两者之间通过一组共享变量和标志位来传递数据。4.2 数据传递与原子性保护中断和主循环之间传递数据最典型的就是电流环的设定值。主循环根据速度环或位置环算出一个目标电流写到一个变量里中断读取这个变量作为电流环的输入。问题来了如果主循环正在写这个变量比如 32 位浮点需要多条指令中断突然插进来读就可能读到一个半新半旧的值。解决办法有几种。最简单的是用单字节或单字长的变量保证读写是一条指令完成的天然原子。如果数据超过一个字长就要用临界区保护在写的时候关中断写完再开。但关中断会影响实时性所以临界区要尽可能短。另一种做法是双缓冲主循环写缓冲区 A中断读缓冲区 B写完后交换指针。这样中断永远读的是完整的数据不需要关中断。ODrive 里对这类共享数据的处理比较讲究具体用哪种方式取决于数据的重要性和更新频率。你在移植或修改时一定要先搞清楚每个共享变量的读写方是谁再决定要不要保护。4.3 状态机在主循环中的调度主循环里跑的是一个状态机管理电机的各种状态空闲、校准、闭环控制、故障。状态切换不是随便切的比如从空闲切到闭环要先完成编码器校准和电流偏置校准这些校准过程需要一定时间不能放在中断里做。主循环按顺序推进这些步骤每一步完成后更新状态中断则根据当前状态决定要不要执行控制计算。这种设计的好处是状态切换的逻辑可以写得很清晰不用担心被中断打断。坏处是状态切换有一定的延迟因为要等主循环走到那一步。对大多数应用来说这个延迟可以接受。如果你需要极快的状态响应可以把关键的状态判断也放进中断但要非常小心。5. 常见问题与排查实录5.1 中断频率不对的排查思路中断频率不对是最常见的问题表现可能是电机抖动、电流环震荡、或者干脆不转。排查顺序我一般是这样先用示波器或逻辑分析仪测中断对应的 GPIO 翻转频率确认硬件层面中断有没有按预期触发。如果频率不对回去查时钟树配置重点看 APB 预分频和定时器倍频规则。如果频率对但电机还是不对再查中断里的计算逻辑。有个隐蔽的坑是有些固件在初始化时会先配一个默认频率等系统稳定后再切到目标频率。如果你只看了初始化那一段可能会以为频率是错的。所以排查时要顺着调用链把整个初始化流程走一遍别只看一个函数。5.2 中断丢失与优先级反转中断丢失的表现是控制节拍偶尔少一拍电机在高速时会有轻微异响。原因通常是中断执行时间太长或者被更高优先级的中断长时间占用。排查方法是统计中断进入次数和理论值对比。如果实际次数偏少就要找是谁占用了时间。优先级反转是另一个坑低优先级中断持有某个资源高优先级中断等这个资源结果高优先级被低优先级阻塞。解决办法是尽量不在中断里用互斥锁如果必须用要支持优先级继承。在电机控制里更好的做法是根本不让中断去抢资源所有资源在初始化阶段就分配好。5.3 常见问题速查表现象可能原因排查方法解决方向中断频率只有预期一半中心对齐模式两次溢出都执行了控制测 GPIO 翻转频率只在波峰或波谷执行电机高速时异响中断偶尔丢失统计中断次数缩短 ISR 执行时间电流环震荡控制频率与参数不匹配核对实际频率重算 PID 参数采样噪声大采样时刻不在波峰波谷示波器看采样触发点调整采样时机系统偶发卡死ISR 里有阻塞操作检查 ISR 代码移除延时和等待5.4 几个我踩过的坑第一个坑是忘了使能定时器的更新中断。定时器配好了、也开始计数了但中断就是不进查了半天发现TIM_ITConfig没调用。这种低级错误在赶进度的时候特别容易犯建议初始化函数写完后逐行核对一遍。第二个坑是中断标志位没清。STM32 的定时器中断进 ISR 后要手动清标志位如果忘了清ISR 会反复进入系统直接卡死。HAL 库一般会在回调前帮你清但如果你用的是寄存器操作就得自己清。第三个坑是共享变量没保护。我早期写的一个版本主循环更新目标电流时被中断打断导致电流环拿到一个错误值电机猛地抖一下。后来改成单字长变量加双缓冲问题就没了。这个坑不踩一次很难有深刻体会但希望你看完这篇能避开。6. 从 8 kHz 延伸出去的设计思考6.1 控制频率是不是越高越好很多人会想既然 8 kHz 能跑那提到 16 kHz、20 kHz 是不是控制效果更好理论上频率越高电流环带宽可以做得越宽动态响应越快。但实际上有几个限制第一主控算力有限频率翻倍意味着每拍的计算时间减半可能来不及算完第二PWM 频率提高会增加开关损耗发热上升第三电流采样对时序要求更苛刻采样窗口变窄噪声更容易进来。所以控制频率的选择是算力、损耗、精度三者之间的平衡。ODrive 选 8 kHz 是一个比较稳妥的折中既能保证不错的动态性能又给计算留了余量。如果你做的是低电感高速电机可能需要更高的频率如果是大功率低速电机8 kHz 甚至更低都够用。6.2 时基设计对其他模块的影响8 kHz 这个时基不只服务于电流环它还是整个系统的时间基准。比如速度环和位置环通常跑在更低的频率上通过对 8 kHz 中断计数来分频实现。故障检测的响应时间、通信的超时判断也都可以基于这个时基来算。所以时基一旦定下来整个系统的时间相关逻辑都要跟着它走。这也意味着如果你要改控制频率不能只改定时器参数还要检查所有依赖这个时基的模块。速度环的分频系数、故障检测的计数阈值、通信超时的时间换算都得同步更新。漏改一个就可能出现电流环正常但速度环抽风的怪现象。6.3 移植到其他主控时的注意事项如果你想把 ODrive 的这套时基设计移植到别的主控比如国产的 GD32 或者别的 Cortex-M 芯片核心思路是一样的但细节要重新核对。时钟树结构不同定时器时钟的计算方式可能不一样中断向量表不同ISR 的名字和注册方式要改HAL 库的 API 也可能有差异。我的建议是先把时钟树和定时器配置单独调通用一个 GPIO 翻转来验证频率确认无误后再往上叠控制逻辑。不要一上来就把整套代码搬过去出了问题很难定位是时基的问题还是控制逻辑的问题。分步验证是嵌入式调试最省时间的办法。最后分享一个我个人的习惯每次调定时器我都会在纸上把时钟树画一遍从晶振到系统时钟到总线时钟到定时器时钟每一步的倍频分频都标清楚然后算出 PSC 和 ARR。这张纸我会留着后面改频率或者换芯片的时候直接对照比翻代码快得多。这个笨办法帮我省了无数次排查时间你也可以试试。