企业官网建设流程全解析

简介：这是一套面向嵌入式初学者与课程设计者的完整物联网日程管理项目资源，基于STM32F103C8T6（正点原子Mini开发板）实现带WiFi交互、温湿度感知、RTC实时时钟、语音播报及触摸交互的智能日程表系统。资源覆盖硬件驱动（LCD、DHT11、ESP8266、SYN6288、W25Q64）、FATFS文件系统移植、QT跨平台上位机（含Android APK与Windows可执行程序）及配套文档，解决嵌入式人机交互类综合项目开发中多模块协同、数据持久化与远程配置等典型问题。压缩包共210个文件，含25个C/H源码文件（如lcd.c、ff.c、sdio_sdcard.c）、25个编译中间文件（.o/.d）、22个Qt翻译文件（.qm）、4个界面效果图（.png/.jpg）及1个PDF功能说明文档等，整体47.4MB，结构清晰、模块边界明确，便于逐层理解与二次开发。已有907人学习下载，提供可直接烧录的.hex与.axf镜像、完整Android安装包、Windows可执行程序及详细实物效果图，显著降低调试门槛与集成难度。 先交代一下这个项目的来由。我桌面上常年堆着好几块STM32开发板，平时调完一个外设就换下一个，真正拿到日常生活里用的几乎没有。直到有一天下午，手机弹出的日程提醒被我连续划掉三次，然后我彻底忘了两小时后有个重要会议。那一刻我意识到，手机通知对我是无效的——我需要一个会开口说话的实体设备，在我出门前把今天的安排直接念出来。于是就有了这个基于STM32的WiFi语音播报日程表，配套一个上位机用来编辑和管理日程，整个项目做下来，既解决了实际问题，也把串口、WiFi、语音合成、上位机开发这些技能完整串了一遍。

这篇文章我会从硬件选型、上位机方案、通信协议、STM32端核心实现、踩坑排错这几个维度完整讲一遍。适合学过STM32基础、想做一个"带联网功能、有配套PC软件"的完整物联网小项目的朋友参考，也适合正在找毕设或者简历项目的人拿来改造成自己的作品。

1. 这个项目解决什么问题：从"闹钟响三遍也没记住"说起

1.1 传统提醒方式的真实痛点

手机日程提醒最大的问题不是不响，而是太容易被忽略。我统计过自己的使用习惯：早上闹钟响后，我关掉它的动作几乎是肌肉记忆，大脑在那一瞬间根本不会去处理屏幕上的文字。就算看到了，解锁、打开日历、查看详情这一串操作也会被拖延到"等一下再说"，然后就再也没有然后。

还有一种情况是提醒的时机不对。手机的日程提醒往往在你正在专注做某件事的时候弹出来，你扫一眼觉得"还早"，实际上等你忙完就已经错过了。而一个放在桌面上的独立设备，用语音把日程念出来，它所在的物理空间就天然制造了一种"必须处理"的仪式感。

1.2 语音播报日程表的目标形态

我做这个项目时，给它的定位是一个桌面小盒子。它的核心行为是这样的：

• 每天早上定时播报当天的全部日程安排，比如"早上好，今天九点有项目周会，记得带工牌和电脑充电器"
• 设定某条日程前的提前提醒，比如会议前10分钟念一遍
• 上电联网后自动校准时间，不需要手动调RTC
• 用电脑上的上位机程序添加、删除、修改日程，通过WiFi下发到设备
• 设备端自带OLED小屏幕，显示当前时间和WiFi连接状态

这里有一个关键设计思路：日程管理的入口在上位机，不在设备本身。设备端只做一个五向按键用来应急闹钟停播和临时查看，复杂的编辑操作全部交给PC。这样做的原因是日程文本输入在单片机端体验极差，一个旋钮选字母的操作我能忍受一次，但每次改日程都这样谁都会疯掉。

1.3 为什么选STM32加WiFi加上位机这个组合

先说STM32。这个项目的核心功能是串口通信、定时调度、外设控制，STM32F1系列完全够用，不需要上带操作系统的处理器。更重要的是，STM32的HAL库生态成熟，网上资料多，遇到问题好排查。

再说WiFi。本来可以用蓝牙，但蓝牙的通信距离短、配对麻烦，而且PC端开发一个蓝牙虚拟串口远不如走TCP来得干净。用ESP8266模组把设备接到局域网，上位机通过TCP协议直连，整个链路非常直观，排错也方便。

