基于RT-Thread与STM32F407的智能天气时钟：从传感器到网络GUI全流程实战

1. 项目概述与核心价值

最近在整理工作室的旧项目，翻出来一个几年前做的温湿度天气时钟，用的是STM32F407和RT-Thread。当时做这个的初衷很简单，就是想把手头闲置的开发板利用起来，做一个既有实用价值又能深入理解RTOS和网络协议栈的综合性项目。没想到这个小东西后来成了我工作室里最“长寿”的电子设备之一，一直稳定运行到现在。

这个项目本质上是一个集成了本地环境监测和远程天气信息获取的智能显示终端。它通过DHT11或SHT30这类传感器采集室内的温湿度数据，同时通过ESP8266 WiFi模块连接到互联网，从心知天气、和风天气这类开放的API服务获取实时的室外天气、温度、空气质量等信息。所有的数据经过处理后会在一块TFT液晶屏上以美观的界面显示出来，形成一个功能完整的桌面天气时钟。对于嵌入式开发者，尤其是从裸机开发转向RTOS的工程师来说，这个项目是一个绝佳的练手机会。它几乎涵盖了嵌入式开发的几个核心模块：MCU外设驱动（I2C, SPI, GPIO）、实时操作系统（任务管理、信号量、消息队列）、网络通信（TCP/IP, HTTP/JSON解析）以及GUI显示。通过复现这个案例，你不仅能得到一个实用的硬件作品，更能系统地掌握如何在资源受限的STM32平台上，构建一个稳定、可维护的多任务应用系统。

2. 硬件平台选型与核心电路设计

2.1 MCU与核心板选择：为什么是STM32F407？

在项目启动时，MCU的选择是首要决策。我最终选择了STM32F407VET6，这颗芯片属于STM32F4系列的中端型号，基于ARM Cortex-M4内核，主频高达168MHz，拥有512KB的Flash和192KB的SRAM。对于这个天气时钟项目来说，它的性能是绰绰有余的，甚至可以说有些“奢侈”。但我看中的是它的几个关键优势：首先，丰富的片上资源为运行RT-Thread提供了充足的空间，网络协议栈和文件系统都能轻松跑起来；其次，它拥有多个USART、I2C和SPI接口，可以非常方便地同时连接显示屏、温湿度传感器和WiFi模块，无需额外的IO扩展芯片；最后，F407的生态极其成熟，无论是标准库、HAL库还是RT-Thread的BSP支持都非常完善，能极大降低开发调试的难度。

注意：如果你手头是STM32F103（Cortex-M3）或STM32F401（M4但资源较少）等型号，理论上也可以运行RT-Thread Nano和LwIP轻量级协议栈，但可能需要更精细的内存管理和功能裁剪，开发复杂度会有所增加。对于初学者，F407是更稳妥的选择。

我使用的是市面上常见的“STM32F407VET6核心板”，这种板子将MCU、晶振、复位电路、USB转串口和所有IO口引针集成在一块小板上，价格便宜，接口齐全。你需要额外准备的就是一个3.3V的电源（通常核心板的Micro USB口即可供电）和一些杜邦线。这种核心板+外设模块的“积木式”开发方式，非常适合原型验证和个人项目。

2.2 传感器模块选型：精度、成本与接口的权衡

温湿度传感器的选择主要有两个方向：数字型和模拟型。DHT11是经典的入门级数字传感器，单总线通信，价格极低，但湿度精度±5%RH，温度精度±2°C，响应速度也较慢。对于要求不高的室内环境监测，它完全够用。我后来升级为了SHT30，这是一款I2C接口的传感器，精度（湿度±3%RH，温度±0.3°C）和响应速度远超DHT11，价格稍高但仍在可接受范围。在这个项目中，我以SHT30为例进行讲解，因为它的I2C驱动更具有通用性，其代码稍作修改即可适配SHT31、AHT20等同类传感器。

