第三章：软件架构分层设计——应用层、中间件层、硬件抽象层（HAL）、驱动层的职责划分

好，咱们今天聊点硬核的。软件架构分层，说白了就是给代码分家。你想想看，一个车道保持系统，代码量少说也得几万行。如果不分层，所有东西揉在一起，那调试起来简直是一场噩梦。

我个人习惯，把嵌入式软件分成四层：应用层、中间件层、硬件抽象层（HAL）、驱动层。每一层各司其职，互不干扰。这样做的好处是什么？我举个例子，你换了一个摄像头传感器，只需要改驱动层和HAL层，应用层的逻辑代码完全不用动。这在项目迭代中，能省下大把时间。

3.1 应用层：业务逻辑的“大脑”

应用层是离用户最近的一层。它负责实现车道保持的核心算法和决策逻辑。比如，车道线检测、车辆横向控制、状态机切换等。

这一层的代码，应该只关心“做什么”，不关心“怎么做”。它调用中间件层提供的接口，但完全不知道底层用的是I2C还是SPI，也不知道传感器是哪个厂家的。

我在项目中遇到过一个问题：应用层代码里直接操作了GPIO寄存器。当时为了赶进度，有人图省事就这么干了。结果后来换MCU，所有应用层代码都得重写。嗯，这就是典型的架构没分好。

3.2 中间件层：承上启下的“桥梁”

中间件层，我更喜欢叫它“胶水层”。它把应用层和底层硬件隔离开。说白了，应用层要读一个传感器数据，中间件层就提供一个标准化的接口，比如 GetLaneData()。至于这个数据是从CAN总线来的，还是从以太网来的，应用层根本不需要知道。

中间件层通常包含：

• 数据融合模块（多传感器数据对齐）
• 通信协议封装（CAN、LIN、以太网）
• 时间同步机制
• 日志与调试接口

3.3 硬件抽象层（HAL）：硬件的“翻译官”

HAL层，是连接驱动层和中间件层的纽带。它的存在，就是为了解决硬件差异。比如，不同MCU的定时器配置方式不同，但HAL层提供一个统一的 HAL_TIM_Base_Start() 接口，上层调用时完全不用关心底层寄存器怎么配。

HAL层的职责很明确：

• 封装MCU外设的通用操作（GPIO、TIM、ADC、DMA）
• 提供跨平台移植能力
• 处理硬件中断的底层逻辑

举个例子，下面是一个典型的HAL层代码片段：

// HAL层：统一PWM输出接口
void HAL_PWM_SetDutyCycle(PWM_HandleTypeDef *hpwm, uint32_t channel, uint32_t duty) {
    // 内部调用驱动层函数
    DRV_PWM_SetCompare(hpwm->Instance, channel, duty);
}

你看，HAL层只是做了一层简单的封装。但就是这层封装，让你从STM32换到NXP时，只需要改HAL层和驱动层，应用层代码一行都不用动。

3.4 驱动层：硬件的“操作工”

驱动层是最底层，直接和寄存器打交道。它负责初始化外设、配置中断、读写数据。这一层的代码，通常和MCU型号强相关。

驱动层的典型工作：

• 配置GPIO方向、上下拉
• 设置定时器预分频、自动重装值
• 初始化SPI/I2C通信速率
• 处理DMA传输完成中断

驱动层的代码，应该尽量“薄”。它只做最基础的硬件操作，不做任何业务逻辑判断。比如：

// 驱动层：直接操作寄存器
void DRV_GPIO_SetPin(GPIO_TypeDef *port, uint16_t pin) {
    port->BSRR = pin;  // 设置引脚为高电平
}

你想想看，如果驱动层里加了“如果车速大于100km/h，就点亮LED”这种逻辑，那架构就彻底乱套了。驱动层只管“怎么操作硬件”，不管“为什么操作硬件”。

3.5 各层之间的协作关系

这四层是怎么配合的？我画个简单的数据流给你看：

层级	输入	处理	输出
应用层	车道线数据	计算目标转向角	转向指令
中间件层	原始传感器数据	数据融合、时间戳对齐	标准化车道线数据
HAL层	驱动层数据	外设抽象封装	统一接口数据
驱动层	寄存器值	硬件初始化、中断处理	原始传感器数据

说白了，数据从下往上流，指令从上往下流。每一层只和相邻层打交道，绝不越级。这样做的好处，我在实际项目中深有体会：有一次客户要求换一个更高精度的转向执行器，我只改了驱动层和HAL层，应用层的PID参数都没动，两天就搞定了。

嗯，分层架构说难不难，说简单也不简单。关键是要坚持“各司其职”的原则。我见过太多项目，一开始分层分得好好的，后来一赶进度就开始乱来。记住，架构的纪律性，比技术本身更重要。