一套固件适配百样设备：配置系统的设计哲学

1. 痛点：固件版本的“熵增”

做嵌入式开发久了，常会遇到这样的场景：产品A和产品B核心功能一样，只是IO口定义不同；或者产品C和产品D只是通信协议一个是WiFi，一个是4G，其余逻辑完全一致。

如果为每个硬件版本都维护一份独立的工程，代码仓库很快就会变成“版本地狱”。改一个通用的Bug，需要同步修改十几个工程，极易出错。

核心需求：如何用同一份二进制固件（.bin），在运行时动态适配不同的硬件环境和业务需求？

2. 解决方案：面向配置编程

我的解决方案是构建一个统一的配置层。软件不再硬编码IO口或功能模式，而是通过读取“配置”来决定行为。

2.1 核心数据结构设计

C语言的 struct 是通过内存布局描述事物的最佳工具。我们可以定义一个全局的配置结构体，囊括所有可变参数：

/* 硬件配置结构体：一切皆可配置 */
typedef struct {
  // 基础身份信息
  char base;             // 基础标志
  char communication;    // 通信模式：0-WiFi, 1-USB, 2-4G
  char id[6];            // 设备唯一ID
  char work_mode;        // 工作模式策略

  // 网络配置 (不定长数据定长化)
  char wifi_ssid[16];
  char wifi_pwd[16];
  char mqtt_addr[16];

  // IO 映射配置 (核心差异点)
  char power_port[3];    // 电源控制引脚映射
  char foot_port[3];     // 脚踏开关引脚映射
  char trim_port[3];     // 剪线电磁铁引脚映射

  // Modbus 协议参数
  char modbus_addr[3];   // 从机地址
  char modbus_baud[3];   // 波特率索引
} hw_config_t;

设计细节：注意我这里全部使用了 char 数组，这是考虑到 EEPROM 的字节对齐和序列化方便，同时也便于 Shell 并不是所有的配置都是整型。

2.2 存储与映射，消除硬编码

有了结构体，还需要把它持久化到 EEPROM 或 Flash 中。为了避免手写繁琐的 EEPROM_Write(addr, val)，我设计了一个**映射表 (Reflection-like table)**：

/* 配置描述表：建立 名字 -> 内存偏移 -> EEPROM地址 的映射 */
typedef struct {
  const char *name;      // 字符串名称，用于 Shell 命令匹配
  uint16_t addr;         // EEPROM 物理保存地址
  uint16_t offset;       // 结构体成员偏移量
  uint16_t size;         // 数据长度
} config_map_t;

#define OFFSET_OF(type, member) ((uint16_t)(unsigned long)&(((type *)0)->member))

static const config_map_t config_table[] = {
    {"comm_mode",  1,   OFFSET_OF(hw_config_t, communication), 1},
    {"dev_id",     4,   OFFSET_OF(hw_config_t, id),            6},
    {"wifi_ssid",  12,  OFFSET_OF(hw_config_t, wifi_ssid),     16},
    {"modbus_id",  120, OFFSET_OF(hw_config_t, modbus_addr),   3},
    // ... 更多配置项
};

通过这个表，我们可以实现一个通用的 Config_SetItem(name, value) 函数。无论配置项是 1 字节还是 16 字节，逻辑都是统一的。

2.3 业务层的解耦

在业务代码（如 main.c 或任务线程）中，不再出现 if (VERSION == V1) 这样的宏判断，而是变成运行时的逻辑判断：

void CommEntryTask(void const *argument) {
  // 动态读取通信模式配置
  uint8_t mode = Config_GetItem_for_int(1); // 1 对应 comm_mode

  if (mode == 0) {
     // 初始化 WiFi 栈
     wifi_init();
  } else if (mode == 1) {
     // 初始化 USB 虚拟串口
     usb_cdc_init();
  }
}

如此一来，同一个 .bin 文件，烧录进 A 设备（配置为 WiFi 版），它就是 WiFi 模块；烧录进 B 设备（配置为 USB 版），它就是数据采集卡。

3. 自动化产线与智能识别

3.1 命令行交互 (Shell)

为了方便工厂生产，不需要重新编译代码，只需通过串口连接 Shell，输入命令即可修改配置：

1
2
3

> config set wifi_ssid MyFactoryWIFI
> config set modbus_id 0x05
> config save

配合 config_change_wizard 这样的向导函数，生产工人甚至不需要懂指令，跟着提示一步步输入即可。

3.2 智能自适应 (Auto Detect)

在更高阶的应用中（如我的 AutoDetectTask），固件甚至可以自我进化。

通过采集一段时间的传感器数据（如 RPM 转速、IO 触发频率），利用简单的统计学特征或模式识别算法，自动判断当前设备是接在“平缝机”上还是“包缝机”上，从而自动切换内部的 process_pattern。

void AutoDetectTask(void const *argument) {
    // 收集数据 -> 队列满 -> 分析特征
    if (count >= SAMPLE_SIZE) {
        uint8_t detected_mode = auto_detect_process_analyze();
        if (confidence > 80%) {
             // 自动适配工作模式，无需人工干预
             CurrentConfig.work_mode = detected_mode;
        }
    }
}

4. 总结

此方案的本质：将“策略”与“机制”分离。

**机制 (Mechanism)**：如何驱动 GPIO、如何发送串口数据、如何解析 Modbus 协议。这部分是稳定的代码，编译在固件中。
**策略 (Policy)**：哪两个脚对应电源控制、使用什么波特率、设备 ID 是多少。这部分是数据，存储在 EEPROM 中。

通过这种架构，我们实现了 MCU 固件的标准化和量产化。在工业现场，这种灵活性的价值远超代码本身。

MCU之固件配置工作模式适配多种设备