STM32上のソフトウェアグラフィックコプロセッサー

1年が経過し、次の、はるかに大きく、今回は有用なプロジェクトを書くために多くの夜が費やされました。 前回は、できるだけ早くどこでも絞らなければなりませんでした。 その辛抱強い石のリソースは私にとって十分ではなく、ある時点で興味深い解決策が出てきました。 タスクの一部を別のコントローラーに渡します。 （前回同様、カットの下にはたくさんの水と画像があります。）

Nextion HMIやGameduinoのようなプロジェクトを持っているにもかかわらず、いくつかの理由で決断を下すことにしました。 Gameduinoは、興味深いソリューション（ボード上のVGA出力とFPGA）に見えましたが、このボードの2番目のバージョンを入手できないため、最初のリビジョンを購入する必要がありました。 それは痛みと苦しみでした：

• あいまいなプロトコル。
• ネット上のいくつかの例;
• ホスト内のグラフィックスストレージ（SDカードに保存できますが、FatFSが必要になりますが、より多くを消費し、意味が失われます）。
• 達人だけが理解できる多くのマジックナンバー。
• 全体として、このプロジェクトは生きているよりも死んでいる可能性が高いです。
  

Nextionの爆発的な人気にもかかわらず、プロジェクトはそのような広範囲に渡る配布の前に現れ始めました。失敗のその他の理由は次のとおりです。

• IDEから始まるネクシオンに対処したくありませんでした。
• ヨーロッパ以外の料金が発生する危険性（ただし、一種の治療が行われます）。
• IDEから事前にプログラムされたアクションのみが使用可能です（正しくない場合は修正）。
• ホストとディスプレイの両方に書き込む必要があります。
• プロトコルの大きなオーバーヘッド（ただし、これは理解できます）。

そして最も重要なことは、どちらの場合も、独自の何かを追加する方法がないことです。

sGPUのコントローラー

---

アイデアの不合理さのために、STM32F4xxシリーズをすぐに拒否しました（このようなナンセンスにこのようなコントローラーを使用してください！pro2にのみ... ）。

20 kb RAMを備えたSTM32F103C8T6（以下、ミニバージョンと呼びます）および64 kb RAMを備えたSTM32F103VET6（以下、プロバージョンと呼びます）が選択されました。

ミニは、中国とその安価で愛されているメープルミニクローンのおかげではるかに広く普及しているため、以下に説明するいくつかの制限にもかかわらず、メインコアとして選択することが決定されました（中国では、プロバージョンのボードをministm32クローンとしてリリースしています）。

カーネルを作成しただけでなく、プロジェクトのコントローラーのタイプを変更し、いくつかのインクルージョンを変更して、大量のメモリーとFSMCコントローラーを備えたsGPUを取得します（ミニバージョンの安さと普及により、使用しないことが難しくなっています）。

スクリーン

---

ILI9341ドライバー（画面解像度320x240）に基づく画面を使用しました。 画面との相互作用は、SPI経由（FSMC経由でも可能ですが、さまざまな理由でテストすることはできません）で、このコントローラーの最大可能速度-36 Mbps（実際に測定した場合、約2.7 Mb / sまたは22 Mbps）、ただし、リファレンスマニュアル（F101-F107の場合はRM0008）に示されているように、DMA転送のみ。

無駄な試みの後、より高速にSPIを取得することはできませんでした。 コントローラーのSPIブロックは狂い始めます（72 MHzではなく、F_CPUの安定した最大80 MHzは、オーバークロックされた36 Mbit / sより少し多くなります）。

インターフェース

---

最も興味深いことは、ホストとsGPUの通信インターフェースの前に選択が行われたときに始まりました。
インターフェイス要件は次のとおりです。

• ほとんどすべてのコントローラーによるサポート。
• 実装が簡単。
• 十分な帯域幅があります。
• 使用される最小行数があります。

選択はUARTに落ちました。 すべてのデバイスが1MBaudの交換レートをサポートできるわけではないため、速度を選択してもそれほど明白ではなくなりました。 考え直すことなく、彼は4つの可能な速度を作成しました：9600、57600、115200、1M。 3つのGPIOを使用してハードウェアで速度を選択することもできます（GPIOと速度の対応はSTM32_GPU_GPIO_Pinout.txtにあります）。

