跳转到主要内容

已知问题

本文列出了所有TouchGFX版本中已知存在的问题以及潜在的权宜措施。 此外,如果您需要执行任何特定的升级步骤才能将TouchGFX升级至特定版本,文中将会提到。 请注意,如果当前版本与最新版本之间隔了几个版本,您需要执行所有版本的升级步骤,直至升级到最新版本。

TouchGFX 4.21.0

WideTextAction

Types.hpp中枚举WideTextAction的定义已更改,因其具有误导性。 如果您在TouchGFX 4.20或更早版本中使用WIDE_TEXT_WORDWRAP,并希望看到省略号(),则必须在TouchGFX 4.21中使用WITE_TEXT_WORDWRAP_ellipsis。 另请参见文本和字体

使用IAR编译STM32U599项目

将TouchGFX项目从4.20版或更早版本升级到TouchGFX 4.21时,IAR中会显示链接错误。

Error[Li006]: duplicate definitions for "HAL_CPU2D_CommandListCpltCallback"; in "...\Obj\nema_hal.o", and "...\Obj\nema_hal_threadx.o"
Error[Li006]: duplicate definitions for "nema_buffer_create"; in "...\Obj\nema_hal.o", and "...\Obj\nema_hal_threadx.o"
...

此错误的原因是文件TouchGFX/Target/generated/nema_hal_threadx.c已重命名为TouchGFX/Target/generate/nema_har.c。 在文件名中包含操作系统是一个错误。 CubeMX使用新名称创建文件,同时保留旧文件。 这两个文件均由IAR编译。 解决方案是删除文件TouchGFX/Target/generated/nema_hal_threadx.c。

使用NeoChrom在STM32上绘制SVG

具有大坐标的SVG形状可能会在使用NeoChrom的目标上渲染错误。 这是由于NeoChrom库的限制。 该问题可能由于缩放或SVG本身中的大坐标而产生。

解决方案是插入对nema_vg_handle_large_coords()的调用。 touchgfx/target/generated/TouchGFXConfiguration.cpp中的函数touchgfx_components_init()是一个很好的位置:

void touchgfx_components_init()
{
nema_init();
nema_vg_init(480, 480);
nema_vg_handle_large_coords(1, 1);
}

注意:此解决方案的性能略有下降。

TouchGFX 4.20.0

画笔接口变更

出于性能原因,AbstractPainter::render()方法已被AbstractPainter::paint 替换。
如果您实现了自己的画笔类,则需适应此新接口。 请阅读有关Canvas Widgets的文章。

画笔实现移动至生成的文件

在TouchGFX 4.20中,绘制圆、线和其他形状的软件例程已从框架代码移到CubeMX生成的代码中。 这意味着在将项目从TouchGFX 4.19.1(或更早版本)升级到TouchGFX4.20后,必须在CubeMX中重新生成代码。 变更的原因是为了在绘制圆和线时能够使用图形加速器DMA2D。

说明

找到并打开项目根文件夹中的.ioc文件:

项目IOC文件

在软件包组件选择器(alt-O)中选择TouchGFX 4.20:

选择TouchGFX 4.20

关闭此对话框,点击右上角的“生成代码”。 现在转到TouchGFX 设计器并重新生成代码(F4)。

链接器错误

如果不重新生成代码,那么您的项目使用Circle等控件时,会出现链接器错误。 错误如下(此处为16bpp):

Linking TouchGFX/build/bin/target.elf
Middlewares/ST/touchgfx/lib/core/cortex_m7/gcc\libtouchgfx.a(PainterRGB565.o): In function `touchgfx::PainterRGB565::paint(unsigned char*, short, short, short, short, unsigned char) const':
(.text._ZNK8touchgfx13PainterRGB5655paintEPhssssh+0x1a): undefined reference to `touchgfx::paint::rgb565::lineFromColor(unsigned short*, unsigned int, unsigned long, unsigned char, unsigned long)'
Middlewares/ST/touchgfx/lib/core/cortex_m7/gcc\libtouchgfx.a(PainterRGB565.o): In function `touchgfx::PainterRGB565::tearDown() const':
(.text._ZNK8touchgfx13PainterRGB5658tearDownEv+0x0): undefined reference to `touchgfx::paint::rgb565::tearDown()'
collect2.exe: error: ld returned 1 exit status

