嵌入式 HMI 怎么做：SPI、并口 RGB、LVDS、MIPI DSI 的带宽计算与适用区间，触摸点亮，以及 LVGL、Linux 还是 Android 的选择。
嵌入式 HMI（Human-Machine Interface，人机界面）——产品通过屏幕、触摸与按键呈现给使用者的那一层——通常被当成软件问题来讨论。实际上它首先是个硬件问题。多数带屏产品，屏是最后才定的——定完主控、定完外壳构想，有时连工业设计都签完了才回头选屏。这个顺序是反的。面板的接口决定了哪些主控还在候选名单上、板子需要多少引脚和层数、软排线能拉多长、点亮背光后的功耗预算什么样，以及软件栈能不能只是几百 KB 的 LVGL，还是必须上完整的 Linux 或 Android。
我们做过的显示方案覆盖了整个跨度——从电池供电仪表上的 2.4 寸 SPI 屏，到长期连续运行设备上的 32 寸 LVDS 屏——规律很一致：**顺利的项目，都是把面板、接口与软件栈放在一起、尽早、按产品真实需求一次定下来的**。这篇文章讲我们怎么做这个决定。
SPI 屏占用引脚少，能容忍更长更便宜的软排线，几乎任何单片机都能驱动。3.5 寸以下基本是它的天下，界面不追求大面积动画的话，到 4.3 寸依然可用。
约束在带宽，而且这笔账算得很死。一次全屏刷新要把 宽 × 高 × 每像素字节数 的数据推过总线；在常见的 SPI 时钟下，320×240 的 16 位屏刷一帧是几十毫秒量级，而同样时钟下 480×800 的屏根本撑不住流畅的全屏动画。务实的答案是**别做全屏刷新**：局部渲染、脏矩形刷新、小块动效，才是让 SPI 屏跟手的办法。这是一种设计纪律，不只是软件开关。
我们在界面偏信息展示而非视觉表演的产品上用 SPI 屏——仪表前面板、手持检测仪、电池类产品的状态显示。我们做过的 OLED 手持检测仪器，以及助眠声音盒上的显示，都属于这一类。
并口 RGB（也叫 DPI）用 16、18 或 24 根数据线加时钟与同步信号传像素数据。带宽远高于 SPI，4.3 到 10.1 寸区间的面板便宜且货源充足，多数应用级 SoC 都带 RGB 控制器。
代价是引脚和布线。二十多根随像素时钟一起翻转的信号，需要等长、规整的回流路径和对 EMI 的关照，而且占掉的 GPIO 可能是产品别处想用的。软排线必须短。如果外壳里板子和屏离得远，RGB 很快就会变得难搞。
这是我们在白色家电、工业面板和设备前端上最常见的接口，集中在 5 到 10 寸，面板就压在板子正上方、机械距离很短的场合。
LVDS 把像素数据串行化到几对差分线上，换来 RGB 给不了的两样东西：更长的线缆距离，以及更大、更高分辨率的面板。大约 10 寸往上，以及任何屏与主板在机械上分离的产品——翻盖结构、独立面板组件——通常都是 LVDS 的场子。
设计重点转移到差分走线：阻抗控制、对内等长、连接器选型与屏蔽。单通道还是双通道 LVDS 由分辨率和刷新率决定，选错了会在点亮阶段才发现——屏不亮，或者画面顶部出现异常。
我们交付过的 LVDS 工作包括基于全志平台、支持多屏的显示板，以及在同一块 Linux 板上同时点亮 LVDS 与 MIPI 的 RK3128 平台。
MIPI DSI 是现代移动衍生面板使用的接口。它用少数几对差分通道传输高分辨率画面，功耗效率出色，因此在手机、平板，以及任何借用这条供应链的产品上占主导。
它也是四种接口里最不宽容的。通道要等长，软排连接器的选型有讲究，面板的上电时序与初始化命令集必须完全正确，屏幕上才会出现第一帧；而且很多面板不是直驱，要经桥接芯片转换，桥接芯片又带来自己的配置与时序。
这条路我们走过多次。树莓派 DSI 显示项目在 Raspberry Pi 5 上点亮了 4.3、5、7、10 寸面板，用 ICN6211 桥接完成 MIPI DSI 转换，显示配置通过 DTS 与 DTBO 设备树覆盖实现，触摸通路靠 I2C 调试日志诊断。我们也做过基于全志 T113 的 MIPI 定制主板。可迁移的经验是：**同样的电气接口换一块屏，时序参数、上电顺序和触摸配置全都要跟着变**。把这些配置放进设备树覆盖、而不是硬编码进驱动，才是一条有多种屏幕选项的产品线能长期维护的前提。
面板和接口一旦定下来，现实可选的软件方案就迅速收窄。下面四种我们都在交付，按产品选。
裸机加 LVGL。适合成本驱动产品上的小尺寸 SPI 屏，界面就那么几屏，固件其余部分也简单。体积最小，没有调度开销，时序完全可控。
FreeRTOS 加 LVGL。单片机产品的默认选择，屏幕要和通信协议栈、传感采样或控制环共存时尤其如此。GUI 拿到自己的任务和一份有上限的刷新预算，时间关键的活不会被重绘饿死。在433MHz 安防联动系统里，STC32G128K 跑 FreeRTOS，同时驱动 sub-GHz 终端、摄像头 SDK 与 LCD/OLED 状态显示——那里的纪律是：显示永远不能阻塞射频。
嵌入式 Linux。一旦产品需要文件系统、网络服务、视频，或者面板已经超出单片机能驱动的范围，Linux 就是务实的下限。显示变成设备树与帧缓冲的问题，UI 层可以是 LVGL、Qt 或基于浏览器的前端。这类方案我们在全志 T113 与 V3S、瑞芯微 RK3128 以及树莓派硬件上都做过。
Android。当产品想要 Android 应用生态、App 式的交互预期，或者面向客户的界面将由 App 开发者而非固件工程师来写时，选它。我们交付的超声触控系统就用 Android 做医疗设备上的触控界面，通过专用协议与设备通信——界面层需要 App 级的交互品质，而设备侧保持确定性，正是这种场合。
此外还有 STM32 上的 TouchGFX，我们在电动车仪表盘上用过，配深色主题、序列帧动画与成体系的图标资源。当芯片锁定 STM32、且设计师主导的工作流很重要时，它是对的选择；我们在那篇 LVGL 开发文章里详细比较过两者。
还有一种组合值得单独点名：ESP32-S3 配 PSRAM 跑 LVGL，已经成为"要彩色触摸屏但撑不起应用处理器"这类产品的常见答案。它的内存预算与带宽计算，我们在 ESP32-S3 开发指南里讲过。
团队常常为显示留足预算，却忘了触摸是另一轮点亮。电容触摸控制器有自己的 I2C 或 SPI 接线、中断处理、固件配置与校准。控制器的配置往往要针对具体的盖板玻璃厚度和面板叠层去调，而在裸屏上调好的配置，贴合玻璃之后可能表现很差。
工业和白电环境还要加上噪声。挨着电机、加热管或开关电源的触摸屏，会遇到台面环境里根本看不到的干扰。屏蔽、地线策略和控制器阈值调整，是设计的一部分，不是事后补救。
在树莓派 DSI 项目里，四种尺寸面板的触摸校准占掉了点亮阶段相当一部分时间，而让这条通路可诊断的正是 I2C 调试日志。这部分工时要明确预留。
医疗。界面稳定性与响应确定性比视觉花哨更重要，文档要求更重，界面与仪器之间的设备协议本身就是一项交付物。我们的超声触控系统属于这一类，基于 RK3128 的超声平台，以及核酸检测仪的控制系统——后者的主板硬件与 LCD 驱动也是我们做的——同样如此。
白色家电。单台成本压倒一切，界面的使用者从不看说明书，而环境又热、又潮、电气噪声又大。我们做过的烤箱控制板是个好例子：触摸要隔着面板工作、在高温下工作、紧挨着开关负载工作，而价格还得扛得住一轮严苛的 BOM 评审。
工业。宽温、长生命周期、面板要能供货多年、抗振动与 EMI，有时还要支持戴手套或湿手操作。这里的面板选型，供应链属性和技术属性一样重——一块两年后停产的面板，今天再完美也是问题。
这方面的底子有个来处：团队早期做过电视整机研发。电视整机逼着人熟悉面板接口、时序、图像处理与整条显示信号链，深度是多数嵌入式项目触不到的。正因为有这段背景，接口选型、时序调试与面板点亮对我们是常规动作，而不是摸索。
此后我们在各个区间都交付过显示工作——低功耗智能手表上的 240×240 彩色触摸屏、杰里平台上掌上游戏机与智能秤主板的 LVGL 界面、Apollo2 低功耗显示终端、安防与检测产品上的 LCD 与 OLED 状态显示、树莓派硬件上 4.3 到 10 寸的 DSI 面板、支持多屏的 LVDS 显示板、基于全志 T113 的 MIPI 定制主板、医疗设备上的 Android 界面，以及广告机形态的 Android 与 Linux 系统。接口、尺寸与软件栈各不相同，方法是同一套。
如果你正在为产品选显示方案，希望面板选型、板子、点亮与界面软件由同一支团队承接，我们的嵌入式软件服务与硬件设计服务覆盖这条完整路径。
联系我们获取定制化解决方案和报价