フォトポリマーLCD3Dプリンター用のDIYファームウェア。パート1

...または自分の好みに合った好みと芸者を使って自分の自転車を発明した方法-フォトポリマープリンターのファームウェアを最初から作成しました。現時点では、ファームウェアはすでに完全に機能しています。



Agilentで販売されているMKSDLPボードを基準として、メーカーが回路とファームウェアのソースコードを提供しましたが、すべてを最初から作成することを支持して拒否しました。

記事が非常に長いことが判明したので、2つの部分に分割することにしました。このパートでは、タッチスクリーン用の自家製GUIの背景と説明があります。最後に、いじめ自体の主題とGitHubリポジトリへのリンクがあります。





-パート1： 1。ユーザーインターフェイス。

-パート2： 2.USBフラッシュドライブ上のファイルシステムの操作。3.プラットフォーム移動用のステッパーモーター制御。

-パート3： 4。バックライトディスプレイにレイヤーの画像を表示する。5.照明とファンの制御、設定の読み込みと保存など、あらゆる小さなこと。6.快適さと便利さのための追加機能。



理解を深めるために、フォトポリマーLCD 3Dプリンターの作業について、慣れていない人のために簡単に説明します。

バックグラウンド

どうやってこれにたどり着き、メーカーのソースコードを自分で微調整するのではなく、なぜ自分のファームウェアを書き始めたのか。





だから私たちが持っているもの：

• MKS DLPキットには、マザーボード、3.5 "480x320インターフェイスディスプレイおよび5.5" 2560x1440バックライトディスプレイが含まれます。
• メーカーからのネイティブソース
• マザーボード図（パッシブコンポーネントのアクティブ値と公称値の名前なし）