これらのうち、使用されたのは4つだけで、残りは予備です（少なくとも1200ボーを作成できます）。

速度はマスクによって選択され、

タイル

---

これは、sGPUが最初にできることです。

各タイルは、現在のカラーパレット内の色のインデックスを持つバイトの配列です。



タイルが何であるかについては絶対に説明しません。ネットワーク上の情報を見つける能力に頼ります。情報の量が多すぎます。

数百、数千のタイルが存在する可能性があるため、非常に多くのROMを占有します。 ホスト側からそれらを転送することは完全に非論理的です（最初のリビジョンのGameduinoで行われたように）。

出力は、メモリカードをSPIに固執することでしたが、 SDIOはまだです。 FatFSを上げることが最も難しいことが判明しました。 すべてがHALやCubeMXではなくSPLライブラリを使用して記述されているため、またおそらくSDカードの電源を十分にチェックしなかったため（電源に非常に敏感であるため）、ある時点ですべてが機能しました。

最終的に、ホスト側では、ファイル名とRAM sGPUに読み込むタイルの数を送信するだけで十分です。


5バイトのコマンド（これは、書き込み時に1つのタイルをロードするための最小サイズです）は、RAMと読み取り専用メモリの両方のかなりの部分を消費する面倒なFatFSライブラリよりもはるかに小さいことに同意します。

次のタイルサイズがサポートされています。

• 8x8-最小、64バイトのRAMのみを使用。
• 16x16-中型、すでに4倍以上のRAM（256バイト）を使用しています。
• 32x32は最大で、やはり4倍大きく、4倍のRAM（1024バイト）を必要とします。

最後のタイプのタイルはプロバージョンでのみ使用できます。これは、ミニバージョンのメモリの半分を消費するのはこれらの10個だけであるためです。

また、画面に表示するときにトリックを利用したことにも触れます。 DMA（RGB565には1つの変換されたタイル用のバッファーがあります）の使用に加えて、各タイルのインデックスを確認し、前のタイルと一致する場合、変換はスキップされ、古いタイルは新しい座標で表示されます。 このようなメモリの浪費にもかかわらず、同じタイルが画面に連続して表示される場合、これは否定できない利点があります。 変換する時間がないため、タイルはほぼすぐに表示されます。


軟膏で飛ぶ-上記のビデオでは、ホストのコードはCバージョンのライブラリを使用しています（同一はArduinoでSTM32を使用する場合にのみ実現できます）。



その上で、アドレスウィンドウの設定中に多くのボイドに気付くことができます。 ほとんどの場合、これらのボイドはDCラインの切り替え（データまたはコマンドの選択、2番目のチャネルは赤色のライン）、SPIバッファーの解放の待機（すべてのデータの送信の待機）です。 ディスプレイの機能のため、これではほとんど何もできません（9ビットモードまたはFSMCのみ）。

タイルを作成する

---

タイルがRAM sGPUを取得する前に、まずSDカードからダウンロードする必要がありますが、その前にタイルを配置する必要があります。

タイルの作成はそれほど難しくありません。次の手順を実行してください。

• GIMPでは、完成した画像はインデックスモードになります。
• 生データとしてエクスポート（標準R、G、B）;
• 8.3マスク（ファイル名に最大8文字、拡張子に3文字、これは現在のFatFS設定の制限です）でファイルの名前を変更します。通常、* .tle拡張子を使用します（sGPUは拡張子自体を置き換えるため、ホストは転送する必要がありません）。
• ルートのSDカードに* .tleファイルを配置します。
• -???;
• -利益!!!

実際には、タイルまたはタイルのセット（タイルセット）自体のイメージを作成する必要があるためです。 ピクセルアートの多くのツールの中で、PixelEditを選択しました（ネットワーク上の情報を検索できるようになりますように）。

そこで画像を作成したら、それを* .pngとしてエクスポートし、GIMPにフィードするだけで十分です（上記を参照）。

スプライト

---

sGPUでできることの2つ目は、タイルからスプライトを作成することです。 スプライトは、グループ内のタイルの組み合わせです（簡略化されている場合）。


