メイン･コンテンツまでスキップ

NeoChrom / NeoChromVG上でのTouchGFXの使用

This section discusses how to use TouchGFX on hardware having the NeoChrom GPU graphics accelerator. このグラフィック･アクセラレータは、テクスチャ･マッピング、画像のスケーリングや回転などの操作性能を著しく向上します。 これはつまり、高いフレームレートを維持しながら、より高度なUIを構築できるということです。

The NeoChrom graphics accelerator is currently available in STM32U5x7, STM32U5x9, STM32H7R7/S7 and STM32N6 microcontrollers. 開発ボードはすべてのファミリに用意されています。

STM32U5A9 Discoveryボード

The NeoChrom accelerator is known by the name GPU2D in source code and in STM32CubeMX.

NeoChromとNeoChromVG​

STM32U5G9の導入により、NeoChromアクセラレータが更新され、機能が追加されました。 この機能が向上したアクセラレータは、NeoChromVGといいます。 また、このアクセラレータには、ハードウェア･アクセラレーションによるベクタ･グラフィックスを可能にする拡張機能が搭載されています。

マイクロコントローラアクセラレータ
STM32U599/A9NeoChrom
STM32U5F7/G7NeoChromVG
STM32U5F9/G9NeoChromVG
STM32H7R7/S7NeoChrom
STM32N6NeoChrom

NeoChromのグラフィック機能​

NeoChromアクセラレータは、基本のビットマップ転送（画像描画）、ブレンディング、スケーリング、回転、およびテクスチャ･マッピングを実行できます。 このような操作はすべて、NeoChromを内蔵したマイクロコントローラ上で実行されるTouchGFXによって自動的に利用されます。

DMA2Dグラフィック･アクセラレータと比べ、NeoChromはより多くのグラフィック処理を高速化できるだけでなく、より豊富な機能セットも組み込まれています。

グラフィック機能DMA2DGPU2D
サポート対象フォーマット（TouchGFX使用時）ARGB8888、RGB888、RGB565、A8、A4、L8ARGB8888、RGB888、RGB565、A8、A4、A2、A1
コマンドリスト･ベースNoYes
描画長方形マルチサンプリング･アンチエイリアシング（MSAA）を使用した長方形、ピクセル、ライン、三角形、四辺形
ビットマップ転送コピー、アルファブレンディング、ピクセル･フォーマット変換コピー、アルファブレンディング、ピクセル･フォーマット変換、カラー･キーイング
テクスチャ･マッピングNoYes
ベクタ･グラフィックスNoNo*

* Vector Graphics are partially hardware-accelerated with NeoChrom when using TouchGFX. Full hardware acceleration for Vector Graphics is available with NeoChromVG.

利用可能なこれらの機能により、さらに多くのTouchGFXウィジェットがNeoChromによって高速化されます。

ウィジェットDMA2DGPU2D
Box、BoxWithBorderYesYes
Image、AnimatedImage、TiledImage、SnapshotWidgetYesYes
Button、ButtonWithIcon、ButtonWithLabel、ToggleButtonYesYes
RadioButton、RepeatButtonYesYes
PixelDataWidgetYesYes
TextArea、TextAreaWithWildcard、Keyboard一部Yes
ScalableImageNoYes
TextureMapper、AnimatedTextureMapperNoYes
Circle、Line、Graph、GaugeNo*No*
SVGNoNo**

* The drawing/blending of pixels to the framebuffer is done by DMA2D, but the shape calculations are done in software.
** Hardware accelerated SVG is available with NeoChromVG.

ハードウェアで高速化される以外の操作は、ソフトウェアで描画されます（CPU負荷が増加し、性能が低下します）。 上記のテーブルが示すように、NeoChromはScalableImageやTextureMapperなどのウィジェットを高速化できます。 つまり、高い性能を維持しながら、これらのウィジェットをより一層使用できるようになります。

ベクタ･グラフィックス​