マザーボードはSTM32F407マイクロプロセッサに基づいています。バックライトディスプレイを制御するために、ボードには中国のメーカーGW1N-LV4LQ144ESのFPGA、SDRAM、および2つのSSD2828MIPIインターフェイスチップが含まれています。マイクロプロセッサはレイヤのイメージをFPGAに駆動し、FPGAはそれをSDRAMに保存し、そこからSSD2828を介して表示を更新します。ちなみに、メーカーはソースコードでFPGA構成（ファームウェア）を提供していません:(さらに、マザーボードには次のものがあります：

• 電源入力12〜24ボルト
• USB A /
• A4988
• Z —
• WiFi
• FLASH- W25Q64
• EEPROM- AT24C16

抵抗性タッチパネル付きのインターフェースディスプレイは、フラットな40ピンケーブルで接続されています。ディスプレイコントローラー-ILI9488、タッチパネルコントローラー-HR2046（TSC2046と同様）。



周辺機器を初期化するために、STM32CUBEMXプログラムを使用しました。しかし、私はそれから得られた結果を直接使用せず、必要な部分を私のソースに挿入しました。周辺機器を操作するときは、STのHALライブラリを使用し、最高速度を得る必要がある場合は、レジスタを直接操作しました。



したがって、タスクがあります。このキットは、ユーザーが簡単にフラッシュドライブからファイルを印刷できる必要があります。私はこの問題全体を大まかに主要な部分に分け、3つの出版物を作成しました。



私のコードもアプローチも、理想的であるとか、単に良いとは言えないということを、すぐに警告したいと思います。私はできる限りプレイします。私にとってのプログラミングは、職業というよりも趣味です。ですから、厳しすぎる基準で判断しないでください。

1.ユーザーインターフェイス

最初は表示の初期化でした。ここで興味深いことは何もありません。ILI9488コントローラーの標準シーケンスです。私はそれをネイティブソースから取り除いて、他のタイプのディスプレイの初期化コードを切り取りました（おそらく、これらのソースのFDMライフからそこに残っていました）。それから私はフォントを取り上げました。

1.1フォント

ネット上にはマイクロプロセッサ用のフォントライブラリがたくさんありますが、それらの大部分はモノスペースのフォントで動作し、私はそれがあまり好きではありません。これは、文字「z」のように、すべての文字の幅が文字「i」と同じである場合です。私はかつて私のペットプロジェクトの1つに比例フォントライブラリを作成しました。フォントごとに2つの配列を使用します。文字自体のビットデータを含む配列と、各文字の幅を含む配列です。そして、フォントパラメータを持つ小さな構造-配列へのポインタ、フォントの高さ、フォントの文字数：

typedef struct
{
	uint16_t	*width;
	uint8_t		*data;
	uint8_t		height;
	uint16_t	symcount;
} LCDUI_FONT;

このようなフォント構成は、モノスペースのビットマップよりも多くのメモリスペースを使用する必要があるように思われますが、これは完全に正しいわけではありません。まず、モノスペース自体が保存データの余剰を引き起こします。たとえば、高さ8ピクセルと幅5ピクセルのフォントで、文字「i」に1バイト（幅1ビットと高さ8ビット）で十分な場合でも、5バイトのデータ（幅5ビットと高さ8ビット）が必要です。以来幅は固定されています。次に、原則として、このようなフォントでは、データの編成方法に応じて、各行または各列のバイト境界で位置合わせが行われます。



たとえば、同じ5x8フォントを使用します。ビットデータが1行ずつ保存されている場合、各行に3ビットが超過しています。または1文字あたり3バイト：







または、列にデータを格納する7x12フォントの場合、列あたり4ビットまたは文字あたり3.5バイトの過剰なデータがあります







。私のライブラリでは、ビットデータは文字に対して連続しており、バイト境界での配置は文字の末尾のみです。



さらに、保存されているフォントサイズをわずかに小さくすることができるもう1つの小さなトリックがあります。文字にはビットデータがない場合がありますが、同じスタイルの別の文字を参照します。たとえば、キリル文字「A」、「B」、「E」、「K」などです。同じスタイルのラテン文字への参照を持つことができます。これは、文字幅の配列内の対応する文字の幅に負の値を指定することによって行われます。そこに負の値がある場合、この文字の画像は位置（幅* -1）の文字から取得されます。



配列内の文字を見つける手順は次のとおりです。

uint8_t*	_lcdui_GetCharData(char c)
{
	if (c < 32)
		return 0;
	if (c > 126)
		c -= 65;
	c -= 32;
	if (c >= lcdui_current_font->symcount)
		return 0;
	uint16_t c1 = lcdui_current_font->width[c];
	if (c1 & 0x8000)
		c = (c1 & 0x7FFF);
	uint16_t ch = lcdui_current_font->height;
	int32_t i = 0, ptr = 0, bits = 0, line_bits = ch;
	for (i = 0; i < c; i++)
	{
		if (lcdui_current_font->width[i] & 0x8000)
			continue;
		bits = lcdui_current_font->width[i] * line_bits;
		ptr += bits >> 3;
		if (bits & 0x07)
			ptr++;
	}

	return &(lcdui_current_font->data[ptr]);
}

これらすべてにより、フォントのデータ量が増えることさえあります。言うまでもなく、プロポーショナルタイプはより自然に見えます。



このようなフォントのレンダリング速度は、ウィンドウ出力のためにかなりまともです。ディスプレイには、最初に出力ウィンドウを目的の位置にある文字のサイズに制限するコマンドが与えられ、次に文字全体のデータが1つのストリームに注ぎ込まれます。ピクセルごとに個別に座標を設定する必要はありません。



たとえば、下の写真では、青いテキストと上の白い線は私のライブラリによってレンダリングされ、白い下の線はネイティブソースの標準のarduinoのようなライブラリ







によってレンダリングされました。青いテキストは下の白い線よりも数倍速くレンダリングされました。



同時に、画像からプログラムですぐに使用できるフォント配列を作成するためのユーティリティを発明する必要がありました。 Photoshopでは、フォントのすべての文字を使用して目的の高さの画像を作成し、各文字の最後の列のX座標を手動でテキストファイルに入力してから、画像とこのテキストファイルにユーティリティを設定します。これにより、必要な配列を含む.cファイルが作成されます。もちろん、少し面倒ですが、単純です。



テキストを表示する手順は、画面の最後にある新しい行にテキストを折り返すか、または遭遇した改行文字によってテキストを折り返すことができ、左、右、中央に揃えて、テキストが移動しない領域を制限することができます（切り取られます）。また、背景塗装や背景保存でシンボルを表示することができます。2番目のオプションは、1つのストリームで文字データをディスプレイに入力することができなくなったため、動作が遅くなりますが、3〜4行の出力が目に見えないほど高速です。

1.2インターフェース画像の表示

ユーザーインターフェイスでは、背景、アイコン、ボタンなどの画像を表示する必要があります。最初は、あまり気にせず、すべての画像を.bmp形式でボード上の8MBのフラッシュメモリに保存することにしました。そして、私もこのための手順を書きました。ファイルは16ビット形式（R5 G6 B5）でエンドツーエンドまたはエンドツーエンドの行順で保存され、すでにレンダリングルーチンに直接供給されている場合があります。ただし、480x320の背景画像のサイズは300KBを超えています。このフラッシュメモリの一部がファームウェアアップデート専用になることを考慮すると、30個の背景画像がすべてのメモリを占有します。たくさんあるように見えますが、念のため、私が望んでいるよりもまだ少ないです。ただし、ボタンやアイコンなども必要です。そのため、画像を何らかの圧縮形式に変換することにしました。



圧縮には多くのオプションはありません。画像を多かれ少なかれうまく圧縮するすべてのアルゴリズムは、適切なRAM（マイクロシステムの標準による）または適切な解凍時間のいずれかを必要とします。一方、画像はその場でクランチを解除して表示する必要があり、表示するときの画像はクロールの進行状況バーに似ていないことが望ましいです。したがって、私はRLE圧縮に決めました-1バイトは繰り返しの数をエンコードし、それに続く2つは色をエンコードします。このために、.bmpファイルをこの方法で圧縮された画像に変換するユーティリティも作成されました。ヘッダーは4バイトのみで構成されます-画像の幅と高さは2バイトです。平均して、背景画像はこの方法で5〜7倍圧縮され、モノクロ領域のサイズに強く依存します（これは予想されることです）。たとえば、このような画像は元の307KBから74KBに縮小されました。







しかし、これは-同じ307から最大23 KB：





ちなみに、私のデザイナーはプログラマーよりもさらにくだらないです...



私はこの結果に満足しました。画像のデコードと表示は非常に高速です。フルバックグラウンド画像あたり約40ミリ秒です。それで私はこのオプションに決めました。



ちなみに、ディスプレイにデータを出力するためにDMAモードに切り替えても、出力の加速はほとんどありませんでした。ディスプレイは外部メモリとして外部16ビットデータバスを介して接続されていますが、そのタイミングはかなり悲しいため、手動ピクセル出力に対するDMA出力の利点はほとんど無効になっています。

1.3GUIフレームワーク

テキストが表示され、絵が描かれます。次に、ユーザーインターフェイスの基盤がどのように編成されるかを考えます。



タッチパネルを使用すると、すべてが簡単になります。マイクロコンピュータは常にタッチパネルコントローラに割り込みをポーリングし、最後に取得した4つの結果を平均して、表示座標に変換します。したがって、センサーの状態は、押されているかどうか、押されている場合はどこにあるかなど、いつでもわかります。タッチパネルとプログラムの主要部分の間のもう1つの層は、ボタンのクリックを処理するための手順です。これは、かなり長い間、特定の条件に少し適応してプロジェクトからプロジェクトへとさまよっています。





タッチパネルは唯一のインターフェースボタンとして機能し、それを押すという事実に加えて、クリックの座標も分析されます。



ここで、さまざまなインターフェイス要素を画面に表示できるようにするためにすべてを行う必要があります。これは、クリックに反応する場合と反応しない場合、イベントによって更新される場合、サイズや画像が異なる場合などです。



最終的に、私はこのスキームにたどり着きました。インターフェイスは、画面とボタンの2つの主要なタイプの要素で構成されています。



画面は、ボタンのフルスクリーンコンテナの一種です。画面には次のプロパティがあります。

• 背景画像
• 背景色
• 背景を描く方法-背景色で塗りつぶすか、画像を表示する
• ヘッダーテキスト
• タイトルテキストの色
• ヘッダーテキストフォント
• 親画面へのポインタ（これを閉じるときに戻る）
• ボタンへのポインタの配列
• イベントプロシージャへのポインタ（メインプログラムループで定期的に呼び出されます）
• 画面描画ルーチンへのポインタ

実際、ボタンはボタンだけでなく、テキスト、アイコン、カウンターや時計などのある種の変化する要素でもかまいません。すべてを1つのタイプに組み合わせ、そのプロパティを使用して特定の各ボタンの動作を設定すると便利であることがわかりました。



ボタンのプロパティ：

• 画面上の座標
• 背景色
• 自由状態の背景画像
• 押された状態の背景画像
• 無効状態の背景画像
• アクティブ状態の背景画像（たとえば、ラジオボタングループのアクティブな要素の場合）
• レンダリング方法-画像または背景色
• 押したり離したりしたときにボタンを再描画するかどうか
• ボタンのテキスト
• ( )
• (, )
• ( )
• ,
• ,

この一連のプロパティの助けを借りて、そのような要素に基づいてインターフェイスにほとんどすべてのものを作成することが可能になりました。画面またはボタンにいずれかのプロシージャnullへのポインタがある場合、対応する標準プロシージャが呼び出されます。たとえば、ボタンを押したときのプロシージャポインタの代わりに、子画面または前の画面に移動する必要があることを示す特別な識別子があり、標準のプロシージャがそれを実行します。一般に、標準の手順は通常のボタンを使用するほとんどすべてのケースをカバーし、ボタンが時計のように機能する場合やファイルリストの要素として機能する場合など、非標準の場合にのみボタンの独自の手順を作成する必要があります。



しかし、このスキームの機能に欠けていたのは、メッセージや質問のあるモーダルウィンドウ（Windows APIのMessageBoxなど）であったため、別のタイプの画面を作成しました。背景画像はなく、タイトルまたはメッセージ自体によってサイズが決まります。これらのメッセージは、「はい/いいえ」ボタン、「OK /キャンセル」ボタン、1つの「OK」ボタン、またはボタンなし（「待機、データがロードされています...」など）の4つのバージョンで作成できます。









インターフェイス全体が構築されたのは、これら3つのタイプに基づいており、非常に柔軟であることがわかりました。現在、すべての要素の初期化はファームウェアで厳密に実行されますが、構成ファイル内のすべての要素のプロパティを記述し、必要な画像をいくつか追加することで、ユーザーが独自のインターフェイスを作成できるようにするというアイデアがあります。理論的には、メイン画面に配置するボタン、サービス画面に配置するボタンなど、さまざまな画面の内容に合わせて変更することが可能です。

1.4多言語

多言語主義は当初の課題でした。しかし、最初はばかげた道をたどりました。すべての要素を初期化するときに、現在の言語テーブルからテキストを割り当てました。言語を切り替えるということは、すべてのテキスト要素を再初期化することを意味し、インターフェイスに2つ以上の画面があり、20を超えるボタンとラベルがあると、私はもはやこのように生きることができないことに気付きました。それから彼は手順を通してテキストへのすべての参照をしました。プロシージャにはパラメータとしてテキスト識別子が与えられ、現在の言語のテキストへのポインタを返します。

	char *mshortname = LANG_GetString(LSTR_SHORT_JANUARY);

言語を変更すると、ポインタは単に古い言語のテキストの配列から新しい言語のテキストの配列に変わります。

void		LANG_SetLanguage(uint8_t lang)
{
	lngCurrent = lngLanguages[lang].strings;
	
	return;
}

すべてのソーステキストはUTF-8エンコーディングです。また、これらのエンコーディングをいじくり回さなければなりませんでした。テキスト-UTF-8、キリルファイル-Unicode-16、一部の文字列-通常のANSI。マルチバイトエンコーディングをサポートするためにライブラリのセット全体をファームウェアにプルしたくなかったので、エンコーディングからエンコーディングへの変換や、Unicode16文字列の末尾にUTF-8文字列を追加するなど、異なるエンコーディングのテキストを操作するためのいくつかの関数が作成されました。

新しい言語の追加は、その中にテキストのテーブルを作成し、定数LNG_LANGS_COUNTの値を変更することになりました。確かに、新しい言語でCyrillicとLatin以外の記号が使用されている場合、フォントには疑問が残ります。現在、ソースコードでロシア語とGoogleで翻訳された英語をサポートしています。

1.5画像やその他のリソースの保存

大きなリソースを格納するために、ボードには8メガバイトのSPIフラッシュW25Q64があります。最初は、いつものようにやりたかったのです。フラッシュ内の各リソースにオフセットを設定し、バイナリデータとして保存します。しかし、保存されたリソースの数が数十を超えるとすぐに、この方法の問題が保証されることに気付きました。たとえば、6番目に保存された画像を順番に変更したいと思います。サイズが大きくなると、以下のすべてのリソースのアドレスをシフトして書き直す必要があります。または、各リソースの後にサイズが不明なスペアスペースを残します。リソースがどのように変更されるかを知っている人です。はい、棺桶の中で私はこの騒ぎを見ました:)それで、私はこのフラッシュでファイルシステムを吐き出して整理しました。その時までに、私はすでにFatFSライブラリに基づくUSBファイルシステムを持っていたので、セクターごとに別々の低レベルの読み取り/書き込み関数を書くだけで十分でした。私を少し動揺させたのは1つだけです。このマイクロ回路の消去されたセクターのサイズは、すでに4KBにもなっています。これは、最初にファイルが4 KBの部分でスペースを占めるという事実につながります（ファイルは200バイトを書き込みました-それは4 KBのフラッシュを要しました）、そして次に、各ファイルポインターの構造のバッファーは同じ4KBのRAMを消費しますマイクロプロセッサはそれほど多くありません-192KB。もちろん、変質して低レベルの関数を書き込んで、たとえば512バイトなどのセクターサイズを報告して、より小さな部分で読み書きできるようにすることもできます。ただし、Flashの速度が低下するため、セクターサイズは4KBのままになります。そのため、ファイル名だけでどのリソースにもアクセスでき、非常に便利であることがわかりました。たとえば、現時点では、保存されているリソースの数はすでに90を超えています。そして、更新をできるだけ簡単にしました。更新された（または新しい）リソースが特定のディレクトリのUSBフラッシュドライブに書き込まれ、フラッシュドライブがボードに挿入され、ボードがサービスモードで再起動されます（電源を入れるか再起動し、ディスプレイの右上隅を押し続けます）、このディレクトリにあるすべてのファイルをUSBフラッシュドライブからSPIフラッシュに自動的にコピーします。ボードはサービスモードで再起動し（電源投入時または再起動時に、ディスプレイの右上隅を押し続けます）、このディレクトリにあるすべてのファイルをUSBフラッシュドライブからSPIフラッシュに自動的にコピーします。ボードはサービスモードで再起動し（電源投入時または再起動時に、ディスプレイの右上隅を押し続けます）、このディレクトリにあるすべてのファイルをUSBフラッシュドライブからSPIフラッシュに自動的にコピーします。

つづく...

おそらく、最もボリュームのある部分がインターフェイスに出てきました。この記事がコミュニティにとって興味深いものであることが判明した場合は、第2部で、他のすべてに対応しようとします。



さて、質問やコメントをいただければ幸いです。



-パート1： 1。ユーザーインターフェイス。

-パート2： 2.USBフラッシュドライブ上のファイルシステムの操作。3.プラットフォーム移動用のステッパーモーター制御。

-パート3： 4。バックライトディスプレイにレイヤーの画像を表示する。5.照明とファンの制御、設定の読み込みと保存など、あらゆる小さなこと。6.快適さと便利さのための追加機能。

リンク

MKSDLPキットのAliexpressGitHub

のメーカーからの元のファームウェアソースGitHub

のボードの2つのバージョンのメーカーからのスキームGitHubの

私のソース