ESP32-S3 dapat menjalankan HMI touchscreen tanpa prosesor kelas Linux, tetapi clock CPU saja tidak menentukan apakah antarmuka terasa responsif. Ketika display memakai framebuffer besar, jalur kritisnya mencakup kapasitas memori, bandwidth PSRAM, trafik DMA, pixel format, pixel clock, dan seberapa luas bagian layar yang digambar ulang pada setiap interaksi.

ESP32-S3 menggabungkan CPU dual-core Xtensa LX7 hingga 240 MHz dengan peripheral LCD/camera, dukungan DMA, Wi-Fi, Bluetooth LE, dan opsi PSRAM eksternal. Kombinasi ini membuatnya cocok sebagai controller HMI, terutama untuk antarmuka berisi kontrol, indikator status, grafik, halaman konfigurasi, dan animasi moderat.

Batas praktis mulai terlihat ketika pixel harus dipindahkan lebih cepat daripada kemampuan sistem memori memasoknya.

Ukuran framebuffer membesar dengan cepat

Untuk framebuffer tanpa kompresi:

framebuffer bytes = width × height × bytes per pixel

Pada RGB565, setiap pixel memakai 2 byte. Framebuffer 480 × 320 membutuhkan:

480 × 320 × 2 = 307,200 bytes

Pada 800 × 480:

800 × 480 × 2 = 768,000 bytes

Double buffering menggandakan angka tersebut. Display 800 × 480 RGB565 membutuhkan sekitar 1,536 MB untuk dua framebuffer penuh, belum termasuk GUI object, font, image, buffer jaringan, application state, stack, dan alokasi lainnya.

Karena itu, modul ESP32-S3 dengan PSRAM jauh lebih leluasa untuk HMI beresolusi lebih besar. Namun, PSRAM menyelesaikan masalah kapasitas, bukan seluruh masalah bandwidth.

Panel RGB terus mengonsumsi bandwidth display

Display SPI yang memiliki display RAM sendiri dapat mempertahankan pixel setelah data dikirim. Panel RGB biasa bekerja berbeda: controller harus terus mengirim data pixel mengikuti timing panel.

Perkiraan kasar laju data pixel aktif adalah:

pixel data rate = width × height × refresh rate × bytes per pixel

Untuk 800 × 480, RGB565, dan 60 frame aktif per detik:

800 × 480 × 60 × 2 ≈ 46.1 MB/s

Perhitungan ini belum memasukkan horizontal dan vertical blanking, sehingga bukan perhitungan bus clock yang diperlukan. Angka tersebut berguna untuk menunjukkan batas bawah banyaknya data pixel aktif yang terlibat.

Pada saat yang sama, CPU dapat merender widget, menyalin draw buffer, memproses touch input, menjalankan Wi-Fi, mendekode asset, dan mengakses PSRAM. Sistem bisa memiliki memori yang cukup untuk framebuffer tetapi tetap mengalami flicker, gambar bergeser, atau redraw lambat karena beberapa consumer berebut bandwidth memori.

PSRAM mengubah lokasi bottleneck

ESP-IDF dapat menempatkan framebuffer RGB LCD di PSRAM dan menggunakan EDMA untuk mengambil data frame dari sana. Pendekatan ini menghemat internal SRAM yang terbatas dan mengurangi keterlibatan CPU selama scanout stabil.

Konsekuensinya adalah contention. Dokumentasi Espressif menjelaskan bahwa akses CPU dan EDMA dapat berbagi bandwidth PSRAM. Trafik lain, termasuk akses yang berkaitan dengan flash atau pengguna DMA tambahan, dapat membuat jalur display gagal memenuhi waktu pengiriman pada pixel clock yang cukup tinggi.

Perbedaannya penting:

kapasitas PSRAM cukup != bandwidth PSRAM cukup

Menambah kapasitas PSRAM dapat membuat framebuffer yang lebih besar muat, tetapi tidak otomatis meningkatkan kecepatan display, CPU, dan peripheral lain memindahkan data melalui jalur yang dipakai bersama.

Bounce buffer menukar tekanan memori dengan kerja CPU

ESP-IDF juga mendukung bounce buffer untuk RGB LCD. Dalam mode ini, buffer kecil ditempatkan di internal memory sementara framebuffer yang lebih besar dapat tetap berada di PSRAM. DMA membaca satu internal buffer ketika software mengisi buffer lainnya.

Susunan ini dapat lebih tahan terhadap lonjakan bandwidth singkat dibanding scan langsung dari framebuffer PSRAM dan pada konfigurasi tertentu dapat mendukung pixel clock lebih tinggi. Biayanya adalah tambahan kerja CPU karena data harus disalin ke bounce buffer tepat waktu.

Arsitekturnya menjadi:

GUI rendering
     |
PSRAM framebuffer
     |
CPU/cache copy
     v
internal bounce buffer A/B
     |
    DMA
     v
RGB LCD

Ini bukan sakelar performa universal. Jika kedua core CPU banyak mengakses PSRAM sementara proses pengisian bounce buffer juga bergantung pada PSRAM, contention hanya berpindah ke titik lain dalam pipeline.

