TouchGFX升级至4.26版本：持续进化，为STM32嵌入式GUI开发降本提效

发表于 2025-10-10 23:20

本帖最后由 STM新闻官于 2025-10-10 23:25 编辑

2025年9月16日，意法半导体正式发布TouchGFX 4.26版本。该版本搭载了一系列UI优化功能，能有效帮助开发人员简化重复性或习惯性操作，例如快速复制字体设置、调整字体排序，以及克隆交互操作等，进一步提升开发效率。

4.26版本核心优化：提升开发体验，降低集成门槛

此前，TouchGFX 4.25版本已推出模拟帧缓冲区功能，但我们留意到，开发人员在将这一功能集成至现有应用时仍存在操作难点。为此，本次4.26版本更新重点围绕体验优化展开：

一是新增对Clang C++编译器的支持，目前该编译器已可直接在STM32CubeIDE的TouchGFX项目中使用；
二是优化可缩放图像控件，无论采用软件渲染还是NeoChrom GPU加速方式，图像渲染时间均能减少30%，大幅提升界面运行流畅度。

下载TouchGFX

回顾4.25版本：模拟帧缓冲区技术，开启单芯片GUI新可能
今年早些时候，意法半导体发布了TouchGFX 4.25版本。该版本重磅推出模拟帧缓冲区（专利申请中）功能，其核心优势在于：通过将显示图像切分为数据块，并采用无需依赖显示屏自身图形RAM的内存映射技术，显著降低了内存占用空间。这一技术突破带来了关键价值——此前必须依赖外部RAM才能运行的系统，如今可直接在单芯片板上稳定运行，大幅削减了硬件材料成本。更值得关注的是，意法半导体已在中间件层级完成该技术的集成，开发人员无需复杂调试，仅需在TouchGFX Generator中选择对应选项，即可快速评估该功能的适用性并直接应用。同时，这一功能也推动工程师更严谨地评估“帧缓冲区策略与应用场景的匹配度”——而这一关键环节，在此前的开发流程中往往容易被忽视。

常见帧缓冲区策略及其适用场景

双帧缓冲区
开发人员在开发过程中，往往容易忽视图像在显示屏上的渲染机制。但这种疏忽可能带来高昂代价——因为帧缓冲区的类型，会对系统的内存配置产生至关重要的影响。以双帧缓冲区为例，它需要在内存中同时存储两个完整的帧缓冲区，通过这种设计确保画面渲染流畅、避免出现画面撕裂问题。但从实际内存占用来看，一幅标准24位色深、1024×600分辨率的10英寸显示图像，单帧就需占用近4MB内存，双帧缓冲区则需翻倍占用，这在内存资源本就紧张的系统中，通常难以实现。因此，双帧缓冲区方案并非普适选择，其更适合应用于特定场景：即配备大尺寸显示屏、需运行高级图形界面，且系统本身就已配置大容量外部RAM的设备。

单帧缓冲区
一种折衷方案是仅采用单个完整的帧缓冲区。该方案的显著优势在于，能直接将内存占用量降低50%，大幅减轻系统内存压力。不过，单帧缓冲区也存在明显局限——屏幕在刷新过程中出现画面撕裂的风险会相应升高，但这个问题可通过技术手段有效缓解。例如，开发人员可通过限制动画复杂度、适当降低屏幕刷新频率，同时借助DMA2D加速（即STM32芯片上的Chrom-ART技术）优化数据处理效率，以此平衡性能与画面稳定性。这类方案在嵌入式系统的中级图形应用中比较常见；对于屏幕尺寸较小、且对UI流畅度要求不高的场景，单帧缓冲区更适用，甚至基本不会出现画面撕裂的风险。

部分帧缓冲区
与之类似，另一种可行方案是采用部分帧缓冲区——该功能早在TouchGFX 4.12版本中便已引入。顾名思义，其原理是系统内存中仅存储画面需要更新的那部分帧缓冲区数据，而非完整帧，这一设计可进一步降低内存占用量。不过，该技术存在一个关键前提：显示屏必须配备图形RAM（简称GRAM），且这块GRAM需具备存储整个帧缓冲区数据的能力。原因在于：显示屏在渲染图像时，必须调用完整的帧缓冲区数据才能完成显示。因此，即便使用部分帧缓冲区能减少嵌入式系统自身的RAM需求，但“显示屏GRAM需存储完整帧缓冲区”这一硬性限制，始终无法规避。

TouchGFX 4.25模拟帧缓冲区策略详解
TouchGFX 4.25版本推出的模拟帧缓冲区，工作原理与部分帧缓冲区相近，但核心优势在于无需依赖显示屏的GRAM。这一功能的实现，依托于意法半导体图形框架对特定硬件资源的整合——具体而言，是通过调用LTDC（LCD-TFT显示控制器），以及集成在STM32H7R/S、STM32H7A/B、STM32U5系列，还有新发布的STM32N6系列MCU中的Chrom-GRC IP图形内存管理单元来达成。由此可见，模拟帧缓冲区的落地，关键在于借助了STM32器件中的最新IP技术；而从开发体验来看，意法半导体已在中间件层级完成该功能的集成，用户无需进行复杂的底层调试，只需在TouchGFX Generator中选择“启用模拟帧缓冲区”选项，即可直接应用该功能，操作门槛大幅降低。

