最近在指导学弟学妹做毕业设计时，发现一个挺普遍的现象：很多同学虽然能把STM32的各个模块（比如ADC、UART、I2C）跑起来，但一旦要把它们组合成一个完整的、能稳定运行的系统，就问题百出。要么是代码结构混乱，改一处动全身；要么是功耗居高不下，电池半天就没电；还有的通信数据丢包严重，调试起来一头雾水。

这让我想起了自己当年做毕业设计时踩过的坑，于是决定把之前一个比较成熟的项目——“基于STM32的环境监测终端”彻底开源，并梳理出其中的设计思路和关键实现。这个项目麻雀虽小，五脏俱全，涵盖了传感器数据采集、本地文件存储、低功耗无线通信等嵌入式系统常见环节，非常适合作为毕业设计的参考框架。

1. 项目痛点与设计目标

在开始动手前，我们先明确要解决哪些问题：

• 硬件耦合严重：很多同学的代码里，main.c 文件动辄几百行，传感器初始化、数据读取、逻辑处理、通信发送全挤在一起。想换个传感器型号？几乎要重写。
• 资源管理混乱：对MCU的休眠、唤醒机制不熟悉，系统一直处于全速运行状态，功耗是电池供电设备不可承受之重。
• 数据可靠性差：采集的数据直接通过串口打印，或者简单发送，没有校验、没有重传、没有本地缓存，一旦通信中断，数据就丢了。
• 可调试性差：出现问题后，只能靠printf大法，很难定位是传感器问题、通信问题还是逻辑问题。

针对这些，我们的设计目标很清晰：模块化、低功耗、高可靠、易调试。

2. 技术选型背后的思考

为什么是这些组件？我们来逐一分析：

• 主控MCU：STM32F411CEU6

  • 性能与功耗平衡：Cortex-M4内核，带FPU，做简单的数据滤波（如滑动平均）绰绰有余。相比F1系列，它提供了更灵活的低功耗模式（Stop模式）。
  • 外设丰富：拥有多个USART、I2C、SPI接口，方便同时连接传感器和通信模块。内置RTC（实时时钟），为定时唤醒和数据打时间戳提供了硬件基础。
  • 开发生态成熟：HAL库和CubeMX工具链极大降低了开发门槛，让初学者能更关注业务逻辑。

• 温湿度传感器：DHT22

  • 单总线协议：只占用一个GPIO口，节省宝贵的硬件资源。虽然对时序要求严格，但一旦驱动写好，非常稳定。
  • 成本与精度：对于毕业设计级别的环境监测，其精度（温度±0.5℃，湿度±2%RH）完全足够，且价格远低于I2C接口的SHT3x系列。

• 无线模块：LoRa（以SX1278为例）

  • 远距离与低功耗：这是核心优势。在郊区或校园环境，传输1-2公里很轻松。其“发射时功耗高，待机时功耗极低”的特性，非常适合我们“长时间休眠，定时唤醒上报”的场景。
  • 抗干扰能力强：相比Wi-Fi和蓝牙，LoRa在复杂环境下的链路稳定性更好，数据丢包率低。

• 文件系统：FatFS（R0.14c）

  • 兼容性与可读性：将数据以文件形式（如20240515.csv）存储在SD卡或SPI Flash中，文件可以直接在电脑上打开查看，调试和数据分析非常方便。
  • 磨损均衡：如果使用SPI Flash，配合FatFS和底层驱动，可以避免频繁写入同一Flash扇区，延长存储器寿命。

3. 核心实现：拆解与组装

整个系统的运行逻辑可以概括为：RTC定时唤醒 -> 采集传感器数据 -> 存储至文件 -> 组帧并通过LoRa发送 -> 进入低功耗休眠。下面我们分点拆解关键细节。

3.1 低功耗模式切换策略

功耗控制是电池设备的生命线。STM32F4提供了多种低功耗模式，我们主要用到Sleep和Stop模式。

