1. 图形终端需求分析与方案选型

在启动任何 STM32 图形终端项目之前，最容易被跳过、却最影响后期返工量的环节，是需求分析与方案选型。很多工程师拿到一块带 TFT 的开发板后，第一反应是"先把屏幕点亮、把 UI 跑起来"，结果做到一半才发现：屏幕尺寸选小了、刷新率不够导致动画卡顿、图形库授权费超出预算、或者 MCU 的 RAM 根本放不下双缓冲。本章的目标，是把"要做什么样的终端"和"用什么技术路线实现"这两件事在动手写代码之前想清楚。

1.1 从终端形态反推功能指标

工业 HMI 与智能家居面板是两类最典型的 STM32 图形终端，它们的需求差异很大，不能套用同一套指标。

工业 HMI 通常安装在设备机柜或操作台上，操作者戴手套、环境有油污和电磁干扰。它的核心诉求是"可靠、可读、可维护"：屏幕多为 4.3～7 英寸、480×272 到 800×480 分辨率，亮度要求高（≥500 cd/m²），需要支持电阻或电容触摸，界面以参数显示、按钮控制、报警弹窗、趋势曲线为主，动画需求弱，但要求长时间运行不死机、断电后参数不丢失。典型 MCU 选择是 STM32F4/F7/H7 系列，主频 168～480 MHz，外扩 SDRAM 或使用带大容量 SRAM 的型号。

智能家居面板 安装在墙面，用户近距离操作，追求"好看、跟手、低功耗"。屏幕多为 3.5～5 英寸、480×480 或 720×720 分辨率，需要电容触摸、滑动切换、圆角卡片、渐变和过渡动画，帧率期望 30～60 fps。它往往还要接入 Wi-Fi/蓝牙模组、支持 OTA 升级，因此 MCU 需要留出足够的 Flash 和 RAM 给协议栈与图形缓冲。典型选择是 STM32F4/F7 或 STM32H7，配合外部 QSPI Flash 存放图片资源。

把这两类需求落到可量化的指标上，可以形成下面这张对照表，作为选型的第一手输入。

1.2 图形库对比：TouchGFX、LVGL、emWin

确定指标后，下一步是选择图形库。三者在 STM32 生态中都有实际项目在使用，但定位不同。

TouchGFX 是 ST 官方收购并深度集成的图形框架，最大特点是"设计驱动开发"：UI 在 TouchGFX Designer 中以可视化方式搭建，控件、动画、交互通过拖拽和属性配置完成，生成的 C++ 代码与 STM32 的 LTDC、DMA2D、Chrom-ART 硬件加速紧密结合。它天然适合"界面复杂、动画多、需要快速迭代外观"的场景，例如智能家居面板。代价是它主要面向 STM32，且对 MCU 资源要求较高，通常需要 F4 以上并配备外部 RAM。

LVGL 是开源轻量级图形库，MIT 许可，跨平台，资源占用可裁剪。它用纯 C 编写，控件丰富，社区活跃，适合成本敏感、MCU 资源有限（如 STM32F1/F0 加小屏）或需要跨芯片平台复用的项目。缺点是缺少官方可视化设计器（虽有第三方工具），复杂动画和视觉效果需要手写较多代码，且默认不绑定 STM32 硬件加速，需要自行适配 DMA2D。

emWin 是 SEGGER 的商业图形库，成熟稳定，在工业领域应用多年，提供 AppWizard 设计工具，支持多种显示控制器。它的优势是文档完善、工业客户认可度高；劣势是商业授权费用，且对 STM32 新特性的跟进不如 TouchGFX 及时。

三者的取舍可以用一张对比图来快速判断：横轴是"资源开销/成本"，纵轴是"视觉效果与开发效率"。

1.3 确定 STM32 + TouchGFX 技术路线

综合前面的指标与对比，本课程选择 STM32 + TouchGFX 作为主线技术路线，理由有三点：其一，TouchGFX 与 STM32 的 LTDC、DMA2D、Chrom-ART 加速器深度绑定，能在有限主频下把动画帧率做上去，这是纯软件渲染的 LVGL 难以比拟的；其二，TouchGFX Designer 的可视化开发方式，让界面外观的迭代成本大幅降低，适合本课程要覆盖的智能家居面板类复杂 UI；其三，ST 官方提供完整的板级支持包和示例工程，学习路径清晰，便于复现。

但选型不是"选完就结束"，还要把路线落到具体的硬件与软件配置上。以本课程后续将使用的典型配置为例（以下参数为教学示例，实际项目需按屏幕与 MCU 数据手册核算）：

• MCU：STM32F429ZIT6，Cortex-M4 @180 MHz，片内 256 KB SRAM、2 MB Flash，带 LTDC 与 DMA2D。
• 显示：5 英寸 800×480 RGB565 屏，16 位并行 RGB 接口，像素时钟约 30 MHz。
• 显存：外扩 8 MB SDRAM，划分两块 800×480×2 B ≈ 768 KB 的帧缓冲，用于双缓冲。
• 资源存储：外扩 16 MB QSPI Flash，存放图片、字体与动画资源。
• 触摸：电容触摸控制器通过 I²C 接入，中断方式上报坐标。

这里有一个关键的计算需要提前做：单帧缓冲大小 = 宽 × 高 × 每像素字节数。800×480 的 RGB565 每像素 2 字节，即 800×480×2 = 768000 B ≈ 750 KB。双缓冲需要约 1.5 MB，片内 SRAM 显然不够，必须外扩 SDRAM。如果忽略这一步，后期会出现"UI 能显示但动画撕裂"或"内存分配失败"的问题。同理，若改用 480×272 的 RGB565 屏，单帧仅约 255 KB，双缓冲约 510 KB，部分 STM32F4 型号的片内 SRAM 加 CCM 就有机会容纳，方案成本会明显下降。

1.4 需求到方案的落地检查

在正式进入下一阶段前，可以用一份简短的检查清单确认需求与方案已经对齐：

1. 屏幕分辨率与色彩深度是否已确定，并据此算出了单帧与双帧缓冲大小？
2. 目标帧率是否明确，所选 MCU 的 LTDC 像素时钟与 SDRAM 带宽能否支撑？
3. 触摸类型（电阻/电容）与交互方式（点击/滑动/多点）是否与图形库能力匹配？
4. 图片与字体资源总量是否已估算，存储介质（片内 Flash / QSPI Flash / SD 卡）是否选定？
5. 图形库的授权模式与项目预算是否一致，是否需要商业授权？
6. 是否有 OTA、通信协议栈等额外需求，它们占用的 RAM/Flash 是否已计入预算？

这份清单不需要一次全部答"是"，但每一项都应有明确结论或待验证项。需求分析与方案选型的价值，正在于把后期可能出现的"返工点"提前暴露出来。当屏幕、MCU、图形库、存储四者形成一条自洽的技术路线后，后续的 TouchGFX 工程搭建、界面开发与性能调优才有稳定的基础。