基于STM32与迪文屏的智能家居控制面板设计与实现

今年给客户做一套智能家居环境控制面板，需求其实不复杂：实时显示房间温湿度，能手动设定目标温湿度，再根据设定值自动控制加热器、加湿器和排风扇。刚开始我一度想用STM32裸驱一块彩色LCD，把UI、触摸、字体全自己搞定，结果做到一半就发现状态切换、菜单跳转这些工作远比想象中费时间。换用迪文屏+DGUS之后，界面开发直接从“写代码”变成了“画界面”，STM32这边只需要管串口收发和控制逻辑，整个项目节奏完全不一样了。这篇文章就把从选型到落地的完整过程写出来，包括DGUS界面怎么搭、STM32怎么和屏通信、联动控制逻辑怎么写，以及调试过程中踩过的坑，给正在做智能家居项目、毕业设计，或者想快速给产品配一套人机界面的同学做个参考。

1. 为什么是迪文屏+DGUS：一次选型复盘

1.1 项目要解决的核心问题

先说我手里这个需求。控制面板必须做的事情有四件：

• 实时显示温度和湿度，并且带小数位；
• 允许用户直接设定目标温度；
• 一键切换自动/手动模式；
• 显示加热器、加湿器、排风扇各自的当前运行状态。

这些功能单独拎出来都不难，但凑到一起，对UI的要求就上来了。既要多个数字实时刷新，又要有触摸交互，还得表达设备状态。用OLED滚动显示信息量不够，用LCD自己写菜单又得维护一大套状态机。这才是这个项目真正的难点所在——它不是算力问题，而是人机交互的开发效率问题。

1.2 三种人机交互方案的对比

我先后评估过三条路线，各有各的适用场景。

第一，OLED或者LCD1602。这俩优点是便宜，缺点是信息量太小，只能显示数字和简单符号，触摸更不用想，用户交互只能靠物理按键。如果面板只是放一两个温度数字，这条路完全够用。

第二，STM32直接驱动彩色LCD，再移植LVGL或者自己写UI。这条路线自由度最高，但工作量也最大。字体、图标、触摸校准、菜单状态机全都要自己搞，STM32F103这种小内存芯片跑LVGL会比较吃力，图片资源还得压缩处理，一旦做到多页面切换，代码量能翻好几倍。

第三，串口屏方案，其中迪文屏+DGUS是性价比比较高的选择。屏幕端的UI、图片、字库、控件逻辑全部在PC端软件里完成，生成一个DWIN_SET文件夹下载到屏上就生效。STM32这边只需要往指定的变量地址写数据、读取用户按键值，不需要关心屏幕坐标、字体、图片这些事。

三条路线我最终选了第三条，核心原因是开发成本和视觉效果的平衡。客户要的是“看起来像产品”，不是“看起来像开发板”。迪文屏可以直接导入现成的素材做界面，MCU里完全不需要存图片数据，这对STM32F103这种资源紧张的平台特别友好。

1.3 什么项目适合这套方案

得说清楚，不是所有项目都该无脑上串口屏。如果界面只有一两个数字、几个按键，OLED加物理按键反而更简单、更省成本。但如果界面信息量大、需要触摸设置参数、需要多页面切换，迪文屏的价值就很明显了。智能家居控制面板、环境监测终端、工业小HMI，这类场景都很匹配。

把界面开发从单片机工程里剥离开，本质上是在把开发精力放回真正的业务逻辑上。毕竟控制策略、传感器采集、设备联动才是这类项目的核心，UI只是壳。

2. 系统总架构与硬件选型：STM32、SHT30、继电器和电源

2.1 数据流链路

整个系统的数据流用一句话就能说清：SHT30采集温湿度，STM32换算成物理值，通过串口写到迪文屏的变量地址，屏幕控件自动刷新；用户触摸面板设置目标值，屏把键值或输入值通过串口发给STM32，STM32执行控制逻辑，再把执行状态写回屏上。

这个“变量地址”机制是整个DGUS的命根子，后面单独讲。硬件上最关键的就是把这条链路上的每一环选对，否则后面全是坑。

2.2 主控选型：STM32F103C8T6就够了

主控我用了STM32F103C8T6。原因很直接：这个项目不需要跑复杂算法，不需要很大内存，外设需求就是一路串口、一路I2C、一路PWM加上几个GPIO，C8T6资源完全够用，而且资料多、成本低、无论是CubeMX还是标准库都顺手。用F407甚至F103RCT6也可以，逻辑完全一样。

