Firmware DIY untuk printer LCD 3D photopolymer. Bagian 1

... atau bagaimana saya menemukan sepeda saya sendiri dengan preferensi dan geisha sesuai selera saya - saya menulis firmware untuk printer photopolymer dari awal. Saat ini, firmware sudah berfungsi penuh.



Papan MKS DLP yang dijual di Aliexpress diambil sebagai dasar, di mana pabrikan menyediakan kode sumber sirkuit dan firmware, yang saya tolak untuk menulis semuanya dari awal.

Artikel itu ternyata sangat panjang, jadi saya memutuskan untuk membaginya menjadi dua bagian. Pada bagian ini akan terdapat background dan deskripsi GUI bikinan untuk sebuah layar sentuh. Pada akhirnya akan ada tautan ke subjek penindasan itu sendiri dan ke repositori GitHub.





- Bagian 1: 1. Antarmuka pengguna.

- Bagian 2: 2. Bekerja dengan sistem file pada USB flash drive. 3. Kontrol motor stepper untuk gerakan platform.

- Bagian 3: 4. Menampilkan gambar lapisan pada tampilan lampu latar. 5. Setiap hal kecil, seperti mengontrol pencahayaan dan kipas, pengaturan pemuatan dan penyimpanan, dll. 6. Fitur tambahan untuk kenyamanan dan kemudahan.



Untuk pemahaman yang lebih baik, saya akan memberikan uraian singkat tentang pekerjaan printer 3D LCD photopolymer bagi mereka yang belum terbiasa dengannya:

Latar Belakang

Bagaimana saya sampai pada hal ini dan mengapa saya mulai menulis firmware saya sendiri alih-alih hanya mengubah kode sumber dari pabrikan untuk diri saya sendiri.





Jadi apa yang kami miliki:

• Kit MKS DLP, yang meliputi: motherboard, layar antarmuka 3,5 "480x320 dan layar lampu latar 2560x1440 5,5"
• sumber asli dari pabrikan
• diagram motherboard (tanpa nama nilai aktif dan nominal komponen pasif)

