📚 课程目录第4章接口隔离设计原理

4. 接口隔离设计原理

回调函数，说白了就是「你告诉我该做什么，到时候我喊你」。在嵌入式系统里，这是最常用的异步通知手段。我刚开始做嵌入式那会儿，总觉得回调函数不就是个函数指针嘛，有啥好讲的？直到有一次在电机驱动项目里，因为回调注册顺序搞反了，导致系统在中断里死循环……嗯，从那以后我再也不敢小看这个机制了。

4.1 函数指针：回调的基石

函数指针本质上就是一个地址——代码段里某条指令的入口地址。你想想看，变量指针存的是数据地址，函数指针存的是代码地址，道理是一样的。

// 定义一个函数指针类型
typedef void (*event_handler_t)(uint32_t event_id, void *param);

// 声明一个回调函数
void on_button_press(uint32_t event_id, void *param) {
    uint8_t pin_state = *(uint8_t *)param;
    if (pin_state == 0) {
        // 按键按下
    }
}

// 使用函数指针
event_handler_t handler = on_button_press;
handler(BUTTON_EVENT_PRESS, &pin_value);

我的习惯：函数指针类型定义一定要用 typedef，不然每次声明都写一遍完整的函数签名，代码又长又容易写错。我在项目里见过有人写了 5 个不同的函数指针声明，结果参数类型对不上，编译报错找了半天。

4.2 注册机制：让系统知道该找谁

注册机制解决的是「谁关心这个事件」的问题。系统维护一张回调表，外部模块通过注册接口把自己的回调函数挂上去。事件发生时，系统遍历这张表，逐个通知。

注册方式	特点	适用场景
单回调注册	一个事件只能注册一个回调	简单通知、一对一场景
多回调注册	一个事件支持多个回调	多模块监听同一事件
优先级注册	回调按优先级排序执行	实时性要求不同的场景

// 多回调注册实现示例
#define MAX_CALLBACKS 8

typedef struct {
    event_handler_t handlers[MAX_CALLBACKS];
    uint8_t count;
} event_slot_t;

static event_slot_t event_table[EVENT_MAX];

int event_register(uint32_t event_id, event_handler_t handler) {
    if (event_id >= EVENT_MAX) return -1;
    if (event_table[event_id].count >= MAX_CALLBACKS) return -2;
    
    event_table[event_id].handlers[event_table[event_id].count++] = handler;
    return 0;
}

void event_dispatch(uint32_t event_id, void *param) {
    event_slot_t *slot = &event_table[event_id];
    for (uint8_t i = 0; i < slot->count; i++) {
        slot->handlers[i](event_id, param);
    }
}

我曾经踩过的坑：在中断服务函数里直接调用回调函数，结果回调函数里有个 printf，导致系统卡死。记住：中断上下文里调用的回调，绝对不能做阻塞操作、不能拿锁、不能调用可能触发调度的函数。

4.3 异步通知模式：三种典型实现

异步通知的核心是「我不等你，你完事叫我」。嵌入式里常见的三种模式：

中断回调模式：硬件事件触发中断，ISR 里直接调用注册的回调。延迟最低，但约束最多。
任务通知模式：中断或线程把事件塞进队列，工作线程从队列取出后执行回调。延迟稍高，但更安全。
轮询回调模式：主循环里定期检查标志位，发现事件就调用回调。实现简单，适合非实时场景。

// 任务通知模式示例（基于消息队列）
typedef struct {
    uint32_t event_id;
    void *param;
    event_handler_t handler;  // 可选：携带回调
} event_msg_t;

static osMessageQueueId_t event_queue;

void async_event_post(uint32_t event_id, void *param) {
    event_msg_t msg = {
        .event_id = event_id,
        .param = param,
        .handler = NULL
    };
    osMessageQueuePut(event_queue, &msg, 0, 0);
}

void event_task(void *argument) {
    event_msg_t msg;
    while (1) {
        osMessageQueueGet(event_queue, &msg, NULL, osWaitForever);
        // 查找注册表并执行回调
        event_dispatch(msg.event_id, msg.param);
    }
}

选型建议：

中断回调：适合定时器溢出、GPIO 边沿触发等极简通知
任务通知：适合多模块、多事件的复杂系统
轮询回调：适合按键扫描、传感器数据读取等低频率场景

4.4 回调链与生命周期管理

回调注册了就得考虑什么时候注销。模块卸载、动态重配置、低功耗模式切换，这些场景下如果回调还挂在表里，系统就会调用到野指针。

// 安全注销示例
int event_unregister(uint32_t event_id, event_handler_t handler) {
    if (event_id >= EVENT_MAX) return -1;
    
    event_slot_t *slot = &event_table[event_id];
    for (uint8_t i = 0; i < slot->count; i++) {
        if (slot->handlers[i] == handler) {
            // 用最后一个覆盖当前，避免移动大量数据
            slot->handlers[i] = slot->handlers[--slot->count];
            return 0;
        }
    }
    return -1;  // 未找到
}

我的建议：每个模块在初始化时注册回调，在反初始化时注销回调。养成成对操作的习惯。我在一个 BSP 驱动框架里强制要求：register 和 unregister 必须在同一个源文件里成对出现，代码审查时重点检查。

4.5 知识结构图：回调与事件驱动核心逻辑

4.6 调试回调问题的三板斧

回调函数出问题，最难查的是「到底有没有被调用」和「谁注册了它」。我总结了三招：

打桩法：在注册接口里打印调用栈，看谁在什么时候注册了什么回调。
计数法：每个回调入口和出口各放一个计数器，看调用次数是否匹配。
超时检测：回调执行时间超过阈值就触发断言，防止回调里死循环。

// 调试辅助宏
#define CALLBACK_TRACE(fmt, ...) \
    do { \
        if (g_callback_debug) { \
            printf("[CB] %s:%d: " fmt "\r\n", __func__, __LINE__, ##__VA_ARGS__); \
        } \
    } while(0)

// 带超时检测的回调执行
void event_dispatch_safe(uint32_t event_id, void *param) {
    uint32_t start = get_tick_ms();
    event_dispatch(event_id, param);
    uint32_t elapsed = get_tick_ms() - start;
    
    if (elapsed > MAX_CALLBACK_DURATION_MS) {
        CALLBACK_TRACE("WARNING: event %d callback took %d ms", event_id, elapsed);
    }
}

特别注意：回调函数里不要调用 event_register 或 event_unregister。我在一个网络协议栈里见过这种递归注册，结果注册表被改得乱七八糟，事件分发直接跑飞。如果确实需要动态修改注册表，用延迟注册机制——先把请求放进队列，等事件分发完成后再处理。

回调函数与事件驱动，说白了就是「解耦」两个字。事件源不需要知道谁在处理，处理者不需要知道事件怎么来的。中间只靠一张注册表和一套分发机制连接。你想想看，这种设计让模块之间的依赖关系变得多清晰？每个模块只管自己的回调函数，系统整体却可以灵活组合。嗯，这就是接口隔离的魅力所在。