この新しいNeoChromVGアクセラレータは、ベクタ･グラフィックスを高速化できます。 この機能は、TouchGFXでSVG画像を描画するときに使用されます。 GPU2Dグラフィックス･アクセラレータには、ステンシル･バッファと呼ばれる追加のバッファが必要です。 このバッファは、フレームバッファと同じサイズですが、ピクセル当たり1バイトだけです。

たとえば、フレームバッファが24bppで480 x 480の場合、ステンシル･バッファは480 x 480 = 230,400バイトである必要があります。 最適な性能を得るため、このステンシル･バッファを高速SRAMに割り当てることが重要です。

ステンシル･バッファはTouchGFX Generatorによって割り当てられます。 こちらのガイドを参照してください。

NeoChromによる描画時間の改善​

次の例では、DMA2Dやソフトウェアによる描画と比較してNeoChromがもたらす高速化について説明します。 Designerを使用して、2つのプロジェクトを作成しました。 最初のプロジェクトは、ボックスのバックグラウンド上に画像を表示します。 2つ目のプロジェクトは、ボックスのバックグラウンド上にTextureMapperウィジェットを表示します。 このウィジェットはすべてのフレームで再描画されます。 どちらの場合でも、ビットマップは128x128のサイズ、ARGB8888フォーマットで、内部Flashに格納されます。 フレームバッファは、RGB565フォーマットです。

Imageプロジェクト

TextureMapperプロジェクト

両方のプロジェクトをSTM32F746およびSTM32U5A9 Discoveryボードで実行しました。

GPIOをロジック･アナライザに接続して、描画時間を測定しました。

STM32F746でImageプロジェクトを実行

上図は、STM32F746で実行されているときの、フレームレートと描画時間を示しています。 チャネル00は、VSYNC信号を示しています。 59.2 Hzのフレームレートに対応した、16.9 msのフレーム間隔（A1～A2）で表示されていることがわかります。 チャネル01は描画時間を示しており、描画時（B1～B2）は高くなります。 したがって、画像の描画時間は1.3 msです。 STM32F746では画像描画は高速で実行されます。

STM32F746でTextureMapperプロジェクトを実行

上図は、STM32F746で実行中のTextureMapperプロジェクトです。 TextureMapperの描画時間は4.5 msです。 TextureMapperウィジェットは、Imageの場合よりも大幅に時間がかかります。

STM32U5A9でImageプロジェクトを実行

ここでは、STM32U5A9 DiscoveryキットがImageプロジェクトを実行しています。 STM32U5A9 Discoveryキットのディスプレイは、81.6 Hzのフレームレートに対応した12.26 msのディスプレイ･フレーム間隔で表示されています。 画像の描画時間は0.7 msです。 STM32F746キットの場合よりも、Imageウィジェットが高速であることがわかります。

STM32U5A9でTextureMapperプロジェクトを実行

TextureMapperの描画時間は1.7 msです。 TextureMapperも、STM32F746よりもSTM32U5A9上で実行する方が高速になります。

描画時間のまとめ​

次の表に、描画時間を示します。

要素STM32F746STM32U5A9速度向上
周波数200 MHz160 MHz0.8
Image1.3 ms0.7 ms~2x
TextureMapper4.5 ms1.7 ms~3x

クロック周波数が低くとも、STM32U5A9は、特にTextureMapperの場合に、STM32F746と比べてはるかに優れた性能を発揮します。

これらの測定は、内部Flash内の画像と、STM32F746の場合は外部SDRAMのフレームバッファを使用して行われます。 STM32U5A9の場合、フレームバッファは内部SRAMにあります（これが通常のシナリオです）。 画像を外部Flashに移動するとき、STM32F746はQSPI Flash（4bitバス）を使用しているため遅くなります。一方、STM32U5A9はそれよりも高速のOSPI Flash（8bitバス）を使用しています。

