简介：围绕迪文串口屏与STM32单片机的串口通讯实验，这份资料面向正在学习嵌入式串口通信、HMI显示与基础外设联动的开发者，重点解决STM32与迪文屏之间指令收发、界面配置和交互反馈的落地问题。压缩包共44个文件，约6.8MB，包含4个C源文件与4个头文件构成的主控工程，覆盖USART初始化、主流程、按键及LED控制；另有24个BMP界面图、6个TFT屏工程文件、HMI工程、字库与配置文件，便于对照屏幕分辨率、显示区域和触控变量进行调试。已有5976人学习下载，说明其作为入门到进阶的通讯实验参考具有一定认可度。读者可从中获得清晰的工程结构、串口收发与按键联动思路、迪文屏配置素材及显示管理示例，适合按模块拆解实验并排查通信与显示问题。

1. 屏幕亮了却不显示数据：STM32 与串口屏通讯最容易翻车的起点

很多人第一次做 STM32 串口通信接串口屏，卡住的地方往往不是屏幕不亮、供电不稳，也不是线接错，而是屏幕通电后背景界面正常、按钮能切换页面，但主控发过去的数据一点反应都没有。这个现象很典型：屏幕自己运行自己的，MCU 自己跑自己的，两边像在不同频段，各说各话。问题八成出在帧格式、波特率对齐、指令结束符这几处细节上，而这正是迪文串口屏与 STM32 通讯实验要解决的核心问题——把“屏幕能亮”推进到“数据能双向流动”。

这类实验的价值不在点灯，而在于它是一套完整的“MCU 通过 UART 驱动人机界面”的最小闭环：STM32 侧要配置 USART、收发中断或 DMA、拼装指令帧；屏幕侧要理解变量地址、VP 寄存器、指令集与返回帧。适合正在做毕业设计、工控面板原型、仪器仪表显示的从业者，也适合已经会点库函数但没真正做过屏机联调的新手。下面按接线、配置、指令、排错、进阶的顺序往下拆，能直接照着复现。

2. 硬件链路与串口配置：从电平到波特率的对齐

2.1 先确认电平与接线，别急着写代码

迪文串口屏的通讯口一般是 TTL 电平的 UART，常见是 5V 或 3.3V 可选（具体以屏的规格为准），STM32 的 USART 引脚是 3.3V 电平。两边直连前必须确认三件事：电平是否匹配、TX/RX 是否交叉、地是否共地。我一般会先在断电状态下用万用表确认屏的 TX 与 RX 丝印，再把 STM32 的 PA9（USART1_TX）接屏的 RX，PA10 接屏的 TX，GND 对 GND。

如果屏是 5V 电平而 MCU 是 3.3V，直接连会长期损伤 IO，常见做法是加双向电平转换，或者在屏侧选择 3.3V 供电档位。另一个常被忽略的点是供电能力：屏带背光时电流不小，如果和 STM32 共用 USB 供电，屏幕刷新时容易拉低电压导致 MCU 复位，表现为“一操作屏幕程序就跑飞”。这类玄学现象，血泪经验是先用独立稳压源给屏供电，再排查软件。

接线上还有一个边界：部分屏的调试口和用户口是同一个 UART，如果电脑串口工具和 MCU 同时挂在同一对线上，会互相抢总线，表现为偶发丢帧。联调阶段要么分时使用，要么把 MCU 的 TX 串一个电阻做隔离测试。

2.2 USART 参数：波特率、帧格式、空闲中断

配置侧的关键参数就那几个，但每一个都不能想当然。下面是一段基于 HAL 库的 USART1 初始化，参数与迪文屏出厂默认（常见 115200、8N1）对齐：

/* USART1: PA9=TX, PA10=RX, 115200-8-N-1, 开启接收中断 */ void MX_USART1_UART_Init(void) { huart1.Instance = USART1; huart1.Init.BaudRate = 115200; /* 必须与屏的波特率一致 */ huart1.Init.WordLength = UART_WORDLENGTH_8B; /* 数据位 8 */ huart1.Init.StopBits = UART_STOPBITS_1; /* 停止位 1 */ huart1.Init.Parity = UART_PARITY_NONE; /* 无校验 */ huart1.Init.Mode = UART_MODE_TX_RX; huart1.Init.HwFlowCtl = UART_HWCONTROL_NONE; /* 不启用硬件流控 */ huart1.Init.OverSampling = UART_OVERSAMPLING_16; if (HAL_UART_Init(&huart1) != HAL_OK) { Error_Handler(); } /* 开启接收中断，逐字节进入回调，适合不定长帧 */ __HAL_UART_ENABLE_IT(&huart1, UART_IT_RXNE); }