ミニ版のスプライトの数は56で、プロ版の場合は63です。ミニ版とプロ版のスプライトの数は異なる方法で計算されました。 ミニの場合、これは各タイプのタイルの最大数の半分の合計ですが、プロの場合、これはすべての人にとって十分な63のスプライトの四分の一の合計です 。

スプライトは、同じ種類のタイルで構成できます。 8x8と16x16のタイルからスプライトを同時に作成することはできませんが、8x8と16x16のタイルから2つのスプライトを作成することはできます。 各スプライトは4つのタイル（最大）で構成され、 64x64スプライトはすべてのユーザーに十分であり、他のすべてには* .bmp出力があります 。

次のサイズの組み合わせが可能です。

• 1x1;
• 1x2;
• 2x1;
• 2x2

ここで、最初の桁はタイルの高さ、タイルの2番目の幅です。

さらに、各スプライトには、描画されるピクセル単位の座標が含まれています（2つのスプライトの衝突の計算に役立ちますが、ここにも存在します）。

タイルの背景

---

sGPUでできることは3つ目です。

メモリには、サイズがわずか8x8のタイルインデックスを持つ1200バイト（40x30タイル）の配列が含まれています（将来的には選択肢があるかもしれません）。

タイルカードはRAMに保存され、SDカードから読み込まれます（* .map拡張子）。 現在、マップファイルを作成するツールはありません。


電源投入時にタイルの背景の例を見ることができます。



今最も不快です。 スプライトとタイルの背景は同じ8x8タイルを使用します。 つまり、背景とスプライトには、異なるタイルを使用する必要があります（はい、ミニバージョンには多くありません）。

メモリ割り当て

---

明らかに、stm32 RAMは限られているため、あまり多くのことを突き詰めることはできません。 私にはまだわからない理由で、私はタイル用のメモリをミニ-7680バイト、プロ-40960バイトに割り当てることにしました。

しかし、このすべてのメモリを1種類のタイルに割り当てたくありませんでした。 このメモリの分散、または使用するタイルの数に問題が発生しました。

以前、古いコンソールに関する記事を読んだときに、コンソールによっては、ある種のタイルが常に欠落しているという事実に出会いました。

したがって、考えられる多くのシナリオを考慮して、次のように配布することが決定されました。

• 最も使用されるリソースとしての80タイル8x8。
• 10タイル16x16、残念ながら少数です。これは空きメモリのすべてであるためです。

64 kb RAMのより大きなコントローラーを忘れないでください。そのため、ディストリビューションは既に次のようになっています。

• 160 8x8タイル、これもまた最も使用されるリソースです。
• 80タイル16x16、今回はさらに多くのタイルがあります。
• 10タイル32x32、ここでも数は少ないですが、今回はサイズを考慮する価値があります。

私はまだ正しい分布を疑っています（ダイナミクスはまったく選択肢ではありません）。 残りは「RAMmath.txt」ファイルにあります。

カラーパレット

---

使用するメモリを削減するために、タイルは各ピクセルの色全体を使用せず（申し訳ありませんが、メモリはそれほど多くありません）、パフォーマンスを大幅に向上させますが、カラーパレットの色インデックスのみを使用します。 このソリューションにより、メモリ要件が半分に削減され、トリックを使用してパレットを変更し、同じタイルを表示できるようになりました（新しいタイルをダウンロードする必要はありません）。

同様のトリックがすべての古いコンソールで使用されました。 最も有名で有名な

最も単純なパレットとして、NESパレットが使用されましたが、その不十分さが発見されました。

GIMPとシステムに統合された比色計を装備して、彼は色セットを76（予備用に4つの黒）に拡張しました。

もちろん、完璧な色知覚を持つ人ではないため、76色の適切なパレットを作成できませんでした。


誰かが256色のより適切なパレット（将来のアルファチャネル用に1色）を見つけたり作成したりできたら、とても感謝しています。

別のパレットを使用する必要がある場合は、SDカードからダウンロードできます。 RAM sGPUには最大512バイトがあります（256色、色ごとに2バイト、GameBoy Advanceと同様ですが、RGB565のみ）。

GIMPからパレットをエクスポートするのは非常に簡単です。インデックスされた画像（生データなど）をエクスポートするだけで、画像ファイルの隣のGIMPは* .pal拡張子を持つ別の画像を作成します。 また、SDカードに配置する必要があります（最大8文字の名前のサイズを忘れないでください）。