STM32F746 Discoveryキットは、内部RAMで480x272 RGB565フレームバッファを使用して実行できます。 これにより性能は向上しますが（Imageは1.03 msまで短縮）、これはSTM32F746の標準設定ではありません。内部SRAMの大半がフレームバッファ用に使用されるため、他のアプリケーション･コンポーネントに使用できるRAMはほとんど残らないからです。 単一フレームバッファでの実行もまた、すべてのアプリケーションに適しているわけではありません。

より豊富なユーザ･インタフェース​

描画パフォーマンスの向上により、より高度なアニメーションを組み込んだユーザ･インタフェースを作成できます。 たとえば、スケーリングや回転が多用されたエレメントなどです。 STM32F746の場合、ディスプレイのリフレッシュ時間は16.8 msでした。 つまり、アプリケーションは、60 fpsのフレームレートを維持するために、描画時間をこの値より低く保持する必要があります。 したがって、画面上では、その複雑さの場合、最大3.75個（16.8 ms / 4.48 ms）のテクスチャ･マッパーが使用可能です。または、サイズが247 x 247の単一の大型のテクスチャ･マッパー（ピクセル数が同じで、描画時間もほぼ同じ）が可能です。 同じ画面リフレッシュレートでSTM32U5A9 CPUを使用すると仮定すると、14.36個（16.8 ms / 1.17 ms）のテクスチャ･マッパー、またはサイズが485 x 485の単一のテクスチャ･マッパーを使用できます。

次の図は、それぞれSTM32F746およびSTM32U5A9で実行される2つのアプリケーションを示しています。 ここでは、中央に近づくにつれて要素が拡大され、遠ざかると縮小される、カルーセルのようなメニューを作成することを意図しています（ここでは、すべての要素に対して同じテクスチャを使用しています）。

480x272ピクセルのディスプレイのSTM32F746（左）と480x480ディスプレイでテクスチャ･マッパー･ベースのカルーセル･プロジェクトを実行するSTM32U5A9（右）

STM32F746は、3つのアイコン、つまり、係数1.9で拡大された大きいアイコン1つと、2つの小さいアイコンを表示できます。 STM32U5A9は、7つのアイコンを表示できます。 最大のアイコンは、係数2.7で拡大されています。

STM32F746で、3つのアイコンを持つアプリケーションの描画時間は14.38 msです。 STM32U5A9で、7つのアイコンを持つアプリケーションの描画時間は14.93 msです。 よって、どちらのUIも60 fpsで動作できますが、STM32U5A9はより高い解像度ではるかに多くのコンテンツを表示できます。

アクセラレータ･ベクタ･グラフィックス​

この新しいNeoChromVGアクセラレータは、ベクタ･グラフィックスを高速化できます。 これにより、アプリケーションの新しいクラスの可能性が開かれ、ビットマップではなく、ベクタ･ベースのグラフィックスが中心的な役割を担うことになります。

その一例がマップ･アプリケーションです。 マップはビットマップから作成できますが、非常に大きなストレージや特定のマップ･セクションの事前ダウンロードが必要な場合がよくあります。

次のビデオは、STM32U5G9で実行されるアプリケーションのデモです。 このアプリケーションでは、ベクタ定義（さまざまな色で塗りつぶされ、ストロークされた複数のポリゴン）から描画されたマップをズーム、回転、パンしています。 このビデオは色深度が16bppの800 x 480ディスプレイの全画面で実行されています。

STM32U5G9でムービング･マップを表示。

SVG​

NeoChromVGアクセラレータは、SVG画像の描画パフォーマンスを大幅に向上します。 TouchGFXは、利用可能なハードウェアを自動的に活用します。 パフォーマンスの向上がわかる簡単な例を次に示します。 ここでは、サイズ152x152ピクセルのSVG画像を、ソフトウェア･レンダリングを使用したST32F746、NeoChromを搭載したSTM32H7S、およびNeoChromVGを搭載したSTM32U5G9で描画します。

サイズが152 x 152ピクセルの簡単なSVG画像描画

次の表に、SVG画像の描画時間を示します。