最后说上位机。这个项目没有上位机其实也能运行，但只能是"出厂预置几条日程"的封闭玩具。有了上位机，才能实现日程的灵活编辑、批量同步、天气信息获取这些真正有实用价值的功能。做上位机也顺便把C#的Socket编程、JSON解析、UI布局这些技能练了一遍，算是一鱼两吃。

2. 硬件选型与系统架构：为什么是F103C8T6加ESP8266加SYN6288

2.1 主控选型：STM32F103C8T6够不够用

先说结论：完全够用，而且还有不少余量。

STM32F103C8T6的核心参数是72MHz主频、64KB Flash、20KB RAM。这个项目里主要的RAM消耗点有三个：串口接收缓冲、cJSON解析时的临时对象、日程文本的拼接缓冲区。我实测下来，在最极端的情况下（同时缓存几帧AT指令回显、解析一条含中文的JSON日程、拼接一条语音播报文本），RAM占用大概在6KB左右，离20KB的极限还很远。Flash方面，HAL库加上外设驱动、cJSON、字库转换表，总共烧进去大概40KB左右，也够。

选用这个芯片还有一个实际考虑：蓝色Pill开发板很便宜，而且板载USB转串口，调试阶段可以省掉一个USB转TTL模块。项目做完了如果想打板，这个芯片的封装也很好手工焊接。

2.2 语音播报方案对比：合成芯片还是预录音频

语音播报是这个项目体验的核心，方案选错了整个产品感就垮了。我对比了市面上常见的几种方案：

我最终选了SYN6288。原因很简单：日程文本是用户在上位机里随便输入的，任何一条都可能是完全陌生的组合，只有离线合成芯片能做到"拿到文本就念出来"。预录音频方案完全不适用于动态日程，在线TTS方案要处理的环节太多，容易顾此失彼。

SYN6288的接线也非常简单：VCC接3.3V，GND接地，TXD接STM32的一个USART的RX，RXD接同一USART的TX，再加一个功放喇叭。串口波特率默认9600，8位数据、1位停止位、无校验。

2.3 WiFi模块：ESP8266-01s的AT指令模式

WiFi部分我用的ESP8266-01s，选这个模块而不是直接上ESP32的原因很简单：项目标题就是"基于STM32设计"，ESP8266在这里的角色是"STM32的无线网卡"，用AT指令驱动即可，不需要给它单独写固件。

ESP8266-01s的引脚非常少，一共8个，实际用到的更少：

• VCC接3.3V，注意必须是稳定的3.3V，电流要求到300mA以上，用开发板自带的LDO供电够用
• GND接地
• TX接STM32的USART1_RX（PA10）
• RX接STM32的USART1_TX（PA9）
• EN（CH_PD）接3.3V使能
• GPIO0保持悬空或接上拉，进入正常工作模式
• GPIO2悬空

ESP8266的固件默认波特率是115200，AT指令的交互方式是"发一条指令，等回显+结果码"。比如发AT\r\n，正常会回AT\r\nOK\r\n。这里有个重要的经验：AT指令模块的接收和回显是异步的，不能发完就立刻认为收到了完整的回复，一定要做超时判断和帧完整性判断，否则程序跑复杂了之后很容易因为时序问题随机卡死。

2.4 系统整体连接关系与引脚分配

整个系统的硬件连接我用文字描述一下：电源进来之后分三路，一路给STM32开发板，一路通过稳压给ESP8266，一路给SYN6288和功放。STM32的USART1接ESP8266用于联网，USART2接SYN6288用于语音合成，I2C1接DS3231高精度RTC时钟芯片，SPI1接W25Q32 Flash存储日程数据，I2C2接0.96寸OLED显示状态。还有一路PWM输出控制无源蜂鸣器，当作语音播报的补充提醒。

具体的引脚分配表：

这里我要特别强调一下DS3231的选择。很多人会用DS1302，觉得便宜够用，但实际上DS1302的走时精度在常温下还凑合，温度一变化就可能一天差几十秒。DS3231内置了温补晶振，精度要做到年误差几分钟级别，而且它带I2C接口，跟STM32对接比DS1302那种自定义三线协议简单得多。既然是联网设备，每次上电都会校准RTC，芯片本身精度要求可以放宽，但DS3231的可靠性依然值得多花这几块钱。

2.5 为什么要用W25Q32存日程而不是STM32内部Flash