新的内存管理系统
简而言之，TouchGFX通过内存管理单元（MMU）对地址空间进行映射，实现了整个帧缓冲区的“虚拟化”——无需实际存储完整帧缓冲区数据。当系统需要访问帧缓冲区时，内存管理单元能精准识别需求并提供对应数据。

TouchGFX 4.25模拟帧缓冲区的新虚拟内存管理机制与部分帧缓冲区的原理相似，使用这一虚拟内存管理机制时，开发人员需将显示区域划分成若干等份（例如四等分或八等分），以此优化UI更新。分块越小，开发团队对显示区域的控制粒度越精细，但相应的操作计算强度也会随之增加。因此，程序员需结合实际屏幕更新范围，在系统性能与显示效果之间找到最佳平衡。

显示交互与反馈
另一方面，意法半导体的LTDC（LCD-TFT显示控制器）会持续读取内存管理单元（MMU）写入的像素数据，并通过并行RGB或MIPI DSI等接口，将模拟帧缓冲区的内容传输至显示屏。若系统无法在16毫秒内完成全屏刷新，图像便会出现明显的画面撕裂问题。不过，这一特性若运用得当，也能转化为技术优势。从适用场景来看，模拟帧缓冲区更适合UI元素相对静态的场景。当使用条件匹配时，该技术节省的内存空间效果显著——足以省去外部RAM，仅依靠MCU自身内存即可支撑系统运行。例如，以往驱动720p或1080p分辨率的高画质UI显示屏，通常需要依赖微处理器；如今借助意法半导体的模拟帧缓冲区技术，仅用MCU就能轻松实现。进一步来说，若应用场景以快速信息更新（如状态实时刷新）为主，且对动画效果需求极少，那么在内存中始终保存完整帧缓冲区就完全没有必要。这种情况下，模拟帧缓冲区能提供更高效的内存利用方案，让系统仅通过MCU加更少RAM的配置即可稳定运行。因此，开发过程中若遇到画面撕裂问题，可将其看作框架发出的“优化提示”——这意味着需要移除部分非必要动画，或切换至其他更适配的帧缓冲区策略（具体可参考我们关于帧缓冲区策略的专项文档）。所有帧缓冲区策略均可在TouchGFX Generator中直接选择，策略间的切换操作十分轻松，无需复杂的底层调整。

实际应用
自TouchGFX 4.12版本推出部分帧缓冲区技术五年后，我们的团队再次推出优化升级的模拟帧缓冲区方案，为单芯片设计拓展了全新可能性。这一解决方案，充分体现了TouchGFX对STM32器件内置IP的深度运用：通过优化内存使用效率，直接帮助降低硬件材料成本；同时也显著降低了GUI开发门槛——以往因外部RAM模块成本过高，而不得不放弃采用图形界面的项目，如今借助该方案可轻松实现图形化设计。验证帧缓冲区策略实际效果的最佳方式是在兼容的开发平台（如STM32H7S78-DK开发板）上，对模拟帧缓冲区策略进行实测，直观观察应用运行是否流畅稳定。在内部测试阶段，我们在上述开发板上仅依靠内部RAM完成了概念验证，结果显示：在800×400分辨率下，系统整体表现十分优异。测试中唯一出现屏幕撕裂的场景，仅发生在运行实时统计数据展示功能时。我们分享这一实测案例，核心目的是帮助开发者社区更清晰地理解：并非所有应用场景都适配模拟帧缓冲区策略。但对于适配该策略的应用而言，它能为嵌入式系统带来显著价值——运行效率更高，成本性价比更突出。例如，下面图片呈现的电梯UI界面基于720p显示屏与STM32H7芯片搭建，全程仅使用嵌入式RAM运行；这样的方案在模拟帧缓冲区技术出现之前，是完全无法实现的。

基于TouchGFX 4.25模拟帧缓冲区实现的UI界面

TouchGFX 4.25版本的其他重磅升级
TouchGFX 4.25同时还引入了位图字体压缩，进一步减少UI内存占用。当系统出于性能考量必须使用位图字体时，该功能可作为矢量字体的理想替代方案。在实际应用中，新的压缩技术可将位图字体的内存占用减少20%到80%。例如，一个包含大量汉字的字体文件可实现40%的体积缩减；而对于字符集较小但尺寸较大的字体（如110磅Verdana），其内存占用可从约40KB降至仅8KB。

TouchGFX Designer新增位图字体压缩系统选项此外，新版TouchGFX还增加了对CMake与IAR 9的支持，进一步优化开发流程。CMake作为一套开源工具集，能够协助开发人员完成软件编译、测试与打包等工作。因此，该集成将有助于工程师轻松实现项目跨平台移植，更方便与团队成员共享开发成果，从而简化开发操作。

发表于 2025-10-10 23:25

阅读原文

发表于 2025-10-10 23:26

[其他ST产品] TouchGFX升级至4.26版本：持续进化，为STM32嵌入式GUI开发降本提效

相关帖子

浏览过的版块