从C宏到现代C++：LED驱动的优化实践

1. 从C宏到现代C++：LED驱动的进化之路

在嵌入式开发领域，LED驱动常被视为最简单的入门练习。但正是这种看似简单的模块，最能体现编程思想的演进。我见过太多STM32项目，LED控制代码充斥着#define和条件编译，虽然功能正常，却像用石器时代的工具完成精密仪器组装——能跑，但绝不优雅。

十年前我刚接触STM32时，教程里清一色是这样的代码：

c复制#define LED1_ON()  HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_SET)
#define LED1_OFF() HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_RESET)

这种写法的问题在于：当你的系统有20个LED，每个LED需要支持PWM调光、闪烁模式、状态查询时，宏定义的维护成本会呈指数级增长。更糟的是，当硬件引脚变更时，你需要在数十个宏定义中手动修改，极易出错。

2. 传统C宏方案的三大硬伤

2.1 类型安全的彻底缺失

宏只是简单的文本替换，编译器不会检查参数类型。假设你误写了LED1_ON(123)，编译器不会报错，但运行时必然出错。我曾调试过一个夜间突然失效的LED指示灯，最终发现是有人误传了浮点数参数导致宏展开异常。

2.2 调试地狱

当你在Keil或IAR中单步调试时，宏展开后的代码与实际编写差异巨大。某次我遇到一个LED状态异常的问题，在调试器中看到的调用栈全是HAL_GPIO_WritePin，根本无法快速定位是哪个LED操作出了问题。

2.3 扩展性灾难

尝试用宏实现LED状态自动同步：

c复制#define LED1_SET(state) \
    do { \
        HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, (state)); \
        g_led1_state = (state); \
    } while(0)

这种写法不仅丑陋，而且当需要添加日志功能时，又得修改所有宏定义。在真实项目中，这种代码会迅速腐化成难以维护的"屎山"。

3. 现代C++的降维打击方案

3.1 基于类的封装

我们用C++11重构LED驱动，首先定