这是我在设计时踩过的一个思维惯性坑。STM32F103C8T6自带64KB Flash，看着空间足够存几百条日程，直接往里写多省事？但问题在于内部Flash的擦写寿命只有一万次左右，而且擦除操作会阻塞CPU。

我们来算一笔账：如果你每天早晚各同步一次日程，每次同步都全量擦写日程区，一天就是两次擦写，一年730次，一万次寿命大约能用13年，听起来好像够了对不对？但实际开发调试阶段，你可能一天之内就会反复擦写几十上百次，加上Flash擦写是按扇区（1KB）进行的，即使只改了一个字节也要擦掉整个扇区，磨损会更快。

所以我用了外挂的W25Q32 SPI Flash，32Mbit（4MB）容量，擦写寿命十万次，而且SPI Flash的擦写不阻塞主流程太久，配合简单的磨损均衡策略（每次写入轮询使用不同的扇区组），寿命完全不用操心。实际数据结构里，每条日程大约占128字节（包含时间戳、文本内容、校验字段），4MB空间存几千条都绰绰有余。

3. 上位机方案取舍：C# WPF还是PyQt，通信拓扑怎么定

3.1 上位机的职责边界

这个项目的上位机，功能定位我给它划了三条明确的边界：编辑日程、下发数据、状态监控。

编辑日程指用户能在一个图形化界面里增删改日程条目，包括时间、文本内容、是否启用、是否重复；下发数据指把编辑好的日程列表通过WiFi同步到设备端；状态监控指显示当前连接状态、设备是否在线、设备端是否已经播报过某条日程。

我刻意没有让上位机承担"语音播报"的职责。PC端也可以调用Windows的TTS库直接念日程，那样确实更省事，但这就把项目的核心价值从"独立硬件设备"降级成了"一个带音箱的PC程序"，完全失去了DIY的意义。上位机负责管理，设备负责执行，这个边界定清楚了，整个项目的架构就清晰了。

3.2 C# WPF和PyQt的对比

我做上位机时在C# WPF和PyQt之间纠结了一段时间，最后选了C# WPF。原因有三点：

第一，C#的Socket编程和JSON序列化用起来太顺手了。TcpClient类封装好了连接、读写、关闭的完整生命周期，System.Text.Json或Newtonsoft.Json可以直接把日程对象序列化成JSON字符串，不需要像Python那样到处注意缩进和类型转换。

第二，WPF的界面布局能力比PyQt的QWidget要现代一些，用XAML做数据绑定非常灵活，日程列表的增删改可以靠ObservableCollection自动刷新UI，不用手动写一堆ui->update()。

第三，发布部署简单。Visual Studio里直接发布成单文件exe，目标机器装了.NET Desktop Runtime就能跑，不需要像PyQt那样打包各种dll。

不过我也得承认PyQt的优势：跨平台、Python生态方便快速抓取天气API做原型验证。如果你主力开发机是Mac或者Linux，那PyQt是更自然的选择。这个项目里因为最终要连局域网内设备做联调，我一直在Windows上开发，所以C# WPF胜出。

3.3 通信拓扑：设备做Server还是PC做Server

这是整个项目最关键的架构决策。我选择的方案是：ESP8266作为TCP Server，上位机作为TCP Client主动去连接设备。

反过来思考一下。如果让PC做Server，ESP8266做Client主动连PC，那会有两个问题：一是ESP8266在Station模式下要连接路由器拿到IP之后才能去连PC，这个连接动作依赖PC端的Server先启动，如果上位机程序没开，设备就永远连不上，这不符合"设备独立工作"的定位；二是如果换了网络环境，PC的IP地址会变，ESP8266固件里不可能写死一个永远不变的PC地址。

做Server的好处在于：设备的IP是路由器动态分配的，但设备自己知道自己的IP，设备开机后在OLED上显示出来，上位机输入IP即可连接。更进一步，设备可以主动向局域网广播自己的存在，上位机自动发现设备，用户连IP都不用输入。

这里有一个容易忽略的细节：ESP8266在AT指令模式下要开启TCP Server，必须先设置AT+CIPMUX=1（多连接模式），然后AT+CIPSERVER=1,8080。CIPSERVER这个指令的第二个参数是端口号，可以在1到65535之间选，但要注意避开常见的已被占用的端口（比如80、443、8080在部分路由器上可能会有冲突），我选的是9000端口。

3.4 设备自动发现的实现思路

为了让上位机做到"打开就能自动找到设备"，我加了一个UDP广播发现机制。具体做法是：