CubeMX配置要点：

• RCC选择外部晶振；
• SYS里的Debug选择Serial Wire，不然第二次烧录会报找不到芯片；
• USART1：115200-8-N-1，接迪文屏；
• I2C1：标准模式100kHz，接SHT30；
• 若干GPIO输出，接继电器和MOS；
• TIM2_CH1输出PWM，控制排风扇。

这里有个细节要提醒：Debug配置很多人会漏。如果选了No Debug，Keil下载两次之后就提示连接不上芯片，只能把BOOT0拉高擦除整个Flash再拉回来，非常折腾。新建工程时直接选Serial Wire，能省掉这一整段麻烦。

2.3 温湿度传感器：SHT30 还是 DHT22

温湿度传感器我直接选了SHT30。不推荐DHT11，也不推荐DHT22，原因很现实。

DHT11精度太差，温度±2℃，湿度±5%RH，只能算“有数据”，不能算“准确数据”，做控制面板根本没法看。

DHT22精度稍好，温度±0.5℃，湿度±2%RH，但它走的是单总线协议，时序要求非常严格。主机需要精确到微秒级的拉低、释放、采样，在HAL库环境下稍不注意就被中断打断，读出来的数据全错。网上大量“DHT22读取失败”的问题，根因基本都是这个。

SHT30是I2C接口，带CRC校验，精度±0.3℃，读取逻辑简单可靠。唯一的缺点就是价格比DHT系列高几块钱，但这点差价相比后期排查通信问题省下来的时间，太值了。

SHT30读取代码片段：

static uint8_t sht30_crc(uint8_t *data, uint16_t len) { uint8_t crc = 0xFF; while (len--) { crc ^= *data++; for (uint8_t bit = 0; bit < 8; bit++) { crc = (crc & 0x80) ? (crc << 1) ^ 0x31 : (crc << 1); } } return crc; } void sht30_read(float *temp, float *hum) { uint8_t cmd[2] = {0x2C, 0x06}; uint8_t buf[6]; HAL_I2C_Master_Transmit(&hi2c1, 0x44 << 1, cmd, 2, 100); HAL_Delay(50); HAL_I2C_Master_Receive(&hi2c1, 0x44 << 1, buf, 6, 100); if (sht30_crc(buf, 2) != buf[2] || sht30_crc(buf + 3, 2) != buf[5]) { return; } uint16_t tr = (buf[0] << 8) | buf[1]; uint16_t hr = (buf[3] << 8) | buf[4]; *temp = -45.0f + 175.0f * tr / 65535.0f; *hum = 100.0f * hr / 65535.0f; }

CRC校验千万别省。I2C总线在继电器动作、电源波动时容易产生干扰，如果读到错数据还拿去控制继电器，后果很严重。SHT30的数据帧正好自带CRC，校验通过才使用，不通过就丢一次采样，反正采集周期很快。

2.4 执行器件和电源设计

执行器件分三路：

• 加热器：一路继电器控制220V加热设备；
• 加湿器：一路继电器控制加湿器；
• 排风扇：NMOS驱动12V风扇，MCU输出PWM调速。

继电器一定要选带光耦隔离的模块，同时在线圈两端加续流二极管。继电器线圈是感性负载，断电瞬间会产生反向电动势，如果不加吸收，打坏单片机引脚是常有的事。

PWM频率建议设在10kHz到25kHz之间。太低了风扇会啸叫，那声音和蚊子叫差不多，晚上放卧室客户肯定投诉。我实际用20kHz，听不到噪音，驱动也稳。

电源部分，整个系统用12V适配器输入，12V直接给风扇，5V给继电器模块，3.3V给STM32和传感器。迪文屏的供电电压要看具体型号，有的是3.3V有的是5V。系统统一共地，屏和主板之间必须共地，否则串口的电平参考点都不一样，数据必乱。

3. DGUS工程搭建：从一张底图到可交互面板

3.1 先理解变量地址机制

DGUS最核心的概念是VP变量地址。屏幕上的数值、开关、图标这类控件，在DGUS软件里都会绑定一个16位变量地址，比如0x1000。MCU往这个地址写数据，屏幕上的控件就会自动更新显示；用户触摸屏幕上的输入控件，屏幕也会把结果写到指定地址。

这个思路非常像PLC里的寄存器。好处就是MCU完全不用关心屏幕在哪个坐标画了什么东西，只需要往指定地址读写数据就行，UI和业务彻底解耦。

我自己的工程地址规划如下：