这段代码里最容易被改错的是BaudRate和WordLength：迪文屏如果你在工程里改过波特率，而 MCU 侧没同步，两边就会“看起来在发但全是乱码”，接收到的字节数可能对但值全错。HwFlowCtl保持 NONE，因为屏通常不支持 RTS/CTS 流控；如果误开，STM32 会一直等 CTS 信号，表现为只发不收或干脆不发。

不定长帧的接收，我一般不用HAL_UART_Receive死等固定长度，而是逐字节中断进缓冲区，配合空闲检测或超时判定帧尾。原因是屏返回的应答长度不固定，用固定长度接收必然错位。下面是一个接收缓冲的最小实现：

#define RX_BUF_SIZE 128 static uint8_t rx_buf[RX_BUF_SIZE]; static uint16_t rx_len = 0; static uint8_t rx_byte; /* 在 HAL_UART_RxCpltCallback 中调用，每次收 1 字节 */ void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart->Instance == USART1) { if (rx_len < RX_BUF_SIZE) { rx_buf[rx_len++] = rx_byte; /* 存入缓冲，长度自增 */ } HAL_UART_Receive_IT(&huart1, &rx_byte, 1); /* 重新挂接收 */ } }

逻辑说明：每次进入回调说明收到 1 字节，存进rx_buf后立刻重新挂起单字节接收，保证不漏字节。rx_len是当前累计长度，主循环里根据帧尾标志或超时来判断这一帧结束。参数上RX_BUF_SIZE要大于屏最长返回帧，一般 128 足够；如果屏会回传大段数据（比如读多个 VP），要放大到 256 以上。注意rx_len的清零时机必须在帧解析完成后，否则会出现“上一帧尾部粘到下一帧头部”的经典错位。

2.3 帧间隔与超时判定

串口是字节流，没有天然边界，所以“一帧到哪里结束”必须由协议约定。迪文屏的指令一般有固定帧头与结束符（常见以 0xFF 0xFF 或特定长度字节结尾，具体看所用指令集版本），MCU 侧要么按结束符判断，要么用空闲超时。我一般两者结合：先找帧头，再等结束符，同时开一个 5～10ms 的定时器做兜底，超时就丢弃半帧。

这个 5～10ms 不是随便取的。115200 波特率下传 1 字节约 87μs，一帧几十字节也就几毫秒，帧间间隔通常明显大于帧内字节间隔。超时阈值设太小会把一帧截断，设太大则错帧后恢复慢。新手最容易在这翻车：只看结束符不看超时，一旦干扰导致丢一个字节，接收缓冲就永久错位，后面所有应答全乱。加超时清缓冲，是最便宜的黑匣子手段。

3. 指令帧的拼装与收发：VP 地址、指令集与状态机

3.1 搞清变量地址与指令格式再动手

迪文屏的显示逻辑是“变量驱动”：你在屏幕工程里放一个文本控件或数字控件，给它分配一个 VP 变量地址（比如 0x1000），MCU 只要往这个地址写数据，屏上的控件就自动刷新。这跟“MCU 直接画点”是两种思路，理解这一点，后面所有指令就顺了。

常见指令结构大致是：帧头 + 指令码 + 数据长度 + 变量地址 + 数据 + 结束符。具体字节序、帧头值、是否带长度字节，取决于屏所用的指令集（不同系列、不同固件有差异）。实操上不要凭记忆写，我一般会先在屏的开发工具里生成一条示例指令，用电脑串口助手发一遍确认屏有反应，再把这条指令原样搬进 MCU 代码。这一步能把“协议理解错误”和“代码写错”两类问题分开。

写数据时的地址计算要特别小心：很多屏的 VP 地址是字地址，写一个 16 位数据占一个地址，写字符串则按字递增，一个汉字占一个字。常见错误是按字节递增地址，结果字符串只显示第一个字或显示乱码。下面的发送函数把地址自增做成参数，避免各处手写：

/* 向 VP 地址写一串字节数据，addr_step 为每次写后地址增量 */ void DGUS_WriteBytes(uint16_t vp_addr, const uint8_t *data, uint16_t len, uint16_t addr_step) { uint8_t frame[64]; uint16_t idx = 0; frame[idx++] = 0x5A; /* 帧头，按实际指令集填写 */ frame[idx++] = 0xA5; frame[idx++] = 0x82; /* 写 VP 指令码 */ frame[idx++] = vp_addr >> 8; /* 地址高字节 */ frame[idx++] = vp_addr & 0xFF; /* 地址低字节 */ for (uint16_t i = 0; i < len; i++) { frame[idx++] = data[i]; } frame[idx++] = 0xFF; /* 结束符，部分指令集不需要 */ frame[idx++] = 0xFF; HAL_UART_Transmit(&huart1, frame, idx, 100); /* 100ms 超时 */ }

