Skip to content

Add support for ESP32-S3 4-Inch LCD display.#20

Open
Solaniel wants to merge 1 commit into
HermannBjorgvin:mainfrom
Solaniel:esp32-s3-4inch-led-support
Open

Add support for ESP32-S3 4-Inch LCD display.#20
Solaniel wants to merge 1 commit into
HermannBjorgvin:mainfrom
Solaniel:esp32-s3-4inch-led-support

Conversation

@Solaniel

Copy link
Copy Markdown

Add Waveshare ESP32-S3-Touch-LCD-4 support

Adds multi-board support so the same codebase compiles and runs on both the Waveshare ESP32-S3-Touch-AMOLED-2.16 (original target) and the Waveshare ESP32-S3-Touch-LCD-4 (4" 480×480 RGB LCD). All board-specific code is gated with #ifdef
BOARD_WAVESHARE_LCD4 / #else so the AMOLED build is unaffected.

Changes

firmware/platformio.ini

  • Restructured with a shared [env] base and two named environments: waveshare_amoled_216 and waveshare_lcd4
  • Both environments use board_build.arduino.memory_type = qio_opi — required for the ESP32-S3R8's OPI PSRAM on both boards
  • LCD-4 env does not include XPowersLib (no AXP2101 PMU)

firmware/src/display_cfg.h

  • Split into board-specific sections: LCD-4 uses ST7701 RGB parallel panel (Arduino_ESP32RGBPanel + Arduino_RGB_Display), AMOLED uses CO5300 QSPI (Arduino_CO5300)
  • LCD-4 pins: 16-bit RGB data bus, HSYNC/VSYNC/DE/PCLK, SPI for ST7701 init, I2C for GT911 touch on SDA=15/SCL=7
  • LCD-4 includes TouchDrvGT911.hpp; AMOLED keeps TouchDrvCSTXXX.hpp, XPowersLib.h, SensorQMI8658.hpp

firmware/src/main.cpp

  • Hardware objects: Arduino_ESP32RGBPanel + Arduino_RGB_Display + TouchDrvGT911 declared under #ifdef BOARD_WAVESHARE_LCD4
  • RGB panel constructed with bounce_buffer_size_px = LCD_WIDTH * 10 — allocates two ~9.4 KB SRAM bounce buffers so DMA never reads directly from PSRAM. This eliminates the DMA-PSRAM write race that caused tearing/jitter on the RGB panel
  • I2C peripheral expander at 0x24 initialised before gfx->begin() to power the display rails
  • GT911 touch: polled (no interrupt), I2C address scanned (0x5D or 0x14 fallback)
  • touch_isr and the interrupt-driven touch_data_ready flag guarded with #ifndef BOARD_WAVESHARE_LCD4
  • rounder_cb (CO5300 even-alignment requirement) guarded with #ifndef BOARD_WAVESHARE_LCD4
  • handle_rotation_change (brightness ramp + IMU-driven rotation) guarded with #ifndef BOARD_WAVESHARE_LCD4
  • gfx->setBrightness() calls guarded (method doesn't exist on Arduino_RGB_Display)
  • Forward button mapped to GPIO 4 on LCD-4 (GPIO 18 is display data line R3 on this board)
  • LVGL partial render mode with double PSRAM-backed buffers for both boards

firmware/src/power.cpp

  • LCD-4 stub implementations (no AXP2101): power_init/power_tick are no-ops; power_battery_pct returns -1; power_is_charging and power_pwr_pressed return false

firmware/src/imu.cpp

  • LCD-4 stub implementations (no QMI8658): imu_init/imu_tick are no-ops; imu_get_rotation always returns 0

flash-mac.sh

  • Now requires as the first argument (e.g. ./flash-mac.sh waveshare_lcd4) to prevent accidentally flashing the wrong firmware binary

Test plan:

  • ✅ pio run -e waveshare_amoled_216 builds without errors or warnings (AMOLED build unaffected)
  • ✅ pio run -e waveshare_lcd4 builds without errors or warnings
  • ✅ LCD-4 board shows splash screen on boot; no tearing or jitter
  • ✅ BLE connects and usage data renders on the usage screen
  • ✅ Single button only due to hardware limitations
  • ✅ Touch input navigates the UI on LCD-4
  • ✅ ./flash-mac.sh without arguments prints usage and exits cleanly
  • ⚠️ Not regression-tested on Linux — I don't have a Linux setup

Tested on an ESP32-S3 4" LCD Display board on a Macbook Pro 2022 M3:

IMG_5571 IMG_5572 IMG_5573 IMG_5574

@HermannBjorgvin

Copy link
Copy Markdown
Owner

Hey thanks for your contribution! Here's a bit of an update:

I held off on merging any alternative hardware ports because I wanted a good abstraction layer for that. Then @tobby168 came in clutch and delivered that in #25 with instructions in the docs folder on how to implement your port.

We include detailed instructions now which hopefully would allow your clanker to refactor your PR to conform with the new standard, thank you for your patience!

P.S. if you can post a picture of your port that would be appreciated, I enjoy seeing how it looks on people's devices!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants