Qt for MCUs 2.11 LTS与Qt 5.15.19：嵌入式GUI选型与实战

1. 从一次选型争论说起：MCU 上跑 Qt 到底是不是伪命题

去年底跟几个做工业 HMI 的朋友吃饭，席间吵起来一个话题：一块十几块钱的 MCU，到底该不该上图形框架。一派认为老老实实裸机刷屏、状态机切页面就够了，上框架纯属给自己找麻烦；另一派则被产品经理反复改 UI 的需求折磨得够呛，恨不得把 Qt 搬上去。当时谁也没说服谁，但今年 Qt for MCUs 2.11 LTS 和 Qt 5.15.19 这两个版本一前一后落地，我觉得这场争论可以有个阶段性的答案了。

先把结论摆前面：Qt for MCUs 2.11 LTS 是给"资源受限但 UI 需求不简单"的设备准备的，典型代表就是 ESP32-S3 和瑞萨 RA8D1 这类带显示能力、内存又卡得死死的芯片。而Qt 5.15.19 作为 Qt 5 系列的最终版本，意义完全不同——它是给那些还压在 Qt 5 上、短期不打算迁 Qt 6 的老项目一个"封版安心丸"。这两件事放在一起看，其实勾勒出了嵌入式 GUI 领域两条并行的路线：一条往极轻量走，一条往存量维护走。

这篇东西我打算按实际做项目的思路来写：先讲清楚 Qt for MCUs 这套东西在 MCU 上到底怎么跑起来的，再拆 ESP32-S3 和 RA8D1 这两个平台各自的坑，然后聊地图渲染这种"看起来不该出现在 MCU 上"的功能是怎么实现的，最后说说 Qt 5.15.19 这个最终版对存量项目意味着什么。如果你正在纠结 HMI 方案选型，或者手上有个 Qt 5 老项目不知道该不该动，应该能捞到点有用的东西。

2. Qt for MCUs 的运行模型：它和桌面 Qt 根本不是一回事

很多人第一次接触 Qt for MCUs，会下意识拿它跟桌面 Qt 对比，然后得出"阉割版"的结论。这个理解方向就偏了。Qt for MCUs 不是把桌面 Qt 裁剪一下塞进 MCU，而是一套重新设计的、面向无操作系统或 RTOS 环境的渲染与声明式 UI 运行时。搞不清这一点，后面所有的性能预期和调试思路都会跑偏。

2.1 QML 在 MCU 上是怎么被"编译掉"的

桌面 Qt 跑 QML 靠的是 QML 引擎在运行时解析、绑定、求值，这套机制灵活但吃内存吃 CPU。Qt for MCUs 走的是另一条路：QML 在构建阶段就被 QUL 工具链（Qt Quick Ultralite）转译成 C++ 代码，运行时几乎没有解释器开销。

具体流程大致是这样：你写的.qml文件先经过qmltocpp之类的工具，生成对应的 C++ 类和属性绑定代码，然后跟 QUL 运行时库一起编译进固件。属性绑定不再是运行时反射，而是编译期生成的直接函数调用。这意味着什么？意味着绑定表达式的复杂度在编译期就基本定型了，运行时改不了结构，只能改值。

这个设计带来的直接后果是：你不能像桌面那样动态Qt.createComponent()或者运行时加载 QML 字符串。所有界面结构在编译时就固定了。对做惯了桌面 Qt 的人来说这是束缚，但对 MCU 来说这是必须的——没有 MMU、没有虚拟内存、堆只有几十 KB，任何运行时动态分配都是风险。

提示：QUL 工具链对 QML 语法的支持是子集，不是全集。动画、状态机、部分 JavaScript 表达式支持，但像eval、动态属性、复杂的 JS 闭包基本别想。写之前先翻一遍官方支持的 QML 子集列表，能省掉大量"编译过了但跑不起来"的时间。

2.2 渲染管线：为什么 MCU 也能跑出 60fps

MCU 没有 GPU，这是常识。但 Qt for MCUs 依然能在 ESP32-S3 这种芯片上跑出流畅动画，靠的是分层渲染 + 脏矩形更新 + 硬件加速的 2D 位块搬运。