WiFi模块的选择几乎没有悬念，ESP8266（如ESP-01S模块）以其极高的性价比和成熟的AT指令固件生态成为首选。它通过串口与STM32通信，STM32发送AT指令控制其连接路由器、创建TCP连接等。也有朋友会问，为什么不直接用带WiFi的MCU（如ESP32）？原因在于，这个项目的学习重点之一是主控MCU与通信模组之间的协同，通过串口AT指令解析网络数据，能让你更清晰地理解应用层与网络层的边界，这对于理解复杂的嵌入式网络应用架构至关重要。

显示模块我选用的是2.4寸或2.8寸的ILI9341驱动的TFT液晶屏，接口为SPI。选择SPI屏而非并口屏，主要是为了节省宝贵的IO口资源。虽然SPI刷屏速度不如并口，但对于刷新频率不高的天气信息界面来说，其速度完全满足要求，且驱动简单，占用MCU资源少。

2.3 电路连接与电源管理

整个系统的连接非常简单，遵循“核心板为枢纽”的原则：

1. SHT30：VCC接3.3V，GND接地，SCL接STM32的PB6（I2C1_SCL），SDA接PB7（I2C1_SDA）。记得在SDA和SCL线上各接一个4.7K的上拉电阻到3.3V。
2. ESP-01S：VCC接3.3V（务必确保电源能提供至少500mA的峰值电流，否则WiFi启动时可能复位），GND接地，TX接STM32的PA3（USART2_RX），RX接PA2（USART2_TX）。CH_PD引脚接3.3V使能。
3. ILI9341 TFT屏：根据你的模块引脚定义，连接SPI的SCK、MISO、MOSI以及RESET、DC、CS等控制引脚到STM32的对应IO。通常我会使用SPI1（PA5, PA6, PA7）。

电源部分需要特别注意ESP8266的功耗。当WiFi模块在发射信号时，瞬时电流可能超过200mA。如果核心板的LDO（低压差线性稳压器）输出能力不足，会导致电压跌落，引起MCU或模块复位。一个实用的技巧是，在ESP8266的VCC引脚附近并联一个470μF的电解电容，可以很好地缓冲这种电流冲击。

3. 软件架构设计与RT-Thread工程搭建

3.1 RT-Thread操作系统引入的必要性

如果使用裸机编程，你需要自己用状态机或前后台的方式管理传感器读取、数据解析、网络通信和屏幕刷新，代码会很快变得复杂且难以维护，尤其网络AT指令的异步响应处理会非常棘手。RT-Thread的引入，正是为了解决多任务管理和资源同步的问题。

在这个项目中，我规划了四个主要任务：

• sensor_task：负责定时（如每5秒）读取SHT30的温湿度数据。
• weather_task：负责定时（如每10分钟）通过ESP8266从网络API获取天气信息。
• gui_task：负责管理显示界面，根据最新数据刷新屏幕。
• at_parser_task：一个常驻任务，专门解析ESP8266通过串口发来的所有AT指令响应和数据。

这些任务之间需要通信。例如，sensor_task读取到新数据后，需要通知gui_task更新本地温湿度显示；weather_task获取到网络天气数据后，也需要通知gui_task。同时，weather_task需要向at_parser_task发送指令并等待响应。RT-Thread提供的消息队列和信号量完美契合这些需求。这种清晰的任务划分和通信机制，是项目稳定运行的基石。

3.2 使用Env工具配置RT-Thread工程

我强烈推荐使用RT-Thread的Env配置工具和scons构建系统。它比直接使用MDK或IAR工程更灵活，特别是对于组件（如网络协议栈、文件系统、GUI框架）的裁剪和管理。

首先，从RT-Thread官网获取针对STM32F407的BSP（板级支持包）。在BSP根目录打开Env，执行menuconfig命令进入配置界面。以下是几个关键的配置步骤：

