TouchGFX on NeoChrom/NeoChromVG
이 섹션에서는 NeoChrom GPU 그래픽 가속기가 포함된 하드웨어에서 TouchGFX를 사용하는 방법에 대해 설명합니다. 이 그래픽 가속기는 텍스처 매핑, 이미지 확대/축소 및 회전 같은 작업의 성능을 획기적으로 개선합니다. 이는 곧 높은 프레임 속도를 유지하면서 고급 UI를 구축할 수 있다는 것을 의미합니다.
NeoChrom 그래픽 가속기는 현재 STM32U5x9, STM32H7R7/S7, STM32N6 마이크로컨트롤러에서만 사용할 수 있습니다. 개발 보드는 모든 제품군에서 사용할 수 있습니다.
STM32U5A9 Discovery 보드
NeoChrom 가속기는 소스 코드와 STM32CubeMX에서 GPU2D라는 이름으로 알려져 있습니다.
NeoChrom 및 NeoChromVG
NeoChrom 가속기는 STM32U5G9을 도입하면서 추가 기능이 업데이트되었습니다. 개선된 가속기의 이름은 NeoChromVG입니다. 가속기에는 하드웨어 가속 벡터 그래픽을 사용할 수 있도록 확장 기능이 포함되어 있습니다.
| 마이크로컨트롤러 | 가속기 |
|---|---|
| STM32U599/A9 | NeoChrom |
| STM32U5F7/G7 | NeoChromVG |
| STM32U5F9/G9 | NeoChromVG |
| STM32H7R7/S7 | NeoChrom |
| STM32N6 | NeoChrom |
NeoChrom 그래픽 기능
NeoChrom 가속기는 기본 블리팅(이미지 그리기), 블렌딩, 스케일링, 회전 및 텍스처 매핑 기능을 수행할 수 있습니다. 이러한 모든 기능은 NeoChrom이 포함된 마이크로컨트롤러에서 실행될 때 TouchGFX에서 자동으로 사용됩니다.
DMA2D 그래픽 가속기에 비해 NeoChrom은 더 많은 그래픽 작업을 가속화할 수 있으며, 보다 풍부한 기능 세트를 갖추고 있습니다.
| 그래픽 기능 | DMA2D | GPU2D |
|---|---|---|
| 지원되는 형식(TouchGFX가 포함된 경우) | ARGB8888, RGB888, RGB565, A8, A4, L8 | ARGB8888, RGB888, RGB565, A8, A4, A2, A1 |
| 명령 목록 기반 | No | Yes |
| 그리기 | 직사각형 | 직사각형, 픽셀, 라인, 삼각형, MSAA(Multi-Sample Anti-Aliasing)가 있는 사변형 |
| 블리팅 | 복사, 알파 블렌딩, 픽셀 형식 변환 | 복사, 알파 블렌딩, 픽셀 형식 변환, 컬러 키잉 |
| 텍스처 매핑 | No | Yes |
| 벡터 그래픽 | No | No* |
* TouchGFX 사용 시 벡터 그래픽은 NeoChrom을 통해 부분적으로 하드웨어 가속됩니다. NeoChromVG를 사용하면 벡터 그래픽에 대한 완전한 하드웨어 가속을 사용할 수 있습니다.
NeoChrom에서는 이러한 기능들을 사용할 수 있기 때문에 더 많은 TouchGFX 위젯이 가속화됩니다.
| 위젯 | DMA2D | GPU2D |
|---|---|---|
| Box, BoxWithBorder | Yes | Yes |
| Image, AnimatedImage, TiledImage, SnapshotWidget | Yes | Yes |
| Button, ButtonWithIcon, ButtonWithLabel, ToggleButton | Yes | Yes |
| RadioButton, RepeatButton | Yes | Yes |
| PixelDataWidget | Yes | Yes |
| TextArea, TextAreaWithWildcard, Keyboard | Partly | Yes |
| ScalableImage | No | Yes |
| TextureMapper, AnimatedTextureMapper | No | Yes |
| Circle, Line, Graph, Gauge | No* | No* |
| SVG | No | No** |
* 픽셀을 프레임 버퍼에 그리고 블렌딩하는 작업은 DMA2D가 수행하지만 모양 계산 작업은 소프트웨어가 수행합니다.
** NeoChromVG에서는 하드웨어 가속 SVG를 사용할 수 있습니다.
하드웨어 가속화가 되지 않은 작업은 소프트웨어 렌더링이 됩니다(CPU 부하가 높아진다는 것은 성능이 저하된다는 것을 의미). 위의 표에서 볼 수 있듯이, NeoChrom은 ScalableImage 및 TextureMapper 같은 위젯을 가속화할 수 있습니다. 즉, 높은 성능을 유지하면서 위젯을 보다 활발하게 사용할 수 있습니다.
벡터 그래픽
새로운 NeoChromVG 가속기는 벡터 그래픽을 가속화할 수 있습니다. 이 기능은 TouchGFX로 SVG 이미지를 렌더링할 때 사용됩니다. GPU2D 그래픽 가속기에는 스텐실 버퍼라는 추가 버퍼가 필요합니다. 이 버퍼는 프레임 버퍼와 크기는 동일하지만, 픽셀당 1바이트만 가능합니다.
예를 들어 프레임 버퍼가 24bpp에서 480 x 480인 경우 스텐실 버퍼는 480 * 480 = 230,400바이트여야 합니다. 최상의 성능을 위해서는 고속 SRAM에 스텐실 버퍼를 할당하는 것이 중요합니다.
스텐실 버퍼는 TouchGFX Generator에서 할당됩니다. 이 가이드를 참조하십시오.
NeoChrom을 통한 렌더링 시간 단축.
다음 예는 DMA2D 및 소프트웨어 렌더링을 통해 NeoChrom이 제공하는 가속 기능을 보여줍니다. 우리는 TouchGFX Designer를 통해 두 개의 프로젝트를 만들었습니다. 첫 번째 프로젝트는 Box를 배경으로 이미지를 보여줍니다. 두 번째 프로젝트는 Box 배경에 TextureMapper Widget을 보여줍니다. 매 프레임마다 위젯은 다시 그려집니다. 두 경우 모두 비트맵이 크기가 128x128이고, ARGB8888 형식이며, 내부 플래시에 저장됩니다. 프레임버퍼는 RGB565 형식입니다.
Image 프로젝트
TextureMapper 프로젝트
두 프로젝트 모두 STM32F746 및 STM32U5A9 Discovery 보드에서 실행되었습니다.
우리는 GPIO를 로직 분석기에 연결해서 렌더링 시간을 측정했습니다.
Image 프로젝트를 실행 중인 STM32F746
위의 그림은 STM32F746에서 실행 중일 때의 프레임 속도와 렌더링 시간을 보여줍니다. 채널 00은 VSYNC 신호를 보여줍니다. 디스플레이가 59.2Hz의 프레임 속도에 해당하는 16.9ms의 프레임 간격(A1에서 A2로)으로 실행되는 것을 알 수 있습니다. 채널 01은 렌더링 시간을 보여줍니다(렌더링 시 높음, B1에서 B2까지). 따라서 이미지 렌더링에 소요되는 시간은 1.3ms입니다. STM32F746에서는 이미지 렌더링이 빠르게 수행됩니다.
TextureMapper 프로젝트를 실행 중인 STM32F746
위의 그림에는 STM32F746에서 실행 중인는 텍스처 매퍼 프로젝트가 나와 있습니다. TextureMapper의 렌더링 시간은 4.5ms입니다. TextureMapper 위젯의 속도는 이미지보다 훨씬 느립니다.
이미지 프로젝트를 실행 중인 STM32U5A9
다음은 이미지 프로젝트를 실행 중인 STM32U5A9 Discovery 키트입니다. STM32U5A9 Discovery 키트 디스플레이의 프레임 간격은 12.26ms이고, 이는 프레임 속도 81.6Hz에 해당합니다. 이미지의 렌더링 시간은 0.7ms입니다. 이미지 위젯이 STM32F746 키트보다 빠르다는 것을 알 수 있습니다
TextureMapper 프로젝트를 실행 중인 STM32U5A9
TextureMapper의 렌더링 시간은 1.7ms입니다. TextureMapper는 STM32F746보다는 STM32U5A9에서 더 속도가 빠릅니다.
렌더링 시간 요약
아래 표에는 렌더링 시간이 나와 있습니다.
| 요소 | STM32F746 | STM32U5A9 | 가속 |
|---|---|---|---|
| 주파수 | 200 MHz | 160 MHz | 0.8 |
| 이미지 | 1.3ms | 0.7ms | ~2x |
| TextureMapper | 4.5ms | 1.7ms | ~3x |
클록 주파수가 감소하더라도 STM32U5A9는 특히 TextureMapper에서 STM32F746보다 훨씬 뛰어난 성능을 보입니다.
내부 플래시의 이미지와 STM32F746용 외부 SDRAM의 프레임버퍼에 대해 이러한 측정이 수행됩니다. 프레임 버퍼는 STM32U5A9의 내부 SRAM에 있습니다(일반적인 시나리오이기 때문). STM32F746은 QSPI 플래시(4비트 버스)를 사용하기 때문에 이미지를 외부 플래시로 이동하는 것은 손해입니다. 반면에, STM32U5A9는 더 빠른 OSPI 플래시(8비트 버스)를 사용합니다.
STM32F746 디스커버리 키트는 내부 RAM에서 480x272 RGB565 프레임버퍼와 함께 실행될 수 있습니다. 이렇게 하면 성능이 향상되지만(이미지가 1.03ms까지 감소), 이것이 STM32F746의 표준 구성은 아닙니다. 내부 SRAM의 상당 부분을 프레임 버퍼에 사용하기 때문에 다른 애플리케이션 구성 요소에 사용할 RAM이 거의 남지 않습니다. 단일 프레임 버퍼로 실행하는 것도 모든 애플리케이션에 적합하지 않습니다.
보다 풍부한 사용자 인터페이스
개선된 렌더링 성능을 사용해 고급 애니메이션을 갖춘 사용자 인터페이스를 만들 수 있습니다. 예를 들어 확대/축소되거나 회전되는 요소가 더 많아집니다. STM32F746의 경우, 디스플레이 화면 갱신 시간은 16.8ms였습니다. 이는 애플리케이션이 60fps의 프레임 속도를 유지하기 위해서는 렌더링 시간을 이 시간 아래로 유지해야 한다는 것을 의미합니다. 따라서 화면에 해당 복잡도(16.8ms/4.48ms)의 텍스처 매퍼를 최대 3.75개 배치하거나 247 x 247 크기의 더 큰 텍스처 매퍼 하나(픽셀 수는 같고 렌더링 시간은 거의 같음)를 배치할 수 있습니다. 화면 주사률은 동일하지만 STM32U5A9 CPU를 사용한다고 가정하면 14.36개의 텍스처 매퍼(16.8ms/1.17ms) 또는 485 x 485 크기의 텍스처 매퍼 하나를 배치할 수 있습니다.
다음 그림은 각기 STM32F746 및 STM32U5A9에서 실행 중인 두 개의 애플리케이션을 보여줍니다. 가운데로 갈 때는 요소가 확대되고 가운데에서 나올 때는 요소가 축소되는 회전 컨베이어 스타일의 메뉴를 만들어봤습니다(여기서는 모든 요소에 대해 동일한 텍스처를 사용).
STM32F746(480x272픽셀 디스플레이, 왼쪽) 및 텍스처 매퍼 기반의 회전 컨베이어 프로젝트를 실행 중인 STM32U5A9(480x480 디스플레이, 오른쪽)
STM32F746은 3개의 아이콘, 1개의 큰 아이콘(배율 1.9로 확대), 2개의 작은 아이콘을 표시할 수 있습니다. STM32U5A9는 7개의 아이콘을 표시할 수 있습니다. 가장 큰 아이콘은 배율 2.7로 확대된 것입니다.
STM32F746에 3개의 아이콘을 가진 애플리케이션의 렌더링 시간은 14.38ms입니다. STM32U5A9에서 7개의 아이콘을 가진 애플리케이션의 렌더링 시간은 14.93ms입니다. 따라서 두 UI 모두 60fps에서 실행이 가능하며, STM32U5A9는 더 높은 해상도에서 훨씬 더 많은 콘텐츠를 표시합니다.
가속 벡터 그래픽
새로운 NeoChromVG 가속기는 벡터 그래픽을 가속화할 수 있습니다. 덕분에 벡터 기반 그래픽이 비트맵이 아닌 중심 역할을 하는 새로운 종류의 애플리케이션이 가능해졌습니다.
한 가지 예로 지도 애플리케이션이 있습니다. 지도는 비트맵에서 만들 수 있지만, 매우 큰 저장 공간이 필요하거나 특정 지도 섹션을 미리 다운로드해야 하는 경우가 많습니다.
아래 비디오는 STM32U5G9에서 실행 중인 데모 애플리케이션을 보여줍니다. 벡터 정의(서로 다른 색상으로 채워져 있고 외각선이 있는 여러 개의 다각형)에 따라 그려지는 지도를 확대/축소, 회전 및 패닝(panning) 할 수 있습니다. 비디오는 16bpp 색상의 800 x 480 디스플레이에서 전체 화면으로 실행됩니다.
무빙 맵을 보여주는 STM32U5G9
SVG
NeoChromVG 가속기는 SVG 이미지 그리기 성능을 대폭적으로 개선해 줍니다. TouchGFX는 가용한 하드웨어를 자동으로 활용합니다. 간단한 예제가 이러한 개선을 보여줍니다. 아래는 소프트웨어 렌더링을 사용하는 STM32F746, NeoChrom을 사용하는 STM32H7S, NeoChromVG를 사용하는 STM32U5G9로 그린 152x152픽셀 이미지입니다.
152 x 152픽셀 크기의 간단한 SVG 그리기입니다.
SVG 이미지의 렌더링 시간은 아래 테이블에 나와 있습니다.
| 마이크로컨트롤러 | 가속기 | 렌더링 시간 /ms |
|---|---|---|
| STM32F746 | Chrom-ART* | 4.12 |
| STM32U5G9 | NeoChromVG | 0.97 |
| STM32H7S8 | NeoChrom | 2.8 |
* Chrom-ART는 벡터 렌더링을 하드웨어 가속하지 않으므로 완전히 소프트웨어로 렌더링됩니다.
SVG에서 TouchGFX에서 SVG를 사용하는 것에 대한 자세한 내용을 읽어보십시오.
벡터 글꼴
NeoChrom과 NeoChromVG도 벡터 글꼴 그리기를 가속합니다. 벡터 글꼴 문서에서 벡터 글꼴을 사용하는 방법에 대해 알아볼 수 있습니다.
프로젝트 생성하기
CubeMX 및 TouchGFX Generator는 NeoChrom을 지원합니다. STM32CubeMX에서 가속기는 코드 이름 GPU2D로 알려져 있습니다. GPU2D 가속기는 STM32CubeMX의 TouchGFX 구성에서 GPU2D가 활성화된 경우에만 TouchGFX에서 사용할 수 있습니다. TouchGFX Designer와 함께 제공되는 TouchGFX TBS(템플릿 프로젝트)를 사용하는 경우에는 이미 활성화되어 있습니다. 자체적인 커스텀 프로젝트를 만드는 경우, 아래에서와 같이 GPU2D Accelerator를 활성화해야 합니다.
STM32CubeMX에서 GPU2D(NeoChrom GPU) 활성화
GPU2D를 활성화한 후 STM32CubeMX에서 "Generate Code"를 클릭하십시오. 이렇게 하면 대상 구성 코드가 재생성됩니다. 이제 TouchGFX Designer에서 해당 프로젝트를 열고, 거기에서도 코드를 생성합니다(F4).
TouchGFX Designer는 대상 구성과 일치하는 애셋(이미지, 글꼴 및 텍스트) 및 시뮬레이터 코드를 생성합니다. 이것으로 코드를 컴파일할 준비를 마쳤습니다.
TouchGFX Designer에서 프로젝트를 시작하는 경우, 일부 하드웨어 설정을 변경해야 하는 경우가 아니라면 STM32CubeMX를 열 필요가 없습니다.
프레임버퍼 형식
STM32U5A9, STM32U5G9, STM32H7S8, STM32N657 디스커버리 보드는 RGB565, RGB888, ARGB8888 등 3가지의 프레임 버퍼 형식을 지원합니다. 이는 CubeMX에서 구성할 수 있습니다.
| 마이크로컨트롤러 | RGB565(16bpp) | RGB888(24bpp) | ARGB8888(32bpp) |
|---|---|---|---|
| STM32U5x7/x9 | 네이티브로 | 네이티브로 | 네이티브로 |
| STM32H7R7/S7 | 네이티브로 | GFXMMU* 사용 | 네이티브로 |
| STM32N6 | 네이티브로 | 지원되지 않음* | 네이티브로 |
- 이러한 제한 사항은 다음 장에서 설명합니다.
RGB888 프레임 버퍼(24bpp) 사용 시 STM32H7S8 및 STM32N657 제한 사항
STM32H7R7/S7 및 STM32N657의 NeoChrom GPU로 연결되는 내부 버스는 24bpp를 지원하지 않습니다. 현재 STM32N6에 대한 해결 방법은 없으나, STM32H7R7/S7의 경우 GFXMMU를 사용하여 24bpp 프레임 버퍼를 구현할 수 있습니다. 이 시나리오에서는 GFXMMU를 사용하여 32bpp 렌더링을 24bpp 프레임 버퍼로 변환합니다. 이는 TouchGFX가 32bpp 프레임 버퍼인 것처럼 실행된다는 뜻이며 그러고 나면 GFXMMU가 픽셀 데이터를 24bpp 프레임 버퍼에 쓸 때 이를 전환합니다. 이 설정의 예제를 보려면 TouchGFX Designer에서 이 STM32H7S78_24bpp TBS를 다운로드할 수 있습니다. 이는 24bpp 프레임 버퍼를 활성화하는 데 GFXMMU 설정을 사용합니다. 이 설정을 사용할 경우 RGB888 형식으로 불투명한 이미지 애셋을 사용할 수 없다는 점에 유의하십시오. 대신 ARGB8888을 불투명 이미지 형식으로 선택해야 합니다. 이를 통해 24bpp 프레임 버퍼의 전체 색 심도를 활용할 수 있습니다.
STM32H7R7/S7에서 24bpp 프레임 버퍼 활성화 단계별 가이드
이 가이드는 STM32H7R7/S7 프로젝트를 24bpp 프레임 버퍼를 사용하도록 변환하는 방법에 대한 단계별 지침을 제공합니다. NeoChrom/NeoChromeVG가 탑재된 마이크로컨트롤러에서 실행되는 TouchGFX 애플리케이션에서 이러한 이미지 형식을 사용할 경우, 해당 이미지는 DMA2D를 사용해 그려집니다. 32bpp 프레임 버퍼를 사용하는 프로젝트에서 단계를 따를 경우, 6단계를 생략할 수 있습니다.
- STM32CubeMX를 열고 애플리케이션 컨텍스트에 대해 GFXMMU를 활성화하십시오. GFXMMU는 멀티미디어 탭 아래에서 찾을 수 있습니다.
- 두 개의 패킹 버퍼를 활성화하고, 둘 모두에 대해 패킹 모드로 GFXMMU_PACKING_MSB_REMOVE를 선택하십시오. 프레임 버퍼 하나당 하나의 버퍼가 필요하므로, 단일 프레임 버퍼 설정에서는 하나의 버퍼만 필요합니다.
참고: 에뮬레이션 프레임 버퍼를 사용하는 경우, 첫 번째 버퍼는 이를 위해 예약됩니다. 따라서 에뮬레이션 프레임 버퍼를 동시에 사용하는 경우, 32bpp에서 24bpp로의 변환에 첫 번째 버퍼를 사용할 수 없습니다. - 위에서 활성화된 버퍼의 물리적 주소를 설정하십시오. 물리적 주소는 24bpp 프레임 버퍼가 RAM에 배치되는 위치를 의미합니다.
- 기본 알파 값을 0xFF로 설정합니다.
- LTDC 구성에서 레이어 설정을 엽니다. 이는 멀티미디어 탭 아래에서도 찾을 수 있습니다.
- Layer 0 - Pixel Format을 ARGB8888로 설정합니다.
- Layer 0 - Color Frame Buffer Start Address를 GFXMMU 가상 버퍼 중 하나로 설정합니다.
24bpp 프레임 버퍼를 사용하는 STM32H7S78-DK용 GFXMMU 및 LTDC 구성 예제
- 미들웨어 및 소프트웨어 팩 아래에 있는 X-CUBE-TOUCHGFX를 엽니다.
- 버퍼 위치를 주소별로 설정하고 시작 주소에 GFXMMU_VIRTUAL_BUFFERx_BASE를 기록합니다. 'x'를 2단계에서 선택한 패킹 버퍼의 수로 대체합니다.
- STM32CubeMX에서 코드를 생성합니다.
- main.c의 MX_LTDC_Init 함수에 다음 코드를 추가하여 LTDC의 이미지 형식 설정을 재정의합니다.
/* USER CODE BEGIN LTDC_Init 2 */
// Reconfigure pixelformat since TouchGFX project generator does not allow setting different format for LTDC and
// remaining configuration. This way TouchGFX runs 32BPP mode but the LTDC accesses the real framebuffer in 24BPP
pLayerCfg.PixelFormat = LTDC_PIXEL_FORMAT_RGB888;
if (HAL_LTDC_ConfigLayer(&hltdc, &pLayerCfg, 0) != HAL_OK)
{
Error_Handler();
}
/* USER CODE END LTDC_Init 2 */ - 프로젝트 디렉토리의 TouchGFX/target 아래에 있는 TouchGFXHAL.cpp를 엽니다.
- MCU용 HAL 파일이 아직 존재하지 않는 경우 해당 포함을 추가합니다. STM32H7R7/S7의 경우 다음과 같습니다.
#include "stm32h7rsxx_hal.h" - 다음 줄을 추가하여 GFXMMU 핸들을 사용할 수 있게 합니다.
extern GFXMMU_HandleTypeDef hgfxmmu; - 가상 프레임 버퍼에 대한 포인터를 선언합니다. 예제:
static uint16_t* tft = 0; - TouchGFX 프레임워크는 GFXMMU를 통해 가상 주소를 사용하므로, TFT LTDC 컨트롤러에는 실제 프레임 버퍼 주소가 전달되도록 TouchGFXHAL::setTFTFrameBuffer의 구현을 변경합니다. 사용된 패킹 버퍼가 버퍼 0과 1이라고 가정할 때, 구현은 다음과 같아야 합니다.
void TouchGFXHAL::setTFTFrameBuffer(uint16_t* address)
{
tft = address;
if (tft == (uint16_t*)GFXMMU_VIRTUAL_BUFFER0_BASE)
{
TouchGFXGeneratedHAL::setTFTFrameBuffer((uint16_t*)hgfxmmu.Init.Buffers.Buf0Address);
}
else
{
TouchGFXGeneratedHAL::setTFTFrameBuffer((uint16_t*)hgfxmmu.Init.Buffers.Buf1Address);
}
} - TouchGFXHAL::getTFTFrameBuffer()의 구현을 다음과 같이 변경하십시오.
uint16_t* TouchGFXHAL::getTFTFrameBuffer() const
{
return tft;
} - TouchGFX Designer에서 프로젝트를 엽니다.
- Config -> Default Image Configuration으로 이동한 다음, Opaque Image Format으로 ARGB8888을 선택합니다.
- TouchGFX Designer에서 코드를 생성합니다.
프로젝트는 이제 24bpp 프레임 버퍼로 실행되지만, TouchGFX는 여전히 32bpp로 렌더링됩니다. 결과적으로 성능은 16bpp와 네이티브 24bpp에 비해 자연스럽게 저하될 것입니다. 그러나 STM32H7R7/S7에서는 네이티브 24bpp가 지원되지 않으므로, 24bpp가 필요한 경우 이 방법이 최선의 해결책입니다.
외부 RAM에 프레임버퍼가 있는 경우 STM32U5 제한 사항
STM32U5 MCU 제품군의 NeoChrom 가속기는 외부 메모리에 쓸 때 높은 효율성을 달성하기 위해 전용 쓰기 버퍼를 통합하지 않습니다. 그 결과, NeoChrom 가속기는 외부 메모리가 연결된 버스에 수많은 "작은" 쓰기를 수행합니다. 이로 인해 동일한 버스의 픽셀을 읽는 디스플레이 컨트롤러에서 버스 경합 문제가 발생할 수 있습니다. 따라서 STM32U5에서 NeoChrom 가속기를 사용할 경우에는 프레임 버퍼를 내부 RAM에만 두는 것이 좋습니다. 프레임 버퍼를 외부 RAM에 두어야 할 경우에는 NeoChrom 가속기를 사용하지 않는 것이 좋습니다. Chrom-ART 가속기는 계속해서 사용할 수 있습니다.
Texture Cache
The STM32U5 MCU family with the NeoChrom accelerator uses a second data cache (DCACHE2) to optimize the access to texture in external RAM. This cache can also cache the internal SRAM. This is the default behavior for the second data cache.
There is generally no big benefit of caching the SRAM (it is already fast) and it is better to reserve the cache for the slower external memories (OSPI flash). Caching also requires cache maintenance operations (cache invalidation) to be performed when the CPU writes to the cached areas of SRAM.
For these reasons TouchGFX assumes that caching of SRAM is disabled for the second cache.
Since version 6.11 CubeMX generates these lines:
static void MX_DCACHE2_Init(void)
{
hdcache2.Instance = DCACHE2;
hdcache2.Init.ReadBurstType = DCACHE_READ_BURST_INCR;
if (HAL_DCACHE_Init(&hdcache2) != HAL_OK)
{
Error_Handler();
}
__HAL_RCC_SYSCFG_CLK_ENABLE();
HAL_SYSCFG_DisableSRAMCached();
}
Make sure you have the two last lines, if you do not use CubeMX.
NeoChrom의 한계
NeoChrom 및 NeoChromVG 그래픽 가속기는 TouchGFX에서 L8 이미지 형식(L8_RGB565, L8_RGB888, L8_ARGB8888)을 지원하지 않습니다. NeoChrom/NeoChromVG가 탑재된 마이크로컨트롤러에서 실행되는 TouchGFX 애플리케이션에서 이러한 이미지 형식을 사용할 경우, 해당 이미지는 DMA2D를 사용해 그려집니다. ScalableImage 또는 TextureMapper와 함께 이러한 형식을 사용하는 경우 소프트웨어 폴백이 사용됩니다.
따라서 NeoChrom/NeoChromVG 가속기에서는 L8 이미지와 마이크로컨트롤러를 함께 사용하지 않는 것이 좋습니다.
NeoChrom 그래픽 가속기는 NeoChromVG와 비교했을 때 'Non-zero fill-rule'로 그린 그래픽 요소에서 최적화되지 않은 안티 앨리어싱을 생성합니다. 이는 채우기 규칙을 "nonzero"로 지정할 수 있는 SVG 파일에서 발생할 수 있습니다. 이를 피하는 한 가지 방법은 "evenodd" 채우기 규칙을 사용하는 것이지만 모든 그리기에서 유효한 것은 아닙니다.