Motherboard ini didasarkan pada mikrokontroler STM32F407. Untuk mengontrol tampilan lampu latar , papan berisi FPGA dari pabrikan Cina GW1N-LV4LQ144ES, SDRAM dan dua chip antarmuka MIPI SSD2828. Mikrokontroler menggerakkan gambar lapisan ke dalam FPGA, FPGA menyimpannya di SDRAM dan dari sana menyegarkan tampilan melalui SSD2828. Pabrikan, omong-omong, tidak menyediakan konfigurasi FPGA (firmware) dalam kode sumber: (Selain itu, motherboard memiliki:

• masukan daya 12-24 volt
• USB A /
• A4988
• Z —
• WiFi
• FLASH- W25Q64
• EEPROM- AT24C16

Tampilan antarmuka dengan panel sentuh resistif dihubungkan dengan kabel datar 40-pin. Pengontrol tampilan - ILI9488, pengontrol panel sentuh - HR2046 (analog dari TSC2046).



Untuk menginisialisasi periferal, saya menggunakan program STM32CUBE MX. Tetapi saya tidak menggunakan hasil yang diperoleh darinya secara langsung, tetapi memasukkan potongan-potongan yang diperlukan ke dalam sumber saya. Saat bekerja dengan periferal, saya menggunakan perpustakaan HAL dari ST, dan di mana saya perlu mendapatkan kecepatan maksimum, saya bekerja dengan register secara langsung.



Jadi, ada tugas - kit ini harus dapat mencetak file dari flash drive dengan mudah bagi pengguna. Saya membagi seluruh masalah ini secara kasar menjadi beberapa bagian utama, yang menghasilkan tiga publikasi.



Saya ingin segera memperingatkan Anda bahwa baik kode saya maupun pendekatan saya sama sekali tidak berpura-pura menjadi ideal atau bahkan hanya bagus, saya bermain sebisa saya. Pemrograman bagi saya lebih merupakan hobi daripada profesi. Jadi tolong jangan menilai dengan standar yang terlalu ketat.

1. Antarmuka pengguna

Pertama adalah inisialisasi tampilan. Tidak ada yang menarik di sini, urutan standar untuk kontroler ILI9488. Saya merobeknya dari sumber asli, memotong kode inisialisasi untuk jenis tampilan lain (yang, mungkin, tetap ada di sana dari kehidupan FDM sumber-sumber ini). Lalu saya masuk ke font.

1.1 Font

Ada banyak pustaka font untuk mikrokontroler di internet, tetapi sebagian besar dari mereka bekerja dengan font monospace, dan saya tidak terlalu menyukainya. Ini terjadi ketika semua karakter memiliki lebar yang sama, seperti huruf "z", dengan huruf "i". Saya pernah menulis perpustakaan font proporsional untuk salah satu proyek hewan peliharaan saya. Ini menggunakan dua array untuk setiap font - array dengan data bit dari karakter itu sendiri dan array dengan lebar setiap karakter. Dan struktur kecil dengan parameter font - pointer ke array, tinggi font, jumlah karakter dalam font:

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

Tampaknya organisasi font semacam itu harus menggunakan lebih banyak ruang memori daripada hanya bitmap monospace, tetapi ini tidak sepenuhnya benar. Pertama, monospace itu sendiri menimbulkan surplus data yang disimpan. Misalnya, jika dalam font dengan tinggi 8 piksel dan lebar 5 piksel, 1 byte (lebar 1 bit dan tinggi 8 bit) sudah cukup untuk huruf "i", maka masih akan membutuhkan 5 byte data (lebar 5 bit dan tinggi 8 bit), sejak lebarnya tetap. Kedua, sebagai aturan, dalam font seperti itu, penyelarasan dilakukan pada batas byte setiap baris atau setiap kolom, tergantung pada bagaimana data diatur.



Misalnya, ambil font 5x8 yang sama. Jika bit data disimpan baris demi baris, maka ada kelebihan 3 bit untuk setiap baris. Atau 3 byte per karakter:







Atau font 7x12 dengan penyimpanan data di kolom, maka ada kelebihan 4 bit per kolom atau 3,5 byte per karakter:







Di perpustakaan saya, data bit kontinu untuk karakter dan penyelarasan pada batas byte hanya di akhir karakter.



Ditambah ada satu lagi trik kecil yang memungkinkan Anda untuk sedikit mengurangi ukuran font yang disimpan: karakter mungkin tidak memiliki data bit, tetapi merujuk ke karakter lain dengan gaya yang sama. Misalnya, huruf Sirilik "A", "B", "E", "K", dll. dapat memiliki referensi ke huruf latin dengan gaya yang sama. Ini dilakukan dengan menentukan nilai negatif untuk lebar karakter yang sesuai dalam larik lebar karakter. Jika ada nilai negatif di sana, maka gambar karakter ini diambil dari karakter pada posisi (lebar * -1).



Berikut adalah prosedur untuk menemukan karakter dalam sebuah array:

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]);
}

Semua ini bahkan sering memberi keuntungan dalam jumlah data untuk font. Belum lagi, tipe proporsional terlihat lebih natural.



Kecepatan rendering font semacam itu cukup baik karena output berjendela - tampilan pertama-tama diberi perintah untuk membatasi jendela output ke ukuran karakter di posisi yang diinginkan, dan kemudian data dari seluruh karakter dituangkan ke dalamnya dalam satu aliran. Tidak perlu mengatur koordinat secara terpisah untuk setiap piksel.



Misalnya, pada foto di bawah, teks biru dan garis putih atas dirender oleh perpustakaan saya, dan bagian bawah putih - oleh perpustakaan seperti arduino standar dari sumber asli:







Teks biru dirender beberapa kali lebih cepat daripada garis putih bawah.



Pada saat yang sama, saya harus menemukan utilitas untuk membuat array font yang siap digunakan dalam program dari sebuah gambar. Di Photoshop, gambar dengan ketinggian yang diinginkan dibuat dengan semua karakter font, kemudian koordinat X dari kolom terakhir setiap karakter dimasukkan ke dalam file teks dengan tangan, dan kemudian utilitas diatur pada gambar dan file teks ini. Ini membuat file .c dengan array yang diperlukan. Agak membosankan, tentu saja, tapi sederhana.



Prosedur untuk menampilkan teks dapat membungkus teks ke baris baru di ujung layar atau sesuai dengan karakter feed baris yang ditemui, dapat meratakan ke kiri, kanan dan tengah, membatasi area yang tidak akan dilewati teks (akan terpotong). Dan itu mampu menampilkan simbol dengan lukisan latar belakang atau pelestarian latar belakang. Opsi kedua bekerja lebih lambat, karena tidak lagi mungkin untuk mengisi data karakter ke dalam tampilan dalam satu aliran, tetapi masih cukup cepat sehingga keluaran dari 3-4 garis tidak terlihat oleh mata.

1.2 Menampilkan gambar antarmuka

