주요 내용으로 건너뛰기

알려진 문제

'@site/components/Caution'에서 Caution 가져오기, '@site/components/Figure'에서 Figure 가져오기, '@site/components/InlineNote'에서 InlineNote 가져오기, '@site/components/Shortcut'에서 Shortcut 가져오기

이 섹션에서는 모든 TouchGFX 버전에 존재하는 것으로 알려진 문제와 가능한 해결책을 알아보겠습니다. 또한 TouchGFX를 특정 버전으로 업그레이드하는 데 필요한 단계가 있다면 함께 알려드리겠습니다. 다만 현재 사용 중인 버전이 이전 릴리스라면 최신 릴리스 버전으로 업그레이드하는 단계를 수행해야 합니다.

TouchGFX 4.19.0​

새로운 타이포그래피 작업 방식​

TouchGFX 4.18.1에서 TouchGFX 4.19.0으로 사용되는 타이포그래피가 바뀌었습니다. 이제 타이포그래피에는 기본 설정과 0개 이상의 언어별 설정이 있습니다

이에 대한 자세한 내용은 TouchGFX Designer 가이드를 참조

텍스트별 방향 및 타이포그래피는 더 이상 옵션이 아닙니다. 이러한 옵션들은 새로운 기본 설정 및 언어별 설정으로 이동되었습니다. 이러한 기능의 변경은 이 기능을 사용했던 프로젝트에서 생성된 코드에 영향을 줍니다. 텍스트 변환기는 기본 설정에 대한 글꼴 ID와 각 언어별 설정에 대한 글꼴 ID를 생성합니다. 언어별 설정에서 생성된 글꼴 ID에는 자동으로 이름이 지정됩니다(아래 예 참조).

TouchGFX 4.18에서 특정 텍스트의 방향 및 타이포그래피 설정

예: 자동 생성된 글꼴 ID​

  • 기본 타이포그래피 ID: HEADLINE
  • 언어별 설정: 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는 항상 기호로 참조하는 것이 좋습니다(예를 들어 0이 아니라 TypographyFontIndex::HEADLINE로 참조).

ARMCLANG에서 LibJPEG 사용​

CubeMX에서 LibJPEG 미들웨어가 선택된 ARMCLANG 프로젝트는 실행이 불가능합니다. ARMCLANG은 LibJPEG가 libc 파일 함수(예: fopen)를 참조하기 때문에 세미 호스팅을 사용합니다.
세미 호스팅은 애플리케이션에게 시작 단계에서 세미 호스팅 인식 디버거에 대한 연결을 기다리도록 합니다.
이 문제를 해결하는 한 가지 방법은 LibJPEG/source/jdatasrc.c와 LibJPEG/source/jdatadst.c 두 파일에서 JFILE의 정의를 해제하여 LibJPEG에서 fopen에 대한 참조를 제거하는 것입니다.

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에서 알려진 문제​

버전 CubeMX 6.1.0부터 CubeMX에서 생성된 EWARM 프로젝트는 X-CUBE-TOUCHGFX와 호환되지 않는데, 이는 "C/C++ Compiler" / "Language" 옵션이 "Auto"에서 "C++"로 변경되어 잘못 설정되는 바람에 컴파일 오류가 발생하기 때문입니다. 이 문제는 CubeMX 6.1.1에서 해결될 예정입니다. 한편, 옵션을 수동으로 다시 "Auto"로 변경하면 컴파일 문제가 해결되지만 CubeMX에서 코드를 생성하면 원래 설정으로 돌아갑니다.

CubeProgrammer 2.6에서는 외부 로더(.stldr)의 참조 방식과 관련된 버그가 기존 애플리케이션 템플릿(AT)에 사용되는 Makefile을 손상시킬 뿐만 아니라 TouchGFX Designer에서 "Run Target” 기능의 정상적인 작동을 방해합니다. 이 문제는 현재 AT 버전을 기준으로 사용자 프로젝트에도 영향을 미칩니다. 이 버그에 대한 보상을 목적으로 애플리케이션 템플릿에 대한 업데이트가 예정되어 있으며, CubeProgrammer 2.5와 2.6에 모두 적용됩니다. 만약 CubeProgrammer 2.6과 호환되지 않는 AT를 기반으로 프로젝트를 생성했다면 다음과 같이 수정하여 지원을 추가할 수 있습니다. 사용자가 외부 로더를 참조할 때 bin 폴더에서 STM32CubeProgrammer_CLI.exe를 실행해야 합니다. 일반적으로,

  • STM32CubeProgrammer 설치 폴더의 bin 폴더로 cd 명령을 실행합니다.
  • 아래와 같이 명령을 실행하여 .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