对于24bpp:

Linking TouchGFX/build/bin/target.elf
Middlewares/ST/touchgfx/lib/core/cortex_m7/gcc\libtouchgfx.a(PainterRGB888.o): In function `touchgfx::PainterRGB888::paint(unsigned char*, short, short, short, short, unsigned char) const':
(.text._ZNK8touchgfx13PainterRGB8885paintEPhssssh+0x18): undefined reference to `touchgfx::paint::rgb888::lineFromColor(unsigned char*, unsigned int, unsigned long, unsigned char)'
Middlewares/ST/touchgfx/lib/core/cortex_m7/gcc\libtouchgfx.a(PainterRGB888.o): In function `touchgfx::PainterRGB888::tearDown() const':
(.text._ZNK8touchgfx13PainterRGB8888tearDownEv+0x0): undefined reference to `touchgfx::paint::rgb888::tearDown()'
collect2.exe: error: ld returned 1 exit status

当您在CubeMX中重新生成代码时,缺失的函数将生成至TouchGFX/target/generated/STM32DMA.cpp中。

如果您的控制器没有DMA2D(或未启用),CubeMX将包含TouchGFX 4.19.1和以前版本中使用的软件例程。

如果由于某种原因无法在CubeMX中重新生成代码,则可通过在应用程序的.cpp文件中插入以下includes来手动添加缺少的函数:

#include <touchgfx/hal/Paint.hpp>
#include <touchgfx/hal/PaintRGB565Impl.hpp> // 16bpp painting routines
#include <touchgfx/hal/PaintRGB888Impl.hpp> // 24bpp painting routines

使用Keil调试STM32G0

用于带X-NUCLEO-GFX01M1/2显示模块的STM32G0板的TouchGFX项目,使用0x90000000的地址范围来存储外部SPI Flash中的数据。 这样会中断Keil调试器,因其在启动调试会话时尝试访问这些地址。 Keil提示错误“无法访问目标。 正在关闭调试会话。”

在Keil中启动调试会话

解决方案是为调试器创建一个init脚本,其中包含以下文本:

load STM32G071_NUCLEO\STM32G071_NUCLEO.axf NOCODE
g,main

NOCODE选项提示Keil不加载代码。 这样就解决了访问的问题。

Keil的调试初始化脚本

在调试配置对话框中选择该文件:

Keil的调试配置

用Keil编译STM32U5和STM32L5项目

使用CubeMx创建的Keil项目在项目文件中缺少DSP扩展标签。 这会使链接器在与TouchGFX库链接时出错,该库设置了DSP扩展标签。 链接器错误类似于:

STM32U575ZI_NUCLEO\STM32U575ZI_NUCLEO.axf: L6366E: abstractpartition.o属性与提供的属性不兼容。
Object abstractpartition.o包含的Build Attributes与提供的属性不兼容。
Tag_DSP_extension =允许该代码使用Thumb DSP函数作为基础架构上的可选架构扩展,如Tag_CPU_arch (=1)所示

解决办法在您的.uvprojx项目文件中添加DSP标签(/Project/Targets/Target/Target option/TargetCommonOption/Cpu XML-element中):

<Targets>
<Target>
<TargetName>STM32U575ZI_NUCLEO</TargetName>
<ToolsetNumber>0x4</ToolsetNumber>
<ToolsetName>ARM-ADS</ToolsetName>
<pCCUsed>6120000::V6.12::.\ARMCLANG</pCCUsed>
<uAC6>1</uAC6>
<TargetOption>
<TargetCommonOption>
<Device>STM32U575ZITx</Device>
<Vendor>STMicroelectronics</Vendor>
<PackID>Keil.STM32U5xx_DFP.2.0.0</PackID>
<PackURL>https://www.keil.com/pack/</PackURL>
<Cpu>IRAM(0x20000000-0x200BFFFF) IROM(0x08000000-0x81FFFFF) CLOCK(8000000) FPU3(SFPU) CPUTYPE("Cortex-M33") ELITTLE TZ DSP</Cpu>
<FlashUtilSpec></FlashUtilSpec>