Untuk antarmuka pengguna, Anda perlu menampilkan gambar - latar belakang, ikon, tombol. Pada awalnya, saya memutuskan untuk tidak terlalu repot dan menyimpan semua gambar dalam format .bmp dalam memori flash 8MB yang tersedia di papan tulis. Dan saya bahkan menulis prosedur untuk ini. File disimpan dalam format 16-bit (R5 G6 B5) dengan urutan baris ujung-ke-ujung atau ujung-ke-ujung, dan mungkin sudah langsung diumpankan ke rutin rendering. Tetapi ukuran gambar latar 480x320 lebih dari 300 KB. Mengingat sebagian dari memori flash ini akan didedikasikan untuk pembaruan firmware, 30 gambar latar belakang akan menggunakan semua memori. Sepertinya banyak, tapi masih kurang dari yang saya inginkan, untuk berjaga-jaga. Tetapi juga harus ada tombol, ikon, dll. Oleh karena itu, diputuskan untuk mengonversi gambar ke beberapa jenis format terkompresi.



Tidak banyak opsi dengan kompresi - semua algoritme yang memampatkan gambar kurang lebih membutuhkan RAM yang layak (menurut standar mikrokontroler) atau waktu yang cukup untuk mendekompresi. Gambar, di sisi lain, harus ditampilkan, dilepaskan dengan cepat, dan sebaiknya gambar saat ditampilkan tidak menyerupai bilah kemajuan perayapan. Oleh karena itu, saya menetapkan kompresi RLE - 1 byte mengkodekan jumlah pengulangan, dan dua mengikutinya - warnanya. Untuk ini, sebuah utilitas juga ditulis yang mengubah file .bmp menjadi gambar yang dikompresi dengan cara ini. Header hanya terdiri dari 4 byte - 2 byte untuk lebar dan tinggi gambar. Rata-rata, gambar latar belakang dikompresi dengan cara ini 5-7 kali, sangat bergantung pada ukuran area monokrom (yang diharapkan). Misalnya, gambar seperti ini menyusut dari aslinya 307 KB menjadi 74 KB:







Tapi yang ini - hingga 23 KB dari 307 yang sama:





Ngomong-ngomong, perancang saya bahkan lebih buruk daripada programmer ...



Saya puas dengan hasil ini. Mendekode dan menampilkan gambar sangat cepat - sekitar 40 milidetik per gambar latar belakang penuh. Jadi saya memilih opsi ini.



Dan omong-omong, beralih ke mode DMA untuk mengeluarkan data ke tampilan tidak memberikan hampir semua percepatan keluaran. Layar ini dihubungkan melalui bus data 16-bit eksternal sebagai memori eksternal, tetapi pengaturan waktunya agak menyedihkan, yang hampir meniadakan keuntungan keluaran DMA dibandingkan keluaran piksel manual.

1.3 Kerangka GUI

Teks ditampilkan, gambar digambar, sekarang saatnya memikirkan bagaimana dasar antarmuka pengguna akan diatur.



Dengan panel sentuh, semuanya sederhana - mikrokontroler secara konstan mengumpulkan pengontrol panel sentuh dengan menyela dan rata-rata dari 4 hasil terakhir yang diperoleh, menerjemahkannya ke dalam koordinat tampilan. Dengan demikian, keadaan sensor dapat diketahui setiap saat - apakah ditekan atau tidak, dan jika ditekan, maka di tempat mana. Lapisan lain antara panel sentuh dan bagian utama program adalah prosedur untuk memproses klik tombol, yang telah berpindah-pindah dari proyek ke proyek dengan sedikit adaptasi untuk kondisi tertentu selama beberapa waktu.





Panel sentuh berfungsi sebagai satu-satunya tombol antarmuka, hanya saja selain menekannya, koordinat klik juga dianalisis.



Sekarang semuanya perlu dilakukan agar berbagai macam elemen antarmuka dapat ditampilkan di layar, yang mungkin atau mungkin tidak bereaksi terhadap klik, diperbarui berdasarkan peristiwa, memiliki ukuran dan gambar yang berbeda, dll.



Akhirnya, saya sampai pada skema ini: antarmuka terdiri dari dua jenis elemen utama - layar dan tombol.



Layar adalah semacam wadah layar penuh untuk tombol. Layar memiliki properti berikut:

• gambar latar belakang
• warna latar belakang
• cara menggambar latar belakang - mengisi dengan warna latar belakang atau menampilkan gambar
• teks header
• warna teks judul
• font teks header
• penunjuk ke layar induk (yang akan dikembalikan saat menutup ini)
• serangkaian penunjuk ke tombol
• penunjuk ke prosedur acara (disebut secara berkala di loop program utama)
• penunjuk ke rutinitas menggambar layar