버전 2.10에서는 CubeProgrammer 버그가 해결되었습니다.

새로운 .touchgfx 형식​

TouchGFX 4.17.0에서 TouchGFX 4.18.0로 업데이트되면서 .touchfgx 파일의 내용이 두 가지 주요 영역에서 크게 바뀌었습니다. 이에 따라 TouchGFX Designer를 사용해 .touchgfx 프로젝트 파일을 열고 저장하는 것만으로도 .touchfgx 파일이 대폭 업데이트될 수도 있습니다. 주요 변화가 일어난 영역은 다음과 같습니다.

기본 값이 .touchgfx에 작성되지 않음​

박스 오프셋 X=0, Y=0 또는 검은색(빨간색=0, 녹색=0, 파란색=0) 같은 기본값이 있는 위젯 매개변수가 이전에는 .touchgfx 파일에 작성되었지만 TouchGFX version 4.18.0부터는 이러한 기본값이 작성되지 않습니다. 이에 따라 .touchgfx 파일의 용량이 다소 줄어들 수 있습니다.

TextEntries 블록 삭제​

새로운 Single Use 텍스트가 동일한 id를 갖지 않기 때문에 일부 개발자와 프로젝트 병합을 용이하게 추진하기 위해 SingleUseId의 이름이 시퀀스 번호가 아닌 난수와 임의 문자를 포함하도록 바뀌었습니다. 또한 .touchgfx 파일에서 "TextEntries” 섹션이 삭제되어 .touchgfx 파일 크기가 크게 줄어들 수 있습니다.

LCD16bpp::fillRect 및 LCD16bpp::drawGlyph​

LCD16bpp에서 fillRect 함수와 drawGlyph 함수가 이제 줄어든 16비트(RGB565) 색상이 아닌 24비트 색상을 DMA에게 전달합니다. 이로 인해 시뮬레이터가 아닌 하드웨어에서 잘못된 색상이 나타날 수 있지만 CubeMX에서 DMA 클래스를 다시 생성하면 문제를 해결할 수 있습니다.

Makefile 및 xlsx​

TouchGFX 4.18.0은 이전에 사용했던 .xlsx 형식이 아닌 새로운 .xml 형식을 사용해 텍스트와 번역을 저장합니다. 이는 Makefile와 Visual Studio 프로젝트의 참조 파일인 "texts.xlsx"가 모두 "texts.xml"로 바뀌어야 한다는 것을 의미합니다. TextConvert 도구는 이러한 변화를 인식하여 texts.xlsx 파일이 존재하고, texts.xml 파일이 존재하지 않더라도 이후에 사용할 때마다 texts.xlsx를 texts.xml로 변환합니다.

새로운 유효 Makefile을 보고 싶다면 TouchGFX Designer를 사용해 새로운(비어있는) 프로젝트를 생성한 다음 generated/simulator/gcc/Makefile 폴더에 만들어진 Makefile을 찾아보면 됩니다.

texts.xsd의 글꼴 크기 제한​

TouchGFX Designer가 texts.xml의 유효성을 검사하는 데 사용하는 texts.xsd의 글꼴 크기는 255로 제한됩니다. 글꼴 크기가 255보다 클 경우, TouchGFX Designer에서 다음과 같이 오류 메시지가 표시됩니다.

오류 메시지 - 글꼴 크기 제한

프로젝트를 닫고 texts.xsd에서 Typography Size 속성을 xs:unsignedByte에서 xs:unsignedInt로 변경한 다음, 프로젝트를 다시 열면 문제가 해결됩니다.

Linux의 SDL2 링커 오류​

