* copy pins_arduino from tasmota not framework
* move specific P4 settings out of pins_arduino.h
* keep backwards compability
with the option to redefine the specific different P4 board configs
* Keep P4 SD card on SDMMC slot 0 and set hosted MCU pins in default module
Arduino core and libraries do not see my_user_config.h, so without
BOARD_SDMMC_SLOT in pins_arduino.h SD_MMC uses slot 1 which is taken
by ESP-Hosted.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Add command Ldo<x> <mV> to configure ESP32-P4 LDO3 and LDO4
LDOs are set at boot before any GPIO use. LDO settings of DSI display
descriptor, CSI camera and SD card are only used if not set by command
Ldo and are deprecated.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Show clear error if pins_arduino.h for a variant is missing
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Jason2866 <obermeier.johann@googlemail.com>
Co-authored-by: Jason2866 <24528715+Jason2866@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Fix silently-dropped LVGL flush chunks on ESP32-P4 DSI panels
esp_lcd_panel_draw_bitmap()'s DMA2D path takes an internal draw
semaphore with a 0 timeout and returns ESP_ERR_INVALID_STATE (without
drawing anything) if the previous async transfer hasn't completed yet.
DSIPanel::pushColors() ignored that return value, and lv_flush_callback()
always calls lv_disp_flush_ready() regardless, so LVGL believed the
flush succeeded even when the chunk was silently dropped - leaving
stale framebuffer content on screen for that region.
Retry instead of dropping the chunk. The transfer typically completes
in well under 1ms, so poll in short bursts rather than 1ms FreeRTOS
ticks; a bounded retry count still catches a genuinely stuck transfer
and logs it instead of looping forever.
* Allow LVGL DSI draw buffers to use PSRAM on ESP32-P4
lv_pixel_buf/lv_pixel_buf2 previously preferred MALLOC_CAP_INTERNAL,
costing ~120KB of scarce internal SRAM on boards where PSRAM is
otherwise nearly idle (e.g. a 1024x600 DSI panel at 60 flushlines).
Prefer MALLOC_CAP_SPIRAM instead, falling back to internal RAM if
PSRAM is unavailable - safe now that the previous commit fixes the
DMA2D transfer race that PSRAM's slower read speed was exposing.
Also switch the flush-timing debug log from millis() to micros() and
drop its DMA-path exclusion: at a ~60KB/transfer chunk size the whole
operation completes in a few hundred microseconds, so millisecond
resolution just read back 0 or 1 and the DMA path - the one we
actually needed data from - was never logged at all.
* Remove defaulting to PSRAM for now
---------
Co-authored-by: s-hadinger <49731213+s-hadinger@users.noreply.github.com>
Building with UDSP_DEBUG enabled fails:
lib/lib_display/UDisplay/src/uDisplay.cpp:908:24: error: #if with no expression
908 | #if USE_UNIVERSAL_TOUCH
| ^
USE_UNIVERSAL_TOUCH is defined without a value (my_user_config.h and the
user_config_override.h convention both use a bare `#define`), so `#if` expands
to an empty expression and the preprocessor errors out.
Every other test of this macro already uses #ifdef:
uDisplay.cpp:47 #ifdef USE_UNIVERSAL_TOUCH
uDisplay.cpp:792 #ifdef USE_UNIVERSAL_TOUCH
uDisplay_touch.cpp:4 #ifdef USE_UNIVERSAL_TOUCH
so this looks like a typo rather than a deliberate value test.
Introduced in a1639507d ("Udisp SPI fix for mono color display", #24899). It
goes unnoticed in normal builds because the block sits inside #ifdef
UDSP_DEBUG, which ships commented out at uDisplay.cpp:27 — it only surfaces
for anyone who turns that debug logging on. Found on an ESP32-P4 build with
UDSP_DEBUG enabled for DSI init diagnostics.
Co-authored-by: Ari Friedman <afriedman@millsupplyco.com>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
- Skip :TI (touch I2C) and :TS (touch SPI) lines in case 'T' of the uDisplay
descriptor parser. These touch config lines are handled separately by
xdsp_17_universal.ino via strstr(), but case 'T' was matching on the first
character and unconditionally writing the subsequent values into
panel_config->epd.lut_full_time/lut_partial_time/update_time. In the
PanelConfigUnion, these EPD fields overlap with I80 panel bus pin config
(cs_pin, dc_pin, wr_pin, rd_pin, data_pins), causing parallel displays to
silently receive corrupted GPIO pin assignments and fail to render.
The fix checks if the character after 'T' is 'I' or 'S' and skips EPD timing
parsing for those lines. EPD descriptors using :T,<timing> continue to work
as before.
- Remove dead reference to berry.lvgl_panel_loaded in xdrv_54_lvgl.ino.
The member was removed from BerrySupport in commit e4c2cf591 (Berry Extension
Manager) but the reference in start_lvgl() was left behind, causing a compile
error when USE_BERRY_LVGL_PANEL is defined.
- Add verified display descriptor for WT32-SC01 Plus (ESP32-S3, ST7796U 480x320,
8-bit parallel I80, FT5206 capacitive touch). Tested on Tasmota v15.3.0.1 with
LVGL 9.5.0.
Co-authored-by: Ari Friedman <afriedman@millsupplyco.com>
RGB565 value for pink was same as magenta. This is obviously wrong, hence correcting to the "pink" value from the docs.
While I'm far from certain about the "right" shading of color nuances, the correction does "reasonably pink" in my eyes (on a ST7789), and assuming that the value from the docs was sourced from something relevant to the small displays used with Tasmota, I consider the change to be at least a move in the right direction.
Still, the corrected value (FF80C0 in RGB888) does have the name "tea rose" when using HTML color codes as a reference, but "some people" may have more interest in long discussions like what pink "really" is.
This commit is an optimization of code and possibly performance for pushing
pixel data to an RGB display with an ESP32-S3. It uses ESP-IDF's LCD driver
for doing so and replaces multiple code paths in the previous implementation.
No code for other ESP32 variants has been changed.
Also see the discussion arendst/Tasmota#22553