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

Generatorユーザ・ガイド

X-CUBE-TOUCHGFXの一部であるTouchGFX Generatorは、STM32CubeMXの追加ソフトウェア・コンポーネントで、開発者が自前のハードウェア・プラットフォーム上でTouchGFXを実行するための設定を行うのを支援するものです。 既存のSTM32CubeMXの設定とユーザ入力に基づいて、TouchGFX Generatorは機能するTouchGFXアプリケーションの設定に必要なファイルを生成します。 ここには、TouchGFX HAL、TouchGFX OSAL、およびTouchGFXの設定ファイルが含まれています。

STM32CubeMXを介してコードを生成すると、TouchGFX DesignerからTouchGFXプロジェクトを開けるようになり、ここでUIを開発できます。 TouchGFX Designerは、追加生成されたコードのファイルを、STM32CubeMXでプロジェクト用に設定されたターゲットのIDEプロジェクトに自動的に追加します。

TouchGFX Generatorの有効化

ユーザは、X-CUBEから[Select Components]ボタンを押すことで、追加機能にアクセスできます。

STM32CubeMXで[Additional Software]を選択

次の図は、プロジェクトに対してTouchGFX Generatorを有効化する方法を示しています。

TouchGFX Generatorの有効化

デュアル・コアのマイクロコントローラに対してTouchGFXを有効化する場合には、正しいコンテキストで有効化するようにしてください。 TouchGFXは単一コンテキストでのみ有効化できます。

デュアル・コアに対するTouchGFX Generatorの有効化

生成されるコードのアーキテクチャ

TouchGFX Generatorの機能の説明の前に、生成されるコードのアーキテクチャと、開発者がそれを使用して設定や動作をカスタマイズする方法について理解することが重要です。

STM32CubeMXで生成するファイル内のユーザ記述のコードは、STM32CubeMX(Cコード)で生成されるコード全体に明示的に配置されたUser Code・セクションを使用することで保護されます。 TouchGFX Generator(C++コード)で生成されるコードでは、この柔軟性が保持されています。

[Additional Software]でTouchGFX Generatorを追加し、有効化すると、STM32CubeMXは常にそのプロジェクトにTouchGFXフォルダを作成します。 このフォルダには設定に関わらず常に同じファイルが含まれますが、ファイルの内容はSTM32CubeMXおよびユーザ設定に応じて変わります。

次のリストは、TouchGFX Generatorが有効化されたSTM32CubeMXプロジェクトの内容の概要を示しており、特にTouchGFX関連ファイルが強調されています。 リストの後の表は、最も重要なエントリの役割を概説しています。

TouchGFX フォルダ
│   .mxproject
│ myproject.ioc
├───Core
├───Drivers
├───EWARM
├───Middlewares
└───TouchGFX
│ ApplicationTemplate.touchgfx.part
├───App
│ app_touchgfx.c
│ app_touchgfx.h
└───target
│ STM32TouchController.cpp
│ STM32TouchController.hpp
│ TouchGFXGPIO.cpp
│ TouchGFXHAL.cpp
│ TouchGFXHAL.hpp

└───generated
OSWrappers.cpp
TouchGFXConfiguration.cpp
TouchGFXGeneratedHAL.cpp
TouchGFXGeneratedHAL.hpp
フォルダ役割
myproject.iocSTM32CubeMXプロジェクト・ファイル
Coremain.c と起動コード
DriversCMSISとマイクロコントローラ・ファミリのドライバ
EWARMIDEプロジェクト・フォルダ。 EWARM、MDK-ARM、STM32CubeIDEのいずれか
MiddlewaresTouchGFXライブラリ / ヘッダファイルと、サードパーティ・ソフトウェア(FreeRTOSなど)が含まれます。
ApplicationTemplate.touchgfx.part.partファイルはSTM32CubeMXによって、TouchGFX Designerプロジェクトに関連する情報(画面の寸法やビット深度など)で更新されます。
AppX-CUBEのSTM32CubeMXに対するインタフェース。 app_touchgfx.c には、関数MX_TouchGFX_Process(void)および MX_TouchGFX_Init(void) の定義が含まれます。これらの関数はTouchGFXを初期化してメイン・ループを開始するために使用されます。
target/generatedこのサブフォルダには、設定変更時にSTM32CubeMXによって上書きされる読出し専用ファイルが含まれます。 TouchGFXGeneratedHAL.cppはTouchGFXクラスHALのサブクラスで、STM32CubeMXが現在の設定に基づいて生成することのできるコードが含まれます。 OSWrappers.cppOSAL)にはTouchGFXエンジンとの同期に必要な関数が含まれます。最後にTouchGFXConfiguration.cpp には、TouchGFXの構築および設定のためのコードが含まれます(HALを含む)。
targetHALの動作を拡張したりSTM32CubeMXによって生成された設定をオーバーライドしたりするためにユーザが変更できるファイルの大部分が含まれています。 STM32TouchController.cppには、空のタッチ・コントローラ・インタフェースが含まれます。 TouchGFXHAL.cpp は、TouchGFXGeneratedHALのサブクラスTouchGFXHAL,を定義します。