시뮬레이터에서 사용되는 SDL2 라이브러리는 이제 Windows 사용자에게만 기본적으로 제공됩니다. Linux 사용자는 SDL2 라이브러리를 직접 설치해야 합니다. 설치 작업은 한 번에 완료하며, ubuntu의 경우 명령은 다음과 같습니다.

sudo apt install libsdl2-dev libsdl2-image-dev

그러면 개발용 헤더 파일을 포함해 libsdl2와 libsdl2-image가 설치됩니다.

TouchGFX 4.17.0​

페인터가 더 이상 setAlpha()를 지원하지 않습니다.​

캔버스 위젯 렌더러(CWR)에서 사용되는 페인터는 성능 문제로 알파를 더는 지원하지 않습니다. 하지만 페인터가 포함된 캔버스 위젯에서 알파를 설정하면 알파 효과가 지속됩니다. 일반적으로 코드를 다음과 같은 모습에서

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);

이전에 페인터와 캔버스 위젯에 알파를 적용했다면 다음과 같이 두 알파 값을 곱셈한 후 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);

그 밖에 255로 나누지 않고 LCD::div255()를 사용하는 방법도 있습니다.

HAL 클래스 사용​

버전 4.17.0 이전에는 헤더 파일 touchgfx/hal/HAL.hpp가 HAL을 전혀 사용하지 않는 TouchGFX 프레임워크의 일부 파일에 포함되었습니다. 이렇게 불필요한 참조는 삭제되었지만 결과적으로 컴파일러가 HAL을 인식하지 못하기 때문에 사용자 코드를 컴파일하지 못할 수도 있습니다. 이러한 문제는 다음과 같이 HAL 헤더 파일을 추가하여 간단하게 해결할 수 있습니다.

#include <touchgfx/hal/HAL.hpp>

또한 Screen 클래스에 스크린 크기를 지정할 수 있는 getScreenWidth() 함수와 getScreenHeight() 함수가 새로 추가되었습니다. 두 함수는 스크린 크기를 지정하는 데 유용한 방법으로 Screen1View.cpp 같은 스크린 서브 클래스에서 직접 호출할 수 있습니다.

TouchGFX Generator의 FMC 디스플레이 인터페이스​

TouchGFX Generator에서 새로운 FMC 디스플레이 인터페이스를 사용할 경우 CubeMX 6.2.1에서 생성하면 FMC 뱅크의 메모리 오프셋이 정확하지 않습니다(0). 이 문제는 CubeMX 6.3.0에서 해결될 예정이며, 릴리스되면 X-CUBE-TouchGFX의 최소 필요 버전도 6.2.1이 아닌 6.3.0으로 상향됩니다. 사용자는 문제가 해결될 때까지 TouchGFXGeneratedHAL.cpp에서 FMC 뱅크 메모리 주소를 정확하게 입력할 수 있습니다(재생성 시 덮어쓰게 됩니다). 예를 들면 다음과 같습니다.

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

그 밖에도 사용자는 TouchGFXHAL.cpp에서 완전히 재정의할 수 있습니다.

16- 24- 또는 32bpp 구성에서의 L8 이미지​

Cortex-M33은 현재 TouchGFX에서 완벽하게 지원되지만 현재 CubeMX 버전(v6.0.1)에서는 CubeMX에 지원이 추가될 때까지 "소프트웨어 팩"(특히 TouchGFX Generator)을 멀티 컨텍스트 MCU에 사용할 수 없습니다. 하지만 Cortex-M33 기반 MCU에서 "Trust Zone”을 비활성화하면 MCU가 단일 컨텍스트로 제한되어 TouchGFX Generator를 사용할 수 있습니다.

  1. 프로젝트 옵션에서 ARM Compiler v6.x를 선택합니다.
  2. ARMCC 라이브러리(CubeMX에서 구성)가 아닌 ARMCLANG 라이브러리와 연결합니다.
  3. CubeMX에서 FreeRTOS를 구성한 경우 FreeRTOS 이식 가능 파일을 portable/RVDS 폴더(ARM Compiler v5.x의 기본 폴더)가 아닌 portable/GCC 폴더에서 가져와야 ARM Compiler v6.x와 호환됩니다.