1. 硬件配置：在Hardware Drivers Config中，使能你需要的外设，如I2C1（用于SHT30）、USART2（用于ESP8266）、SPI1（用于LCD），以及对应的PIN驱动。
2. 组件配置：在RT-Thread Components中，使能AT commands、POSIX layer and C standard library。AT组件是连接ESP8266 AT固件的桥梁，POSIX层便于使用标准的C库函数（如sprintf,strstr）。
3. 网络配置：在Network中，使能SAL (Socket Abstraction Layer)和Protocol stack，选择lwIP作为协议栈。然后，在AT commands子菜单下，使能AT client和AT socket功能。AT socket是这个项目的关键，它允许我们像使用标准的BSD Socket一样（如connect,send,recv）来操作ESP8266的网络连接，极大简化了网络编程。
4. 软件包配置：RT-Thread的另一个强大之处在于其软件包中心。我们可以通过menuconfig->RT-Thread online packages来添加现成的库。例如，可以添加cJSON软件包用于解析从天气API返回的JSON数据，添加u8g2或LVGL软件包用于高级GUI开发（本项目为简化起见，直接使用LCD驱动画图）。

配置完成后，保存退出，在Env中执行pkgs --update更新软件包，然后执行scons --target=mdk5生成Keil MDK工程文件。打开生成的project.uvprojx，你就可以在熟悉的IDE环境中进行代码编写和调试了。

3.3 任务划分与通信机制设计

在applications文件夹下创建main.c，开始编写我们的应用任务。首先定义任务间通信的载体：