LOGONSERVER环境变量

我们在几台计算机上观察到TouchGFX非常慢(例如,“Run simulator”30秒内什么都不做)。 将环境变量LOGONSERVER设置为空值可能会有所帮助。

在bash中,命令是:

export LOGONSERVER=

TouchGFX 4.19.0

在H7上使用MJPEG Video生成STM32CubeMX代码

不幸的是,在STM32CubeMX 6.3.0或更早版本的STM32H750上使用MJPEG Video生成代码时,缺少将MDMA配置到MDMA处理程序的代码,如视频解码所示,开发人员必须手动添加突出显示的用户代码:

Core\Src\stm32h7xx_hal_msp.c
void HAL_JPEG_MspInit(JPEG_HandleTypeDef* hjpeg)
{
if(hjpeg->Instance==JPEG)
{
/* USER CODE BEGIN JPEG_MspInit 0 */
hmdma_jpeg_infifo_th.Init.Request = MDMA_REQUEST_JPEG_INFIFO_TH;
hmdma_jpeg_outfifo_th.Init.Request = MDMA_REQUEST_JPEG_OUTFIFO_TH;
/* USER CODE END JPEG_MspInit 0 */
...

使用字体排印的新方法

从TouchGFX 4.18.1到TouchGFX 4.19.0,字体排印的使用发生了变化。 现在,字体排印有一个默认设置和零或多个特定语言设置。

在Designer指南中 了解更多相关信息

文本特定的方向和字体排印不再是一个选项,这些选项转移到了新的默认设置和特定语言设置中。 该项新功能会对使用该功能的项目生成的代码产生影响。 文本转换器将为默认设置生成一个字体id,并为每种特定语言设置生成一个id。 根据特定语言设置生成的字体id将被自动命名,参见下面示例。

在TouchGFX 4.18中设置特定的文本方向和字体排印

示例:自动生成的字体id

  • 默认字体排印id: 标题
  • 特定语言设置: JPN

generated/fonts/include/fonts/ApplicationFontProvider.hpp中生成两个字体ID:

struct TypographyFontIndex
{
static const touchgfx::FontId HEADLINE = 0;
static const touchgfx::FontId HEADLINE_AUTO_GENERATED_FOR_JPN = 1;
};

升级到4.19.0时自动生成的字体排印

如前所述,文本特定的方向和字体排印不再是一个选项。 由于功能上的这一变化,在升级旧版本时,可能会生成具有默认和特定语言设置的新字体排印。 您可以通过id来识别这些自动生成的字体排印。 文本方向作为后缀或A-Z范围内的字母:

  • Headline_LTR
  • PosterText_RTL
  • Title_A
  • ButtonText_B

在用户代码中引用字体id

如果在用户代码中引用字体id,则可能需要对其进行更新。 当字体id不是通过符号而是通过值引用的情况下,会有出错的风险,因为在升级期间字体id可能会更改。 建议始终通过符号引用字体id,即:用TypographyFontIndex::HEADLINE而非0

将LibJPEG与ARMCLANG结合使用

在CubeMX中选择了LibJPEG中间件的ARMCLANG项目无法运行。 ARMCLANG启用半托管,因为LibJPEG引用libc文件函数(如:fopen)。
半托管使应用程序在启动时等待与半托管感知调试器连接。
解决此问题的一种方法是取消两个文件中对JFILE的定义来删除对LibJPEG中fopen的引用:LibJPEG/source/jdatasrc.c and LibJPEG/source/jdatadst.c:

LibJPEG/source/jdatasrc.c
#include "jerror.h"

#undef JFILE

/* Expanded data source object for stdio input */
#ifdef JFILE
LibJPEG/source/jdatadst.c
#include "jerror.h"

#undef JFILE

#ifndef HAVE_STDLIB_H /* <stdlib.h> should declare malloc(),free() */

H750B Discovery上的MJPEG视频

H750B Discovery板使用YCbCr视频数据的硬件解码。 TouchGFX为该板提供的代码中的一个错误导致某些视频播放会出现虚影。
解决方案是改为软件解码。 在某些情况下,也可以通过修改视频的宽度几个像素来解决问题。

ThreadX汇编程序文件

Keil IDE的ThreadX汇编程序文件使用新的ARMCLANG V6汇编程序语法。 某些固件包中提供的startup.s文件使用的是旧的ARMCC汇编程序语法。 这意味着您必须将项目设置为使用ARMCLANG V6汇编程序,然后针对startup_stm32xxx.s进行重写:

取消选择用于startup.s的ARMCLANG V6汇编程序

TouchGFX 4.18.0

CubeMX 6.1.0和CubeProgrammer 2.6的问题

由于“C/C++编译器” / “语言”选项的错误设置(从“自动”更改为“C++”导致编译错误),CubeMX生成的CubeMX 版本6.1.0 EWARM工程不能与X-CUBE-TOUCHGFX一起使用。 此问题将在CubeMX 6.1.1中进行修正。 在此期间,将选项手动改回“自动”将解决编译问题,但是会在CubeMX生成代码时还原。

CubeProgrammer 2.6中与外部加载器 (.stldr)引用方式相关的问题会损坏所有现有应用模板(AT)的Makefile,还会妨碍TouchGFX Designer中“运行目标”功能的正常工作。 此问题还扩展到了基于最新AT版本的用户工程。 应用程序模板将更新以修补该问题,并将适用于CubeProgrammer 2.5和2.6。 如果您已有不能与CubeProgrammer 2.6一起使用的基于AT的工程,您可以进行下列修改以添加支持。 在引用外部文件夹时,用户必须从bin文件夹执行STM32CubeProgrammer_CLI.exe。 一般而言,指:

  • cd进入STM32CubeProgrammer安装文件夹中的bin文件夹。
  • 执行命令,通过对.stldr文件的相对引用对连接的目标硬件进行烧录。
@cd "$(st_stm32cube_programmer_bin_path)" && ./$(stm_stm32cube_programmer_exe) -c port=SWD -d $(application_path)/$(binary_output_path)/target.hex -el $(stm32cubeLoader_relative_path) -hardRst
Note
CubeProgrammer错误在2.10版中得到解决。

新的.touchgfx格式

从TouchGFX 4.17.0到TouchGFX 4.18.0,.touchfgx文件的内容主要在两个方面做了重大改变。 其后果会全面更新.touchfgx文件,只需使用TouchGFX Designer打开TouchGFX工程文件,然后保存即可。 主要变化在以下领域:

默认值不再写入 .touchgfx文件

具有默认值(例如框体偏移量X=0,Y=0 或黑色(red=0,green=0,blue=0))的控件参数之前被写入.touchfgx文件;但在TouchGFX版本4.18.0中,这些值不再写入。 其结果会导致稍小些的.touchgfx文件。

删除了TextEntries块

重命名了SingleUseId,其名称现包含随机数字和字母(而不是连续的数字),这会简化合并几个活跃的开发人员共同开发的同一工程的工作,因为新的一次性使用文本id不会获得重复的id。 另外,.touchgfx中的“TextEntries”部分已被删除,这带来.touchgfx文件尺寸大大减少。

LCD16bpp::fillRect与LCD16bpp::drawGlyph

LCD16bpp中的fillRect和drawGlyph函数现在用完整的24位颜色(而非缩减后的16位(RGB565)颜色)传递给DMA。 这可能会导致硬件(非模拟器)上出现错误的颜色,可以通过CubeMX重新生成DMA类来修复该问题。

Makefile和xlsx

TouchGFX 4.18.0使用新的.xml格式(而不是以前使用的旧的.xlsx格式)来存储文本和译文。 这意味着Makefiles和visual studio项目中所有对"text .xlsx"的引用都应该改为"text .xml"。 TextConvert工具可以自动识别,即使旧的texts.xlsx文件存在而texts.xml不存在,其会将texts.xlsx转换为texts.xml,以适应所有未来的使用。

要查看能正常工作的新Makefile,只需使用TouchGFX Designer新建一个(空白)项目,文件位于文件夹generated/simulator/gcc/Makefile中。

texts.xsd中的字体大小限制

Designer中用于验证texts.xml的texts.xsd的字体大小有255的限制。 如果字体大于255,您将在Designer中看到如下错误消息:

错误消息-字体大小限制

解决方法是关闭工程,将texts.xsd中的“字体大小”属性从xs:unsignedByte更改为xs:unsignedInt,然后重新打开工程。

Linux上的SDL2链接器错误

现在只为Windows用户提供仿真器使用的SDL2库。 Linux用户需要自己安装SDL2库。 仅需要执行一次的命令,对于ubuntu,命令是

sudo apt install libsdl2-dev libsdl2-image-dev

即可安装libsdl2和libsdl2-image,包含开发所用的头文件。

TouchGFX 4.17.0

绘图工具不再支持setAlpha()

出于性能方面的考虑,Canvas Widget Renderer(CWR)使用的绘图控件不再支持alpha。 通过在有绘图控件的画布控件上设置alpha,仍然可以达到效果。 一般而言,可以将下面这样的代码:

painter.setColor(Color::getColorFromRGB(0xFF, 0x00, 0x00));
painter.setAlpha(128);
circle.setPainter(painter);

修改成这样:

painter.setColor(Color::getColorFromRGB(0xFF, 0x00, 0x00));
circle.setPainter(painter);
circle.setAlpha(128);

如果之前将alpha应用于绘图控件和画布控件,可以将这两个alpha值相乘,然后除以255,如下所示:

painter.setColor(Color::getColorFromRGB(0xFF, 0x00, 0x00));
painter.setAlpha(painterAlpha);
circle.setPainter(painter);
circle.setAlpha(circleAlpha);

变成

painter.setColor(Color::getColorFromRGB(0xFF, 0x00, 0x00));
circle.setPainter(painter);
circle.setAlpha((painterAlpha * circleAlpha) / 255);

或者使用LCD::div255()替代除以255。

使用HAL类

在版本4.17.0之前,完全不使用HAL的TouchGFX框架中的多个文件包含头文件touchgfx/hal/HAL.hpp。 这可能导致用户代码由于编译器不知道HAL而不进行编译。这些不必要的引用现已清理。 为了修正这个问题,只需包含HAL头文件,如下所示:

#include <touchgfx/hal/HAL.hpp>

另外,Screen类有两个新函数getScreenWidth() 和getScreenHeight(),用于给出屏幕尺寸。 推荐该方法用来获得屏幕尺寸,可从Screen的任意子类(如Screen1View.cpp)直接调用。

TouchGFX Generator中的FMC显示接口

当使用TouchGFX Generator中新的FMC显示接口时,用CubeMX 6.2.1生成时FMC存储区的内存偏移是不正确的(零)。 这会在CubeMX 6.3.0中修正,在发布时,X-CUBE-TouchGFX需要的最低版本将跳至6.3.0而不是目前的6.2.1。 到那时,用户可以在TouchGFXGeneratedHAL.cpp中输入正确的FMC BANK存储地址(将在重新生成时被覆盖)。 如

#define FMC_BANK1_REG ((uint16_t *) 0x60000000)
#define FMC_BANK1_MEM ((uint16_t *) 0x60000002)

用户还可以在TouchGFXHAL.cpp中全部重新定义它们。

16-24或32bpp配置的L8图像

在加载L8图像的CLUT时,对OSWrappers::taskYield() 的调用被错误地引入了STM32DMA类。 要解决此问题,用户可以执行以下操作:

  1. 导航到您的Users/<user name>/STM32Cube/Repository/Packs/STMicroelectronics/X-CUBE-TOUCHGFX/4.17.0/CubeMX/templates/Target文件夹。
  2. 根据您的位深打开相应的dma\u Xbpp\u implementation\u tmp.ftl文件
  3. 删除或注释while ((READ_REG(DMA2D->FGPFCCR) & DMA2D_FGPFCCR_START) != 0U)循环中对 OSWrappers::taskYield()的调用,并从STM32CubeMX重新生成代码,以使用此修改的模板生成代码。
while ((READ_REG(DMA2D->FGPFCCR) & DMA2D_FGPFCCR_START) != 0U)
{
// OSWrappers::taskYield();
}

TouchGFX 4.15.0

支持的MCU

虽然TouchGFX完全支持Cortex-M33,但在CubeMX中添加支持前,当前CubeMX(v6.0.1)版本中不能启用多上下文MCU的“软件包”(包括TouchGFX Generator)。 对基于Cortex-M33的MCU禁用“Trust Zone”,从而将MCU限制在单上下文,将允许您启用TouchGFX Generator。 应在“用户代码”区手动使能TrustZone。

TouchGFX 4.14.0

ARMCLANG支持

虽然TouchGFX现在为Cortex-M0Cortex-M4fCortex-M7Cortex-M33提供ARMCLANG(ARM编译器v6.x)库,CubeMX却不能生成启用ARMCLANG编译器(ARM编译器v6.x)的工程。 想在其工程中使用该编译器的用户需要在Keil uVision中的工程选项中手动选择编译器。

如果在CubeMX内配置FreeRTOS中间件,生成的任何使用ARMCC(ARM编译器v5.x)的工程都都会包含FreeRTOS可移植文件,这些文件与ARMCLANG是不兼容的;必须手工替换这些文件。 每当从CubeMX内部运行“生成代码”时,任何手工修改都会被覆盖,最好在版本控制(git等)下维护工程,以便撤销这些特定修改。

总之, 由于CubeMX只能生成使用ARM Compiler v5.x编译器的工程,因此用户每次从CubeMX生成代码时必须修改下列内容,在版本控制下维护项目除外。

  1. 在工程选项中选择ARM Compiler v6.x。
  2. 链接ARMCLANG库而不是ARMCC库(通过CubeMX配置)。
  3. 如果在CubeMX内配置FreeRTOS,为了兼容ARM Compiler v6.x,应从portable/GCC文件夹获取FreeRTOS可移植文件,而不是portable/RVDS文件夹(ARM Compiler v5.x的默认选择)。

工作流程

下列流程描述了如何在Keil uVision中对CubeMX生成的工程使用v6.x ARM 编译器和TouchGFX ARMCLANG库。

  1. 在Keil uVision中选择ARMCLANG(v. 6.x)。

ARMCLANG支持

  1. 如果您在CubeMX中配置了FreeRTOS,CubeMX将生成错误的可移植文件,并将您的工程配置为使用这些文件。 您必须使用来自https://github.com/FreeRTOS/FreeRTOS-Kernel/tree/6199b72fbf57a7c5b3d7b195a3bd1446779314cd/portable/GCC的文件(`port.c`和`portmacro.h`)或下载一个FreeRTOS版本并从中找到相应文件来手工替换。

    替换port.c

    port.c

    将include路径设置修改为包含portable/GCC文件夹中的portmacro.h(本例中以Cortex-M7为例):

    可移植文件包含路径

  2. “生成代码”期间中,TouchGFX Designer生成后步骤会根据您选择的编译器版本自动插入正确的库。

TouchGFX 4.13.0

错误

字体转换器

FontConverter工具会为unicodes码生成字形像素数据,这是字体规则的一部分,而无论该字形是否在应用中实际文本中用到。 这可能会导致数兆字节的额外字形像素数据。 这里可以找到不会为应用中未使用的字形生成像素数据的FontConverter新工具(Windows和Linux):

在4.13.0安装的根目录下提取该压缩文件将更新touchgfx\framework\tools内部的fontconverter库

touchgfx\framework\tools

额外编译器支持

用ARMCLANG编译器(v6.12)构建的库可以在这里找到:

在4.13.0安装的根目录提取此文件可将库touchgfx_core_clang.lib置入

touchgfx\lib\core\cortex_m7\Keil

向后兼容

已弃用的功能

下列弃用的功能已经被移除了。 如果您在代码中引用了它们,您可能需要重新编写应用中的这部分内容:

  • 已弃用的 TRANSPARENT_COL定义
  • Drawable::getType()
  • HAL::blitSetTransparencyKey()
  • HAL::registerTextCache()
  • HAL::cacheTextString()

默认禁用TextureMapper

默认禁用TextureMapper,以消减TouchGFX使用的代码空间。 TouchGFX designer会在所有新工程中插入代码,以启用纹理映射器。

如果您将旧工程移植到TouchGFX 4.13,并更新至TouchGFX 4.13,将由TouchGFX Designer处理这些问题。

如果是手工更新,则需要插入代码来启用TextureMapper。 否则,将不会在屏幕上绘制任何TextureMapper。

阅读更多内容:配置TouchGFX特性

不兼容HAL SDL1

有两个函数从TouchGFX库代码移到了HALSDL2.cpp。 这对将HALSDL2.cpp用在Windows模拟器的HAL应用而言没有分别。

如果您有一个老应用(早于TouchGFX 4.8.0),则您的模拟器可能是在使用HALSDL(非2)。 此模拟器HAL不再包含在TouchGFX中。 HALSDL缺失了之前包含在TouchGFX库中的两个函数。 您需要将它们手动添加到HALSDL.cpp

HALSDL.cpp
void simulator_enable_stdio();
void simulator_enable_stdio()
{
HWND consoleHwnd = GetConsoleWindow(); // Get handle of console window
if (!consoleHwnd) // No console window yet?
{
HWND activeHwnd = GetActiveWindow(); // Remember which window is active

AllocConsole(); // Allocate a new console
consoleHwnd = GetConsoleWindow(); // Get handle of console window

FILE* dummy;
freopen_s(&dummy, "CONIN$", "r", stdin); // Redirect stdin/stdout/stderr to the new console
freopen_s(&dummy, "CONOUT$", "w", stdout);
freopen_s(&dummy, "CONOUT$", "w", stderr);

SwitchToThisWindow(activeHwnd, true); // Switch back to the originally active window
}
if (consoleHwnd)
{
ShowWindow(consoleHwnd, SW_SHOW); // Show/hide it!
}
}
void simulator_printf(const char* format, va_list pArg);
void simulator_printf(const char* format, va_list pArg)
{
// Create a console window, if window is visible.
simulator_enable_stdio();
if (GetConsoleWindow()) // Only print if we have a console window
{
vprintf(format, pArg);
}
}

TouchGFX 4.12.3

向后兼容

屏幕切换

更早的版本在完成屏幕切换后重绘整个屏幕。 额外的重绘在一些较慢的平台上会导致了性能问题。 如果您出于某些原因需要此类重绘,则需要使屏幕的相关部分失效,例如,在切换到的屏幕的虚函数Screen::afterTransition()中调用container.invalidate()

二进制字体

由于字距调整数据现已包含在二进制字体中,因而修改了二进制字体的格式。 需要重新生成二进制字体文件,原有的老文件会工作不正常。 根据Makefiles的设置方式,通常可以通过重新生成所有资源来完成(如“make -f simulator/gcc/Makefile clean assets”)。

TouchGFX 4.11.0

向后兼容

touchgfx/framework/include/touchgfx/lcd/LCD.hpp中,我们删除了头文件touchgfx/hal/HAL.hpp,这个是在早期版本中误插入的。 这可能会导致包含LCD.hpp并使用HAL.hpp内容的文件发生编译错误。 解决方案是在您的文件中也包含进touchgfx/framework/include/touchgfx/hal/HAL.hpp

TouchGFX 4.10.0

从4.9.x升级

从版本4.10.0开始,TouchGFX只在STM32 MCU上运行。

如需更新老项目,您需要执行下列操作。

在应用启动时添加下面突出显示的代码,以通知TouchGFX正在STM32硬件上运行。 合适的添加位置是BoardConfiguration.cpphw_init()函数的结尾处。

BoardConfiguration.cpp
void hw_init() {
...
//Enable CRC engine for STM32 Lock check
__HAL_RCC_CRC_CLK_ENABLE();
}

向后兼容

删除了未使用的文件\touchgfx\framework\include\touchgfx\canvas_widget_renderer\RGBA8.hpp

工程更新器的问题

从TouchGFX Designer调用的IAR和Keil工程更新器不遵循在相应IDE中设置的自定义文件级别优化。

TextArea和ChromART(DMA2D)

用ChromART渲染TextAreas(当TextArea是最顶端的元素/最后进行绘制时)导致帧缓冲区提前解锁,继而导致当前帧提前完成/传输到显示屏。 在TouchGFX调用endFrame()后,所有绘制操作(包括DMA操作)应已完成。 由于TextArea在如何恰当地保护帧缓冲区方面违反该约定,即使从endFrame()返回后,仍然允许DMA操作继续。

控件的约定为:

  1. 锁定帧缓冲(返回指向帧缓冲的指针)。
  2. 在帧缓冲中绘制一些内容。 
  3. 解锁帧缓冲区。

或者,使用DMA操作,这种情况下将自动处理帧缓冲的同步。

在版本4.10.0中,如果是当前屏幕最顶端的元素(最后进行绘制),TextArea将两个流程混合可能导致短时间的故障。 该问题可通过用下列endFrame()重写手工保护endFrame()来修正(基于F4 HAL)。 此举确保如果ChromART操作仍在进行时endFrame()不返回。  

void STM32F4HAL::endFrame()
{
if (dma.isDMARunning())
{
OSWrappers::tryTakeFrameBufferSemaphore();
}
HAL::endFrame();
}

TouchGFX 4.9.0

从4.8.0升级

随着应用模板(从实质上将板支持包与核心框架分离开来)的引入,我们在版本4.9.0的touchgfx文件夹中删除了许多底层驱动和其他文件。 这些文件现在由应用模板提供。 但是,这也意味着您不能通过仅仅替换touchgfx文件夹来升级到4.9.0,那样做会导致一些BSP文件缺失。 反之,TouchGFX Designer能够自动执行升级。 可通过两种不同的方式升级,您需要确定哪种方式是适合。

Caution
请确保升级前进行了工程备份。

方法1:保留原始文件结构

使用该方法,只需在新的TouchGFX Designer 4.9.0中打开工程。 TouchGFX Designer将提示您是否要升级,在点击“确定”后,TouchGFX Designer将进行必要的修改。 TouchGFX Designer将执行下列操作:

  1. 将新的压缩过的touchgfx文件夹解压到应用中,并修改TouchGFX路径以与之匹配。
  2. 下载并解压所有已从touchgfx文件夹中删除的文件,因此您的工程仍然可以通过编译。

此方法几乎会让一切保持原样,如果原有文件结构适合您的工程,则这是最轻松的选择。 此方法的主要缺点是不会有图像转换器加速(通过操作图像文件夹而不是单个文件)。 但是,您可以手动修改makefile,以便使用此方法。

方法2:导入到新的模板

您可以使用此方法将工程转换到基于新模板的文件结构中。 为此,您必须首先使用上面的方法1让Designer升级工程。 然后,使用合适的应用模板(模拟器或与您的评估板匹配的应用模板)新建工程。 在Designer中打开此新工程后,转至顶部菜单并点击“编辑->导入GUI”。 在对话框中指定工程的.touchgfx文件。 Designer会自动将所有UI文件(包括资源)导入新建的工程。 如果您在gui文件夹之外增加了额外的代码,您需要将这些文件手动复制到新工程。

方法3:手工升级(无TouchGFX Designer)

如果不使用TouchGFX Designer,您可以用以下方式进行升级:

  1. 用版本4.9.0的安装文件夹中的touchgfx文件夹替换您工程中使用的touchgfx文件夹。
  2. 下载本zip文件并将其解压到touchgfx文件夹,恢复删除的文件。