1. 课程导论与分层思想：为什么需要抽象层？从裸机开发到分层架构的演进

大家好，我是你们这门课的老朋友。咱们今天不绕弯子，直接聊一个核心问题：为什么你的MCU代码，需要分层？

我见过太多工程师，包括十年前的我自己，写代码都是“一把梭”。main函数里直接操作寄存器，GPIO、定时器、中断全揉在一起。项目小的时候还好说，一旦产品迭代、芯片换型、或者团队协作，那代码简直就成了“祖传屎山”。

这节课，我们就来拆解一下，从裸机开发到分层架构，这条路到底是怎么走过来的。

1.1 裸机开发的“甜蜜”与“苦涩”

先说说裸机开发。说白了，就是直接操作硬件寄存器。比如点亮一个LED：

// 裸机风格：直接操作寄存器
#define GPIOB_BASE      0x40010C00
#define GPIOB_CRL       *(volatile uint32_t *)(GPIOB_BASE + 0x00)
#define GPIOB_BSRR      *(volatile uint32_t *)(GPIOB_BASE + 0x10)

void led_on(void) {
    GPIOB_CRL = (GPIOB_CRL & ~0xF0000000) | 0x30000000; // PB15推挽输出
    GPIOB_BSRR = 0x8000; // 置位PB15
}

这段代码，我刚开始做项目时特别喜欢。为什么？直接、高效、没有中间商赚差价。一个函数调用，几个时钟周期，灯就亮了。对于资源极度受限的8位机，这几乎是唯一的选择。

但是，你想想看，如果项目变成这样：

• 需要把LED从PB15换到PA0
• 需要把MCU从STM32F1换到GD32F3
• 需要让另一个同事接手你的代码

会发生什么？

嗯，这里要注意。你需要在几十个文件里，找到所有操作GPIOB_CRL和GPIOB_BSRR的地方，然后一个个改。改错一个位，灯就不亮。改漏一个地方，编译报错。我曾经在一个项目中，因为芯片换型，花了整整两天时间，就为了把所有的寄存器地址重新映射一遍。那两天，我基本就是在重复“查手册-改代码-编译-报错-再查手册”的循环。

1.2 从“一把梭”到“函数封装”

为了解决上面的问题，我们很自然地想到了函数封装。把对硬件的操作，抽象成一个个API。比如：

// 第一层封装：硬件抽象
void led_init(void) {
    // 配置PB15为推挽输出
    GPIOB_CRL = (GPIOB_CRL & ~0xF0000000) | 0x30000000;
}

void led_on(void) {
    GPIOB_BSRR = 0x8000;
}

void led_off(void) {
    GPIOB_BRR = 0x8000;
}

这样一来，当你要换引脚时，只需要改led_init和led_on/off里的寄存器操作。其他地方调用led_on()的代码，一个字都不用动。

这看起来已经很好了，对吧？但问题来了：如果换的不是引脚，而是整个MCU呢？

比如从STM32F1换到GD32F3。虽然它们都是Cortex-M3内核，但GPIO的寄存器结构完全不同。STM32F1用的是CRL/CRH/BSRR/BRR，而GD32F3用的是CTLx/OMCx/OSPCx。你的led_init函数，需要完全重写。

这就引出了我们的核心问题：如何让上层的业务逻辑（比如“点亮LED”），彻底不依赖于具体的硬件实现？

1.3 分层架构的诞生：抽象层

答案就是分层。我们在硬件和业务逻辑之间，插入一个抽象层。这个抽象层，定义了一套标准的接口，上层只管调用，下层负责实现。

我个人的习惯，是把MCU驱动分为三层：

你看，APP层只跟HAL层打交道。它不知道底层是STM32还是GD32，也不知道用的是GPIO的哪个引脚。它只知道调用hal_led_on()。

这样做的好处，我总结了几点：

• 可移植性：换MCU时，只需要重写MCU驱动层，APP层和HAL接口定义完全不用动。
• 可测试性：你可以为HAL层编写Mock对象，在PC上测试APP层的逻辑，而不需要硬件。
• 可维护性：每个层的职责清晰，新人接手代码，只需要关注自己负责的那一层。