/* 定义消息结构体 */ struct sensor_msg { float temperature; float humidity; }; struct weather_msg { char weather[20]; // 如“晴”、“多云” int temp; int humidity; char city[20]; }; /* 创建消息队列 */ static rt_mq_t sensor_mq; static rt_mq_t weather_mq; /* 创建信号量，用于AT指令同步 */ static rt_sem_t at_ack_sem;

在main函数中，初始化这些内核对象，并创建任务：

int main(void) { /* 硬件初始化：I2C、SPI、LCD等应在RT-Thread启动前或单独任务中完成 */ lcd_init(); sht30_init(); at_client_init(); // 初始化AT客户端 /* 创建消息队列 */ sensor_mq = rt_mq_create("sensor_mq", sizeof(struct sensor_msg), 10, RT_IPC_FLAG_FIFO); weather_mq = rt_mq_create("weather_mq", sizeof(struct weather_msg), 5, RT_IPC_FLAG_FIFO); /* 创建二进制信号量 */ at_ack_sem = rt_sem_create("at_ack", 0, RT_IPC_FLAG_FIFO); /* 创建任务 */ rt_thread_t sensor_tid, weather_tid, gui_tid, at_parser_tid; sensor_tid = rt_thread_create("sensor", sensor_task_entry, RT_NULL, 1024, 10, 10); weather_tid = rt_thread_create("weather", weather_task_entry, RT_NULL, 2048, 8, 10); gui_tid = rt_thread_create("gui", gui_task_entry, RT_NULL, 4096, 6, 10); // GUI任务需要较大栈空间 at_parser_tid = rt_thread_create("at_parser", at_parser_task_entry, RT_NULL, 2048, 12, 10); /* 启动任务 */ if (sensor_tid) rt_thread_startup(sensor_tid); if (weather_tid) rt_thread_startup(weather_tid); if (gui_tid) rt_thread_startup(gui_tid); if (at_parser_tid) rt_thread_startup(at_parser_tid); return 0; }

这样的架构清晰地将不同职责模块化，每个任务专注于自己的事务，通过消息队列解耦，系统的可测试性和可维护性大大增强。

4. 关键驱动与组件实现详解

4.1 SHT30传感器I2C驱动实现

RT-Thread提供了完善的I2C设备驱动框架。我们首先需要在menuconfig中使能I2C1总线。然后，编写SHT30的设备驱动。这里的关键是理解SHT30的测量命令和CRC校验。

在drivers目录下创建sht30.c和sht30.h。首先实现一个基础的写命令函数：

rt_err_t sht30_write_cmd(uint8_t *cmd, uint8_t len) { struct rt_i2c_msg msgs; rt_device_t i2c_bus = rt_device_find("i2c1"); // 查找I2C总线设备 if (i2c_bus == RT_NULL) { rt_kprintf("I2C bus not found!\n"); return -RT_ERROR; } msgs.addr = SHT30_ADDR; // 0x44 msgs.flags = RT_I2C_WR; // 写标志 msgs.buf = cmd; msgs.len = len; if (rt_i2c_transfer(i2c_bus, &msgs, 1) == 1) { return RT_EOK; } else { return -RT_ERROR; } }

读取温湿度数据的函数需要先发送测量命令（例如高重复性测量0x2C06），延迟15ms（根据数据手册），然后读取6个字节的数据（温度高8位、低8位、CRC8、湿度高8位、低8位、CRC8）。CRC校验是保证数据可靠性的关键，不能省略。网上有现成的CRC8计算代码，直接集成即可。

实操心得：I2C通信失败，十有八九是硬件问题。除了检查接线和上拉电阻，务必用逻辑分析仪或示波器抓一下SCL和SDA的波形，确认起始信号、地址、数据和ACK信号都符合预期。软件上，可以逐步增加rt_i2c_transfer后的调试打印，定位是在哪一步出错。

4.2 ESP8266 AT指令套接字编程

这是项目的网络核心。RT-Thread的AT组件和SAL层为我们做了大量封装。我们需要做的是：

1. 初始化网络：在weather_task中，首先使用at_exec_cmd发送AT+CWMODE=1（STA模式）、AT+CWJAP="SSID","password"连接WiFi等基础AT指令。这些指令是同步的，需要等待OK或ERROR响应。
2. 使用AT Socket联网：连接WiFi成功后，我们就可以使用标准的socket API了。因为我们在menuconfig中使能了AT socket，系统会自动将socket调用通过AT指令转发给ESP8266。

int get_weather_data(void) { int sockfd; char *host = "api.seniverse.com"; char request[512]; char recv_buf[1024]; struct hostent *server; struct sockaddr_in serv_addr; /* 1. 创建socket */ if ((sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0) { rt_kprintf("Socket creation error\n"); return -1; } /* 2. 解析主机名（AT Socket可能不支持，建议直接使用IP地址）*/ // 更稳妥的方式是提前通过AT+PING指令获取IP，或使用静态IP serv_addr.sin_addr.s_addr = inet_addr("123.456.789.012"); // 替换为天气API服务器的实际IP serv_addr.sin_family = AF_INET; serv_addr.sin_port = htons(80); // HTTP端口 /* 3. 连接服务器 */ if (connect(sockfd, (struct sockaddr *)&serv_addr, sizeof(serv_addr)) < 0) { rt_kprintf("Connection Failed\n"); closesocket(sockfd); return -1; } /* 4. 构造HTTP GET请求 */ snprintf(request, sizeof(request), "GET /v3/weather/now.json?key=YOUR_API_KEY&location=beijing&language=zh-Hans&unit=c HTTP/1.1\r\n" "Host: %s\r\n" "Connection: close\r\n" "\r\n", host); /* 5. 发送请求 */ if (send(sockfd, request, strlen(request), 0) < 0) { rt_kprintf("Send failed\n"); closesocket(sockfd); return -1; } /* 6. 接收响应 */ int total_len = 0; int len = 0; while ((len = recv(sockfd, recv_buf + total_len, sizeof(recv_buf) - total_len - 1, 0)) > 0) { total_len += len; } recv_buf[total_len] = '\0'; closesocket(sockfd); /* 7. 解析JSON（这里需要cJSON库）*/ // 从HTTP响应体中提取JSON部分，然后用cJSON解析，提取weather、temperature等信息 // ... return 0; }

注意事项：ESP8266的AT固件对连续接收大量数据（如完整的HTTP响应）可能处理不过来，导致数据丢失或连接关闭。建议在recv循环中增加小的延时（如rt_thread_mdelay(10)），并设置合理的接收超时。另外，务必在socket操作的外层进行异常处理和重试机制，因为网络是不稳定的。

4.3 TFT液晶屏的图形界面绘制

在没有使用高级GUI库的情况下，我们需要基于LCD驱动实现基本的绘图功能。通常ILI9341的驱动会提供画点、画线、填充矩形、显示字符等基本函数。我们的界面可以设计得简洁明了：

• 顶部区域：显示城市名称、日期和时间（可以通过网络对时NTP获取，或使用RTC）。
• 中部左侧：大字体显示当前室外温度。
• 中部右侧：显示天气图标（晴、雨、雪等）和文字描述。
• 下部：分两行显示室内温湿度（来自SHT30）。

实现时，关键在于避免在GUI任务中阻塞。gui_task的主体应该是一个无限循环，等待来自sensor_mq和weather_mq的消息。一旦收到新消息，就更新对应的显示区域。对于时间，可以创建一个单独的软件定时器，每秒触发一次，只刷新时间显示区域。

static void gui_task_entry(void *parameter) { struct sensor_msg local_sensor_msg; struct weather_msg local_weather_msg; rt_uint8_t *sensor_ptr, *weather_ptr; /* 初始化显示，绘制静态界面框架 */ lcd_clear(WHITE); draw_static_ui(); while (1) { /* 非阻塞地检查传感器消息队列 */ if (rt_mq_recv(sensor_mq, &local_sensor_msg, sizeof(local_sensor_msg), 0) == RT_EOK) { /* 收到新的传感器数据，更新屏幕对应区域 */ update_indoor_display(local_sensor_msg.temperature, local_sensor_msg.humidity); } /* 非阻塞地检查天气消息队列 */ if (rt_mq_recv(weather_mq, &local_weather_msg, sizeof(local_weather_msg), 0) == RT_EOK) { /* 收到新的天气数据，更新屏幕对应区域 */ update_weather_display(&local_weather_msg); } /* 每秒更新一次时间 */ update_time_display(); rt_thread_mdelay(1000); // 每秒循环一次 } }

这种基于消息驱动的UI更新机制，确保了界面的响应性，并且CPU占用率很低。

5. 系统集成、调试与优化实录

5.1 多任务同步与数据一致性挑战

当多个任务同时访问共享资源（例如，一个用于格式化显示字符串的全局缓冲区）时，就会产生竞态条件。在这个项目中，虽然核心数据通过消息队列传递，避免了直接共享，但在调试打印、或者某些临时计算中，仍可能用到全局变量。使用互斥锁是标准的解决方案。RT-Thread提供了rt_mutex。

例如，我们有一个全局的调试信息缓冲区debug_buf，多个任务都可能调用rt_kprintf来打印日志（虽然rt_kprintf本身可能是线程安全的，但这里举例说明）：

static rt_mutex_t debug_mutex; static char debug_buf[128]; void safe_print(const char *format, ...) { va_list args; rt_mutex_take(debug_mutex, RT_WAITING_FOREVER); va_start(args, format); rt_vsnprintf(debug_buf, sizeof(debug_buf), format, args); va_end(args); // 这里可以将debug_buf输出到串口、屏幕或网络 uart_send_string(debug_buf); rt_mutex_release(debug_mutex); }

在main函数中初始化这个互斥锁：debug_mutex = rt_mutex_create("debug_mtx", RT_IPC_FLAG_FIFO)。任何任务需要打印时，都调用safe_print函数。

5.2 低功耗与稳定性优化策略

作为一个常驻设备，稳定性是第一位的。除了硬件上做好电源滤波，软件上也有几个优化点：

1. 看门狗：务必启用STM32的独立看门狗。在main函数初始化后立即启动IWDG，并在主任务或一个专用的监控任务中定期喂狗。这能防止程序跑飞导致死机。
2. 网络异常处理：weather_task中的网络请求必须放在一个while(1)循环中，并包含完整的异常处理。一次HTTP请求失败，应该延迟一段时间（如2分钟）后重试，而不是卡死。同时，连续多次失败后，可以考虑重启ESP8266模块（通过控制其EN或RST引脚）。
3. 内存监控：RT-Thread提供了list_mem和list_thread等命令（通过Finsh控制台）。定期检查内存碎片和线程栈使用情况，确保没有内存泄漏或栈溢出。特别是gui_task和at_parser_task，栈空间要设置得充裕一些。
4. 合理的任务优先级：at_parser_task负责处理异步的AT响应，优先级应设为最高（如12），确保它能及时处理来自ESP8266的数据，避免串口缓冲区溢出。gui_task的刷新频率低，优先级可以设低一些（如6）。sensor_task和weather_task是周期性任务，优先级居中。

5.3 常见问题排查与解决实录

在开发和调试过程中，我遇到了不少典型问题，这里记录下排查思路：

问题一：ESP8266连接WiFi成功，但无法创建TCP连接。

• 排查：首先使用AT指令手动测试：AT+CIPSTART="TCP","api.seniverse.com",80。如果返回ERROR，可能是DNS解析失败。尝试使用IP地址直接连接（如AT+CIPSTART="TCP","123.456.789.012",80）。
• 解决：在代码中，可以先发送AT+CIPDOMAIN="api.seniverse.com"解析域名获取IP，然后用IP去创建连接。或者，更简单的方法是，在程序中硬编码API服务器的IP地址（虽然不优雅，但稳定）。

问题二：屏幕显示乱码或花屏。

• 排查：首先检查SPI的时序和频率。ILI9341初始化序列是否正确？可以通过逻辑分析仪抓取SPI总线数据，与数据手册的初始化命令对比。其次，检查GRAM的写入方向（旋转设置）。
• 解决：确保在lcd_init()函数中，严格按照驱动芯片数据手册的初始化流程，并正确设置内存访问控制寄存器（MADCTL）。如果使用DMA传输，要确保缓冲区对齐和传输完成标志。

问题三：系统运行一段时间后死机。

• 排查：
  1. 检查看门狗是否启用并正常喂狗。
  2. 检查各任务栈空间是否足够。可以在list_thread命令输出中查看每个线程的“max used”栈使用量，确保它小于分配的栈大小。
  3. 检查消息队列是否被填满未及时取出，导致发送任务永久阻塞。可以适当增大队列容量，或提高消费者任务（如gui_task）的优先级。
  4. 使用list_mem检查内存分配情况，看是否有持续增长未释放的情况。
• 解决：根据排查结果调整栈大小、队列长度，并仔细检查代码中动态内存（rt_malloc）的分配与释放是否成对出现。

问题四：SHT30读取数据偶尔失败。

• 排查：I2C通信对时序和电气特性比较敏感。首先检查硬件连接和上拉电阻（通常4.7K）。然后用逻辑分析仪观察失败时的I2C波形，看是否在发送测量命令后，MCU是否给出了足够的测量时间（mdelay(15)）再去读取。最后，检查CRC校验计算是否正确，可能是CRC错误导致数据被丢弃。
• 解决：在读取函数中加入重试机制。如果一次读取失败（CRC错误或I2C NACK），可以重试2-3次。同时，确保I2C总线在初始化时设置了正确的时钟频率（如100kHz或400kHz）。

这个基于RT-Thread和STM32F407的温湿度天气时钟项目，从硬件选型、软件架构到调试优化，完整地走完了一个嵌入式产品从原型到稳定运行的全过程。它没有用到特别高深的技术，但将嵌入式开发中常见的知识点串联了起来。当你看到屏幕上稳定刷新的室内外温湿度和天气图标时，那种将代码转化为实际功能的成就感，正是驱动我们不断折腾的动力。希望这个详细的案例拆解，能为你自己的嵌入式项目带来一些切实可行的思路和帮助。