裸机编程的痛点：全局变量满天飞、模块耦合严重
说实话，我见过太多工程师在裸机项目里「翻车」了。我自己刚入行那会儿，也踩过同样的坑。你想想看，一个简单的温控项目，刚开始就几个全局变量，跑得挺欢。等加了按键、LCD显示、报警、通信……好家伙，代码直接变成一团乱麻。
这一章，我就带你看看裸机编程最典型的三个痛点。都是我在项目里真实遇到过的，希望能帮你少走弯路。
痛点一：全局变量满天飞
先看一个典型的「反面教材」——一个温控系统的核心代码片段：
// global.h —— 全局变量集中营
uint8_t g_sys_mode; // 系统模式
uint16_t g_temp_current; // 当前温度
uint16_t g_temp_target; // 目标温度
uint8_t g_heater_status; // 加热器状态
uint8_t g_fan_status; // 风扇状态
uint16_t g_alarm_threshold; // 报警阈值
uint8_t g_key_value; // 按键值
uint8_t g_lcd_buffer[32]; // LCD显示缓冲区
uint8_t g_uart_rx_buf[64]; // 串口接收缓冲区
uint8_t g_uart_tx_buf[64]; // 串口发送缓冲区
uint8_t g_tick_1ms; // 1ms时基
uint8_t g_tick_10ms; // 10ms时基
uint8_t g_tick_100ms; // 100ms时基
uint8_t g_tick_1s; // 1秒时基
// …… 后面还有30多个全局变量看着眼熟吗？我早期做的一个项目，全局变量比这还多一倍。当时觉得「方便啊，哪里都能用」。结果呢？
全局变量的三大「罪状」：
- 谁都能改，谁都不负责 —— 任何一个函数都能修改
g_temp_current，出问题了根本查不到是谁改的。 - 依赖关系隐式化 —— 模块A改了
g_sys_mode，模块B依赖这个变量做判断，但代码里没有任何「依赖声明」。你删掉一个变量，可能崩掉五个模块。 - 可读性极差 —— 新人接手项目，光看这几十个全局变量就头大。更别说理清它们之间的「隐形关联」了。
我的经验：后来我给自己定了个规矩——全局变量数量不超过10个。超过这个数，就必须用结构体封装，或者考虑分层设计。这个习惯帮我避免了很多后期调试的噩梦。
痛点二：模块耦合严重
全局变量只是表象，真正的病根在于模块之间没有清晰的边界。我画了一张图，你看看典型的裸机项目是怎么「缠」在一起的：
你看这张图，每个模块都直接操作全局变量，模块之间还有「偷偷摸摸」的交叉调用。这种代码，改一个地方，就像推倒多米诺骨牌——
我曾经遇到过一个真实案例：一个智能家居项目，产品已经量产了。客户要求增加一个「夜间静音模式」——风扇在晚上降低转速。我心想，小改动嘛，就在 heat.c 里加了个判断，根据 g_sys_mode 调整 PWM 占空比。
结果呢？测试发现，LCD 背光也跟着变暗了！查了两天才发现——lcd.c 里有个函数，居然也偷偷读了 g_sys_mode 来做背光控制。我改了一个变量，影响了两个完全不相关的模块。这就是典型的「牵一发而动全身」。
痛点三：修改一个功能导致多处崩溃
这个问题，说白了就是没有「隔离层」。我整理了一个表格，对比一下「有分层」和「没分层」的区别：
| 场景 | 裸机直接耦合 | 分层封装后 |
|---|---|---|
| 更换LCD驱动芯片 | 需要修改所有调用LCD的函数，至少涉及5个文件 | 只修改 lcd_driver.c 一个文件，接口不变 |
| 修改温度采集方式 | 从NTC换成DS18B20，要改 temp.c、control.c、alarm.c |
只改 temp_driver.c，上层完全无感知 |
| 增加通信协议 | 在 main.c 里加 if-else，还要改全局变量定义 |
新增一个 protocol_modbus.c，注册接口即可 |
| 调试某个模块 | 必须跑整个系统，无法单独测试 | 可以写测试桩，单独验证每个模块 |
我再说个具体的例子。之前做一个数据采集器，用的是一块12864的LCD。后来客户要求换成OLED屏，驱动芯片从ST7920换成了SSD1306。你猜怎么着？
因为所有显示相关的代码都散落在各个模块里——main.c 里直接写 LCD_Clear()，menu.c 里直接调 LCD_ShowString()，data.c 里直接操作 g_lcd_buffer……
换屏那天，我改了整整8个文件，改了3天，还引入了两个新bug。后来我反思——如果当初把LCD操作封装成一个独立的驱动层，提供一个统一的接口，比如 lcd_display_text()、lcd_draw_pixel()，那么换屏只需要重写底层驱动，上层代码一行都不用动。
核心结论：
- 全局变量不是不能用，但要有「访问权限」的概念——能用结构体就别用散装变量，能用局部就别用全局。
- 模块之间必须「解耦」——通过接口通信，而不是直接读写对方的变量。
- 分层是解决耦合的「银弹」——驱动层、中间层、应用层各司其职，改一层不影响其他层。
嗯，这三个痛点，说白了就是「图省事」埋下的坑。你可能会想：「项目小，没必要搞那么复杂吧？」
我当年也这么想。直到项目从300行膨胀到3000行，从一个人开发变成三个人维护……那时候再重构，成本已经高得吓人了。