Tombol sebenarnya bukan hanya tombol, tetapi juga teks, ikon, semacam elemen yang berubah seperti penghitung atau jam. Ternyata mudah untuk menggabungkan semuanya dalam satu jenis, dan mengatur perilaku setiap tombol tertentu melalui propertinya.



Properti tombol:

• koordinat di layar
• warna latar belakang
• gambar latar belakang untuk keadaan bebas
• gambar latar belakang untuk keadaan ditekan
• gambar latar belakang untuk keadaan dinonaktifkan
• gambar latar belakang untuk keadaan aktif (untuk elemen aktif dari grup tombol radio, misalnya)
• metode rendering - gambar atau warna latar belakang
• Apakah akan menggambar ulang tombol saat ditekan dan dilepaskan
• teks tombol
• ( )
• (, )
• ( )
• ,
• ,

Dengan bantuan set properti ini, menjadi mungkin untuk membuat hampir semua hal di antarmuka berdasarkan elemen seperti itu. Jika layar atau tombol memiliki penunjuk ke salah satu prosedur nol, maka prosedur standar terkait dipanggil. Alih-alih penunjuk prosedur saat menekan tombol, misalnya, mungkin ada pengenal khusus yang menunjukkan bahwa Anda perlu pergi ke layar anak atau sebelumnya, maka prosedur standar akan melakukannya. Secara umum, prosedur standar mencakup hampir semua kasus penggunaan tombol biasa dan Anda harus membuat prosedur Anda sendiri untuk tombol hanya dalam kasus non-standar - misalnya, ketika tombol berfungsi seperti jam, atau sebagai elemen daftar file.



Tetapi apa yang kurang dari kemampuan skema ini adalah untuk jendela modal dengan pesan atau pertanyaan (seperti MessageBox di Windows API), jadi saya membuat jenis layar terpisah untuk mereka. Tidak ada gambar latar belakang dan ukurannya ditentukan oleh judul atau pesan itu sendiri. Pesan-pesan ini dapat dibuat dalam empat versi - dengan tombol "Ya / Tidak", dengan tombol "OK / Batal", dengan satu tombol "OK", atau tanpa tombol sama sekali (seperti "Tunggu, data sedang dimuat ...").









Atas dasar ketiga jenis inilah seluruh antarmuka dibangun, ternyata cukup fleksibel. Sekarang inisialisasi semua elemen dilakukan secara kaku di firmware, tetapi ada ide untuk memberi pengguna kesempatan untuk membuat antarmuka mereka sendiri dengan menjelaskan properti dari semua elemen dalam file konfigurasi dan menambahkan sejumlah gambar yang diperlukan. Secara teori, dimungkinkan untuk mengubah konten layar yang berbeda - tombol mana yang akan diletakkan di layar utama, tombol mana yang ke layar layanan, dll.

1.4 Multibahasa

Multilingualisme adalah tugas awalnya. Tetapi pada awalnya saya mengambil jalan yang bodoh - ketika menginisialisasi semua elemen, saya menugaskan mereka teks dari tabel bahasa yang saat ini. Mengganti bahasa berarti menginisialisasi ulang semua elemen teks, dan ketika ada lebih dari dua layar di antarmuka, dan lebih dari 20 tombol dan label, saya menyadari bahwa saya tidak dapat hidup seperti ini lebih lama lagi. Kemudian dia membuat semua referensi ke teks melalui prosedur. Prosedur ini diberi pengenal teks sebagai parameter, dan mengembalikan penunjuk ke teks dalam bahasa saat ini:

	char *mshortname = LANG_GetString(LSTR_SHORT_JANUARY);

Saat mengubah bahasa, penunjuk hanya berubah dari larik teks dalam bahasa lama menjadi larik dengan teks dalam bahasa baru:

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

Semua teks sumber dalam pengkodean UTF-8. Saya juga harus mengutak-atik pengkodean ini. Teks - dalam UTF-8, file Sirilik - di Unicode-16, beberapa string - dalam ANSI biasa. Saya tidak ingin menarik ke firmware seluruh rangkaian pustaka untuk mendukung pengkodean multibyte, jadi beberapa fungsi ditulis untuk mengubah dari pengkodean menjadi pengkodean dan untuk operasi dengan teks dalam pengkodean yang berbeda, misalnya, menambahkan string UTF-8 ke akhir string Unicode16.