TouchGFXConfiguration.cppにはHALを構築する関数とTouchGFXのメイン・ループを開始する関数が含まれることを把握しておくことが重要です。 追加設定は、編集可能なユーザクラスTouchGFXHALにて行うことができます。 HALの一般的なアーキテクチャは次のようになります。

生成されるコードの階層

機能の概要

TouchGFX Generatorを有効にすると、ユーザ・インタフェースには次の4つのグループが表示されます。

  • Dependencies - このグループには依存関係、警告、または設定内の具体的なエラーに関する開発者への通知が含まれます。 エントリが存在しない場合、このグループは非表示になります。
  • Display - このグループにはディスプレイに関連する設定(インタフェース、フレームバッファのビット深度、幅、高さなど)が含まれます。 これらの設定は、TouchGFXプロジェクトのキャンバスのサイズや、アセット用に生成されるコードに直接影響します。
  • Driver - このグループでは、アプリケーション、グラフィック・アクセラレーション、RTOSのティック・ソースに関連する多くの既製のドライバに対してユーザがオプトインできます。 STM32CubeMXはFreeRTOS(CMSIS RTOS v1およびv2)の設定をサポートしているため、TouchGFX Generatorはこれらの各オプションに対してドライバを提供します。
  • Video Decoding - このグループでは、ハードウェアまたはソフトウェアのビデオ・デコーディングをユーザが有効化できます。 このオプションはビデオ・ウィジェットと併用する必要があります。 なお、すべてのマイクロコントローラがビデオ・デコーディングに対応しているわけではありません。

TouchGFX Generatorには4つのグループ、Dependencies、Display、Driver、Video Decodingがあります。

Display

Displayグループには、ディスプレイに関連する設定(インタフェース、寸法、バッファリング戦略など)が含まれます。

インタフェースと寸法

現在、STM32マイクロコントローラでは、次に示すような複数のディスプレイ・インタフェースを使用できます。

  • パラレルRGB(LTDC)
  • MIPI DSI
  • FMC
  • SPI

ディスプレイがLTDCまたはFMCに接続されたマイクロコントローラの場合、TouchGFX Generatorは、接続されたディスプレイにフレームバッファを転送するためのコードを生成できます。 DSIおよびSPIインタフェースのドライバは、開発者自身で実装する必要があります。

Further reading
さまざまなディスプレイ・インタフェースのコードの具体例については、「シナリオ」を参照してください。

フレームバッファのピクセル・フォーマット

TouchGFX Generatorによって現在サポートされているフレームバッファのピクセル・フォーマットは、以下です。 Customディスプレイ・インタフェースを使用する場合はすべてのオプションを使用できます。それ以外の場合、オプションはディスプレイ・コントローラの設定に制限されます(たとえば、LTDCフレームバッファの形式を「RGB565」に設定すると、TouchGFX Generatorのオプションは「RGB565」に制限されます)。

  1. BW(1bpp)
  2. Grey2(2bpp)
  3. Grey4(4bpp)
  4. ABRG2222(8bpp)
  5. ARGB2222(8bpp)
  6. BGRA2222(8bpp)
  7. RGBA2222(8bpp)
  8. RGB565(16bpp)
  9. RGB888(24bpp)
  10. ARGB8888(32bpp)
  11. XRGB8888(32bpp)