マイクロコントローラアクセラレータ描画時間（ms）
STM32F746Chrom-ART*4.12
STM32U5G9NeoChromVG0.97
STM32H7S8NeoChrom2.8

* Chrom-ART does not hardware accelerate vector rendering, so it is rendered entirely in software.

TouchGFXでのSVGの使用については、「SVG」を参照してください。

ベクタ･フォント​

NeoChromおよびNeoChromVGもベクタ･フォントの描画を加速します。 ベクタ･フォントを使用する方法については、記事「ベクタ･フォント」を参照してください。

プロジェクトの作成​

CubeMXとTouchGFX Generatorは、NeoChromに対応しています。 In STM32CubeMX the accelerator is known by its code name GPU2D. The GPU2D accelerator is only available to TouchGFX if GPU2D is enabled in the TouchGFX configuration in STM32CubeMX. TouchGFX Designerに付属のTouchGFX TBS（テンプレート･プロジェクト）のいずれかを使用する場合は、これはすでに有効になっています。 独自のカスタム･プロジェクトを作成する場合は、以下に示すように、GPU2Dアクセラレータを必ず有効にしてください。

Enabling GPU2D (NeoChrom GPU) in STM32CubeMX

After enabling GPU2D press "Generate Code" in STM32CubeMX. これにより、対象の設定コードが再生成されます。 TouchGFX Designerでプロジェクトを開き、そこでもコードを生成します（F4）。

TouchGFX Designer generates assets (images, fonts, and texts) and simulator code, that matches the target configuration. これで、コードをコンパイルする準備ができました。

If you are starting a project from TouchGFX Designer there is no need to open STM32CubeMX unless you need to change some hardware settings.

フレームバッファのフォーマット​

The NeoChrom GPU does not natively support all color formats on all MCUs. The supported frambuffer formats can be seen in the table below:

マイクロコントローラRGB565 (16 bpp)RGB888 (24 bpp)ARGB8888 (32 bpp)
STM32U5x7/x9NativelyNativelyNatively
STM32H7R7/S7NativelyUsing GFXMMU*Natively
STM32N6NativelyNot supported*Natively

* These limitations are described in the following chapter.

STM32H7R7/S7 and STM32N6 limitations when using RGB888 framebuffer (24 bpp)​

The internal bus to the NeoChrom GPU in STM32H7R7/S7 and STM32N657 does not support 24 bpp. At the moment there is no workaround for STM32N6, but for STM32H7R7/S7 it is possible to use the GFXMMU to achieve 24 bpp framebuffers. In this scenario, the GFXMMU is used to convert 32 bpp rendering to 24 bpp framebuffers. This means that TouchGFX runs as if it was a 32 bpp framebuffer and then the GFXMMU converts the pixel data when writing it to the 24 bpp framebuffer. To see an example of this setup, you can download the STM32H7S78_24bpp TBS from TouchGFX Designer, which uses the GFXMMU setup to enable 24 bpp framebuffer. Be aware that when using this setup it is not possible to have opaque image assets in RGB888. Instead you must select ARGB8888 as your opaque image format to utilize the full color depth of your 24 bpp framebuffer.

Step-by-step guide to enable 24 bpp framebuffers on STM32H7R7/S7​