while ((READ_REG(DMA2D->FGPFCCR) & DMA2D_FGPFCCR_START) != 0U)
{
    // OSWrappers::taskYield();
}

TouchGFX 4.15.0​

MCU 지원​

이제 TouchGFX가 ARMCLANG(ARM 컴파일러 v6.x) 라이브러리를 Cortex-M0, Cortex-M4f, Cortex-M7 및 Cortex-M33에게 제공하기 때문에 CubeMX가 ARMCLANG 컴파일러(ARM 컴파일러 v6.x)를 실행하는 프로젝트를 생성할 수 없습니다. 이에 따라 프로젝트에서 컴파일러를 사용하고자 하는 사용자는 Keil uVision의 프로젝트 옵션에서 컴파일러를 수동으로 선택해야 합니다. 단, TrustZone는 사용자 코드 섹션에서 수동으로 활성화해야 합니다.

TouchGFX 4.14.0​

ARMCLANG Support​

CubeMX에서 FreeRTOS 미들웨어를 구성한 경우 ARMCC(ARM Compiler v5.x)를 사용해 생성된 프로젝트에 FreeRTOS 이식 가능 파일이 만들어지지만 ARMCLANG과 호환되지 않습니다. 따라서 수동으로 교체해야 합니다. 수동으로 변경한 내용은 CubeMX에서 "Generate code"를 실행할 때마다 덮어쓰게 되기 때문에 프로젝트의 버전을 지속적으로 관리(git 등)하여 특정 변경 내용을 실행 취소하는 것이 좋습니다.

요약하자면, CubeMX는 오직 ARM Compiler v5.x 컴파일러 프로젝트만 생성하기 때문에 사용자는 프로젝트의 버전을 지속적으로 관리하지 않는 한 CubeMX에서 코드가 생성될 때마다 다음과 같이 수정해야 합니다.

요약하자면, CubeMX는 오직 ARM Compiler v5.x 컴파일러 프로젝트만 생성하기 때문에 사용자는 프로젝트의 버전을 지속적으로 관리하지 않는 한 CubeMX에서 코드가 생성될 때마다 다음과 같이 수정해야 합니다.

  1. Keil uVision에서 ARMCLANG(v. 6.x)을 선택합니다.
  2. ARMCC 라이브러리(CubeMX에서 구성)가 아닌 ARMCLANG 라이브러리와 연결합니다.
  3. CubeMX에서 FreeRTOS를 구성한 경우 FreeRTOS 이식 가능 파일을 portable/RVDS 폴더(ARM Compiler v5.x의 기본 폴더)가 아닌 portable/GCC 폴더에서 가져와야 ARM Compiler v6.x와 호환됩니다.

워크플로​

다음 워크플로는 Keil uVision에서 ARM Compiler v6.x를 구성하여 CubeMX 생성 프로젝트 및 TouchGFX ARMCLANG 라이브러리와 함께 사용할 수 있는 방법을 설명한 것입니다.

  1. Keil uVision에서 ARMCLANG(v. 6.x)을 선택합니다.