这个表是整个工程的地图。实际项目里地址可以随意规划，但强烈建议在Excel里建一张地址分配表，避免前后控件叠加覆盖。DGUS界面里如果两个控件绑了同一个地址，显示会互相干扰，这种问题在PC端预览时看不出来，只能靠地址表排查。

3.2 素材准备与控件布局

界面素材我用Photoshop做了一张800x480的背景底图，分辨率必须和屏幕一致。底图上把固定的标题、文字、边框全部画好，动态内容留空，然后在DGUS软件里叠加动态控件。

具体控件配置：

• 实时温度：放一个“数据变量显示”控件，变量地址0x1000，数据类型选有符号整数，整数位数2，小数位数1，单位填“℃”。DGUS里所有变量本质都是整数，不支持浮点，所以小数必须自己放大10倍再传输。23.4℃在协议里发234，屏上显示23.4。如果你把浮点数直接发过去，那就干脆显示乱了。
• 目标温度：用“数据变量输入”控件，绑定0x3000，同样放大10倍。用户点击这个区域，屏会弹出数字键盘，输入结果自动写进0x3000，STM32周期读取这个地址即可。
• 模式切换：用“按键值返回”控件，绑0x2000，键值填1，勾选“自动上传”。这样用户按下时，屏幕会自动给MCU发一帧数据，MCU不需要主动查询。
• 状态图标：用“位图标”控件，绑定0x4000，分别配置bit0、bit1、bit2对应加热器、加湿器、排风扇的开和关两种图标。

布局上，我习惯把温度湿度放在屏幕中上部，一眼能看到；目标温度和模式按钮放在中下部，符合操作习惯；状态图标放在底部，不抢视觉焦点。

3.3 生成DWIN_SET并下载到屏

DGUS软件里工程编辑完成后，点击生成，所有资源会被打包成一个DWIN_SET文件夹。把这个文件夹整个拷贝到TF卡根目录，插到屏背面的卡槽，重新上电，屏幕会自动烧录，烧完有进度提示。等界面变成新工程，断电拔卡就完成了。

这里有三个坑必须注意：

• TF卡必须是FAT32格式，NTFS不识别；
• DWIN_SET里的文件名不要改，改一个字母都可能下载失败；
• 下载完成后最好把卡拔掉或清空，否则下次上电还会重复烧录，浪费时间。

3.4 三个容易忽略的设置

第一个是波特率。DGUS工程的串口波特率默认常见是115200，但不同固件版本可能有差异，最好在软件里确认。波特率不一致的表现很典型：STM32发指令屏完全没反应，但屏自身显示正常。用串口助手先发一帧验证，要比直接接单片调快得多。

第二个是触摸校准。部分屏出厂时触摸没有校准，点击位置偏得离谱。CFG配置里有一项触摸校准，开启后下载，屏会进入校准界面，点击十字校准点完成后再关闭该项下载一次，免得每次开机都进校准。

第三个是数据变量输入控件需要配套的键盘资源。有些DGUS版本里输入控件自带的键盘库不全，没有键盘底图和GUI配置，SD卡下载时会提示缺文件。开发前先打开示例工程，把键盘相关文件一并放到DWIN_SET里。

4. STM32与迪文屏的通信落地：0x82/0x83指令与驱动代码

4.1 最小指令集

DGUS串口协议帧格式很简洁：帧头5A A5，然后是长度、指令、参数。

写变量用0x82指令，格式如下：

5A A5 [Len] 82 [Addr_H] [Addr_L] [Data_H] [Data_L]

Len表示从指令字节开始到帧尾的字节数。写一个16位数据，Len就是05。

读变量用0x83指令：

5A A5 04 83 [Addr_H] [Addr_L] 01

最后的01表示读取一个字（16位）。屏收到后回复：

5A A5 06 83 [Addr_H] [Addr_L] 01 [Data_H] [Data_L]

注意，所有数据都是大端格式，高字节在前。这个点我踩过坑，有一段时间把所有数据高低字节写反，结果26.5℃显示成91.0℃，排查了半天才发现是字节序问题。

4.2 发送驱动：向屏写入实时温湿度

STM32侧写一个串口发送函数就够了：

void dgus_write_word(uint16_t vp, uint16_t value) { uint8_t frame[8]; frame[0] = 0x5A; frame[1] = 0xA5; frame[2] = 0x05; frame[3] = 0x82; frame[4] = vp >> 8; frame[5] = vp & 0xFF; frame[6] = value >> 8; frame[7] = value & 0xFF; HAL_UART_Transmit(&huart1, frame, 8, 50); }