Double buffering mengatasi tearing, bukan biaya rendering

Dengan satu framebuffer, display dapat melakukan scan ketika aplikasi sedang mengubah image yang sama. Jika area yang terlihat diperbarui pada waktu berbeda, pengguna dapat melihat tearing.

Double buffering memisahkan frame yang sedang dipindai dari frame yang sedang disiapkan:

frame A -> LCD scanout
frame B -> GUI rendering

VSYNC boundary

frame B -> LCD scanout
frame A -> GUI rendering

ESP-IDF mendukung beberapa framebuffer berukuran penuh untuk panel RGB, dan Espressif mendokumentasikan double buffering di PSRAM sebagai cara langsung untuk menghindari tearing.

Biaya memorinya besar. Double buffering juga tidak membuat layar yang mahal untuk dirender menjadi lebih ringan. Teknik ini mencegah display memperlihatkan frame yang belum selesai dirender ketika sinkronisasinya ditangani dengan benar.

LVGL tidak mengharuskan seluruh layar digambar ulang

Library GUI seperti LVGL dapat merender ke draw buffer dan memperbarui area yang berubah, sehingga aplikasi tidak harus membangun ulang setiap pixel untuk setiap interaksi. Karakteristik ini sangat berguna pada microcontroller.

Status bar yang statis, background yang tidak berubah, dan control yang idle tidak memerlukan beban yang sama seperti animasi full-screen. Desain HMI karena itu berpengaruh langsung terhadap beban hardware.

Antarmuka yang berisi:

  • button dan toggle,
  • pengukuran numerik,
  • status icon,
  • grafik moderat,
  • halaman konfigurasi,
  • redraw lokal,

jauh lebih ringan daripada transisi full-screen terus-menerus, layer alpha-blended besar, video, atau animated background dengan frame rate tinggi.

Persoalannya bukan apakah ESP32-S3 dapat menggambar grafis. Persoalannya adalah berapa banyak pixel yang harus dibuat, disalin, dan dikirim per satuan waktu.

Display SPI dan RGB memiliki batas yang berbeda

Pada display SPI dengan GRAM internal, ESP32-S3 mengirim area pixel yang berubah melalui SPI. Setelah transfer selesai, display controller mempertahankan image tersebut. Partial update dapat mengurangi trafik bus secara signifikan.

Pada panel RGB mentah, scanout berlangsung terus-menerus. Walaupun GUI hanya mengubah satu button, interface LCD tetap harus memenuhi timing untuk raster lengkap kecuali arsitektur panel menyediakan mekanisme penyimpanan lain.

Pemilihan interface karena itu menjadi bagian dari desain performa:

SPI + display GRAM
    -> transfer area yang berubah
    -> jumlah pin lebih sedikit
    -> bandwidth serial dapat membatasi redraw besar

RGB panel
    -> raster stream terus-menerus
    -> throughput tinggi
    -> lebih banyak pin dan tekanan framebuffer/bandwidth lebih besar

Tidak ada satu interface yang selalu lebih baik untuk semua HMI. Panel kontrol kecil dapat bekerja sangat baik melalui SPI, sedangkan display lebih besar yang membutuhkan update ber-throughput tinggi dan lebih mulus dapat lebih cocok menggunakan RGB.

Wi-Fi berbagi resource dengan UI

Salah satu alasan ESP32-S3 menarik untuk HMI adalah MCU yang sama dapat menangani antarmuka lokal sekaligus koneksi jaringan. Integrasi tersebut juga berarti display bukan satu-satunya workload.

Perangkat nyata dapat menjalankan semua pekerjaan ini secara bersamaan:

touch input
GUI rendering
LCD DMA
Wi-Fi/Bluetooth
sensor acquisition
protocol handling
flash access
application logic

Benchmark yang hanya merender satu layar secara terisolasi belum mewakili kondisi perangkat sebenarnya. Pengujian yang berguna menjalankan UI bersamaan dengan networking, storage, sensor, dan background task.

Pilih board berdasarkan pipeline display

Untuk HMI berbasis ESP32-S3, pemilihan modul sebaiknya dimulai dari display, bukan hanya dari frekuensi CPU. Resolusi dan color depth menentukan ukuran framebuffer; interface dan kebutuhan refresh menentukan perpindahan data; perilaku GUI menentukan biaya redraw.

Urutan desain yang praktis:

display resolution + pixel format
             |
             v
framebuffer requirement
             |
             v
SPI or RGB interface
             |
             v
PSRAM / internal SRAM placement
             |
             v
DMA and buffering strategy
             |
             v
GUI redraw workload
             |
             v
network + application load

Untuk control panel dan embedded dashboard, ESP32-S3 memiliki compute dan peripheral yang memadai sebagai controller HMI. Batas engineering yang penting bukan sekadar “240 MHz sudah cukup cepat.” Desain yang stabil menjaga kapasitas framebuffer, trafik memori berkelanjutan, timing DMA, dan cakupan redraw tetap berada dalam satu performance budget.

ESP32-S3 HMI LVGL Display