ARMCLANG Support

  1. CubeMX에서 FreeRTOS를 구성하면 CubeMX가 잘못된 이식 가능 파일을 생성하고 프로젝트에서 잘못된 파일을 사용하도록 구성하게 됩니다. 이 파일들은 port.c 및 portmacro.h 파일(https://github.com/FreeRTOS/FreeRTOS-Kernel/tree/6199b72fbf57a7c5b3d7b195a3bd1446779314cd/portable/GCC)로 수동으로 교체하거나, 혹은 FreeRTOS 릴리스를 다운로드하여 해당 파일을 직접 찾아야 합니다.

    아래와 같이 port.c를 교체합니다.

    port.c

    include 경로 설정을 변경하여 portable/GCC 폴더의 portmacro.h 파일이 포함되도록 설정합니다(여기에서는 Cortex-M7).

    Portable include 경로

  2. TouchGFX Designer는 "Generate Code”의 Post-Generate 단계에서 사용자가 선택한 컴파일러 버전에 따라 정확한 라이브러리를 자동으로 삽입합니다.

TouchGFX 4.13.0​

버그​

글꼴 변환 도구​

이전에는 글꼴 변환 도구가 실제 애플리케이션 텍스트에서 사용되는 글리프와 상관없이 글꼴 규칙에 포함된 유니코드에 맞춰 글리프 픽셀 데이터를 생성했습니다. 이로 인해 글리프 픽셀 데이터가 추가로 몇 메가바이트 늘어날 가능성이 높았습니다. 이제는 새로운 글꼴 변환 도구(Windows 및 Linux)가 애플리케이션에서 사용하지 않는 글리프 픽셀 데이터를 더 이상 생성하지 않습니다. 새로운 글꼴 변환 도구는 여기에서 찾아볼 수 있습니다.

4.13.0이 설치된 루트 경로에서 이 파일의 압축을 풀면 내부에서 글꼴 변환 도구 바이너리가 업데이트됩니다.

touchgfx\framework\tools

추가 컴파일러 지원​

4.13.0이 설치된 루트 경로에서 이 파일의 압축을 풀면 내부에 touchgfx_core_clang.lib 라이브러리가 저장됩니다.

4.13.0이 설치된 루트 경로에서 이 파일의 압축을 풀면 내부에 touchgfx_core_clang.lib 라이브러리가 저장됩니다.

touchgfx\lib\core\cortex_m7\Keil

하위 호환성​

지원 종료 기능​

TextureMapper는 TouchGFX에서 사용하는 코드 공간을 줄이기 위해 기본적으로 비활성화됩니다. TouchGFX Designer가 새로운 프로젝트에서 코드를 삽입하여 TextureMapper를 활성화합니다.

  • 지원 종료된 TRANSPARENT_COL의 정의
  • Drawable::getType()
  • HAL::blitSetTransparencyKey()
  • HAL::registerTextCache()
  • HAL::cacheTextString()

TextureMapper는 기본적으로 비활성화되어 있습니다.​

TextureMapper는 TouchGFX에서 사용하는 코드 공간을 줄이기 위해 기본적으로 비활성화됩니다. TouchGFX Designer가 새로운 프로젝트에서 코드를 삽입하여 TextureMapper를 활성화합니다.

이전 프로젝트를 TouchGFX 4.13으로 마이그레이션하고, TouchGFX 4.13으로 업데이트하면 이러한 과정을 TouchGFX Designer에서 처리합니다.

그렇지 않고 수동으로 업데이트하는 경우에는 코드를 삽입하여 TextureMapper를 활성화해야 합니다. 그렇지 않으면 TextureMapper가 스크린에 드로잉하지 않습니다.

자세한 내용은 TouchGFX 기능 구성을 참조하십시오.

호환되지 않는 HAL SDL1​

하지만 TouchGFX 4.8.0 이전 애플리케이션이라면 시뮬레이터에서 HALSDL(2 아님)을 사용할 수도 있습니다. 이 시뮬레이터 HAL은 TouchGFX에 더는 포함되지 않습니다.

하지만 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()를 호출해야 합니다.

이진 글꼴​

이제 이진 글꼴에 커닝 데이터도 포함되기 때문에 이진 글꼴의 형식이 바뀌었습니다. 이에 따라 이진 글꼴 파일을 다시 생성해야 하며, 이전 파일은 올바르게 실행되지 않습니다. Makefile 설정 방식에 따라 다르지만 일반적으로 모든 애셋을 다시 생성하여 실행됩니다(예: make -f simulator/gcc/Makefile clean assets).

TouchGFX 4.11.0​

하위 호환성​

touchgfx/framework/include/touchgfx/lcd/LCD.hpp에서 초기 버전에 실수로 삽입되었던 touchgfx/hal/HAL.hpp 파일의 include가 제거되었습니다. 이에 따라 LCD.hpp가 포함된 파일에서 컴파일 오류가 발생할 뿐만 아니라 HAL.hpp 내용을 이용하게 될 수도 있습니다. 이 문제 역시 파일에 touchgfx/framework/include/touchgfx/hal/HAL.hpp를 추가하면 해결됩니다.

TouchGFX 4.10.0​

4.9.x에서 업그레이드​

TouchGFX는 버전 4.10.0부터 STM32 MCU에서만 실행됩니다.

따라서 이전 프로젝트를 업데이트할 경우에는 다음과 같이 따라야 합니다.

애플리케이션 시작 단계에서 아래 강조 표시된 코드를 추가하여 TouchGFX에게 STM32 하드웨어에서 실행한다는 것을 알립니다. 추가할 위치는 BoardConfiguration.cpp에서 hw_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를 사용해 TextArea를 렌더링하면(TextArea가 항상 위에 있는 요소이기 때문에 마지막에 드로잉되는 경우) 프레임버퍼 잠금을 조기에 해제하기 때문에 결과적으로 너무 이른 시기에 완료되어 현재 프레임을 디스플레이로 전송하게 됩니다. 일단 TouchGFX에서 endFrame()이 호출되면 DMA 연산을 포함해 모든 드로잉 연산이 완료되어야 합니다. 하지만 TextArea에서 프레임버퍼를 보호하는 방법에 대한 절차를 위반하여 DMA 연산은 endFrame()에서 값이 반환된 후에도 계속 실행됩니다.

위젯의 절차는 다음 중 한 가지를 따라야 합니다.

  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가 업그레이드를 자동 실행할 수 있습니다. 업그레이드에는 두 가지 방식이 있기 때문에 자신에게 가장 적합한 방식을 선택해야 합니다.

업그레이드 전에 반드시 프로젝트를 백업하시기 바랍니다.

방법 1: 이전 파일 구조 유지​

이 방법은 새 Designer 4.9.0에서 프로젝트를 열기만 하면 실행됩니다. 그러면 TouchGFX Designer가 업그레이드 여부를 묻고, 여기서 OK를 클릭하면 TouchGFX Designer가 필요한 변경 사항을 적용합니다. 이때 TouchGFX Designer는 다음과 같은 작업을 수행합니다.

  1. 줄어든 새 touchgfx 폴더의 압축을 애플리케이션에 풀고 TouchGFX 경로를 여기에 맞게 수정합니다.
  2. 프로젝트가 계속 컴파일할 수 있도록 touchgfx 폴더에서 삭제된 파일을 모두 다운로드하여 압축을 해제합니다.

이 방법은 거의 모든 것을 그대로 유지하기 때문에 이전 파일 구조가 프로젝트에 적합한 경우에는 가장 무난하게 선택할 수 있는 방법입니다. 다만 이미지 변환 프로그램의 빠른 속도가 주는 이점(각 파일이 아닌 이미지 폴더에서 작업)을 이용하지 못하는 것이 가장 큰 단점입니다. 그렇지만 Makefile을 수정하면 이 방법도 사용할 수 있습니다.

방법 2: 새 템플릿으로 가져오기​

이 방법을 사용하면 프로젝트를 새로운 템플릿 기반 파일 구조로 전환할 수 있습니다. 이렇게 하려면 먼저 Designer에서 위의 방법 1을 사용해 프로젝트를 업그레이드해야 합니다. 그런 다음 해당하는 애플리케이션 템플릿(시뮬레이터 또는 평가 보드에 적합한 템플릿)을 사용해 새로운 프로젝트를 생성합니다. 새로 생성한 프로젝트를 Designer에서 열고 상단 메뉴에서 "Edit -> Import GUI"를 클릭합니다. 대화상자에서 프로젝트의 .touchgfx 파일을 지정합니다. 그러면 Designer가 애셋을 포함한 모든 UI 파일을 새로 생성된 프로젝트에 자동으로 가져옵니다. 만약에 gui 폴더 외부에서 다른 코드를 추가했다면 해당하는 파일들을 새 프로젝트에 직접 복사해야 합니다.

방법 3: Designer가 없는 수동 업그레이드​

Designer를 사용하지 않는 경우에도 다음과 같은 방법으로 업그레이드가 가능합니다.

  1. 프로젝트에서 사용하는 touchgfx 폴더를 4.9.0이 설치된 폴더로 교체합니다.
  2. 이 zip 파일을 다운로드하여 touchgfx 폴더로 압축을 푼 다음 삭제된 파일들을 복구합니다.