カラーLCDにシンプルなグラフィックスを表示するARMベースのデバイスを設計するとき、できれば特定のARMまたはLCDベンダーに縛られることなく、高速更新を可能にするものをどのように設計するのが最善でしょうか？私の現在のプロジェクトでは、PICのSPIポートによって電光石火で高速駆動できる白黒ディスプレイを使用しています（1/60秒で複雑なディスプレイを再描画）。一般的なカラーLCDディスプレイにはSPIポートがあるように見えますが、160x120 LCDを無地で塗りつぶすのに30msかかり、320x240に120msのベストケース（10MHzシフトクロック）がかかります。
コントローラーのピンを空けることができれば、パラレルモードの方が良いかもしれませんが、各ピクセルに3つのメモリストア命令（データを設定するための1つ、 1つはクロック出力を高く設定し、もう1つはクロック出力を低く設定します）。一部のARMチップにはメモリバスインターフェイスがありますが、多くの場合、アドレスとデータの多重化、または無関係なアドレスビットの出力に多くのピンを使用します（LCDには1つのアドレスビットが必要です）。
ILITEKのILI9320またはRenesasのHD66789を見ると、CPLDを使用してSPIをパラレルデータに変換し、ビット/ピクセルを出力するモードを含めることは興味深いと思われるアプローチの1つです。ルネサスのデータシートを見ると、すべてのパラレルポートデータビットがシリアルデータピンを追跡し、ピクセル以外のすべてにシリアルモードを使用することにより、最小限のハードウェアでピクセルごとの書き込みを取得できる可能性があります（CPLDは不要）書き込み、比較/マスク関数を使用して、すべてゼロのピクセルが透明になり、すべて1のピクセルがGRAMの選択されたビットを設定するか、すべて1のピクセルが透明になり、すべてゼロのピクセルが選択されたビットをクリアします。IKITEKデータシートの「機能」セクションは、同様の機能を備えていることを示していますが、レジスタマップにはありません。
コードが主に単色のテキストとグラフィックスを表示すると仮定すると、理想的なアプローチは、CPLDを使用してARMのSPIポートをディスプレイのパラレルポートに接続し、CPLDに前景色/背景色をロードできるようにすることです。これは、「透明」ピクセルを書き込む手段があれば特に便利です。フォントを2色のビットマップとして指定すると、フォントデータをSPIポートに直接ロードできます。これにより、2つのARMクロックごとに1ピクセルの割合でフォントデータを表示できます。一方、このような表示制御タスクを処理するのに十分なCPLDのコストは約2ドルです。
主に単色のテキストまたは単純な（16色または64色など）グラフィックを表示することが目的である場合、ARMとカラーLCDを接続する最良の方法は何ですか？
編集
キャラクターモードLCD、独自のドライブ方式を使用したカスタム3：1多重化セグメントベース、コントローラー内蔵の白黒グラフィックLCD、白黒マイクロコントローラの汎用DMA（4レベルのグレースケールを提供）とインターフェイスするためのCPLDベースのコントローラを独自に設計した白色LCD。私はディスプレイをジッピーにすることに誇りを持っています。グラフィックコントローラーの1つは、一定のデータを書き込む場合でも、全画面更新に約1/10秒を必要とするちょっとした犬でしたが、ほとんどのディスプレイでは、1/50秒未満でかなり複雑な画像をレンダリングできます。
私がやるプロジェクトの多くはバッテリー駆動であるため、消費電流が問題になります。私がやったDMAベースのディスプレイコントローラーはうまくいきましたが、それはライン駆動のプロジェクト用でした。グラフィックLCDから妥当な電流を引き出す唯一の方法は、ディスプレイバッファーと列ドライバーを組み合わせたコントローラーを使用することだと思います。チップ間で多くのディスプレイをフレームごとに送信すると、1ビットあたり1ビットのディスプレイでも多くのエネルギーが無駄になります。ピクセルあたり16ビットのカラーディスプレイでは、さらに悪化します。
私はカラーLCDのデータシートを見始めたばかりです。多くのディスプレイはILITEK ILI9320に似たコントローラーを使用しているように見えますが、その一般的な設計に基づいたコントローラー用のデータシートはすべて「予備」とマークされています。ILITEKのようなものの中には、マスキングと透過性の機能があると主張するものもありますが、それらのレジスタはリストしません。実際のチップにそのような機能があるが、「予備の」データシートにそれらの機能が含まれていないのか、機能を省いて言及するのを忘れたのかはわかりません。実際にそのようなすべてのチップに透過機能がある場合、それらのために設計することは理にかなっているようです; そうでない場合、そうではありません。
ほとんどのプロジェクトでは、通常の画面は中程度の数の任意サイズの単色フォントで任意に配置されたテキストで構成されると予想されます。フォントは、おそらくピクセルごとのビットデータとして保存されます。Cortex-M3を使用して、並列データでディスプレイを作成する場合、2つのピクセルを書き込むコードの「内部ループ」は、おそらく次のようになります。
rol r0、r0、＃2; Cで1ビット、Nでもう1ビットを取得 itcs strhcs r1、[r3、＃DATA_OFS]; データを書き込む strhcc r2、[r3、＃DATA_OFS]; データを書き込む strb r4、[r3、＃CLOCK_SET_OFS]; クロックを高く設定する strb r4、[r3、＃CLOCK_CLR_OFS]; クロックを低く設定 itmi strhmi r1、[r3、＃DATA_OFS]; データを書き込む strhpl r2、[r3、＃DATA_OFS]; データを書き込む strb r4、[r3、＃CLOCK_SET_OFS]; クロックを高く設定する strb r4、[r3、＃CLOCK_CLR_OFS]; クロックを低く設定
まさに世界最速というわけではありません。クロック設定/クリア命令への書き込みを削除すると役立ちます。私の推測では、両方のクロック書き込みを排除する素晴らしいアーキテクチャに依存しない方法はありませんが、1つを排除することを可能にするかなり一般的な方法があるかもしれません単一のメモリストア操作に応じて短時間）。
SPIポートを使用し、ビットあたり1ピクセルをクロックするハードウェアを追加すると、ディスプレイアクセスが大幅に高速化されます。マスクと透明度なしでディスプレイを使用する場合、CPLDはアドレスカウンターを含める必要があり、各ピクセルに対してピクセルデータのワードをクロックするか、次のピクセルの位置のアドレス設定コマンド（カウンターが必要） ）。対照的に、ディスプレイにマスキングと透明度がある場合、CPLDに16ビットでクロックを供給した後、追加ビットごとに1ワードのデータをディスプレイに出力するモードをサポートする必要がありますLSBはSDIピンを追跡します（CPLDを使用する必要はないかもしれません-ほんの数個の通常のロジックチップ）。透明度の色を、LSBを反転させて書きたい色に設定します。
マスキングと透明度に依存する美しいデザインを思いつき、そのような機能を備えたディスプレイのみが30週間のリードタイムを持っていることを発見したくありません。一方、そのようなディスプレイが多くのベンダーから入手可能であり、広く利用されている場合は、可用性についての妄想に劣ったデザインを使用させられたくありません。
