4、中断管理优化：中断延迟分析、中断嵌套与优先级、中断线程化、中断负载均衡

中断管理，说白了就是AMR的“应急响应系统”。

机器人跑着跑着，突然撞到障碍物，或者电机编码器丢了一个脉冲——这些紧急事件都得靠中断来通知CPU。如果中断处理不好，轻则抖动一下，重则直接翻车。我这些年调过的机器人，十有八九的性能瓶颈都跟中断有关。

4.1 中断延迟分析：到底慢在哪？

先问一个问题：从硬件拉高中断引脚，到CPU开始执行你的中断服务函数，这中间到底花了多少时间？

这个时间，就叫中断延迟。我见过最夸张的一次，延迟达到了200微秒——对电机控制来说，这已经足够让机器人跑偏好几厘米了。

中断延迟主要由三部分组成：

• 硬件延迟：CPU响应中断前的指令完成时间，通常几个时钟周期
• 上下文保存：保存当前寄存器、栈指针等，这个跟CPU架构强相关
• 中断控制器仲裁：如果有多个中断同时到达，得排队

怎么测中断延迟？我个人习惯用GPIO翻转法：

// 中断入口处拉高GPIO
void IRQ_Handler(void) {
    GPIO->BSRR = PIN_MASK;  // 置位
    // ... 实际处理 ...
    GPIO->BRR = PIN_MASK;   // 复位
}

// 用示波器看GPIO上升沿到中断源触发的时间差

嗯，这个方法虽然土，但最直观。你想想看，示波器一抓，延迟多少毫秒、微秒，一目了然。

4.2 中断嵌套与优先级：别让高优先级饿死低优先级

中断嵌套，就是高优先级中断可以打断低优先级中断。听起来很合理对吧？但实际用起来坑不少。

我曾经遇到一个案例：电机控制中断（优先级0，最高）和通信中断（优先级2）同时触发。电机中断里有个耗时操作——读取霍尔传感器并计算角度，花了30μs。这30μs里，通信中断一直被阻塞。结果呢？通信超时，上位机报错，机器人直接急停。

中断嵌套的设计原则，我总结了几条：

• 实时性要求 < 10μs：给最高优先级，比如急停、过流保护
• 实时性要求 10μs ~ 100μs：中等优先级，比如电机控制、编码器
• 实时性要求 > 100μs：低优先级，比如通信、日志
• 同优先级中断：按硬件中断号排序，别指望软件能控制顺序

这里有个小技巧：如果两个中断共享数据，记得在低优先级中断里关掉高优先级中断的使能位，防止数据竞争。我习惯用临界区保护：

void LowPrio_IRQ(void) {
    __disable_irq();  // 关全局中断
    // 访问共享数据
    shared_data++;
    __enable_irq();   // 开全局中断
}

但注意：关中断时间别超过1μs，否则高优先级中断会饿死。

4.3 中断线程化：把“急事”和“重事”分开

中断服务函数里，到底该做多少事？

我的答案是：越少越好。中断里只做最紧急的事——比如读寄存器、清标志位、存数据。剩下的“重活”——比如数据处理、协议解析、状态机切换——统统扔到线程里去做。

这就是中断线程化的核心思想：上半部（Top Half）在中断上下文执行，下半部（Bottom Half）在进程上下文执行。

在Linux RTOS里，我常用这种方式：

// 上半部：中断服务函数
static irqreturn_t motor_irq_handler(int irq, void *dev_id) {
    struct motor_dev *mdev = dev_id;
    
    // 只做最紧急的事
    mdev->raw_count = readl(mdev->regs + COUNT_REG);
    
    // 触发下半部
    tasklet_schedule(&mdev->tasklet);
    
    return IRQ_HANDLED;
}

// 下半部：tasklet或工作队列
static void motor_tasklet_handler(unsigned long data) {
    struct motor_dev *mdev = (struct motor_dev *)data;
    
    // 在这里做耗时操作：滤波、计算速度、更新状态
    mdev->filtered_count = low_pass_filter(mdev->raw_count);
    mdev->speed = calc_speed(mdev->filtered_count);
}

中断线程化的好处很明显：

• 减少中断屏蔽时间，提高系统实时性
• 下半部可以睡眠、可以加锁，编程更灵活
• CPU负载更均衡，不会因为一个中断卡死整个系统

4.4 中断负载均衡：别让一个CPU累死

多核AMR上，中断默认都跑到CPU0上。你想想看，CPU0既要处理电机控制中断，又要处理激光雷达中断，还要处理通信中断——不卡才怪。

中断负载均衡，就是把中断分散到不同的CPU核心上。在ARM GIC（通用中断控制器）里，可以通过设置中断亲和性（IRQ Affinity）来实现。

我常用的配置方法：

# 查看当前中断分配
cat /proc/interrupts

# 将电机控制中断（假设IRQ 42）绑定到CPU1
echo 2 > /proc/irq/42/smp_affinity

# 将激光雷达中断（假设IRQ 55）绑定到CPU2
echo 4 > /proc/irq/55/smp_affinity

# 将通信中断（假设IRQ 68）绑定到CPU3
echo 8 > /proc/irq/68/smp_affinity

注意：smp_affinity的值是位掩码。CPU0对应1，CPU1对应2，CPU2对应4，CPU3对应8，以此类推。

中断负载均衡的注意事项：

• 不要过度分散：中断切换也有开销，分散到太多核心反而降低性能
• 考虑缓存亲和性：如果中断处理函数频繁访问某个数据结构，最好让中断和访问该数据的线程在同一个核心上
• 动态调整：运行时可以用irqbalance守护进程自动调整，但实时性要求高的场景建议手动绑定

下面这张图展示了中断负载均衡前后的对比：

嗯，中断管理优化这块，说白了就是三个字：快、准、稳。延迟要快，优先级要准，负载要稳。把这三点做好了，AMR的性能至少能提升30%。

---

公众号:蓝海资料掘金营，微信deep3321