• Sleep模式：仅内核停止，外设（如RTC、通信模块的唤醒引脚）仍在工作。功耗约几mA。适用于短时间等待（如等待传感器数据稳定）。
• Stop模式：所有时钟都停止，SRAM和寄存器内容保留。功耗可降至几十μA级别。这是我们长时间休眠（如10分钟采集一次）时采用的模式。

实现的关键在于HAL_PWR_EnterSTOPMode函数和唤醒源配置。我们使用RTC的闹钟（Alarm）作为唤醒源。

// 进入Stop模式前的准备
void Enter_Stop_Mode(void)
{
    // 1. 关闭所有不需要的外设时钟（如ADC、USART等）
    __HAL_RCC_ADC1_CLK_DISABLE();
    // ... 关闭其他外设时钟

    // 2. 配置唤醒源（这里使用RTC Alarm A）
    HAL_RTC_SetAlarm_IT(&hrtc, &sAlarm, RTC_FORMAT_BIN);

    // 3. 设置唤醒引脚（可选，如果通信模块有数据来需要唤醒）
    HAL_PWR_EnableWakeUpPin(PWR_WAKEUP_PIN1);

    // 4. 清除唤醒标志，进入Stop模式
    __HAL_PWR_CLEAR_FLAG(PWR_FLAG_WU);
    HAL_PWR_EnterSTOPMode(PWR_LOWPOWERREGULATOR_ON, PWR_STOPENTRY_WFI);

    // 5. 系统从这里被唤醒后继续执行
    SystemClock_Config(); // 重新配置系统时钟（HSE）
    // 重新初始化被关闭的外设
    MX_ADC1_Init();
    // ...
}

3.2 传感器驱动的模块化设计

绝对不要把DHT22的读写时序代码写在main函数里！我们将其封装成独立的dht22.c/.h文件。

• 接口抽象：头文件dht22.h只暴露两个函数：

  uint8_t DHT22_ReadData(float *temperature, float *humidity);
  void DHT22_Delay(uint32_t ms); // 提供微秒级延时函数接口
  

• 硬件解耦：在dht22.c内部，通过宏定义来指定数据引脚，这样换一个引脚只需要改一个地方。

  // dht22.c 顶部
  #define DHT22_GPIO_PORT GPIOC
  #define DHT22_GPIO_PIN  GPIO_PIN_13
  

• 错误处理：在DHT22_ReadData函数内部，严格检查起始信号和校验和，并返回不同的错误码（如DHT_ERROR_TIMEOUT, DHT_ERROR_CHECKSUM），方便上层逻辑判断。

3.3 数据流与帧封装

数据从采集到发送，经历了“原始值 -> 结构体 -> 文件存储 -> 通信帧”的转换。

1. 定义统一的数据结构体：

   typedef struct {
       RTC_TimeTypeDef time;
       RTC_DateTypeDef date;
       float temperature;
       float humidity;
       uint16_t battery_voltage; // ADC采集的电池电压
   } SensorData_t;
   

2. 文件存储：每次采集后，将SensorData_t结构体中的数据，格式化成一行CSV字符串，写入当天的数据文件。

   // 示例：2024-05-15,14:30:00,25.6,48.2,3300\n
   fprintf(&file, “%04d-%02d-%02d,%02d:%02d:%02d,%.1f,%.1f,%d\n”, ...);
   

3. LoRa通信帧封装：为了节省无线传输的流量和功耗，我们不能直接发送CSV字符串。需要定义一个紧凑的二进制帧格式。

   • 帧头：2字节，固定为0xAA 0x55，用于接收方同步。
   • 设备ID：4字节，唯一标识此终端。
   • 数据载荷：将SensorData_t中的浮点数转换为整型（如温度25.6 -> 256），并打包进字节数组。
   • CRC校验：2字节，校验帧的完整性，防止传输错误。

   发送前，调用LoRa模块的API，将此字节数组发送出去。接收端（网关）按照相同格式解析，并还原出数据。

4. 性能与稳定性的“守门员”

