STM32 + FreeRTOS 5层架构设计文档(用户业务代码)

一、架构整体说明

本架构仅包含用户业务代码,不含CubeMX自动生成的底层代码(Drivers、Middlewares);严格遵循“从上到下、单向调用”原则,禁止反向调用、跨层越级调用,确保工程整洁、可维护、可复用。

5层架构(从上到下):App 应用层 → Protocol 协议层 → Middleware 中间工具层 → BSP 板级封装层 → Driver 底层驱动层

二、各层详细说明(职责+内容+规则)

第一层:App 应用层

作用:业务逻辑核心,只关心“做什么”,是整个系统的业务入口。

内容:设备运行流程、状态机管理、FreeRTOS任务创建与任务实体、业务逻辑控制(如LED控制、OLED显示、4G/RS485业务交互等)。

规则:不直接操作硬件、不处理协议底层细节,仅调用下层(Protocol、Middleware、BSP)提供的接口完成业务逻辑。

第二层:Protocol 协议层

作用:负责通信协议的解析与封装,只关心“怎么通讯”,屏蔽协议底层差异。

内容:Modbus、自定义串口协议等的打包、解包、校验(如CRC校验)、寄存器映射、协议异常处理。

规则:不直接操作硬件,仅调用BSP层(硬件接口)和Middleware层(工具函数)完成协议处理。

第三层:Middleware 中间工具层

作用:通用工具库,与硬件、业务逻辑完全无关,提供全局可复用的工具函数。

内容:FIFO缓冲区、日志打印、CRC校验、数据滤波、软件定时器、数据格式转换(如进制转换、高低字节拆分)等纯软件算法。

规则:纯软件实现,无任何硬件依赖、无任何业务逻辑,可跨工程复用。

第四层:BSP 板级封装层

作用:对底层硬件接口进行统一封装,对上提供简洁、统一的API,屏蔽不同硬件的底层差异。

内容:板级外设操作(串口、LED、OLED、按键、继电器、4G、RS485等),统一封装硬件操作接口。

规则:不写业务逻辑、不处理协议,仅调用Driver层的底层驱动接口,对外提供标准化API。

第五层:Driver 底层驱动层

作用:最底层硬件驱动,直接操作芯片寄存器或HAL库,是硬件操作的最终入口。

内容:GPIO、UART、SPI、ADC、定时器等外设的初始化、读写操作,纯硬件底层驱动实现。

规则:仅做纯硬件操作,无任何业务逻辑、无协议处理、无逻辑判断,只对外提供最基础的硬件操作接口。

三、main函数标准模板(唯一规范)

c
int main(void)
{
  // 1. 系统底层初始化(CubeMX自动生成相关函数)
  HAL_Init();
  SystemClock_Config();

  // 2. BSP板级硬件初始化(调用BSP层统一初始化接口)
  BSP_Init();

  // 3. 创建所有FreeRTOS任务(顶层调用,统一管理任务创建)
  Task_CreateAll();

  // 4. 启动FreeRTOS调度器(系统进入自动调度模式)
  osKernelStart();

  while (1) {
    // 永远为空!不写任何业务逻辑、不做任何硬件操作
  }
}

四、FreeRTOS任务管理说明

核心逻辑:FreeRTOS内核(CubeMX自动生成)负责任务调度,用户仅需完成“任务创建”和“任务实体编写”。

  • 任务创建:统一放在 App 层的 task_create.c 文件中,通过 Task_CreateAll() 函数集中创建所有任务,便于管理。
  • 任务实体:每个任务的具体业务逻辑(while(1)循环),放在 App 层对应的心文件中(如app_led.c、app_oled.c)。
  • 任务调度:由FreeRTOS内核自动完成,无需用户编写调度代码,仅需设置任务优先级即可。

任务管理核心分工:

  • Task_CreateAll():负责创建所有FreeRTOS任务,统一管理任务优先级、堆栈大小。
  • User_App:负责编写每个任务的业务逻辑(任务实体),不负责任务创建。
  • FreeRTOS:负责自动调度所有任务,实现任务切换、延时、同步等功能。

五、系统运行流程(单向流转)

plain text
main函数启动
  ↓
系统初始化(HAL + 时钟)
  ↓
BSP硬件初始化(调用BSP_Init())
  ↓
创建所有FreeRTOS任务(调用Task_CreateAll())
  ↓
启动FreeRTOS调度器(osKernelStart())
  ↓
FreeRTOS自动调度任务
  ↓
App层(任务实体运行,执行业务逻辑)
  ↓
Protocol层(协议打包/解包) / Middleware层(调用工具函数)
  ↓
BSP层(调用板级封装API)
  ↓
Driver层(调用底层硬件驱动)
  ↓
HAL库 / 芯片寄存器
  ↓
硬件设备(执行具体操作)

六、工程目录结构(规范统一)

plain text
// 用户业务代码(自定义目录)
App                  // 应用层
  ├─ app_task.c       // 所有FreeRTOS任务创建(Task_CreateAll())
  ├─ app_led.c        // LED任务实体(业务逻辑)
  ├─ app_oled.c       // OLED任务实体(业务逻辑)
  ├─ app_rs485.c      // RS485任务实体(业务逻辑)
  └─ app_4g.c         // 4G任务实体(业务逻辑)

Protocol             // 协议层
  └─ modbus_rtu.c     // Modbus协议打包、解包、校验

Middleware           // 中间工具层
  ├─ crc.c            // CRC校验函数
  └─ fifo.c           // FIFO缓冲区操作

BSP                  // 板级封装层
  ├─ bsp_led.c        // LED板级封装API
  ├─ bsp_oled.c       // OLED板级封装API
  ├─ bsp_usart.c      // 串口板级封装API
  └─ bsp_rs485.c      // RS485板级封装API

Driver               // 底层驱动层
  ├─ drv_gpio.c       // GPIO底层驱动(初始化、读写)
  ├─ drv_uart.c       // UART底层驱动(初始化、收发)
  └─ drv_spi.c        // SPI底层驱动(初始化、读写)

// CubeMX自动生成代码(无需修改)
Drivers              // HAL库 + CMSIS内核相关文件
Middlewares          // FreeRTOS内核相关文件

七、调用规则(强制遵守)

1.  调用方向:只能从上往下调用,即 App → Protocol → Middleware → BSP → Driver,禁止反向调用(如下层调用上层)。

2.  禁止跨层:禁止跳过中间层直接调用下层接口(如App层直接调用Driver层、Protocol层直接调用Driver层)。

3.  职责边界:各层严格遵守自身职责,不越权处理其他层的内容(如BSP层不写业务逻辑,Driver层不处理协议)。

Logo

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。

更多推荐