3 个阶段让老 Mac 跑上最新 macOS：零固件改动指南
2026/9/14 18:38:23
除湿机彩屏显示方案，最近被问到的比较多的是 2.8 寸 320×240 这一档配置，LT165A 在很多屏厂和方案商那里是屏幕模组的识别型号。整体看下来，这类方案解决的实际问题不是“把数码管换大一号”，而是把除湿机当前湿度、目标湿度、运行模式、水箱满、化霜、故障码这些状态真正可视化。除湿机和空调不一样，它放在阳台、卫生间、地下室，面板状态直接影响用户判断机器现在到底在干什么。彩屏能显示汉字、能分页面、能弹故障窗口，这是数码管做不到的。下面按我实际评估这类方案的顺序，把架构判断、界面规划、主控对接、联调排查和选型边界拆开讲。
1. 除湿机从数码管换彩屏，换的不是显示方式，而是交互逻辑
1.1 一台除湿机要显示的信息比想象中多
很多项目早期用两位或三位数码管，觉得显示一个湿度就够了。真正做整机定义时才发现，用户想知道的东西远不止一个数字。当前环境湿度、设定目标湿度、当前温度、运行模式、风速档位、定时剩余时间、水箱满提醒、化霜状态、童锁状态、滤网清洗提醒，还有压缩机故障、传感器故障、通信故障等异常代码。
一套完整的除湿机显示页面，核心信息至少有这样几类：
- 主状态：待机、运行、达到目标湿度停机、化霜中、水满停机、故障停机。
- 环境数据：当前湿度、当前温度。
- 用户设定：目标湿度、模式、风量、定时时长。
- 提醒信息：水箱满、滤网清洗、自清洁过程、故障码。
如果用数码管，这些含义只能靠固定图标、闪烁和几段数字拼出来，用户看到“E1”还要翻说明书。彩屏可以直接写“水箱已满，请清理”“正在化霜，请稍候”，学习成本几乎是零。
1.2 320×240 能不能装下这些内容
2.8 寸、320×240 分辨率，在手机屏幕里当然不算高，但放到除湿机前面板上足够用。因为除湿机交互并不复杂，不是要展示大幅图表，而是要把几个关键数字和状态说清楚。
我一般建议把显示内容按信息等级拆三层：
第一层是当前湿度和运行状态，必须大字号、高对比，用户在三四米外能扫到主要信息。
第二层是目标湿度、模式、风量，放主页面中下部或做成轻量控件。
第三层是故障码、版本号、滤网累计时间这类低频内容，放到专门状态页或弹窗里，不需要常驻。
320×240 做主页面时，最稳妥的布局是“大数字居中 + 两侧状态图标 + 底部文字区”。不要在这么小的屏幕里塞进度条、曲线图和一堆装饰元素。信息密度太高，字号必然变小，反而失去了彩屏的意义。
1.3 屏幕只能显示状态，不能替代主控逻辑
这里要提前说一个边界：彩屏再清晰，也解决不了湿度传感器不准、压缩机起停逻辑混乱、水箱检测失效的问题。显示方案的职责是把主控已经判断好的状态呈现出来，传感器采集、湿度回差、压缩机三分钟延时保护，仍然要由主板完成。
所以做项目时，页面里“正在启动，压缩机延时中”“湿度达到设定值，待机”这类提示，必须由主控明确上报，不能靠屏幕自己猜。否则用户看到屏幕黑着或一直显示运行中，投诉率会很高。
2. 用 LT165A 之前，先分清它属于哪种屏端架构
2.1 小家电彩屏常见的三条技术路线
同样是 320×240 的 2.8 寸屏幕，硬件架构不同，开发方式差别非常大。很多团队踩坑，就是拿到一块屏就开始按“自己刷屏”的老思路写代码，结果方案根本不是那么设计。
先看下面这张对比表：
| 技术路线 | 屏端是否有独立处理单元 | 主控负担 | UI 修改方式 | 适合场景 |
|---|---|---|---|---|
| 主控直驱 TFT，自己画界面 | 通常没有 | 高，要刷像素、管图形库 | 改主控代码，重新烧录固件 | 主控资源强，团队想完全掌控界面 |
| 串口指令屏 | 有，板载控制器 | 低，按通信协议发送指令 | 固定控件或指令页切换 | 界面相对固定，改动不频繁 |
| 集成 UI 引擎的屏控方案 | 有，且内置字库、图片资源和界面状态机 | 很低，只上报变量和事件 | 上位机工具改 UI，再下载资源包 | 除湿机这类机型多、界面调整频繁的产品 |
LT165A 从项目标题的命名习惯看，更像是屏厂或方案商给整套显示模组编的产品型号，而不是某颗通用主控型号。它大概率是把 TFT 面板、驱动电路、存储资源和界面处理能力整合在一起卖给整机厂的方案。遇到这种方案，最容易犯的错就是拿它当普通 SPI 屏直接刷像素。
2.2 如果屏端自带 UI 处理能力，开发方式会怎么变
如果确认 LT165A 是集成了 UI 引擎的屏控方案，那主控端的工作模式和直驱屏完全不同。
- 主控不再需要刷整屏、画矩形、显示文字，这些都由屏端完成。
- 主控只需要把“当前湿度 65%”“运行模式自动”“水箱已满”这类变量通过串口或其他接口发给屏幕。
- 界面切换、图标变化、开机动画、故障弹窗，由屏端根据变量和内部状态机执行。
这个转变很重要。主控端代码会简单很多，原先最占资源的显示模块整个砍掉，主控选型压力下降。但代价是主控和屏幕之间不再是“显示”关系，而是“通信”关系。联调时看的不是像素对不对，而是变量有没有发到位、事件有没有及时触发。
2.3 拿到方案后，先要这三样东西
在写任何代码之前，先找屏厂或方案商确认以下三件事：
- 完整的接口定义和电气规格，包括供电电压、通信接口、复位时序、背光控制方式。
- UI 设计工具或资源下载工具，搞清楚界面素材是由谁画、谁烧、怎么更新。
- 通信协议文档，也就是主控和屏端怎么交换数据。
如果这三样拿不全，不要急着做界面。否则后面每改一版画面都要等供应商配合，项目周期会非常不可控。我的习惯是：先请屏厂提供一套能上电运行的 Demo 工程和通信例程，哪怕画面是厂家通用模板也行，先确认链路能通。
3. UI 设计阶段要把资源算清楚，别等到联调才改
3.1 主页面布局建议
2.8 寸屏幕在整机面板上视觉占比不大，主页面必须做到“一眼能读懂”。我会按下面顺序排内容：
最上方放状态栏，包括 WiFi 或智能联动状态、童锁、滤网提醒这类低频小图标。
中间区域是主角，当前湿度用超大字号，旁边写“当前湿度”，单位 %RH。如果主控有偏差补偿，屏幕上显示的值和传感器原始值可能不同，这一点要提前和主控对齐。
中下部显示当前模式、目标湿度、风速、定时。设定操作最好做成一整块可点击区域，点进去是设置页，而不是让用户在主页面反复点加减号。
最下方留一条动态文字区，用来显示“正在除湿”“达到设定湿度”“化霜中”“水箱已满”等瞬时状态。这个区域比固定图标更重要，因为它能直接用文字告诉用户发生了什么。
3.2 图片和字库占多少 Flash，先算一笔账
很多小家电项目的主控 Flash 很紧张，如果屏幕方案的图片和字库放错了位置，导致资源包过大，烧录和升级都会变得很难受。
先按 320×240 的 RGB565 格式估算：
- 一张满屏背景图，约 320 × 240 × 2 = 153600 字节，也就是 150KB 左右。
- 一个 48 × 48 图标，约 4.5KB。
- 一个 32 × 32 图标，约 2KB。
- 16×16 点阵的常用汉字字库，如果只放几百个汉字，占用可以控制在几十 KB；如果放完整 GB2312 字库，体积会到 200KB 以上。
所以页面设计一开始就要确定：是每页都放一张全彩背景，还是用纯色背景加少量图标控件。个人建议优先走“背景尽量简单 + 控件局部替换”的路子，这样 UI 资源包不会因为多加了几个页面就迅速膨胀。
另一个细节是字库子集。除湿机显示内容非常固定，需要出现的中文无非是“当前湿度、目标湿度、自动、手动、干衣、睡眠、风速、水箱已满、化霜、定时、童锁、清洗滤网”等几十个词。完全可以只用自定义子集字库，不需要动不动就烧全字库。
3.3 页面状态机先定下来，再画页面
彩屏方案最怕的是页面乱跳。主控上报一个水满，屏端应该切到水满提示页还是主页面加弹窗？这必须有明确归属。
我会先列状态清单：
- 待机页：机器未启动，显示当前环境湿度。
- 运行主页面：显示除湿过程中的各项数据。
- 设置页：调节目标湿度、模式、风速、定时。
- 提示页或弹窗：水箱满、化霜、滤网提醒、自清洁。
- 故障页：显示故障码和简单说明。
状态和状态之间，谁发起切换要写清楚。比如水箱满必须从任意页面弹出提示，并在水箱清理完成、主控上报清除信号后才能消失。化霜提示只出现在运行主页面顶部，不强制打断设置操作。这些规则要在协议变量表里能映射出来，而不是靠屏端自己猜。
3.4 配色和夜间使用要注意什么
除湿机经常放在卧室、书房，夜间运行是常见场景，屏幕不能像广告灯箱一样刺眼。
建议至少配置两档背光：白天的亮度可以 80% 以上，夜间运行自动降到 30% 左右，并且提供 10 到 60 秒无操作自动熄屏。很多除湿机面板附近有环境光传感器，没有的话就用主控定时熄屏。
配色方面，白色或浅色背景在室内灯光下更清晰，但夜间会偏亮。深色背景对比度高，但对图标和文字的描边要求高。小尺寸面板我更倾向浅色背景方案，图标用彩色、数字用深色，整体的科技感也不会差。
4. 主控和屏端对接：变量表、刷新周期、故障上报
4.1 先把变量表定下来
屏端做得再好，主控不知道发什么，联调时依然会乱。做除湿机彩屏方案，最重要的一张表就是主控和屏幕之间的变量表。
可以先按下面这个思路建表：
| 变量名 | 含义 | 数据类型 | 取值范围 | 更新条件 |
|---|---|---|---|---|
| current_humidity | 当前湿度 | 数值，0.1%RH | 0 到 1000 | 湿度变化大于设定阈值时上报 |
| current_temp | 当前温度 | 数值，0.1℃ | -200 到 600 | 周期上报，例如 30 秒 |
| set_humidity | 目标湿度 | 数值，0.1%RH | 300 到 800 | 用户设定改变时上报 |
| mode | 运行模式 | 枚举 | 0 自动 1 连续 2 干衣 3 睡眠 | 模式改变时上报 |
| fan_speed | 风速档位 | 枚举 | 0 低 1 中 2 高 | 档位改变时上报 |
| water_full | 水箱满 | 布尔 | 0 正常 1 满 | 状态跳变立即上报 |
| defrost | 化霜中 | 布尔 | 0 否 1 是 | 状态跳变立即上报 |
| fault_code | 故障码 | 枚举 | 0 无故障，其他按产品定义 | 故障发生和恢复时上报 |
| timer_remaining | 定时剩余 | 数值，分钟 | 0 表示无定时 | 每分钟更新或剩余时间变化时上报 |
上面只是示例，具体字段和编号要以实际协议文档为准。目的是让主控开发、屏端开发和整机测试看到同一套语言。
4.2 上报频率怎么定
除湿机湿度变化是很慢的过程，不需要每秒钟刷一次。湿度显示更新太频繁反而会造成视觉跳动，比如 65.3%RH 和 65.4%RH 反复跳，用户会以为机器不稳定。
建议以 0.5%RH 或 1%RH 为单位做变化上报，湿度稳定时 3 到 5 秒一台即可。温度更慢，30 秒甚至 1 分钟一次都可以。但运行状态、水箱满、故障码这类事件，一旦发生必须立即上报，不能等下一个周期。
这里要提醒一点：屏幕显示的是一个“观察结果”，不是实时流媒体。主控要把湿度变化先做合理滤波和变化量判断，再由屏幕更新，而不是把原始采样值直接丢给屏幕。
4.3 水箱满和故障码必须主动上报
从实际售后经验看，除湿机最容易被用户误解的是两种状态：一是水箱满了但机器还在响，二是机器在化霜但用户以为坏了。
主控检测到水满后，应立即把 water_full 置位并上报。屏幕收到后显示“水箱已满，请清理”，同时最好配合蜂鸣器短促提醒。水满状态清除后，要发一个恢复正常事件，屏幕才能退出水满提示。这中间如果通信有丢帧，屏端会一直卡在提示，所以需要屏厂协议里带确认机制或重发机制。
化霜同理。低温环境下，除湿机蒸发器容易结霜，需要周期性进入化霜状态，此时压缩机停、风机不一定停，用户会看到机器开着但湿度没下降。若不提示，第一反应就是机器坏了。屏幕显示“化霜中，请稍候”，售后压力能小很多。
4.4 触摸和实体按键的事件归属
有些除湿机面板是触摸屏，有些则是机身实体按键加显示彩屏，还有两者都有。这个要提前想清楚：
- 如果操作全部在屏幕触摸完成，主控不用管按键扫描，但电源开关这类关键操作要设计防误触，比如长按 2 秒。
- 如果显示归屏幕、控制仍归机身物理按键，按键事件应该在主控处理，主控再下发状态给屏幕显示，屏幕不能自己假设按键功能。
- 如果触摸屏既要显示又要控制，触摸事件由屏端上报给主控，主控判断当前状态是否可以执行，比如水箱满时不允许继续除湿，屏幕仍然可以查看设置。
事件归属不清，最常见的结果是屏幕显示“定时 2 小时”，但主控根本没有计时，用户看着屏幕却控制不了机器。这种问题在整机测试阶段才会暴露，返工成本很高。
5. 联调阶段的异常，按现象分层排查
5.1 屏幕显示异常，先分清是哪一种
联调时最常见的现象就是白屏、黑屏、花屏、背光亮但没内容。先别急着怀疑屏幕质量，按下面顺序排查：
| 现象 | 优先排查方向 |
|---|---|
| 完全黑屏 | 背光电源、背光使能引脚、背光电压 |
| 白屏 | 屏端主控有没有正常启动、复位时序、初始化是否完成 |
| 花屏、文字错乱 | 通信速率、信号电平、线序、共地是否稳定 |
| 背光亮但一直无内容 | 主控有没发出首个页面切换指令，屏端资源包是否烧录 |
| 偶发卡死、界面不动 | 通信丢帧、校验失败、屏端看门狗未喂、主控发送频率过高 |
如果 LT165A 这类屏控方案本身负责全部像素渲染，花屏概率通常比直驱屏低。真出现花屏或乱码，先查通信和资源包，而不是去找像素时钟。
5.2 通信层排错，先看日志再看波形
联调第一步，是让主控和屏幕“自报家门”。建议在 Demo 阶段做一个简单循环：主控每隔 3 秒上报一次当前湿度和运行模式，屏幕收到后刷新对应控件。如果界面数字能跟着变，通信链路就通了。
如果数字不变，则检查顺序是：
- 先看主控有没有真正发出数据，串口打印或示波器抓 UART 引脚。
- 再看发的内容编码和协议文档是否一致，特别是帧头、变量 ID、长度、校验位。
- 再看屏端有没有回包，回包内容和协议对不对。
- 如果主控能发、屏幕能收但界面不变，看变量 ID 或页面层级是否绑定错。
不要一开始就怀疑屏端界面设计。很多时候是主控发的湿度值单位不一致，比如主控发整数 655，屏幕按 0.1%RH 显示成 65.5%RH，而界面里放的是 6.55%RH，差别就会很吓人。
5.3 除湿机环境的特殊坑
除湿机使用环境湿度高、温差变化大，屏幕和整机结构之间容易出现结露。面板密封不好，水汽进入屏幕内部，轻则显示模糊，重则 FPC 排线氧化、短路。
结构上要注意：
- 屏幕和前面板之间做密封处理，尽量不让高湿空气直接接触 FPC 连接器。
- 屏幕表面玻璃和外壳之间留出防应力空间，避免拧螺丝过紧导致液晶受压变花。
- 生产阶段要在相对干燥环境存放，避免 PCB 和屏体受潮后直接上电。
电磁干扰也不能忽视。除湿机里有压缩机、继电器、水泵、风机，开机和停机瞬间电流变化大。屏的供电和信号线如果和强电走线太近，可能出现偶发花屏或触摸误触发。联调测试时要把整机放在真实工作状态跑，不能只在开发板上点灯。
5.4 量产前的验证清单
开发阶段跑通 UI 只是第一步。正式量产前，我会重点检查下面几项：
- 连续运行老化测试：页面长时间打开，供电和背光是否稳定。
- 通信压力测试：主控循环发送变量 8 小时以上，有没有屏端死机或变量累计偏差。
- 异常状态测试：水满、化霜、传感器拔出等边界情况，屏幕提示是否正确。
- 掉电恢复测试：运行中突然断电，再上电屏幕能否回到正确页面。
- 触摸校准一致性：同一批屏幕触摸坐标是否存在漂移，必要时做每台校准。
- 固件版本管理：屏幕 UI 资源和主控固件版本要能对应，否则产线混料会造成整机软件不匹配。
资源占用观察也很重要。比如主控 Flash 很小，UI 资源包如果存在主控端，要确认烧录空间足够；如果存在屏端，要确认产线能单独升级屏的资源包，不会每改一个图标就升级整机主控。
6. 选型结论：什么项目适合这套方案，什么项目其实不用上
6.1 适合上 2.8 寸彩屏的条件
如果产品定义里存在下面任一场景，2.8 寸 320×240 彩屏就有价值。
一是多模式多设定。自动、连续、干衣、睡眠加上目标湿度和定时，用户需要频繁操作和确认结果，纯数码管操作路径太长。
二是需要中文化提示。水箱满、化霜、滤网清洗这些提示文字比图标直观得多，特别适合家里老人使用。
三是产品要通过交互做出差异化。相同容量的除湿机，配置大字号湿度显示、夜间自动熄屏和清晰弹窗的产品，现场的体验明显更完整。
四是和智能模块联动。如果整机有 WiFi 或小程序，彩屏上需要显示联机状态、远程设定结果，这时普通段码屏做不了动态反馈。
6.2 不建议上的情况
如果产品只是基础型除湿机，功能上只有开关和连续除湿，没有目标湿度设定，也没有模式切换，上彩屏意义不大。多一块屏幕就多一份 BOM 成本，还要承担 UI 资源和显示驱动的维护工作，入门价位撑不住。
还有一类项目也建议缓一缓：主控端资源和团队经验都不足，但急着要在两个月内出货。彩屏方案的界面美化、协议联调、量产烧录都要时间，仓促上线容易出现显示逻辑混乱、售后问题集中爆发。不如先上成熟的段码屏或串口屏，等第一阶段功能稳定后再升级彩屏。
6.3 平台化复用：同一套协议往其他产品扩展
彩屏方案真正值钱的地方，是可以做平台化复用。除湿机、加湿器、空气净化器、暖风机，交互逻辑高度相似，都是传感器数据加运行状态加用户设定。
做方案时，把主控和屏幕的变量表设计得抽象一些，不要写死成“湿度和除湿模式”，而是定义成“传感器数值”“运行模式”“设置值”“告警事件”等通用字段。换产品时，屏幕界面的图元和布局改动，主控通信逻辑基本不用重写。这样 LT165A 方案可以覆盖一个小家电产品线，而不是只服务一台除湿机。
最后说个建议：不管选什么方案，第一次打样一定要先跑最小链路。用厂家 Demo 点亮屏幕、串口收发变量、切换三个页面，确认链路稳定后再投入界面资源和量产设计。看起来多花了两三天，实际上能避免后面“屏幕动不动就花屏”“界面改一版烧录一次”这种大返工。除湿机彩屏方案的核心不是屏幕有多炫，而是状态表达准确、通信稳定、量产可控，这三点做到了，这个方案才算真正落地。