做嵌入式这几年跟人机交互打交道的项目换了一茬又一茬最早用裸TFT屏的时候光是驱动LCD画点、显示字符、找字库就折腾了一周后来项目排期紧赶不上索性换成淘晶驰串口屏。当时我第一反应很简单串口屏本质上就是把显示和交互这些杂活全交给屏幕自己的主控STM32这边只通过USART发指令、收事件思路一下清爽了很多。这篇内容就是我基于实际项目整理的完整流程覆盖硬件接线、USART参数、屏端指令、心跳检测和大量踩坑记录适合正在做毕设、比赛或者小产品项目的开发者尤其是第一次碰串口屏的人照着做基本能少走一半弯路。我自己最早接触串口屏是在一个温湿度监控项目里需求很普通把传感器数据实时显示上去带两个报警按钮顺便做个断线提示。如果按照传统方案光是画界面、管理字库和触控逻辑就够忙一阵子但用淘晶驰之后从STM32端打开串口助手到屏幕上稳定显示数据前后不到半天。这篇文章不是那种逐行教你点界面的教程而是把通信这条主线上最容易出问题的地方全部拎出来讲透包括为什么TX要接RX、为什么波特率选115200不选9600、为什么屏上电要等一下再发指令、为什么printf一用就死机等等。你看完再动手节省的绝对不止一个下午。1. 为什么用串口屏一次人机交互方案的减法1.1 串口屏到底是什么东西串口屏说白了就是一块自带主控芯片的液晶屏把常见的显示、绘图、字库、触控、控件管理这些事情全部封装在屏幕内部外部设备只要用串口发一些约定好的文本指令屏幕就能完成对应的界面动作。淘晶驰TJC这个牌子在国内用的非常多它的串口屏走的是USART异步通信指令以ASCII文本为主帧尾用三个0xFF作为结束标记格式非常直白比如要让屏幕跳转到第0页只需要发送这样的数据page 0\xff\xff\xff要让某个文本控件显示一行字符也是类似的操作。外部单片机不需要关心屏幕内部用了什么GUI库也不需要了解字库怎么加载只需把字符串拼好顺着串口发过去就够了。理解了这一点你就明白为什么很多STM32项目选它做显示终端——精力可以全部留在“数据怎么处理”上而不是耗在“像素怎么刷”上。1.2 对比裸屏和传统TFT省在哪很多人刚开始做STM32项目都会纠结要不要用1.8寸TFT、2.4寸TFT裸屏再配个字库芯片自己画控件、处理触摸。坦率说这种方式并不是不行我之前也这么干过但一个页面稍微复杂一点比如要画曲线、弹窗、动态按钮工作量马上指数上升。裸屏方案需要自己管理图层、重绘、防闪烁稍有疏忽就会出现残影、闪烁和触摸漂移。串口屏把这些事情全部接管了。你在淘晶驰的上位机工具“USART HMI”里拖几个控件、设置好属性编译下载到屏幕剩下的交互逻辑就可以交给屏幕主控跑。STM32这边只需要在业务逻辑的地方向串口发送一条指令比如按钮按下时收到屏幕回传的key1再根据这个值决定下一步动作。这种“单片机管逻辑、屏幕管显示”的分工让两端开发可以并行推进联调时也只需要盯着串口数据排查链路简短很多。对于毕设、竞赛或者快速出原型的产品这个优势非常明显。1.3 顺手把USART、UART、I2C、SPI理清楚这里必须花点篇幅讲清楚USART因为串口屏通信的真正主角就是它。USART的英文全称是Universal Synchronous/Asynchronous Receiver/Transmitter相比UART多了一个“同步”的能力但在驱动串口屏的场景里我们几乎只会用到异步收发模式也就是通常说的UART通信。UART只需要TX、RX两根数据线外加一根地线通信双方各自约定好波特率、数据位、停止位和校验位就能把字节流送出去。I2C和SPI虽然也是嵌入式里特别常见的通信接口但它们和UART的定位完全不同。I2C只有两根线属于同步半双工总线适合短距离、低速、多设备挂载的场景SPI则是四根线的同步全双工总线速度快适合传感器、Flash、显示屏这类高速外设。串口屏选UART一个重要原因是极简、通用、几乎没有驱动门槛任何一个调试助手都能直接看到通信内容出现问题很容易定位。USB转TTL模块插上电脑打开串口助手你就能直接观察屏幕发出来的是什么、发过去的指令有没有被回显这一点非常利于新手快速建立“通信链路”的概念。2. 硬件接线与通信参数这些坑千万别重踩2.1 TX/RX交叉连接是最常见的低级错误STM32和淘晶驰串口屏之间基本就是三根线STM32的TX接屏幕的RXSTM32的RX接屏幕的TX然后再拉一根共用地线。很多人第一次接的时候下意识以为同名的TX接TX、RX接RX结果屏幕没有任何反应。我在指导别人做项目时至少有三分之一的问题出在这个交叉接法上。如果条件允许建议用USB转TTL先单独验证屏幕。把屏的TX、RX和GND接好在电脑串口助手里手动发送page 0\xff\xff\xff如果屏幕正常跳转说明屏幕自身没问题然后再把STM32接上去用逻辑分析仪或者示波器看STM32的TX脚有没有波形。这样就能快速判断问题是出在屏幕、线序还是单片机侧而不是两边一起瞎猜。接线这块多检查一遍远比烧录程序后再抓狂划算。2.2 共地与电平逻辑问题串口通信的双方必须有共同的参考地否则你发出去的信号电位就是悬空的偶尔能通、偶尔乱码、换一个环境彻底不工作。我之前接过一个项目屏和STM32各自用独立的电源适配器当时偷懒没有共地结果波特率调到9600才能勉强显示改成115200后全是乱码。后来把两个电源的GND接到一起问题立刻消失。所以无论是单电源供电还是双电源供电GND这根线绝对不能省。电平方面STM32的串口引脚是3.3V TTL电平淘晶驰串口屏的串口接口一般也兼容3.3V TTL或者5V TTL具体要看对应型号的硬件手册。用STM32驱动直接连接通常没问题但要注意屏幕的电源一定要按手册要求独立供电不要试图从STM32板的3.3V引脚给屏幕供大电流因为串口屏背光功耗不小贸然供电可能会把稳压芯片拉垮轻则屏幕闪屏重则系统掉电复位。稳妥做法是屏幕用5V/1A以上的电源单独供电再和STM32共地。2.3 串口参数怎么选115200、8N1背后的逻辑串口通信双方如果波特率对不上收到的就是乱码或者完全没反应。淘晶驰串口屏默认参数通常是波特率115200、8位数据位、1位停止位、无校验位也就是我们常说的8N1。我刚上手时为了省事想用9600结果发现屏幕完全没数据显示后来查手册才知道默认配置不是9600。这里顺便说一下为什么很多项目都推荐115200。STM32F103这类芯片主频如果是72MHz计算USART分频时115200可以做到几乎零误差72,000,000 / (16 × 115200) 39.0625这个分频值能精确落到波特率寄存器上所以误码率非常低跑起来稳定。9600虽然也可以用但实际传输速度只有115200的约1/12。串口屏一个指令动辄十几个字节尤其需要频繁刷新文本、进度条、波形的时候慢速波特率会明显感觉到界面卡顿所以我一般直接用115200起步。发送端和接收端的参数必须完全一致数据位8位、停止位1位、无校验位。校验位如果设置错了波特率再准也是徒劳。有一个小技巧先用串口助手手动验证屏幕配置确认能正常收发再烧STM32程序这样至少能保证通信的“底层约定”没有任何分歧。2.4 上电时序先等“USART HMI Ready”再发指令串口屏跟普通单片机外设不一样它内部有独立的处理器上电之后需要跑系统、初始化字库、加载页面这个过程快的几百毫秒慢的可能要一两秒。如果STM32一上电就开始疯狂发指令屏幕此时还没准备好指令就会被直接丢掉。最典型的症状是屏幕上电后能看到画面但所有指令都无效而单片机这边已经发得不亦乐乎了。淘晶驰串口屏上电完成后会主动通过串口发送一串字符通常就是USART HMI Ready后面跟一个回车换行调过淘晶驰屏的人都见过这个回显。这个信号特别适合作为握手条件STM32初始化完串口之后先不要急着发业务指令等收到这串“Ready”再进入正常流程。哪怕你不做严格的握手至少也要在上电后加一个延时比如300到1000毫秒给屏幕留足启动时间。很多老手写代码时不加延时换了一片速度慢的屏就会莫名其妙出现第一批数据显示不出来的问题根源就在时序上。3. 从零搭建STM32工程串口点屏的完整流程3.1 环境准备Keil5、ST-Link和驱动一次装明白开始写代码前开发环境得先弄顺。STM32最常用的IDE是Keil MDK也就是Keil5。需要注意Keil5本身是一个外壳真正做ST芯片开发还要安装对应的器件支持包也就是STM32F1系列的DFP包。如果你装了Keil5之后新建工程找不到STM32型号基本就是Pack包没装好在Pack Installer里找到Keil::STM32F1xx_DFP下载安装即可。如果还要同时开发C51单片机Keil5是可以和C51共存的但本质上C51和MDK是两套独立的工具链安装时最好放在不同目录不要互相覆盖。芯片包安装完成后烧录调试我推荐直接用ST-Link V2配套软件用STM32 ST-LINK Utility驱动装好后能在设备管理器里看到ST-Link对应的COM口或者调试器设备。如果电脑提示USB设备无法识别优先检查驱动是否安装正确其次看是不是用了“只能充电不能传数据”的USB线这类线材问题非常坑但很难从外观上分辨。如果手头没有ST-Link也可以用USB转TTL模块走串口ISP下载。方法是把STM32的BOOT0拉高、BOOT1拉低复位后芯片进入系统存储器引导模式然后在PC端用STM32 Flash Loader Demonstrator选择对应串口和波特率烧录程序。这种方式虽然慢一点但当调试器不在身边时它是个可靠的备用方案。3.2 USART初始化配置先用最简代码点亮屏幕我用的是标准库或HAL库都能跑通这套流程下面以HAL库为例展示最常用的USART1初始化。STM32F103C8T6的USART1默认引脚是PA9TX和PA10RX配置GPIO为复用推挽串口参数用115200、8N1开启接收中断就足够跟屏幕通信了。__HAL_RCC_USART1_CLK_ENABLE(); __HAL_RCC_GPIOA_CLK_ENABLE(); GPIO_InitTypeDef GPIO_InitStruct {0}; // TX脚 PA9 GPIO_InitStruct.Pin GPIO_PIN_9; GPIO_InitStruct.Mode GPIO_MODE_AF_PP; GPIO_InitStruct.Speed GPIO_SPEED_FREQ_HIGH; HAL_GPIO_Init(GPIOA, GPIO_InitStruct); // RX脚 PA10复用推挽或输入模式都可以HAL例程一般也用AF_PP GPIO_InitStruct.Pin GPIO_PIN_10; GPIO_InitStruct.Mode GPIO_MODE_INPUT; GPIO_InitStruct.Pull GPIO_PULLUP; HAL_GPIO_Init(GPIOA, GPIO_InitStruct); huart1.Instance USART1; huart1.Init.BaudRate 115200; huart1.Init.WordLength UART_WORDLENGTH_8B; huart1.Init.StopBits UART_STOPBITS_1; huart1.Init.Parity UART_PARITY_NONE; huart1.Init.Mode UART_MODE_TX_RX; huart1.Init.HwFlowCtl UART_HWCONTROL_NONE; HAL_UART_Init(huart1); // 开启单字节接收中断 uint8_t rx_byte; HAL_UART_Receive_IT(huart1, rx_byte, 1);这段代码跑通之后你可以先封装一个最简单的发送函数用来发page 0\xff\xff\xff屏幕如果没有反应优先检查波特率、TX/RX是否交叉和GND是否共地而不是去怀疑代码本身。记住串口屏调试的关键是先把一条指令调通再谈界面优化。3.3 printf重定向与半主机模式很多人在STM32里喜欢用printf向串口屏发数据因为拼字符串太方便了。但这个用法在Keil环境下有个经典大坑如果你直接重定向fputc却没有处理半主机模式程序一旦执行到printf就会卡死调试器里往往停在异常中断里让人一头雾水。半主机模式是ARM调试环境提供的一套机制用来让开发板上的程序通过调试器访问PC主机的键盘、显示器、文件等资源。标准库里的printf默认认为支持这种环境所以执行到输出函数时会尝试调用半主机相关的底层函数。正常运行时没有调试器处理程序就会停住。解决办法也不复杂最简单的方案是在Keil工程设置里勾选“Use MicroLIB”MicroLIB是一套精简版C库省掉了半主机操作重定向fputc之后就能正常用printf了。#ifdef __GNUC__ #define PUTCHAR_PROTOTYPE int __io_putchar(int ch) #else #define PUTCHAR_PROTOTYPE int fputc(int ch, FILE *f) #endif PUTCHAR_PROTOTYPE { HAL_UART_Transmit(huart1, (uint8_t *)ch, 1, 0xFFFF); return ch; }如果不想勾选MicroLIB也可以手动禁用半主机模式加上#pragma import(__use_no_semihosting)之类的声明。我的习惯是直接勾MicroLIB省心又能减小代码体积。另外要提醒一句不要在中断服务函数里长时间调用阻塞式HAL_UART_Transmit否则会拖累整个系统的实时性后面会细讲。3.4 淘晶驰HMI指令格式与基础交互淘晶驰串口屏的指令系统核心就是“控件地址属性操作”。比如屏上放了一个文本控件名字叫n0要让它的文本显示为HelloSTM32端就要拼出这样一帧数据uint8_t cmd[] {0x6E, 0x30, 0x2E, 0x74, 0x78, 0x74, 0x3D, 0x22, 0x48, 0x65, 0x6C, 0x6C, 0x6F, 0x22, 0xFF, 0xFF, 0xFF}; // 对应文本: n0.txtHello HAL_UART_Transmit(huart1, cmd, sizeof(cmd), 0xFFFF);更直观的写法是直接拼字符串uint8_t buf[64]; sprintf((char*)buf, n0.txt\Hello\\xff\xff\xff); HAL_UART_Transmit(huart1, buf, strlen((char*)buf), 0xFFFF);注意那条末尾的\xff\xff\xff这是淘晶驰指令帧的结束符少了它屏幕就会一直等后续数据指令不执行。很多新手调了半天屏不动最后才发现是结束符没发全。页面切换、文本改写、进度条更新本质上都是同样的套路先拼好指令再通过串口发出去。屏幕往STM32方向的消息也不复杂比如按钮b0被按下时可以在屏幕的控件事件里写一行print(key1\xff\xff\xff),STM32的接收中断就会收到这段字符串。收到之后你只需要做字符串匹配就能知道哪个按钮被按下了。3.5 接收中断与字节解析STM32接收串口屏数据最简单的做法是单字节中断配合一个环形缓冲区或者普通数组。每次进入中断把一个字节存进来然后在主循环或者业务任务里判断是否有完整指令。下面这个例子比较常用uint8_t rx_byte; uint8_t rx_buf[128]; uint16_t rx_index 0; void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart-Instance USART1) { rx_buf[rx_index] rx_byte; if (rx_index sizeof(rx_buf)) { rx_index 0; } HAL_UART_Receive_IT(huart1, rx_byte, 1); } }这个回调里面只做“存字节”这一件最轻的事情千万不要在这里去解析大字符串更不要在这里调用HAL_UART_Transmit回数据。串口中断讲究短平快处理时间过长轻则丢字节重则导致系统其他中断无法响应。等完整的一帧数据攒到缓冲区里再到主循环去解析效率和稳定性都会好很多。如果你的串口屏指令比较多、数据帧长可以考虑用DMA空闲中断IDLE的方式接收不定长数据。这个方案可以做到“一批数据到了再通知CPU”省去频繁进中断的开销。核心思路是开启UART的IDLE中断在中断里判断当前DMA接收了多少字节然后处理整包数据。这里给个简化示意// 开启IDLE中断 __HAL_UART_ENABLE_IT(huart1, UART_IT_IDLE); // 在USART1_IRQHandler里增加判断 if (__HAL_UART_GET_FLAG(huart1, UART_FLAG_IDLE) ! RESET) { // 先读SR再读DR清除IDLE标志 uint8_t tmp huart1.Instance-SR; tmp huart1.Instance-DR; // 处理当前DMA收到的数据长度 uint16_t len rx_buf_size - __HAL_DMA_GET_COUNTER(hdma_usart1_rx); // 解析len长度数据 HAL_UART_Receive_DMA(huart1, rx_buf, rx_buf_size); }这种接收方式在数据量上来之后优势很明显。对于大多数串口屏应用数据不会特别密集单字节中断已经够用但如果你的屏要高频上报触摸坐标、波形数据DMA方式会更省心。4. 实战温湿度监测面板心跳保活4.1 屏端工程页面、控件、地址我拿一个具体的温湿度监测面板来举例。先在USART HMI上位机里新建工程选择你手里那块屏幕的型号然后新建一个页面放上几个控件温度显示文本、湿度显示文本、连接状态文本、一个手动刷新按钮。控件命名建议有规律比如温度用n0湿度用n1状态用n2按钮用b0。名字起好了后面的协议拼接才不容易乱。控件在屏端实际上都绑定到一个“地址”上这个地址类似于寄存器编号。STM32给n0.txt赋值本质上就是往这个地址对应的属性写内容。你不需要记住内部寄存器具体怎么映射只要在上位机里看到控件名拼指令时用对名字就行。这也是淘晶驰上手快的一个原因——协议对人友好所有操作都可以用文本指令直观表达。4.2 STM32端数据采集与上报STM32这边采集温湿度最简单的是用DHT11或者SHT30采集逻辑不是本文重点重点是采集到数据之后怎么组帧发给屏幕。假设温度是25.3摄氏度湿度是60.2%你希望屏幕上显示25.3和60.2那么发送逻辑可以这样写char buf[64]; sprintf(buf, n0.txt\%d.%d\\xff\xff\xff, temp_int, temp_dec); HAL_UART_Transmit(huart1, (uint8_t*)buf, strlen(buf), 100); sprintf(buf, n1.txt\%d.%d\\xff\xff\xff, humi_int, humi_dec); HAL_UART_Transmit(huart1, (uint8_t*)buf, strlen(buf), 100);这里我把整数和小数拆成两个变量拼进去避开float格式化带来的代码体积和精度问题。实测下来这种拆数拼接在嵌入式里更稳也更容易控制显示格式。如果你要在字符串里带中文单位比如“℃”和“%RH”记得先在上位机里确认屏幕的编码格式Keil编辑器如果保存成UTF-8而屏幕字库是GB2312显示出来就是乱码。建议新手先用纯ASCII字符调通再考虑中文显示。4.3 心跳检测与断线提示“串口屏实现心跳信号连接”这个需求本质上是要知道屏幕是否还活着以及STM32和屏的通信链路是否中断。这个功能在工业现场、远程监控里特别实用因为屏幕死机或者通信线松动系统如果不报警后果可能很严重。最简单实用的双端心跳方案是屏幕端用定时器控件周期上报心跳帧STM32端负责监控超时。在USART HMI里新建一个定时器周期设为1000毫秒在事件里写一句printf(hb\xff\xff\xff);这样屏幕只要活着每隔一秒就会给STM32发一个hb。STM32端用一个计数器或者时间戳记录最后一次收到hb的时间主循环里判断如果超过3秒没收到就认为通信异常点亮报警指示灯同时向屏幕发送一条page 2\xff\xff\xff把界面切换到故障提示页。反过来如果STM32死了屏幕并不知情这个问题通常靠屏端脚本定时器检查“来自STM32的心跳文本控件是否更新”来解决不过这种方案对屏端脚本的字符串处理能力有一定要求建议等项目跑稳定了再扩展。我之前做的几套方案里优先保证的是MCU侧检测屏端离线因为MCU往往是整个设备的控制核心它知道设备整体状态报警、断电保护这些动作也都是它来执行。屏幕侧做离线检测可以作为辅助但不要依赖它去完成关键安全动作。心跳超时阈值方面一般取心跳周期的3倍比较稳妥比如心跳1秒一次超过3秒没收到再报警避免偶发串口拥塞引起误报。5. 常见问题排查与避坑速查表5.1 常见故障对照速查表我把串口屏联调阶段遇到最多的问题整理成了表格每次项目卡壳我都会先对着表格过一遍很多问题几分钟内就能定位。现象可能原因排查方法屏幕完全无反应TX/RX接反、GND未共地、供电不足检查线序测量引脚电压串口助手发指令无效缺少三个0xFF结束符核对指令帧尾显示乱码波特率不一致、编码不匹配统一115200检查屏字库编码上电后前面几条指令丢失屏幕尚未ReadyMCU发得过早等待“USART HMI Ready”printf卡死不执行半主机模式未处理勾选MicroLIB接收回调里放耗时操作导致丢帧中断处理时间过长只存数据解析放主循环按钮按下却收不到数据屏端事件里没写print/printf检查上位机控件事件脚本USB无法识别调试器/转串口驱动问题或USB线只能充电重装驱动更换数据线STM32下载不进程序BOOT0/BOOT1配置不当BOOT0拉高进ISP拉低进Flash5.2 乱码、花屏、无响应的排查思路乱码的问题大概率出在“速率不一致”或者“参考地不稳”。就先拿电脑串口助手做实验把屏幕接到USB转TTL上手动发指令如果串口助手换成115200还是乱码试试9600、57600看哪个能稳定显示。能收到正确回显说明屏幕本身没问题再回头检查STM32的配置或者接线。花屏和闪屏多半是电源问题屏幕背光突然变暗通常说明供电电流不够换一个输出能力更强的电源适配器基本能解决。无响应的排查要分层推进第一层看硬件TX/RX是否交叉、GND是否接好第二层看指令格式结束符是否带全第三层看时序是否给足了等待时间。我用逻辑分析仪抓过自己的项目发现很多时候STM32发出的数据完全正确但屏就是不理原因竟是STM32在屏幕还没上电完成的时候把指令发出去了指令丢在启动空隙里。后来改成等Ready信号再发就再也没有复现过。5.3 程序卡死问题delay、printf、中断程序跑着跑着卡死在串口屏项目里特别常见而且原因往往比较隐蔽。先说printf卡死这个前面提过多半是半主机模式没处理好勾上MicroLIB问题直接消失。再说delay卡死常见情况是延时函数依赖SysTick而SysTick又被其他优先级更高的中断反复抢占或者延时函数里使用的是未被初始化的时钟源。如果代码里只有裸机逻辑delay一般在while循环里执行此时要检查延时函数是否自己清除了计数标志否则会一直死等。中断导致的卡死更隐蔽。有人喜欢在HAL_UART_RxCpltCallback里做字符串匹配、显示状态机跳转甚至直接调用HAL_UART_Transmit发送应答表面上代码运行没报错但系统实时性已经崩了。正确的做法是在回调里把收到的字节塞进缓冲区然后置一个标志位主循环检测到标志位再去做耗时操作。这样才能保证串口接收不丢包、其他中断不被饥饿。5.4 下载与USB识别问题下载相关的问题很多其实是环境问题。Keil5编译通过但下载失败先看调试器配置是否选对了用的是ST-Link就选ST-Link用的是J-Link就选J-Link还要确认芯片型号和Flash容量是否匹配。报错“No target connected”时绝大多数是接线问题或者调试器驱动问题。STM32的SWD只需要SWDIO、SWCLK、GND三根线把这三根核对一遍多半就有反应了。电脑无法识别USB设备这个问题常见于刚接触STM32开发板的人群。CH340、CP2102这类USB转串口芯片需要安装对应驱动ST-Link V2也需要装驱动Win10/Win11很多版本会自动装但也有识别不了的情况这时去设备管理器看有没有带感叹号的设备有的话就手动指定驱动目录安装。再一个坑就是USB线很多线看着一模一样实际上只有充电能力没有数据传输能力换一根已知能传数据的线往往立刻解决。5.5 关于其他品牌串口屏的友情提醒市面上串口屏品牌不少玩法差异很大。比如大彩串口屏用的是以0xAA开头的帧结构并且有一个完整的Lua脚本体系而淘晶驰走的是文本指令协议。这两者看起来都能“用串口发指令控制屏幕”但协议栈完全是两套不能互相套用。之前有朋友改用大彩屏写了个编译不通过的Lua脚本排查了半天才发现是固件版本和上位机版本不匹配。所以项目如果存在换屏的可能我建议在选型阶段就确定好品牌然后牢牢绑定对应文档别想着临时切换。从通信角度看不管什么品牌的串口屏核心逻辑都是“数据帧正确、参数匹配、电源稳定、时序可靠”。只要把这四件事抓好换品牌只是换了一套指令格式而已上手成本并不会太高。我个人在实际项目里的体会是STM32加淘晶驰串口屏这套组合最大的价值不是省掉了画界面的功夫而是把嵌入式系统里最占用精力的“显示”拆了出去让整个项目可以并行推进极大降低联调难度。通信链路看着简单但物理接线、参数匹配、上电时序、中断处理这几个环节环环相扣任何一个地方出问题表象都可能是一句“屏幕没反应”。真到排查的时候反而要按部就班、一层层拆。最后再分享一个我常用的调试小技巧先用USB转TTL模块连接屏幕在电脑上把屏端所有功能验证完毕再接STM32去调。这样一旦出现问题你能瞬间判断是屏的问题还是单片机侧的问题节省的时间是实实在在的。这套方案我后来连续用在了好几个项目里从温湿度计到环境监测终端没有一次让我失望过。