Note
一部のピクセル・フォーマットでは、ChromART(DMA2D)のサポートがないか、一部のみになります。
Caution
Cortex F7/H7の場合、フレームバッファがライトスルーのキャッシュ・メモリ(SRAMなど)に配置されていれば、DMA2D(Generatorで設定されている場合)がアクセスする前に、生成されたコードによってDCacheが一掃されます。 このキャッシュ・メカニズムを機能させるには、STM32CubeMXで[Cortex M7][System Core]設定にある[CPU Cache]を必ず有効化してください。
Further reading
CPUキャッシュの詳細については、「F7およびH7のキャッシュ」サブセクションを参照してください。

Buffering Strategies

TouchGFX Generatorを介して、次のフレームバッファ戦略を設定できます。

  • Single Buffer - アプリケーション・フレームバッファを1つだけ使用します。 パフォーマンスが制限される可能性がありますが、メモリの使用量は少なくて済みます。 [Buffer Location]設定で使用して、内部RAMに配置できます。 さらに最適化するには、ディスプレイ・コントローラによって現在処理されているラインを返す関数をユーザが定義できます。 この方法はフレームワークによって使用され、このフレームですでにディスプレイに転送済みのメモリへの更新ができるようになります。
  • Double Buffer - 2つのフレームバッファを使用します。 通常、多くのメモリを必要としますが、パフォーマンスが向上します。
  • Partial Buffer - 1つ以上のユーザ定義のメモリ領域をフレームバッファとして使用します。 この戦略は外部RAMに頼らないが、ディスプレイのフレームバッファ全体では使用可能なメモリ量を超える可能性がある場合の低コストのソリューションをターゲットにしています。

シングル・バッファとダブル・バッファの場合、ユーザは[Buffer Location]設定で次のオプションを使用して場所を設定できます。

  • By Allocation - リンカがリンカ・スクリプトに従ってフレームバッファのメモリを配置できます。 デフォルトは内部RAMです。
  • By Address - ユーザが1つ(シングル)または2つ(ダブル)のフレームバッファ・アドレスを定義できます。

パーシャル・バッファ戦略では、ユーザは以下のパラメータを定義できます。

  • ブロック数(常に内部RAMに配置される)
  • ブロック・サイズ(バイト)

パーシャル・バッファ戦略に関する中心的な概念を理解するには、パーシャル・フレームバッファを使用してメモリ要件を軽減する方法に関する専門の記事を参照してください。 この記事はパーシャル・フレームバッファを実現する方法を概念的に示したものなので、この記事に示すコードはTouchGFX Generatorによって生成されるコードと少し異なっています。 これらの戦略で生成されるコードの具体例については、「フレームバッファ戦略」を参照してください。

Driver

[Driver]セクションでは、TouchGFX ALのさまざまな役割に対応するドライバを開発者が選択できます。

Application Tick Source

アプリケーションのティック・ソースは、アプリケーションを前進させる方法を定義します。 開発者は以下のオプションを使用できます。

  • LTDC - [Display]グループのインタフェースとして[LTDC]を選択した場合、[Application Tick Source]を[LTDC]にできます。 つまり、TouchGFX GeneratorがTouchGFXGeneratedHAL クラスにドライバ関数(LTDC割込みハンドラ)をインストールし、それがOSWrappers::signalVSync().を呼び出してアプリケーションを前進させます。
  • Custom and FMC - この場合、OSWrappers::signalVSync()を繰り返し呼び出すことでアプリケーションを前進させるハンドラを、開発者が実装する必要があります。

Graphics Accelerator

グラフィック・アクセラレーションに関して、開発者には次の3つのオプションがあります。

  • None - アプリケーションはCPUのみを使用してフレームをレンダリングします。
  • Chrom-ART (DMA2D) - アプリケーションは可能であればChrom-ART機能を使用してピクセルの移動やブレンドを行い、CPUサイクルを解放します。 TouchGFX Generatorによってドライバがインストールされるので、開発者によるアクションは必要ありません。

TouchGFX Generatorから提供されるChrom-ART(DMA2D)ドライバは、TransferCompleteInterruptの受信方法として次の2つをサポートしています。

  1. TM32Cube HALドライバを使用して、dma2dハンドラにコールバック関数hdma2d.XferCpltCallbackを登録する。
  2. DMA2D_IRQHandler()割込みハンドラを直接使用する。

この2つの方法を切り替えるには、DMA2D IP用のSTM32CubeMXのNVIC設定で、DMA2Dグローバル割込みを有効化 / 無効化します。 グローバル割込みを有効化するとオプション1のコードが生成され、グローバル割込みを無効化するとオプション2のコードが生成されます。