• ESP8266在开启TCP Server的同时，额外建立一个UDP连接，目标地址是255.255.255.255，端口1900，周期性地发送一条发现报文，内容是设备型号和名称，比如"STM32-SCHEDULER"
• 上位机启动时监听本机1900端口，收到这条广播后提取来源IP，填入设备IP输入框并尝试连接

直接用ESP8266的AT指令发UDP广播有一个坑：AT+CIPSTART=0,"UDP","255.255.255.255",1900这种方式建立的UDP连接是单向的，而且广播包能不能发出去取决于路由器是否允许。实测下来家用路由器基本都能通，公司网络可能会有隔离策略导致收不到。所以我的设计是：发现功能作为快捷方式，手动输入IP作为兜底方案，两者共存，绝不强行依赖自动发现。

4. 通信协议设计：JSON报文、ACK确认与断线重连

4.1 为什么在STM32上用JSON而不是自定义二进制协议

这是一个很值得聊的设计决策。很多人一听"单片机"就觉得应该用紧凑的二进制协议，每个字节都要节省。但在这个项目里，STM32和上位机之间传的数据量极小——一条日程文本撑死几十上百个字节，WiFi带宽的浪费完全可以忽略。

用JSON的好处是实实在在的：

• 上位机用JsonSerializer.Deserialize<T>()一行代码就能把报文解析成对象，不需要自己写字节流的边界判断和字段拼接
• 调试阶段可以在PC上用网络调试助手直接发JSON文本测试设备逻辑，不需要额外写测试工具
• 加字段不用改协议版本，上位机和设备端对未知字段可以自动忽略
• 出问题的时候日志里打印的是可读文本，不是一串十六进制

STM32端解析JSON的开销也确实存在，但我实测过：cJSON库解析一条100字节的JSON报文，耗时在毫秒级，RAM开销看报文复杂度，几十到几百字节不等，F103C8T6完全可以承受。重要的是管理好解析对象的生命周期，这个我在第七章踩坑部分会详细说。

4.2 报文格式定义

整个通信协议分上行和下行两组，全部使用UTF-8编码的JSON，每条报文以换行符\n作为结束标志。

下行（上位机到STM32）的报文格式：

这里最关键的是id字段。设备端存储的每条日程都有一个唯一ID，上位机用它来标记删除和修改的目标。如果上位机同步时发现某条日程的ID在设备端不存在了，说明设备端可能已经被手动清空，需要做全量重新同步。

msg_id字段是每次命令的唯一编号，上位机用它来匹配ACK响应。比如上位机发送第8号命令，设备处理完就回一条msg_id:8的ACK，上位机才知道这条命令成功送达。

4.3 帧边界与粘包处理

TCP是流式传输，没有自带的消息边界。如果连续发送两条JSON命令，接收端可能会一次性收到两条拼在一起的字节流，也可能一条命令被拆成两段到达。这就是所谓的"粘包"和"半包"。

我的处理思路分两层：

第一层，在协议层用\n作为结束符。每条JSON报文的末尾强制加一个\n，接收方把数据累积到缓冲区，每检测到一个\n就认为前面是一个完整帧，交给解析器处理。这个方案简单可靠，JSON本身是文本格式，天然不会包含\n（字符串里如果有换行会被转义成\n两个字符）。

第二层，在STM32端结合串口空闲中断处理ESP8266的数据流。ESP8266每收到一次TCP数据，会输出+IPD,<channel>,<length>:<data>格式的内容，这个前缀和实际数据混在一起。如果用简单的循环读取方式，很容易把+IPD前缀和JSON内容拆散。最终的稳定做法是：串口DMA接收加IDLE空闲中断，把一帧完整数据交给解析函数，解析函数先识别+IPD前缀提取长度，然后取对应长度作为真正的数据帧。

4.4 ACK确认与超时重发机制

TCP协议本身保证了数据包能送到设备，但设备端"收到数据之后是否成功处理"是TCP保证不了的。比如设备端Flash写入失败、cJSON解析失败，TCP都会认为"数据已经送达"，但日程实际没有生效。

所以我加了应用层的ACK确认。上位机的每次写操作（添加、删除、清空、时间校准）都会带上唯一的msg_id，发送后启动一个3秒超时定时器。如果在3秒内收到对应的ACK，就认为处理成功；如果超时未收到，自动重发，最多重发3次；3次都失败则提示用户"设备响应超时，请检查连接"。

