裸机编程的痛点：传统前后台系统（Main+ISR）的缺陷

说实话，我刚开始做单片机开发那几年，用的就是这种前后台系统。那时候觉得挺顺手的——一个main循环里轮询，几个中断服务程序处理紧急事件，简单粗暴。但后来项目越做越大，问题就一个个冒出来了。

什么叫前后台系统？说白了就是：

• 前台：中断服务程序（ISR），处理紧急事件
• 后台：main函数里的无限循环，处理常规任务

代码结构大概长这样：

// 典型的裸机前后台系统
void main(void)
{
    // 初始化
    System_Init();
    
    while(1)
    {
        // 后台轮询
        Task_KeyScan();      // 按键扫描
        Task_LED_Update();   // LED更新
        Task_Display();      // 显示刷新
        Task_Comm_Process(); // 通信处理
    }
}

// 前台中断
void TIMER_IRQHandler(void)
{
    static uint32_t tick = 0;
    tick++;
    if(tick % 10 == 0)
    {
        g_Flag_10ms = 1;  // 设置标志位
    }
}

嗯，看着挺清晰的对吧？但实际项目中，这种结构会让你欲哭无泪。我一个个来说。

痛点一：实时性无法保证

你想想看，main循环里那么多任务，每个任务执行时间不一样。如果某个任务卡住了，后面的任务都得等着。我在一个智能家居项目里就吃过这个亏——显示刷新任务里有个延时函数，结果按键扫描被堵了50毫秒，用户按了键没反应，产品直接被投诉。

痛点二：中断服务程序过于臃肿

很多新手喜欢在ISR里写大量代码。我见过有人把整个通信协议解析都放在中断里。为什么？因为觉得这样响应快。但这是个天大的误区。

中断服务程序的原则是：快进快出。ISR里应该只做最必要的事——比如读取数据、设置标志位。复杂的处理逻辑必须放到后台去。

我曾经接手过一个项目，UART中断里做了几百行的数据处理。结果呢？中断嵌套导致系统频繁崩溃。后来我花了三天时间重构，把ISR里的逻辑全拆到后台任务里，问题才解决。

痛点三：代码复用性极差

这是前后台系统最让我头疼的问题。每个项目的代码都是"一次性"的——换个MCU，代码基本要重写。为什么？

• 硬件操作和业务逻辑混在一起
• 全局变量满天飞，模块之间互相依赖
• 没有清晰的接口定义

举个例子，你写了一个LED闪烁的函数：

// 糟糕的代码：硬件和逻辑耦合
void LED_Blink(void)
{
    // 直接操作寄存器
    GPIOA->ODR ^= (1 << 5);  // PA5翻转
    Delay_ms(500);             // 延时500ms
}

这个函数换个MCU就不能用了。如果我把硬件操作抽象出来：

// 好的做法：分层设计
void LED_Blink(void)
{
    LED_Toggle();    // 调用硬件抽象层
    Delay_ms(500);   // 延时500ms
}

// 硬件抽象层
void LED_Toggle(void)
{
    // 这里才操作具体寄存器
    // 换MCU只需要改这个函数
    HAL_GPIO_TogglePin(LED_GPIO_PORT, LED_GPIO_PIN);
}

你看，这样一拆，LED_Blink函数在任何MCU上都能用。这就是分层的好处。

痛点四：可维护性低

前后台系统的代码，三个月后你自己都看不懂。我翻过自己两年前写的代码，满屏的全局变量和标志位，函数之间互相调用，像一团乱麻。

典型的"意大利面条式代码"长这样：

// 全局变量泛滥
uint8_t g_Flag_1ms;
uint8_t g_Flag_10ms;
uint8_t g_Flag_100ms;
uint8_t g_Key_Value;
uint8_t g_LED_State;
uint16_t g_ADC_Value;
// ... 还有几十个

void main(void)
{
    while(1)
    {
        if(g_Flag_1ms)
        {
            g_Flag_1ms = 0;
            // 处理1ms任务
        }
        if(g_Flag_10ms)
        {
            g_Flag_10ms = 0;
            // 处理10ms任务
            // 这里可能修改了g_Key_Value
            // 也可能修改了g_LED_State
        }
        // ... 更多标志位判断
    }
}

这种代码，加一个新功能就像往乱麻里再塞一根线。改一个地方，可能引发连锁反应。我有个同事改了一个标志位的赋值顺序，结果整个系统的时序都乱了，排查了两天才找到原因。

痛点五：模块间耦合严重

前后台系统里，模块之间经常通过全局变量通信。比如按键模块检测到按键，直接修改LED模块的状态变量：

// 按键模块
void Key_Scan(void)
{
    if(KEY_PRESSED)
    {
        g_LED_State = !g_LED_State;  // 直接操作LED模块的变量
    }
}

// LED模块
void LED_Update(void)
{
    if(g_LED_State)
    {
        LED_On();
    }
    else
    {
        LED_Off();
    }
}

这种写法，按键模块和LED模块就耦合在一起了。如果我想把LED模块换成蜂鸣器模块，按键模块也得改。这显然不合理。

总结一下

前后台系统不是不能用，小项目、原型验证完全没问题。但一旦项目规模超过1万行代码，或者有多个开发者协作，它的缺陷就会暴露无遗。

痛点	表现	后果
实时性差	任务互相阻塞	响应延迟、用户体验差
ISR臃肿	中断里做大量处理	系统崩溃、死机
复用性差	代码和硬件耦合	换MCU就得重写
可维护性低	全局变量泛滥	改一处动全身
耦合严重	模块互相依赖	难以扩展和测试

所以，当我们开始做稍微复杂一点的项目时，就得考虑分层设计了。下一章我会讲怎么用分层架构来解决这些问题。嗯，到时候你会看到，其实解决思路并不复杂，关键是要有意识地去改变编码习惯。

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