Note
  • DMA2Dのグローバル割込みを使用する場合は、「IRQハンドラ」が「DMA2D HALハンドラ」を呼び出すことを確認します。これはデフォルトの動作です。
  • グローバル割込みが有効で「IRQハンドラ」とDMA2Dの「HALハンドラの呼び出し」が無効になっている場合、登録されたコールバックが呼び出されません。
  • Real-Time Operating System

    開発者はTouchGFXで任意のRTOSを使用できます(OS無しも含む)。 「抽象化レイヤ・アーキテクチャ」で説明したように、TouchGFXエンジンはインタフェースを使用して、ユーザが選択したRTOSと、メイン・イベント・ループおよびフレームバッファのアクセスを同期させます。OSWrappers 開発者がTouchGFX Generatorを介してオペレーティング・システムを選択した場合、選択したOSのプリミティブを介して内部同期するためのコードが生成されます。 それでも、特にスタック・サイズを決定するために、STM32CubeMXを介してオペレーティング・システムを設定する必要があります。

    FreeRTOS(CMSIS準拠OS)およびAzureRTOS(H7のみ)は、STM32CubeMXおよびTouchGFX Generator内から直接設定可能で、タスク定義とTouchGFX RTOSドライバの両方のユーザ生成のコードをユーザに提供します。 TouchGFX Generatorは、任意のCMSIS準拠RTOSと組み合わせで動作するCMSIS V1およびCMSIS V2準拠のRTOSドライバ、オペレーティング・システムなしでベア・メタルで実行するドライバ、ThreadXのネイティブ・ドライバ(AzureRTOS X-CUBEを使用)を生成できます。 オペレーティング・システムなしの場合、開発者はSTM32CubeMXを使用してタスク定義のコードを生成できなくなり、ユーザ・コードでこれを行う必要が生じます。

    Note
    FreeRTOS実行のDesignerから使用できるすべてのTouchGFXボード設定

    次の図は、TouchGFX Generatorを通して使用可能なオプションを示しています。

    RTOSドライバのオプション

    この画像では具体的に、AzureRTOS X-CUBEが有効化されており、ThreadXとCMSIS RTOS V2が選択できるようになっています(ThreadXはCMSIS準拠)。 FreeRTOSが有効になると、「ThreadX」オプションが無効になります。 ThreadXを有効にするには、X-CUBE-AZRTOS-H7(H7のみ)パックを使用します。

    X-CUBE-AZRTOSの設定

    次の関数を呼び出すと、TouchGFXのメイン・ループに入ります。

    void MX_TouchGFX_Process(void);

    開発者はTouchGFXアプリケーションを実行したいタスクのタスク・ハンドラ内で、この関数を呼び出す必要があります。 次の例は、ユーザがSTM32CubeMXからDefaultTaskという名前のFreeRTOSタスクを設定した場合に、 MX_TouchGFX_Process()を呼び出して、このタスク・ハンドラのユーザ・コード・セクションでTouchGFXを開始する方法を示しています。

    void StartDefaultTask(void *argument)
    {
      /* USER CODE BEGIN 5 */
    MX_TouchGFX_Process();
      /* USER CODE END 5 */ 
    }

    FreeRTOSを有効にすると、STM32CubeMXはスケジューラを起動するosKernelStart();の呼び出しも生成します。

    その他のCMSIS準拠OS

    STM32CubeMXが提供可能なOS(FreeRTOSおよびThreadX)以外のCMSIS準拠OSを必要とする開発者は、RTOSの設定とタスク定義を手動で行う必要があります。 一般的には、以下の手動ステップを行う必要があります。

    1. RTOSを設定する。
    2. TouchGFXを実行するためのタスクを定義する(MX_TouchGFX_Process)。
    3. スケジューラを起動する。

    ここでは、 ThreadX向けにステップ2と3を手動で実行する方法の例を示します。 STM32CubeMXはサポートしていないオペレーティング・システムの設定を支援できないので、コードの上書きを防ぐため、提供されたユーザ・コード・セクション内ですべてを設定する必要があります。 以下のコードは、GUIタスク定義の疑似コードを示しています。 一般に、STM32CubeMXで生成されていないコードについては、main.cファイル全体に点在するユーザ・コード・セクション内に配置する必要があります。

    /* BEGIN USER CODE SECTION */
    #include "tx_api.h"

    #define GUI_THREAD_STACK_SIZE 1024
    TX_THREAD gui_thread;
    void gui_thread_entry(ULONG thread_input); //Thread prototype
    /* END USER CODE SECTION */

    int main()
    {
    /* BEGIN USER CODE SECTION - Choose an appropriate one from main.c */
    /* Allocate the stack for gui thread */
    tx_byte_allocate(...);

    /* Create the gui thread. */
    tx_thread_create(&gui_thread, "GUI Thread", gui_thread_entry, 0,
    pointer, GUI_TASK_STACK_SIZE,
    1, 1, TX_NO_TIME_SLICE, TX_AUTO_START);

    /* END USER CODE SECTION*/

    MX_TouchGFX_Process を呼び出して、タスク・ハンドラ内で TouchGFXエンジンのメイン・ループを開始します。

    /* BEGIN USER CODE SECTION */
    void gui_thread_entry(ULONG thread_input)
    {
    MX_TouchGFX_Process();
    }
    /* END USER CODE SECTION*/

    スケジューラを起動して、GUIタスクとTouchGFXアプリケーションを起動します。

    /* BEGIN USER CODE SECTION */
    tx_kernel_enter();
    /* END USER CODE SECTION*/

    Additional features

    External Data Reader

    RGB565フレームバッファ・ピクセル・フォーマットでは、touchgfxは、いわゆるデータ・リーダのインタフェースをサポートしています。これにより開発者は、メモリ内で追加バッファが必要となるキャッシュを行うのではなく、メモリマップされないシリアルFlashから直接データを読み出せます。 データ・リーダを実装して、メモリマップされないFlashチップからアプリケーション・アセットを取得する方法の例については、シリアルFlashの記事を参照してください。

    通常、データ・リーダのオプションは、追加バッファ用に十分なメモリを備えていない低コストのソリューション(STM32G0など)で使用されます。 DMA2Dが有効である場合、これは有効化できません。

    フレームバッファのピクセル・フォーマットとしてRGB565を選択すると、[Additional Features]グループが使用可能になります。

    [Additional Features]のデータ・リーダ

    開発者は以下の設定を行うことができます。

    • External Data Reader: この機能を有効化または無効化します。 有効化すると、TouchGFXは生成済みのインタフェースを介してアセットのデータを直接取得します。 無効化した場合は、開発者がメモリ内のバッファに画像をキャッシュする必要があります。
    • External Data Reader: Line Buffer Size: 画像またはテキストをフレームバッファにブレンドするための2つのバッファを作成します。 ARGB8888ピクセル・フォーマットでフル・サイズの画像をサポートするためのデフォルト値は、一画面の幅 x 4バイトです。
    • External Data Reader: Minimum DMA transfer size: DMA転送を開始するための最小限必要なバイト数を設定します。 これより少ないバイト数が要求された場合、DMAは使用されません。

    [External Data Reader]を有効にしてコードを生成すると、メモリマップされないFlashからアセットを直接取得できるように以下の追加ファイルが作成されます。

    • TouchGFX/target/generated/TouchGFXGeneratedDataReader.cpp
    • TouchGFX/target/generated/TouchGFXGeneratedDataReader.hpp
    • TouchGFX/target/TouchGFXDataReader.cpp
    • TouchGFX/target/TouchGFXDataReader.hpp

    通常通り、TouchGFX Generatorによって生成されたコードに対して、TouchGFXGeneratedDataReader は読出し専用であり、ユーザの変更は TouchGFXDataReaderクラス内で行う必要があります。 TouchGFXGeneratedDataReaderのタイプはtouchgfx::FlashDataReader.です。

    以下のファイルが変更され、DataReaderを使用するようにTouchGFX HALが設定されます。

    • TouchGFX/target/generated/TouchGFXConfiguration.cpp
    • TouchGFX/target/generated/TouchGFXGeneratedHAL.cpp
    • TouchGFX/target/generated/TouchGFXGeneratedHAL.hpp
    Note
    データ・リーダの[Additional Feature]は、DMA2DとLTDCが無効になっている場合にのみ使用できます。

    8bitLTDCカラー・ルックアップ・テーブル

    フレームバッファをL8フォーマットで読み出すようにLTDCが設定されており、TouchGFXが ABRG2222ARGB222BGRA2222RGBA2222のいずれかでレンダリングする場合、TouchGFX Generatorは、TouchGFXHAL::initialize()の実行時にLTDCにロードされるCLUTを提供します。 LTDCおよびCLUTの使用方法の詳細については、STM32マイクロコントローラのリファレンス・マニュアルを参照してください。

    Video Decoding

    [Video Decoding]セクションを使用すると、開発者は、ハードウェアまたはソフトウェアのいずれかのビデオ・デコーディング機能を使用してTouchGFX HALを強化できます。

    [Video Decoding]はRGB565(16bpp)およびRGB888(24bpp)フレームバッファ・ピクセル・フォーマットでのみ利用可能です。 これらのフォーマットのどちらも選択されていない場合は、[Video Decoding]セクションは使用できません。

    Note
    すべてのマイクロコントローラがハードウェア・ビデオ・デコーディングに対応しているわけではありません。

    Type

    デフォルトでは、[Video Decoding]の[Type]は無効になっています。 必要なペリフェラルがSTM32CubeMXで有効化されていない場合は、[Software]と[Hardware]の両方がグレー表示になります。 マウスをグレー表示されているオプションに合わせ、必要なペリフェラルを確認します。

    [Hardware]のビデオ・タイプの依存関係を示す情報ボックス

    • Software - STM32CubeMXの[Middleware]セクションでLIBJPEGが有効になっている場合は、[Sotware]オプションを選択すると、ソフトウェア・デコーダが生成されます。 これはつまり、ToughGFX GeneratorによってソフトウェアMJPEGデコーダが生成されるということです。
    • Hardware - JPEGが[Multimedia]セクションで有効になっており、CMSIS準拠のRTOSがTouchGFX Generatorで選択されている場合は、[Hardware]オプションを選択できます。

    Video Decodingタイプのオプション

    LIBJPEG設定では、効率化のために、[RGB scanline format]セクションでRGB順序を「RGB」ではなく「BGR」に設定する必要があります。 ピクセル当たりのバイト数は3に設定します。

    LIBJPEGの必要な[RGB scanline format]の設定

    ハードウェア・デコーディングを使用する場合、JPEG設定のRGBフォーマットはディスプレイと同じにする必要があります。

    Further reading
    各種ビデオ・デコーディング・シナリオの具体的なコード・サンプルについては、「シナリオ」セクションを参照してください。

    Concurrent videos

    [Concurrent Videos]オプションは任意の時点でGUIの同じ画面で同時にデコードされるビデオの最大量を指定します。 画面上で1つのビデオをデコードする場合にのみ、[Number of Videos]を1に設定できます。

    最大で4つのビデオを同時にデコードできます。

    Strategy

    ビデオ・デコーディング方式に関して、開発者には次の3つのオプションがあります。

    • Direct to Framebuffer - ビデオはUIスレッドでデコードされます。 これは、他の方式よりも時間がかかります。 ハードウェア・ビデオ・デコーディングを使用する場合、[Direct to Framebuffer]オプションは使用できません。
    • Single Buffer - ビデオは1つの専用バッファと1つの専用タスクでデコードされます。 このバッファは内部メモリに割り当てられます。
    • Double Buffer - ビデオは2つの専用バッファと1つの専用タスクでデコードされます。これは多くのメモリを必要としますが、パフォーマンスは向上します。

    シングルまたはダブル・フレームバッファ方式を採用する場合、CMSIS準拠のOSを有効化する必要があります。

    CMSIS RTOS要件に関する情報ボックス

    Note
    ダブル・バッファ方式を採用する場合には、メモリ消費に注意してください。
    Further reading
    ビデオ・デコーディングのFreeRTOS設定の具体例については、「シナリオ」セクションを参照してください。

    Decode Format

    ソフトウェア・デコーディングの場合、開発者は、フレームバッファのピクセル・フォーマットに関係なく、RGBバッファのピクセル・フォーマットを選択できます。 TouchGFX Generatorは、これらのフォーマットが異なっている場合に、ChromARTでピクセル・フォーマットの変換を実行できるコードを生成します。 ビデオ・デコーディング・バッファをRGB565にすると、開発者はメモリ・フットプリントを小さくすることができます。

    デコード形式

    Buffer size

    バッファの幅と高さの設定は、アプリケーションの最大ビデオ寸法に一致する必要があります。 幅は32で割り切れる必要があります。

    次のコードは、480x272、RGB888ビデオ・ディスプレイと「シングル・バッファ」ビデオ・デコーディング方式を使用するアプリケーション向けにTouchGFXGeneratedHAL.cppに生成されたコードです。

    TouchGFXGeneratedHAL.cpp

    #include <DedicatedBufferVideoController.hpp>
    #include <SoftwareMJPEGDecoder.hpp>

    uint32_t lineBuffer[480];

    SoftwareMJPEGDecoder mjpegdecoder1((uint8_t*)lineBuffer);

    uint32_t videoRGBBuffer[97920];
    DedicatedBufferController<1, 480, 272, 480*3U, Bitmap::RGB888> videoController;

    //Singleton Factory
    VideoController& VideoController::getInstance()
    {
    return videoController;
    }

    void TouchGFXGeneratedHAL::initialize()
    {
    HAL::initialize();
    registerEventListener(*(Application::getInstance()));
    setFrameBufferStartAddresses((void*)frameBuf, (void*)(frameBuf + sizeof(frameBuf) / (sizeof(uint32_t) * 2)), (void*)0);

    /*
    * Add software decoder to video controller
    */
    videoController.addDecoder(mjpegdecoder1, 0);

    videoController.setRGBBuffer((uint8_t*)videoRGBBuffer, sizeof(videoRGBBuffer));
    }

    生成されるプロジェクト

    STM32CubeMXでGenerate Codeボタンを使用してコードを生成する場合、TouchGFXは(少なくとも)以下のIDEで動作します。

    1. EWARM
    2. MDK-ARM
    3. STM32CubeIDE

    最適なプロジェクト構造を得るために、プロジェクト生成では以下のオプションを選択します。

    • [Application structure]:[Advanced]
    • [Generate under root]無効化(STM32CubeIDEのみ)

    [Advanced]のアプリケーション構造を選択し、[Generate under root]をオフにする

    STM32CubeMXは以下の構造を持つTouchGFXフォルダも生成します。

    TouchGFXフォルダの構造

    • Appフォルダには、TouchGFXを初期化し、起動するコードが含まれています。
    • targetフォルダには、読出し専用の生成済みコード(generated/内)と、変更可能なユーザ・クラス(STM32TouchController.cppTouchGFXGPIO.cpp およびTouchGFXHAL.cppが含まれています。
    • .partファイルは、TouchGFXヘッダ・ファイルとライブラリを完備した完全なTouchGFXプロジェクトを作成するために、TouchGFX Designerを使用して開かれます。partファイルにはピクセル・フォーマットやDesignerがTouchGFXアプリケーション・コードを生成するときに使用するキャンバスの寸法などの関連するアプリケーション情報が含まれています。

    TouchGFX Designerプロジェクト

    以下のコードは、 「生成されるコードのアーキテクチャ」セクションで説明した.partファイルの内容例を示しています。 下記の生成後コマンドでは、TouchGFX Designerで新しいファイル(新しい画面やアセットなど)が作成されると、STM32CubeMXで選択されたプロジェクト(EWARMなど)が更新されます。

    {
    "Application": {
    "Name": "my_project",
    "TouchGfxPath": "../Middlewares/ST/touchgfx",
    "AvailableColorDepths": [ 16 ],
    "AvailableLCDs":
    {
    "16": "LCD16bpp"
    },
    "AvailableResolutions" :
    [
    {
    "Width": 320,
    "Height": 240
    }
    ],
    "PostGenerateTargetCommand" : "touchgfx update_project --project-file=../my_project.ioc --platform=m7"
    },
    "Version": "4.13.0"
    }

    TouchGFX Designerで.partファイルを開くと、開発者には、具体的なUIをロードするのか、空のテンプレートから開始するのかを選択するオプションが表示されます。

    UIの選択

    TouchGFX Designerで[Generate Code]を押すと、TouchGFXフォルダの構造は以下のようになります。 下の画像はTouchGFXフォルダ構造の具体例を示しており、生成後の新しいファイルやフォルダをハイライト表示しています。

    [Generate Code]

    TouchGFXフォルダの構造

    TouchGFXは、STM32CubeMXの.iocファイルから選択されたIDEを検出し(STM32CubeIDE、EWARM、MDK-ARMの場合)、画面の定義や画像およびフォント・アセットなどの新しく生成されたファイルでプロジェクト・ファイルを更新します。

    この時点で開発者は、STM32CubeMX、TouchGFX Designer、およびツールチェーン / IDEで以下のように交互に作業できるようになります。

    • STM32CubeMXでIDEプロジェクトのドライバを更新する。
    • STM32CubeMXはDesignerで即座に選択したUI関連の変更で、TouchGFXの.partファイルを更新する。
    • STM32CubeMXはTouchGFXが特定のプラットフォーム上で動作するために必要なTouchGFX Generatorの設定に基づいて、HALコード(TouchGFX/target/generated/)を生成する。
    • TouchGFX Designerは生成されたコードでプロジェクトを更新する。
    Note
    デュアルコア・プロジェクトでは、TouchGFXが特定のコンテキストに対して有効になっていると、通常、TouchGFXプロジェクトはそのコンテキスト専用のフォルダに配置されます(「CM4/TouchGFX」または「CM7/TouchGFX」など)。

    生成された動作の変更

    HALはクラス階層を持つので、STM32CubeMXによって生成されたHALの設定や動作をユーザがオーバーライドできることに留意してください。 以下の例では、開発者が initialize 関数を変更することで、TouchGFXの追加設定や、TouchGFXGeneratedHAL の既存の設定の変更が可能です。

    TouchGFXHAL.cpp
    void TouchGFXHAL::initialize()
    {
    // Calling parent implementation of initialize().
    //
    // To overwrite the generated implementation, omit call to parent function
    // and implemented needed functionality here.
    // Please note, HAL::initialize() must be called to initialize the framework.

    TouchGFXGeneratedHAL::initialize();

    //Overriding configurations
    hal.lockDMAToFrontPorch(true);
    hal.setFingerSize(4);
    hal....
    }

    プロジェクトのアップグレード

    TouchGFX Generatorのパラメータは.iocファイル(STM32CubeMXプロジェクト)に格納されます。 TouchGFX Generatorの新バージョンがリリースされると、旧バージョンのパラメータが新バージョンと互換性を持たないために移行が必要になる可能性があります。

    STM32CubeMXはX-CUBEバージョン間のアップグレードをサポートしていないため、[Generate Code]が押されると、.touchgfxファイルのPostGenerateTargetCommandセクション内の以下のコマンドによってTouchGFX Designerで自動的にアップグレードが実行されます。

    .touchgfx
    "PostGenerateTargetCommand" : "touchgfx update_project --project-file=../upgrade.ioc --platform=m7"

    コマンドによって.ioc ファイルが読み出され、現在のバージョンのX-CUBE-TOUCHGFXに合うようにパラメータが更新されます。 次の例は、X-CUBE-TOUCHGFX 4.13.0で作成された.iocファイルで、スクリプト(X-CUBE-TOUCHGFX 4.14.0)を手動で実行する方法を示しています。

    STM32F746 DISCOアプリケーション・テンプレートを使用した4.13.0から4.14.0へのアップグレード例
    $ touchgfx update_project --project-file=../STM32F746G_DISCO.ioc
    TouchGFX Generator 4.13.0 found
    Creating backup of ../STM32F746G_DISCO.ioc as ../backup_STM32F746G_DISCO.ioc
    Performing upgrade 4.13.0 -> 4.14.0 ... OK

    更新されたプロジェクトをSTM32CubeMXで開くと、.iocファイルで示されたバージョンのX-CUBE-TOUCHGFXをインストールするように求められます(まだインストールしていない場合)。 [Download now]をクリックすると、X-Cube-TouchGFX-4.14.0のダウンロードとインストールが行われます。

    追加ソフトウェア・コンポーネントが見つからない場合:

    アップグレード・プロセスの実行時、TouchGFX Generatorの設定はすべて保持され、.iocファイルのバックアップは先頭にbackup_が付いた状態で、元のファイルと同じ場所に配置されます

    Note
    TouchGFX Generatorによって提供される新機能を使用するには、STM32CubeMXで[Generate Code]を実行する必要があります。
    Caution
    既存のTouchGFXプロジェクト用にSTM32CubeMXを介してX-CUBE-TOUCHGFXをアップグレードするときに、そのアップグレード・プロセスがTouchGFX Designerによって実行されない場合、TouchGFX Generatorのパラメータは別のバージョンに適用されるパラメータであるため、デフォルトにリセットされます。