这个机制在开发调试阶段帮我抓到了好几个隐藏Bug，比如SYN6288播报时占用USART2会导致主循环短暂阻塞，如果这时刚好收到上位机的命令，ACK就会延迟。如果没有ACK机制，这种偶发问题根本没法定位。

4.5 心跳与断线重连

TCP连接在局域网内也会因为路由器NAT表老化、WiFi信号波动、设备休眠等原因莫名其妙断开。尤其是ESP8266在长时间没有数据收发时，路由器的连接追踪表会把这台设备的映射关系清掉。

心跳机制很简单：上位机和设备之间每30秒互发一次心跳报文（{"cmd":"PING"}和{"cmd":"PONG"}），连续2次没有收到对方的回应，就认为连接已断开，进入重连流程。设备端也会在长时间未收到心跳时主动关闭当前连接，回到Server监听状态，重新等待客户端接入。这一步很关键，如果不主动关闭，ESP8266的TCP连接资源会被僵尸连接耗尽，之后新连接就无法建立。

5. STM32端核心实现：ESP8266驱动、语音合成与RTC调度

5.1 串口资源分配与DMA加空闲中断的接收框架

这个项目里串口是核心外设，一共用到两路：

• USART1：接ESP8266，波特率115200，用于WiFi通信
• USART2：接SYN6288，波特率9600，用于语音合成交互

USART1的接收是整个系统最容易出Bug的地方。ESP8266的数据是异步到达的，可能是一条AT指令的回显，也可能是设备端主动上报的TCP数据，还可能是WiFi状态变化的通知，这些数据会混在同一个串口流里出现。如果只用简单的HAL_UART_Receive阻塞接收，主循环会被串口拖死。

我用的是DMA加空闲中断（IDLE）的方式。核心思路是：DMA接收数据时自动把字节搬运到内存缓冲区，当串口线路上出现一个字节时间的空闲（没有新数据进来）时，触发IDLE中断，此时DMA收到的就是一段完整的数据帧，交给解析函数处理。

关键代码片段如下（HAL库）：