1.4 一张图看懂分层架构

说了这么多，不如一张图来得直观。下面这张图，就是我们这门课要讲的模块化分层架构的核心逻辑。

这张图，我希望你牢牢记住。它就是咱们这门课的“宪法”。所有的代码、所有的设计，都围绕这个分层结构展开。

1.5 一个简单的例子：点亮LED的分层实现

光说不练假把式。我们来看看，用分层架构，点亮一个LED的代码长什么样。

第一步：定义HAL接口

// hal_gpio.h
#ifndef _HAL_GPIO_H_
#define _HAL_GPIO_H_

#include <stdint.h>

typedef enum {
    HAL_GPIO_MODE_OUTPUT,
    HAL_GPIO_MODE_INPUT,
    HAL_GPIO_MODE_AF,
    HAL_GPIO_MODE_ANALOG
} hal_gpio_mode_t;

typedef enum {
    HAL_GPIO_PIN_RESET = 0,
    HAL_GPIO_PIN_SET = 1
} hal_gpio_pin_state_t;

void hal_gpio_init(uint8_t port, uint8_t pin, hal_gpio_mode_t mode);
void hal_gpio_write(uint8_t port, uint8_t pin, hal_gpio_pin_state_t state);
hal_gpio_pin_state_t hal_gpio_read(uint8_t port, uint8_t pin);

#endif

第二步：实现MCU驱动层（以STM32F1为例）

// mcu_gpio_stm32f1.c
#include "hal_gpio.h"
#include "stm32f10x.h"

void hal_gpio_init(uint8_t port, uint8_t pin, hal_gpio_mode_t mode) {
    GPIO_TypeDef *gpio;
    // 根据port选择GPIO组
    switch(port) {
        case 0: gpio = GPIOA; break;
        case 1: gpio = GPIOB; break;
        // ...
    }
    // 配置模式（简化版）
    if(mode == HAL_GPIO_MODE_OUTPUT) {
        gpio->CRL &= ~(0xF << (pin * 4));
        gpio->CRL |= (0x3 << (pin * 4)); // 推挽输出
    }
}

void hal_gpio_write(uint8_t port, uint8_t pin, hal_gpio_pin_state_t state) {
    GPIO_TypeDef *gpio;
    // ... 选择GPIO组
    if(state == HAL_GPIO_PIN_SET) {
        gpio->BSRR = (1 << pin);
    } else {
        gpio->BRR = (1 << pin);
    }
}

第三步：应用层调用

// app_led.c
#include "hal_gpio.h"

#define LED_PORT    1   // GPIOB
#define LED_PIN     15

void app_led_init(void) {
    hal_gpio_init(LED_PORT, LED_PIN, HAL_GPIO_MODE_OUTPUT);
}

void app_led_toggle(void) {
    static hal_gpio_pin_state_t state = HAL_GPIO_PIN_RESET;
    state = (state == HAL_GPIO_PIN_RESET) ? HAL_GPIO_PIN_SET : HAL_GPIO_PIN_RESET;
    hal_gpio_write(LED_PORT, LED_PIN, state);
}

你看，app_led.c里没有任何寄存器操作。它只用了hal_gpio_init和hal_gpio_write这两个API。如果哪天我要把LED换到PA0，只需要改app_led.c里的LED_PORT和LED_PIN宏定义。如果我要把MCU换成GD32，我只需要重写mcu_gpio_stm32f1.c，app_led.c和hal_gpio.h一个字都不用动。

1.6 总结：这节课你学到了什么？

咱们这节课，主要讲了三个东西：

• 裸机开发的痛点：代码耦合度高，移植困难，维护成本大。
• 函数封装的局限性：只能解决引脚级的变化，无法应对MCU级的更换。
• 分层架构的核心思想：通过抽象层隔离变化，让上层业务逻辑与底层硬件解耦。

说白了，分层架构不是什么高深的理论，它就是一种组织代码的纪律。它强迫你思考：哪些是稳定的？哪些是易变的？然后把稳定的接口暴露出去，把易变的实现藏起来。