ODrive 的固件源码里最容易被忽略、但又最不该被忽略的一块就是它的时基系统。很多人第一次翻源码注意力全被 FOC 算法、电流环、编码器校准这些明星模块吸走了结果看到Axis::run_control_loop()里那一堆if (count % ...)就懵了——为什么控制环是 8 kHz为什么不是 10 kHz 或者 20 kHz这个 8 kHz 到底是从哪个定时器、哪个分频系数、哪个中断里长出来的我当初也是带着这个疑问一路从main.cpp追到TIM8的初始化中间踩了不少想当然的坑。这篇就把这条链路完整拆一遍从时钟树到定时器配置再到中断里怎么把 8 kHz 的节拍分发给电流环、位置环和 PWM 更新尽量把每一步的为什么讲清楚。适合已经能编译 ODrive 固件、想深入理解实时控制时基设计的嵌入式开发者也适合做电机控制、想把控制频率这件事从玄学变成工程的人。1. 为什么 ODrive 把控制环钉在 8 kHz 这个数字上1.1 8 kHz 不是拍脑袋定的它和 PWM 频率是绑定关系先把结论摆出来ODrive 的 8 kHz 控制环本质上是PWM 开关频率 24 kHz 的三分之一。这个三分之一不是随便取的而是由中心对齐 PWM 每周期采样一次电流这套经典组合推出来的。在电机控制里电流环的采样时刻必须和 PWM 的载波对齐否则采样到的电流里会混进开关噪声。ODrive 用的是中心对齐center-alignedPWM计数器从 0 涨到 ARR 再降回 0一个完整周期里电流在波峰和波谷各稳定一次。理论上你可以在每个波峰和波谷都采一次那就是 2 倍 PWM 频率也可以只在波峰采那就是 1 倍。ODrive 选的是在波峰采样、并且把控制环频率设成 PWM 的 1/3这样每个控制周期里 PWM 正好走完 3 个完整周期采样点始终落在同一个相位上电流纹波的相位是固定的PI 调节器的相位裕度就好算。如果你把控制环设成 24 kHz和 PWM 同频采样点会一直在波峰附近抖动电流环的噪声会明显变大设成 12 kHz 也能跑但 ODrive 官方在文档里明确说过 8 kHz 是性能和 CPU 占用的平衡点。我实测过把CURRENT_MEASURE_PERIOD相关的宏改大改小8 kHz 确实是最稳的再往上 CPU 负载会吃掉太多再往下电流环带宽就不够用了。1.2 从 8 kHz 反推一个控制周期里到底发生了什么8 kHz 意味着每个控制周期是 125 微秒。这 125 微秒里ODrive 要干完这些事读取三相电流采样值ADC 已经由定时器触发采好了这里只是搬运读取编码器位置SPI 或 ABZ取决于编码器类型跑电流环 PI算出 Vd、Vq跑位置环/速度环这两个不是每个周期都跑后面会讲做反 Park 变换算出三相占空比把占空比写进定时器的 CCR 寄存器125 微秒对 STM32F405ODrive 用的主控来说168 MHz 主频大概 21000 个时钟周期。听起来很多但电流环里涉及浮点运算、三角函数反 Park 要用 sin/cos如果不用查表或者 CORDIC光算三角函数就能吃掉一大半。所以 ODrive 在时基设计上做了很多省时间的取舍这些取舍直接决定了它的定时器配置方式。提示如果你自己写电机控制固件别一上来就追求 20 kHz 控制环。先把 8 kHz 跑稳把电流采样和 PWM 的相位对齐做对比盲目提高频率有用得多。1.3 定时器时基在整个固件里的位置ODrive 固件里其实有不止一个时间源容易混淆我列一下时间源用途频率/精度TIM8高级定时器产生 PWM 触发 ADC 触发控制环中断24 kHz PWM8 kHz 中断SysTick系统滴答给 HAL 库做延时、超时1 kHzTIM2/TIM5通用定时器做编码器接口或辅助计时视配置而定DWT数据观察点做微秒级性能测量CPU 周期级真正驱动控制环的是 TIM8不是 SysTick。SysTick 只负责慢速的事情比如通信超时、状态机轮询。很多人第一次看源码会以为控制环挂在 SysTick 上那是完全跑不动的——SysTick 默认 1 kHz连电流环的边都摸不到。2. 从时钟树一路追到 TIM8 的寄存器配置2.1 先搞清楚 TIM8 挂在哪条总线上、时钟是多少STM32F405 的时钟树里TIM8 挂在 APB2 总线上。ODrive 的SystemClock_Config()里把系统时钟配到 168 MHzAPB2 预分频器设成 2所以 APB2 的时钟是 84 MHz。但这里有个 STM32 的坑当 APB 预分频系数不为 1 时定时器的时钟会自动倍频。也就是说TIM8 的实际计数时钟不是 84 MHz而是168 MHz。这个倍频规则写在参考手册的时钟树章节里但很多人配定时器的时候会忘掉导致算出来的 PWM 频率差一倍。我第一次算的时候就是按 84 MHz 算的结果示波器一测PWM 频率只有 12 kHz排查了半天才发现是倍频没算进去。所以 TIM8 的输入时钟是 168 MHz这是后面所有分频计算的基准。2.2 中心对齐模式下ARR 和 PWM 频率的关系ODrive 要的是 24 kHz 中心对齐 PWM。中心对齐模式下计数器先向上数到 ARR再向下数回 0一个完整周期是2 * ARR个计数。所以PWM 频率 TIM8_CLK / (2 * ARR * (PSC 1))ODrive 里 PSC 设成 0不分频那么24000 168000000 / (2 * ARR) ARR 168000000 / (2 * 24000) 3500所以TIM8-ARR 3500。这个数字你在源码里能直接找到对应的是PWM_ARR或者类似的宏。我建议你自己拿计算器按一遍比死记硬背强。2.3 8 kHz 中断是怎么从 24 kHz PWM 里分出来的关键来了PWM 是 24 kHz但控制环中断是 8 kHz正好是三分之一。ODrive 的做法不是再开一个定时器而是在 TIM8 的更新中断里做计数分频。TIM8 中心对齐模式下计数器到 0 和到 ARR 都会产生更新事件如果开了对应的中断源。ODrive 只在一个方向上触发中断所以中断频率是 24 kHz。然后在中断服务函数里用一个静态计数器static uint32_t control_loop_count 0; if (control_loop_count 3) { control_loop_count 0; // 这里才真正跑控制环 axis-run_control_loop(); }这样每 3 次中断跑一次控制环24 kHz / 3 8 kHz。这个3就是 PWM 和控制环之间的分频比。注意这个分频计数器必须是静态的或者全局的不能是局部变量否则每次进中断都被重置控制环就变成 24 kHz 了。我见过有人抄代码的时候把static漏了结果电机一上电就啸叫查了两天才发现是这个问题。2.4 ADC 触发和中断触发的时序配合TIM8 不只是产生中断它还要触发 ADC 采样。ODrive 用的是 TIM8 的 TRGOTrigger Output去触发 ADC触发点选在计数器等于某个比较值的时候保证采样时刻正好落在电流稳定的窗口里。具体来说TIM8 的CCR4或者某个比较通道被用来做 ADC 触发源触发事件选在计数器向上计数到 CCR 时。这个时刻对应的是 PWM 波形的中间点也就是电流最稳的时候。ADC 采完之后产生转换完成中断或者用 DMA 把数据搬走控制环中断里直接读结果。这里有个时序细节ADC 采样和转换需要时间STM32F405 的 ADC 在 12 位精度下大概几微秒。如果控制环中断来得太早ADC 还没转换完读到的就是旧数据。ODrive 的做法是让 ADC 触发稍微提前于控制环中断给转换留出时间。这个提前量在源码里是通过比较值来调的不是固定的。3. 中断服务函数里那点事谁先跑、谁后跑3.1 中断优先级为什么电流环必须最高ODrive 固件里TIM8 的中断优先级是最高的数值最小。这不是随便设的因为电流环对抖动极其敏感。如果电流环中断被别的中断打断哪怕只延迟几微秒电流波形就会畸变严重的时候会触发过流保护。STM32F405 的 NVIC 支持抢占优先级和子优先级。ODrive 把 TIM8 设成抢占优先级 0最高其他中断比如 UART、USB、CAN 都设得比它低。这样即使通信中断正在处理电流环中断也能立刻抢占。我实测过把 TIM8 优先级调低电机在低速的时候会有明显的咔咔声就是电流环被延迟导致的。所以这个优先级设置千万别乱改。3.2 控制环里的分频逻辑不是所有环都跑 8 kHz虽然中断是 8 kHz但 ODrive 里的控制环是分层的电流环每个 8 kHz 周期都跑这是最内环必须最快速度环通常跑 1 kHz 左右通过count % 8来分频位置环更低可能 100 Hz 到 1 kHz看配置源码里能看到类似这样的结构if (count % current_meas_period 0) { // 电流环 } if (count % (current_meas_period * 8) 0) { // 速度环 } if (count % (current_meas_period * 80) 0) { // 位置环 }这里的current_meas_period就是那个3的倒数关系对应的周期数。这种分层设计的好处是内环跑得快保证响应外环跑得慢减少 CPU 占用而且外环的采样周期是内环的整数倍相位关系固定不会出现拍频。3.3 中断里的浮点运算和 FPU 使用STM32F405 有硬件 FPU单精度浮点。ODrive 的电流环里大量用 float编译的时候必须开-mfpufpv4-sp-fp和-mfloat-abihard否则浮点运算会走软件模拟慢几十倍。但即使有 FPU中断里也不能随便用sinf()、cosf()这种库函数因为它们内部可能有分支、查表、甚至调用慢速路径。ODrive 的做法是预先算好 sin/cos 表或者用快速近似算法。反 Park 变换需要角度角度来自编码器每个周期都在变所以要么实时算要么用查表加插值。我自己的经验是如果控制环里发现某个函数耗时异常先用 DWT 或者 GPIO 翻转法测一下别猜。ODrive 源码里就有用 GPIO 翻转做性能标记的地方示波器一挂就知道哪个环节慢。4. 实测中容易踩的时基相关坑4.1 定时器时钟倍频算错PWM 频率差一倍前面提过APB 预分频不为 1 时定时器时钟倍频。这个坑我踩过两次第一次是算 PWM 频率第二次是算死区时间。死区时间也是基于定时器时钟算的如果时钟算错死区要么太大效率低、波形畸变要么太小上下管直通炸管。正确的做法是配完时钟树之后先写个测试代码让定时器输出一个已知频率的方波用示波器或者逻辑分析仪测一下确认时钟频率和计算一致再去配 PWM 和死区。4.2 中断里做浮点除法耗时爆炸浮点除法在 FPU 上虽然比软件快但仍然比乘法慢很多。ODrive 的电流环里PI 调节器的积分项涉及除法除以采样周期如果每个周期都做一次除法累积起来很可观。优化方法是把除法提前算成乘法1/Ts预先算好中断里只做乘法。这个技巧在写任何实时控制固件时都适用。我见过有人把1.0f / 8000.0f写在中断里编译器如果没优化每次都要做一次除法白白浪费几十个周期。4.3 编码器读取和电流环的时序冲突如果编码器走 SPISPI 传输需要时间。ODrive 里编码器读取不是在电流环中断里同步做的而是用 DMA 或者异步方式中断里只读已经准备好的结果。如果强行在 8 kHz 中断里同步读 SPISPI 时钟不够快的话一个周期根本读不完控制环就会被拖慢。这个坑在换用高分辨率编码器的时候特别明显。分辨率越高SPI 要传的位数越多时间越长。解决办法要么提高 SPI 时钟要么降低编码器读取频率位置环本来就不需要 8 kHz要么用 ABZ 接口让定时器硬件解码。4.4 中断嵌套和栈溢出TIM8 中断优先级最高如果它里面调用的函数又触发了更低优先级的中断就会嵌套。嵌套层数多了栈会不够用。ODrive 的栈大小是调过的如果你自己加功能比如在中断里调用 printf千万别这么干栈很容易爆。排查栈溢出可以用填充法启动时把栈区域填成特定 pattern跑一段时间后看还有多少没被覆盖就知道峰值用量了。5. 把 8 kHz 时基迁移到自己的项目里5.1 最小可用的定时器 中断骨架如果你想在自己的 STM32 项目里复现这套 8 kHz 时基核心步骤是配时钟树确认 TIMx 的输入时钟注意倍频配定时器为中心对齐 PWM 模式算 ARR 和 PSC开更新中断在中断里做 3 分频配 ADC 用定时器 TRGO 触发采样点对齐 PWM 波峰设中断优先级为最高在分频后的中断里跑控制逻辑代码骨架大概长这样void TIM8_UP_TIM13_IRQHandler(void) { if (TIM8-SR TIM_SR_UIF) { TIM8-SR ~TIM_SR_UIF; // 清标志 static uint8_t div 0; if (div 3) { div 0; control_loop_isr(); // 8 kHz 控制环 } } }注意清标志的顺序先读 SR 再写 SR这是 STM32 的标准操作别搞反了。5.2 控制频率不是越高越好算一笔 CPU 账假设你的电流环一次执行需要 5 微秒含 ADC 读取、PI、反 Park、写 CCR那么8 kHz每周期 125 微秒占用 4%16 kHz每周期 62.5 微秒占用 8%32 kHz每周期 31.25 微秒占用 16%看起来占用不高但别忘了还有通信、状态机、编码器处理。而且中断本身有进出开销频率越高开销越大。更重要的是PWM 频率如果不变控制环频率提高并不会让电流更平滑反而可能因为采样点相位变化引入噪声。所以选控制频率的正确姿势是先定 PWM 频率受功率管和电感限制再根据每个 PWM 周期采样几次来定控制频率。ODrive 选 1/3 是一个经过验证的平衡点。5.3 用 GPIO 翻转法验证时基是否准确最后分享一个我常用的调试技巧在控制环中断的入口和出口各翻转一个 GPIO用示波器看这个 GPIO 的波形。波形的频率就是控制环频率高电平时间就是中断执行时间。这个方法比用调试器打点直观得多而且不影响实时性。如果发现频率不是 8 kHz先查分频计数器如果发现高电平时间忽长忽短说明有更高优先级的中断在抢占或者中断里有不确定的分支比如 cache miss虽然 F4 没有 cache但有 flash 等待周期。这套时基系统看起来简单但它是整个 ODrive 固件能稳定跑 8 kHz 控制环的地基。把定时器时钟、分频、中断优先级、ADC 触发这几件事理清楚后面看 FOC 算法和状态机就会顺很多。我在实际项目里迁移这套结构的时候最大的体会是先把时基跑通、用示波器验证过再去写控制逻辑否则后面出了问题你根本分不清是算法错了还是时基歪了。