This guide provides step-by-step instructions on how to convert a project for STM32H7R7/S7 to use 24 bpp framebuffers. It assumes that the steps are implemented on an already working project with 16 bpp framebuffers. If the steps are followed on a project with 32 bpp framebuffers, step 6 can be skipped.

  1. Open STM32CubeMX and activate the GFXMMU for the Application context. The GFXMMU is found under the Multimedia tab.
  2. Enable two packing buffers and select GFXMMU_PACKING_MSB_REMOVE as the packing mode for both. One buffer is needed per framebuffer, so for a single framebuffer setup, only one buffer is needed.
    Note: If you use emulated framebuffer, the first buffer is reserved for this. Therefore, you cannot use the first buffer for the 32 bpp to 24 bpp conversion if you are also using emulated framebuffer.
  3. Set the physical addresses of the buffers enabled above. The physical address is where the 24 bpp framebuffer is placed in RAM.
  4. Set default alpha to 0xFF.
  5. Open Layer Settings in the LTDC configuration, which is also found under the Multimedia tab.
  6. Set Layer 0 - Pixel Format to ARGB8888.
  7. Set Layer 0 - Color Frame Buffer Start Address to one of the GFXMMU virtual buffers.

    Example of GFXMMU and LTDC configuration for STM32H7S78-DK with 24 bpp framebuffers

  8. Open X-CUBE-TOUCHGFX, which is found under Middleware and Software Packs.
  9. Set Buffer Location to By Address and write GFXMMU_VIRTUAL_BUFFERx_BASE in the start addresses. Replace 'x' with the numbers of the packing buffers selected in step 2.
  10. Generate code in STM32CubeMX.
  11. Add the following code to the MX_LTDC_Init function in main.c to override the image format setting for the 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 */
  12. Open TouchGFXHAL.cpp, which is found in the project directory under TouchGFX/target.
  13. Add include of HAL file for the MCU if not already present. For STM32H7R7/S7 that would be:
    #include "stm32h7rsxx_hal.h"
  14. Make the handle for the GFXMMU available by adding the line:
    extern GFXMMU_HandleTypeDef hgfxmmu;
  15. Declare a pointer to the virtual framebuffer. For example:
    static uint16_t* tft = 0;
  16. Change the implementation of TouchGFXHAL::setTFTFrameBuffer to give the true framebuffer address to the TFT LTDC controller while TouchGFX framework uses the virtual address through the GFXMMU. Assuming the packing buffers used are buffer 0 and 1, the implementation should be like this:
    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);
        }
    }
  17. Change the implementation of TouchGFXHAL::getTFTFrameBuffer() to
    uint16_t* TouchGFXHAL::getTFTFrameBuffer() const
    {
        return tft;
    }
  18. Open the project in TouchGFX Designer.
  19. Go to Config -> Default Image Configuration and select ARGB8888 as the Opaque Image Format.
  20. Generate code in TouchGFX Designer.

The project will now run with 24 bpp framebuffers, but TouchGFX will still render in 32 bpp. As a result, the performance will naturally be worse compared to 16 bpp and native 24 bpp. However, since native 24 bpp is not an option on STM32H7R7/S7, this is the best available solution when 24 bpp is required.

フレームバッファが外部RAMにある場合のSTM32U5の制約​

The NeoChrom accelerator on the STM32U5 MCU family does not integrate dedicated write buffers to enable high efficiency when writing to external memories. As a consequence, the NeoChrom accelerator does a lot of "small" writes to the bus where the external memory is connected. This can lead to bus contention issues with the diplay controller which reads pixels on the same bus. Therefore, it is recommended to only have framebuffers in internal RAM when using the NeoChrom accelerator on STM32U5. If framebuffer must be in external RAM, it is recommended to not use the NeoChrom accelerator. The Chrom-ART accelerator can still be used.

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の制約​

The NeoChrom and NeoChromVG graphics accelerators does not support the L8 image formats (L8_RGB565, L8_RGB888, L8_ARGB8888) with TouchGFX. If you use these image formats in a TouchGFX application running on either of the micro controllers with NeoChrom/NeoChromVG the images will be drawn using DMA2D. If you use these formats with ScalableImage or TextureMapper a software fall-back will be used.

したがって、NeoChrom/NeoChromVGアクセラレータを搭載したマイクロコントローラでは、L8画像を使用しないことを推奨します。

The NeoChrom graphics accelerator creates suboptimal anti-aliasing on graphics elements drawn with the "Non-zero fill-rule" compared to NeoChromVG. これは、フィル･ルールを「nonzero」として指定できるSVGファイルで発生する可能性があります。 回避策は、「evenodd」フィル･ルールを使用することですが、すべての描画に有効なわけではありません。