实际使用时，温度计算完要立即放大10倍并转换成整数。负温度要处理成补码，比如-5.0℃对应-50，强转成uint16_t之后是0xFFCE，直接发过去，屏上有符号显示控件会自动显示成-5.0。

主循环里每500ms刷一次：

sht30_read(&temp, &hum); uint16_t temp_x10 = (uint16_t)(int16_t)(temp * 10.0f); uint16_t hum_x10 = (uint16_t)(hum * 10.0f); dgus_write_word(0x1000, temp_x10); dgus_write_word(0x1001, hum_x10);

刷新周期不用太短，屏幕控件本身刷新不过来，500ms肉眼完全够用，还能降低串口负载。

4.3 接收解析：读取目标温度和按键值

目标温度的读取，我配置的是屏上按钮按下后自动上报，而不是MCU周期性发0x83去查。前者响应快，实现也简单。按键值返回的上报帧不同固件略有差异，典型的格式是：

5A A5 [Len] 81 [VP_H] [VP_L] [键值_H] [键值_L]

具体字节序以你手上屏对应的《开发指南》为准。MCU端接收我用一个最简单的状态机，串口中断收字节进数组，主循环里按帧头找、按长度截帧。

void uart_rx_handler(uint8_t byte) { static uint8_t rx_buf[16]; static uint8_t idx = 0; rx_buf[idx++] = byte; if (idx == 2 && !(rx_buf[0] == 0x5A && rx_buf[1] == 0xA5)) { idx = 0; } if (idx >= 3 && idx == (rx_buf[2] + 3)) { parse_dgus_frame(rx_buf, idx); idx = 0; } }

逻辑很直白：前两字节不是5A A5就清空重来，收满“长度字段+3”个字节当作一帧处理。这种固定短帧协议用这个状态机足够，不用上复杂的环形缓冲区。

parse_dgus_frame里面根据指令类型分流：

• 0x81按键上报，看键值，切换自动/手动模式；
• 0x83读变量回包，取目标温度数据，存进全局变量set_temp_x10。

4.4 通信链路自检

新板子第一次调试，别急着写完整逻辑。先用USB转TTL模块把屏接到电脑串口助手，手动发一帧：

5A A5 05 82 10 00 00 64

如果0x1000绑定的温度控件显示100，也就是10.0℃，说明屏和协议都没问题。如果没反应，先检查波特率，再检查屏的接口是TTL还是RS232。很多串口屏背面同时有TTL排针和RS232插座，接错就完全不通。

确认屏端正常后再接STM32。把STM32的TX接到屏的RX，发一帧心跳帧，看屏是否响应。这样一层一层剥离，能快速定位是电平问题、波特率问题还是代码问题。

5. 联动控制逻辑：从“屏上显示”到“自动化控制”

5.1 目标温度下发与滞回控制

用户通过屏设置目标温度后，0x3000里就是用户输入值放大10倍的整数。STM32周期读取这个地址，得到目标值set_temp_x10。

温度控制我用滞回区间，而不是等号直接比较。比如目标22.0℃，实际温度低于21.0℃打开加热器，高于23.0℃关闭加热器。这种设计主要防止继电器在目标值附近频繁吸合。继电器机械寿命和触点火花都在这个设计下得到明显改善。

float set_temp = set_temp_x10 / 10.0f; if (!heater_state && temp < set_temp - 1.0f) { heater_state = 1; HAL_GPIO_WritePin(HEATER_GPIO_Port, HEATER_Pin, GPIO_PIN_SET); } else if (heater_state && temp > set_temp + 1.0f) { heater_state = 0; HAL_GPIO_WritePin(HEATER_GPIO_Port, HEATER_Pin, GPIO_PIN_RESET); }

滞回宽度设1℃比较合适。太窄继电器依然会频繁动作，太宽温度波动会很明显。

5.2 湿度联动与PWM风扇调速

除湿部分我用排风扇处理。湿度超过设定值加10%时开启排风扇，低于设定值则关闭。同时温度控制里如果温度过高，排风扇也可以按比例调速，把风量跟温差做线性映射：

uint16_t duty = 0; if (temp > set_temp + 1.0f) { float diff = temp - (set_temp + 1.0f); if (diff > 3.0f) diff = 3.0f; duty = (uint16_t)(diff / 3.0f * 800.0f); } __HAL_TIM_SET_COMPARE(&htim2, TIM_CHANNEL_1, duty);

