宏实现配置系统：编译时配置选项，功能开关宏，模块化配置的宏设计

说实话，嵌入式开发里最让人头疼的事情之一，就是代码要适配不同硬件版本、不同功能需求。你想想看，同一个项目，可能A客户要蓝牙功能，B客户要WiFi功能，C客户两个都要。如果每次都在源码里改来改去，那维护成本就太高了。

这时候，宏配置系统就派上用场了。说白了，就是用宏在编译阶段决定“哪些代码被编译进去，哪些被扔掉”。我做了这么多年嵌入式，几乎每个项目都会用到这套思路。今天我就把压箱底的经验拿出来聊聊。

1. 功能开关宏：最简单的配置方式

功能开关宏，就是用一个宏定义来控制某段代码是否参与编译。这是最基础、也是最常用的配置手段。

// 功能开关定义
#define FEATURE_BLUETOOTH_ENABLED    1
#define FEATURE_WIFI_ENABLED         0
#define FEATURE_SENSOR_ENABLED       1

// 应用代码
void system_init(void) {
    #if FEATURE_BLUETOOTH_ENABLED
        bluetooth_init();
    #endif

    #if FEATURE_WIFI_ENABLED
        wifi_init();
    #endif

    #if FEATURE_SENSOR_ENABLED
        sensor_init();
    #endif
}

我在项目中遇到过这样的坑：有人把宏定义写成了 #define FEATURE_BLUETOOTH_ENABLED 后面没写值。结果 #if 判断时，这个宏被认为是“已定义但值为空”，编译出来的行为完全不对。嗯，这里要注意，#if 和 #ifdef 是两码事。

2. 编译时配置选项：用宏做参数化配置

除了开关功能，宏还可以用来配置参数。比如缓冲区大小、超时时间、采样频率等。这些值在编译时就确定下来，运行时不需要额外开销。

// 配置参数宏
#define CONFIG_UART_BAUDRATE        115200
#define CONFIG_TASK_STACK_SIZE      2048
#define CONFIG_SAMPLE_INTERVAL_MS   100

// 使用配置参数
void uart_init(void) {
    uart_config_t config = {
        .baudrate = CONFIG_UART_BAUDRATE,
        .data_bits = 8,
        .stop_bits = 1
    };
    uart_configure(&config);
}

void sensor_task(void *param) {
    while(1) {
        read_sensor();
        vTaskDelay(CONFIG_SAMPLE_INTERVAL_MS / portTICK_PERIOD_MS);
    }
}

我个人习惯把配置参数集中放在一个 config.h 文件里。这样改配置时，只需要改一个文件，不用满世界翻代码。你想想看，如果每个模块都自己定义配置宏，那后期维护起来得多痛苦。

3. 模块化配置的宏设计：分层与组合

当项目规模变大后，简单的开关宏就不够用了。我们需要一套模块化的配置体系。我一般会分三层：

• 平台层：定义硬件相关的宏，比如芯片型号、时钟频率
• 功能层：定义功能模块的开关，比如蓝牙、WiFi、传感器
• 参数层：定义各模块的具体参数，比如缓冲区大小、优先级

// ========== platform_config.h ==========
// 平台层：硬件相关配置
#define MCU_STM32F407
#define CPU_CLOCK_HZ        168000000
#define FLASH_SIZE_KB       1024

// ========== feature_config.h ==========
// 功能层：功能开关
#include "platform_config.h"

#define FEATURE_BLUETOOTH   1
#define FEATURE_WIFI        0
#define FEATURE_CAN_BUS     1

// ========== module_config.h ==========
// 参数层：模块参数
#include "feature_config.h"

#if FEATURE_BLUETOOTH
    #define BT_TX_BUF_SIZE      256
    #define BT_RX_BUF_SIZE      256
    #define BT_PRIORITY         5
#endif

#if FEATURE_CAN_BUS
    #define CAN_BAUDRATE        500000
    #define CAN_RX_FIFO_SIZE    64
#endif

4. 配置宏的进阶技巧：条件组合与默认值

有时候，功能之间是有依赖关系的。比如开启“高级传感器”功能，就必须同时开启“基础传感器”功能。这时候可以用条件组合宏：

// 条件组合宏
#define FEATURE_BASIC_SENSOR    1
#define FEATURE_ADV_SENSOR      1

// 自动检查依赖关系
#if FEATURE_ADV_SENSOR && !FEATURE_BASIC_SENSOR
    #error "FEATURE_ADV_SENSOR requires FEATURE_BASIC_SENSOR to be enabled"
#endif

另外，给配置宏设置默认值也是个好习惯。这样即使用户忘记定义某个宏，代码也能正常工作：

// 设置默认值
#ifndef CONFIG_TASK_STACK_SIZE
    #define CONFIG_TASK_STACK_SIZE   1024
#endif

#ifndef CONFIG_UART_BAUDRATE
    #define CONFIG_UART_BAUDRATE     9600
#endif

5. 知识体系总览

下面这张图，是我对宏配置系统核心逻辑的总结。你可以看到，从最底层的平台配置，到功能开关，再到模块参数，层层递进。每个层次都有对应的宏设计策略。

6. 实战中的配置管理

最后，分享一个我在实际项目中的做法。我会为每个产品型号创建一个独立的配置文件，比如 config_product_a.h、config_product_b.h。然后在编译脚本里通过 -include 选项指定使用哪个配置文件。

// Makefile 示例
PRODUCT ?= product_a
CFLAGS += -include config_$(PRODUCT).h

// config_product_a.h
#define FEATURE_BLUETOOTH   1
#define FEATURE_WIFI        0
#define CONFIG_TASK_STACK_SIZE  2048

// config_product_b.h
#define FEATURE_BLUETOOTH   0
#define FEATURE_WIFI        1
#define CONFIG_TASK_STACK_SIZE  4096

这样做的好处是，不同产品的配置完全隔离，互不干扰。而且新增产品时，只需要新建一个配置文件，不需要改动任何源代码。我曾经用这套方法管理过20多个产品变种，编译时只需要改一个环境变量，就能生成对应的固件。

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