Menambahkan bahasa baru sekarang bermuara pada membuat tabel teks di dalamnya dan mengubah nilai konstanta LNG_LANGS_COUNT. Benar, masih ada pertanyaan dengan font, jika bahasa baru menggunakan simbol selain Cyrillic dan Latin ... Sekarang saya mendukung bahasa Inggris yang diterjemahkan Rusia dan Google dalam kode sumber.

1.5 Menyimpan gambar dan sumber daya lainnya

Untuk menyimpan sumber daya yang besar, papan ini memiliki flash SPI 8 megabyte W25Q64. Awalnya, saya ingin melakukan seperti biasa - mengatur offset untuk setiap sumber daya di dalam flash dan menyimpannya di sana hanya sebagai data biner. Tetapi kemudian saya menyadari bahwa masalah dengan metode ini dijamin untuk saya segera setelah jumlah sumber daya yang disimpan melebihi beberapa lusin dan saya ingin mengubah, misalnya, beberapa gambar yang disimpan di urutan keenam. Jika ukurannya bertambah, Anda harus menggeser alamat dari semua sumber daya berikut dan menulis ulang. Atau tinggalkan ruang cadangan dengan ukuran yang tidak diketahui setelah setiap sumber daya - siapa yang tahu bagaimana salah satu sumber daya dapat berubah. Ya, saya melihat keributan ini di peti mati :) Jadi saya meludah dan mengatur sistem file di flash ini.Pada saat itu, saya sudah memiliki sistem file USB berdasarkan pustaka FatFS, jadi cukup bagi saya untuk menulis fungsi baca / tulis tingkat rendah yang terpisah untuk sektor. Hanya satu hal yang sedikit mengecewakan saya - ukuran sektor yang dihapus di sirkuit mikro ini sudah mencapai 4 KB. Ini pertama-tama mengarah pada fakta bahwa file akan mengambil ruang dalam porsi 4 KB (file menulis 200 byte - butuh 4 KB flash), dan kedua, buffer dalam struktur setiap penunjuk file akan memakan 4 KB RAM yang sama, yang pada mikrokontroler tidak terlalu banyak - 192 KB. Seseorang dapat, tentu saja, memutarbalikkan dan menulis fungsi tingkat rendah sehingga mereka dapat menulis dan membaca dalam porsi yang lebih kecil, melaporkan ukuran sektor, misalnya, 512 byte. Tapi itu akan memperlambat Flash, jadi ukuran sektor tetap 4 KB.Jadi sumber daya apa pun dapat diakses hanya dengan nama filenya, yang ternyata sangat nyaman. Saat ini, misalnya, jumlah sumber daya yang disimpan telah melebihi 90. Dan saya membuat pembaruannya sesederhana mungkin - sumber daya yang diperbarui (atau baru) ditulis ke flash drive USB di direktori tertentu, flash drive dimasukkan ke papan, papan di-boot ulang ke mode layanan (selama hidupkan atau boot ulang, tekan dan tahan sudut kanan atas layar) dan secara otomatis menyalin semua file yang ditemukan dalam direktori ini dari flash drive USB ke flash SPI.papan akan melakukan boot ulang ke mode layanan (selama daya hidup atau boot ulang, tekan dan tahan sudut kanan atas layar) dan secara otomatis menyalin semua file yang ditemukan dalam direktori ini dari flash drive USB ke flash SPI.papan akan melakukan boot ulang ke mode layanan (selama daya hidup atau boot ulang, tekan dan tahan sudut kanan atas layar) dan secara otomatis menyalin semua file yang ditemukan dalam direktori ini dari flash drive USB ke flash SPI.

Bersambung...

Mungkin bagian yang paling banyak keluar dari antarmuka. Jika artikel ini ternyata menarik bagi masyarakat, maka di bagian kedua saya akan mencoba mengakomodasi yang lainnya.



Baiklah, saya akan senang untuk pertanyaan dan komentar.



- Bagian 1: 1. Antarmuka pengguna.

- Bagian 2: 2. Bekerja dengan sistem file pada USB-stick. 3. Kontrol motor stepper untuk gerakan platform.

- Bagian 3: 4. Menampilkan gambar lapisan pada tampilan lampu latar. 5. Setiap hal kecil, seperti mengontrol pencahayaan dan kipas, pengaturan pemuatan dan penyimpanan, dll. 6. Fitur tambahan untuk kenyamanan dan kemudahan.

Tautan

Kit MKS DLP di Aliexpress

Sumber firmware asli dari pabrikan di

Skema GitHub dari pabrikan dua versi papan di GitHub

Sumber saya di GitHub