它的渲染模型大致分三层：背景层、内容层、覆盖层。每层独立维护自己的缓冲区，只有发生变化的区域才重新绘制并合成。ESP32-S3 带 LCD_CAM 外设和 PSRAM，可以把帧缓冲放在外部 PSRAM 里，CPU 只负责往脏区域写像素，剩下的搬运交给 DMA。RA8D1 那边更舒服，它自带 2D 图形加速引擎（DRW），画线、填充、alpha 混合都能硬件做，CPU 占用能压得很低。

这里有个关键参数要算清楚：帧缓冲大小 = 宽 × 高 × 每像素字节数。以 480×272 的 RGB565 屏为例，单缓冲就是 480×272×2 ≈ 255KB。ESP32-S3 内部 SRAM 只有 512KB，还要留给程序和数据，所以帧缓冲基本必须放 PSRAM。而 PSRAM 的带宽是有限的，如果每帧都全屏重绘，带宽直接吃满，帧率就崩了。这就是为什么脏矩形更新不是"优化选项"而是"生存必需"。

2.3 内存账本：先算清楚再动手

我见过太多项目死在内存上，所以这里把账算细一点。一个典型的 Qt for MCUs 应用，内存开销主要来自四块：

Flash 那边 ESP32-S3 一般有 8MB 外部 Flash，问题不大。真正的瓶颈是 RAM。内部 SRAM 要留给中断栈、DMA 描述符、WiFi 协议栈（如果用的话），能分给 GUI 的往往只有一两百 KB。所以帧缓冲放 PSRAM、堆尽量放内部 SRAM是常见做法——堆访问频繁，放内部快；帧缓冲访问模式是顺序大块，PSRAM 带宽够用。

3. ESP32-S3 平台实操：从点亮屏幕到跑通第一个 QUL 界面

ESP32-S3 是这两年被问得最多的 MCU 之一，带 WiFi/BLE、带 LCD 接口、带 PSRAM 支持，价格还便宜，做带屏 IoT 设备几乎是默认选项。但它的坑也不少，尤其是显示这块，官方例程和实际项目之间隔着一条河。

3.1 硬件连接：RGB 接口和 SPI 接口的选择

ESP32-S3 支持两种主流屏幕接口：RGB 并口（LCD_CAM 外设）和 SPI。选哪个直接决定了你能跑多高的刷新率。

RGB 并口走的是 16 位或 18 位并行数据线，配合 PCLK、HSYNC、VSYNC、DE 几个同步信号，可以直接对接 RGB 屏。优点是带宽高，480×272 甚至 800×480 都能跑；缺点是吃引脚，16 位数据线加控制线，二十多个 GPIO 就没了。ESP32-S3 的 GPIO 数量本来就紧张，如果还要接 WiFi 天线、按键、传感器，很容易不够用。

SPI 屏省引脚，四线 SPI 加几个控制脚就够，但带宽是硬伤。以 40MHz SPI 算，理论峰值 5MB/s，刷 480×272 RGB565 全屏要 255KB，也就是 20 帧/秒封顶，实际还要打折。所以 SPI 屏适合小尺寸、低刷新率的场景，比如 240×240 的状态显示。

我的建议是：如果 UI 有动画、有滑动列表，咬牙上 RGB 并口；如果只是静态参数显示、偶尔刷新，SPI 够用还省事。选型阶段就把引脚规划做出来，别等 PCB 画完了才发现 GPIO 不够。

3.2 PSRAM 配置：最容易翻车的一步

ESP32-S3 的 PSRAM 配置有几个关键点，配错了要么跑不起来，要么性能惨不忍睹。

第一，PSRAM 的时钟频率和模式。ESP32-S3 支持 Quad SPI PSRAM 和 Octal SPI PSRAM，Octal 带宽翻倍但引脚占用多。在 menuconfig 里要选对模式，选错了轻则不识别，重则启动就崩。