void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size) { if (huart == &huart1) { // Size是本次接收到的有效数据长度 process_esp8266_data(uart1_rx_buffer, Size); // 重新启动DMA接收 HAL_UARTEx_ReceiveToIdle_DMA(&huart1, uart1_rx_buffer, UART1_RX_BUFFER_SIZE); } else if (huart == &huart2) { process_syn6288_data(uart2_rx_buffer, Size); HAL_UARTEx_ReceiveToIdle_DMA(&huart2, uart2_rx_buffer, UART2_RX_BUFFER_SIZE); } }

这里有一个重要细节：DMA接收的缓冲区大小要留够。ESP8266一条最大的AT指令回显（比如查询AP列表）可能超过256字节，我把USART1的缓冲区设为512字节。如果缓冲区太小导致DMA溢出，数据会覆盖，连+IPD的长度字段都可能解析错误。

5.2 ESP8266 AT指令的封装和连接状态机

ESP8266的AT指令如果直接在主循环里发一条等一条，整个系统的实时性会很难看。我封装了一个简单但够用的状态机：

typedef enum { WIFI_POWER_ON, // 上电等待ready WIFI_SET_MODE, // 设置Station模式 WIFI_JOIN_AP, // 连接路由器 WIFI_GET_IP, // 获取IP地址 WIFI_START_SERVER, // 开启TCP Server WIFI_SERVER_READY, // 服务器就绪 } wifi_state_t;

每个状态对应一条或一组AT指令，发送后等待回复，超时则重试，重试次数到达上限就进入错误处理。举例来说，WIFI_JOIN_AP状态发送AT+CWJAP="ssid","password"，正常情况下会回WIFI CONNECTED然后回OK，如果密码错误会回FAIL，如果路由器不在线会回ERROR。

这里最大的坑是AT指令的回复不是原子的。比如AT+CIFSR查询IP地址，返回的是两行内容：

AT+CIFSR +CIFSR:STAIP,"192.168.1.100" +CIFSR:STAMAC,"xx:xx:xx:xx:xx:xx" OK

如果按"收到OK就算结束"的逻辑，你拿到的缓冲区里确实是完整的，但如果按"发完指令等固定时间"的逻辑，可能只读到前一半。所以我的解析策略是：从收到数据开始启动超时定时器（比如3秒），在超时之前持续累积数据，直到收到OK、ERROR、FAIL等结束标志才认为一条AT指令执行完毕。

还有一个实际经验：ESP8266上电后第一次发AT指令往往会失败。因为模块内部ROM启动需要时间，串口可能还没准备好。所以我的代码里上电后会先延时1秒，然后尝试发送AT指令，收到OK之前最多重试5次，每次间隔500ms。

5.3 时间校准：用上位机当NTP服务器

日程表最核心的准确性来自时间。DS3231虽然精度高，但如果纽扣电池没电或者板子断电很久，时间就漂了。既然设备已经连着WiFi，自然应该联网自动对时。

最初我考虑用ESP8266直接像NTP服务器发起UDP查询，但实践下来有两个问题：首先，ESP8266的AT指令模块处理UDP需要额外建立连接，而UDP在AT指令模式下没有可靠的"接收完成"标志，非常容易丢包；其次，很多公司的网络会封掉NTP常用的123端口，导致对时失败。

我换了一个更务实的思路：让上位机充当时间源。设备开机建好TCP Server后，主动向上位机发送REQ_TIME命令，上位机收到后把当前Unix时间戳（设备上电时的编译时间和DS3231的差值可以通过首包校准）通过SYNC_TIME命令下发。设备端用这个Unix时间戳直接写入DS3231的寄存器，完成对时。

这个方案的精度取决于上位机到设备之间的网络延迟，在局域网环境下延迟通常小于1毫秒，对日程表的秒级精度完全够用。而且好处是上位机的时间就是PC系统时间，用户看到的时间和自己电脑上完全一致，不会有"设备时间和电脑时间差8小时"这种乌龙。

5.4 SYN6288语音合成驱动与GBK编码问题

SYN6288的驱动协议比ESP8266还简单，只关注一个数据帧格式：

比如要播报"你好"，拼出来的帧长是：帧头1字节 + 长度2字节 + 命令字1字节 + 编码格式1字节 + 文本4字节（"你好"在GBK里是4字节）+ 校验1字节，总长10字节。

这里最折磨人的是编码问题。STM32端收到的是上位机传来的UTF-8编码JSON文本，但SYN6288只认GB2312/GBK编码。如果在STM32端做UTF-8到GBK的转换，需要内置一张完整的码表，光这张表就要占几十KB的Flash，而且F103C8T6的Flash空间本来就不宽裕。

我最终的解决方式是：编码转换放在上位机完成。上位机在发送日程下发命令之前，先把JSON里的text字段从UTF-8转成GBK十六进制字符串，比如"你好"变成C4E3BAC3，然后通过{"cmd":"ADD","text":"C4E3BAC3"}下发。STM32端解码这个十六进制字符串变成字节数组，直接塞进SYN6288的帧里。这样STM32完全不需要做编码转换，上位机的Encoding.GetEncoding("GB2312")一行搞定。

5.5 日程存储设计与到点触发调度

日程存储在W25Q32上的数据结构我设计成一个简单的块表结构：

• 扇区0：存储头部信息，包括魔数（0xA5A5）、日程总条数、最后修改时间
• 扇区1到N：每条日程128字节，按顺序存储

每条日程的128字节包含：ID（4字节）、时间戳（Unix格式，4字节）、播报状态（1字节）、文本长度（2字节）、文本内容（UTF-8 最多115字节）。文本内容限制在115字节以内能覆盖绝大多数中文日程，一条"明天上午十点和客户开产品评审会，记得带上周发出去的需求文档"大约40个汉字，在GBK下是80字节，完全放得下。

到点触发的调度逻辑在主循环的1秒定时器里执行：

• 读取DS3231的当前时间
• 遍历存储区所有日程
• 如果某条日程的时间戳与当前时间的分钟数匹配，并且当天没有被播报过，就触发语音播报
• 播报需要提前看当前时间是否在日程设定时间的前后5分钟窗口内，避免因为设备启动晚导致漏报

这里有个细节：日程的重复模式。我的repeat字段设计为0表示不重复，1表示每天重复。不重复的日程播报过一次之后就把播报状态置为已播报标记，存入Flash；重复的日程每次到点都会播报，不受已播报标记限制。

6. 上位机实现细节：WPF界面、设备发现与天气接口

6.1 WPF界面布局

上位机UI我按"左列表右编辑"的模式布局，整体分四个区域：

顶部是连接状态栏，显示设备IP地址、连接状态、心跳状态，旁边是"连接/断开"按钮和"自动发现设备"按钮。主区域左侧是一个DataGrid日程列表，每一行显示日程时间、文本内容、重复模式、播报状态。右侧是一个编辑面板，包含时间选择器、文本输入框、重复模式勾选框，以及"添加""修改""删除"三个按钮。底部是一个日志输出框，实时显示网络收发和错误信息。

界面逻辑用MVVM模式写，但不需要引入完整的MVVM框架，我手动实现了INotifyPropertyChanged，日程集合用ObservableCollection，这样新增或删除日程时表格会自动刷新。

6.2 TcpClient连接与设备自动发现

网络连接部分用System.Net.Sockets.TcpClient封装了一个DeviceClient类，核心方法包括：

• ConnectAsync(ip, port): 异步连接设备，带3秒超时
• SendCommand(json): 发送一条JSON命令，生成msg_id并启动ACK超时重发任务
• OnDataReceived: 后台线程持续读取数据流，按\n切分完整报文，交给消息分发器
• HeartbeatLoop: 每30秒发送一次PING

设备自动发现通过UdpClient实现。上位机启动时在一个后台线程里监听1900端口，接收UDP广播包，如果报文内容包含"STM32-SCHEDULER"关键字，就把来源IP地址提取出来，自动填入IP输入框并尝试连接。

6.3 日程编辑与全量同步策略

上位机编辑日程采用"本地编辑、手动同步"的策略，不搞自动实时推送。因为自动推送会导致用户在打字过程中设备就收到半截内容，反而容易出错。

具体流程是：用户在编辑面板输入日程内容，点"添加"后日程加入本地列表；所有改动完成后点"同步到设备"按钮，上位机遍历本地列表，与设备端已有的日程ID做比对：

• 本地有而设备没有的，发送ADD命令
• 本地没有而设备有的，发送DEL命令
• 两边都有但内容不同的，发送ADD命令覆盖

每次发送后都要等ACK，收到确认才发下一条，进度条显示同步进度。如果设备端返回result:1（表示处理失败），上位机立即停止同步并弹窗提示哪一条出了什么问题。

6.4 天气信息播报的实现

这个功能是后来加上的，做法是上位机调用一个免费天气API（我用的是和风天气的免费版，也有高德和心知天气可选），获取当前城市当天的天气状况和最高温度，然后拼成一句播报文本，通过WEATHER命令下发到设备，设备会立刻用SYN6288播报出来，比如"今日天气晴，气温18到25度，早晚温差较大，注意添衣"。

天气接口在上位机实现而不是STM32直接访问，一是因为JSON解析和网络请求在PC上做太轻松了，二是因为天气API的Key放在设备端容易被刷，放上位机至少安全一些。天气数据的刷新策略是每天早上6点自动拉取一次，用户也可以手动点"刷新天气"按钮。

6.5 关于AI辅助生成上位机代码的经验

热搜词里有个"ai写上位机软件有哪些"，这里聊聊我的实际体会。这个项目的上位机界面代码，我确实用了AI辅助生成，比如DataGrid的列定义、XAML布局样式、TcpClient的连接模板，这些模型训练数据里到处都是，AI生成的代码质量不错。

但通信协议状态机、ACK超时重发逻辑、设备发现处理这些有业务状态的部分，AI生成的东西基本都不能直接用，需要自己理清楚状态转移再手动写。我建议的用法是：让AI生成UI骨架和通用的网络模板，你自己负责协议解析和业务逻辑。千万别把整个"发送JSON、等ACK、超时重发、失败处理"的流程交给AI，它生成的代码十有八九会在异常处理上有漏洞。

7. 联调排错实录：四个必踩的坑和定位过程

7.1 坑一：UTF-8中文在SYN6288上变成乱码

现象：上位机下发"早上好"，设备端播出来是"鏃╀笂濂"。

排查路径：刚开始我怀疑SYN6288的接线有问题，或者波特率不对，用串口调试助手直接给SYN6288发固定文本，发现完全正常。这就说明问题出在这个项目的数据链路上。再用网络调试助手直接连ESP8266的TCP端口发同样的JSON，发现设备端播报照样乱码。最后我用十六进制打印设备端实际收到的JSON数据，发现上位机发出来的text字段内容，在设备端收到后显示的十六进制是UTF-8编码，而SYN6288只认GBK。

结论和解决：编码转换必须在上位机完成，STM32端只做十六进制解码透传。具体实现我前面提到过，上位机把text字段从UTF-8转成GBK字节数组，再转成十六进制字符串放入JSON，STM32端解析这个字符串变成字节数组，直接组装进SYN6288帧。这个坑我非常确定人人都要踩一次，因为UTF-8和GBK的编码差异在纯PC端开发时根本感知不到，只在嵌入式端对接外设时才暴露。

7.2 坑二：cJSON在STM32上频繁解析导致内存碎片

现象：设备运行一段时间后，收到上位机的日程下发命令时偶尔会重启，或者无响应，但串口打印里没有任何异常信息。

排查路径：先怀疑是看门狗超时，加了一堆调试日志，发现重启前Flash写入失败。再往前查，发现是内存分配失败导致空指针，程序解引用后就HardFault了。为什么会内存分配失败？因为ESP8266每帧数据到达后，我都在process_esp8266_data里直接调用cJSON_Parse创建新对象，解析完再cJSON_Delete释放。这个操作每来一帧就做一次，而cJSON底层用的是malloc/free，频繁地小块分配和释放导致堆内存碎片化，跑一段时间后明明剩余总内存还够，但无法分配出一块连续的缓冲区。

结论和解决：两个措施。一是把cJSON的malloc和free替换成固定大小的内存池，即用cJSON_InitHooks配置一个静态数组作为堆空间；二是在主循环里把解析操作集中处理，避免在中断回调里频繁动态分配。改完之后跑了一整天的压力测试，内存稳定在固定水位。

7.3 坑三：路由器AP隔离导致上位机连不上设备

现象：在家里路由器下联调一切正常，换到公司无线网或访客网络，上位机提示"连接超时"，设备端OLED却显示WiFi已经连接成功，IP也正常。用手机热点做测试也是一样的问题。

排查路径：一开始怀疑是ESP8266的TCP Server有没有真正开启，反复检查AT指令回显都正常，端口也在监听了。后来在PC上用ping设备的IP，完全不通过，但设备又能正常访问外网（说明它能连上WiFi网关）。这时候我才意识到，这是典型的**无线客户端隔离（AP Isolation）**问题——很多路由器或AP会把连接到同一个WiFi的设备互相隔离，禁止它们直接通信。设备能上外网，但设备到PC的局域网通路被切断了。

结论和解决：测试阶段直接开手机热点，或者把路由器里的"AP隔离"开关关掉。这不是设备的问题，是网络环境的问题。排查这类问题时，先用ping验证二层和三层的连通性，如果设备能拿到IP但互相ping不通，九成是AP隔离。

7.4 坑四：ESP8266断线假死，TCP连接被僵尸连接占满

现象：设备长时间运行后（一到两天），上位机显示"连接失败"，设备端的OLED显示WiFi正常，但TCP Server好像完全没反应。重启ESP8266模块之后一切恢复正常。

排查路径：进ESP8266的串口调试界面看状态，用AT+CIPSTATUS查询连接状态，发现有好几条4状态（表示TCP连接已建立但实际对端已经消失）。这些就是"僵尸连接"。原因是ESP8266的TCP Server在客户端异常退出时（比如PC睡眠、崩盘、网线拔掉），不能及时感知连接关闭，连接一直挂在那里。当所有可用的连接槽位被占满后，新的客户端就无法接入。

结论和解决：在设备端加一个资源清理机制。每次收到心跳超时或者长时间没有数据交换，就主动关闭最早的那个空闲连接。另外在上位机端保证每次断线重连时，客户端先主动关闭旧Socket实例，不要新开连接而不关旧的。改完之后，设备连续运行了一周没有再出现"连接不上了"的问题。

7.5 排错速查表

这些坑单拎出来每个都花了我不少时间，但排查思路都是通用的：先定位问题发生在通信链路的哪一环，再缩小范围到具体模块，最后用最细粒度的日志和打印来确认根因。嵌入式的调试就是这样，耐住性子一层层剥。

这个项目做完后，我最大的感受是：把STM32、WiFi模块、语音芯片、上位机这些独立技术点串成一个完整的闭环，比单独调通任何一个外设都要有价值。过程中遇到的所有问题都发生在"模块之间的接口处"，而不是模块本身。也正是这些接口处的问题，才真正锻炼了排查和设计能力。你可以在这个框架上继续扩展，比如把上位机改成网页版，手机浏览器直接访问设备管理日程；或者用ESP32替代STM32加ESP8266的组合，体积更小功耗更低；也可以把播报内容接入AI大模型，让设备每天早上根据日程自动生成一句提醒语。这个项目的后续空间还很大，希望我的实践过程能让你少走几步弯路。

本文还有配套的精品资源，点击获取