プロトコル

---

プロトコルは、コマンドのサイズができるだけ小さくなるように作成されました。 厳密に指定されたコマンドのサイズとパラメーター、およびコマンドの正確さを完全に制御できない。 コマンド実行の最高速度のためのすべて（結局、すべてはプログラムで行われます、覚えている場合）。

コマンドは、コードのバイトで始まります。 チーム全体の最終的なサイズは、コードによって異なります。 したがって、画面全体を単一の色で塗りつぶすために必要なのは3バイトだけですが、三角形を描画するためにはすでに15バイトです。

コマンドコードはきちんと範囲（セクション）に分割され、多数の未使用コードがあります。 現在のプロトコルの実装では、合計で255チームを使用できますが、そのうちの半分も使用されていません（創造性のための自由な分野があります）。

ホスト側

---

ホスト側では、sGPUは通常の画面のように見えますが、UARTインターフェース上のみです。

sGPUコマンド用の大きな入力バッファーにもかかわらず、オーバーフローするリスクがまだあります。 したがって、2つの保護オプションがあります（実際1）。

• ホストへのプログラムによる応答。 低速ですが、広くサポートされているオプション（少なくともUSB <-> UARTと交換用の3行のみを使用できます）。
• ホストへのハードウェア応答。 GPIOが使用され、ホストがこのピンの状態を監視するだけで、バッファがいっぱいになる可能性が低くなるため、大幅に高速になります。

Arduinoには2つのバージョンのライブラリがあります。 Arduino（C ++）向けに完全にシャープ化されたライブラリのバージョンは、非常に多くの利点がありますが、1つの大きな副次的な欠点があります-非常に厚くて遅いです（タイルセクションを参照）。 言い換えれば、空のスケッチ、これを言ってみましょう：

 #include <STMsGPU.h> STMsGPU gpu; void setup() {} void loop() {} 

1634バイトのROMと217バイトのRAMを消費しますが、これにはsGPUとの同期方法がありません！ さらに、STM32を使用する場合、これらの数値は10倍（少なくとも）倍になります-16732バイトのROMと3960バイトのRAM！

したがって、Cにはバージョンがあります。残念ながら、これまでのところatmega328p（など）に投獄されており、Arduinoのほとんどすべての利点がありません。 これらの欠点は、速度の向上とサイズの大幅な縮小の両方で補われます。922バイトのROMと46バイトのRAM（もちろん、これよりも少なくすることができます）は同期のみです。

最も重要なことは、Adafruit ili9341スクリーンライブラリを使用した場合、ほとんど何も書き換える必要がないことです。 すべてのメソッドとほぼ完全な互換性があります。

短所

---

画面全体の1フレームに必要なメモリ量は180キロバイトを占有するため、大量のメモリはありません。このため、フレームバッファを作成することは不可能です。 このため、現在、タイルとスプライトのアルファチャネルはありません。

ゆっくり。 FPGA（FT800、RA8875など）に対して、単純な72MHzコントローラーには抵抗する機会がありません。 プロ版でFSMCを起動すると状況が改善されることは明らかですが、私たちが望むほどではありません。

ソースコード

---

すべてのソースコードとstm32のファームウェアもGithubにあります（突然プログラマーがいない場合は、UART1経由でSTM32 Flash Loader Demonstratorを介してフラッシュできます）。

プロジェクトリポジトリへのリンクは次のとおりです（まだ存在する場合、ハブラ効果トラフィックのために禁止/ミュートアカウントを取得しないことを望みます ）。 ソースには、sGPUのプロジェクト（IAR ARMバージョン7.40用）、AVRとArduinoのコード（トートロジーはまだ公開されています）、接続方法などの説明があります。

---

一般に、既存の機能にもかかわらず、プロジェクトは非常に粗雑です。 YM2149Fのオーディオコプロセッサーを使用してコンソールに残すステップはあまりありません。

質問があれば、尋ねてください、私は答えてうれしいです。 また、いくつかのポイントをより詳細に強調して、さらに書くこともできます（これが必要かどうかを教えてください）。 ある記事では、上で書いたように、すべてをプッシュしないでください。