逻辑说明：帧头、指令码、地址高低字节、数据、结束符按顺序拼进frame，最后一次性发送。参数vp_addr是屏幕工程里分配的变量地址，必须与界面配置一一对应；addr_step留给需要按字递增的场景（如连续写多个变量），如果只是单点写可以不传或传 0。HAL_UART_Transmit的超时给 100ms 是保守值，实际几毫秒就发完，但别设成 0 或 1ms，阻塞发送在低优先级任务里容易被抢占导致超时失败。

这里有个容易被忽略的边界：frame数组大小。上面写死 64，如果写入的数据超过 60 字节就会越界。稳妥做法是按最大数据长度定义，或在函数入口加长度断言。很多“偶发死机”追到最后就是这类静态缓冲越界，写坏了旁边的全局变量。

3.2 发送与应答的状态机组织

屏的指令分两类：一类只管发不用等回复（写显示），一类需要读回（读版本、读变量）。如果全用阻塞发送加同步等待，主循环会被拖慢；如果全异步又不加状态管理，应答和请求就对不上号。我一般用一个极简状态机：每次只允许一条“待应答”指令在途，发出后置标志，收到完整帧后比对指令码，匹配则清标志、更新数据，超时未回则重发一次并记错误计数。

typedef enum { DGUS_IDLE = 0, DGUS_WAIT_ACK } dgus_state_t; static dgus_state_t dgus_state = DGUS_IDLE; static uint8_t dgus_cmd_sent = 0; static uint32_t dgus_tick = 0; /* 主循环中周期调用，超时 50ms 未应答则重发一次 */ void DGUS_Task(void) { if (dgus_state == DGUS_WAIT_ACK) { if (HAL_GetTick() - dgus_tick > 50) { dgus_cmd_sent++; if (dgus_cmd_sent <= 1) { DGUS_SendLastCmd(); /* 重发上一次指令 */ dgus_tick = HAL_GetTick(); } else { dgus_state = DGUS_IDLE; /* 两次失败，放弃并交上层处理 */ dgus_cmd_sent = 0; } } } }

逻辑说明：dgus_state只有空闲和等待应答两态，简单但够用。dgus_tick记录发送时刻，50ms 是应答超时阈值，比帧传输时间宽裕得多，又能让上层在百毫秒级感知故障。重发只做一次，避免总线被反复占用；两次失败就置空闲并让上层决定是否报错。参数dgus_cmd_sent兼作重试计数，用完清零，防止状态残留。

这个结构的优点是“永远不会出现两条指令的应答互相串台”，缺点是吞吐低。对于按钮响应、参数回读这类场景完全够；如果要做高频数据刷新（比如 10Hz 以上曲线），就得改成带序列号的请求队列，把应答按指令码或序号匹配。新手阶段先用单在途状态机，能避开一大半时序问题。

3.3 触摸事件的上报处理

屏不仅被动显示，还会主动上报触摸事件。屏被按下时，会通过串口发回一帧包含控件地址和事件类型的数据，MCU 解析后执行对应动作。这一环最容易出的错是把“按下”“松开”“长按”混为一谈，或者把上报帧和应答帧混在同一个解析函数里。

我的做法是解析函数只做一件事：从缓冲区里切出一条完整帧，然后按指令码分派。触摸上报的指令码与读写的指令码不同，分派时先判类型，再解析地址与键值。缓冲区用环形队列更稳，中断只负责入队，主循环出队解析，这样即使解析耗时略长也不会丢字节。环形队列的实现不复杂，关键是读写指针的原子性：单生产者（中断）单消费者（主循环）场景下，读写指针各自只被一方修改，不加锁也是安全的，这个前提要记住。

解析时还有一个细节：事件值不同含义不同，有的值代表按下，有的代表松开，有的代表长按持续上报。如果不区分，按钮会“按一下触发两次”或“松手才触发”，用户体感很差。我一般只对“按下”那一个值做业务响应，松开事件只用来做界面反馈，长按事件单独处理。这套约定在屏的界面工程里也要对应配置，两边一致才不会出现逻辑打架。

4. 联调避坑：五类高频故障的现象、原因与解法

4.1 现象：屏幕完全无应答

现象是 MCU 发指令后屏毫无反应，界面也不刷新。原因通常有三类：TX/RX 接反、波特率不一致、共地缺失。解法是先用 USB 转 TTL 直接接屏，用串口助手发一条已知正确的示例指令，确认屏本身工作正常；再把这条线换回 MCU，示波器或逻辑分析仪看 MCU 的 TX 引脚有没有波形。有波形说明软件在发，问题在电平或接线；没波形说明 USART 没真正启动或引脚复用没配。