PWM频率设20kHz，占空比按0到1000算。这里有个细节：排风扇和加热器要加互斥逻辑。加热器开启期间，排风扇只保留基础换气占空比，不能一边疯狂加热一边猛烈排风，否则系统会陷入震荡，温度永远控制不住。

5.3 状态回显：让屏实时反映控制结果

控制状态必须实时回显到屏上，让用户看到自动控制到底在做什么。前面在DGUS里设计了0x4000作为设备状态位图标地址，STM32每200ms拼一次状态字写过去：

uint16_t status = 0; if (heater_state) status |= 0x01; if (humidifier_state) status |= 0x02; if (fan_on) status |= 0x04; dgus_write_word(0x4000, status);

这样屏上的加热器、加湿器、排风扇图标会跟着实际IO状态切换，实现“面板所见即设备所得”。做产品时这个细节很重要，用户能直观看到系统在响应自己的操作，使用感受完全不一样。

5.4 控制逻辑的抗干扰处理

我的处理方式有三条：

• 传感器连续两次CRC失败就保留上次数据，不更新显示，避免屏上数字乱跳；
• 继电器状态改变后加50ms延时，等IO稳定再回传状态；
• 串口读取目标温度加超时保护，连续3秒通信异常就自动切回手动模式并关闭所有执行器，保证安全。

这些不是花架子。智能家居设备如果通信卡死，执行器停在开启状态，轻则浪费电，重则出安全事故。通信异常即停止执行，是这类设备控制逻辑的底线。

6. 调试与量产前的避坑清单

6.1 屏上显示0或者满量程

现象是温度区域显示0.0，或者直接显示整屏最大值。

排查思路有两个方向。先用串口助手往那个地址发固定值，比如发0x03E8也就是1000。如果显示0，说明地址或者控件类型没对上；如果显示100.0，说明MCU发送链路有问题。然后再从MCU侧打印实际发送的帧，看长度和字节序。我自己遇到过把帧长度字段写错的，屏端直接丢弃整帧，看起来就像“屏幕没收到数据”。

另外有个不常见但很坑的：数据变量显示控件的位数配置不够。比如整数位设了2位，结果数值超过99，屏上会显示0或者最高位丢失。数值范围和显示位数一定要在开发时留足余量，不然客户把温度设到30℃，屏上直接变0，那场景极度尴尬。

6.2 触摸没反应或者配置没生效

先别怀疑屏坏了，多数情况是这几类：

• 工程没有真正下载成功。SD卡不是FAT32，或者文件没有放进DWIN_SET文件夹；
• 按键值返回控件里没勾“自动上传”，导致屏不主动发数据；
• MCU串口解析状态机被坏帧卡死。我最初那版状态机在连续噪声下一直清零重来，后来改成“最多8字节没有找到有效帧头就强制复位”，问题就消失了。

还有一个容易被忽略的：有些屏烧录完成后必须重新断电再上电，触摸和串口配置才生效。热插拔SD卡不算一次完整上电，很多人在这里反复折腾。

6.3 通信不稳定与静电干扰

继电器开关的瞬间，单片机偶尔死机或者串口数据乱码，根源通常是电源地线太细，以及继电器模块没有光耦隔离。继电器线圈通断产生反向电动势，通过地环路干扰串口信号，这是最常见的干扰路径。

解决方案：

• 继电器模块选带光耦的；
• 控制板铺地，继电器供电和单片机供电之间做好单点连接或者加磁珠；
• 屏和主板之间的串口线尽量短，双绞线更好；
• 如果产品要过EMC测试，串口线上加TVS管。

这些措施看起来基础，实际量产中全是血泪教训。室内智能家居环境还好，如果面板靠近大功率设备，干扰会非常明显。

6.4 踩完这些坑之后我的建议

如果让我重新做一遍，我会在硬件上直接把迪文屏的供电和主板分开，只共地，避免屏的背光电流波动影响单片机的供电稳定性。软件上，我会把DGUS地址规划表做成一个头文件，所有地址用宏定义，而不是散落在代码各个角落，后期维护和排查会舒服很多。控制策略先跑纯软件仿真，把滞回参数调好再接真实执行器，安全又高效。

最后分享一个提升调试效率的小技巧：迪文屏和STM32联调时，在串口线上挂一个逻辑分析仪，比在MCU里printf加日志更省事。逻辑分析仪能看到每一帧实际从串口线上传输的电平和数据，用来判断是哪一方没发、帧内容对不对、字节序是否正确，基本一眼就能定位问题。设备已经跑起来的场合，这个技巧更是救命。