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

TouchGFX AL（抽象化レイヤ）開発の概要

プロジェクト作業

TouchGFXアプリケーション内のTouchGFX抽象化レイヤ（AL: Abstraction Layer）は、ボードの立ち上げフェーズで開発されるボード初期化コードとTouchGFXエンジンの間に存在するソフトウェア･コンポーネントです。 主なタスクは、エンジンと基盤となるハードウェアおよびオペレーティング･システムをつなぎ合わせることです。 このためには、基盤となるハードウェアとOSの詳細仕様を抽象化し、エンジンが統一された方法で処理できるようにします。

AL(抽象化レイヤ) は、ハードウェア抽象化レイヤ(HAL) とオペレーティング･システム抽象化レイヤ(OSAL) という2つの異なる部分で構成されます。

プロジェクト･コンポーネント

このセクションでは、抽象化レイヤの原理や役割と、TouchGFXエンジンとやり取りする方法について概略を紹介します。

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

以下のセクションでは、TouchGFX ALの一般的なアーキテクチャについて説明します。 STM32CubeMX内でTouchGFX Generatorを使用する方法に関する「ユーザガイド」も提供されています。 一般的な使用例を用いて、有用なシナリオも示されています。

抽象化レイヤの役割​

「基本概念」の章の「メイン･ループ」セクションで説明したように、TouchGFXエンジンには、以下の3つの基本ステップを実行するメイン･ループがあります。

  1. 入力の収集(タッチ座標、ボタン)
  2. シーン･モデルの更新
  3. シーン･モデルのフレームバッファへのレンダリング

この3つのステップによって、アプリケーションの現在の状態を反映するようにフレームバッファを更新するというTouchGFXエンジンの主な役割が果たされます。

ディスプレイへのフレームバッファ･データの実際の転送や外部入力の収集は、エンジンによって直接処理されるわけではなく、エンジンからTouchGFX ALに委譲されます。

メイン･ループはフレームバッファを繰り返し更新します。 すべてのフレームが転送され、ディスプレイに正しく表示されるようにするには、このプロセスをディスプレイの実際の更新頻度およびレディ状態と同期する必要があります。 同期が行われない場合、メイン･ループは更新を繰り返すので、転送される前にフレームバッファが上書きされてしまう可能性があります。 この同期を行うのはALの役割です。

TouchGFX ALは、フレームバッファ･メモリ領域とそのメモリ領域へのアクセスを制御する役割も担っています。 つまり、フレームバッファへのすべてのアクセスはALを介することになります。

TouchGFX ALの役割を詳しく説明すると以下のようになります。

役割説明
TouchGFXエンジンのメイン･ループとディスプレイ転送の同期次のフレームが計算され、使用可能なフレームバッファにレンダリングされた時点で、エンジンのメイン･ループを停止して、新たにアセンブルされたフレームバッファがディスプレイに転送される前に上書きされないようにする必要があります。
タッチおよび物理ボタンのイベントのレポートタッチ･イベントが発生したかどうかと、その座標をサンプリングします。 物理ボタンやそれに類似するものがアクティブ化されたかどうかをサンプリングします。 これらのイベントをエンジンにレポートします。
その他の外部イベントは、別のメカニズムを通してTouchGFXアプリケーションに伝播されます。 詳細については、バックエンド通信に関するセクションを参照してください。
フレームバッファへのアクセスの同期フレームバッファ･メモリはTouchGFX ALの担当範囲であり、ここにはさまざまなアクター(メイン･ループ･スレッドやDMAなど) がアクセスできるので、TouchGFX ALはこのメモリを保護する方法を提供する必要があります。
次に使用可能なフレームバッファ領域のレポートALは、次に更新可能なのは現在のフレームバッファのどの部分なのかを回答できる必要があります。 標準の2フレームバッファ設定では、常に1つのフレームバッファ全体がレンダリング専用になり、もう1つがディスプレイへの転送用になるため、これは常に完全なフレームバッファになります。 1つまたは部分的なフレームバッファ設定では、もっと複雑になります。
レンダリング操作の実行シーン･モデルのレンダリング時に、エンジンのメイン･ループはALに部分的なレンダリングを行うように要求します。 特定のTouchGFX AL実装では、基盤となるハードウェアを利用してグラフィック･プリミティブのレンダリングを行います。 一例としては、Chrom-ARTグラフィック･アクセラレータによるマイクロコントローラ上でのビットマップのレンダリングが挙げられます。 TouchGFXには、すべての使用可能なプラットフォームに対して最適化されたレンダリング手法が組み込まれているので、カスタマイズの必要はありません。
ディスプレイへのフレームバッファの転送処理エンジンはALに、転送の必要があるのはどのフレームバッファのどの部分なのかを通知します。 ALはこの転送を開始して、最終的にはピクセルを物理ディスプレイ上に表示させる必要があります。

TouchGFX ALはパッシブなソフトウェア･モジュールで、独自のスレッドやそれに類似するものを持たないため、TouchGFXエンジンのメイン･ループから呼び出された特定のフック(機能) または割込みを介してアクションを実行する必要があります。

使用可能な一連のフックと割込みを以下の図に示します。

使用可能なフックと割込み

基盤となるハードウェアおよびオペレーシング･システムが与えられている場合に、ALの役割が果たされるようにこれらのフックを実装するかどうかは、AL開発者の判断に委ねられます。 役割をサポートするためにAL開発者が他の手段を必要とする場合、開発者は特定のポイントでアクティブ化するように割込みを設定できます。 この例としては、LTDC垂直同期割込みやハードウェア･タイマが挙げられます。 ディスプレイ･レディ割込みは、垂直同期割込みの例です。 これらの割込みの設定は、AL開発の一部と見なされることに注意してください。

設定例: 2フレームバッファ - LTDC付きマイクロコントローラ​

一般的な設定の一つは、2つのフレームバッファとLTDC付きマイクロコントローラによるものです。 各フックのALアクションは、この設定では主に次のようになります。

LTDC VSYNC割込みに反応するようにALを設定し、ディスプレイが新しいフレームを受信する準備ができるたびにI1が実行されるようにします。 これを使用してメイン･ループとディスプレイを同期します。

フックと割込みアクション
I1: ディスプレイ･レディこれをトリガするには、LTDC VSYNC割込みを設定します。
メイン･ループをブロック解除し、前のフレームで準備されたフレームバッファのフレームバッファ転送を開始します。
H1: タッチおよび物理ボタンのイベントのレポートタッチ･イベントまたは物理ボタンのクリックに関する情報を返します。
H2: 次に使用可能なフレームバッファ領域の取得ダブル･バッファ設定を使用して、単に、現在ディスプレイに転送されていないフレームバッファの全領域を返します。
H3: レンダリング操作の実行マイクロコントローラの機能によって異なります。 ハードウェア支援のレンダリング操作とそれ以外に対するソフトウェア･フォールバックを実行します。
H4: 領域レンダリングの完了アクションなし
H5: レンダリング終了メイン･ループをブロックします。

この設定では、以下のような実行フローとなります。

2つのフレームバッファとLTDC付きマイクロコントローラによる設定の実行フロー

これは、この設定のALの全体設計を示しています。 以降のセクションでは、抽象化レイヤの実装方法に詳しく踏み込んで説明します。