血泪经验是：不要一上来就怀疑屏坏了。绝大多数“屏不响应”最后都落在接线和波特率上，而这两项恰恰是最容易在改代码时被忽略的。

4.2 现象：数据能发出去，但屏上显示乱码或只显示一部分

现象是数字控件显示成乱码，字符串只出第一个字。原因一般是两类：地址递增方式错了（按字节而非按字递增），或者数据编码与屏的编码设置不一致（GBK 与 UTF-8 混用）。解法是先用单字符测试，确认一个字的写入占用几个地址；再检查屏工程里的字符编码设置与 MCU 侧发送的字节流是否一致。中文乱码在这个实验里出现频率极高，且常被误判为“通讯不稳定”。

4.3 现象：运行一段时间后程序死机或复位

现象是连续操作屏几分钟后 MCU 复位，或进入 HardFault。原因多见于发送缓冲越界、接收缓冲未及时清零导致覆盖、以及屏背光电流拉低电源。解法是给所有定长缓冲加长度检查，接收侧在帧解析完成后立即清零长度；电源侧用独立供电，并在屏电源脚附近加足够容量的去耦电容。排查这类问题，先看是不是固定时间后必现——如果是，多半和缓冲累计或电源发热有关，而不是随机干扰。

4.4 现象：应答时有时无，偶发丢帧

现象是大部分指令正常，偶尔读不回数据。原因通常是帧边界判断不稳（只看结束符没超时兜底）、中断优先级配置不当导致接收中断被长时间阻塞、或者电脑串口工具与 MCU 抢同一路总线。解法是加空闲超时清缓冲，把 USART 接收中断优先级提到合理位置，联调时断开电脑侧连接。另外要注意，如果在中断里调用了带阻塞的发送函数，等于自己把自己卡死，这类写法必须改成中断只入队、主循环发送。

4.5 现象：触摸响应错位，按 A 触发 B

现象是按钮功能串了，或按一个键触发多个动作。原因是触摸上报帧解析错位——上一帧没消费完就来了下一帧，或者地址解析的字节序搞反。解法是严格按帧头+长度切帧，解析前先校验帧完整性；地址高低字节的顺序用一条已知按键做基准测试，确认后再批量套用。这类问题在界面控件多、上报频繁时最容易出现，建议在解析函数里加一条日志，把收到的原始帧打印出来对照。

5. 进阶收口：把联调变成可复用的验证套路

真正让这个实验从“能跑”变成“敢用”的，是建立一套固定的验证套路。我后来养成的习惯是分三层验：第一层用电脑串口助手对屏，只验屏的指令集和地址映射，不牵扯 MCU；第二层用 MCU 发固定测试帧，循环写同一个变量，看屏是否稳定刷新十分钟以上；第三层才接真实业务逻辑，同时开一个错误计数器，把超时、重发、帧校验失败都记下来。

第三层的错误计数器特别值得做。下面是一个极简统计结构，挂在状态机旁边即可：

typedef struct { uint32_t tx_cnt; /* 发送总帧数 */ uint32_t rx_ok; /* 校验通过的应答帧 */ uint32_t timeout_cnt; /* 应答超时次数 */ uint32_t crc_err; /* 帧校验失败次数 */ } dgus_stat_t; static dgus_stat_t stat; /* 每发送一帧调用 */ void DGUS_StatTx(void) { stat.tx_cnt++; } /* 收到完整帧并校验通过后调用 */ void DGUS_StatRxOk(void) { stat.rx_ok++; } /* 超时分支里调用，与重发逻辑配合 */ void DGUS_StatTimeout(void) { stat.timeout_cnt++; }

这几个计数不需要实时显示，接个调试串口定期打印就行。判据很直接：timeout_cnt / tx_cnt长期高于 1% 就说明链路或时序有问题，crc_err不为零则优先查干扰和共地。参数上不用调，纯观测；关键是把它当成回归指标，每次改完代码跑十分钟对比数值，比凭感觉判断“好像稳定了”靠谱得多。

再往上一步，可以把常用操作封装成带返回值的接口，比如DGUS_SetText(vp, str)返回成功或超时，让上层业务不用关心帧怎么拼。封装时把地址合法性、字符串长度上限、编码转换都放进去，业务层只传语义参数。这样即便以后换屏型号，改的也只是底层这一层。

最后说个我踩过的坑：早期我图省事，把发送函数直接写在按键中断里，结果屏幕刷新时偶发死机，查了两天才定位到是中断里做了阻塞发送，和接收中断互相等待。从那以后我每次做屏机联调，都强制走一遍“中断只入队、发送只在主循环、所有缓冲带长度检查”这三条，再配合上面那套计数器跑满十分钟，才敢往整机里合。希望帮到你。

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