一个能用的系统和一个好用的系统，差别就在这些细节里。

• ADC采样精度：用于采集电池电压。STM32的ADC容易受到电源噪声影响。我们采取的措施是：

  • 软件上，采样多次（如16次）然后取平均值。
  • 硬件上，在ADC输入引脚加一个0.1uF的滤波电容。
  • 在代码中做校准，读取内部参考电压VREFINT来计算实际电压值，减少因供电电压波动带来的误差。

• 通信的幂等性：这是一个重要的概念。因为LoRa可能丢包或重复，我们的设计是：

  • 发送方：每一条数据帧都带有时间戳（来自RTC）。即使重复发送，也是相同时间戳的数据。
  • 接收方（服务器）：以“设备ID + 时间戳”作为唯一键。收到数据后，先检查数据库是否已有该时间戳的数据，如果有则更新，没有则插入。这样就保证了无论收到多少次，最终结果都是一致的。

• Flash写入寿命：如果我们使用SPI Flash（如W25Q128）来存储文件，需要关注其擦写次数（通常10万次）。

  • 策略：不是每次采集都立刻保存。可以缓存10条数据在内存中，凑够10条再一次性写入Flash，这样将写入频率降低为原来的1/10。
  • FatFS的功劳：文件系统会自动管理Flash的擦写块，在一定程度上实现了磨损均衡。

5. 那些年我们踩过的“坑”

这里分享几个调试过程中遇到的典型问题及解决方案：

• GPIO悬空导致电流异常：系统进入Stop模式后，发现电流还有几百μA，远高于理论值。用万用表逐一测量GPIO引脚电压，发现有几个配置为浮空输入（Floating Input）的引脚电压不稳。解决方案：将所有未使用的GPIO引脚，在初始化时设置为模拟输入（Analog）模式，这是功耗最低的状态。

• RTC时钟漂移：发现设备运行几天后，RTC的时间比实际时间慢了几十秒。原因是外部低速晶振（LSE）的负载电容不匹配。解决方案：

  1. 硬件上，根据晶振数据手册调整匹配电容（通常为两个10-22pF的电容）。
  2. 软件上，可以实现一个简单的“时钟补偿”算法。通过LoRa网关定期下发精确的北京时间，设备计算本地RTC的误差率（如每天慢2秒），然后在每次休眠前，动态调整RTC闹钟的唤醒间隔进行补偿。

• LoRa发送失败阻塞系统：在发送LoRa数据时，如果模块没有应答，原始的HAL_UART_Transmit函数会一直等待（阻塞）。解决方案：使用带超时的非阻塞方式发送，并加入重试机制。

  for(uint8_t retry = 0; retry < 3; retry++) {
      if(HAL_UART_Transmit(&huart2, tx_buffer, len, 100) == HAL_OK) {
          break; // 发送成功，跳出重试循环
      }
      HAL_Delay(100); // 等待片刻后重试
  }
  if(retry == 3) {
      // 重试3次均失败，将数据存入“发送失败”队列，下次唤醒时优先发送
  }
  

总结与展望

通过这个项目，我们实践了一个嵌入式产品从需求分析、技术选型、模块化编码到稳定性优化的完整流程。代码已经开源，大家可以在GitHub上搜索项目名找到它。希望这个框架能帮你快速搭建起毕业设计的核心骨架，把更多精力放在创新功能的实现上。

下一步可以尝试的扩展：LoRa虽然功耗低、距离远，但依赖自建网关。如果想让设备直接上云，可以尝试将LoRa模块替换为NB-IoT模块（如BC26）。只需要修改通信驱动层和相应的AT指令解析逻辑，上层的应用代码（数据采集、存储、封装）几乎可以无缝复用。这不仅能让你掌握另一种主流物联网通信技术，也能让项目的实用性和复杂度再上一个台阶。

嵌入式开发就是这样，从一个能跑通的小例子开始，不断遇到问题、解决问题，系统就在这个过程中变得越来越健壮。祝你毕业设计顺利！