第二，PSRAM 的访问方式。默认情况下 PSRAM 是映射到地址空间的，可以直接指针访问，但通过 cache 访问和绕过 cache 访问性能差很多。帧缓冲这种顺序访问的场景，走 cache 效率高；但如果 DMA 要直接读 PSRAM，就得考虑 cache 一致性问题，可能需要手动 flush。

第三，堆的分配策略。ESP-IDF 里可以用heap_caps_malloc指定从哪块内存分配。QUL 的帧缓冲建议用MALLOC_CAP_SPIRAM，运行时对象用MALLOC_CAP_INTERNAL。这个在 QUL 的移植层里要改对，默认配置不一定合适。

注意：PSRAM 不是万能的。它的随机访问延迟比内部 SRAM 高一个数量级，如果 QUL 的某些操作频繁随机访问帧缓冲（比如 alpha 混合读改写），性能会明显下降。实测下来，把覆盖层放内部 SRAM、背景层放 PSRAM 是个折中方案。

3.3 跑通第一个界面：从官方 example 到自己的工程

官方给的 ESP32-S3 例程一般是个简单的仪表盘或者按钮界面，跑通它不难，难的是把它改成自己的工程结构。我一般这么做：

1. 先用官方例程确认硬件没问题，屏幕能亮、能显示、触摸能响应。
2. 然后把 QUL 的运行时库和生成的 UI 代码抽出来，做成独立的 component。
3. 最后把应用逻辑（业务代码）和 UI 代码分离，UI 只负责显示和发信号，业务逻辑在单独的 task 里跑。

这里有个经验：QUL 的 UI 更新最好放在单独的 task 里，给它固定的栈和优先级。因为渲染是周期性的，如果跟业务逻辑混在一个 task，业务一忙 UI 就卡。ESP32-S3 是双核的，可以把 UI task 绑到 core 1，业务绑到 core 0，互不干扰。

另外，QUL 的Qul::Application主循环需要定期调用，一般是app.update()或者类似的接口。这个调用频率决定了 UI 的响应速度，但也不能太频繁，否则 CPU 全耗在渲染上。实测 30~60Hz 的更新频率比较合理，具体看屏幕刷新率。

4. RA8D1 平台：当 MCU 自带 2D 加速引擎时该怎么用

瑞萨 RA8D1 是另一条路线。它基于 Cortex-M85，主频高，还带了 DRW（2D Drawing Engine）和 GLCDC（Graphics LCD Controller），硬件底子比 ESP32-S3 厚实不少。但硬件强不代表就能随便造，用不好照样卡。

4.1 DRW 加速引擎的能力边界

RA8D1 的 DRW 能做什么？简单说：画线、画矩形、填充、alpha 混合、图像旋转缩放、颜色格式转换。这些操作如果让 CPU 做，480×272 全屏填充一次就是十几万次写操作，DRW 几个周期就搞定。

但 DRW 不是万能的。它不支持任意路径绘制、不支持复杂的混合模式、不支持着色器。QUL 的渲染器在 RA8D1 上会尽量把能交给 DRW 的操作交出去，但像圆角矩形、渐变、阴影这些，可能还是 CPU 软渲染。所以实际性能取决于你的 UI 用了多少"DRW 友好"的元素。

我的经验是：多用纯色块、直线、矩形、位图，少用渐变和复杂圆角。如果设计稿里全是毛玻璃和阴影，那 RA8D1 也救不了你，得回去跟设计师聊聊。

4.2 GLCDC 双缓冲与撕裂问题

GLCDC 是 RA8D1 的 LCD 控制器，支持双缓冲和图层混合。双缓冲的意义在于：CPU/DRW 在后台缓冲绘制，GLCDC 在前台缓冲扫描输出，绘制完成后交换。这样就不会出现"画到一半屏幕显示出来"的撕裂现象。

但双缓冲的代价是帧缓冲内存翻倍。480×272 RGB565 双缓冲就是 510KB，RA8D1 的 SRAM 够不够要看具体型号。如果不够，就得考虑单缓冲 + 垂直同步等待，或者降低分辨率。

