每次换芯片就重写驱动，这日子什么时候是个头？
一、又双叒叕换芯片了
最近老朋友李工有点上火。
作为干了十二年嵌入式的“老炮儿”，他带的项目不下二十个，从 51 单片机到 ARM Cortex-M，从裸机到 RTOS，什么场面没见过。但这次，他栽在了“换芯片”这件事上。
事情是这样的：公司有个成熟的温控器产品，用的是 STM32F103。代码写得挺顺溜，跑了三年没啥大毛病。结果今年芯片涨价，老板一拍桌子：“换国产芯片！GD32，价格便宜一半！”
李工心想，GD32 不是号称“兼容 STM32”吗？应该改改引脚配置就完事了吧。
结果一上手才发现——驱动代码里 STM32 的库函数调用满天飞。
// 到处都是这样的代码
void UART_SendByte(uint8_t data)
{
while (USART_GetFlagStatus(USART1, USART_FLAG_TXE) == RESET);
USART_SendData(USART1, data);
}
void LED_On(void)
{
GPIO_SetBits(GPIOA, GPIO_Pin_5);
}
void Delay_ms(uint32_t ms)
{
// 用的 SysTick，但初始化代码和 STM32 库绑死了
}
GD32 虽然“大体兼容”，但库函数名不一样，寄存器有些细节也不同。李工估算了一下：光改驱动层，至少要动 30 个文件，上千行代码。
更扎心的是，隔壁组的小王，之前做过一个几乎一样的温控器项目，用的是 NXP 的芯片。两个项目的业务逻辑 80% 相同——温度采集、PID 计算、LCD 显示、Flash 存储——但代码一行都没法复用。
李工叹了口气：“咱们写了这么多年代码，怎么每次换个芯片就像从头开始？”
二、代码复用的三大拦路虎
李工的遭遇不是个例。干嵌入式的，谁没被“代码复用”这事折腾过？仔细想想，阻碍我们复用代码的，无非就这三个坎儿：
拦路虎 1：硬件平台绑定
这是最常见的问题。代码里直接调用厂商库、直接操作寄存器，换个芯片就得大改。
┌─────────────────────────────────────────────────────────────────┐
│ 硬件绑定的代码结构 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌───────────────────────────────────────┐ │
│ │ 应用层（业务逻辑） │ │
│ │ 温度控制、PID算法、参数管理 │ │
│ └──────────────────┬────────────────────┘ │
│ │ 直接调用 │
│ ▼ │
│ ┌───────────────────────────────────────┐ │
│ │ STM32 HAL 库 │ ← 换芯片？全改！ │
│ │ USART_SendData、GPIO_SetBits... │ │
│ └──────────────────┬────────────────────┘ │
│ │ │
│ ▼ │
│ ┌───────────────────────────────────────┐ │
│ │ 硬件寄存器 │ │
│ └───────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
问题根源： 应用层直接“认识”底层硬件，两者之间没有缓冲层。
拦路虎 2：功能代码不内聚
很多时候，同一个 .c 文件里，既有业务逻辑，又有硬件操作，还夹杂着通信协议处理。你想复用其中一部分？对不起，牵一发动全身。
// 这种代码你见过没？（别装没见过，我们都写过）
void Task_Main(void)
{
// 读传感器（硬件相关）
uint16_t adc_val = ADC_GetValue(ADC1, ADC_Channel_1);
// 数据处理（业务逻辑）
float temp = adc_val * 3.3 / 4096 * 100;
// 显示（又是硬件相关）
LCD_ShowFloat(0, 0, temp);
// 通信（协议处理）
uart_buf[0] = 0xAA;
uart_buf[1] = (uint8_t)temp;
USART_SendBytes(uart_buf, 2);
}
四种职责混在一个函数里，你说怎么复用？这不仅是复用的问题，更是软件设计原则的问题。
拦路虎 3：接口不统一
就算你把功能拆分得很好，但不同项目的接口风格不一样，想复用还是头疼。
A 项目的串口驱动：UART_Send(uint8_t *data, uint16_t len)
B 项目的串口驱动：Serial_Write(char *buf, int size)
C 项目的串口驱动：COM_Transmit(void *pData, uint32_t length)
功能一样，名字不一样，参数类型不一样。你说气人不气人？这本质上是对“接口”这一计算机基础概念缺乏统一规划的结果。
三、破局之道：分层 + 抽象
问题找到了，解决思路也就清晰了——分层隔离，接口抽象。
这不是什么高深的理论，说白了就是：让不该认识的模块别认识，让该统一的接口统一起来。
3.1 代码复用的三个层次
┌─────────────────────────────────────────────────────────────────┐
│ 代码复用的三个层次 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 层次1：函数级复用 —— 最基础 │
│ ─────────────────────────────────────── │
│ 把常用的计算、数据处理封装成函数 │
│ 例如：CRC校验、滤波算法、字符串处理 │
│ 特点：不依赖硬件，随便哪个项目都能用 │
│ │
│ ──────────────────────────────────────────────────────────────│
│ │
│ 层次2：模块级复用 —— 进阶 │
│ ─────────────────────────────────────── │
│ 把一组相关功能打包成模块，对外暴露统一接口 │
│ 例如：通信协议栈、参数管理器、状态机引擎 │
│ 特点：内部高内聚，对外低耦合 │
│ │
│ ───────────────────────────────────────────────────────────── │
│ │
│ 层次3：接口级复用 —— 最高境界 │
│ ─────────────────────────────────────── │
│ 定义抽象接口，底层实现可替换 │
│ 例如：HAL层、设备驱动框架 │
│ 特点：换硬件只改适配层，业务代码一行不动 │
│ │
└───────────────────────────────────────────────────────────────┘
3.2 分层架构：嵌入式复用的基石
李工一咬牙一跺脚，决定重构代码架构。他画了这样一张图：
┌─────────────────────────────────────────────────────────────────┐
│ 分层架构示意图 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ╔═══════════════════════════════════════════════════════════╗ │
│ ║ 应用层 (Application) ║ │
│ ║ PID控制、业务流程、参数管理 ║ │
│ ║ 【可复用：100%】 ║ │
│ ╚════════════════════════════╤══════════════════════════════╝ │
│ │ 调用抽象接口 │
│ ▼ │
│ ╔═══════════════════════════════════════════════════════════╗ │
│ ║ 服务层 (Service/BSP) ║ │
│ ║ LED服务,温度采集服务, 显示服务 ║ │
│ ║ 【可复用：80%】 ║ │
│ ╚════════════════════════════╤══════════════════════════════╝ │
│ │ 调用HAL接口 │
│ ▼ │
│ ╔═══════════════════════════════════════════════════════════╗ │
│ ║ 硬件抽象层 (HAL） ║ │
│ ║ 统一的 GPIO/UART/ADC/Timer 接口 ║ │
│ ║ 【接口固定，实现可换】 ║ │
│ ╚════════════════════════════╤══════════════════════════════╝ │
│ │ │
│ ▼ │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ 驱动层 (Driver) │ │
│ │ STM32实现 │ GD32实现 │ NXP实现 │ ... │ │
│ │ 【换芯片只改这层】 │ │
│ └───────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
核心思想：
- 应用层只认识抽象接口，不认识具体硬件
- 换芯片时，只需要替换驱动层的实现
- 业务代码一行不改，直接跑
这不是空话，我们来看看具体怎么做。
四、实战：设计一个可复用的串口模块
光说不练假把式。我们以串口驱动为例，看看怎么实现换芯片不改业务代码。
4.1 第一步：定义抽象接口
先定义一个“串口应该长什么样”。不管是 STM32 还是 GD32，对上层来说，串口就该有这些能力：
/* hal_uart.h —— 抽象接口定义 */
#ifndef HAL_UART_H
#define HAL_UART_H
#include <stdint.h>
/* 串口句柄（具体内容对上层透明） */
typedef void* UART_Handle_t;
/* 统一的串口接口 */
void HAL_UART_Init(UART_Handle_t handle, uint32_t baudrate);
void HAL_UART_SendByte(UART_Handle_t handle, uint8_t data);
void HAL_UART_SendBytes(UART_Handle_t handle, uint8_t *data, uint16_t len);
uint8_t HAL_UART_RecvByte(UART_Handle_t handle);
uint16_t HAL_UART_RecvBytes(UART_Handle_t handle, uint8_t *buf, uint16_t max_len);
#endif
注意看这个头文件——没有任何具体芯片的影子。它定义的是“契约”，而不是实现。
4.2 第二步：针对不同芯片实现接口
接下来，为每种芯片写一个实现文件：
/* hal_uart_stm32.c —— STM32 的实现 */
#include "hal_uart.h"
#include "stm32f1xx_hal.h" /* STM32 HAL 库 */
void HAL_UART_Init(UART_Handle_t handle, uint32_t baudrate) {
UART_HandleTypeDef *huart = (UART_HandleTypeDef *)handle;
huart->Init.BaudRate = baudrate;
huart->Init.WordLength = UART_WORDLENGTH_8B;
huart->Init.StopBits = UART_STOPBITS_1;
HAL_UART_Init_Internal(huart); /* 调用 STM32 HAL */
}
void HAL_UART_SendByte(UART_Handle_t handle, uint8_t data) {
UART_HandleTypeDef *huart = (UART_HandleTypeDef *)handle;
HAL_UART_Transmit(huart, &data, 1, 100);
}
/* ... 其他函数类似 ... */
/* hal_uart_gd32.c —— GD32 的实现 */
#include "hal_uart.h"
#include "gd32f10x_usart.h" /* GD32 库 */
void HAL_UART_Init(UART_Handle_t handle, uint32_t baudrate) {
uint32_t usart = (uint32_t)handle;
usart_baudrate_set(usart, baudrate);
usart_word_length_set(usart, USART_WL_8BIT);
usart_enable(usart);
}
void HAL_UART_SendByte(UART_Handle_t handle, uint8_t data) {
uint32_t usart = (uint32_t)handle;
usart_data_transmit(usart, data);
while (RESET == usart_flag_get(usart, USART_FLAG_TBE));
}
/* ... 其他函数类似 ... */
4.3 第三步：业务代码只认接口
现在，上层代码这样写：
/* app_comm.c —— 业务层通信模块 */
#include "hal_uart.h"
static UART_Handle_t g_debug_uart;
void App_Comm_Init(UART_Handle_t uart) {
g_debug_uart = uart;
HAL_UART_Init(g_debug_uart, 115200);
}
void App_Comm_SendLog(const char *msg) {
while (*msg) {
HAL_UART_SendByte(g_debug_uart, *msg++);
}
}
这段业务代码里，没有任何 stm32、gd32 的字眼。 换芯片时，只需要：
- 编译时链接不同的
hal_uart_xxx.c
app_comm.c一行不改
┌─────────────────────────────────────────────────────────────────┐
│ 换芯片的工作量对比 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 【重构前】换 STM32 → GD32 │
│ ───────────────────────────── │
│ · 修改 30+ 个业务文件 │
│ · 全局搜索替换函数名 │
│ · 逐个测试，祈祷没漏改 |
│ · 工作量：3~5 天 │
│ │
│ ────────────────────────────────────────────────────────────── │
│ │
│ 【重构后】换 STM32 → GD32 │
│ ───────────────────────────── │
│ · 新建 hal_uart_gd32.c（或从库里复制） │
│ · 修改编译配置，链接新的驱动文件 │
│ · 业务代码：0 修改 │
│ · 工作量：半天 │
│ │
└─────────────────────────────────────────────────────────────────┘
五、老鸟的避坑清单
重构完架构，李工总结了几条血泪教训：
坑 1：过度抽象
有些年轻人学了设计模式，恨不得把每个函数都抽象三层。
记住：抽象是有成本的——多一层调用就多一点性能开销，多一个文件就多一点维护负担。
原则：只在真正需要替换的地方做抽象。GPIO 点个灯，不需要抽象；串口通信，值得抽象。
坑 2：接口定义朝令夕改
接口一旦定下来，就尽量别改。每改一次，所有的实现文件都得跟着改。
建议：设计接口时多想想未来的扩展性。比如 UART_Init() 的参数，与其只传波特率，不如传一个配置结构体，以后加参数不用改函数签名。这在C/C++开发中是常见的良好实践。
坑 3：忘了造轮子前先找轮子
在自己动手封装之前，先看看有没有现成的：
- ARM CMSIS：提供了标准的外设接口定义
- Zephyr / RT-Thread：成熟的 RTOS，自带 HAL 层
- 厂商的 LL 库：比 HAL 库更底层，但更容易跨平台封装
站在巨人的肩膀上，比自己从头撸要靠谱得多。你也可以在云栈社区这样的开发者社区里，找到许多同行分享的宝贵经验和现成轮子。
六、写在最后
代码复用这事，说难也难，说简单也简单。
难在思维转变——从“能跑就行”到“以后好改”，需要多迈一步。
简单在方法论——分层、抽象、统一接口，翻来覆去就这几招。
李工后来把这套方法推广到整个团队。半年后，公司的产品线从 STM32 扩展到了 GD32、AT32、APM32，业务代码的复用率达到了 85% 以上。
他跟我说：“以前觉得嵌入式就是和硬件死磕，现在才明白，好的架构才是真正的效率放大器。”
代码是写给人看的，顺便让机器执行。
而可复用的代码，是写给未来的自己和队友看的。
发表于 9 小时前
|
查看: 3|
回复: 0
