除湿机彩屏方案落地：LT165A驱动2.8寸320X240屏的关键要点

梅雨季一过除湿机的需求就起来了。这个品类对显示屏的要求并不算苛刻要显示当前湿度、目标湿度、运行模式、水箱状态晚上最好能自动暗一点故障时给个明确提示。可真正做过这类产品的人都知道难点往往不在“屏幕能不能亮”而在另一件事这块屏由谁来画、由谁来管、以后改版时到底要动哪里。现在很多除湿机显示方案都在往 LT165A 这类显示主控配合 2.8 寸 320X240 彩屏的方向走看起来只是把段码屏换成一块小彩屏本质上是把显示逻辑从整机主控里拆了出去。这个选择改的不是屏幕规格而是整机的开发节奏、改版成本和现场调试方式。1. 先回答一个问题除湿机到底需不需要一块彩屏1.1 不要拿手机和汽车屏的逻辑来套家电屏我见过不少产品定义一上来就提“要高清、要全贴合、最好带触摸”但等样机做出来用户真正天天看的还是那两三个数字和状态图标。家用除湿机不是娱乐设备它是一台“状态显示型”机器。用户站在两米外扫一眼先看到当前湿度高不高再判断要不要调模式。这种场景下4K、高刷新率、千万色彩全是无效参数。真正需要的是三件事湿度数字足够清楚运行状态能直观区分故障和提醒不会被忽略。能做到这三点的显示方案并不一定要从手机方案里迁移。一块 2.8 寸、320X240 分辨率的 TFT 彩屏放在除湿机面板上尺寸刚好信息密度也刚好驱动起来还不会吃掉太多主控资源。1.2 段码屏和数码管为什么开始不够用了传统除湿机常用段码屏或数码管成本低、可靠、开发也简单。但越往后做越会发现一个尴尬产品功能一多段码屏的固定图标就开始不够用。你要加“滤网清洁提醒”段码屏上可能没有这个丝印你想把“除霜中”和“水箱满”用不同颜色表达段码屏做不到你想在深夜把亮度降到很低数码管要么太刺眼要么干脆关掉没法看。彩屏解决的不是“好看”是“可变化”。同一个位置既能显示湿度也能显示故障代码还能提示滤网状态不需要改面板丝印不需要重新开模。这也是为什么很多中高端除湿机会选择 LT165A 这类方案搭配 2.8 寸 320X240 TFT 屏把显示内容变成软件资源产品迭代时只改 UI 和字库硬件改动被尽量压缩。判断一个除湿机项目是不是真需要彩屏先别看颜色数量先看产品定义里有没有“同一块面板需要承载多种可变提示信息”这个需求。2. 2.8寸320X240方案不等于“加一块小屏”先从显存与接口说起2.1 算清楚一帧图像要占多少存储很多人以为换彩屏就是把 MCU 换成性能高一点的再买一块现成模组接上去。但 320X240 这个分辨率放到低成本的嵌入式主控上第一个拦路虎就是显存。分辨率是 320×240像素点共 76800 个。如果采用 RGB565 格式一个像素占 2 字节整屏数据约 153600 字节折算下来接近 150KB。如果采用 RGB888一帧高达约 225KB。对于很多家电主控来说内部 RAM 通常只有几十 KB连存放一帧完整的图像数据都很吃力更不要说一边刷新屏幕一边跑除湿机主逻辑。这恰好是独立显示方案存在的原因。LT165A 这类显示控制方案无论它是一颗独立芯片还是一块串口屏模组的控制核心它在链路里承担的核心任务就是把主控从“管理彩色图像数据”这件事里解放出来。面板显示、图层叠加、局部刷新、帧缓冲都由显示侧处理整机 MCU 只需要告诉它“当前湿度是 62%”“机器正在除霜”这些业务信息。具体到 LT165A 内部有没有内置帧缓冲、外部需不需要挂 SPI Flash 存储图片字库要看对应厂家的手册。但工程判断可以先做凡是给你屏幕背后一颗专门画图的控制核心都比让主控直接刷点阵更合理。2.2 接口选择的第一原则先看主控能留出多少 IO2.8 寸的 320X240 TFT 屏常见接口有 SPI、8080 并口、RGB 接口少部分还带 MIPI。但在小尺寸家电屏上SPI 和并口出现频率更高。接口类型连线数量刷新速度主控负担适用场景SPI少通常 6 根内中等较小显示内容简单、更新不频繁8080 并口较多8/16 根较快较大需要频繁刷新或图形变化多RGB多需要显示控制器快很大通常用于中大屏或带独立控制器的方案MIPI最多时序复杂很快很大手机类高分辨率屏家电小屏很少用实际选型里很多除湿机显示方案用的是 SPI 或并口模组再在前面放一颗显示控制核心。主控 MCU 通过 UART 或者 SPI 与显示核心通信显示核心再驱动 TFT 面板。这样整机主控的引脚资源占用少布线压力小后续换屏也不至于重新画整机主板。除了接口还要考虑背光和电源。2.8 寸彩屏的背光电流不算大但除湿机会长时间上电背光一直亮着加上机器内部有压缩机、风机、蜂鸣器上电瞬间电流波动明显。把背光电源单独留一路用 PWM 控制调光并做好上电延时比依赖面板默认背光电路要稳妥。3. 除湿机 UI 怎么做才不浪费这块彩屏3.1 320X240 的空间里先做减法再做加法2.8 寸屏幕物理尺寸不大如果按手机 App 的思路排版把文字、图标、卡片全堆上去用户在正常使用距离根本看不清。除湿机的 UI 设计信息层级一定要比手机界面更硬朗。我给这类产品做信息分级时会先把所有要显示的内容分成三级一级信息当前湿度必须最大字号显示一眼可见。二级信息目标湿度、运行模式、风速、定时用图标加少量文字。三级信息故障代码、水满提示、滤网清洁、版本号平时不出现出现时要有告警感。一级信息放在屏幕视觉中心二级信息围绕边缘排布三级信息用弹窗或整页提示。主界面维持一屏就能看完不要搞多级菜单。除湿机的交互频次很低用户不会像玩手机一样去翻二三级页面把“设置湿度”和“模式切换”做成两三个键能到达的页面就好。如果产品定义确定要加触摸2.8 寸屏幕上也要保证按钮热区尺寸合理。按键目标不宜小于 48×48 像素否则手指点按成功率会很差。但除湿机本身按键频率低我个人更建议保留实体按键触摸不是必选项尤其在水汽和潮湿环境中实体按键的可靠性通常更好。3.2 字库和图片资源才是隐形成本大头彩屏 UI 开发最容易低估的不是画图而是字库和素材资源。320X240 屏上如果要用中文显示状态信息就要面对中文字库的体积。粗略估算一下一个 16×16 点阵汉字占 32 字节如果只收录实际用到的 80 个汉字只占约 2.5KB如果把 GB2312 一级字库 3000 多字放进去就要占上百 KB如果把完整字库和不同字号都放进去Flash 压力会非常明显。这就是为什么彩屏方案里通常不把 UI 资源全部交给主控 Flash而是让显示控制侧挂独立 SPI Flash 或者通过烧录工具更新资源。LT165A 这类方案在落地时要有意识地把“固件代码”和“UI 资源包”分开管理。界面字体建议优先使用专用点阵字库而不是嵌入 TrueType 字体解释器图片素材尽量压缩成适合小屏的索引色或 RGB565 格式不要直接放 24 位 BMP。资源类型典型单页占用影响16×16 点阵汉字 100 个约 3.2KB基本菜单提示够用GB2312 常用汉字 3000 个约 96KB可以做较丰富信息全字库较大小容量 Flash 放不下通常不推荐一张 320×240 全屏 RGB565 图片约 150KB一次显示刷新占资源图标/小图若干每张 1KB~8KB尽量使用小尺寸图标所以 UI 设计时要先约定“只用固定词组”不要做任意文本输入或动态拼接长句。除湿机显示“当前湿度”“目标湿度”“水箱已满”“除霜中”这类短语全部做成预置词条显示侧收到编号后直接显示对应字串。这个规则能节省大量 Flash也降低显示程序出 bug 的概率。4. 关键一步用串口协议把“画图”变成“改值”4.1 直接传点阵是最笨的做法如果主控和显示侧之间用串口通信最不推荐的做法是把整屏像素数据发过去。原因很简单一张 320×240 的 RGB565 全屏数据是 150KB就算 UART 波特率跑到 115200每秒约 14.4KB传一帧满屏数据也要 10 秒以上。除湿机界面又不是视频完全没必要这样刷。真正适合的通信方式是“命令 模板页 变量刷新”。显示侧先把常用页面、图标、数字位、字符位封装成模板主控只用极短数据帧通知显示侧“切到第几页”“某个数据显示什么”。例如主界面上的湿度数字并不是一幅单独的图而是一个可更新文本区域。主控发现当前湿度从 65% 变成 63% 时只发送一条“把湿度值设置为 63”的指令显示侧把那个位置重新画一遍即可。整个过程不到几十字节串口压力几乎为零。4.2 一个最小可用帧协议该怎么设计我在实际项目里会先定义一套极简的通信协议结构不复杂但必须具备可扩展性。常见的帧结构示例如下// 帧格式示意具体协议以实际方案手册为准 // [帧头 0xAA 0x55] [命令字] [数据长度] [数据] [校验和] [帧尾 0x0D 0x0A] #define CMD_SET_HUMIDITY 0x01 // 设置当前湿度显示 #define CMD_SET_TARGET_HUM 0x02 // 设置目标湿度显示 #define CMD_SET_MODE 0x03 // 设置运行模式 #define CMD_SET_FAULT 0x04 // 设置故障代码 #define CMD_BEEP 0x05 // 控制蜂鸣器 #define CMD_SWITCH_PAGE 0x10 // 切换页面 #define CMD_HEARTBEAT 0xF0 // 心跳握手主控发送一条设置湿度指令时可以这样封装void uart_send_cmd(uint8_t cmd, uint8_t *data, uint8_t len) { uint8_t buf[64]; uint8_t i; uint8_t sum 0; buf[0] 0xAA; buf[1] 0x55; buf[2] cmd; buf[3] len; for (i 0; i len; i) { buf[4 i] data[i]; sum data[i]; } buf[4 len] sum; buf[5 len] 0x0D; buf[6 len] 0x0A; uart_send_bytes(buf, 7 len); }对应的数据可以是一个表示湿度的字节比如 65 代表 65%uint8_t humidity 65; uart_send_cmd(CMD_SET_HUMIDITY, humidity, 1);这个结构很简单但已经能覆盖除湿机 80% 的显示需求。真正复杂的是页面状态机比如“正在除霜”时要同时锁定部分按键、显示特定图标这需要整机主控和显示侧约定一套状态命令让显示侧的模板页面能根据状态位自动显示对应图标而不只是被动地画某个数字。4.3 协议里最容易忽略的几个边界第一波特率要固定不能随意改。显示侧如果基于串口中断接收波特率误差大时偶发丢字节排查起来非常隐蔽。整机联调时先确认两端波特率一致。第二电压域要一致。如果整机主控是 3.3V显示模组接口也尽量用同电平标准必要时加电平转换。不要把 5V 信号直接灌进 3.3V 管脚很容易造成长期可靠性问题。第三通信异常不能造成 UI 永久卡住。主控开机后通常会给显示侧发初始化指令和心跳包显示侧长时间没收到有效数据可以设计超时回到待机页或保持当前状态不要让界面停在半空。协议设计原则不是把所有 UI 细节都暴露给主控而是只暴露业务需求变化的部分。主控只关心“现在湿度多大、处于什么状态”不关心这个图标在屏幕上的 x、y 坐标。5. 从样机到量产这类彩屏方案最容易踩的坑都在现场5.1 上电瞬间背光闪烁、白屏后重启不一定是屏坏了除湿机里有压缩机、风机继电器吸合瞬间会让电源产生跌落。如果背光和显示主控共用一个电源继电器一动作屏幕可能先闪一下、花一下甚至重启。遇到这种现象先不要怀疑面板。按这个顺序排查先把背光供电和逻辑供电分开再给背光增加软启动或延时上电逻辑看主控和显示侧之间的地线是否足够粗最后确认主控复位和显示复位时序不要让显示侧在电源不稳时就被初始化。很多“白屏”问题其实是主控和显示侧两端复位时序不一致造成的。5.2 高湿环境对排线和板面工艺有隐性要求除湿机工作环境湿度比普通家电高有时还会有凝露风险。2.8 寸 TFT 屏使用的 FPC 排线非常细密如果没有固定好开合、振动、湿气侵入都有可能出现接触不良、显示暗线或按键乱跳。量产设计里要保证 FPC 连接器锁紧PCB 走线区域根据环境决定是否涂三防漆屏背面的金属背板要做好接地。显示板不要直接放在压缩机上方高温和高湿叠加会加速器件老化。5.3 花屏、条纹、闪烁按从供电到时序的顺序排查花屏很少只有一个原因。我常用的排查链路是看电源纹波示波器量显示侧 3.3V 和背光供电是否在继电器切换或蜂鸣器响起时大幅跌落。看排线连接和地线FPC 是否插到位、压紧显示板和主板之间的地线是否单点悬空。看显示初始化时序是不是主控和显示侧上电时间不同步导致寄存器初始化失败。看 SPI/刷屏频率并口和 SPI 速率是否过快走线过长导致信号质量差尝试降低频率验证。最后才怀疑屏本身可以通过单独使用厂家测试 Demo 板排除。单独建议一句改初始化参数前先保留一份“原始能显示”的版本。很多时候不是新代码逻辑错了是初始化参数被复制到别的项目里忘改。5.4 中文显示成方块或乱码不要先怀疑硬件彩屏上出现“□□□”或乱码大概率是编码不一致或者字库不匹配。主控发送中文内容时内部使用 GBK/GB2312显示侧可能按 UTF-8 解析或者显示侧字库里根本没有这个汉字。排查顺序是先看编码格式再看字库是否包含该字符再检查发送的字符串是否被截断。为了规避这类问题我更推荐界面词条编号化。主控不直接发中文字符串而是发一个词条编号显示侧根据编号查表显示对应汉字。比如 0xA1 代表“滤网清洁”0xA2 代表“除霜中”。这样主控不关心字库显示侧也不担心乱码。5.5 亮度不能只做最高档PWM 频率低了会闪彩屏在室内使用背光全亮既刺眼又费电。除湿机最好设计成多档亮度白天高亮夜间检测到低照度或定时进入“睡眠亮度”甚至关闭彩色部分只保留低亮度背光。如果亮度调低后有肉眼可见闪烁往往是背光 PWM 频率太低通常把 PWM 频率提高到 1kHz 以上会有明显改善具体频率要看屏的背光驱动方案。5.6 产线测试不能只看“能不能显示”量产阶段最怕“样机好好的产线十台里有两台花屏”。根源往往不是屏的一致性而是测试流程不完整。最好把产线测试项拆成显示功能测试能否正常进入主页温度湿度数字是否变化故障显示测试模拟水满、故障代码确认对应的提示图标和告警色能出现背光测试高低亮切换是否正常离散性测试连续上下电 20 次以上确认上电初始化稳定老化测试工厂老化房里跑几小时看是否有花屏、闪烁、字库显示异常。6. 适合谁用、不适合谁用用一张清单说清楚6.1 适合使用这类方案的产品特征LT165A 2.8寸 320X240 这类彩屏显示方案本质上适用于“信息有变化、要分组、要告警、需要中文提示”的嵌入式设备。除湿机是典型场景但它并不局限于除湿机。同类的加湿器、新风机、热水器、净水器、小型暖通设备很多都可以沿用这套思路。适合的特征包括面板需要同时显示多个状态且状态之间有优先级需要把错误信息用图标、颜色、提示语表达减少用户误判产品定义还在迭代后续可能要增加新功能显示位整机主控性能不强不希望因为显示功能升级而换更高成本的 MCU项目团队里没有专职 GUI 工程师希望用串口命令把显示层隔离出去。6.2 不适合的场景也要说清楚不是所有除湿机都应该上这块屏。如果是超低价引流款成本和 BOM 编号越少越好段码屏仍然够用。如果产品定位是户外强光下使用2.8 寸小屏的亮度通常拼不过强光反射需要更高亮度屏或加遮阳设计。如果设备需要在极低温或高可靠性场景下连续工作还需要确认屏的工作温度范围和整套方案的防护等级。判断维度更适合彩屏方案可能更适合段码屏或无屏产品定位中高端、功能多、UI 要差异化低端走量、只显示基础状态信息量多个模式、告警、水位、定时固定图标加数字即可开发资源能承担显示侧开发和调试成本希望一次开发长期不改环境要求室内找稳态环境高低温、强光、长寿命极严苛迭代节奏后续可能增加新功能产品定义已冻结选择这块屏并不是“越贵越好”。真正的判断依据是你的产品是否需要在不变面板的情况下持续变化内容。如果是彩屏方案省下的是模具、丝印、印刷流程和主控升级成本如果不是那多出来的每分成本都是浪费。6.3 选型前先回答三个前置问题第一整机主控能留出多少个引脚多少路串口如果用 UART 做显示通信需要空的 TX/RX 管脚和稳定电源。第二你的数据更新频率是多少除湿机的湿度温度变化很慢这个方案完全适配如果要做动画或游戏类界面就要重新评估。第三后续屏资源由谁维护如果显示侧素材更新需要烧录器能够方便地在产线实现吗这些做不到开发效率再高也走不到量产。7. 更推荐的落地顺序先跑通单板再谈产品化7.1 第一步先把单板 Demo 跑起来不接整机主控拿到显示方案后不要急着把它焊进整机里联调。先把 2.8 寸屏和显示主控接好后用 USB 转 TTL 模块连接电脑通过串口助手手动发送几条指令确认这些事屏幕背光能否正常点亮初始页面能否显示中文词条显示是否正常有没有乱码切换页面、修改湿度值、触发故障提示等命令是否正确点亮数小时后屏体和驱动芯片温度是否正常。把这一阶段当作用户验收来对待。显示侧与整机主控无关时才方便定位真正的问题在哪个环节。7.2 第二步整理一张整机数据字典除湿机在运行中会出现哪些变化、哪些状态、哪些故障很多人是在写代码时想到一个加一个导致显示侧命令越来越乱。更推荐的做法是先列一张数据字典数据名称类型取值范围默认值触发条件当前湿度uint80~100%50%每次采样值变化目标湿度uint830%~80%50%用户设置变化运行模式uint80~40模式切换水满状态bool0/10水位开关变化故障代码uint80~90故障条件成立滤网清洁提醒bool0/10累计运行时间达到阈值这张表就是你设计通信协议、页面模板和显示控制状态机的依据。没有这张表前面定义的帧协议很容易在项目中途长出发散的命令。7.3 第三步UI 设计和页面模板要并行定版UI 设计师不要等硬件全部稳定后才开始画图。更高效的做法是在单板 Demo 跑通后马上拿一张纸或画图工具把产品经理关心的一、二、三级信息放到 320X240 的框里确定每个区块的尺寸尤其是大数字湿度的位置。这一步要从像素级考虑资源湿度数字用多大的字体一页能显示几行中文图标是否需要在不同状态下变色。尽量在模板阶段确定所有状态组合不要等代码写完再让 UI 去填新位置否则资源包和字库要反复调整浪费时间。7.4 第四步写一个回归脚本模拟整机状态变化整机主控程序还没写完的时候可以先用一个 PC 端脚本或者测试单片机按照运行逻辑自动发送串口命令开机、显示当前湿度、湿度逐步下降、目标湿度达到、风机停止、水满、倾倒水箱、继续运行、故障恢复。把每一次状态变化对应的预期显示记录下来最后对照验收清单检查界面是否和预期一致。这个脚本最大的价值是帮你验证长期稳定性。除湿机用户也许一天只操作几次但机器可能连续运行几周。显示侧长时间不刷新、反复更新数值、报警触发又恢复这些操作要能在调试阶段跑出足够多次才能更早发现问题而不是等问题出现在用户家里。7.5 把这套流程沉淀成下一次可复用的基线如果这块屏的方案验证成功得到的不只是一台能显示的样机还有一套可以复用的协议模板、UI 资源规划方法、产线测试项目和排查路径。此后再出来湿机、新风机、热水器项目只要显示规模变化不大整机主控侧的通信代码可以相对低成本地迁移显示侧模板和字库也可以沿用。长期价值就在这里它不是一次性接一块屏而是让“给设备加一块彩屏”变成一项标准化工作。回到最开始的问题除湿机真正的产品竞争力并不是“有一块彩屏”而是用户需要从屏幕上最快看懂机器的状态。LT165A 配 2.8 寸 320X240 这类方案把显示从主控的底层任务里抽离出来让主控专注于环境控制和压缩机管理让显示侧专注于界面呈现。选择这种方案前最该想清楚的不是分辨率高低而是你愿不愿意花精力把显示工作流单独梳理清楚。先跑通一个单板再做数据字典再定 UI 模板最后回归量产测试这条路走下来很多“屏幕能不能用”的焦虑其实都会变成可验证、可修改、可复用的工程细节。