撕裂问题在静态界面看不出来，一旦有滑动、动画就非常明显。我建议只要做动画，就上双缓冲，这是体验的底线。内存实在紧张，宁可降分辨率也别省这个。

4.3 中断优先级与渲染任务的配合

RA8D1 的 GLCDC 和 DRW 都会产生中断，这些中断的优先级要设对。GLCDC 的垂直同步中断优先级要高，因为它决定了帧的节奏；DRW 的完成中断可以稍低，但也不能太低，否则绘制任务排队。

QUL 在 RA8D1 上的移植层一般会封装这些中断处理。你要做的是确认：渲染任务的优先级低于显示中断，但高于普通业务任务。这样显示不卡，业务也不至于饿死。

5. MCU 上的地图渲染：一个"反常识"功能的实现思路

地图渲染出现在 MCU 上，第一反应是"疯了吧"。桌面地图动辄几百 MB 瓦片数据，MCU 那点 Flash 和 RAM 怎么扛？但仔细想想，很多场景其实不需要完整地图——工业设备的厂区平面图、车载的简易导航、手持设备的轨迹显示，这些"地图"数据量小、交互简单，完全可以在 MCU 上做。

5.1 瓦片数据的裁剪与存储

核心思路是只存需要的瓦片，而且只存低精度的。比如一个厂区平面图，切成 256×256 的瓦片，总共可能就几十张，每张用 RGB565 存，压缩后也就几百 KB。放外部 Flash 完全没问题。

存储格式上，我倾向于预先把瓦片转成 QUL 能直接用的位图格式，避免运行时解码。QUL 支持从 Flash 直接读位图资源，配合Qul::Image使用。如果瓦片是 PNG/JPG，构建阶段就转掉，别留到运行时。

5.2 视口计算与瓦片调度

地图渲染的核心是根据当前视口位置，决定加载哪些瓦片、画在什么位置。这个计算不复杂：视口中心点坐标除以瓦片尺寸，得到中心瓦片索引，然后按视口大小向外扩展一圈，就是需要渲染的瓦片集合。

关键是调度策略。MCU 的 Flash 读取速度有限，如果每帧都重新读瓦片，带宽吃不消。所以要做缓存：把最近用到的瓦片缓存在 PSRAM 里，用 LRU 淘汰。缓存大小看 PSRAM 余量，一般能放十几到几十张瓦片就够流畅了。

5.3 缩放与平移的性能取舍

地图交互无非缩放和平移。平移相对简单，改视口偏移，重新计算瓦片位置即可。缩放麻烦一些，因为瓦片需要缩放绘制。

QUL 在 RA8D1 上可以借助 DRW 做位图缩放，性能还行；ESP32-S3 上就得 CPU 软缩放，480×272 全屏缩放一次可能就要十几毫秒，帧率直接掉到 30 以下。所以ESP32-S3 上的地图缩放建议做限制：要么只支持整数倍缩放（2x、4x），要么缩放时降低刷新率，松手后再恢复。

提示：地图渲染最怕的是"每帧全量重绘"。一定要用脏矩形，只重绘视口变化的区域。平移时其实只有边缘新进入的区域需要绘制，中间大部分可以复用上一帧。

6. Qt 5.15.19：Qt 5 的最终版本对存量项目意味着什么

聊完 MCU 那边，再说说 Qt 5.15.19。这个版本号本身没什么惊喜，但"Qt 5 最终版本"这个定位很关键。它意味着Qt 5 系列到此为止，后续只有安全补丁，不会再有新功能。

6.1 为什么还有大量项目压在 Qt 5 上

原因很现实：迁移成本。Qt 5 到 Qt 6 不是小版本升级，是架构级变动。QML 引擎换了、图形栈换了、构建系统从 qmake 转向 CMake、很多模块被拆分或废弃。一个中型项目迁移，几个月起步，还得重新做兼容性测试。

对于工业设备、医疗仪器这类产品生命周期长、认证成本高的领域，迁移意味着重新认证，代价太大。所以很多团队的选择是：留在 Qt 5，锁死版本，只打安全补丁。Qt 5.15.19 就是给这些团队准备的。

