1. 课程导论与抽象层思想：为什么需要MCU抽象层？

各位同学好，我是这门课的主讲。今天咱们聊聊一个很基础、但又特别容易被忽视的问题——为什么你的MCU代码，换个芯片就得重写？

我见过太多团队，产品卖得不错，代码却是一团乱麻。换了个MCU型号，整个项目组就得加班三个月。说白了，就是代码和硬件绑得太死了。

从裸机开发到分层架构的演进

先回忆一下，我们最早是怎么写单片机的？

// 典型的裸机代码
void delay_ms(uint32_t ms) {
    for(uint32_t i = 0; i < ms * 1000; i++) {
        __NOP();
    }
}

void led_on(void) {
    GPIOA->BSRR = (1 << 5);  // 直接操作寄存器
}

void led_off(void) {
    GPIOA->BRR = (1 << 5);
}

这段代码，在STM32F103上跑得挺好。但换个GD32、或者换个AT32，你就得把所有GPIO地址、时钟配置全部重写。为什么？因为代码里到处都是硬件细节。

我个人习惯把这种代码叫做「硬编码式开发」。早期项目小、芯片固定，这么写没问题。但一旦产品线多了，维护成本就指数级上升。

那怎么解决？分层架构。

把代码拆成三层：

• 应用层：只关心业务逻辑，比如“每隔1秒翻转LED”
• 抽象层：定义统一的接口，比如 led_toggle()
• 硬件驱动层：实现具体的寄存器操作

这样，应用层根本不关心底层是STM32还是GD32。它只知道调用 led_toggle() 就行。

为什么需要MCU抽象层？

说白了，抽象层就是给上层软件一个「统一的接口」，把硬件的差异藏起来。

我在项目中遇到过这么一件事：有个产品用了NXP的LPC系列，后来因为成本原因要换成国产的AT32。如果没有抽象层，那几乎每个驱动文件都得改。但如果我们提前定义好了抽象层接口，比如：

// 抽象层接口定义
typedef struct {
    void (*init)(void);
    void (*set)(uint8_t state);
    uint8_t (*get)(void);
} gpio_t;

// 应用层使用
gpio_t led;
led.init = stm32_gpio_init;   // 或者 gd32_gpio_init
led.set(1);                    // 统一调用

换芯片时，只需要换掉底层的 stm32_gpio_init 实现，应用层一行代码都不用动。

课程目标与学习路径

这门课的目标很明确：让你掌握一套可复用的MCU抽象层设计方法，能快速适配不同芯片平台。

具体来说，你会学到：

模块	内容	实战产出
基础篇	抽象层设计思想、接口定义规范	GPIO/UART抽象层框架
进阶篇	定时器、中断、DMA的跨平台封装	多平台驱动库
实战篇	从STM32移植到GD32/AT32全流程	完整移植报告
调试篇	抽象层调试技巧、断言与日志系统	调试工具链

学习路径我建议这样走：

1. 先理解思想：别急着写代码，把分层架构的「为什么」想清楚
2. 动手搭框架：从一个简单的GPIO抽象层开始，跑通一个LED
3. 逐步扩展：加入UART、定时器、中断
4. 实战移植：找两块不同厂家的开发板，实际移植一次

知识体系总览

下面这张图，概括了本章的核心逻辑：

嗯，这张图把整个课程的核心逻辑串起来了。从问题出发，到解决方案，再到三层结构，最后落到收益。你每次觉得“抽象层没用”的时候，就回来看一眼这张图。

写在前面的话

这门课不会讲太多花哨的理论。我会把我在多个项目里踩过的坑、总结出的套路，直接拿出来分享。

你可能会问：“我平时就做一个小产品，有必要学这个吗？”

我的回答是：有必要。因为代码的复用性，不是等到项目大了才考虑的。从第一个LED开始，就养成封装的习惯。后面你会发现，这比后期重构要省心得多。

好了，第一章就到这里。记住一句话：抽象层不是银弹，但它能让你少掉一半头发。