简介面向嵌入式开发者的STM32与迪文DGUS屏串口通信实操例程主要解决工业控制、智能家居等项目中主控与显示模块的数据交互问题。资源包共998个文件、16.59MB包含大量C源文件、头文件、汇编源文件以及链接脚本、工程配置文件、固件烧录文件、界面位图和辅助脚本覆盖源码阅读、工程编译到固件下载的完整流程。例程基于硬件抽象层库演示串口初始化与参数配置、标准发送接收接口完成数据帧交换、按迪文协议构造与解析数据包帮助理解主控如何驱动屏显示和响应触控同时结合变量配置、触控配置及界面位图展示界面素材与通信数据结构的对应关系。调试方面提供串口打印或调试助手监视收发数据的思路可快速定位波特率不匹配、帧格式错误等问题。目前已有3507人学习下载适合首次接触迪文屏幕的嵌入式开发者也适合需要快速集成人机界面的工程师直接参考移植。 我最早接触迪文屏是从一个挺朴素的需求开始的手头接了个小项目要做一个带彩色显示和按键交互的控制器显示界面还得能反复改、改完立刻让现场的人有信心不能天天重刷单片机程序。市面上方案不少最后我拿到手的就是这个“02、STM32与迪文屏通信例程”式的工程包——核心就是用一片STM32串口驱动迪文串口屏实现变量显示和按键上报。这个“屏-MCU”通信模型弄明白以后后面不管是接温湿度传感器、做指令下发还是做报警弹窗都只是往里填函数的事。这篇文章我就把这个例程里真正关键的东西——DGUS协议、串口收发、屏端组态、常见坑——按我实际调通的顺序重新梳理一遍。适合刚接触迪文屏、手里有STM32开发板和一套迪文屏的开发板想尽快跑起通信的人也适合被“屏上数据不刷新”“返回乱码”这类问题卡住的老哥。1. 方案选型为什么是“STM32 迪文串口屏”的组合1.1 迪文屏的本质屏不是用来“点”的是用来“读写变量”的很多从8080接口、RGB屏、SPI屏转过来的朋友第一次接触迪文屏容易懵它到底是一个屏还是一个MCU答案很直接——迪文DGUS屏内部有一颗自己的处理器固件把屏幕刷新、触控检测、图片存储全部接管了。你在电脑上用一个叫DGUS的工具组态把按钮、数值显示、文本控件统统摆好每个控件分配一个变量地址编译生成DWIN_SET文件夹拷到SD卡里插到屏上就完成“烧录”。MCU这边要做的根本不是像素级操作而是通过串口往这些变量地址写入数据、读取数据。这就好比你雇了一个前台接待你要做的不是自己去跑各个工位喊话而是通过桌上那部固定电话串口告诉前台“把三楼会议室的状态牌翻成‘使用中’”。迪文屏就是那个前台串口指令就是那部电话。所以STM32和迪文屏之间的通信例程核心其实就是“用串口读写一段内存”。一旦理解了这一点你再看网上那些几百行的通信例程会发现它们不过是在做三件事拼帧、发帧、解析回帧。1.2 串口资源怎么分配选USART2USART1还是FreeRTOS下的串口队列通信例程里第一个要决定的是STM32的哪个串口用来接屏。工程里常用USART2原因不神秘它引脚默认在PA2(TX)、PA3(RX)和USART1的PA9/PA10错开调试串口正规做法接USB转TTL看日志用USART1时两条线不冲突。如果你用USART3接多半是因为PA2/PA3被别的外设占了比如ADC或定时器输入。系统资源分配建议资源用途优先级USART1调试日志输出越高越好调试期离不开USART2迪文屏通信项目主通信链路优先保证独立定时器TIM2/TIM4帧超时判断、界面刷新节拍看系统是否复杂有RTOS时可选波特率方面迪文屏默认常见的是115200或9600DGUS软件里可以选择但务必注意屏端波特率是组态时烧进去的MCU端波特率是代码里配置的两边不一致一上来就全是乱码。例程里我习惯统一用1152008位数据、1位停止位、无校验。帧率高、显示刷新不卡误码率在短线上完全可接受。1.3 为什么不用“直接驱动屏”方案而选串口屏做产品的人要面对一个现实UI需求变化速度远快于固件迭代。交给串口屏后MCU只负责业务逻辑和传感器采集界面改版全在DGUS工具里完成SD卡一插不碰MCU代码。尤其当一个项目里配多个屏幕型号、或者甲方反复改显示布局时这个解耦优势能救命。另外引脚占用少也是一个现实收益。RGB屏起步几十个引脚还牵扯SDRAM、DMA、LTDC而串口屏两根TXD/RXD就完事PCB布线和结构改动成本都低。实话说如果只是做数据展示和设备控制串口屏确实是平衡开发效率和成本的最优解。2. DGUS通信协议的核心细节一帧数据的“暗号”怎么写2.1 帧结构帧头、长度、命令、数据、帧尾DGUS指令帧的通用格式我这里按最常用的DGUS II指令集说明老一些的固件是7字节短帧格式但现在的屏基本都在用带帧尾校验的格式AA [帧长] [命令字] [数据区...] CC 33 C3 3C其中帧长是从命令字开始到数据区结束的字节数不包含帧头AA也不包含帧尾。只要把这一点记牢长度就不会算错。帧尾是固定的CC 33 C3 3C共4字节。老版本固件有些只有CC 33 C3 3C部分叫帧尾但新版本普遍要求这条5字节固定尾巴包括长度不同型号有差异请以屏型号对应的《DGUS指令集》为准但绝大多数新屏是AA LEN 命令 数据 CC 33 C3 3C这个结构。两个最常用的命令一个写变量地址一个读变量地址写变量地址0x82以向地址0x1000写入一个16位数值0x1234为例AA 05 82 10 00 12 34 CC 33 C3 3C05 命令字0x82占1字节 地址0x1000占2字节 数据0x1234占2字节共5字节0x82是写命令固定10 00表示变量地址高字节在前12 34是本次写入的数据读变量地址0x83以读取地址0x1000的一个字为例AA 04 83 10 00 01 CC 33 C3 3C04 命令字1字节 地址2字节 读取长度1字节 4字节01表示读一个字16位屏返回数据时一般长这样AA 06 83 10 00 01 12 34 CC 33 C3 3C这里06 命令字1 地址2 读取长度1 返回数据2返回数据放在最后紧贴帧尾之前。2.2 变量地址和控件屏幕上的东西其实是内存里的变量在DGUS组态软件中你拖一个“数值显示”控件在属性框里给它分配一个变量地址比如0x1000。运行后屏幕上这个控件显示的内容永远等于MCU最近一次向0x1000写入的数值。按钮触控控件则相反用户手指一碰屏会主动向MCU发一帧带0x83读指令或者0x81触控上传的帧告诉你“这个地址对应的控件被按下了”。这个“控件变量”的映射习惯非常关键。我在例程中习惯把地址按功能分区例如变量地址用途类型0x1000 - 0x1010传感器数据上报温度、湿度等只读向上传0x2000 - 0x2005MCU控制指令下发启动、停止、模式屏端触控写入0x3000 - 0x3002系统状态反馈MCU主动刷新这样分区之后即使UI改版换控件位置只要变量地址不变MCU代码几乎不用动。这也是例程里最值得学习的思想硬件解耦UI与业务逻辑靠“地址表”解耦。2.3 电平、共地、接线通信不稳的第一个排查点STM32的UART引脚是3.3V TTL电平迪文屏的串口接口在大部分型号上也是3.3V/5V兼容TTL直接连即可。但有三点必须注意TX和RX必须交叉连接STM32_TX - 屏的RXSTM32_RX - 屏的TX。接反了屏幕不会理你这是最最常见的“通信不上”原因。必须共地两个设备的GND连在一起否则电平参考点不对偶尔能通偶尔乱码很难排查。电源尽量隔离屏的背光瞬间电流可能几百毫安到1A以上不要和STM32开发板共用同一个LDO压差过大的电源口否则屏亮起瞬间MCU会复位或者出现“杂信号”。给屏单独接5V/500mA以上电源效果会稳很多。3. STM32端代码如何落纸一个可以直接抄的通信例程骨架3.1 串口初始化标准库还是HAL库差别不大关键是中断接收例程基于什么库都能跑标准库和HAL库只是初始化API不同协议处理逻辑完全一致。下面按HAL库演示因为现在用CubeMX生成工程的人多代码可读性也好一些。CubeMX里把USART2配成异步模式波特率1152008N1打开全局中断。RX用普通中断接收即可不需要DMA因为迪文屏数据帧很短一般几十个字节以内DMA在这个场景下只是锦上添花。初始化代码// 在 main.c 的 USER CODE BEGIN 2 里启动接收 HAL_UART_Receive_IT(huart2, (uint8_t *)rx_buf, 1); // 单字节接收中断这里每次只接收一个字节然后在中断回调里逐字节喂状态机。这个做法在例程中很常见能保证每一帧不丢字节也能预防一帧还没收完下一帧就挤进来的情况。3.2 发送函数拼帧并计算长度发送端的核心是构造带帧头帧尾的完整数据帧。我自己习惯封装一个通用函数参数是命令字、变量地址、数据指针和数据长度内部自动拼帧void DWIN_SendData(uint8_t cmd, uint16_t addr, uint8_t *data, uint8_t len) { uint8_t frame[256]; uint8_t index 0; frame[index] 0xAA; // 帧头 frame[index] 3 len; // 帧长命令1字节 地址2字节 数据len字节 frame[index] cmd; // 命令字0x82写 / 0x83读 frame[index] (uint8_t)(addr 8); // 地址高字节 frame[index] (uint8_t)(addr 0xFF); // 地址低字节 if (len 0) memcpy(frame[index], data, len); index len; frame[index] 0xCC; frame[index] 0x33; frame[index] 0xC3; frame[index] 0x3C; // 帧尾 HAL_UART_Transmit(huart2, frame, index, 100); }写一个变量时调用DWIN_SendData(0x82, 0x1000, (uint8_t[]){0x12, 0x34}, 2);就生成上面那帧数据。这里帧长为什么是3 len而不是3 0因为命令字、地址高、地址低各占1字节数据长度len按实际字节数算所以要加上前面的3个字节。3.3 接收解析一个用状态机啃帧的土但好使的办法接收解析是通信例程里最容易翻车的地方。有的人用HAL_UART_Receive_IT接收不定长帧在回调里判断字节如果帧边界判断错了就会出现“能收到resp但reply乱掉”的烦人问题。我例程里的办法是状态机逐字节解析uint8_t rx_step 0; uint8_t rx_len 0; uint8_t rx_buf[128]; uint8_t rx_cnt 0; void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart-Instance USART2) { uint8_t byte rx_buf; // 实际工程中换成一个全局变量接收 switch (rx_step) { case 0: // 等待帧头 if (byte 0xAA) { rx_step 1; rx_cnt 0; } break; case 1: // 等待帧长 if (byte 0 byte 100) { rx_len byte; rx_step 2; } else rx_step 0; // 长度非法重新等帧头 break; case 2: // 收数据区 rx_buf[rx_cnt] byte; if (rx_cnt rx_len) rx_step 3; break; case 3: // 收帧尾校验 if (byte 0xCC) rx_step 4; else rx_step 0; break; case 4: if (byte 0x33) rx_step 5; else rx_step 0; break; case 5: if (byte 0xC3) rx_step 6; else rx_step 0; break; case 6: if (byte 0x3C) { // 一帧完整收到交给协议解析函数 DWIN_ParseFrame(rx_buf, rx_len); } rx_step 0; break; default: rx_step 0; break; } HAL_UART_Receive_IT(huart2, (uint8_t *)rx_buf, 1); } }注意这个例程里我为了展示逻辑把变量名写成了接收缓冲名实际工程中建议接收字节单独用一个全局变量避免覆盖还没有处理的rx_buf内容。帧收完了在DWIN_ParseFrame里再判断命令字是0x83读响应还是0x81触控响应并更新对应的业务变量。3.4 一个完整例子每秒刷新一个温度值顺便读取按钮状态以最常见的应用场景为例STM32内部ADC采集一个温度假设换算后为26.5℃即0x0109通过迪文屏0x1000地址的数值控件显示用户按屏幕上的“启动”按钮控件地址0x2000MCU收到后置位一个全局标志。写入温度值uint8_t temp_data[2] {0x01, 0x09}; DWIN_SendData(0x82, 0x1000, temp_data, 2);在解析到屏返回的触控帧时0x81命令void DWIN_ParseFrame(uint8_t *buf, uint8_t len) { if (buf[0] 0x81 buf[1] 0x00 buf[2] 0x01) { // buf[3]的高位代表按键状态变化这里用最简处理 uint16_t touch_addr (buf[4] 8) | buf[5]; if (touch_addr 0x2000) { start_flag 1; // 全局启动标志 } } // 其他命令字类似处理 }需要说明的是0x81触控上传帧的具体格式在不同括展类型下会略有差异例程这里用的是“按键值返回”模式实际使用以组态软件里配置的触控控件返回格式为准。核心思路永远是控件配了地址按压就会上报地址MCU接住地址就等于接到了按键事件。4. 组态工程侧的关键设置别让MCU端代码白写4.1 在DGUS里新建工程与分配变量地址迪文屏的组态工具叫DGUS打开后新建工程选择你的屏型号。先把做好的背景图按分辨率导入比如800x480的屏底图就是800x480的BMP/JPG。然后拖入“数值显示”控件在控件属性里设置整数位、小数位、显示格式最关键的是“显示变量地址”要和MCU写入地址一致。比如MCU写0x1000控件地址就必须填0x1000而且数据类型要匹配——图中控件是16位WordMCU就往这个地址写入2字节如果控件配的是32位长整形MCU就必须连续写入4个字节。这个“MCU写几个字节”和“控件数据类型”不匹配的问题是屏上数值显示长期不对、跳乱码、只能显示一半的高频原因写代码前先记住这一条。4.2 触控控件的返回设置按钮按下去屏到底怎么告诉MCU在DGUS里添加“按键返回”或“触控控件”分配变量地址再设置返回模式。常见的是“按下返回”按下时立即上发和“弹起返回”松开时上发。我建议用“按下返回”做启动、急停这类需要快速响应的按钮用“弹起返回”做模式切换避免误触发。触控控件配置好之后屏会自动生成触控帧。你不需要记住所有字节的含义只要在MCU解析时读出触控变量地址或者读出按键键值就够了。4.3 烧录到屏SD卡里必须叫DWIN_SETDGUS软件工程编译后会生成一个DWIN_SET文件夹务必把这个文件夹原样拷贝到一张FAT32格式的SD卡根目录卡不要太大16GB以内兼容性最好。把SD卡插到屏的SD卡槽重新上电屏会自动检测并开始升级界面文件和组态配置。期间能看到屏幕提示或指示灯变化升级完成后断电、拔卡再上电就是新界面了。我踩过的一个小坑是SD卡里之前残留别的文件导致屏启动时误读后来每次烧录前都先把SD卡清空只放最新的DWIN_SET这个毛病就再没犯过。5. 常见问题与排查技巧实录我把踩过的坑一次性列出来这部分我给一张速查表基本覆盖通信例程跑不起来的大多数原因。现象排查方向备注屏黑屏、无反应电源、SD卡、固件是否正常先看背光是否亮、外接供电是否足够屏花屏或界面错乱DWIN_SET是否完整、SD卡格式FAT32格式文件夹名务必全大写MCU收不到屏的任何返回TX/RX是否交叉、GND是否共地、波特率是否一致用串口助手抓屏TX引脚输出收到数据但全是乱码波特率、电平、干扰短接线、屏蔽线或者降低波特率到9600写入地址后屏上数值不刷新控件变量地址和MCU地址是否一致、数据类型是否匹配多数是地址不一致或写错了宽度按钮按下MCU无反应触控控件的返回类型是否配置地址是否解析正确在DGUS里检查触控控件的变量地址和返回模式STM32下载程序时报error: no stm32 target found!连接器和电源问题检查SWD四根线SWDIO、SWCLK、GND、3.3V确认BOOT0接地屏和开发板是否独立供电导致地电位差上位机虚拟串口显示感叹号驱动未装好重装USB转串口驱动换个USB口上电后先通后乱干扰或电源波动检查屏背光瞬间电流给MCU和屏分开供电5.1 “MCU和屏单独能工作一接到一起就乱码”的破解这种情况十有八九是地电位差或电源不稳。我做过一个项目把STM32开发板和迪文屏接到了同一个USB口供电屏一亮开发板就复位最后改成屏用独立5V适配器供电两块板子的GND再接在一起问题立即消失。5.2 帧尾校验同一个屏、不同型号指令可能差一位前面给的帧尾是CC 33 C3 3C适用于大部分DGUS II固件。但偶尔遇上较旧或特殊的屏帧尾格式可能不同有的只发CC 33 C3 3C有的却要求计算CRC校验填在帧尾前。例程里如果发现屏端“死活不回”先用串口助手指着屏的TX看它上电主动发的握手帧是什么样的对照数据手册确认帧结构。我记得自己第一次调的时候一直按老数据手册拼帧屏根本不理后来抓屏的主动广播帧才发现新版指令集长度计算多了一个字节。5.3 调试利器串口助手三件套调这类通信例程工具比代码值钱。我始终备三样一个USB转TTL串口模块用来并联监听屏的TX线串口助手好软件虚拟示波器或逻辑分析仪实在没有就靠串口助手。监听时注意可能影响时序我是直接飞线出来逻辑分析仪的夹子夹住屏的TX和GND不影响通信又能看到一帧一帧的真实波形。这么干过一次很多玄学问题都能快速定位。6. 把这套例程用起来的个人心得这类“STM32与迪文屏通信例程”表面上是一段串口收发代码但它真正的价值是给了你一套“低成本、低引脚、高可维护性”的人机交互方案。我现在做任何需要面板显示和控制的小设备都是先给客户出DGUS界面原稿地址表列一张Excel然后MCU代码里按地址表操作变量就行。UI改版、文案修正、图标替换客户自己拿SD卡就能刷完全不影响固件开发。如果你刚把手里的例程跑通建议下一步做三件事第一把地址表整理成一个头文件用宏定义给每个地址起名字第二把接收状态机封装成库方便以后换库或换平台比如从标准库换到HAL库的时候协议层不用动第三补一个看门狗超时重发机制——迪文屏偶尔受干扰丢一帧很正常超时重发比每次都傻等更稳。这几个习惯养成了以后接屏的工作会顺很多。最后再分享一个小技巧如果你手头屏的固件版本资料不够全可以在组态软件里打开一个官方例程看看它导出的变量地址和控件配置再对照MCU代码里的发帧顺序很多疑问都能迎刃而解。毕竟这些例程能流传这么多年就说明路子是对的照着走绝对比从零开始瞎猜靠谱。本文还有配套的精品资源点击获取