6.2 锁版本的正确姿势

锁版本不是简单地把版本号写死就完事。我建议做这几件事：

1. 把 Qt 安装包归档。官方下载链接以后可能失效，自己存一份离线安装包。
2. 依赖库也锁死。Qt 5.15.19 依赖的 OpenSSL、字体库、图形驱动版本都要记录清楚。
3. 构建环境容器化。用 Docker 把编译环境固化，避免"换台机器就编不过"。
4. 补丁管理流程。后续如果有安全补丁，要有渠道获取并验证。

这些事听起来琐碎，但真到了需要重新构建的时候，能救命。

6.3 什么时候该考虑迁移

我的判断标准是：如果项目还在活跃开发、还要加新功能、还要支持新硬件，那就该规划迁移。Qt 5 封版意味着新硬件适配、新系统支持都会越来越难。反之，如果项目已经进入维护期，只修 bug 不加功能，那锁在 Qt 5.15.19 上完全合理。

迁移也不是一步到位，可以先迁构建系统（qmake 转 CMake），再迁 QML 代码，最后迁图形栈，分阶段降低风险。

7. 两个版本放在一起看：嵌入式 GUI 的路线选择

把 Qt for MCUs 2.11 LTS 和 Qt 5.15.19 放一起，其实能看到嵌入式 GUI 的两条清晰路线。

路线一：极致轻量。用 Qt for MCUs，跑在 ESP32-S3、RA8D1 这类 MCU 上，无 OS 或 RTOS，内存以 KB 计，UI 用 QML 子集描述，编译期定型。适合成本敏感、量大、UI 相对固定的产品。

路线二：存量维护。用 Qt 5.15.19，跑在带 Linux 的应用处理器上，内存以百 MB 计，UI 功能完整。适合已经量产、进入维护期的产品。

这两条路线不是对立的，很多公司同时有这两类产品。关键是别用错工具：拿 Qt 5 去跑 MCU 是自找苦吃，拿 Qt for MCUs 去做复杂桌面级 UI 也是缘木求鱼。

选型的时候，我一般会问三个问题：屏幕多大、刷新率要求多少、UI 会不会频繁改。屏幕小、刷新率低、UI 固定，MCU 方案；屏幕大、要动画、UI 常改，上应用处理器。中间地带就看成本能不能接受，没有标准答案。

8. 实操中踩过的几个坑和对应的解法

最后分享几个实际项目里踩过的坑，都是文档里不太会写、但真能卡住人的。

坑一：QUL 的字体渲染吃 RAM。中文字体动辄几 MB，QUL 支持字体子集化，但子集化工具用不对，要么缺字要么体积没降下来。我的做法是先用工具统计界面实际用到的字符，生成精确子集，别偷懒用常用字表。

坑二：ESP32-S3 的 PSRAM 和 WiFi 抢带宽。WiFi 工作时会占用 PSRAM 带宽，如果帧缓冲也在 PSRAM，UI 会明显卡顿。解法是UI 刷新和 WiFi 传输错峰，或者把关键帧缓冲放内部 SRAM。

坑三：RA8D1 的 DRW 中断和 QUL 渲染任务死锁。DRW 完成中断里如果直接触发下一次绘制，可能和渲染任务抢资源。正确做法是中断里只置标志，实际绘制在任务里做。

坑四：Qt 5.15.19 的 OpenSSL 版本兼容。Qt 5.15 对 OpenSSL 1.1 和 3.0 的支持不一样，锁版本时要把 OpenSSL 一起锁，否则换个环境就握手失败。

坑五：地图瓦片的坐标精度。MCU 上浮点运算慢，地图坐标尽量用整数，缩放用定点数。我见过用 float 算瓦片位置的，帧率直接腰斩。

这些坑的共同点是：都不是框架本身的 bug，而是资源约束下的工程取舍。MCU 开发就是这样，硬件资源摆在那，你得在有限空间里做平衡。想清楚每一 KB 内存、每一个 CPU 周期花在哪，比背 API 重要得多。